Subject: Proposal for resolution of Issue 327: Applicability

From: Bernard Aboba <[email-masked]>
Date: Sun, 14 Feb 2010 13:31:10 -0800

The concerns expressed in Issue 327 appear to apply to Sections 1, 1.3, 3.1.2, 3.1.3 and 3.1.4. 

Here is a proposed resolution.  Comments welcome. 

Section 1

   This document provides guidelines for the design of
RADIUS attributes

   both within the IETF as well as within other SDOs.  By
articulating

   RADIUS design guidelines, it is hoped that this document
will

   encourage the development and publication of high quality
RADIUS

   attribute specifications.

   However, the advice in this document will not be helpful
unless it is

   put to use.  As with "Guidelines for Authors and
Reviewers of MIB

   Documents" [RFC4181], it is expected that this document
will be used

   by authors to check their document against the guidelines
prior to

   requesting review (such as an "Expert Review"
described in

   [RFC3575]).  Similarly, it is expected that this document
will used

   by reviewers (such as WG participants or the AAA Doctors
[DOCTORS]),

   resulting in an improvement in the consistency of
reviews.

   In order to meet these objectives, this document needs to
cover not

   only the science of attribute design, but also the art. 
Therefore,

   in addition to covering the most frequently encountered
issues, this

   document attempts to provide some of the considerations
motivating

   the guidelines.

   In order to characterize current attribute usage, both
the basic and

   complex data types defined in the existing RADIUS RFCs
are reviewed.

[BA] Proposed
change is to replace Section 1 with the following:

   "This document provides guidelines for the design of
RADIUS attributes

   used to encode service-provisioning or authentication
data, 

   based on the data model and attribute formats defined in
RFC 2865 and

   subsequent RADIUS RFCs.   In order to characterize
current attribute 

   usage, both the basic and complex data types defined in
the existing 

   RADIUS RFCs are reviewed. Since the RADEXT WG is
currently considering

   extensions to the RADIUS data model and attribute
formats, 

   future documents may extend the data model and guidelines
provided here.

   In order to meet these objectives, this document needs to
cover not

   only the science of attribute design, but also the art. 
Therefore,

   in addition to covering the most frequently encountered
issues, this

   document attempts to provide some of the considerations
motivating

   the guidelines.

   RADIUS protocol changes, or specification of attributes 

   (such as Service-Type) that can be used to, in effect,
provide 

   new RADIUS commands require greater expertise and deeper
review, 

   as do changes to the RADIUS operational model as
discussed in Section 

   3.3.  As a result, such changes are outside the scope of
this

   document and MUST NOT be undertaken outside the IETF. 
Registration policies

   for RADIUS parameters are discussed in [RFC3575] Section
2.1." 

1.3.  Applicability

   As RADIUS has become more widely accepted as a management
protocol,

   its usage has become more prevalent, both within the IETF
as well as

   within other SDOs.  Given the expanded utilization of
RADIUS, it has

   become apparent that requiring SDOs to accomplish all
their RADIUS

   work within the IETF is inherently inefficient and
unscalable.  By

   articulating guidelines for RADIUS attribute design, this
document

   enables SDOs out of the IETF to design their own RADIUS
attributes

   within the Vendor-Specific Attribute (VSA) space.

   It is RECOMMENDED that SDOs follow the guidelines
articulated in this

   document.  Doing so will ensure the widest possible
applicability and

   interoperability of the specifications, while requiring
minimal

   changes to existing systems.  Specifications that do not
follow the

   guidelines articulated herein are NOT RECOMMENDED. 
However, we

   recognize that there are some situations where SDOs or
vendors

   require the creation of specifications not following these

   guidelines.  We do not forbid these specifications, but
it is

   RECOMMENDED that they are created only if they have a
limited scope

   of applicability, and all attributes defined in those
specifications

   are VSAs, as discussed Appendix A.5, below.

   It is RECOMMENDED that SDOs and vendors seek review of
