[Sip] On The Essentialness of Corrections

[Dean Willis <[e-mail]>]

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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip