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

[Alan DeKok <aland@deployingradius.com>]

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