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

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 28 Jul 2011 08:05:54 +0300

Hello,

The new version is obviously shorter, but it omits some points.  With 
eliminating of DS level, RFC 5657 makes no sense more.  It should be 
obsoleted and moved to Historic by your document, if IESG decides to 
eliminate the requirement for interoperability documentation, which I am 
opposed to (see my LC comments to -06).

Another issue is STD numbers.  Mentioning that they are still assigned 
to ISs in Section 2.2 should be fine.

Also, Section 3.3:

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

Won't such action be allowed after 2 years from approval?

Mykyta Yevstifeyev

28.07.2011 5:02, The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Reducing the Standards Track to Two Maturity Levels'
>    <draft-housley-two-maturity-levels-08.txt>  as a BCP
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Jul 2011 09:52:32 -0400

On 7/28/11 1:05 AM, Mykyta Yevstifeyev wrote:
> eliminating of DS level, RFC 5657 makes no sense more. 

Wrong. The *title* needs to be adjusted, but mutatis mutandis the
general advice is useful.

> It should be

I see no reason to move RFC 5657 to Historic.

> to ISs in Section 2.2 should be fine.

The STD issue is orthogonal.

> Won't such action be allowed after 2 years from approval?

That's what the text says, no?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 28 Jul 2011 20:55:50 +0300

The document says:

>     RFC 2026 [1] requires a report
>     that documents interoperability between at least two implementations
>     from different code bases as an interim step ("Draft Standard")
>     before a specification can be advanced further to the third and final
>     maturity level ("Standard") based on widespread deployment and use.
>     In contrast, this document measures interoperability through
>     widespread deployment of multiple implementations from different code
>     bases, thus condensing the two separate metrics into one.

which implies that no requirement for interoperability reports is set.  
RFC 5735 defines what the implementation report is; so I think retaining 
RFC 5735 as BCP will create confusion, as it will define procedures for 
the issue which no longer exists.

> I see no reason to move RFC 5657 to Historic.

See above.

> That's what the text says, no?

Yes, I misunderstood the statement.  I thought that before 2 years come, 
DS->PS may be OK while after these 2 years this won't be OK, while it's 
vice versa.

Mykyta

---

From: Bob Hinden <[email-masked]>
Date: Fri, 29 Jul 2011 10:39:25 -0400

Hi,

I generally support this proposal, but have some questions on Section 2.3, "Transition to a Standards Track with Two Maturity Levels".  I am both an author of several Draft Standards and have chaired working groups that have produced them.

>    Any protocol or service that is currently at the abandoned Draft
>    Standard maturity level will retain that classification, absent
>    explicit actions.  Two possible actions are available:
> 
>    (1) A Draft Standard may be reclassified as an Internet Standard as
>        soon as the criteria in Section 2.2 are satisfied.

What is the process for this?  Is the IESG going to review all Draft Standards.  Should authors and/or working groups propose a change of status as defined in the document?  Something else?  Most draft standards very likely meet most of the requirements listed in the document for Internet Standard.

>        document as Proposed Standard.

I think this is unfair to the people who have done considerable work to get a document to Draft Standard.  I hope that the IESG would only do this after giving a lot of notice to the authors, appropriate working groups, and the IETF community to give them the opportunity to request advancement to Internet Standard. 

I think this Section of the document needs to provide additional detail on how this should work.

Regards,
Bob

---

From: Russ Housley <[email-masked]>
Date: Fri, 29 Jul 2011 11:13:50 -0400

> What is the process for this?  Is the IESG going to review all Draft Standards.  Should authors and/or working groups propose a change of status as defined in the document?  Something else?  Most d…

Section 2.2 is pretty clear I think.  A request to reclassification must be sent to the IESG.

   ... The request for reclassification is sent to the
   IESG along with an explanation of how the criteria have been met.
   The criteria are:

   (1) There are at least two independent interoperating implementations
       with widespread deployment and successful operational experience.

   (2) There are no errata against the specification that would cause a
       new implementation to fail to interoperate with deployed ones.

   (3) There are no unused features in the specification that greatly
       increase implementation complexity.

   (4) If patented or otherwise controlled technology is required for
       implementation, the implementations demonstrate at least two
       separate and successful uses of the licensing process.

> I think this is unfair to the people who have done considerable work to get a document to Draft Standard.  I hope that the IESG would only do this after giving a lot of notice to the authors, appro…

