Proposal for resolution of Issue 327: Applicability

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."