ietf
[Top] [All Lists]

Re: Client and server authentication for email

2005-06-13 01:08:21


--On Monday, June 13, 2005 12:56 AM -0400 Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf



<Prev in Thread] Current Thread [Next in Thread>