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

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

Typo correction inline... 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wojciech Dec (wdec)
> Sent: 19 January 2010 10:40
> To: Dave Nelson; radiusext@ops.ietf.org
> Subject: RE: "Last Look" at the RADIUS Design Guidelines document
> 
>  
> 
> > -----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 
> 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 
*servers* do 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/>
> 

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