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
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
[ ... ]
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.
Ietf mailing list