Ballot for draft-ietf-radext-datatypes
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
I think this is a very useful document, thank you for writing it. Some comments: In 3.4: ABNF needs an informative reference to RFC 5234. In 3.16: there is a reference to Section 2.13. There is no such section in the document. Did you mean 3.15? In 4.1: does the "value" even need to be in the IANA registry, considering that it never appears on the wire? In 4.2: I would recommend that you instruct RFC Editor to remove the CSV content, as it is not useful long term. So basically IANA can use the data, then the section can be shortened.
In Section 4.1, if the registration policy is Standards Action doesn't that obviate the need to say anything about IETF Review?
It would have been nice to consolidate the IANA-related sections (4 and 6) in one place.
-2.1.2, first paragraph: "The specification may, of course, define a new data type and use it in the same document." Am I correct to assume that any such definition must (or maybe MUST) be registered? (Maybe that's already covered in 6929?) -4.1: I'm curious why new data types need a policy as strong as "standards action". Is there a concern that people will get this wrong without the full weight of the IETF consensus process? Is there a concern that the numbering space will run out? Would it be reasonable to have a "specification-required" policy, with some guidance to the designated expert(s)? (Or is it because such data types need to be referenceable from standards track documents, perhaps related to the guidance against vendor-specific types?)
"As RADIUS does not encode information about data types in a packet, the numbers assigned to a data type will never occur in a packet." Given the Name must be unique, I don't see why a Value field is needed. Related: There is an inconsitency between section 4.1 and 6 regarding the use of Description/Name.
Thanks for addressing my DISCUSS and COMMENTs.