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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/7/11 11:00 PM, Peter Saint-Andre wrote:
Pete, thanks for your helpful summary. Comments inline, now that I've
had a chance to review all of the Last Call feedback.

A conversation I'm happy to have. Comments inline. We are still men without hats.

On 5/30/11 5:20 PM, Pete Resnick wrote:
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.

So you think that this is *not* a motivation for the changes and is *not* something we need to change? Interesting.

    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.

We agree on that point.

I certainly agree with addressing the above concerns.
I'm not yet convinced that these are real problems.

This we're likely to agree to disagree on.

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.

Strongly agreed on the latter point: I'm not at all convinced that we understand what results we're trying to achieve and what behaviors we're trying to encourage by modifying the standards track. And given that, whatever change we end up making, I have to say that this document can't be it, because it does not explain what we're trying to achieve.

Skipping down to "going back to 2026 requirements for proposed":

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.

All of the above may be true. I personally think that the best thing that could happen in some sense is to "decrease the quality" of Proposed Standard RFCs, but that's certainly a controversial view. And I think it's worthy of an independent discussion. So, at the very least, we either need to agree on this as a topic for this document or remove it.

As to the change to 2 levels:

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

"Simplify" (even three times) is not a good motivation for this change. If "simplify, simplify, simplify" means "cut off your right arm, cut off your left arm, and cut off your left leg", I will certainly be a simpler being for the act, but none the better; I would argue a bit worse for my purposes. "Simplify" is not, in and of itself, a good justification. So I want to hear more. Certainly more than is in the current document.

On the downrefs:

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

Agreed.

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.

I'll try to argue separately later for why this is good. But I suspect that we're going to be deadlocked at least with regard to this document.

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.

Excellent. This we probably can get agreement on for this document.

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.

I don't mind, but I might want to wordsmith to still allow the IESG the possibility to classify something as Historic with simply a Last Call.

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.

Again, I'll wait to hear the justification. But to say I am very skeptical would be to understate.

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.

So, I think I hear us agreeing that it would be fine to make the changes to requirements for Draft Standard, but not agreeing to much of anything else. You're willing to write an I-D explaining why it's a good idea to go to two-tracks and I'm willing to write an I-D explaining why it's a good idea to go back to 2026 requirements for Proposed Standard, and we both seem to agree that the present I-D does neither of these things. Given that, I think it makes sense to remove the two-track business and the Prosposed Standard business from this document and simply make it about simplifying the requirements for Draft Standard.

I think we will wait for the shepherding AD to give us direction. :-)

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]