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.