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