[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Last Look" at the RADIUS Design Guidelines document
Alan,
The problem with the document is as follows:
It talks about a RADIUS model which is not really defined anywhere. The document itself talks about impacts on RADIUS and Applications and it define neither nor does it define the interactions between the RADIUS server and the Applications. That is a huge problem because the document makes statements and when the reader has a different model in his/her brain it creates confusion.
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.
The view (that i get from the document) WRT to the NAS (client) new code would be required and WRT to the server no new code would be required. This is problematic.
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.
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....
There are other problems as I pointed out and inconsistencies that are problematic.
On 11-01-2010, at 06:05 , Alan DeKok wrote:
> Wojciech Dec (wdec) wrote:
>> With all due respect, but this isn't terribly helpful. Based on this
>> and previous heated threads, it's my impression that the topic of
>> complex attributes and how they're described/dealt with in the "Design
>> Guidleines" document has been and clearly continues to be a bone of
>> contention, i.e. there doesn't appear to be any long standing consensus
>> on the matter.
>
> The main point of discussion is whether or not RADIUS is *more* than
> what is described in the documents. I think that everyone, (including
> me), agrees that RADIUS *can* be more.
>
> The point of contention is whether or not it is *required* to be more.
>
> The document describes a model of RADIUS which is compatible with the
> original implementation and specification. The model is also compatible
> with 100% of the RADIUS deployments today.
>
> The document recommends BCPs according to that model, and does not
> forbid against any behavior that is more capable than the model suggests.
>
> The "heat" in the discussions comes from two topics. One, an
> accusation that the document forbids "more" from RADIUS. And two, a
> request that the document be changed to *require* more from RADIUS. I
> have repeatedly offered proof that (1) is wrong, and repeatedly
> suggested that (2) is out of scope of this document.
>
>> If we want to move on with the doc, perhaps removing the
>> whole section off to another draft would be the way to go.
>
> I have previously suggested writing a new document. Please do so.
>
> But removing the "basic" model description from the document would
> mean that the design guidelines would refer to a non-existent design.
> That renders the document useless for all practical purposes.
>
> To put it another way, *requiring* a more complex model from RADIUS
> would mean that 100's of 1000's of deployments that do AAA for 100's of
> millions of users would suddenly be defined post-facto as "not matching
> the RADIUS operational model".
>
> This idea is *ridiculous*. It's gaming the standards process in order
> to bypass open competition in the market place.
>
> 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/>
--
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/>