ietf
[Top] [All Lists]

Re: The notion of "fast tracking" drafts

2012-12-16 14:09:06
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.

Keith