Re: [newtrk] IESG comments on ISD proposal

["Spencer Dawkins" <[e-mail]>]

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