Subject: I-D Action:draft-ietf-radext-design-13.txt

From: [email-masked]
Date: Wed, 14 Apr 2010 05:15:03 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, A. DeKok
	Filename        : draft-ietf-radext-design-13.txt
	Pages           : 40
	Date            : 2010-04-14

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-13.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 14 Apr 2010 14:54:40 +0200

> 	Filename        : draft-ietf-radext-design-13.txt

  See also the 'diff' available at:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-radext-design-13.txt

  This revision incorporates suggestions from all open issues, including
#327.

  Please provide feedback.

  Alan DeKok.

--
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/>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 15 Apr 2010 09:06:26 -0700

Glancing at -13, there appear to be some inconsistencies within the text:

Section 1.3.1

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. 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 new attributes defined in those
specifications are VSAs. See Section 3, below, for additional
discussion of this topic.

It is RECOMMENDED that SDOs and vendors seek review of RADIUS
attribute specifications from the IETF. However, specifications do
not require IETF review when they satisfy all of the following
criteria:

* are SDO specific;

* reference attributes from pre-existing IETF or SDO
specifications;

* define new attributes only in the VSA space;

* use only the "basic data types" (see below) for all VSAs;

* follow the guidelines given in this document.

[BA] This text is similar to text in Section 3.3.3, which leads me to
believe that there was an editing problem.
My suggestion is that the text in 3.3.3 be moved to Section 1.3.1.

3.3.3. SDO Allocations

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. Is is therefore RECOMMENDED
that SDO RADIUS Attribute specifications 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
allocation process defined in [RFC3575].

The recommendation for SDOs to allocate attributes from a vendor
space rather than via the IETF process is a recognition that SDOs
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. 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.

Nevertheless, following the guidelines outlined within this document
has many advantages. It is therefore RECOMMENDED that SDOs follow
the guidelines outlined here, which are intended to enable maximum
interoperability with minimal changes to existing systems.

[BA] The last paragraph does not appear to be consistent with Section 1.3,
so I'd
recommend that it be deleted.

3.3.2. Vendor Allocations

Nevertheless, following the guidelines outlined within this document
has many advantages. It is therefore RECOMMENDED that vendors follow
the guidelines outlined here, which are intended to enable maximum
interoperability with minimal changes to existing systems. If these
guidelines are not followed, the result will be increased complexity
with little or no benefit.

[BA] The resolution to Issue 327 recommended the following alternative text:

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.3.4. Publication of specifications

In order to enable IETF review of SDO specifications, it is
RECOMMENDED 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.

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.

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.

SDOs are encouraged to seek early review of their specifications by
the IETF. It should be understood that reviews are a voluntary-based
service offered on best-effort basis.

Where the RADIUS 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 follow the
allocation process defined in [RFC3575].

[BA] The resolution to Issue 327 recommended the following alternative text:

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alan DeKok
> Sent: Wednesday, April 14, 2010 5:55 AM
> To: [email-masked]
> Subject: Re: I-D Action:draft-ietf-radext-design-13.txt
>

---

From: Alan DeKok <[email-masked]>
Date: Fri, 16 Apr 2010 16:36:05 +0200

> Glancing at -13, there appear to be some inconsistencies within the text:
...
> believe that there was an editing problem.

  The intent was to start off defining situations where SDOs did *not*
require review, and to later discuss situations where they did need review.

> My suggestion is that the text in 3.3.3 be moved to Section 1.3.1.

  Hmm... it's substantially similar to 3.3.2, but directed towards SDOs
rather than vendors.  I'd prefer to leave it where it is, but there are
arguments to be made both ways.

> recommend that it be deleted.

  I'm not sure what isn't consistent, but OK.

> [BA] The resolution to Issue 327 recommended the following alternative text:

  OK.  I was trying to avoid repeating the discussion on dictionaries
and code changes...

> 3.3.4. Publication of specifications
...
> [BA] The resolution to Issue 327 recommended the following alternative text:

  OK.

  Alan DeKok.