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

[Avi Lior <avi@bridgewatersystems.com>]

I dont disagree with most of what you are saying...but I want to focus back to the point...

In an exchange on Jan 18 David Nelson wrote...

"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."

The document should clearly state what you wrote...otherwise, it will create confusion - as you can see...

Or improve the text to encompass all different types of models/deployments/implementations ... I don't think you want to do that.

But what is clearly not acceptable is to leave the document as is.


On 22-01-2010, at 21:50 , Dave Nelson wrote:

> Avi Lior writes...
> 
>> I would think that the BCP that would be published today
>> will be reflecting the new RADIUS designs but if that is not
>> the case then we need to be clear about the applicability of
>> this document.  I am okay with a BCP that applies to protecting
>> traditional RADIUS usage but we need to be clear about it.
>> 
>> Can we start with this then...
> 
> I'm not sure what this really means.  I *suspect* that it provides a
> convenient way to dismiss the document as being irrelevant when doing new
> RADIUS work in "walled gardens" of "current technology" RADIUS server
> deployments.
> 
> The thing about protocols is that they are simply words on paper.  A
> *protocol* can not be said to have the property of multi-vendor
> interoperability.  Only *implementations* of protocols can be tested to see
> if interoperability is obtained.  Given that multi-vendor interoperability
> is a key concern of IETF Standards-Track protocols, we can't dispense with
> discussing implementations.
> 
> If a sufficient number of implementations take advantage of any given
> property of a protocol, such the simplicity of that protocol's data model,
> that property, e.g. the data model, becomes an integral element of the
> protocol.
> 
> That's the case here.  The simple data model is an inherent property of the
> RADIUS protocol by virtue of many implementations having relied upon it, if
> for no other reason.  If we want to expand the data model, to be more rich
> and complex, we therefore need to either revise or extend the protocol.
> 
> IMO, We can't simply say that the past is irrelevant, and we're going to
> define a new version of the protocol that works well with a class of newly
> designed implementations.  That would violate the basic tenets of
> multi-vendor interoperability.
> 
> I'm all *for* expanding the RADIUS data model.  In fact, my personal
> preferences in that regard extend beyond what the WG has achieved consensus
> to support.  However, we need to do that within the constraints of a
> reasonable protocol evolution methodology.  Either we add a protocol version
> number negotiation methodology or we use an "escape" mechanism such as the
> Extended Attribute format.
> 
> I think that simply ignoring the interoperability considerations of a
> significant class of implementations, by labeling them "traditional",
> legacy" or "historic" (or any other synonym) is the wrong thing to do.
> 
> 
> 
> --
> 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/>