--On Monday, October 26, 2009 02:05:43 PM +0100 Pasi.Eronen at nokia.com wrote:
I've now done my AD review for draft-ietf-sasl-gs2-17. Basically, it looks good, so I've asked the secretariat to start IETF Last Call. I do have couple of minor comments that can be considered as the first last call comments: - I have two questions about Section 8. First, if the GS2 mechanism doesn't e.g. support confidentiality, wouldn't setting conf_req_flag cause things to fail? (so it's not really "irrelevant")
No. conf_req_flag indicates a request, not a demand; if the mechanism doesn't support confidentiality, or it cannot be negotiated, then you'll get a context that doesn't include that feature. GSS-API applications which do require that feature must check that the conf_avail flag is set on context establishment, indicating that the feature is available.
- Second, should Section 8 say something about the flags that are not related to per-message tokens? (deleg, mutual, anon)
I'm a fan of being fairly specific about the values that must be passed in to the GSS-API, where particular values are needed. So, I wouldn't object to making section 8 a little more verbose. But, I also don't care very much; GS2 doesn't need any of the features requested by these flags, nor will it be harmed by requesting them.
- Section 4 should say either that character case (for things like "p=" and "a=") must be exactly as shown here, or that they're case insensitive (if nothing is said, RFC 5234 strings are by default case insensitive, I think).
In RFC5234 ABNF, strings given in quotes are always case-insensitive. See the bottom of page 5 of that document. If that's not what we mean, we need to specify the letters numerically, like %x61.3d instead of "a=".
-- Jeff
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.