Subject: [Sip] On The Essentialness of Corrections

From: Dean Willis <[email-masked]>
Date: Fri, 14 Dec 2007 11:42:13 -0600

Keith has been kind enough to define a process for rolling up all the  
updates/corrections/revisions to RFC 3261 we might process in a given  
year into a single document. This process is documented in draft- 
drage-sip-essential-correction-02. We hope to apply this same process  
to other RFCs in the core set.

We've recently been having some discussion on what, if any, drafts  
should be steered into this process vs. conventional standards and  
BCP tracks.

Let's revisit the rationale for the "essential corrections" process:  
the idea is to reduce the number of documents that an implementer  
will have to read in order to produce a correct implementation of our  
RFCs. Problems and their corrections belong not in a bug-tracking  
system, but need to be resolved in IETF-published documents.

I believe that Jonathan sees draft-ietf-sip-hitchhikers-guide-04 as  
the place where all of the core RFCs, their extensions, and  
corrections thereto are put into a usable order and given the  
perspective needed to make them work. That's certainly one way to  
track the relationships between various documents, and I think we  
need it. But I think we need something else.

There are two primal approaches to updating RFCs. In one, every  
change is an optional extension to the RFC that might or might not be  
used. Negotiation mechanisms like option tags are required for every  
extension, as is fallback behavior to operation without that  
extension. The nature of the core protocol remains unchanged --  
perhaps certain modalities are never exercised, but they remain in  
the specifications as paths that need to be tested for when  
considering compliance against the specifications.

The second approach is to issue revisions that actually change the  
specification, potentially eliminating or replacing entire blocks of  
functionality that need no longer be tested, and potentially  
inserting new behavior that becomes "the standard" against which  
implementations are judged. The most obvious way to make these sort  
of changes to an RFC is to issue a new RFC that replaces (and makes  
obsolete) an older one. IETF also allows new RFCs to "revise" older  
ones, essentially including them by reference into a new  
specification. The problem with this approach is that it might be  
possible for many such revisions to be made to a large spec such as  
RFC 3261, and it then becomes very difficult to effectively "merge"  
all these changes into a working specification against which one can  
implement (and test) correctly.

Out "essential corrections" process is an attempt to manage the  
complexity of many revisions by collecting those revisions into  
periodic batches and issuing each batch as an RFC that revises a core  
specification.

The question is: Which, if any, changes need to be processed as  
extensions and which as revisions?

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'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".

--
Dean

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

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 14 Dec 2007 19:48:14 +0200

Dean Willis writes:

 > Then instead  

that sounds like a good idea.  would only corrections go to the bis
documents or would also clarifications be allowed?

-- juha

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 14 Dec 2007 15:11:36 -0600

> occasionally publishing them as RFCs that replace the older versions.

We are still talking the sip-essential-correction model here, right?
Or is what you propose above a new model?

> 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".

Isn't that what we essentially did with rfc2543-bis set of drafts?
Of course, the domain of influence of SIP back then was a bit more
limited than it is now.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 Dec 2007 17:36:05 -0500

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.

> 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.

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.

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.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Dean Willis <[email-masked]>
Date: Sat, 15 Dec 2007 12:27:07 -0600

> Or is what you propose above a new model?

It's the "logical product" of the essential corrections process.

Each draft in the essential corrections process has to specify line- 
by-line changes to the RFC it is correcting. If we were to extract  
those changes and apply them to the source, we would get the  
"tracking draft" I'm talking about.

> Of course, the domain of influence of SIP back then was a bit more

Not really. The 2543-bis work was more traditional draft editing. The  
various editors would get input, make changes to the draft, then we'd  
review the changes and maybe accept them or back them out or change  
them again.

In the extended essential corrections process, we'd formally review  
and reach consensus on each change before committing the change into  
the -bis document. So every -bis document would reflect WG consensus  
on the changes at any given time.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 15 Dec 2007 12:53:01 -0600

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.
>
> 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.

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.

>> 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".
>

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? 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? 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 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.

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.

> 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.

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Sun, 16 Dec 2007 00:03:20 +0200

> do we want a base document plus many "diff" deltas?

there should be one document that implementor needs to read, not a base
plus corrections docs.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Sat, 15 Dec 2007 18:11:49 -0600

> there should be one document that implementor needs to read, not a  

Thanks! I know when you agree with something that it's probably  
technically right. However, it's also usually a sign that I'm going  
to have a hard time convincing the other folks in the WG about it!

Have a happy holiday season and new year.

--
dean

---

From: "Frank W. Miller" <[email-masked]>
Date: Sat, 15 Dec 2007 17:19:29 -0700

Here's another indication.  I think it should be one document too.

FM

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 17 Dec 2007 08:42:27 +0000

As a further consideration, MMUSIC already seems to be taking an
approach for SDP similar to Dean's proposal for SIP:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-00.txt

John

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: 15 December 2007 18:53
> To: Jonathan Rosenberg
> Cc: IETF SIP List
> Subject: Re: [Sip] On The Essentialness of Corrections
> 
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 17 Dec 2007 10:00:58 -0600

Dean Willis wrote:
> Each draft in the essential corrections process has to specify 
> line-by-line changes to the RFC it is correcting. If we were to extract 
> those changes and apply them to the source, we would get the "tracking 
> draft" I'm talking about.

OK; I am with you now.  In that case, yes, maintaining one draft
is preferable.

This also means that -- as Jonathan said earlier -- we have to be
careful as to what constitutes an essential correction  vs. new
functionality.

- vijay

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 17 Dec 2007 18:12:30 +0200

> OK; I am with you now.  In that case, yes, maintaining one draft

for the maintenance i suggest keeping the draft in subversion repository
and each time a change is agreed, a commit will be made.  this way it is
easy keep the draft up to date.  also, a change history is automatically
visible.  once in a while, editors can issue a new tag, which will
become next rfc bis.

-- juha

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 Dec 2007 12:31:05 -0500

inline:

Dean Willis wrote:
>> 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.
>>
> 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 

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.

> 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.

>> 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.

>> 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.
> 
> 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.