Re: [Sip] On The Essentialness of Corrections

[Jonathan Rosenberg <[e-mail]>]

inline:

Dean Willis wrote:
> 
> On Dec 14, 2007, at 4:36 PM, Jonathan Rosenberg wrote:
> 
>> inline:
>>
>> Dean Willis wrote:
>>
>>> Here's a test I'd like to propose: If the change is such that if we 
>>> were re-writing the affected RFC we'd include the new behavior as 
>>> normative behavior, then we track it as a revision. This allows us to 
>>> fully deprecate the behavior that it replaces, such that we no longer 
>>> have to consider the old behavior when compliance testing. If we 
>>> can't deprecate the replaced behavior, then we really do have an 
>>> extension (not a revision), and we need an extension negotiation 
>>> mechanism to know when it can be used or is being used.
>>
>> I'm not sure I agree with this. I think we have some extensions which 
>> we'd arguably include as, 'things we'd make as new normative behavior 
>> that is core to sip'. I personally would have wished that nat 
>> traversal were an integral part of sip and if I could do it over, 
>> would not have it split out. But clearly ICE and outbound and all that 
>> are not essential corrections.
>>
>> In my mind, the right litmus test is that the new behavior:
>>
>>   1. cannot be negotiated using the standardized techniques, AND
>>   2. represents a change that impacts interoperability with other 
>> implementations which might not implement this new behavior
>>
>> THEN its an essential correction.
>>
>> THings like BNF bugs are clearly in scope. Something like record-route 
>> fix doesn't meet this litmus test because of the second item. I can 
>> implement this and fully interoperate with existing implementations.
> 
> Ok, there's probably a valid argument here. It's important to note also 
> that if something is an "essential correction", we'd be willing to say 
> that an implementation that does not conform to the correction is in 
> violation of the specification and needs to be fixed. In other words, 
> there is the same sort of justification for fixing it as there is for 
> "MUST" in RFC 2119 -- failure to conform creates a failure to 
> interoperate or function correctly.

Right, and to be clear, 'violation of the specification' basically 
refers to 3261 itself.

> 
> Now, it's arguable whether the record-route-fix falls into this category 
> or not. Route rewriting, as opposed to double recording, prevents route 
> signing. Is the ability to use route-signing important enough that we'd 
> say that any implementation that precludes its use is "broken"? I'd say 
> that this is the test.

Clearly no. RFC3261 explicitly says you can't do it. I can't think of 
any reasonable use case for it.


> 
> 
>>> I'd actually like to see us go beyond the batching of "essential 
>>> corrections" and start maintaining complete and fully-revised 
>>> versions of the normative behaviors as internet drafts, perhaps 
>>> occasionally publishing them as RFCs that replace the older versions. 
>>> So for example with RFC 3261, we'd maintain a 
>>> "draft-ietf-sip-rfc3261-bis" that would start as a copy of RFC 3261 
>>> (with current boilerplate, of course) and then be edited to reflect 
>>> the changes documented in each "essential correction" we agree to. 
>>> Then instead of telling implementors to go read RFC 3261 plus a dozen 
>>> more potentially conflicting revision documents, we could just say 
>>> "see draft-ietf-sip-rfc3261-bis-xx".
>>
>> I thought the idea is that there is just one revision document 
>> (essential corrections) and not seven.
> 
> Let's say we roll the 7 changes (I just made that number up, there may 
> be more or less) for 2008 into the 2008 essential corrections RFC. What 
> do we do in 2009? Copy all of the 2008 changes into the 2009 RFC? 

That was Keith's original proposal.

> What 
> happens when we've had overlapping changes, such that the same part of 
> the spec has been touched twice? Does the second change need to write 
> step-by-step edits against the base RFC, or against the base RFC as 
> amended by the first change? 

Well, this may be a problem in theory only and not in practice. We don't 
have this problem AFAIK for any of the existing stuff.


> This gets hairy, and it is made a lot 
> easier if we write the first change against the RFC, apply the first 
> change to the RFC to generate the -bis spec, and then make subsequent 
> corrections bundles against the -bis spec. This gives us a "fully 
> assembled" spec to work against. Reverse deltas as opposed to forward 
> deltas, from a source-code-control perspective.

I agree that it is easier for someone, starting from scratch, to pick up 
a document which is all of sip including the corrections, all built in. 
However for folks who already implemented rfc3261 and want to know what 
has changed, a separate document that clearly states the new 
functionality is easier.

> 
>> I promise you that once you open the floodgates to an rfc3261 revision 
>> spec, the temptation to do LOTS of other things to the document will 
>> be too great. Clarify this while we're at it? OK. Maybe we should pull 
>> that extension in. ANd so on. I don't want to do that. Segmenting this 
>> into an essential corrections document keeps pandoras box from opening.
> 
> I'll certainly agree that a substantial amount of discipline is required 
> in either case.

I think we'll find the discipline much harder to follow if we are 
actually producing an rfc3261bis. Would we indeed reject a one-line 
clarifying correction?

> 
> The question is: Do we want one document an implementor can go to, or do 
> we want a base document plus many "diff" deltas?
> 
> Looking at the bug tracker for RFC 3261, I can see that there have been 
> 85 different bugs filed. While some may not meet the criteria of 
> "essential" (is confusing "excepting" and "accepting" essential?), I'll 
> bet you there are still a lot of things that need fixing in the doc. And 
> RFC 3261 isn't the only spec that needs polishing -- there are over 200 
> bugs in that tracker.

OK - so that is more than just a few essential corrections, its a real 
revision.

> 
>> The amount of work that went into rfc2543 -> rfc3261 was astoundingly 
>> large, as any of the editors who basically did this as a full time job 
>> for like 6 months will tell you (my boss would ask me when I was 
>> coming back to work...). I do not think we as a working group have or 
>> want to spend the cycles on such a monumentally large task at this time.
> 
> I'm not proposing SIP 3.0 here -- just proposing ways to correct the 
> known bugs in our RFCs that produces a result usable by developers, 
> students, other SDOs, and other readers of those RFCs. What we're doing 
> now IS NOT WORKING.

WELL, rfc2543->rfc3261 wasn't a sip3.0 either; it was meant to be only 
fixes, clarifications and elimination of unimplemented things. But it 
was still huge.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[e-mail]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip