Re: RFC 2195 (Was: what happened to newtrk?)

On Thursday, September 07, 2006 07:07:51 PM -0400 John C Klensin 
<john-ietf(_at_)jck(_dot_)com> wrote:
> However, 2195 is not, itself, a SASL method and there is nothing
> in the procedural rules as I understand them that permits the
> SASL WG to de-standardize it (you could write any of several
> styles of document that would designate it as "not recommended"
> or even "historic" but such documents had best be in your
> Charter and Last Called as doing that).
To the extent that SASL is the successor to the original extensible 
authentication framework contained in IMAPv4, yes, CRAM-MD5 is a SASL 
mechanism.  The cross-references don't explicitly point out that RFC2222 
obsoletes RFC1731, but it seems clear that was the intent.
> Now, suppose someone comes along who _likes_ the non-SASL
> incarnation of CRAM-MD5 in 2195.  Let's call this hypothetical
> person "nobody" to avoid casting aspersions on Frank.  Nothing
> in our current procedures prevents him, at any time, from
> preparing an interoperability report on 2195-specified CRAM-MD5,
> pointing out that there are many deployed interoperable
> implementations, and asking that 2195 be reclassified (or a
> 2195bis be published) as a Draft Standard.
Well, he could ask that 2195 be advanced as-is, but I would expect such an 
effort to fail, as that version has turned out to be somewhat 
underspecified.  Multiple interoperable implementations is not the _old_ 
criteria for advancement; it is necessary but not sufficient(*).
Given that the SASL WG has an explicit charter item to produce a revised TS 
for CRAM-MD5, with RFC 2195 as a starting point, I would expect any effort 
to do so outside of that WG to meet with very strong resistance.  As Kurt 
has noted, the WG is nearly finished its work on that item, and the 
resulting draft will be in Last Call soon.
The working group decided, due to a variety of considerations, not to 
pursue publication of the new document on the standards track, and instead 
to ask that it be published as Informational.  However, the decision as to 
whether to publish that document and what status to assign it belongs to 
the IESG, not the working group.  IMHO, an argument that it should be 
assigned a status other than that requested by the working group would be 
an appropriate subject for a Last Call comment.


If "nobody" were so
> inclined, I would expect him to protest any effort on the part
> of the SASL WG to deprecate 2195 itself
Why?  That working group's charter clearly includes an item to produce an 
updated specification for CRAM-MD5, and it seems obvious that the intent is 
that such a new specification obsolete RFC 2195 (if it's not obvious, 
that's a bug in the charter; certainly everyone participating in the work 
has understood that to be the intent).


(*) I think this is perhaps the crux of the matter.  I do not believe that 
every old specification should be advanced along the standards track simply 
because it has been around a while and has multiple implementations. 
Advancing a specification to Draft Standard sends the signal that the IETF 
thinks the specification is a good idea and that people should deploy it. 
Protocols for which that is not the case have no business advancing toward 
the status of Internet Standard, *even if we thought they were good ideas 
when they were written*.

-- Jeff

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf