[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue: Vendor Specifc Attribute Values



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.

  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.

  Alan DeKok.

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