Re: [radext] #31: Section 2.1

["radext issue tracker" <trac@tools.ietf.org>]

#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:            
---------------------------------------+------------------------------------

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:

 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.

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


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>