Re: [radext] Ben Campbell's No Objection on draft-ietf-radext-datatypes-06: (with COMMENT)

[Alan DeKok <[e-mail]>]

> On Oct 11, 2016, at 3:59 PM, Kathleen Moriarty <[e-mail]> wrote:
> 
> Hi Alan,
> 
> I don't see responses to the No Objection messages on your draft.  Can you take care of that so I can progress the document?

  I didn't get the original message. <mumble smtp issues>

> ---------- Forwarded message ----------
> From: Ben Campbell <[e-mail]>
> Date: Tue, Aug 16, 2016 at 9:59 PM
> Subject: Ben Campbell's No Objection on draft-ietf-radext-datatypes-06: (with COMMENT)
> To: The IESG <[e-mail]>
> Cc: [e-mail], [e-mail], [e-mail], [e-mail]
...
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> -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?)

  Any such new definition MUST be registered.  RFC 6929 just forbids new data types.

  I think I can update the doc in the next rev, as soon as that's required.

> -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?)

  See RFC 6929 covers this in detail.  There are few good reasons to create new data types.  There is a huge cost to creating new data types, and very little benefit.

  Section 6 has guidelines for creating attributes.  RFC 6158 also contains long guidelines in Appendix A.  Both sections have text explaining why these guidelines are in place.

  In addition, as the draft notes, RADIUS implementations are typically driven by a dictionary containing attribute names, assigned numbers, and data types.  This means that adding new attributes with known data types is trivial: edit the dictionary.  Adding new data types is complex, and requires much code to be written.

  Another reason is practice.  I'm aware of only a few data types which have been vendor-defined in the last twenty years.  One is an "ad hoc" structure to describe firewall rules.  Another is a signed integer (the above RFCs explain why this is wrong).  A few vendors defined a 64-bit integer before the IETF did.  That's really about it.

  So new data types are not needed, and without IETF consensus, are generally wrong.

  FWIW, IPFix has a fixed set of data types, an IANA registry, and requires standards action for update.  There is a strong overlap between the data IPFix tracks, and RADIUS accounting.  So a fixed set of data types works well in both places.

  Alan DeKok.