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

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Bernard Aboba <> supposedly scribbled:

> 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).  

Sorry for the tardiness of my reply.

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

I do not agree with this; as I've pointed out ad nauseam, this problem was already solved some years ago in Diameter.  The current problem is that some folks don't want to accept the solution (though, strangely enough, those same folks seem to be in a rush to turn RADIUS into Diameter (again)).

> * RADEXT WG is the place to solve the problem.

If the first statement garners consensus, I can't think of any other place to do it.

> * The attribute exhaustion problem should be the focus -- not adding
> other capabilities to RADIUS (such as support for the Diameter data
> types).  

I think that the attribute exhaustion problem should definitely be the focus of the solution for the attribute exhaustion problem ;-).  Seriously, I think that one you solve that problem, the solutions to a bunch of other problems will pretty much just fall out.

> 
> 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).  

Agree strongly.

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

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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