Re: Client and server authentication for email

[John C Klensin <john-ietf at jck.com>]

--On Monday, June 13, 2005 12:56 AM -0400 Keith Moore 
<moore at cs.utk.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.org
https://www1.ietf.org/mailman/listinfo/ietf