On 01/27/2011 01:10, John C Klensin wrote:
--On Thursday, January 27, 2011 09:41 +0200 Gonzalo Camarillo
<Gonzalo(_dot_)Camarillo(_at_)ericsson(_dot_)com> wrote:
Hi,
yes, I also agree the first one is the most important point
and has not been addressed so far. If we want a system that
works (and is used), it needs to include incentives to move
from one level to the next one. I have discussed this issue
with quite a few people. Some people claim that those
incentives exist in some areas (e.g., public institutions
preferring or requiring full standards in their RFQs) but, at
least in the RAI area, the incentives are not there in the
vast majority of cases.
Gonzalo,
Suppose we were to succeed in returning Proposed Standard to its
intended purpose -- more or less a good rough sketch of a
protocol, suitable for implementation and testing with the
support of mailing list discussions -- and being completely
clear about what that meant. I think the incentives to advance
to a more complete specification that represented community
consensus about its being implementable and probably useful
would then be clear.
That change clearly requires our being very clear internally
that Proposed Standard is a lightweight spec with a lightweight
approval process: if we can't get away from the mentality of
"you made me review this, so I have to find at least something
to comment on and ask for changes" in the various review teams
and the IESG, I think it is pretty much hopeless and that
draft-housley-two-maturity-levels will turn out to accomplish
exactly nothing other than to eliminate whatever further
specification refinement occurs in the few documents that now to
to Full Standard.
As long as we apply a very high bar to entry for Proposed
Standard and insist that specifications at that level are
perfectly good standards, there will rarely be an incentive to
move to the second level, no matter what we call it and whether
or not there is a third level.
I think the change, and the incentives, might be reinforced by
renaming "Proposed" to "Rough Preliminary Specification" or
something else without "Standard" in its name, but that is a
separate matter.
I've made this statement before, so I'll only touch on it briefly. The
world outside the IETF does not understand the difference between our
various flavors of "RFC" now. There is absolutely no hope of refining
that understanding EXternally when we can't even follow it consistently
INternally.
To some extent I think Russ' draft accurately reflects the status quo,
namely that drafts are the new proposed, and that proposed is the new
deployed. I'm hesitant to provide full-throated support for the draft
for a few reasons:
1. To the extent that anyone still cares that I once managed the IANA I
don't want to appear to be trying to influence the IETF's processes.
2. As an IETF participant I haven't fully thought through all the
ramifications of the draft.
3. As both an IETF participant and as a consumer of the standards we
create I still believe (as I've said previously) that what we need is
not an evolution, but a revolution; with different names for things that
more accurately reflect their status and intended use. However, it's
pretty obvious at this point that there is no broad support for this
position, so I won't waste more time on it.
hth,
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf