RE: [radext] #31: Section 2.1

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

>  Recommended replacement:
> 
>     All other data formats (including nested attributes) are defined
>     to be "complex data types", and are NOT RECOMMENDED for normal
>     use.  Complex data types MAY be used in situations where they
>     reduce complexity in non-RADIUS systems, or where using
>     the basic data types would be awkward (such as where grouping
>     would be required in order to link related attributes).  Since
>     there are no "hard and fast" rules for where complexity is best
>     located, each situation has to be decided on a case-by-case
>     basis.  Examples of this tradeoff are discussed in Appendix B.
>     Where a complex data type is selected, an explanation SHOULD be
>     offered as to why this was necessary.

At this point in time, I would support adding "such as where grouping would
be required in order to link related attributes" as an example of a case
that would justify the use of complex data types.  It is a great
disappointment to me that the WG failed to come to consensus on a more
regularized and formal mechanism to accommodate attribute grouping.  I think
that the ad hoc mechanism of grouping in complex data values is a distant
second best to a more formal and structured grouping mechanism.  However, at
this point, it is what it is.



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