This was added after the discussion that Draft Standards could linger for a very long time.  Some people said that would not be a problem, and other people said it would be harmful.  I conclude that no one knows, so we should include the powers necessary to resolve the problems if they emerge.  If they do not emerge, there is no requirement that the IESG do anything.

> I think this Section of the document needs to provide additional detail on how this should work.

I do not think we should add speculation about the potential problems to this document.

Russ

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 29 Jul 2011 12:53:05 -0400

On 7/29/2011 11:13 AM, Russ Housley wrote:
>>> (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.
>>
>> I think this is unfair to the people who have done considerable work to get
>> a document to Draft Standard.  I hope that the IESG would only do this
>> after giving a lot of notice to the authors, appropriate working groups,
>> and the IETF community to give them the opportunity to request advancement
>> to Internet Standard.
>
> This was added after the discussion that Draft Standards could linger for a
> very long time.  Some people said that would not be a problem, and other
> people said it would be harmful.  I conclude that no one knows, so we should
> include the powers necessary to resolve the problems if they emerge.  If they
> do not emerge, there is no requirement that the IESG do anything.

If a document no longer has anyone watching it, there's a reasonable concern
that it no longer has much constituency.  In that case, it's better to treat it 
as immature rather than mature.

> I do not think we should add speculation about the potential problems to this

+1

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: SM <[email-masked]>
Date: Fri, 29 Jul 2011 12:43:43 -0700

At 07:02 PM 7/27/2011, The IESG wrote:

>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2011-08-24. Exceptionally, comments may be

 From Section 2.1:

  "no existing published requirements are relaxed".

Are these published requirements BCPs?

 From Section 2.2:

   'This maturity level is a merger of Draft Standard and Standard as
    specified in RFC 2026 [1].  The chosen name avoids confusion between
    "Draft Standard" and "Internet-Draft".'

Shouldn't that be "Internet Standard" instead of "Standard"?

    "The request for reclassification is sent to the IESG along with an
     explanation of how the criteria have been met.
     The criteria are:

    (3) There are no unused features in the specification that greatly
        increase implementation complexity."

The document that has been the subject of innumerable messages 
highlights how difficult it can be to reclassify a RFC.  Moreover, it 
amplified the divide between application folks and operators.  The 
IESG could have used the review clause from RFC 2026 and:

   (i)  requested an implementation report from the people in favor of the
        proposed standard; and

   (ii) a statement about deployment to determine whether there are operational
        issues that have to be addressed.

I don't know whether application folks and operators agree that 
cross-area requires mutual understanding.

The creation of interoperable protocol implementations requires clear 
specifications.  Interoperability does not mean that the protocol 
would not have unintended effects on the network.  That is where 
operational experience comes in.  It can serve as valuable input to 
improve a specification.  For what it is worth, there approximately 
75 implementation reports have been submitted since 1996.

A two-step maturity level folds the two different classes of issues 
into one.  Quoting RFC 5657, which this draft unfortunately does not reference:

   "Moving documents along the standards track can be an important signal
    to the user and implementor communities, and the process of
    submitting a standard for advancement can help improve that standard
    or the quality of implementations that participate."

During a discussion on another mailing list, it has been mentioned 
that such an effort has a cost.  Lumping all the issues together can 
only increase that cost.

Strangely, this draft argues for measuring "interoperability through 
widespread deployment of multiple implementations from different code 
bases".  It will be more difficult to remove features once 
implementations are widely deployed.  Keeping the feature fight 
within the Draft Standard  discussion can reduce the level of 
controversy at the last step.  As a side note, it would be less 
costly if feature evaluation was based on implementations instead of 
what people would like to keep (only one implementation of a feature).

Once a Proposed Standard is published, it is expected that people 
will go and write code, if they have not done so yet, and evaluate 
whether their implementation can interoperate with other 
implementations.  I don't see anything in this draft that encourages that.

In the RFC 5000 range, there are 7 Internet Standards, 13 Draft 
Standards and 537 Proposed Standards.  One of the arguments for this 
draft is that it reduces the number of IESG evaluations, and other 
review cycles, from three to two.  Basically, this draft is to adjust 
the environment so that the IESG can review everything.  It does not 
reduce the barrier of "intended proposed standards" to the RFC 2026 
level.  It does not offer any incentive to advance document along the 
Standards Track.

I unfortunately cannot support this draft.

Regards,
-sm