Subject: RE: [newtrk] an alternate standards promotion process

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 23 Feb 2006 18:34:08 -0800

I think you need to start taking a different approach.

Present the IESG with a list of the 100 or so DRAFT standards that have
been languishing for years. Discuss advancing one spec to STD. Measure
the amount of time taken, multiply by the number of remaining standards.
Ask IESG if this is really something they think is a valuable use of
their time. 

If they say yes, take the next standard. If the process is reduced to a
formality there is no need for NEWTRK. It is also likely that resistance
to change will evaporate.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Scott Bradner
> Sent: Thursday, February 23, 2006 7:21 PM
> To: [email-masked]
> Subject: [newtrk] an alternate standards promotion process
> 
> 
> the following ID is (imo) in charter for newtrk so I agreed 
> with John that it should be published as a newtrk ID to 
> stimulate discussion
> 
> this publication should not be taken to mean that newtrk has 
> reached consensus on this path (that should be clear since 
> there has yet to be any discussion on it but I thought I 
> would say that just so that noone would misunderstand)
> 
> -----
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the New IETF Standards Track 
> Discussion Working Group of the IETF.
> 
> 	Title		: Cleaning the Attic II: Promoting
> Marketplace-approved Standards
> 
> 	Author(s)	: J. Klensin, S. Dawkins
> 	Filename	: draft-ietf-newtrk-promotion-00.txt
> 	Pages		: 11
> 	Date		: 2006-2-23
> 	
> Historically, Internet Standards have been characterized by 
> three primary criteria: the specifications are stable, 
> implementations of them have been demonstrated to be 
> interoperable, and they have achieved sufficient deployment 
> to be considered useful.  The IETF has developed specific 
> rules for determining whether those criteria have been met, 
> but the rules and their implementation have sometimes not 
> adequately reflected those underlying criteria.  The result 
> has been that the application of the rules has not resulted 
> in STDs for all protocols that meet the underlying criteria.  
> This document proposes a process experiment to reclassify 
> standards-track documents whose interoperability and utility 
> have been demonstrated by the fact of deployment and use in 
> products being used by Internet users.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-newtrk-promotion-00.txt
> 
> ...
> .
> newtrk resources:_____________________________________________________
> web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
> mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html
> 
> 

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

---

From: John C Klensin <[email-masked]>
Date: Fri, 24 Feb 2006 00:50:04 -0500

--On Thursday, 23 February, 2006 18:34 -0800 "Hallam-Baker,
Phillip" <[email-masked]> wrote:

> Present the IESG with a list of the 100 or so DRAFT standards
> that have been languishing for years. Discuss advancing one
> spec to STD. Measure the amount of time taken, multiply by the
> number of remaining standards. Ask IESG if this is really
> something they think is a valuable use of their time. 
> 
> If they say yes, take the next standard. If the process is
> reduced to a formality there is no need for NEWTRK. It is also
> likely that resistance to change will evaporate.

I think this is a plausible alternative.  I think I prefer what
I suggested for a few reasons, but YMMD:

(1) I'm actually more concerned about getting things out of
Proposed than I am about getting those which are at Draft
advanced.  Had I been concerned primarily or exclusively about
Draft, I would have proposed an even faster approach, e.g., to
make a list like the "decruft" list and, for each document that
had been in Draft for some time, ask only two questions: (i) has
this been significantly deployed for a while? and (ii) have
_serious_ problems appeared during that time?  If the answer to
the first were "yes", and the second "no", then the document
advances.  No enabling documents, re-analysis, etc.    I would
actually consider such a proposal complementary to the one that
I posted were it not for the observation that a debate about the
choices between the two would probably, based on NEWTRK
experience, kill both of them.  But, if you believe it is the
right thing to do, I think you have until 0900 ET Monday to get
it written up.

(2) I disagree with your hypothesis that, if one specification
can be advanced, resistance to change would evaporate (I know
that isn't quite what you said -- see below).  Were I on the
IESG, I would believe that a single document can be advanced at
any time if  the requirements were met -- it would just be a
matter of normal processing of one document.  However, faced
with an "opportunity" to get a hundred of so within a short time
and the further opportunity to evaluate them according to the
current procedures and requirements (including the need to
evaluate 15-year-old specifications against current criteria --
the earliest Draft Standard I could find on a quick glance that
had not been significantly updated or obsoleted is RFC 1184 from
Oct 1990), I think I'd get the chills.

(3) The decision about the relative priority of advancing
current specs versus working on new ones should ultimately be
made by the community, not the IESG.   Thus far, the community
has clearly voted: the IESG has processed every single
advance-in-grade proposal it has received, they just have
received very few (relative to possibilities) of them.  So,
ignoring the "automatic review" provisions of RFC 2026 and its
predecessors, the reason why we don't have documents advancing
is either (i) no one cares enough to do the work or (ii) the
work is too burdensome since the level of effort keeps getting
higher.  One way to look at the posted proposal is that it is an
attempt to tease those alternative explanations apart to see
what would happen if the burden were reduced of updating
documentation and potentially updating protocols because
community or IETF expectations have increased.  I can't tell if
your proposal would make the same test because you haven't
constructed a proposal yet.

But, as Scott said in his note, this was posted to stimulate
discussion.  From my point of view, part of that discussion is
to determine whether there is actually work to be done to revise
or clean up the standard track and whether such work is feasible
or if, in practice, we are good at complaining but incapable of
actually agreeing on anything ... in the community at large or
with the IESG>  If the draft and subsequent discussion causes a
better idea to surface, that would be great.  If the community
is more concerned about advancing Draft Standards than with
clearing the backlog of Proposed Standards that have clearly
been implemented and deployed, I hope we see a concrete
proposal, and soon.  And, if the community doesn't care enough
to reach sufficient consensus on any of these proposals to
produce action, well, I think that answers some broader
questions with "we deserve the standards process that we have,
warts, ignored rules, and all".

    best,
      john

.