Re: The notion of "fast tracking" drafts

Stephen Farrell <> Sat, 15 December 2012 14:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BD6D21F85E6 for <>; Sat, 15 Dec 2012 06:59:06 -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 JzXaPYPvFpDw for <>; Sat, 15 Dec 2012 06:59:05 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6843221F85DF for <>; Sat, 15 Dec 2012 06:59:03 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 844E0BE39; Sat, 15 Dec 2012 14:58:36 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qSY9lAJaHRTX; Sat, 15 Dec 2012 14:58:35 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 56EC4BDC7; Sat, 15 Dec 2012 14:58:35 +0000 (GMT)
Message-ID: <>
Date: Sat, 15 Dec 2012 14:58:34 +0000
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: John C Klensin <>
Subject: Re: The notion of "fast tracking" drafts
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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: Sat, 15 Dec 2012 14:59:06 -0000


On 12/14/2012 11:09 PM, John C Klensin wrote:
> Hi.
> 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. 

That's a defensible opinion that I don't share. I'd say
s/most/many/ above would be better, but also think that we
ought try break this logjam where everything that touches
on process has to involve a gigantic debate with all the
usual suspects. (I don't foresee success in breaking that
logjam, but do think we ought not let it prevent us trying

I also think that since my proposal has a corner case where
a WG chair gets to put a draft on the IESG telechat agenda
that that ought only be done after some form of IETF LC.

> 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:

Luckily my draft says that: "All other criteria for Proposed
Standard or Experimental need to be met as usual." So I've no
idea how the text below is relevant.


> (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.
>    john