[rfc-i] RFC Standard Process question

Aaron Falk falk at ISI.EDU
Fri May 7 08:54:41 PDT 2004


Section 4.1.2 or rfc2026 says:

    The requirement for at least two independent and interoperable
    implementations applies to all of the options and features of the
    specification.  In cases in which one or more options or features
    have not been demonstrated in at least two interoperable
    implementations, the specification may advance to the Draft Standard
    level only if those options or features are removed.

and in section 6.2:

    A specification may be (indeed, is likely to be) revised as it
    advances through the standards track.  At each stage, the IESG shall
    determine the scope and significance of the revision to the
    specification, and, if necessary and appropriate, modify the
    recommended action.  Minor revisions are expected, but a significant
    revision may require that the specification accumulate more
    experience at its current maturity level before progressing. Finally,
    if the specification has been changed very significantly, the IESG
    may recommend that the revision be treated as a new document, re-
    entering the standards track at the beginning.

So, it appears to me (not in any RFC Editor capacity) that removing 
non-implemented options is part of going from Proposed to Draft and, 
so, doesn't push you back to the start.  However, it appears to be a 
judgment call _on the part of the IESG_ as to whether the changes are 
significant enough.

Now, speaking for the RFC Editor, since this is a standards process 
question, not an RFC publication question, rfc-i is the wrong list.  
I'd suggest addressing the IESG directly and cc'ing the IETF general 
list or possibly the newtrk list (since they are contemplating changes 
to the process).


On May 7, 2004, at 7:33 AM, Julian Reschke wrote:

> Hi,
> I have the following question about what kind of changes are allowable 
> when a specification is meant to be advanced from "Proposed" to 
> "Draft".
> Assuming a specification defines a core protocol, plus a set of 
> features that are clearly marked as "optional" (so a server doesn't 
> need to implement them), and in particular the protocol defines how 
> support for these features can be discovered at runtime.
> Is it possible to advance the base protocol to "Draft" while removing 
> optional features from the document (possibly moving them into a 
> separate document)?
> Looking at the history of RFC2396 (currently at "Draft") indicates 
> that this has happened before, and certainly this makes a lot of 
> sense. On the other hand, some people are telling me that in cases 
> like these, the protocol revision would need to go back to "Proposed".
> Feedback appreciated,
> Julian
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> http://www.rfc-editor.org/mailman/listinfo/rfc-interest
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20040507/0a1d704d/PGP.bin

More information about the rfc-interest mailing list