RJ Atkinson <rja@extremenetworks.com> writes: > On Thursday, Jan 23, 2003, at 17:54 America/Montreal, Bob Braden wrote: > > I interpret "IETF consensus" as meaning that at least a Last > > Call was conducted. To use any other interpretation seems to me to > > be dishonest. I guess I am agreeing with Kireeti. > [IAB hat off] > I agree with the above. IESG approval is not identical to IETF > consensus. If it were, the IETF community would not be giving such > vocal feedback about concerns with the IESG at the last 2 meetings > and on the ietf-problems mailing list, IMHO. As one of the authors of RFC 2434 "Guidelines for Writing an IANA Considerations Section in RFCs", I have long regretted defining the term "IETF Consensus" as it is in that document. 2434 says: > IETF Consensus - New values are assigned through the IETF > consensus process. Specifically, new assignments are made via > RFCs approved by the IESG. Typically, the IESG will seek > input on prospective assignments from appropriate persons > (e.g., a relevant Working Group if one exists). > > Examples: SMTP extensions [SMTP-EXT], BGP Subsequent Address > Family Identifiers [BGP4-EXT]. The intent of the above wording was to provide a way for documents to request that IANA only assign code points when there exists a document that gets published as an RFC. The wording above specifically does not say "Standards Track" RFC and was intented to include informational and experimental documents, whether from a WG or not. There is an alternate definition - "Standards Action" - that can be cited if IANA assignments are only to be made for Standards Track documents. I think intent of the above definition is fine. But naming the term "IETF Consensus" is obviously problematical and confusing, as there are many Info and Experimental RFCs for which there is nothing close to IETF consensus on, and no one would claim so. So, let's be clear that in the context of most of the discussion on this thread, folks seem to be applying their own definition of what "IETF Consensus" means when in fact the 2434 definition is what should be used, as is cited in the relevant IANA considerations section. I don't know what can be done a this point to change the terminology in 2434. It's been in use for some 4 years now... I'm reminded of another great choice of terms, the Best Current Practice, where we have had numerous threads about whether something was actually "best" or a "currently practice". There too, the actual definition as defined in the RFC is not quite the same as the what the literal term might suggest. Thomas