RE: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66

["Avi Lior" <avi@bridgewatersystems.com>]

I support this consensus. 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Monday, July 10, 2006 5:45 PM
> To: radiusext@ops.ietf.org
> Subject: Consensus Call: "Sense of the Room" at RADEXT WG 
> meeting at IETF 66
> 
> At the RADEXT WG meeting at IETF 66, we took a "sense of the 
> room" with respect to what the WG should do with respect to 
> the exhaustion of the 
> RADIUS standard attribute space.   A  consensus appeared to 
> emerge.  We 
> would now like to confirm that consensus on the RADEXT WG 
> mailing list.
> 
> In your reply to this message, please state whether you 
> support the consensus described below, or whether you 
> disagree with it (and if so, how).
> 
> The "sense of the room" in the RADEXT WG meeting at IETF 66 was that:
> 
> * Exhaustion of the RADIUS standard attribute space is a 
> problem that should be solved.
> * RADEXT WG is the place to solve the problem.
> * The attribute exhaustion problem should be the focus -- not 
> adding other capabilities to RADIUS (such as support for the 
> Diameter data types).
> 
> In reviewing the potential solutions to the problem, the 
> people present at the meeting appeared to strongly favor a 
> RADIUS extension approach such as that outlined by Lior & Li 
> (RADIUS attribute extension), over the current proposals for 
> adding Diameter AVP support to RADIUS (Wolff & Weber and 
> Mitton proposals).  Some of the reasoning behind this was 
> that adding support for Diameter AVP parsing and dictionary 
> support would involve a substantial portion of the effort to 
> develop a Diameter server, whereas simply adding support for 
> an extended space vwould involve less effort, and would 
> therefore be more likely to be deployed.
> 
> This consensus, if it is confirmed on the mailing list, has 
> implications for the Design Guidelines document.  If the 
> RADIUS attribute space is extended without changing the 
> RADIUS protocol in other ways, then Design Guidelines 
> document needs only to focus on guidelines for the RADIUS 
> protocol.  Thus, the Design Guidelines effort is considerably 
> simplified.
> 
> 
> 
> --
> 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/>