--On Monday, June 13, 2005 12:56 AM -0400 Keith Moore
<moore@xxxxxxxxxx> wrote:
...
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 this particular case, that assumption is reasonable. I don't
know whether the document authors have done such a search, but
some of the rest of us certainly did.
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)."
And that would be a plausible solution to the present impasse/
debate, although, obviously, not as desirable as getting on
things before the problem manifests itself in a document that
has advanced far enough to be up for IESG consideration.
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.
I suggest that, from a process standpoint, if we start
deprecating standards-track documents/ recommendations by errata
page, we will be in big trouble... or will need a process and
bureaucracy equivalent to the IESG for errata page approvals.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf