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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf