[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: "Last Look" at the RADIUS Design Guidelines document
Would it be possible for Alan and Avi to take it from this point of the
discussion and try to write and agree on a few paragraphs of text which
describe what this BCP covers and what is not covered and left out
possibly for future work?
Dan
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Avi Lior
> Sent: Tuesday, January 19, 2010 6:06 AM
> To: Dave Nelson
> Cc: radiusext@ops.ietf.org
> Subject: Re: "Last Look" at the RADIUS Design Guidelines document
>
> See inline...
>
> On 18-01-2010, at 04:08 , Dave Nelson wrote:
>
> >> Complex attributes may also be added to the dictionary
> such that the
> >> RADIUS server does not require code changes to process
> these attributes.
> >
> > This may be true of a class of newer RADIUS server implementations,
> > those with a "dynamic" data dictionary, but it is not true
> of another
> > class of more "traditional" RADIUS servers, and it's those
> that this
> > section intends to address.
>
> It should be made clear. Maybe it says that somewhere in the
> document.
>
> As a minimum it must be clearly stated that the intent of the
> BCP is to protect legacy.
> "the recommendation of this BCP are applicable in
> deployements that utilize legacy RADIUS servers/clients...."
>
> Define legacy RADIUS servers/clients and I would be okay.
>
> IMO the BCP should make a distinction and address both legacy
> and newer RADIUS servers. Bu
>
> >
> > As I said in a previous post, the plan is to recommend (via
> this BCP)
> > that newly design RADIUS attributes not contribute to rendering a
> > significant installed base of deployed RADIUS servers
> effectively obsolete.
> >
> > If we were talking about VSAs, this wouldn't be a concern. We're
> > talking about standards-tack attributes.
> Okay then we should make sure that the document makes this clear.
>
> Perhaps we can clarify this -- In section 2.1 and section 2.2
> or in section 2.0
>
> > If all you have to worry about is the class of "enhanced
> capability"
> > RADIUS servers, then I would agree. In the IETF, we need to take a
> > broader view, I think.
> Which is fine but I think you have to document this
> distinction. That is a problem with this BCP only people who
> read these long email threads will understand what is really
> going on. If the intent is to protect the existing radius
> base then we should be clear about that.
>
>
> --
> 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/>