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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-kitten-gssapi-channel-bindings-06.txt
Reviewer: Brian Carpenter
Review Date: 2009-04-05
IESG Telechat date: 2009-04-09

Summary: Almost ready; needs one clarification.

Comments: 

I was expecting the sentence quoted below to be updated
following Nico's comments on my Last Call comment. I think the new
text would be

    Where the language binding of the GSS-API model's channel bindings is as 
    single OCTET STRINGs (or the language's equivalent), then the implementation
    SHOULD assume that the given bindings correspond only to the
    application-data field of GSS-CHANNEL-BINDINGS as shown above.


On 2008-11-03 21:47, Nicolas Williams wrote:
> On Mon, Nov 03, 2008 at 11:10:20AM +1300, Brian E Carpenter wrote:

...

>> 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'? 
> 
> More like "as a single OCTET STRING".
> 
>> 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.)
> 
> Because RFC2743 said "OCTET STRING" and later RFC2744 imposed structure
> without specifying an encoding of that structure to an OCTET STRING.
> 
> That's an old screwup.
> 
> Now, if anyone had built a language binding based strictly on RFC2743
> then they'd have only an OCTET STRING input.  What to do?  Well, since
> those "network addresses" in the RFC2744 channel binding structure
> turned out to be utterly useless[*] and since such a language binding
> would not have intended for network-addresses-as-channel-bindings, the
> simplest choice is as given above.
> 
>> 3. Maybe I'm lacking context, but the 'rather than' clause doesn't make 
>> sense to me at all. 
> 
> I think it can be removed.  Also, I suppose the MUST should be a SHOULD.
>