RE: Question regarding draft-ietf-radext-design-05.txt

["D. B. Nelson" <d.b.nelson@comcast.net>]

Hannes Tschofenig writes...

> Given the available data types this was essentially the only 
> choice to comply with the idea of the data dictionary and the
> desire to have everything be covered under the available data
> types.

Yes.  The current RADIUS data types are very limiting, in that they
represent only scalars and octet arrays (strings).  I once suggested that we
try to address this in a fashion similar to the way SMI (SNMP) handles this
issue, i.e. to allow sequences of basic types to be encoded in an attribute
to form a complex type.  That went over like a lead balloon. :-(

> Whether the AAA server had to be updated in order to provide
> additional parsing capability depends a lot on the procedure how
> some of these attributes (and the values in them) get introduced
> into the system in the first place.

Sure.  The problem is, I suspect, that if one developer gets to standardize
attributes that were designed based on _his_ server implementation, that may
have impact on everyone else whose server is implemented differently.  What
turns out to be a natural encoding representation for a given implementation
/ system design may be cumbersome for another design, even though both are
fully "compliant" with the feature requirements.  Standards have to serve
the least (reasonable) common denominator.



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