RADIUS

   attribute specifications from the IETF.  However, when
specifications

   are SDO specific, re-use existing data types, and follow
these

   guidelines, they do not require IETF review.

   In order to enable IETF review of such specifications,
the authors

   recommend that:

      * SDOs make their RADIUS attribute specifications
publicly

      available;

      * SDOs request review of RADIUS attribute
specifications by

      sending email to the AAA Doctors [DOCTORS] or
equivalent mailing

      list;

      * IETF and SDO RADIUS attribute specifications are
reviewed

      according to the guidelines proposed in this document;

      * Reviews of specifications are posted to the RADEXT
WG mailing

      list, the AAA Doctors mailing list [DOCTORS] or
another IETF

      mailing list suggested by the Operations &
Management Area

      Directors of the IETF.

   These reviews can assist with creation of specifications
that meet

   the SDO requirements, and which are also compatible with
the

   traditional data model and uses of RADIUS.  While these
reviews

   require access to public specifications, the review
process does not

   require publication of an IETF RFC.

   The advice in this document applies to attributes used to
encode

   service-provisioning or authentication data.  RADIUS
protocol

   changes, or specification of attributes (such as
Service-Type) that

   can be used to, in effect, provide new RADIUS commands
require

   greater expertise and deeper review, as do changes to the
RADIUS

   operational model as discussed below in Section 3.3. 
Such changes

   MUST NOT be undertaken outside the IETF and when handled
within the

   IETF require "IETF Consensus" for adoption, as
noted in [RFC3575]

   Section 2.1.

[BA] Proposed change is to replace Section 1.3 with the following: 

   "   As RADIUS has become more widely accepted as a
management protocol,

   its usage has become more prevalent, by vendors as well
as the IETF and

  other SDOs.  By articulating RADIUS design guidelines, it
is hoped that

   this document will encourage the development and
publication of 

   high quality RADIUS attribute specifications.  As with
"Guidelines 

   for Authors and Reviewers of MIB Documents"
[RFC4181], it is 

   expected that this document will be used by authors to
check their 

   document against the guidelines prior to requesting
review 

   (such as an "Expert Review" described in

   [RFC3575]).  Similarly, it is expected that this document
will used

   by reviewers (such as WG participants or the AAA Doctors
[DOCTORS]),

   resulting in an improvement in the consistency of
reviews.

   The guidelines articulated in this document enable the
design

   of attributes with the widest possible interoperability,

   while requiring minimal changes to existing systems.

   As a result, they are suitable for application to
attributes 

   designed for general usage.  It is RECOMMENDED 

   that these guidelines be applied to review of documents 

   requesting allocations within the IETF standard attribute

   space defined in [RFC2865]. 

   These guidelines may also prove useful in the design of 

   attributes within the Vendor-Specific Attribute (VSA)

   space.  As noted in RFC 2865 Section 5.26, RADIUS VSAs 

   were created "to allow vendors to support their own
extended 

   Attributes not suitable for general usage."  

   Rather than requesting allocation of standard attributes

   for those uses, [RFC2865] Section 6.2 notes that
utilization

   of VSAs "should be encouraged instead of allocation
of global 

   attribute types, for functions specific only to one
vendor's 

   implementation of RADIUS, where no interoperability is
deemed useful." 

   However, experience has shown that attributes not
originally 

   designed for general usage can subsequently garner
wide-spread 

   deployment.  An example is the vendor-specific attributes

   defined in [RFC2548], which have been widely implemented 

   within IEEE 802.11 Access Points. 

   As a result, while SDOs and vendors MAY choose to create 

   specifications not following these guidelines for use in

   scenarios within a limited scope of applicability,

   where general usage is possible,  adhering to the 

   design guidelines is RECOMMENDED.  Discussion of

   vendor allocations is provided in Section 3.1.2; 

   discussion of SDO allocations is provided in Section

   3.1.3.   SDOs and vendors desiring review of their 

   specifications by the IETF are encouraged to follow 

   the advice presented in Section 3.1.4." 

