Subject: [radext] #31: Section 2.1

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

#31: Section 2.1
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  minor                      |   Milestone:  milestone1
Component:  design                     |     Version:  1.0       
 Severity:  Submitted WG Document      |    Keywords:            
---------------------------------------+------------------------------------
 All other data formats are defined to be "complex data types", and
    are NOT RECOMMENDED for normal use.  Nested attributes, or attributes
    grouped via methods other than defined in [RFC2868] do not qualify as
    "basic data types", and SHOULD NOT be used.

    There may be situations where complex attributes are acceptable
    because they reduce complexity in non-RADIUS systems, or because
    leveraging the basic data types would be awkward.  Unfortunately,
    there are no "hard and fast" rules for where the complexity would
    best be located.  Each situation has to be decided on a case-by-case
    basis.  The cost-benefit trade-off may result in a "complex data
    type" being defined in RADIUS, as discussed in Appendix B.  When this
    is done, an explanation SHOULD be offered as to why the complex data
    type was used.

 [BA] The first paragraph could be mis-construed as prohibiting grouping
 mechanisms such as the Extended Attributes approach.

 Recommended replacement:

    All other data formats (including nested attributes) are defined
    to be "complex data types", and are NOT RECOMMENDED for normal
    use.  Complex data types MAY be used in situations where they
    reduce complexity in non-RADIUS systems, or where using
    the basic data types would be awkward (such as where grouping
    would be required in order to link related attributes).  Since
    there are no "hard and fast" rules for where complexity is best
    located, each situation has to be decided on a case-by-case
    basis.  Examples of this tradeoff are discussed in Appendix B.
    Where a complex data type is selected, an explanation SHOULD be
    offered as to why this was necessary.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/31>
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:52:11 -0400

>     offered as to why this was necessary.

At this point in time, I would support adding "such as where grouping would
be required in order to link related attributes" as an example of a case
that would justify the use of complex data types.  It is a great
disappointment to me that the WG failed to come to consensus on a more
regularized and formal mechanism to accommodate attribute grouping.  I think
that the ad hoc mechanism of grouping in complex data values is a distant
second best to a more formal and structured grouping mechanism.  However, at
this point, it is what it is.

---

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

#31: Section 2.1

Comment(by bernard_aboba@…):

 Sorry for the inexact editing instructions.  Once the first paragraph is
 replaced, the second paragraph is unnecessary.  Please delete the
 following:

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

---

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

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

  * owner:  => aland@…

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