The notion of "fast tracking" drafts (was: Re: Running code, take 2)

John C Klensin <> Fri, 14 December 2012 23:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D73621F8AB9 for <>; Fri, 14 Dec 2012 15:09:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bq2hzDmviO-7 for <>; Fri, 14 Dec 2012 15:09:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 85F1421F8AAC for <>; Fri, 14 Dec 2012 15:09:57 -0800 (PST)
Received: from [] ( by with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <>) id 1TjeOC-0000kT-Fq for; Fri, 14 Dec 2012 18:09:56 -0500
Date: Fri, 14 Dec 2012 18:09:51 -0500
From: John C Klensin <>
Subject: The notion of "fast tracking" drafts (was: Re: Running code, take 2)
Message-ID: <>
In-Reply-To: <>
References: <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Dec 2012 23:09:58 -0000


I've been trying to say out of this because I think most of the
suggestions are better carried out by AD-encouraged experiments
and reports to the rest of us on effectiveness rather than by
long discussions in the community about details and the costs of
an unnecessary consensus process. 

However, since I gather we are pushing (or being pushed) down
this path, let me suggest that approval of an IETF spec,
especially a standards-track one, has (or should have) elements
of all of the following:

(1) A conviction that the idea is implementable and that the
ideas expressed are consistent with implementation (and,
ideally, operational realities.

(2) Specification of sufficient quality to make
independently-developed interoperable implementations by people
who were not part of the WG or development process possible and
specifically that there are no ambiguities that could adversely
affect interoperable implementations.  This includes, but is not
limited to, editorial quality in terms of good technical
English, but does not include "good idea" criteria (see (4)).

(3) "No known technical defects" in the spec (the RFC 2026
requirement).  Note that, while an implementation might turn up
technical defects that might otherwise be unknown, it might
easily not turn up ones that could be identified in other ways.
It should imply a fairly comprehensive review that would have a
high likelihood of turning up any technical defects that are
present, but we all know that sometimes doesn't happen.

(4) Some level of IETF consensus that publishing the
specification has value for the community.  This might or might
not include a community belief that the document specifies a
good idea that should be implemented and deployed (the latter is
why we have Applicability Statements).

While I hope the above is obvious, the four categories are
nearly orthogonal.   One can have a good specification and a
worthwhile idea without an implementation, an implementation of
a bad idea and a lousy specification, and so on.   I believe...

(i) It is a bad idea, and could be a real disservice to the
community, to say that meeting a high standard on any one of
those dimensions should allow some of the others to be dealt
with in a perfunctory fashion.  That is exactly what a "fast
track" idea seems to be about and much of the debate seem to be
about how high a standard is relevant.

(ii) If it were really acceptable to decide that an
implementation (i.e., a limited demonstration of the first
criterion) justifies a "fast track", then demonstrations of the
others should to.  For example, if a WG could demonstrate that
the specification had been carefully and professionally
technically edited, perhaps that should justify "fast track"
treatment.  If there is already wide and successful deployment
of what is supposedly the specification, leaving aside the
question of whether those deployments and the specification
actually match, perhaps that should justify "fast track"
treatment.  If the review of the specification in a WG had been
particularly intense, including careful looks by many diverse
parties, perhaps that should justify "fast track" treatment.

I'm not certain what makes having an implementation more special
than any of these other categories and, to the extent to which
"fast track" means "less review" or a "higher bar to comments",
the idea makes me really, really, nervous, especially if the
requirement is not for a production-quality implementation that
has been tested both for interoperability and through deployment
to users.