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

["Wojciech Dec (wdec)" <wdec@cisco.com>]

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Dave Nelson
> Sent: 19 January 2010 14:39
> To: radiusext@ops.ietf.org
> Subject: RE: "Last Look" at the RADIUS Design Guidelines document
> 
> > 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.

I think you're confusing protocol with implementation. An interoperable
protocol and a standard implementation are different things. One can
(and does!) have plenty of protocols that are multi-vendor
interoperabile without a standardized implementation, and one can have a
standard implementation that is NOT interoperable (case in hand, Radius
server implementation A does not support attribute Z which another
radius server implemented in the same way does).
To say it differently, whether one codes up a Radius server to use a
data-type cast dictionary or not, it is not what makes the server
interoperable with other Radius devices. 
> 
> > 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.

I see no point in defending an *implementation* as a standard, why do
you?

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

As per my corrected mail, I meant "how Radius servers do it" (is the
"how" that doesn't matter)

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

Well, I don't think anyone proposed that. Instead, the proposal at least
as I understood it to be (and support), is that the design guidelines
should not be used as bar/ban/stick on complex attributes design and
should have text to that effect. And, as already pointed out by Avi,
placing such work in the extended attribute doc without any change to
the current wording of the BCP is an issue.
> 
> 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.

An old IETF mantra used to say that running code matters. The fact that
there are multi-vendor production networks that use a galore of complex
attributes, albeit custom defined is perhpas evidence to how off-course
the WG has gone in this area. It would be nice to give the customizers
some structure/guidance instead...

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

The current set-up looks like to me like this: During the (undoubtedly
lengthy) discussions around complex attributes under the "extended
attributes" banner, someone will claim "these attributes don't work with
my foobar radius server implementation and are against the BCP of the WG
itself". Even after such design, one will have a BCP that says one thing
and another doc something else. This will be confusing to anyone trying
to make sense of it.
Why don't you see this as an issue?

-Woj.

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