Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt

[Kurt Zeilenga <[e-mail]>]

I see the WG as having needs to choose between three possible  
approaches:
1) revise the CRAM-MD5 specification, resolving known technical  
issues, such that it is suitable for progression (eventually all the  
way to Internet Standard) on the Standards Track,
2) seek a waiver from the IESG of certain requirements placed upon  
SASL mechanism specifications (such as RFC 4422
requirement that mechanism specifications detail how character data  
inputs to cryptographic functions be precisely specified to ensure
interoperability), or
3) documenting existing CRAM-MD5 practice in an Informational  
document, noting the known technical issues.

Consensus has been, and continued to be, that fixing known technical  
issues would be too disruptive to existing deployments (which as you  
note are quite significant).  With this consensus, the third path  
seems quite appropriate as seems to make no sense to progress a  
document on the standard track that you wouldn't put on the standards  
track if considered anew.

It seems to me that what you and others seek is an IESG waiver from  
various requirements placed this technical specification.  It is  
unclear to me whether the IESG which, if any, requirements the IESG  
might be willing to waive in this case.   To to able to even consider  
granting a waiver, they would from us a statement of the specific  
requirements we wish to have waived and why we believe the waiver is  
justified.   I suspect this approach would face a number of challenges  
and is likely to fail.   In particular, given the WG consensus not to  
disruptive to deployments of CRAM-MD5, the intent seems to be never to  
revise the specification to met the requirements.  As such, the  
specification would ever be suitable for Draft (or better) status.  It  
seems inappropriate to keep such a specification on the standards  
track.  Another challenge is that the RFC 2026 specifically warns  
deployments of Proposed Standard specifications of the likelihood that  
subsequent revision will be disruptive to deployers and hence a  
request for waivers based upon such disruption is weak at best.   
Anyways, I ask that those who advocate that certain requirements be  
waived prepare text detail why they should be waived.

I do think it reasonable for those believing the specification fails  
to met requirements placed upon it, enumerate those requirements.   
With that in mind, one requirement I see (off hand) failing to met is  
RFC 4422 mandatory requirement that SASL mechanisms specifications  
precisely specify how character data is to be prepared for input to  
cryptographic to ensure interoperability between implementations of  
the specification.  I do believe there are other requirements.  I  
encourage others to detail them on the list.

I note that little work is needed to accomplish 3 (make the changes  
recently discussed on the list).   2 requires a some amount of work:  
namely documenting the requirements to be waived and why.  1 has no  
support for actually making the changes required under this approach.

-- Kurt