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

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 11 Oct 2016 12:26:54 -0400

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 <
[email-masked]> 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 <
> [email-masked]> 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

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 11 Oct 2016 19:46:09 +0000

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:
> On Thu, Aug 18, 2016 at 11:01 PM, Suresh Krishnan
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Alan,
>     > On Aug 17, 2016, at 5:43 AM, Suresh Krishnan
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >> * Section 3.10
>     >>
>     >> It is not clear from this definition how exactly a sender needs to encode
>     >> prefix such 2001:db8:dead:beef::/64 can legally be encoded using anywhere
>     >   The preferred encoding should be the shortest one.  I'll put some
>     text together.
>     >
>     >> aligning a 4 octet or a 16 octet value to a 16 bit boundary would provide
>     >> any value.
>     specifications.  I'm not entirely sure why they have reserved fields, either.
>     >

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 11 Oct 2016 15:56:13 -0400

Thank you, Suresh.

-- 

Best regards,
Kathleen