Subject: Re: [newtrk] IESG comments on ISD proposal

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 3 Jun 2005 07:22:31 -0500

Just to make my constant hallway comment on the mailing list (which I 
should have done a month ago)...

> Specifically, concern was expressed that determining the right
> granularity (e.g. how many ISDs would be needed to cover the SIP 
> area,
> and how many SIP RFCs would be pointed to by multiple ISDs) would be
> very hard, and would lead to complexity and confusion when updates 
> occur.

This is the perfect example (but not the only perfect example) of why 
ISDs are needed.

In today's world, without ISDs, the complexity and confusion happens 
for every implementer of SIP. Doing this work in private may not 
hinder interoperability (IFF every implementer gets the definition of 
"SIP" right), but cannot improve interoperability.

Having the SIP community slug out "this is the definition of SIP" is 
the right place to do it - not having the SIP implementers slug it out 
in test labs and in production networks, in places where the revealed 
definition never makes it back into specifications.

Yesterday, I was looking at a lovely SCTP trace that had every 
checksum wrong (not code we wrote) - someone implemented Adler-32, 
from RFC 2960, and didn't update it with CRC-32, from RFC 3309. This 
trace was taken from a production carrier network.

You get a clear "updated by RFC3309" if you look on the RFC Editor's 
search page for RFC 2960, but our current practice of pointing to RFCs 
(which don't say "and I was updated by RFC 3309") makes it more likely 
people will miss stuff like this - especially people who don't have 
the experience with our document series that we have.

If SCTP ever becomes an STD, we can tie the documents together more 
tightly, but when's that likely to happen?

Spencer 

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Sam Hartman <[email-masked]>
Date: Fri, 03 Jun 2005 10:45:05 -0400

Folks, no matter what happens to ISDs, I don't see that ISD references
would replace RFC references in other RFCs for the most part.

It is very common for one RFC to refer to section foo.bar of another
RFC.  You cannot do that with an ISD reference.  You might be able to
refer to an ISD if you are saying something really basic like
"implement SCTP," but not if you refer to any details.

I would certainly consider it a really bad idea if we got out of the
practice of making references to specific sections, especially if the
thing we refer to covers multiple RFCs.

--Sam
.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 5 Jun 2005 23:36:28 -0500

Hi, Sam,

> "implement SCTP," but not if you refer to any details.

Perhaps I misunderstood, but I was keying off the following text in 
http://www.ietf.org/internet-drafts/draft-ietf-newtrk-repurposing-isd-03.txt, 
which I interpreted as saying that ISD references could actually be as 
precise as RFC references.

Perhaps you are correct - that people will continue to (try to) refer 
to RFCs as they do today, no matter what Newtrk produces. This 
practice has been problematic for me (and is becoming more problematic 
as time goes on), but the world does not always do what I wish it did. 
So you may be correct.

Spencer

9.1  References to ISDs or References to RFCs

   Before this proposal was generated, vendors who wished to specify
   what they support, and potential customers who wished to specify 
what
   they wanted to purchase, had a choice between referencing specific
   RFCs (to get precision) or, for full standards, a specific STD 
number
   (to get "the most current version").  Except for providing an "ISD"
   mechanism for referencing documents other than full Internet
   Standards, this proposal does not change either of those options:
   both are still free to use the existing forms.  In the rare case in
   which a vendor is deliberately attempting to confuse its potential
   customers, this mechanism is not likely to help very much either. 
It
   does, however, provide a third option, which is to specify the 
state
   of an ISD (and hence a Standard) as of a particular date (even a 
date
   in the past or future) or within a particular date range.  So,
   whatever the referencing issues are today, this certainly does not
   make them worse and almost certainly makes them better.

   It should also be noted that other Standardization bodies have had
   difficulties when referencing RFCs.  It is not always clear whether
   an RFC or an STD should be referenced.  When a reference is made,
   there can be problems when the RFC that is referenced becomes 
updated
   or obsoleted.

.