On Fri, 8 Sep 2006, John C Klensin wrote: > --On Thursday, 07 September, 2006 20:11 -0400 Sam Hartman wrote: > > OK. I read RFC 2026 as giving the IESG the latitude to make a > > judgment of the technical quality of a protocol (and the TS) > > when advancing along the standards track. I'd always assumed > > that the IESG should include factors like security in that > > determination--not just interoperability. Heck, I even > > assumed it was reasonable to have a higher bar for spec > > clarity at DS than PS. > > I think both of those (spec quality and factors like security) > are useful and important. But 2026 seems very clear on this > subject: > > > 4.1.2 Draft Standard > > > > A specification from which at least two independent and > > interoperable implementations from different code bases > > have been developed, and for which sufficient successful > > operational experience has been obtained, may be elevated > > to the "Draft Standard" level. For the purposes of this > > section, "interoperable" means to be functionally > > equivalent or interchangeable components of the system or > > process in which they are used. > > [...] Elevation to > > Draft Standard is a major advance in status, indicating a > > strong belief that the specification is mature and will be > > useful. [ ... ] > If the documents meet the published requirements for Draft, then > they should be published at Draft. > > The recent practice in the IESG appears to have been closer to > "if we don't like it or would not recommend it, it should not be > published at all, especially on the standards track no matter > how widely interoperable implementations are deployed". I can > find little support for that position in RFC 2026 or elsewhere. I think that Mr Hartman is right and that Mr Klensin is mistaken. As I read it, section 6 of RFC 2026 not only gives the IESG the latitude to make a judgment of the technical quality of a specification when advancing it along the standards track, but actually REQUIRES the IESG to do so: |6. THE INTERNET STANDARDS PROCESS | | The mechanics of the Internet Standards Process involve decisions of | the IESG concerning the elevation of a specification onto the | standards track or the movement of a standards-track specification | from one maturity level to another. Although a number of reasonably | objective criteria (described below and in section 4) are available | to guide the IESG in making a decision to move a specification onto, | along, or off the standards track, there is no algorithmic guarantee | of elevation to or progression along the standards track for any | specification. The experienced collective judgment of the IESG | concerning the technical quality of a specification proposed for | elevation to or advancement in the standards track is an essential | component of the decision-making process. ... |6.1.2 IESG Review and Approval | | The IESG shall determine whether or not a specification submitted to | it according to section 6.1.1 satisfies the applicable criteria for | the recommended action (see sections 4.1 and 4.2), and shall in | addition determine whether or not the technical quality and clarity | of the specification is consistent with that expected for the | maturity level to which the specification is recommended. //cmh _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf