[rfc-i] RFC Standard Process question

Scott Bradner sob at harvard.edu
Fri May 7 11:47:53 PDT 2004

basic assumption for years has been that removing options
(used or not) does not force a recycle 


>From falk at ISI.EDU  Fri May  7 11:55:58 2004
X-Original-To: sob at newdev.harvard.edu
Delivered-To: sob at newdev.harvard.edu
In-Reply-To: <409B9E2F.9030600 at gmx.de>
References: <409B9E2F.9030600 at gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-33-411382928"
Content-Transfer-Encoding: 7bit
Cc: Harald Tveit Alvestrand <harald at alvestrand.no>,
	Scott Bradner <sob at harvard.edu>, rfc-interest at rfc-editor.org
From: Aaron Falk <falk at ISI.EDU>
Subject: Re: [rfc-i] RFC Standard Process question
Date: Fri, 7 May 2004 08:54:41 -0700
To: Julian Reschke <julian.reschke at gmx.de>
X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3)
X-Mailer: Apple Mail (2.613)
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: falk at isi.edu

Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed


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

content-type: application/pgp-signature; x-mac-type=70674453;
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

Version: GnuPG v1.2.2 (Darwin)



More information about the rfc-interest mailing list