Re: Guidelines suggested text for checklist:

["Bernard Aboba" <bernard_aboba@hotmail.com>]

>   That appears to be backwards from your first comment.  Maybe SHOULD.
> allocate from vendor-specific, or else IANA if wider inter-operability
> is desired.

Here is what RFC 3575 says about value allocations:

  Certain attributes (for example, NAS-Port-Type) in RADIUS define a
  list of values to correspond with various meanings.  There can be 4
  billion (2^32) values for each attribute.  Additional values can be
  allocated by the Designated Expert.  The exception to this policy is
  the Service-Type attribute (6), whose values define new modes of
  operation for RADIUS.  Values 1-16 of the Service-Type attribute have
  been allocated.  Allocation of new Service-Type values are by IETF
  Consensus.  The intention is that any allocation will be accompanied
  by a published RFC.

Given this, a vendor or SDO can request allocation of a value by "Designated 
Expert", unless we are talking about a value that can be used to create new 
commands (e.g. Service-Type).  Given this, I'm not sure why it would be 
desirable for an SDO to create a VSA for a normal value allocation.

If we are talking about creation of new commands, that is a major protocol 
change whether it is occurring via VSAs or new values -- and I'd suggest 
that this is the kind of "extension" that is outside the scope of the 
document.



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