Let's suppose we have a standards track document that says "this is
a technique that can reasonably used in situation X". Maybe, to
create the problem of interest, it is sufficient that it be a
standards track document and not say "doing this in any form is
really stupid but, if you insist on doing it, this is the agreed-
upon way".
Now someone comes along with another protocol or BCP that is being
designed. We claim we believe in reuse of protocols, rather than
adopting a "invent everything anew" approach, so looking for
existing tools and protocols is presumably a reasonable thing to
do. I'd like to think that, if a group finds a standards-track
document, checks the various indices and determines that it hasn't
been superceded or moved off the standards track, and decides on
that basis to go use the thing, they have done due diligence. If
"still on standards track" isn't sufficient to constitute a "safe
to use" recommendation, then I suggest that the IETF is in rather
serious trouble. In particular, if someone, especially the IESG,
shows up during Last Call and says "use of that thing is evil,
please drop it", that is a symptom of a particularly nasty problem.
okay, I see your point. and for the sake of argument I assume that
this isn't a case of standard X being contradicted/updated/superseded/
invalidated by some later document - the WG or document author has
read all relevant documents and hasn't found any reason to not use
standard X. In such a case I'd certainly support some sort of fast
track action to publish an applicability statement of the form "X is
broken and is no longer recommended and considered safe to use; the
known risks associated with continued use of X are these; we
recommend that you transition away from use of X (immediately, asap,
within time T)."
p.s. For Newtrk/ISD discussion fans, note that, if we had that
mechanism in place, the amount of work that would be required to
deprecate CRAM-MD5 as described above would have been to get some
level of consensus and reissue the ISD with a "not recommended any
more" sentence and a change in status for the RFC. The level of
flexibility anticipated for those documents is such that it would
be reasonable to post an version of the ISD with that much change
and an indication that an explanation would follow and/or citations
to a few published articles and we could reasonably expect to have
such a notice posted formally on the ISD within a really short time
of the IESG decision to approve the change. By contrast, doing
it today requires that we go though the entire process from I-D to
RFC, that the description of the problems be complete enough for
RFC publication, and that there is no real notice to the typical
implementer until the RFC is published.
well the RFC Editor does have errata pages now. this might be a good
use for them, until such time as corrective RFCs can be written and
published.
Keith
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf