I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-kitten-gssapi-channel-bindings-05.txt Reviewer: Brian Carpenter Review Date: 2008-11-03 IETF LC End Date: 2008-11-13 IESG Telechat date: (if known) Summary: This draft is on the right track but needs some clarification. Comments: Here, then, is a generic re-statement of this structure, in pseudo- ASN.1: What's pseudo-ASN.1? This is normative, so why isn't it ASN.1? I can't parse this sentence: Where a language binding of the GSS-API models channel bindings as OCTET STRINGs (or the language's equivalent), then the implementation MUST assume that the given bindings correspond only to the application-data field of GSS-CHANNEL-BINDINGS as shown above, rather than some encoding of GSS-CHANNEL-BINDINGS. 1. Is the 'as' supposed to mean 'only as'? 2. Why is this restricted to the application-data field? Why doesn't it also cover the various address fields? (OK, there's a clue hidden in the Security Considerations, but the explanation belongs here.) 3. Maybe I'm lacking context, but the 'rather than' clause doesn't make sense to me at all. Now, if what this is actually saying is that "Where a language binding does not support a SEQUENCE (or the language's equivalent)..." I could make some sense of it. But then the (pseudo) ASN.1 would need to be different, since the address fields would be absent.
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
