Re: The notion of "fast tracking" drafts

Keith Moore <> Sun, 16 December 2012 20:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7981621F8972 for <>; Sun, 16 Dec 2012 12:08:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lVHkdi7G2kF1 for <>; Sun, 16 Dec 2012 12:08:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 914C221F8970 for <>; Sun, 16 Dec 2012 12:08:43 -0800 (PST)
Received: from compute4.internal (compute4.nyi.mail.srv.osa []) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D5E77205F5 for <>; Sun, 16 Dec 2012 15:08:42 -0500 (EST)
Received: from frontend1.nyi.mail.srv.osa ([]) by compute4.internal (MEProxy); Sun, 16 Dec 2012 15:08:42 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=pGDOccyI6KJ3Cf/tjKZHOG rv/Xw=; b=O60XpP6i72aOHfyf8a00jntEqiCvovsFNXq/7n7rUhsHjvYPmghcaY ea9HzuUTyYwpcy7mvhgP3XV92AcdsoSOiWNAnprHsNiFMeiH4OJpyzkhLjZD6wQ4 7KaVAIWRQiXksZvKfMNEjItvxOpbe78xNCTze8RRjgRfObPtl1pcs=
X-Sasl-enc: LxhS36w2M0czlPxFfBnJEBY9WBwJYAbOlToKYLa6YBA9 1355688522
Received: from [] (unknown []) by (Postfix) with ESMTPA id 2113A8E0636; Sun, 16 Dec 2012 15:08:42 -0500 (EST)
Message-ID: <>
Date: Sun, 16 Dec 2012 15:08:38 -0500
From: Keith Moore <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
Subject: Re: The notion of "fast tracking" drafts
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
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: Sun, 16 Dec 2012 20:08:44 -0000

On 12/14/2012 06:09 PM, John C Klensin wrote:
> 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).
to this I'd add

(5) Widespread, examined belief that the specification has minimal 
impact on the Internet architecture.

I keep seeing IETF standardize protocols that seem likely to have 
seriously damaging architectural impact without much, if any, 
examination of that impact (the PCP and MIF work come most immediately 
to mind, but I could cite several others given a few minutes to think 
about it).  I'd hate to see a fast-tracking procedure used as a way to 
further circumvent such examination.