[rfc-i] RFC Standard Process question

[Scott Bradner]

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

Scott

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


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

Julian-

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

--aaron


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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)

iD8DBQFAm7FB/i95hBY97NERAj32AKCOiqDYsUZyNuT6bWCJV+gdRl+qWwCgiofR
kfTFHN5ssloKLzvyt66R/Vs=
=gpkL
-----END PGP SIGNATURE-----

--Apple-Mail-33-411382928--