RE: Proposed resolution to guidelines document

["Bernard Aboba" <bernard_aboba@hotmail.com>]

Do these changes address Issue #325?  

-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On
Behalf Of Alan DeKok
Sent: Tuesday, January 19, 2010 5:25 AM
To: 'radext mailing list'
Subject: Proposed resolution to guidelines document

  I have put a proposed draft on my web site.  It *should* address the
(cough) minor comments discussed here:

http://git.freeradius.org/ietf/10-11-diff.html

http://git.freeradius.org/ietf/draft-ietf-radext-design-11.txt

  Changes are:

1) delete unused definition of RADIUS proxy as pointed out by Avi

2) add missing line as pointed out by Avi

3) change text about "complex" types to "new" types.

4) move "Complex attributes and security" to the "Security" section

5) remove all text referencing "applications" from that section,
   and change the text to "other, non-RADIUS systems".  This makes
   the text generic enough to apply to application layers, or to
   the practice of storing RADIUS data in SQL tables

6) add text about modern systems:

  Some systems permit complex attributes to be defined via a method	
  that is more capable than traditional RADIUS dictionaries.  These	
  systems can reduce the security threat of new types significantly,	
  but they do not remove it entirely.	

7) it doesn't address Joe's comments or Bernard's suggestion.  That
   text will come later.


  I believe that this addresses *all* of controversial points.  The
document no longer relies on traditional RADIUS dictionaries to motivate
its recommendations.  It no longer discusses *any* processing model of
RADIUS, other than to say that systems other than RADIUS may use the
data produced by RADIUS.

  All it says is "prefer simple types to complex ones, but allow complex
ones if everything else is worse".  And it says that change has risk.

  If this text is deemed to be not applicable to the majority of
"RADIUS" implementations, then I suggest that those systems are no
longer implementing RADIUS.

  Alan DeKok.

--
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/>


--
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/>