Re: [radext] Alissa Cooper's No Objection on draft-ietf-radext-coa-proxy-06: (with COMMENT)

[Alissa Cooper <[e-mail]>]

> On Aug 15, 2018, at 3:50 PM, Alan DeKok <[e-mail]> wrote:
> 
> On Aug 15, 2018, at 3:44 PM, Eric Rescorla <[e-mail]> wrote:
>> 
>> On Wed, Aug 15, 2018 at 12:25 PM, Alan DeKok <[e-mail]> wrote:
>> On Aug 15, 2018, at 2:33 PM, Alissa Cooper <[e-mail]> wrote:
>>> S 3.3.
>>> 
>>>>    The new Operator-NAS-Identifier attribute is defined as follows.
>>> 
>>> I suggest adding the depiction of the fields and their lengths in
>>> bytes, as is done in RFC 5580. I was a little confused about whether
>>> the fields in the attribute are just the TLV.
>> 
>>  There are no fields in the Operator-NAS-Identifier attribute.  it's just an opaque blob.
>> 
>> I believe what Alissa means is that it's variable length and therefore must be somehow delimited.
> 
>  The encapsulating RADIUS attribute header has a "Length" field.  That delimits the Operator-NAS-Identifier value.
> 
>  The value itself is (again) just an opaque blob.  The value can have any length, 1 to 32 octets.  There is no intrinsic meaning in any one octet of the value.

Acknowledging my limited recall of how RADIUS attributes are defined, I think what is tripping me up is the definition of the Length field, which says “4 to 23.” If I assume that length is measured in octets, that the type field requires 1 octet, that the length field requires 1 octet, and that the value can be between 1 and 32 octets long, I would conclude that valid length values would be between 3 and 34, not between 4 and 23. Can you clarify why not?

This is I guess the root of why I thought the octet diagram would help.

Alissa  

> 
>  There is no need for the *contents* of the attribute to have any delimitation whatsoever.
> 
>  Alan DeKok.
> 
>