Subject: [radext] #12: Applicability

From: "radext issue tracker" <[email-masked]>
Date: Thu, 13 May 2010 22:31:16 -0000

#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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "radext issue tracker" <[email-masked]>
Date: Fri, 14 May 2010 06:37:54 -0000

#12: Applicability
----------------------------------------+-----------------------------------
 Reporter:  avi@…                       |        Owner:  aland@…                  
     Type:  defect                      |       Status:  closed                   
 Priority:  blocker                     |    Milestone:  milestone1               
Component:  design                      |      Version:  1.0                      
 Severity:  Submitted WG Document       |   Resolution:  fixed                    
 Keywords:                              |  
----------------------------------------+-----------------------------------
Changes (by aland@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 All comments have been addressed in -11, -12, and -13 revisions of the
 document

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/12#comment:1>
radext <http://tools.ietf.org/radext/>