RE: [radext] #36: Section 3.2.3

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

>  Recommended change:
> 
>  Another exception to the recommendation against complex types is for
>  types that can be treated as opaque data by the RADIUS server.

This is a single sentence out of context, so my concern may be addressed
elsewhere, but I've always felt that one important test of "opaqueness" is
whether or not the payload of the attribute is laid out in details in the
RADIUS document, in the traditional fashion of other RADIUS attributes.  If
it's truly opaque, then the format MUST be defined in some other, non-RADIUS
document.  Otherwise, this opens up the possibility of defining new services
in the context of a RADIUS document.  In other words, an attribute can't at
the same time be "opaque" to the RADIUS server but spelled out in detail to
the RADIUS developer in the RADIUS document.  It's either "defined
elsewhere" or it isn't.



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