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

From: "Suresh Krishnan" <[email-masked]>
Date: Tue, 16 Aug 2016 20:43:07 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-radext-datatypes-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-radext-datatypes/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

* 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.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* 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.)

* 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

* Section 3.10 and 3.11

The separator between the Reserved field and the Prefix Length field is
off by one position.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 18 Aug 2016 18:36:21 +0200

> explicit statement to say so.

  The preferred encoding should be the shortest one.  I'll put some text together.

> 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.
 
> The "ifid" data type encodes an 8 octet IPv6 Interface Identifier in

  Sounds good.

> The separator between the Reserved field and the Prefix Length field is

  Fixed.

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 19 Aug 2016 03:01:59 +0000

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

Thanks
Suresh