[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[radext] #12: Applicability
#12: Applicability
----------------------------------------+-----------------------------------
Reporter: avi@â | Owner: aland@â
Type: defect | Status: new
Priority: blocker | Milestone: milestone1
Component: design | Version: 1.0
Severity: Submitted WG Document | Keywords:
----------------------------------------+-----------------------------------
Date first submitted: January 22, 2010
Reference: http://ops.ietf.org/lists/radiusext/2010/msg00068.html
> If we were talking about VSAs, this wouldn't be a concern. We're talking
> about standards-tack attributes.
Okay then we should make sure that the document makes this clear.
The problem is the document talks about SDOs. SDO work on VSAs not
standard track attributes.
From the abstract we have:
"reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs)."
> If all you have to worry about is the
> class of "enhanced capability" RADIUS servers, then I would agree. In
the
> IETF, we need to take a broader view, I think.
Which is fine but I think you have to document this distinction. That is a
problem with this BCP only people who read these long email threads will
understand what is really going on.
The problem is the document talks about SDOs. SDO work on VSAs not
standard track attributes.
From the abstract we have:
"reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs)."
Not only it is not clear but also not true and I want it to be true ... In
section 3.1.1 there is text that contradicts what you say. Here it is:
"The design and specification of VSAs for multi-vendor usage SHOULD be
undertaken with the same level of care as standard RADIUS attributes.
Specifically, the provisions of this document that apply to standard
RADIUS attributes also apply to SSAs or VSAs for multi-vendor usage."
Please get rid of that text!
Also in 3.1.3 ....
It is RECOMMENDED that SDOs follow the guidelines
outlined here, which are intended to enable maximum interoperability
with minimal changes to existing systems.
Also since you already have an applicability section and you already make
the recommendations that SDOs and vendors follow this document -- you dont
need to repeat yourself over and over again. So please get rid of the
repeated text.
So reading the document with respect to SDOs....
In section 3.1.1 please remove the "stuff" related to SDO Specific
Attribute (SSA).
This is only going to create confusion. Either RADEXT formally adopts this
usage or not. I would argue that it is too late.
As a side note, [RFC2865] Section 5.26 uses the term "Vendor-Specific
Attribute" to refer to an encoding format which can be used by
individual vendors to define attributes not suitable for general
usage. However, since then VSAs have also become widely used by SDOs
defining attributes intended for multi-vendor interoperability. As
such, these attributes are not specific to any single vendor, and the
term "Vendor-Specific" may be misleading. An alternate term which
better describes this use case is SDO-Specific Attribute (SSA).
Thus in section 3.1.1 the last two paragraphs should go.
Back to applicability section 1.3
"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. ....
This is fine but the rest is problematic...
"
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."
By specification i assume that you mean SDO specifications. Right? well
you should state that.
Assuming that is correct then i have a problem with the text...
I dont think that the IETF has a say on whether they can prohibit or "not
recommend" or even recommend an SDO specification. I think you have
captured what needs to be captured in the previous part and also in the
following paragraph.
And also what does it mean that all the attributes are VSA.... you mean i
cant reuse an attribute such as User-Name as defined by 2865 in my SDO
specification. I don't agree with that.
[BA] Here is a proposal for addressing this issue:
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] The scope defined above isn't quite right. Suggested change:
"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] Suggested change:
" 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] Suggested change:
" 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] Suggested change:
" 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] Suggested change:
" 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."
[Bernard Aboba]
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."
--
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/12>
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/>