Subject: [newtrk] GrUFToN

From: Tony Hansen <[email-masked]>
Date: Sun, 07 Aug 2005 19:33:20 -0400

Call this message the Grand Unified Field Theory of Newtrk (GrUFToN).

What follows are some thoughts on ISD's, SRD's, IR's, STD's, 1-track,
2-track and 3-track. In other words, the whole ball of wax. The
descriptions below are purposely kept at a fairly high level, so please
bear with me. If there's some detail missing from a description of your
favorite proposal, sorry.

At the Newtrk meeting on Friday, in particular the discussions of ISD's
and SRD's, I kept thinking about "why are we doing this?" What is it
that we're trying to gain over and above what we currently have? What is
it about what we currently have that's failed?

Axiom 1: The 3-track process was supposed to allow a protocol to become
"better cooked" as it was worked on and solidified.

Axiom 2: The STD series was supposed to describe what the current
standards are. It was supposed to describe in a succinct manner what it
is that comprises a standard.

Failure 1: The 3-track process was an experiment that has largely failed
in its desired goal. Very few protocols have progressed beyond the first
level, languishing in "proposed" status.

Failure 2: The STD series has largely failed for two reasons: 1) the
failure of 3-track has prevent protocols that are clearly outdated from
being upgraded to use the latest "real standard" version of the protocol
for the sole reason that "they aren't full standard yet". 2) The data
kept in the STD series is not rich enough to be a complete description
of the protocol.

Commentary:

Corollary 1: ISD's, SRD's and IR's have all been proposed because of the
failures of STD's. We have a couple of options here: 1) go forward with
one or more of ISD's, SRD's and IR's, or 2) fix STD's so that they can
do the job that they were intended to.

Corollary 2: To fix STD's would require: 1) fixing the 3-track process,
2) properly grading the various RFCs, 3) upgrading those references
within the STD descriptions, and 4) adding in the additional data that's
been deemed to be missing.

There have been two main proposals for fixing the 3-track process:
1-track and 2-track.

In the current 3-track, protocols become Proposed or Experimental when
their RFC is first published. Proposed status is for those protocols
that we need operational experience with before it can be moved further
on the track. Experimental status is for those protocols where we feel
there might be some detriment to their being implemented as described
and more experience is needed. After experience with the RFC has been
gained, and an inter-operation report is available for the protocol, a
Proposed RFC can be advanced to draft standard, and subsequently to Full
Standard. This can be accomplished along with a possible revision of the
RFC, or the RFC can be revised and recycled back through again at
proposed. Similarly, an Experimental RFC can be advanced to Proposed.

In 1-track, protocols either become Standard or Experimental when their
RFC is first published. Experimental is for those protocols that we
really don't know enough about yet, or feel that more experience is
needed. Experimental can also be used when there might be some detriment
to the protocol being implemented as described.

In 2-track, protocols become Proposed or Experimental when their RFC is
first published. Proposed status is for those protocols that we need
operational experience with before it can be "blessed". Experimental
status is also for those protocols that we really don't know enough
about yet, or feel that there might be some detriment to their being
implemented as described and more experience is needed. After experience
with the RFC has been gained, and an inter-operation report is available
for the protocol, an RFC of either kind can be advanced to full
standard, along with a possible revision of the RFC, or the RFC can be
revised and recycled back through again at proposed or experimental.

One of the comments on jabber at the newtrk session was that he really
wants to have a state for a protocol to sit in until interoperation can
be proved. At the time, I felt that this was really the basic difference
between 1-track and 2-track, until I later remembered the potential use
of Experimental in 1-track. Note the similarities between the use of
Experimental in 1-track for protocols that we need more experience with,
and Proposed in 2-track where we're really just saying that we need more
experience with it before we can bless it.

But, note the conflation in both 1-track and 2-track of two separate
uses of Experimental: insufficient experience with it and potential for
danger.

>From a 6 km level (~50,000 feet), 2-track uses Proposed where 1-track
would either make the protocol directly a standard or calls it Experimental.

The Grand Unified Field Theory of Newtrk (GrUFToN)

Step 1: Fix 3-track by picking either 2-track or 1-track. My slight
preference would be to use 1-track, but with more emphasis added for
using Experimental more liberally than would be used under the current
definition of Experimental.

Step 1a: possibly add a measure to Experimental that implies the
riskiness level.

Step 2: Fix up the current levels of Proposed and Draft standards in
rfc-index to be what they should be under the >>new guidelines<<.

Step 3: Add additional information to the STD list, including things
like pointers to errata, interoperability reports, and the like, that
have been proposed for ISD's and SRD's.

Sounds simple, but the devil (of course) is in the details. :-)

	Tony Hansen
	[email-masked]

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 8 Aug 2005 14:26:48 -0700

> do the job that they were intended to.

Offering a associative structure over the current flat RFC structure  
relates various RFCs with respect to specific endeavours.  This  
associative structure should not be viewed as overcoming problems  
created by a lack of standard categorizations.  An RFC may be useful  
in describing some aspect of an endeavour and, within a broader  
scope, how RFC are related to each other would be useful from I-D  
inception to RFC obsolescence.  Such a associative structure would be  
independent of a categorization indicating stature.

-Doug
.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 9 Aug 2005 22:36:53 -0400

On Sun August 7 2005 19:33, Tony Hansen wrote:

[rearranged somewhat]
> "better cooked" as it was worked on and solidified.

Yes, and to allow the specification to be improved, and to give increasing
levels of confidence w.r.t. stability and reliability to operations staff.
 
> level, languishing in "proposed" status.

So let's fix the problem(s).  One problem is that the IESG has been
disbanding WGs, leaving nobody to do the worker-bee advancement tasks.
Despite some encouraging noises, that problem doesn't appear to have been
fixed.   Another problem is that the IESG says it doesn;t have the ability
to do the IESG part of the advancement work.  It's not clear whether that
has changed with offloading of administrative tasks to the IASA, or not.

> for the sole reason that "they aren't full standard yet".

See std-index.  There are notes about works in progress.  Unfortunately,
handling of the situation is not consistent.

> 2) The data 

You mean errata?
 
> failures of STD's.

Not necessarily.  Incorporating errata and/or lists of related RFCs (some
of which might not be at full Standard, some might not even be Standards
Track) do not relate to any failure of STDs.

> We have a couple of options here: 1) go forward with 

These are not mutually exclusive.
 
> Corollary 2: To fix STD's would require: 1) fixing the 3-track process,

Or the implementation of the process.

> There have been two main proposals for fixing the 3-track process:

Those aren't fixes, they're fundamental changes.
 
> In the current 3-track, protocols become Proposed or Experimental

No. Experimental is not part of the Standards Track at all.

> when 
> and more experience is needed.

No, Experimental indicates that there is insufficient knowledge of the
problem to formulate a specification that meets the requirements for
Standards Track entry level (design choices resolved, no known technical
omissions, etc.).

> Step 1: Fix 3-track by picking either 2-track or 1-track.

Again, that's not a fix.  There is value to the three stages as specified
in BCP 9; we should fix the implementation so that it corresponds to the
process as designed (modulo tweaks to the review schedule, reviewing body
if IESG remains unable and/or unwilling, etc.).
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html