I think that many of us already know the problem(s) we want to solve here
and have done since before NEWTRK was chartered.
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(_at_)harvard(_dot_)edu>
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
Website: http://hallambaker.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf