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

["Glen Zorn" <glenzorn@comcast.net>]

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.
[gwz] 
[gwz] I'm a bit confused by this statement: the attribute extension draft
basically doubles the size of the existing 
"standard attribute space.  Are you saying that the filter rules would take
up that whole extension?

  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.
[gwz] What changes would you make?

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