Pete, thanks for your helpful summary. Comments inline, now that I've had a chance to review all of the Last Call feedback.
On 5/30/11 5:20 PM, Pete Resnick wrote:
> On 5/5/11 11:13 AM, 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-06.txt> as a BCP
>>
>> 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
>> ietf@ietf.org mailing lists by 2011-06-02. Exceptionally, comments may be
>> sent to i...@ietf.org instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>
>
> Man without hat: Speaking as an individual contributor, not an AD.
Ditto.
> Summary: I am in favor of most of the changes in this document. The
> primary change I am opposed to is the one identified in the title and
> therefore object the adoption of this document as a BCP. However, I
> believe there is a single (though significant) change that would make
> the document acceptable to me.
My summary: I am in favor of many of the changes in this document,
although what you and I like and dislike does not overlap much. :|
> Details:
>
> The document says in section 1 that the motivation for the changes is:
>
> In the current environment, many documents are published as Proposed
> Standard and never advance to a higher maturity level.
I think that's fine and usually appropriate.
> In addition,
> IETF working groups and IESG members provide much more scrutiny than
> is called for by RFC 2026 [1] prior to publication as Proposed
> Standard.
Although this is adduced as a motivation, by my reading it doesn't
actually motivate the proposals in this document.
> I certainly agree with addressing the above concerns.
I'm not yet convinced that these are real problems.
> Section 2 lists
> one additional motivation for the changes:
>
> The benefit associated with a third maturity level has proven
> insufficient to justify the effort associated with document
> progression.
>
> I'll address this below.
I think the third maturity level is unnecessary, but I'm not yet
convinced that we understand what results we're trying to achieve and
what behaviors we're trying to encourage by modifying the standards track.
> Here is a summary of the process changes that occur in the document, by
> section:
>
> Section 2
> (a) Generally, go to two maturity levels, Proposed Standard and Internet
> Standard
> (b) Only review the changes, not the entire document, when recycled at
> Proposed
>
> Section 2.1
> (a) Go back to 2026 level of (i.e., less) scrutiny for Proposed Standard
>
> Section 2.2
> (a) Specifically, merge Draft Standard into Internet Standard
> (b) Combine criteria from Draft Standard and Standard
> (i) Significant number of implementations with successful
> operational experience
> (ii) No unresolved errata causing interoperational problems
> (iii) No unused features, except allow unused features that do not
> greatly increase implementation complexity
> (iv) Independent patent/licensing for implementations
> (c) Remove overt requirement for documentation of interoperability testing
>
> Section 3
> (a) No more annual review of Proposed Standards for movement to Historic
>
> Section 4
> (a) Allow normative references from Internet Standards to Proposed
> Standards
>
> (Editorial note: Please move 2(b) into 2.1. That change is a change to
> the handling of Proposed Standards and therefore belongs in 2.1. That
> makes the rest of Section 2 just introductory text and not making a
> specific procedural change.)
>
> My analysis by section:
>
> 2(a) - I am opposed to this change and will discuss it below in section
> 2.2(a).
I am in favor of this change.
> 2(b) - I like this change and support it.
I'm mostly agnostic about this, although I note that sometimes things
change (e.g., new security threats) and it makes sense to revisit parts
of a document even if they haven't been changed (or, in some instances,
especially if they haven't been changed).
> 2.1(a) - I wholeheartedly agree with this change (or, more to the point,
> reversion to the documented way of doing things).
I disagree with this change. It sounds attractive ("let's return to the
golden age") but I agree with those who posted during the Last Call that
it is a significant change from current practice. You could argue that
current practice is not the best practice, but I don't see how a
reversion to RFC 2026 principles here is truly best current practice. In
addition, IMHO we have not thought enough about the consequences of a
lower bar for Proposed Standard (e.g., our "customers" think that an RFC
is an RFC, and if we suddenly start publishing PS specs of lesser
quality then we might be diluting our brand).
> However:
> - This document gives no mechanism to facilitate this change. I would
> like to hear how this will be accomplished.
I have my doubts that this is even achievable now, at least absent
serious changes to IETF culture and individual expectations among spec
authors, WG chairs, Area Directors, review teams, and everyone else.
> - This change, along with 2(b) has the potential to greatly increase the
> number of RFCs published. The document does not discuss the impact of that.
And, more to the point I think, to greatly decrease the quality of RFCs
published. Perhaps that's OK, but we need pretty strong consensus that
it's the right thing to do, and I haven't seen that consensus in the
Last Call discussion.
> 2.2(a) - I see no motivation for this change other than the one sentence
> in section 2. This change does not address the difficulty of going from
> Proposed to Draft, and it doesn't address the heightened scrutiny for
> going to Proposed. Therefore, if the only reason for changing from three
> levels to two is that getting through the three levels is too hard, and
> most of the procedural changes in this document are to make it easier to
> get through the first two levels, I see no justification for removing
> the third (and in 2026, easiest to get through) level. It does not solve
> any identified problem.
I'm in favor of this change. I don't think the document describes the
motivation very well, but this one makes sense to me. As Thoreau said,
"simplify, simplify, simplify" (although why did he need to say it three
times?).
> 2.2(b)(i) - This is the current requirement for Internet Standard. I'm
> fine with that remaining, but object to the removal of any notion of
> interoperability. If this were changed to "A significant number of
> interoperable implementations...", I would have no objection.
>
> 2.2(b)(ii) - I have no objection to this new requirement, but have no
> strong feeling about it.
>
> 2.2(b)(iii) - I would prefer that this be amended to "All unused 'MUST'
> requirements will be changed to 'SHOULD' requirements." If deployment is
> interoperable and a feature is unused, it means that the feature was not
> actually REQUIRED for interoperability. I object to this as it stands.
>
> 2.2(b)(iv) - This is the current requirement for Draft Standard. I'm
> fine with that remaining.
>
> 2.2(c) - If this is actually "subsumed" by 2.2(b)(i) (see my change
> above), then I am fine with this change.
Agreed.
> 3(a) - I have no objection to this change, but hope that the review can
> be reinstated once the rest of the process settles down.
IMHO this makes a lot of work for various folks with no clear benefit.
Strike it.
> 4(a) - I have no objection to this change as it applies to Draft Standards.
Right. Although I think various Last Call commenters are right that this
needs to be handled on a case-by-case basis (especially if we start
publishing lower-quality or less-mature PS documents).
> So, to summarize, here is how I break down the changes this document
> proposes and my position on them:
>
> A. For Proposed Standard:
> - Go back to 2026 review levels for approval
> - Only review changes, not the entire document, for recycling at Proposed.
>
> I am in favor of these changes.
I am not in favor of these changes.
> B. For Draft Standard:
> - Remove requirement for formal documentation of interoperability tests.
> - Require only a significant number of [interoperable] implementations
> with successful operational experience.
> - Allow no unresolved interoperability errata.
> - Allow for unused [SHOULD level] requirements if they don't increase
> implementation complexity.
> - Allow for downrefs to Proposed Standard documents.
>
> I am in favor of these changes with the square bracketed insertions I
> have made, except for the last one which I can live with.
I am in favor of these changes.
> C. Eliminate annual review of Proposed Standards.
>
> I would prefer not to make this change, but since it does not reflect
> reality, I am OK with it.
I would prefer to make this change.
> D. For Internet Standards:
> - Combine Draft Standards into this category.
>
> This is the only change that I strongly object to since I don't see any
> problem that is solved by doing this and therefore oppose adoption of
> the present document as BCP.
The is the only change I'm strongly in favor of.
> So, here is my a proposed alternative:
>
> 1. Make the changes in (A). We still need to say how to make that
> happen, and how to deal with the increased number of RFCs.
I say: don't make these changes.
> 2. Make the changes in (B).
Agreed.
> 3. Make the changes in (C).
Agreed.
> With regard to the STD numbers, I think that it would be reasonable to:
>
> 4. Assign STD numbers to everything at Draft Standard.
I agree with John Klensin and others that this text can be safely
removed. It's off-topic at this point in the conversation anyway.
> And if people really think that the current *titles* of the levels are a
> problem:
>
> 5. Change the name of "Internet Standard" to "Mature Standard" (or
> "Deployed Standard" or whatever label we like).
>
> 6. Change the name of "Draft Standard" to "Internet Standard".
I disagree -- there's no reason to change the branding.
> I am happy to write an I-D if there is support for this.
And I'm happy to write an I-D that makes a stronger case for two-track.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
