RE: "Last Look" at the RADIUS Design Guidelines document

["Dave Nelson" <d.b.nelson@comcast.net>]

I haven't heard anyone disagree that the market demands more of RADIUS today
than it did when RADIUS was devised.

What's in contention is *how* to address the evolving market requirements.
In the IETF tradition there are three approaches to address the need for
added functionality in a legacy protocol:

(1) Write a new protocol to replace the old one.

(2) Extend the old protocol, using suitable extension mechanisms that permit
backward-forward compatibility and that don't effectively obsolete the older
implementations.

(3) Revise the old protocol by issuing a new version, e.g. V2, using a
suitable version numbering and version negotiation mechanism, so that older
implementations can interoperate with newer implementation when only the
legacy functionality is required.

I've heard a fourth method suggested in this discussion:

(4) Revise the old protocol by adding new functionality, without regard to
whether it effectively obsoletes legacy implementations.

I think it's this fourth approach that Alan finds unacceptable.  I tend to
agree that it's not the IETF way, and it's basically unfair to a large
constituency of implementers.

The AAA WG was chartered to work on either approach (1) or (3).  They
considered a RADIUS V2 proposal (approach (3)) and decided against that in
favor of Diameter (approach (1)).

The RADEXT WG was chartered to work on approach (2).  I think we need to
assiduously avoid wandering into approach (4).



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