[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 the emerging consensus on the all three items below.
I also support Avi's expired draft to address the last issue.
In addition, if adding other capability is needed, I'd suggest adding
such capabilities inside RADIUS attributes, not RADIUS protocol
itself. If such "attribute-level remedy" is considered to be
impossible or unreasonably difficult to add some capability, it is
really time to think about using Diameter for that capability, instead
of trying to do cosmetic or whatever surgery to the RADIUS protocol
itself.
Best regards,
Yoshihiro Ohba
On Mon, Jul 10, 2006 at 02:45:06PM -0700, Bernard Aboba wrote:
> 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/>