[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Proposed resolution to guidelines document

Alan said:

How about adding some text to Section 2.1.3:

"  There may be situations where complex attributes are beneficial,
because they reduce complexity in the non-RADIUS systems.
Unfortunately, there are no "hard and fast" rules for where the
complexity would best be located.  Each situation has to be decided on a
case-by-case basis."

[BA] Is this referring to the "opaque data" case?  Elsewhere in 2.1.3 it
talks about these attribute being defined as type "String":

   If the RADIUS Server simply passes the contents of an attribute to
   some non-RADIUS portion of the network, then the data is opaque, and
   SHOULD be defined to be of type String.  A concrete way of judging
   this requirement is whether or not the attribute definition in the
   RADIUS document contains delineated fields for sub-parts of the data.
   If those fields need to be delineated in RADIUS, then the data is not
   opaque, and it SHOULD be separated into individual RADIUS attributes.


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