Re: Issue: Data Type Advice

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> Section A.1.1 reads:
> 
>    Does the data fit within the existing RADIUS data model, as outlined
>    below?  If so, it SHOULD be encapsulated in a [RFC2865 <http://tools.ietf.org/html/rfc2865>] format RADIUS
>    attribute, or in a [RFC2865 <http://tools.ietf.org/html/rfc2865>] format RADIUS VSA.
> 
> As noted in an earlier issue, Appendix B does not cover data types
> utilized within RADIUS VSAs,
> only the data types in standard RADIUS attributes.

  When the VSAs use standard data types, they are compatible with the
RADIUS data model.  This practice should be encouraged.

>   Therefore the
> "existing RADIUS data model
> as outlined below" is really just the data model for standard RADIUS
> attributes.

  And a RECOMMENDED one for VSAs.  Non-standard data types can be
problematic.

>   On that basis
> the sentence might better read:
> 
>    Does the data fit within the RADIUS standard attribute data model, as outlined
>    below?  If so, it MAY be encapsulated either in a [RFC2865 <http://tools.ietf.org/html/rfc2865>] format RADIUS
>    attribute, or in a [RFC2865 <http://tools.ietf.org/html/rfc2865>] format RADIUS VSA.

  I'm not sure that change is necessary.  The data model applies to
VSA's, too.  Looking at the dictionaries I have access to, I see:

  * ~4K VSA definitions
  * 3 vendors with non-standard data types
  * 7 non-standard data types of
     * abinary
     * byte
     * short
     * polymorphic ipv4/ipv6 address
     * signed
     * tlv  (e.g. 3GPP2 && WiMAX)

  The "abinary" is the old Ascend binary filter attribute.  Everything
else is used by the WiMAX standards, though other vendors use some of
the types, too.

  This last survey isn't *quite* accurate, as a number of non-standard
types are treated as "string" in the dictionaries.

> Assuming that the promised survey of ad-hoc data model extensions is
> actually included in the
> document, then this could be referenced to in a subsequent sentence:

  I would prefer to not survey the ad-hoc extensions to the data model.
 There may be a fair number, and I would conjecture that most offer

  I think we should recommend that VSAs use the existing data types.

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