3.1.2.  Vendor Allocations

   Vendor RADIUS Attribute specifications SHOULD allocate
attributes

   from the vendor space, rather than requesting an
allocation from the

   RADIUS standard attribute space.

   As discussed in [RFC2865] Section 5.26, the vendor space
is intended

   for vendors to support their own Attributes not suitable
for general

   use.  However, it is RECOMMENDED that vendors follow the
guidelines

   outlined here, which are intended to enable maximum
interoperability

   with minimal changes to existing systems.

   Following these guidelines means that RADIUS servers can
be updated

   to support the vendor's equipment by editing a RADIUS
dictionary.  If

   these guidelines are not followed, then the vendor's
equipment can

   only be supported via code changes in RADIUS server
implementations.

   Such code changes add complexity and delay to
implementations.

[BA] Proposed change is to replace Section 3.1.2 with the following:

"  As noted in [RFC3575] Section 2.1, vendors are
encouraged

   to utilize VSAs to define functions "specific only
to one vendor's

   implementation of RADIUS, where no interoperability is
deemed useful.

   For functions specific only to one vendor's
implementation of RADIUS,

   the use of that should be encouraged instead of the
allocation of

   global attribute types."

   Nevertheless, following the guidelines outlined within
this document

   has several advantages, including maximum
interoperability with

   minimal changes to existing systems.  Following these
guidelines 

   means that RADIUS servers can be updated to support the
vendor's 

   equipment by editing a RADIUS dictionary.  If these
guidelines are 

   not followed, then the vendor's equipment can only be
supported 

   via code changes in RADIUS server implementations.

   Such code changes add complexity and delay to
implementations."

3.1.3.  SDO Allocations

   SDO RADIUS Attribute specifications SHOULD allocate
attributes from

   the vendor space, rather than requesting an allocation
from the

   RADIUS standard attribute space, for attributes matching
any of the

   following criteria:

      * attributes relying on data types not defined within
RADIUS

      * attributes intended primarily for use within an SDO

      * attributes intended primarily for use within a group
of SDOs.

   Any new RADIUS attributes or values intended for
interoperable use

   across a broad spectrum of the Internet Community SHOULD
follow the

   normal IETF process, and SHOULD result in allocations
from the RADIUS

   standard space.

   The recommendation for SDOs to allocate attributes from a
vendor

   space rather than via the IETF process is a recognition
that SDOs may

   desire to assert change control over their own RADIUS
specifications.

   This change control can be obtained by requesting a PEC
from the

   Internet Assigned Number Authority (IANA), for use as a
Vendor-Id

   within a Vendor-Specific attribute.  Further allocation
of attributes

   inside of the VSA space defined by that Vendor-Id is
subject solely

   to the discretion of the SDO.  Similarly, the use of data
types

   (complex or not) within that VSA space is solely under
the discretion

   of the SDO.  It is RECOMMENDED that SDOs follow the
guidelines

   outlined here, which are intended to enable maximum
interoperability

   with minimal changes to existing systems.

   It should be understood that SDOs do not have to rehost
VSAs into the

   standards space solely for the purpose of obtaining IETF
review.

   Rehosting puts pressure on the standards space, and may
be harmful to

   interoperability, since it can create two ways to
provision the same

   service.  Rehosting may also require changes to the
RADIUS data model

   which will affect implementations that do not intend to
support the

   SDO specifications.

[BA] Proposed change is to replace Section 3.1.3 with the following:

"  Given the expanded utilization of RADIUS, it has

   become apparent that requiring SDOs to accomplish all
their RADIUS

   work within the IETF is inherently inefficient and
unscalable.  

  SDO RADIUS Attribute specifications SHOULD allocate
attributes from

   the vendor space, rather than requesting an allocation
