Subject: [radext] #27: Section 1.3

From: "radext issue tracker" <[email-masked]>
Date: Sun, 20 Jun 2010 23:34:50 -0000

#27: Section 1.3
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  critical                   |   Milestone:  milestone1
Component:  design                     |     Version:  1.0       
 Severity:  Submitted WG Document      |    Keywords:            
---------------------------------------+------------------------------------
 Section 1.3 needs to describe the situations in which this document
 applies.  As discussed as part of the resolution of Issue 327, there are
 situations where vendors and SDOs will choose to not satisfy the
 guidelines.  Also, there is other work in progress (e.g. Extended
 Attributes).

 My recommendation is to replace Section 1.3 with the following:

 1.3 Applicability

    The advice in this document applies to attributes used to
    encode service-provisioning, authentication, or accounting data,
    based on the attribute encodings and data formats defined in RFC 2865
    [RFC2865], RFC 2866 [RFC2866] and subsequent RADIUS RFCs.

    Since this document represents a Best Current Practice, it does not
    update or deprecate existing standards.  As a result, the uses of
    the terms "MUST" and "MUST NOT" are limited to requirements already
    present in existing documents.

    It is RECOMMENDED that these guidelines be followed for all new RADIUS
    specifications, whether they originate from a vendor, an SDO, or the
 IETF.
    Doing so will ensure the widest possible applicability and
 interoperability
    of the specifications, while requiring minimal changes to existing
 systems.
    In particular, it is expected that RADIUS specifications requesting
    allocation within the standards space will follow these guidelines,
    and will explain why this is not possible if they cannot.

    However, there are situations in which vendors or SDOs can choose not
    to follow these guidelines without major consequences.  As noted in
    [RFC2865] Section 5.26, Vendor-Specific Attributes (VSAs) are
    "available to allow vendors to support their own extended Attributes
 not
    suitable for general usage."  Where vendors or SDOs develop
    specificatons "not suitable for general usage", limited
 interoperability
    and inability to use existing implementations may be acceptable and
    in these situations, vendors and SDOs MAY NOT choose to conform to
 these
    guidelines.

    Note that the RADEXT WG is currently involved in the development of an
    Extended Attributes specification [EXTEN].  This specification, when
    completed, will provide its own usage guidelines.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/27>
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: Mon, 21 Jun 2010 03:35:13 -0000

#27: Section 1.3
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  aland@…                  
     Type:  defect                     |      Status:  new                      
 Priority:  critical                   |   Milestone:  milestone1               
Component:  design                     |     Version:  1.0                      
 Severity:  Submitted WG Document      |    Keywords:                           
---------------------------------------+------------------------------------
Changes (by bernard_aboba@…):

  * owner:  => aland@…

Comment:

 Please add the following paragraph to the end of Section 1.3:

    RADIUS protocol changes, or specification of attributes (such as
    Service-Type) that can, in effect, provide new RADIUS commands
    require greater expertise and deeper review, as do changes to the
    RADIUS operational model.  As a result, such changes are outside the
    scope of this document and MUST NOT be undertaken outside the IETF.

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

---

From: "Dave Nelson" <[email-masked]>
Date: Mon, 21 Jun 2010 07:38:44 -0400

>     However, there are situations in which vendors or SDOs can choose
>     not to follow these guidelines without major consequences.  As
>     noted in [RFC2865] Section 5.26, Vendor-Specific Attributes (VSAs)
>     are "available to allow vendors to support their own extended 
>     Attributes not suitable for general usage."  Where vendors or 
>     SDOs develop specifications "not suitable for general usage",
>     limited interoperability and inability to use existing 
>     implementations may be acceptable and in these situations, 
>     vendors and SDOs MAY NOT choose to conform to these
>     guidelines.

I have always felt that the notion of placing other SDOs on the same plane
as vendors is a silly one.  I believe I know what motivates this treatment.
It seems to me to be a compromise to assuage those RADIUS practitioners who
are active in other SDOs and who have continually been critical of this WG's
attempts to define a reasonably rigorous set of attribute design criteria.
The point of *any* SDO is to define interoperable standards for multiple
vendors to use, to promote multi-vendor interoperability in implementations
and deployments.  To suggest that SDOs, other than the IETF, do not require
multi-vendor interoperability in their standards seems to devalue their
work.

I think that there should be a three tier scheme for recommended compliance
with these guidelines, not two tier.  I believe that non-IETF SDOs should be
held to a higher level of expectations than single vendors, but lower that
the IETF itself.

---

From: "radext issue tracker" <[email-masked]>
Date: Mon, 21 Jun 2010 14:59:40 -0000

#27: Section 1.3
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:  aland@…                  
     Type:  defect                     |       Status:  closed                   
 Priority:  critical                   |    Milestone:  milestone1               
Component:  design                     |      Version:  1.0                      
 Severity:  Submitted WG Document      |   Resolution:  fixed                    
 Keywords:                             |  
---------------------------------------+------------------------------------
Changes (by bernard_aboba@…):

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

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