Subject: [radext] #36: Section 3.2.3

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

#36: Section 3.2.3
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  major                      |   Milestone:  milestone1
Component:  design                     |     Version:  1.0       
 Severity:  Submitted WG Document      |    Keywords:            
---------------------------------------+------------------------------------
 We therefore RECOMMEND that the introduction of
    new types and complex data types within RADIUS attribute
    specifications be avoided.  A potential exception to this
    recommendation occurs for attributes that inherently require code
    changes on both the client and server.  For example, as described in
    Appendix B, complex attributes have been used in situations involving
    authentication and security attributes that need to be dynamically
    computed and verified.

 [BA] This advice is not completely consistent with that in Section 2.1.
 Recommended change:

    As described in Section 2.1, the introduction of complex data
    types is discouraged where viable alternatives are available.
    A potential exception is attributes that inherently require code
    changes on both the client and server.  For example, as described in
    Appendix B, complex attributes have been used in situations involving
    authentication and security attributes that need to be dynamically
    computed and verified.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/36>
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 06:48:59 -0000

#36: Section 3.2.3

Comment(by bernard_aboba@…):

 Despite the above caveats, there may be situations where complex
    attributes are beneficial because they reduce complexity in the non-
    RADIUS systems.  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.

 [BA] This paragraph is repeated in Section 2.1.  It should be deleted
 here.

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

---

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

#36: Section 3.2.3

 Another sentence in Section 3.2.3:

    The only other exception to the recommendation against complex types
    is for types that can be treated as opaque data by the RADIUS server.

 [BA] As noted in Section 2.1, there are other situations in which complex
 types could be used, so this doesn't represent the only exception.
 Recommended change:

 Another exception to the recommendation against complex types is for types
 that can be treated as opaque data by the RADIUS server.

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

---

From: "Dave Nelson" <[email-masked]>
Date: Mon, 21 Jun 2010 08:06:11 -0400

>  Recommended change:
> 
>  Another exception to the recommendation against complex types is for
>  types that can be treated as opaque data by the RADIUS server.

This is a single sentence out of context, so my concern may be addressed
elsewhere, but I've always felt that one important test of "opaqueness" is
whether or not the payload of the attribute is laid out in details in the
RADIUS document, in the traditional fashion of other RADIUS attributes.  If
it's truly opaque, then the format MUST be defined in some other, non-RADIUS
document.  Otherwise, this opens up the possibility of defining new services
in the context of a RADIUS document.  In other words, an attribute can't at
the same time be "opaque" to the RADIUS server but spelled out in detail to
the RADIUS developer in the RADIUS document.  It's either "defined
elsewhere" or it isn't.

---

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

Dave Nelson wrote:
> document.

  Yes.  See Section 2.1, which says this explicitly.

  Alan DeKok.

---

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

#36: Section 3.2.3
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:            
     Type:  defect                     |       Status:  closed    
 Priority:  major                      |    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/36#comment:3>
radext <http://tools.ietf.org/radext/>