Re: The notion of "fast tracking" drafts

[Stephen Farrell <[e-mail]>]

Hiya,

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
things.)

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.

Cheers,
S.

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