Subject: [radext] #26: Terminology (Section 1.1)

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

#26: Terminology (Section 1.1)
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  minor                      |   Milestone:  milestone1
Component:  design                     |     Version:  1.0       
 Severity:  Submitted WG Document      |    Keywords:            
---------------------------------------+------------------------------------
 standard space
      The 256 possible attributes that follow the format defined in
      [RFC2865] Section 5.

 vendor space
      The contents of the "String" field of a Vendor-Specific Attribute
       (VSA) ([RFC2865] Section 5.26).

 [BA] Given the extended attribute work, we may not want to define the
 standard space a bit more flexibly.  Also, the definition of vendor space
 should take the vendor-type field into account, no?
 Recommend this be changed to:

 standard space
      RADIUS attributes which are allocated by IANA and which follow the
 format defined in RFC 2865 [RFC2865] Section 5.

 vendor space
     The contents of the "String" field of a Vendor-Specific Attribute
 (VSA), as defined in [RFC2865] Section 5.26.  These attributes provide a
 unique attribute space for each vendor (identified by the Vendor-Type
 field) which they can self-allocate."

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/26>
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 07:22:53 -0400

Wow.   Such a long series of emails.  I appreciate having the issues
separated, but dealing with so many suggested changes out of context is
challenging.

>  [BA] Given the extended attribute work, we may not want to 
>  define the standard space a bit more flexibly.

Did you intend the "not" in this sentence?

>  standard space
>       RADIUS attributes which are allocated by IANA and which
>       follow the format defined in RFC 2865 [RFC2865] Section 5.

If the suggestion is to be more flexible in defining "standard space", your
suggested text seems to fall short of the mark, in that it talks about the
"format defined in RFC 2865 [RFC2865] Section 5".  Clearly that excludes the
Extended Attributes, no?

---

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

#26: Terminology (Section 1.1)
---------------------------------------+------------------------------------
 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/26#comment:1>
radext <http://tools.ietf.org/radext/>