It's been a while since I read this, so I re-read it from scratch. Mostly editorial nits:
Section 3: implementation may chose to use the same iteration count for all account.) The server sends the salt and the iteration count to the ^^^^^^^ accounts Section 7:
generic-message = attr-val *("," attr-val)
;; Generic syntax of any server challenge
;; or client response
I observe that gs2-header does not conform to "generic-message" if it begins with "y" or "n". This inconsistency could be resolved by removing "generic-message" from the document.
Section 10:
SASL Mechanisms registry. IANA is requested to prevent future registrations of SASL mechanisms starting with SCRAM- without consulting the SASL mailing list <ietf-sasl@xxxxxxx> first.
This at least needs to designate a successor review process if ietf-sasl@xxxxxxx goes away. I'd also prefer the document enumerate principles for when to allow registration. Personally, I consider undesirable to have the family be large. I'd prefer it contain only SCRAM-SHA-1, and in the future SCRAM-SHA-3 (with the -PLUS variants). Perhaps we could briefly discuss this at the meeting.
I support advancement of this version of the document on the standards track.
I intend to implement it excluding section 8 and SASLprep. I will attempt to implement channel bindings, but it has gotten fairly complex particularly with all this stuff about different types of channel bindings. I am unsure how difficult it will be to add channel binding support to NSS. In the event I succeed with channel bindings, but subsequently experience interoperability problems with channel bindings, I will remove all channel binding support from my implementation.
- Chris