The core problem in my view is that the current IETF process is not and cannot be understood by non-participants because the theory is not and has never been followed.
As a result participants in the IETF have to explain to management funding their participation that they have to expect and accept results from IETF process that fall short of their expectations. The IETF presents itself as a standards body but has announced no current standards documents of any consequence other than port assignments, IPv6 and the URI document under the present process). The SNMPv2 documents do not count as they are obsolete as are the vast majority of STD status specifications.
I don't think it is a case of the incentives for advancement to standard being too small. I think that the underlying problem is that the three stage process has moved down one rung so that the practical requirements for PROPOSED are what were originally expected of DRAFT and the practical requirements for DRAFT far exceed those met by any of the official standards.
The only cases where a three step process is really necessary are cases where there is a need for experimental deployment prior to commencing standards track activity. We now use INFORMATIONAL and EXPERIMENTAL for these purposes.
So for the problems:
1, 2 and 3 are all problems
Causes
X) None of the above. The cause is that the IETF is totally uninterested in process. The three stage process suggests that the institution suffers from a fear of commitment.
Action
We should adopt Russ's proposal: Axe the DRAFT status and automatically promote all DRAFT status documents to STANDARD status. This can be done formally by changing the process or the IESG can just agree to a convention where every DRAFT standard is automatically promoted.
Incidentally, there is plenty of precedent for three step processes failing in this manner. The UK parliament nominally runs on a three stage process in which a bill is read and voted on three times. In practice the first reading of a bill has been pro-forma for the past few centuries, although the emergence of the committee stage means that there are still three substantive steps.
The Internet is now a large place with two billion users. Any institution that wants to be influential in shaping the future of the Internet has to be willing to commit to the proposals it is making. The current process represents an abdication of will and a failure of commitment. It should be corrected as a matter of urgency.
On Tue, Oct 26, 2010 at 10:10 AM, Scott O. Bradner <sob@xxxxxxxxxxx> wrote:
some more thoughts
first figure out what problem you are trying to solve
is the problem:
1/ that the 3 step standards track described in RFC 226 and its
predecessors does not describe what happens most of the time?
2/ (as Eric says) that it takes too long to get to the first stage
3/ too much of the Internet runs on Internet Drafts?
4/ ???
then analyze the problem to see what might be behind it
e.g., for problem #1
1/ no real incentive to put more work into advancing a document
2/ too much effort required to advance
3/ no actual benefit in advancing
4/ the current IESG review ensures that the first stage document is
rigorous enough that additional work on the technology is not needed
5/ requiring running code early in the game ensures that additional work
on the technology is not needed (see James's note)
6/ ???
e.g., for problem #2
1/ see #4 above
2/ see #5 above
3/ working with busy volunteers
e.g., problem #3
1/ see problem #2
if the problem is #1 then what to do about it:
1/ change the process to meet what you think is the normal case (i.e.
define away that there is a problem)
2/ change the process to one that is not currently followed and provide
no reason to think that the underlying reasons the current process is
not followed will magically change to make the new process any more of
an accurate description. (to me this is where Russ's ID sits)
3/ address some of the underlying reasons that the current description
is not followed
4/ live with the current description and worry about things that can
actually be fixed
etc.
Scott
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
--
Website: http://hallambaker.com/
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf