On 4/2/15 2:41 PM, Robert Sparks wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-hansen-scram-sha256 > Reviewer: Robert Sparks > Review Date: 2Apr2015 > IETF LC End Date: 24Apr2015 > IESG Telechat date: (if known) > > Summary: Ready for publication as Informational, with nits that should > be considered. > > Nits/editorial comments: > > Nit: > It raises flags for me when an Informational document uses "Updates" > on a standards track document. > I would argue that this does _not_ update 5802. IANA did the things > that 5802 requested, and this document > is requesting something else that happens to change those things. That > makes this more of a "see also" than > a "the protocol changed", and I think the Updates should be removed. > > I don't feel super strongly about the difference in _this particular > case_, hence its classification as a Nit. > But for consistency, and avoiding the issue of having an Informational > update a PS, I hope you choose to remove it. > > Editorial comment: > The URLs in the references section seem superfluous since you've > already expanded them in the introduction? Finally made it back to working on this doc. Thank you Robert for your review. Your comments raise a different question for me: should this spec instead be on the standards track? It *is* defining a SASL mechanism that will probably be used in other standards, in particular, httpauth. One of the reasons for the updates is that mailing address specified in 5802 has changed. If someone reads 5802 without reading this spec, they will probably send email to the wrong mailing address. As for the URIs, those will go away when the paragraph holding them goes away. Thanks again for the comments. Tony Hansen