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

[Suresh Krishnan <[e-mail]>]

Hi Kathleen,
   I have looked at the new revision and it addresses my concerns. I have 
cleared.

Regards
Suresh

On 10/11/2016 12:27 PM, Kathleen Moriarty wrote:
> Hi Suresh,
>
> The new version was posted.  Can you check to see if you are satisfied with
> the changes?
>
> Thank you,
> Kathleen
>
> On Thu, Aug 18, 2016 at 11:01 PM, Suresh Krishnan
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     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] <mailto:[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.
>     >
>
>
>
>
>
> --
>
> Best regards,
> Kathleen