RE: Strawman RADIUSEXT WG charter - Take Three

[Avi Lior <avi@bridgewatersystems.com>]

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