[rfc-i] RFC Standard Process question
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
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:
> I have the following question about what kind of changes are allowable
> when a specification is meant to be advanced from "Proposed" to
> 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,
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
-------------- next part --------------
A non-text attachment was scrubbed...
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