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

["Suresh Krishnan" <[e-mail]>]

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.