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

[Kathleen Moriarty <[e-mail]>]

Hello Ben,

Are you good with Alan's response and changes resulting from one of your
points?

Thank you,
Kathleen

On Tue, Oct 11, 2016 at 4:16 PM, Alan DeKok <[e-mail]>
wrote:

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


-- 

Best regards,
Kathleen