Subject: what is the problem? (was Re: draft-housley-two-maturity-levels)

From: [email-masked] (Scott O. Bradner)
Date: Tue, 26 Oct 2010 10:10:39 -0400 (EDT)

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 26 Oct 2010 13:19:36 -0400

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 <[email-masked]> wrote:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

-- 
Website: http://hallambaker.com/

---

From: Fred Baker <[email-masked]>
Date: Tue, 26 Oct 2010 12:04:34 -0700

On Oct 26, 2010, at 10:19 AM, Phillip Hallam-Baker wrote:

> 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.
>      [snip]
> 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.

I agree with much of that, but suspect I might have worded it differently. Bottom line, we put a lot of effort into making documents at the "Proposed" level "right", and at that point the people working on it have neither incentive nor energy left to do anything more with it unless it is shown to have a bug. There are people that will only buy a product if it has been interoperability-tested with another vendor's product; they generally do interoperability testing themselves.

So yes, move Draft Standards to Standard, and eliminate Draft Standard as a status.

I might also make two other changes.

There is a rule in 2026 that says that every feature of the protocol has to be shown interoperable, and it strongly prefers complete implementations - and wants an updated version with the unused bits removed. It turns out that this becomes hard to accomplish for various reasons, and is one of the issues with taking protocols to Draft (er) Standard. It could also be described as the purpose of a PICS Pro Forma; other standards bodies write documents that say "when you are using protocol X for purpose Y, you need to implement features Z1, Z2, and Z3". PICS make me crazy, but they may be an acceptable alternative to the current rule.

And how do you do interoperability testing? I suspect that if N vendors care and are in a position to say that they have several common customers that are using both of their equipment interchangeably in the same network, that constitutes prima facie evidence of interoperability. We would need to clearly specify what an acceptable statement of interoperability is, but we might consider that approach.

---

From: Eric Burger <[email-masked]>
Date: Wed, 27 Oct 2010 21:15:27 -0400

+1