Hi. A number of recent discussions, specifically including the Last Calls on DKIM and standardizing RRTYPEs and even to some extent the meeting location ones, have started me thinking that perhaps we need to review what business the IETF is actually in and to be sure that we actually still agree about it. The note that follows is an attempt to take the isolated parts (and symptoms) of that discussion up a level and discuss it as a general issue. The key issues go to the very nature of standardization. While there are many variations on each, there are two fundamentally different models for what standards are about. Each is legitimate in its own way and each has its advocates, but they are different. One is a focus on quality: an engineering consensus on the best technical solution given physics or consensus goals and boundary conditions. The other is sometimes called "consensus of industry practice" in which a standard reflects what is already deployed, possibly picking among different implemented options in a few cases but mostly requiring that a common model appears before standards are issued. Two variations on the second theme were extremely common in the earlier days of computer and telecommunciations standardization but are less popular today (at least in theory) due to IPR and antitrust concerns. Both start with a single vendor (or closed consortium) implementation. That implementation might then be offered for standardization (sometimes with a "no major changes" restriction) and adopted more generally or endorsed by traditional SDOs. Or that single implementation might be reverse-engineered by others and then the result treated as common industry practice. Despite the occasional claim that a strange (to me) idea called "anticipatory standardization" is a variation on the second model, that combination makes standards in the absence of, or prior to, implementation and deployment an impossible contradiction. It is basically incompatible with innovation of any type. The IETF has traditionally chosen the first model and a great deal of our thinking and public rhetoric are based on it. Even when we have adopted proposals, sometimes implemented ones, from elsewhere, we have insisted on change control and usually taken that seriously. One could claim that an adaptation of the second model would make the Internet more uniform, but a consensus of existing practice cannot aspire to "working better" except in the narrow sense of substitutability of conforming products. It is interesting that the multi-stage model of RFC 2026 (particularly the original "Proposed Standard" definition), the IEEE's "Trial-Use" standards (the current Section 5.7 of their Standards Board Operations Manual, http://standards.ieee.org/develop/policies/opman/sect5.html#5.7, makes instructive reading), and ISO "Technical Specification" all try to combine the two models by allowing a preliminary specification --one that is intended for trial implementation but not deployment-- to be designed on an engineering basis and then standardized only when implementations exist and can be compared (our original "Draft Standard"). In theory, only when both an industry common practice and consensus about value emerges does true standardization (including our original definition for "Internet Standard") move forward. We know how well that has worked for us in practice. While there have been exceptions, I don't believe it has worked much better for other SDOs. If we are not going to move significantly in the direction of "consensus of industry practice", then it seems to me that we need to be careful about the arguments that are made (or at least those that are considered legitimate) in support of advancement into or on the standards track. For example, if we agree on a relaxed registration procedure for some protocol parameters, it is not reasonable to later turn around and ask that that those parameters be standardized, unchanged, because they are already registered (and maybe deployed). For standardization, the IETF generally needs not only change control but an opportunity to comment on and affect the actual design and specification of whatever is being standardized. Similarly, we sometimes hear it argued that we should accept a specification for Proposed Standard unchanged because it has been extensively developed and reviewed elsewhere. That may be reasonable in some cases although I'd hope we wouldn't make it a common practice. But, if a specification adopted for Proposed Standard on that basis is then proposed for advancement to Internet Standard, I think the review should be comprehensive --perhaps even more comprehensive than the usual such review-- because the Internet Standard is unambiguously an IETF product and recommendation not that of the other body. If we allow a specification to advance to Proposed Standard without an open and critical review because it was developed and reviewed comprehensively by outside expert organizations and then allow the Last Call review for Internet Standard to be constrained by existing deployment, we would have gone into the rubber stamping business that we regularly say is incompatible with our standardization model. That doesn't mean, of course, that changes during review for Internet Standard are likely to be a good idea. Those who propose changes to the spec, and especially to the protocol, should have to convince the community that those changes are important enough to overcome the costs, including those of incompatibility with deployed versions. But I don't think we can reasonably exclude them from raising the issues and making those arguments. thanks, john