Re: draft-housley-two-maturity-levels

+1 to the proposed rules for reclassifying DS to IS. I think they offer a
reasonable balance between expediency and quality.

				Ned

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

> ====

> This phrase in Section 1:

>      In addition,
>      IETF working groups and IESG members providing much more scrutiny
>      than is called for by RFC 2026 [1] prior to publication as Proposed
>      Standard.

> is not a sentence. Should it be "provide"? Should it be "have been
> providing"? Something else?

> ====

> The sentence in Section 1

>      One desired outcome is to provide an environment where the
>      IETF community is able to publish Proposed Standards as soon
>      as rough consensus is achieved.

> and these sentences in Section 2.1:

>      The intention of the two-tier maturity
>      ladder is to restore the requirements for Proposed Standard from RFC
>      2026. No new requirements are introduced; no existing published
>      requirements are relaxed.

> together lay out what is required for PS. Disregarding the other
> arguments over the word "restore", these sentences are otherwise fine
> and dandy.

> But I think there needs to be further guidance provided to the IESG and
> Working Groups on how they should change their behavior. What is wrong
> with how the WGs and IESG are currently interpreting the rules of 2026
> for PS? What current behaviors differ or have gone beyond what 2026
> requires, and hence need to be changed to restore those requirements?
> Without such guidance, nothing changes.

> ====

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

>      Tony Hansen
>      tony@att.com
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf