Re: "Last Look" at the RADIUS Design Guidelines document

[Alan DeKok <aland@deployingradius.com>]

Avi Lior wrote:
> I dont agree with that.  You should not make a judgement call about my application layer.  A complex attribute embedded in a VSA or a String does not make RADIUS layer complex!!!

  The document states *clearly* that transporting complex attributes is
fine, so long as it is opaque to RADIUS.

  If the attributes are *not* opaque to RADIUS, then all of my previous
comments about complexity apply.

> You are asserting that grouping of attributes together adds complexity and I am saying that that is not neccessarily true.

  I'm pretty sure I never said that.

> I think you should let the Designer of the "Application" decide - or do a better job talking about design practices of the Application layer.  I rather we keep silence about practices at the application layer.

  The document *explicitly* states that transport of opaque data (i.e.
application data) is permitted.

  I am already doing what you request.  Please read the document.

> I think the push back is based on the fact that we are disagreeing on the application.  If we rely on the RADIUS layer to parse the attributes then yes it is complex.  But this is not about the RADIUS layer.  And the use of these grouped AVPs is actually reduces complexity.

  The document and this list is about RADIUS.  I have no comments on
non-RADIUS application data.  It now seems that your comments are not
about RADIUS, and therefore are either already addressed in the
document, or are irrelevant to RADIUS.

  i.e. If this isn't about RADIUS, then the discussion can stop now.

  Alan DeKok.

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