Re: Client and server authentication for email

> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf