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(_at_)ietf(_dot_)org mailing lists by 2011-06-02. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)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.
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.
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. 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.
I certainly agree with addressing the above concerns. 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.
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).
2(b) - I like this change and support it.
2.1(a) - I wholeheartedly agree with this change (or, more to the point,
reversion to the documented way of doing things). However:
- This document gives no mechanism to facilitate this change. I would
like to hear how this will be accomplished.
- 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.
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.
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.
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.
4(a) - I have no objection to this change as it applies to Draft Standards.
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.
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.
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.
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.
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.
2. Make the changes in (B).
3. Make the changes in (C).
With regard to the STD numbers, I think that it would be reasonable to:
4. Assign STD numbers to everything at Draft Standard.
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 am happy to write an I-D if there is support for this.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf