[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Last Look" at the RADIUS Design Guidelines document
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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.