RE: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.txt

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

Hannes Tschofenig writes...

> * This approach is totally inline with the RADIUS design guidelines.
> The RADIUS design guidelines document does not require every info
> element to following the standard encoding, as you know.

The RADIUS Design Guidelines document is pragmatic.  It *strongly* suggests
(SHOULD not MUST) that attributes which could reasonably be implemented in a
data-dictionary driven RADIUS server as data dictionary entries be encoded
in the standard encoding.  Exceptions are made for (a) attributes which
would absolutely require code changes in the server, (b) attributes used as
authentication credentials payloads, and (c) attributes which are opaque to
the RADIUS server and RADIUS client.

This is not a matter of aesthetics or personal design choice -- it is
dictated by the usage.

BTW, *my* definition of opaque means that the data field of the attribute,
as described in the RADIUS document is a single string, whose contents are
defined in some non-RADIUS document.  Once the RADIUS attribute definition
starts breaking the attribute data payload into sub-fields it really isn't
opaque anymore.



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