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

Re: Issue: Vendor Specifc Attribute Values



"Nelson, David" <dnelson@enterasys.com> wrote:
> Requested change:
> 
> Describe the practice.  Include recommendations for or against the
> practice, and standardize the recommend method of encoding, if the
> practice is encouraged.

  After a bit of searching, RFC 2882, section 2.2.1 documents this.

  I would recommend using the practice, and documenting the encoding
as defined above.

Proposed text:

  In addition to Vendor-Specific Attributes (VSA's), it is useful for
vendors to define custom values for previously defined attributes.
These values may be called Vendor-Specific Values (VSV's).  This
practice is encouraged, as it avoids overloading of existing values.
Given a choice between re-using an existing value in a context where
it may not be directly applicable, or defining a VSV, vendors SHOULD
define a new VSV.

   A summary of the Vendor-Specific Value format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Vendor-Id           |          Vendor-Value         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Id

      2 octets of the SMI Network Management Private Enterprise Code
      of the Vendor in network byte order, as defined in the "Assigned
      Numbers" RFC [6].

  Vendor-Value

      2 octets defining the vendor-specific value.

  VSV's MUST be defined only for attributes of type "integer", and
then only where the existing standards define one or more values for
the attribute.

  Note that the Vendor-Id is defined here as a 16-bit number, where it
is defined as a 32-bit number in the Vendor-Specific attribute.  This
choice may not be the best one, and is driven by the limitations of
the 32-bit integer field.

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