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

[Alan DeKok <aland@deployingradius.com>]

Avi Lior wrote:
> The problem with the document is as follows:
> 
> It talks about a RADIUS model which is not really defined anywhere.

  I could have sworn that the document tries to address that.

> As an example lets talk about new code.  Depending on your view of what RADIUS is then everytime you introduce a new attribute - not a new attribute type - but just a new attribute say foobar of type int.  Then new code is required - on both the client (NAS) and the RADIUS server.  They have to process this new attribute.

  Already refuted.  See earlier messages.

> I think as long as you use the established data types, then no new code is required by the lower layer (or the RADIUS transport layer or whatever you want to call it) and the upper layer either on the client and server are impacted.  This is the AAA model that diameter uses.

  What does that have to do with RADIUS?

> That is how RADIUS is used today by most SDOs if not all.  And since RADEXT is targeting that group we want the document to reflect that usage - or as a minimum RADEXT should define the model that this BCP applies to.  Then we can agree or disagree on attributes, complexity, security, etc....

  Already addressed.

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