Re: Extensibility of draft-ietf-radext-filter-rules

[Alan DeKok <aland@nitros9.org>]

David B. Nelson wrote:
> Maybe.  Keep in mind that the Extended RADIUS attribute work is introducing
> a method of accommodating grouped attributes (AVPs) in RADIUS.

  That's nice, but doesn't solve the next problem.  The filter rules
document really describes transporting IP addresses and ports via...
text strings.  The guidelines document says this is not recommended.
However, the filter rules document could quickly use many attributes,
exhausting the standard attribute space.

  Is it time to allow sub-attributes?  I will not that the guidelines
document also has them as not recommended.  But 3GPP is using them, as
is WiMAX.  And WiMAX is using the extended attributes proposal... with
the WiMAX vendor identifier.

  Given the utility of sub-attributes, and the fact that most vendors
have implemented them already, or will implement them for WiMAX, I'm
inclined to add them to the extended attributes draft.

  That would permit the filter rules document to define sub-attributes
using the normal RADIUS data types, and encapsulate them in a "filter
rules" AVP.  Given the choice between implementing sub-attributes and
parsing text strings, I strongly prefer sub-attributes.

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