Data Types in RADIUS
draft-ietf-radext-datatypes-08

Note: This ballot was opened for revision 06 and is now closed.

Alvaro Retana No Objection

Comment (2016-08-17 for -06)
No email
send info
It would have been nice to consolidate the IANA-related sections (4 and 6) in one place.

(Alexey Melnikov; former steering group member) Yes

Yes (2016-08-17 for -06)
No email
send info
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.

(Kathleen Moriarty; former steering group member) Yes

Yes ( for -06)
No email
send info

(Alia Atlas; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection (2016-08-16 for -06)
No email
send info
In Section 4.1, if the registration policy is Standards Action doesn't that obviate the need to say anything about IETF Review?

(Ben Campbell; former steering group member) No Objection

No Objection (2016-08-16 for -06)
No email
send info
-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?)

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Mirja K├╝hlewind; former steering group member) No Objection

No Objection (2016-08-17 for -06)
No email
send info
"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.

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Suresh Krishnan; former steering group member) (was Discuss) No Objection

No Objection (2016-10-11 for -07)
No email
send info
Thanks for addressing my DISCUSS and COMMENTs.

(Terry Manderson; former steering group member) No Objection

No Objection ( for -06)
No email
send info