--On Tuesday, 28 June, 2005 09:37 +0200 Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx> wrote: >... > In fact, a simple-minded grep for "iesg approval" shows that > RFC 2048, the first MIME registration procedures, was the > first to use it, 2 years earlier; that only shows where I > cribbed the term from, I guess. > > Quote from 2048: > >> 2.3.2. IESG Approval >> >> Media types registered in the IETF tree must be submitted >> to the IESG for approval. Yep. Ned, Jon, and I did it. I can't remember precisely who the original guilty party was for either the term or the concept. The multiple-tree idea in this space was, I think, originally mine but the rules for getting into the trees was, if I recall, very much group discussion. We did it very deliberately, and were deliberately vague about the procedure IESG was to use. And it was not about document completeness review, it was about content-based approval of whether or not the IESG liked that content. We didn't feel a need to comment on the adequacy of documentation bit because we could not believe IESG would sign off on something in the IETF tree that was incompetently described and IANA was still making decisions that would have produced pushback on such a thing if IESG somehow let an obviously-weak definition slip through. _However_, there are two rather special properties of the concept of IESG review as it appeared in 2048: (1) If the IESG said "no", it wasn't "no, you can't register this thing" or "no, you can't use it". Instead (assuming competence of documentation), it was "nope, not IETF tree, register it in one of the other trees). Note that registration in the some of the other trees was (and is) extremely permissive: in 2048, and as this has evolved in its predecessors, the review required for the others is, at most, "someone besides the applicant needs to look at this, and you need to pay attention to what they say before registering. So, what the IESG review was determining was not "register or not" but whether registration could occur in a particular tree or category. The distinction between "determine category" and "determine registration" is discussed in more detail in section 4 of draft-klensin-iana-reg-policy-00.txt -- I recommend you have a look at it when it is posted and see what you think of it. (2) We introduced the term to include _all_ types of IESG review and approval, including the entire range from "IESG looks at it, nods approvingly, and tells IANA to go ahead" to "standards approval". The reason for the flexibility was primarily so the IESG could decide that something was far enough along in development or us in the IETF community to belong there and, in particular, that a type specified in an I-D that had received wide discussion could be approved long before the I-D itself made it through the process and to the RFC Editor. And the notion was clearly one of the IESG determining, albeit informally and without requiring a formal Last Call, the general direction of IETF consensus on the matter. At least in retrospect, we were relaxed about that because the media type name space is not scarce and, because there were other trees, inappropriately registering something in the IETF tree or not doing so would not be of earthshaking consequence. Now -- personal opinion -- from that perspective we should probably have been a bit more explicit about what criteria the IESG was expected to use for that review. Although it does it in extremely general terms rather than in the context of one registry, draft-klensin-iana-reg-policy-00.txt attempts to remedy that omission. More important, in retrospect, when you picked the term out of context and defined it in 2434 without criteria and in the absence of alternate registration trees, that might not have been A Good Thing. But, probably, you assumed that any specification that invoked that definition from 2434 would define criteria and procedures to the degree needed by the registry involved. From that perspective, the disconnect may have occurred with 2780, or we may have just drifted our way into a problem in which, IMO, the "signoff on definition quality" which applies generally to registrations and becomes more important the more important the registration is got confused with "approval of content" which is appropriate only for choices among multiple-tree situations. Again, draft-klensin-iana-reg-policy-00.txt attempts to focus this discussion by elaborating on the model that underlies my remarks and, I believe, those of several others. If the community agrees with its analysis and recommendations, perhaps we can dig ourselves out of this series of disconnects. >... > In keeping with the general tendency to let things be handled > by others when they can be handled by others, I think changing > requirements from "IESG approval" to "Expert Review" is a Fine > Thing (and think that the IESG should have the right to do > that on its own, even when documents say "IESG approval"). > But I like the text describing the "IESG approval" part in > 2434 just the way it is. To preview what would otherwise be a discussion on the new I-D, here we disagree, for two reasons: (i) For some registrations, especially those for which there are no alternate registration categories and where unidentified use of mechanisms might lead to operational problems, "IESG approval" may be appropriate, but IESG non-approval must never mean "no, you can't register it". (ii) For situations in which "IESG review" is actually intended to convey a lightweight form of IETF approval, substitution of the judgment of an individual for an IESG determination of IETF consensus (however lightweight that determination process) is completely inappropriate. Expert Review is a mechanism for determining adequacy of definition and for managing a feedback process to submitters, it is not as substitute for community consensus (however rough) about quality or desirability, and must not be permitted to become a substitute for such consensus. Four-line summary: We can reasonably delegate a determination of definitional adequacy to an individual, but decisions about "good" or "bad", or recommendations to use or not use something, require community consensus. john > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf