[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66
I support this consensus.
> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of Bernard Aboba
> Sent: Monday, July 10, 2006 5:45 PM
> To: email@example.com
> 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
> to unsubscribe send a message to
> firstname.lastname@example.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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.