|
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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On > Behalf Of Alan DeKok > Sent: Wednesday, April 14, 2010 5:55 AM > To: radiusext@ops.ietf.org > Subject: Re: I-D Action:draft-ietf-radext-design-13.txt > > Internet-Drafts@ietf.org wrote: > > 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 > > 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://psg.com/lists/radiusext/> |