RE: Strawman RADIUSEXT WG charter - Take Two

[Bernard Aboba <aboba@internaut.com>]

> > - RADIUS UDP transport profile.  The transport behavior of the RADIUS
> >   protocol is unspecified in RFC 2865 and 2866.  This has resulted in
> >   implementations lacking support for congestion control.
>
> Is there evidence that this 'lack' is a fatal flaw?

There are cases where after a power failure or large scale reboot of
many NASes, overly aggressive RADIUS clients have swamped the
RADIUS server.

> > - Pre-paid support.  Pre-paid services are contemplated in a number
> >   of potential applications, including wireless LAN access and IP
> >   telephony. In order to enable support of pre-paid services in an
> >   interoperable way, a specification is required.  The implementation
> >   of RADIUS prepaid needs to be compatible with RFC 2865 and 2866,
>
> I doubt very much that this is possible, given that pre-paid support
> would undoubtedly use the capabilities defined (sort of) in RFC 3576 and
> magically justified after the fact by RFC 3575 (unless, of course, we're
> redefining "compatible" to mean "in direct violation of")...

We could change this to "compatible with existing RADIUS RFCs."

> >   as well as with Diameter prepaid capabilities.
>
> Who cares?

I think that there is a desire to potentially gateway between RADIUS
prepaid clients and a Diameter prepaid server, no?


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