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