Subject: [Fwd: I-D ACTION:draft-carpenter-newtrk-questions-00.txt]

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jun 2006 09:17:29 +0200

I invite the IETF community to read this draft and discuss the choices
it suggests, between now and the Montreal IETF.

     Brian

-------- Original Message --------
Subject: I-D ACTION:draft-carpenter-newtrk-questions-00.txt
Date: Fri, 09 Jun 2006 15:50:01 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Questions about the standards track
	Author(s)	: B. Carpenter
	Filename	: draft-carpenter-newtrk-questions-00.txt
	Pages		: 10
	Date		: 2006-6-9
	
    This document sets out some thoughts about three possible directions
    for further work on the evolution of the IETF standards track.  Its
    purpose is to stimulate community discussion leading to a choice
    between these three directions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-carpenter-newtrk-questions-00.txt

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

---

From: Douglas Otis <[email-masked]>
Date: Sat, 10 Jun 2006 06:27:01 -0700

> http://www.ietf.org/internet-drafts/draft-carpenter-newtrk-questions-00.txt

,---
|The three possible ways forward are:
|
| 1.  Agree that, apart from day to day efforts to improve efficiency,
|     the problems with the existing standards track are not serious
|     enough to justify the effort needed to make substantial changes.
|     Conclude that [RFC3774] exagerrated the problem and we only need
|     to make a relatively minor set of clarifications to BCP 9
|     [RFC2026].
| 2.  Focus on the issue of document relationships, or as the newtrk
|     charter currently says "the creation of a new series of short
|     IESG-approved IETF documents to describe and define IETF
|     technology standards."
| 3.  Focus on the three-stage standards track, or as the newtrk
|     charter currently says "agree on a revised IETF Standards
|     Track... to replace the standards track described in RFC 2026."
'---

Step 2 should be the first step taken to achieve a description of the
relationships in a simple, easy to maintain fashion.  The <name.serial>
provides clarity by offering a name rather than a number that is easier
to remember, and secondly a sequential number to allow a prediction of
the identifier for the next document when it finally emerges.  The
relationships, friendly name, and a clear sequence is missing within the
current structure. 

Once the existence of a relational document is instantiated, then 
Step 3 may seek to flatten the RFC documents by imposing a structure of
similar design to that of Step 2 indicating the level of the
<name.serial> documents and indirectly elevating or lowering the related
documents.  

Once Step 2 and then Step 3 are taken, the person isolated on some
remote island only afforded IETF documents should have little trouble
understanding what should be used to fulfill their goals.

-Doug

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 10 Jun 2006 10:04:54 -0400

My perception is that often in the IETF, protocol and process design  
works best that codifies and regularizes what is already being deployed.

The model that seems to be emerging is that we now have a lot of  
revisions of first-generation protocols, with the recent slew of LDAP  
announcements as one example. They are typically marked as  
'rfc1234bis'; the I-D database currently lists around 85 of these  
drafts as being active. The act of revising an earlier RFC presumably  
indicates that there is sufficient community interest in the  
technology and that this is maintenance based on implementation  
experience rather than a new protocol development.

By default, declaring that '*bis' efforts are the second level of  
maturity unless there is an objection during last call would be  
sufficient to differentiate them from first, largely pre- 
implementation specs. (Naturally, RFCs that were perfect on first try  
could get petitioned into the second maturity level, with a simple  
method of collecting support from N independent parties, convincing  
and AD  and based on a last call.)

I don't see why the grouping/labeling of RFCs can't proceed in  
parallel, but in a different group. This seems much more mechanical  
and tools-oriented and could probably be done more readily on an  
experimental basis. If whatever mechanism is chosen doesn't work out,  
we can phase it out or supplement it with something else. Such  
experimentation seems harder to do, without major confusion, for  
standards maturity levels.

---

From: Keith Moore <[email-masked]>
Date: Sun, 11 Jun 2006 09:04:44 -0400

> works best that codifies and regularizes what is already being deployed.

I disagree with this characterization.

If a protocol that is already being deployed is well-designed, IETF 
generally does a good job of documenting it and cleaning up the nits. 
However just because a protocol is already being deployed does not mean 
it is a well-designed protocol, and IETF generally has a difficult time 
fixing poorly-designed protocols that are already being deployed.  In my 
experience it is rare that a protocol that is already being deployed is 
well-designed - usually they are lacking in scalability or security or both.

IETF has more trouble designing protocols from scratch than if there is 
already a well-designed protocol that it can use as a starting point. 
But IETF can often design a better protocol than one that is already 
being deployed.  Not surprisingly, it takes longer to design a new 
protocol than to tweak a good protocol that already exists.  But it 
takes even longer to try to fix a poorly-designed protocol.

The general circumstances under which IETF has trouble designing new 
protocols are either or both of these:  1. When there are substantial 
conflicts between major industry players about strategic direction in 
that area.  2. When the working group set up to design this protocol has 
poorly-defined or inappropriately-defined scope.

---

From: Douglas Otis <[email-masked]>
Date: Sun, 11 Jun 2006 08:09:46 -0700

On Sun, 2006-06-11 at 09:04 -0400, Keith Moore wrote:
> that area.  2. When the working group set up to design this protocol
> has poorly-defined or inappropriately-defined scope.

While agreeing, this problem is not unique, nor does this directly
relate to the questions raised.  Stable document references for an
endeavour can focus dialog, either by the IETF or by others.  Being more
transparent may increase participation, where adding clarity appears to
be a goal of newtrk.

Part of the issue is the complexity created by the number of documents.
While smaller documents representing components of a larger system
should be a way to address the maintenance and scoping issues, a desire
to combat the extremely difficult use of disparate, non-sequential
document references has forced a consolidation detrimental to forward
progress. 

-Doug