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 06:49
> To: radiusext@ops.ietf.org
> Subject: RE: "Last Look" at the RADIUS Design Guidelines document
> 
> > 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.
> 
> The primary intent is to promote *extension* of the RADIUS 
> protocol rather than *revision* of the RADIUS protocol.  That 
> is to say, to use well-accepted mechanisms for 
> forward-backward protocol extensions, rather than simply 
> revising the data model without any concern about 
> compatibility with existing deployments.  This is the way 
> that IETF-Standards track protocols are "evolved", via 
> extension, rather than via revision.  Certainly 
> interoperability with a broad range of implementations, some 
> of which may qualify for the term "legacy", is an important 
> factor.  That's one reason that vendors like to implement 
> standards -- they don't expect them to change in 
> non-backward-compatible ways over time.
> 
> There are examples of protocol revision in the IETF, of 
> course, such as IPv4 and IPv6, but that's not what we're 
> about here.  We already have RADIUS V2 and it's called Diameter.
> 
> I fail to understand the point of most of the arguments 
> against this BCP, unless it's to "protect" a "revised" 
> dialect of RADIUS as implemented in some "modern" RADIUS 
> server implementations.  If RADIUS has become fragmented into 
> non-interoperable dialects, I think that would be very sad 
> indeed.  In that case, I don't see the advantage of 

Woj> The BCP steers to protect more radius server *implementations* and
not protocol interoperability. That's evidenced by the talk of Radius
implementations of % figures in this thread.  
It's not unreasonable to expect that whoever wants to use a complex
attribute (against the recommendations of this BCP will at this stage)
will a) upgrade all their clients (1000s) and b) check their radius
server + make changes if needed. Given that a) is a task of several
orders of magnitude larger than b), it would seem that the stance to
protect old radius server implementations at all costs is highly
unbalanced. 
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. 
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. 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".

-Woj.

> legitimizing that fragmentation by trying to "gut" the core 
> recommendations of this BCP or to narrow its scope to some 
> "legacy" or "historic" segment of the RADIUS server market.  
> It seems to me that's where this discussion is ultimately leading us.
> 
> Have I missed an important point somewhere?
> 
> 
> 
> --
> 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/>