from the

   RADIUS standard attribute space, for attributes matching
any of the

   following criteria:

      * attributes relying on data types not defined within
RADIUS

      * attributes intended primarily for use within an SDO

      * attributes intended primarily for use within a group
of SDOs.

   Allocation of new RADIUS attributes or values intended
for interoperable use

   across a broad spectrum of the Internet Community SHOULD
follow the

   allocation process defined in [RFC3575]. 

   The recommendation for SDOs to allocate attributes from
the vendor

   space rather than via the IETF process recognizes the
need for SDOs

   to assert change control over their own RADIUS
specifications.

   SDOs desiring to define their VSAs are encouraged to 

   request allocation of a Private Enterprise Code (PEC)
from the

   Internet Assigned Number Authority (IANA), for use as a
Vendor-Id.  

   The SDO can then allocate attributes within the VSA space
defined 

   by that Vendor-Id, at their sole discretion.  Similarly,
the use of 

   data types (complex or otherwise) within that VSA space
is solely

   under the discretion of the SDO."

3.1.4.  Publication of specifications

   SDOs are encouraged to seek early review of SSA
specifications by the

   IETF.  This review may be initiated by sending mail to
the AAA

   Doctors list [DOCTORS], with the understanding that this
review is a

   voluntary-based service offered on best-effort basis. 
Since the IETF

   is not a membership organization, in order to enable the
RADIUS SSA

   specification to be reviewed, it is RECOMMENDED that it
be made

   publicly available; this also encourages interoperability. 
Where the

   RADIUS SSA specification is embedded within a larger
document which

   cannot be made public, the RADIUS attribute and value
definitions

   SHOULD be published instead as an Informational RFC, as
with

   [RFC4679].  This process SHOULD be followed instead of
requesting

   IANA allocations from within the standard RADIUS
attribute space.

   Similarly, vendors are encouraged to make their
specifications

   publicly available, for maximum interoperability. 
However, it is not

   necessary for them to request publication of their VSA
specifications

   as Informational RFCs by the IETF.

   All other specifications, including new authentication,

   authorization, and/or security mechanisms SHOULD be
allocated via the

   standard RADIUS space, as noted in [RFC3575] Section 2.1.

[BA] Proposed change is to replace Section 3.1.4 with the following:

"  SDOs or vendors desiring review of their RADIUS
specifications 

   by the IETF are  encouraged to seek review as early as
possible, 

   so as to avoid potential delays.  Since reviews are
handled by volunteers, 

   responses are provided on a best-effort basis, with no
service

   level guarantees.   In order to provide reviewers with
access to the

   specification,  SDOs and vendors are encouraged to make
them publicly available.

   Where the RADIUS specification is embedded within a
larger document which

   cannot be made public, the RADIUS attribute and value
definitions

   can be made available on a public web site or can be
published as 

   an Informational RFC, as with [RFC4679]. 

   Review can be requested by sending email to the AAA
Doctors [DOCTORS]

   or equivalent mailing list.  The IETF Operations &
Management

   Area Directors will then arrange for the review to be

   completed and posted to the AAA Doctors mailing list

   [DOCTORS], RADEXT WG mailing list, or other IETF mailing

   list.  

   The review process requires neither allocation of
attributes 

   within the IETF standard attribute space nor publication
of an 

   IETF RFC.  Requiring SDOs or vendors to rehost VSAs into
the IETF standards 

   attribute space solely for the purpose of obtaining
review

   would put pressure on the standards space, and may be
harmful to

   interoperability, since it can create two ways to
provision the same

   service.  Rehosting may also require changes to the
RADIUS data model

   which will affect implementations that do not intend to
support the

   SDO or vendor specifications."

---

From: "Dave Nelson" <[email-masked]>
Date: Sun, 14 Feb 2010 21:07:03 -0500

Bernard Aboba writes...

> Here is a proposed resolution.  Comments welcome.

I think this is helpful.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>