RE: Question regarding draft-ietf-radext-design-05.txt

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

"I think that the basic issues here is that there is a disconnect between
the
consensus position of the RADEXT WG (to keep things pretty simple) and need
you are describing to provide [near] capability parity with Diameter."

To quote the conclusions of the AAA protocol Evaluation team (RFC 3127) with

respect to the prospects for enhancing RADIUS so as to meet the AAA
requirements:

"  Radius++ is not considered acceptable as an AAA protocol.  There is a
   fairly substantial amount of engineering required to make it meet all
   requirements, and that engineering would most likely result in
   something close to the functionality of Diameter." 

Indeed, at various points with the RADEXT WG, questions have come up
relating
to adoption of one or more features of Diameter, and WG consensus has lined
up
with the RFC 3127 assessment:

1) during the discussion on Extended Attributes, the question arose
as to whether RADIUS should adopt the Diameter AVP format.  The WG
consensus was against this, and as a result only modest extensions
(for tagging and additional attribute space) were adopted. 

2) during the transport work, questions have arisen about the
suitability of the RFC 3539 watchdog timer and failover logic.  Again,
WG sentiment does not appear to support a strict port of the
Diameter functionality to RADIUS.  

So while it is possible (and potentially desirable) for RADEXT to
develop enhancements (such as Extended Attributes and RADSEC), this 
falls considerably short of providing the full functionality of 
Diameter. 






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