RE: Strawman RADIUSEXT WG charter - Take Three

[Avi Lior <avi@bridgewatersystems.com>]

I get your point -- but supposing I was to adopt your IEEE standard and then
wanted changes done.  Nothing compels the IEEE to address my concerns.  At
least at the IETF I can do something about it.

So for example, if the VSAs belonged to the WiFi Alliance well I would have
to pay $25K to have a voice there.

So you are right, it is all about who and how ;-)

> -----Original Message-----
> From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul.congdon@hp.com] 
> Sent: August 27, 2003 4:16 PM
> To: 'Avi Lior'; 'Bernard Aboba'
> Cc: 'radiusext@ops.ietf.org'
> Subject: RE: Strawman RADIUSEXT WG charter - Take Three
> 
> 
> 
> 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/>