ietf
[Top] [All Lists]

Re: Last Call: <draft-housley-two-maturity-levels-06.txt> (Reducing the Standards Track to Two Maturity Levels) to BCP

2011-05-05 13:28:25
Ted:

The document currently says:

   Downward normative references to Informational documents continue to
   be allowed using the procedure specified in RFC 3967 [2].

   Downward normative references to Historic documents, Experimental
   documents, and Internet-Draft documents continue to be prohibited.

I believe these two statements are in conflict and the conflict must be 
resolved.  My reading of 3967 is that if the community has approved the use 
of an Experimental document or internet-draft as a downref in a specific last 
call, that downref is permitted and may even become institutionalized (see 
the text on an AD waiving further last calls).  One of the reasons given in 
RFC 3967 is:

o A migration or co-existence document may need to define a standards track 
mechanism for migration from, and/or co-existence with, an historic protocol, 
a proprietary protocol, or possibly a non-standards track protocol.


Unless a downref is permitted here, in other words, no coexistence or 
migration mechanism can ever advance to Internet Standard.  This seems to me 
contrary to the aim of the document.  I recommend that the Last Call for 
advancement re-iterate any downrefs as a specific part of the call and that 
these calls be lengthened to 4 weeks.  This seems to me to follow the current 
BCPs best, but other resolutions are, of course, possible.

Good catch.  I think we should revise this to allow normative references to 
Informational, Experimental, and Historic RFCs using the procedures in RFC 3967.



I strongly object to this text in Section 5:

2) At any time after two years from the approval of this document as
       a BCP, the IESG may choose to reclassify any Draft Standard
       document as Proposed Standard.

Section 1 already provides a method for any interested party to request that 
a document advance from Draft to Internet Standard.  Creating another, less 
stringent method to be employed only after 2 years is, at best, odd.  At 
worst, it seems like a signal that the IESG desires to do a mass update in 
the future, but does not wish to deal with the political fall-out of saying 
so at the same time as the publication of the document.  I draw this 
inference from the fact that the current section 2 does not require any 
IETF-wide Last Call.  If this is meant to say that after 2 years, any IESG 
member may put forward a Last Call for any document to be advanced, then I 
believe that the IESG member is simply taking the role of community member 
set forward in Section 1, and no further section is needed.  IESG review, 
Last Call, and approval would still go forward according section 1.

In case this is not clear, I do not think a mass update is valuable or 
desirable.  Many of the critical RFCs are pre-Track and no one much seems to 
mind.  At most, I think saying that Internet Standards are permitted to 
reference Draft Standards is needed.  (This can be inferred now from the fact 
that Proposed Standards may be referenced, but it wouldn't hurt to update 
that in section 4).

I also strongly believe that this proposal will not have the intended effect 
without concerted efforts by the IESG and WG Chairs to adhere to the new 
"Proposed Standard" vision.  As a new WG Chair, I plan to push that vision 
for my own group, and I hope that the IESG will support that effort as this 
document intends.

I am lost here.  Based on a previous version of the Internet-Draft, the 
question was raised by Brian Carpenter about documents that were stuck in a 
state Draft Standard after that label is abandoned.  There was discussion on 
the list, and some people felt that it was neither confusing nor harmful, while 
others thought that it would lead to confusion.  This proposal is intended to 
let the IESG decide,  If it is not considered a problem, they can do nothing.  
If it is considered a problem, they can move the Draft Standard DOWN to 
Proposed Standard.  Your use of "be advanced" makes me wonder if you got a 
different interpretation.

Russ

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>