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

[Kathleen Moriarty <[e-mail]>]

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]> 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]> 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