[radext] #29: Section 2

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

#29: Section 2
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  critical                   |   Milestone:  milestone1
Component:  design                     |     Version:            
 Severity:  Submitted WG Document      |    Keywords:            
---------------------------------------+------------------------------------
 Section 2 currently repeats text from other sections and utilizes MUST n
 MUST NOT normative language outside the bounds suggested in RFC 2119.

 A suggested rewrite is as follows:

 2. Guidelines

    The Remote Authentication Dial In User Service (RADIUS) defined in
    [RFC2865] and [RFC2866] uses elements known as attributes in order to
    represent authentication, authorization and accounting data.

    Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does
    not define a formal data definition language.  The data type of
    RADIUS attributes is not transported on the wire.  Rather, the data
    type of a RADIUS attribute is fixed when an attribute is defined.
    Based on the RADIUS attribute type code, RADIUS clients and servers
    can determine the data type based on preconfigured entries within a
    data dictionary.

    To explain the implications of this early RADIUS design decision we
    distinguish two types of data types, namely "basic" and "complex".
    Basic data types use one of the existing RADIUS data types as defined
    below, encapsulated in a RADIUS attribute or VSA.  All other data
    formats are "complex types".

    RADIUS attributes can be classified into three broad categories:

       * Attributes that are of interest to a single vendor, e.g., for a
         product or product line.  Minimal cross-vendor interoperability
         is needed.  Vendor-Specific Attributes (VSAs) are appropriate
         for this purpose.  Code-point allocation is managed by each
         vendor, with the number space defined by their Private Enterprise
         Number (PEN).

       * Attributes that are of interest to an industry segment, where an
         SDO defines the attributes for that industry.  Multi-vendor
         interoperability within an industry segment is expected.

         Vendor-Specific Attributes (VSAs) are appropriate for
         use in this situation.  Code-point allocation is managed by
         the SDO with the number space defined by the SDO's PEN,
         rather then the PEN of an individual vendor.

       * Attributes that are of broad interest to the Internet Community.
         Multi-vendor interoperability is expected.

         Attributes within the standards space are appropriate for this
         purpose, and are allocated via IANA as described in [RFC3575].
         Since the standards space represents a finite resource,
         and is the only attribute space available for use by IETF working
 groups,
         vendors and SDOs are encouraged to utilize the VSA space, rather
 than
         requesting allocation of attributes from the standards space.
         Self-allocation of standards attributes is considered anti-social
         behavior and is strongly discouraged.

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