[radext] #32: Section 2.2

["radext issue tracker" <trac@tools.ietf.org>]

#32: Section 2.2
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  minor                      |   Milestone:  milestone1
Component:  design                     |     Version:  1.0       
 Severity:  Submitted WG Document      |    Keywords:            
---------------------------------------+------------------------------------
 As noted in this Section, VSA data formats are under the sole discretion
 of SDOs and vendors.  This point should be made up front.

 Recommended change is to replace Section 2.2 with the following:

  2.2. Vendor-Specific Attribute Space

    The Vendor-Specific Attribute space is defined to be the contents of
    the "String" field of the Vendor-Specific Attribute ([RFC2865]
    Section 5.26).  As discussed there, it is intended for vendors and
    SDOs to support their own Attributes not suitable for general use.

    While the encoding of attributes within the vendor space is under
    the control of vendors and SDOs, following the guidelines described
    here is advantageous since it enables maximum interoperability with
    minimal changes to existing systems.

    For example, RADIUS server support for new attributes using
    "basic data types" can typically be accomplished by editing
    a RADIUS dictionary, whereas "complex data types" typically
    require RADIUS server code changes, which can add complexity
    and delays in implementation.

    Vendor RADIUS Attribute specifications SHOULD self-allocate
    attributes from the vendor space, rather than requesting an
    allocation (or self-allocating) from within the RADIUS
    standard attribute space.

    VSA encodings that do not follow the [RFC2865] Section 5.26
    scheme are NOT RECOMMENDED.  Although [RFC2865] does not mandate it,
    implementations commonly assume that the Vendor Id can be used as a
    key to determine the on-the-wire encoding of a VSA.  Vendors
    therefore SHOULD NOT use multiple encodings for VSAs that are
    associated with a particular Vendor Id.  A vendor wishing to use
    multiple VSA encodings SHOULD request one Vendor Id for each VSA
    encoding that they will use.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/32>
radext <http://tools.ietf.org/radext/>


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