RE: Strawman RADIUSEXT WG charter - Take Three

["CONGDON,PAUL (HP-Roseville,ex1)" <paul.congdon@hp.com>]

I could imagine official organizations defining their own VSAs and making
them standardized by writing appropriate RFCs to document them.  Since they
aren't truly an independent vendor, implementers shouldn't have the same
loss of control feeling you are talking about.  We are doing something
similar for IEEE 802.1AB (link layer discovery protocol).  We are allowing
other organizations to define their own attributes to exchange in the
protocol.  Thus, it might be possible to use VSAs to extend what might
otherwise be considered base attributes.   Its all about who and how they
are defined, not whether the occupy the base number space or not.

Paul

> -----Original Message-----
> From: Avi Lior [mailto:avi@bridgewatersystems.com] 
> Sent: Wednesday, August 27, 2003 9:27 AM
> To: 'Bernard Aboba'
> Cc: 'radiusext@ops.ietf.org'
> Subject: RE: Strawman RADIUSEXT WG charter - Take Three
> 
> 
> The other issues with VSA is that if I was an SDO I would not 
> want to standerdize my specification on someone elses VSAs.  
> I simply would not have control over these.
> 
> IMO, an SDO that wants to make something interoperable 
> outside their scope of control should define attributes using 
> base RADIUS attribute space. Hence these would be done using 
> RFCs and be reviewed in a WG such as RADIUSEXT.  Hence the 
> need to extend the base RADIUS Space.
> 
> So I agree with Bernard this is the best reason for having a 
> RADIUSEXT group.
> 
> This is what the plan is for prepaid.  While prepaid was 
> defined in the 3GPP2 specs using 3GPP2 specifications, the 
> authors of the draft want to use RADIUS base attributes.  
> Once this is approved in the IETF they would make the changes 
> in subsequent 3GPP2 specification.
> 
> 
> > -----Original Message-----
> > From: Bernard Aboba [mailto:aboba@internaut.com]
> > Sent: Monday, August 25, 2003 7:48 PM
> > To: Richard Perlman
> > Cc: Mark Jones; 'radiusext@ops.ietf.org'
> > Subject: Re: Strawman RADIUSEXT WG charter - Take Three
> > 
> > 
> > > As a practical matter, server vendors have to update code 
> regularly
> > > anyway because of new VSA implementations.  I think the 
> > question here
> > > is really whether we should simply accept new types, and possible
> > > reduce the pressure on new VSAs (but, as Bernard has noted 
> > in another
> > > posting, increasing the pressure on the "standard"
> > attributes) or just
> > > stay with VSAs as a way of accommodating the need for new types.
> > >
> > > Personally, I'd vote to leave it as-is and stick with the
> > well known,
> > > and imperfect VSA route.
> > 
> > The issue with VSAs is that they tend to be un or
> > under-documented, which creates problems in implementation or 
> > even in maintaining compatibility with Diameter.
> > 
> > Also, multiple VSAs are sometimes produced to handle the same
> > function in slightly different ways, which impacts interoperability.
> > 
> > Here's what RFC 2865, Section 6.2 says about VSAs:
> > 
> >    Note that RADIUS defines a mechanism for Vendor-Specific 
> extensions
> >    (Attribute 26) and the use of that should be encouraged 
> instead of
> >    allocation of global attribute types, for functions
> > specific only to
> >    one vendor's implementation of RADIUS, where no 
> interoperability is
> >    deemed useful.
> > 
> > The problem is that VSAs are used today even where
> > interoperability is required (as in SDO specifications).  The 
> > result is that those specifications may not obtain adequate review.
> > 
> > So perhaps the best argument for attribute expansion (and
> > perhaps even the existence of a RADIUSEXT WG) is that it 
> > would make it more likely that the review process envisaged 
> > in RFC 2865 will actually take place.
> > 
> > --
> > 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/>