>>>>> "John" == John C Klensin <john-ietf@xxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf