[radext] #27: Section 1.3

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

#27: Section 1.3
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  critical                   |   Milestone:  milestone1
Component:  design                     |     Version:  1.0       
 Severity:  Submitted WG Document      |    Keywords:            
---------------------------------------+------------------------------------
 Section 1.3 needs to describe the situations in which this document
 applies.  As discussed as part of the resolution of Issue 327, there are
 situations where vendors and SDOs will choose to not satisfy the
 guidelines.  Also, there is other work in progress (e.g. Extended
 Attributes).

 My recommendation is to replace Section 1.3 with the following:

 1.3 Applicability

    The advice in this document applies to attributes used to
    encode service-provisioning, authentication, or accounting data,
    based on the attribute encodings and data formats defined in RFC 2865
    [RFC2865], RFC 2866 [RFC2866] and subsequent RADIUS RFCs.

    Since this document represents a Best Current Practice, it does not
    update or deprecate existing standards.  As a result, the uses of
    the terms "MUST" and "MUST NOT" are limited to requirements already
    present in existing documents.

    It is RECOMMENDED that these guidelines be followed for all new RADIUS
    specifications, whether they originate from a vendor, an SDO, or the
 IETF.
    Doing so will ensure the widest possible applicability and
 interoperability
    of the specifications, while requiring minimal changes to existing
 systems.
    In particular, it is expected that RADIUS specifications requesting
    allocation within the standards space will follow these guidelines,
    and will explain why this is not possible if they cannot.

    However, there are situations in which vendors or SDOs can choose not
    to follow these guidelines without major consequences.  As noted in
    [RFC2865] Section 5.26, Vendor-Specific Attributes (VSAs) are
    "available to allow vendors to support their own extended Attributes
 not
    suitable for general usage."  Where vendors or SDOs develop
    specificatons "not suitable for general usage", limited
 interoperability
    and inability to use existing implementations may be acceptable and
    in these situations, vendors and SDOs MAY NOT choose to conform to
 these
    guidelines.

    Note that the RADEXT WG is currently involved in the development of an
    Extended Attributes specification [EXTEN].  This specification, when
    completed, will provide its own usage guidelines.

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