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

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

> Woj> The BCP steers to protect more radius server *implementations*
> and not protocol interoperability.

I think you perhaps underestimate the role that standards play in
maintaining multi-vendor interoperability, not only at a given snap-shot in
time, e.g. at a plug-fest, but over time in the marketplace, such that
various generations of product implemented to the same standard continue to
interoperate over time -- in the case of long-standing "legacy" protocols
like RADIUS, over a very long time.

> To put it in other words; if a radius server does not support an
> attribute that is deemed useful by an operator, it will get changed,
> period.

One reason that customers like standards is that they provide a "level
playing field".  While it's true that customers sometimes value increased or
specific functionality over standardization and interchangeability, in my
experience they will always opt for the more widely interoperable product
when it meets their needs.  There is an inherent value in a strict standards
process.

> The point is thus, that the main value of Radius is in what the protocol
> does and not entirely in in how it does it.

I disagree heartily.  The value in RADIUS (as defined in the Standard-Track
RFC series) is exactly in how it does it, at least in terms of all of the
on-the-wire encodings.  That's what differentiates a standard protocol from
a proprietary protocol.

> With the BCP, without a reference to "historic" or some other term
> to describe that server segment, we're constraining the "how" for all
> time to come without giving a path to evolve the "what".

I don't think that the RADEXT WG is chartered to deprecate "traditional"
RADIUS, and its on-the-wire data model, to "historic" status.  I will point
out that the RADEXT WG indeed *has* a mechanism for changing the "how".
That mechanism is the RADIUS Extended Attribute document.

My guess as to why that mechanism isn't universally seen as "the way
forward" is that (a) the draft is currently stagnant, for lack of editorial
initiative, and (b) there are already implementations of the advanced
features using the traditional attribute format, in some cases in a way that
the BCP would not recommend.

We can easily address the former issue, by redirecting some energy from this
debate toward finishing the RADIUS Extended Attributes document.
Unfortunately, I see no easy way to alleviate the latter issue.  Well, there
*is* a way, I suppose, and that's to limit the scope of applicability of the
BCP.  I don't believe that's the "right 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/>