RE: The RADIUS attribute space: an assessment

["Nelson, David" <dnelson@enterasys.com>]

Glen Zorn writes...
 
> A far better idea might be for the IESG to finally take some action,
> deprecating RADIUS and actually supporting Diameter to solve one of
the
> problems for which it was designed.

Why would that be a better idea?  Except, perhaps, on some
self-congratulatory level?  I've observed that the IESG doesn't have
much influence over what the rest of the world chooses to implement.  A
recent, off list, discussion about some substantial enhancements to the
RADIUS protocol as opposed to deployment of Diameter, has brought this
home.  The impediment to Diameter deployment in this instance is that
lack of complete, robust, open source implementations of Diameter,
coupled with readily available open source RADIUS implementations and
wide deployment of RADIUS.  The IETF can provide a standardized
specification of a better protocol, but it can make vendors and
operators deploy it.

What would likely happen, if the IESG were to "deprecate" RADIUS, is
that implementers will simply continue to extend RADIUS using the Vendor
Specific Attribute.  I don't see any advantage in taking that route.

The IESG could "support" Diameter by funding (or otherwise stimulating)
the creation of complete, robust, well-documented open source
implementations of Diameter.  However, I don't think the IESG is in that
business.


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