Subject: [radext] #32: Section 2.2

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

#32: Section 2.2
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  minor                      |   Milestone:  milestone1
Component:  design                     |     Version:  1.0       
 Severity:  Submitted WG Document      |    Keywords:            
---------------------------------------+------------------------------------
 As noted in this Section, VSA data formats are under the sole discretion
 of SDOs and vendors.  This point should be made up front.

 Recommended change is to replace Section 2.2 with the following:

  2.2. Vendor-Specific Attribute Space

    The Vendor-Specific Attribute space is defined to be the contents of
    the "String" field of the Vendor-Specific Attribute ([RFC2865]
    Section 5.26).  As discussed there, it is intended for vendors and
    SDOs to support their own Attributes not suitable for general use.

    While the encoding of attributes within the vendor space is under
    the control of vendors and SDOs, following the guidelines described
    here is advantageous since it enables maximum interoperability with
    minimal changes to existing systems.

    For example, RADIUS server support for new attributes using
    "basic data types" can typically be accomplished by editing
    a RADIUS dictionary, whereas "complex data types" typically
    require RADIUS server code changes, which can add complexity
    and delays in implementation.

    Vendor RADIUS Attribute specifications SHOULD self-allocate
    attributes from the vendor space, rather than requesting an
    allocation (or self-allocating) from within the RADIUS
    standard attribute space.

    VSA encodings that do not follow the [RFC2865] Section 5.26
    scheme are NOT RECOMMENDED.  Although [RFC2865] does not mandate it,
    implementations commonly assume that the Vendor Id can be used as a
    key to determine the on-the-wire encoding of a VSA.  Vendors
    therefore SHOULD NOT use multiple encodings for VSAs that are
    associated with a particular Vendor Id.  A vendor wishing to use
    multiple VSA encodings SHOULD request one Vendor Id for each VSA
    encoding that they will use.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/32>
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: "Dave Nelson" <[email-masked]>
Date: Mon, 21 Jun 2010 08:06:11 -0400

>     SDOs to support their own Attributes not suitable for general use.

Once again, I don't support the conflation of vendors and SDOs.  We do want
non-IETF SDOs to use the VSA mechanism, primarily to conserve the scarce
pool of IANA-assigned code points.  However, I'm convinced that sending the
message that what another standards organization does is of no more
importance or consequence than the activity of a single vendor is a mistake.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 21 Jun 2010 14:30:02 +0200

> importance or consequence than the activity of a single vendor is a mistake.

  A single vendor still expects their equipment to be used in a wide
variety of circumstances.  Experience shows that vendors who have
significant sales can have their non-standard formats adopted by all
major RADIUS servers.

  The same applies to SDOs.

  I think that the discussion about "not suitable for general use" is
really "not suitable for standardization through the IETF".  As such,
vendors and SDOs fall into the same non-IETF category.

  Alan DeKok.

---

From: "radext issue tracker" <[email-masked]>
Date: Mon, 21 Jun 2010 15:07:39 -0000

#32: Section 2.2
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:            
     Type:  defect                     |       Status:  closed    
 Priority:  minor                      |    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/32#comment:1>
radext <http://tools.ietf.org/radext/>

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 21 Jun 2010 11:40:33 -0400

> significant sales can have their non-standard formats adopted by all

Yes, but isn't that rather a corner case, in terms of the way the process is supposed to work?  I was addressing baseline expectations.

> vendors and SDOs fall into the same non-IETF category.

If you were to change the text to say that, I'd agree.  But that's not what it says, and the definition of VSA in RFC 2865 is couched in terms of "not suitable for general use".

If what we want to say is that these guidelines really only apply for work done in the IETF, I think the document does convey that message.  My questions is whether that's really the message we want to convey.