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

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

Avi Lior wrote:
> I am not proposing to redefine RADIUS. Please show me where I am doing that WRT to this document.

  You are *demanding* that the traditional RADIUS model be removed from
the document.  You have stated that it is no longer relevant:

Avi Lior, January 6:
>>> I think it would be worth while to define the RADIUS model first.
>>> Not the old RADIUS model but rather the one that we are all living
>>> with today.  That model is not really different then Diameter.

  40% (or more) of current RADIUS deployments would disagree.

  There is *no question* you are trying to redefine RADIUS.  There is no
question that you want to require it be more than the traditional model.

> And even in the extended document i did not want to extend the attribute in the sense of COmplex Types.  The working group did.  All we were trying to do is extended the attribute type space beyond 256.

  ... and add a new grouping mechanism

  ... and add a mechanism to allow attributes longer than 253 octets.

http://tools.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extension-02.txt

  That's from 2007, before it was a WG draft.  I can read, too.

> Take a look at my comments and comments made by other folks and stick to those topics.  That is if you want to make progress.

  I have seen *no* relevant argument for removing discussions on
attribute design from the design guidelines document.  The main
rationale put forward is "it will make my life difficult in an SDO".
(Which also puts paid to the argument that "everyone will ignore it")

  The issue is *not* about "complex types", though that is the main
point of contention.  It's whether or not attribute design guidelines
belong in the design guidelines document.

  Please explain in short, simple words why design guidelines do not
belong in the design guidelines document.  Don't mention "complex
types".  Don't mention "traditional" versus "modern" RADIUS model.

  The closest you've come to this is saying that text about the
application layer doesn't belong in the document.  That's a good
argument, but there are arguments to counter it, too.

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