>>>>> "John" == John C Klensin <[EMAIL PROTECTED]> writes:
John> Actually, that topic opens up one of the fundamental issues John> with our standards process ... one where better definition John> and clear community consensus is, IMO, needed. Measured by John> our documented criteria, 2195 exists in multiple independent John> implementations, has been widely deployed, and is considered John> useful by many of those who are using it. Current thinking John> in the security area is that it isn't much better than the John> use of clear-text passwords, but our formal definitions of John> the requirements for Draft Standard don't require that we John> recommend the use of the protocol involved: "Draft" and "Not John> Recommended" are perfectly consistent. John, in principle I agree with you, but I'll point out there is a huge lack of clarity around ASes. It's hard for example to find ASes for a given TS, and it would confuse people if something were a draft standard and not recommended at the same time. This is particularly true given factors such as the rfc-index only lists the position along the standards track, not the requirements level of the associated AS. I would be all for draft but not recommended if we got to a point where the users of our documents would understand what that meant. I'm all for experiments--even ISD-like experiments--in organizing our metadata and descriptions of standards so people could get these points. I don't have time to work on those experiments myself and so until they succeed my preference is to be conservative. John> It is not consistent with our published policies as I read John> them to refuse to promote it to Draft simply because there John> is general feeling that security technology has passed it John> by. But that is, I think, exactly what would happen today John> if the protocol were proposed for advancement. 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. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf