[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: Vendor Specifc Attribute Values
Hi,
On Fri, Jul 29, 2005 at 01:38:55PM -0400, Alan DeKok wrote:
> Bernard Aboba <aboba@internaut.com> wrote:
> > I think there is a basic issue with tackling this in the Issues &
> > Fixes document. Self-allocation of VSVs is a revision of RFC 3575
> > (RADIUS IANA Allocations Policy) and therefore would need to be a
> > standards track document, which the Issues & Fixes document is not.
>
> Hmm... good point.
>
> > RFC 3575 defines that attribute values can be allocated via
> > designated expert, with the exception of Service-Type, which
> > requires IETF Consensus. All allocations require a specification.
> > The allocation of Service-Type values was tightened because when it
> > was FCFS it had been used (by IEEE 802.11F) to define new RADIUS
> > commands outside the IETF process.
>
> I would say that vendor-specific extensions to the protocol are
> explicitely outside of the scope of the protocol, and things like "new
> RADIUS commands" are a misnomer. The vendor-extensions to RADIUS
> produce a protocol which is like RADIUS, but may not be interoperable
> with standard RADIUS solutions. Since this will happen no matter what
> we decide, I'd prefer to standardize the way to produce non-standard
> solutions.
Seconded!
> I don't have strong opinions about where the text goes, so long it
> goes somewhere, so we can avoid future discussions like the recent
> Authorize-Only issues.
Was it so bad? I think it may have been part of the input that made you
come up with the good idea above.
I don't regard a bit of protocol design philosophy now and then as a bad
thing, as long as it doesn't happen too often.
Cheers,
Emile.
--
E-Advies - Emile van Bergen emile@e-advies.nl
tel. +31 (0)70 3906153 http://www.e-advies.nl
--
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/>