[radext] #34: Section 2.4

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

#34: Section 2.4
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  major                      |   Milestone:  milestone1
Component:  design                     |     Version:  1.0       
 Severity:  Submitted WG Document      |    Keywords:            
---------------------------------------+------------------------------------
 The first paragraph of Section 2.4 appears to refer to a missing quotation
 from RFC 2865 Section 5.26.

 Recommended text for Section 2.4 is as follows:

 2.4. Translation of Vendor Specifications

   [RFC2865] Section 5.26 defines Vendor-Specific attributes as follows:

       This Attribute is available to allow vendors to support their own
       extended Attributes not suitable for general usage.  It MUST not
       affect the operation of the RADIUS protocol.

       Servers not equipped to interpret the vendor-specific information
       sent by a client MUST ignore it (although it may be reported).
       Clients which do not receive desired vendor-specific information
       SHOULD make an attempt to operate without it, although they may do
       so (and report they are doing so) in a degraded mode.

    The limitation on changes to the RADIUS protocol effectively
    prohibits VSAs from changing fundamental aspects of RADIUS operation,
    such as modifying RADIUS packet sequences, or adding new commands.
    However, the requirement for clients and servers to be able to
    operate in the absence of VSAs has proven to be less of a constraint,
    since it is still possible for a RADIUS client and server to mutually
    indicate support for VSAs, after which behavior expectations can be
    reset.

    Therefore, RFC 2865 provides considerable latitude for development of
    new attributes within the vendor space, while prohibiting development
    of protocol variants.  This flexibility implies that RADIUS
    attributes can often be developed within the vendor space without
    loss (and possibly even with gain) in functionality.

    As a result, translation of RADIUS attributes developed within the
    vendor space into the standard space may provide only modest
    benefits, while accelerating the exhaustion of the standard attribute
    space.  We do not expect that all RADIUS attribute specifications
    requiring interoperability will be developed within the IETF, and
    allocated from the standards space.  A more scalable approach is to
    recognize the flexibility of the vendor space, while working toward
    improvements in the quality and availability of RADIUS attribute
    specifications, regardless of where they are developed.

    It is therefore NOT RECOMMENDED that specifications intended solely
    for use by a vendor or SDO use be translated into the standard space.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/34>
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/>