[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Strawman RADIUSEXT WG charter - Take Three
This is no different than the development of any other specification. If
the definitive document is an IETF document then it must follow IETF rules.
If the IEEE doesn't like the direction being taken in the IETF they must
interject as anyone would following IETF rules of engagement. I'm not sure
this is any different than how MIBs are cross developed either.
Paul
> -----Original Message-----
> From: Avi Lior [mailto:avi@bridgewatersystems.com]
> Sent: Wednesday, August 27, 2003 8:10 PM
> To: 'CONGDON,PAUL (HP-Roseville,ex1)'; Avi Lior; 'Bernard Aboba'
> Cc: 'radiusext@ops.ietf.org'
> Subject: RE: Strawman RADIUSEXT WG charter - Take Three
>
>
> 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/>