Re: draft-housley-two-maturity-levels

[Mykyta Yevstifeyev <[e-mail]>]

25.01.2011 6:13, Tony Hansen wrote:
> On 1/24/2011 12:37 PM, Russ Housley wrote:
>> draft-housley-two-maturity-levels-03 was just posted. ...
>
> Overall I find this spec to be an improvement over the previous 
> version. Here are a few areas where improvements can be made.
>
> ====
> [. . . . .]
>
> ====
>
> One major section that has been removed from the previous version of 
> this I-D is what to do with documents currently in the Draft Standard 
> status. I know that there was significant disagreement with the 
> "automatic reclassification to Internet Standard" proposed before, 
> with good reason.
>
> I'm going to letter the the rules in section 2.2 as follows. I'm also 
> going to indicate how these sort of map into the old classifications:
>
>     a) technical maturity (DS => FS)
>     b) belief in significant benefit to Internet community (DS => FS)
>     c) significant number of implementations with successful 
> operational experience (DS => FS)
>     d) no unresolved errata (PS => DS)
>     e) no unused features that increases implementation complexity (PS 
> => DS)
>
> Some people have argued that having a significant number of 
> implementations (c) is sufficient to demonstrate both technical 
> maturity (a) and the belief in benefit (b). The (d) and (e) 
> requirements have already been demonstrated by virtue of those RFCs 
> already being at DS status, although additional errata may have been 
> filed against the DS.
>
> So I'm going to suggest that the following be applied to documents 
> that are currently in Draft Standard status:
>
>     Any protocol or service that is currently in Draft Standard 
> status, without
>     significant unresolved errata, may be reclassified as an Internet 
> Standard
>     as soon as it can be demonstrated to have a significant number of
>     implementations with successful operational experience.
>
>     This reclassification may be accomplished by filing a request with 
> the IESG,
>     detailing the Implementation and Operational Experience. After 
> review, the
>     IESG will hold an IETF-wide Last Call on the reclassification. If 
> there is consensus
>     for the reclassification, the RFC will be reclassified without 
> being reissued.
>
>     Protocols and services that have significant unresolved errata 
> will need to be
>     re-issued to resolve the errata before the above criteria can be 
> applied.
>
> Of course, there is still an open question what it means to have a 
> "significant number", which will remain as subjective as it was before 
> with the 2026 rules.
Russ, Tony, all,

I think that Section 5, regarding STD numbers, does not fully introduce 
the topic and is not acceptable.  So I'd like to propose the following 
solution: the STD numbers are splitted into two groups: STD P-xxx and 
STD F-xxx, for proposed and full standards and assigned to all 
Standards-Track document once they move to one of these levels.   The 
number must then be the same for P- and F- groups, with one of them 
reserved while the doc is in the other level.  I.e. the doc is PS - STD 
F-xxx is reserved and vice versa.

This, IMO, will resolve the problem with STD numbers.

As for the issue with Draft Standards, I find that Tony proposed 
acceptable.  But we should mention that if reclassification to FS did 
not gain the consensus, the spec. is reclassified to Proposed Standard.

All the best,
Mykyta Yevstifeyev
>
>     Tony Hansen
>     [e-mail]
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>