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

["Dave Nelson" <d.b.nelson@comcast.net>]

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