RE: Strawman RADIUSEXT WG charter - Take Two

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

owner-radiusext@ops.ietf.org <mailto:owner-radiusext@ops.ietf.org>
writes:

> RADIUS Extensions Working Group (RADIUSEXT)
> Last Modified: 2003-08-22
> 
> Chair(s):
> Bernard Aboba <aboba@internaut.com>

Isn't it just a bit of a contradiction (not to mention a conflict of
interest) for the same person to chair 2 WGs whose purposes are so
diametrically opposed?  Correct me if I'm wrong, but I thought that
Diameter was to replace RADIUS as the IETF standard AAA protocol, while
the apparent purpose of this proposed WG is to delay that replacement as
long as possible, if not to kill Diameter altogether.  Therefore, I
would suggest that you abandon the dead-end work of the AAA WG
altogether in favor of more fruitful area of RADIUS extensions.

> David Nelson <dnelson@enterasys.com>
> 
> Operations and Management Area Director(s):
> Randy Bush <randy@psg.com>
> Bert Wijnen <bwijnen@lucent.com>
> 
> Operations and Management Area Advisor:
> Randy Bush <randy@psg.com>
> 
> Mailing Lists:
> General Discussion: radiusext@ops.ietf.org
> To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe
> Archive: http://ops.ietf.org/lists/radiusext
> 
> Description of Working Group:
> 
> The RADIUS Extensions Working Group will focus on extensions
> to the RADIUS protocol required to enable its use in applications
> such as IP Telephony and Local Area Network authentication,
> authorization and accounting.  All extensions produced by this
> working group are required to demonstrate backward compatibility with
> the existing RADIUS protocol as well as compatibility with the
> equivalent capabilities in the Diameter protocol.     
> 
> In order to ensure backward compatibility with RADIUS, the following
> restrictions are imposed on extensions considered by the RADIUSEXT
> WG:  
> 
> - No new RADIUS commands will be defined.  Documentation of commands
>   currently in use may be considered in the future.
> - No new RADIUS transports (e.g. TCP, SCTP) will be defined.
> - No changes will be considered to the RADIUS attribute format.
> - No new RADIUS attribute data types will be defined.
> 
> Work Items
> 
> The immediate goals of the RADIUSEXT working group are to address the
> following issues: 
> 
> - 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?

>   This task
>   involves specification of the RADIUS UDP transport mapping,
>   providing support for congestion control and jittering.  Failover
>   behavior is not part of this work item.  An explicit non-goal of
>   this work item is to bring RADIUS up to the level of reliability
>   achievable in Diameter.
> 
> - 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")...

>   as well as with Diameter prepaid capabilities.

Who cares?

> 
> - LAN attributes.  A number of additional attributes have been
>   proposed to enable use of RADIUS authentication, authorization and
>   accounting in wired and wireless LANs.  Standardization of these
>   attributes will enable improved interoperability.
> 
> Goals and Milestones:
> 
> Apr 04  RADIUS UDP transport profile submitted as a Proposed Standard
> RFC. Sep 04  RADIUS pre-paid suport submitted as an Informational
> RFC. Dec 04  RADIUS attributes for LANs submitted as an Informational
> RFC.   
> 
> Quality Control Plan
> 
> In order to ensure quality of work, all drafts will need to undergo
> review prior to acceptance as WG work items. 
> 
> The WG will utilize an automated issue tracking system (such as
> Roundup) in order to track ongoing issues. 
> 
> XML to RFC will be used in production of documents.  This enables
> production of HTML and text files from a single source file as well
> as automated production of difference files.  

Hope this helps,

~gwz

"They that can give up essential liberty to obtain a little temporary
safety deserve neither..." 
-- Benjamin Franklin, 1759

"It is forbidden to kill; therefore all murderers are punished unless
they kill in large numbers and to the sound of trumpets." 
-- Voltaire



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