Re: Issue: Data Type Advice

[Alan DeKok <aland@deployingradius.com>]

Dave Nelson wrote:
> Bernard Aboba writes...
> 
>> Therefore the "existing RADIUS data model as outlined below" is really
>> just the data model for standard RADIUS attributes. 
> 
> Well, characterizing various ad-hoc extensions as part of a data model seems
> to me to de-value the term "data model".  :-)

  Most vendors are smart/lazy enough to re-use the existing data types.
 The guidelines draft is intended to encourage this behavior, and to
discourage "complex" types that are little more than simple collation of
existing data types.

  It is intended to encourage SDO specifications that re-use existing
data types.  These specifications should *not* need IETF review.

  Specifications that are SDO specific, and do *not* re-use existing
types are SDO specific, and do not need IETF review.

  Much of this is already in the document.  What can we do to clarify
the text to avoid repeated questions?

>>   Does the data fit utilize ad-hoc extensions to the RADIUS data model,
>>   as outlined in below?  If so, it SHOULD be encapsulated in a RADIUS VSA 
>>   or an Extended Attribute [EXTENDED].
> 
> While it may be feasible to group the ad-hoc extensions into a handful of
> categories, I'm not sure what benefit this provides.  Anything *other* than
> the (limited) standard data model is automatically an ad-hoc extension,
> right?  Do we need to provide examples?

  I would say no.

  The most I would do is to provide horrific examples of what *not* to
do.  i.e. putting arbitrary text strings into the "data" portion of a
VSA (no... no VSA-type/VSA-length/VSA-data... just Vendor-Id/text..)

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>