Re: [radext] Suresh Krishnan's Discuss on draft-ietf-radext-datatypes-06: (with DISCUSS and COMMENT)

[Suresh Krishnan <[e-mail]>]

Hi Alan,
   Thanks for your response. I will clear once you post a new version with 
the changes.

Thanks
Suresh

On 08/18/2016 12:36 PM, Alan DeKok wrote:
> On Aug 17, 2016, at 5:43 AM, Suresh Krishnan <[e-mail]> wrote:
>> * Section 3.10
>>
>> It is not clear from this definition how exactly a sender needs to encode
>> this attribute on the wire. e.g. From the spec it looks like an IPv6
>> prefix such 2001:db8:dead:beef::/64 can legally be encoded using anywhere
>> between 8 octets and 16 octets. What exactly is the preferred encoding?
>> If you intend to allow all of the encodings can you please add an
>> explicit statement to say so.
>
>   The preferred encoding should be the shortest one.  I'll put some text together.
>
>> * I am not sure why this document uses Reserved fields in sections 3.10
>> and 3.11. Is it for alignment? Please clarify. I don't see exactly why
>> aligning a 4 octet or a 16 octet value to a 16 bit boundary would provide
>> any value.
>> (I personally think such padding related stuff should be in the
>> definition of the radius attribute that uses the datatype and not in the
>> datatype itself but I will not block on this.)
>
>   The data types in 3.10 and 3.11 are taken from previous specifications.  I'm not entirely sure why they have reserved fields, either.
>
>   We can't change the format of the data type, because implementations use this format.  The document just codifies existing practices.
>
>> * Section 3.7
>>
>> I think this text is confusing because "octet string" and network byte
>> order do not seem to be compatible. Suggest rewording
>>
>> OLD:
>> The "ifid" data type encodes an Interface-Id as an 8-octet string in
>>   network byte order
>>
>> NEW:
>> The "ifid" data type encodes an 8 octet IPv6 Interface Identifier in
>>   network byte order
>
>   Sounds good.
>
>> * Section 3.10 and 3.11
>>
>> The separator between the Reserved field and the Prefix Length field is
>> off by one position.
>
>   Fixed.
>