RE: RADEXT charter, Take 8

[Avi Lior <avi@bridgewatersystems.com>]

Thanx Joel,

Just to make it perfectly clear, that in both the Sterman Draft and Perpaid
draft we are absolutely *not* introducing a new RADIUS attribute type.  What
we are doing is encoding the information in an attribute of type String.
Since Strings are supported by RADIUS dictionaries all intermediaries can
process the attribute at least to that level.

In both Prepaid and Sterman, and in similar cases such as EAP, there is no
intent for this attribute to be processed by any entity other than the two
end points.

I cant see how this usage breaks RADIUS, nor even that it qualifies to be
discused as a case for requireing a new RADIUS Subtypes.

Looking over previous emails, Randy Bush the said the following about the
Prepaid Draft:
" For
       example, it creates a new RADIUS attribute format including
       support for "sub-attributes," supposedly because the draft
       would otherwise require so many attributes that it would
       exhaust the entire RADIUS attribute space. "

This is absolutely not true.  Neither draft create a new RADIUS attribute
format.  The attribute is of type STRING in both drafts.


> -----Original Message-----
> From: Joel M. Halpern [mailto:joel@stevecrocker.com] 
> Sent: Wednesday, March 24, 2004 9:51 PM
> To: radiusext@ops.ietf.org
> Subject: Re: RADEXT charter, Take 8
> 
> 
> I was having some side conversations about RADIUS usage for 
> prepaid, and 
> wrote the following comment.  Given the current discussions 
> about whether 
> event charging belongs in the charter, and whether subtypes 
> belong within 
> scope, it seems that the comment belongs on the list.
> 
> 
> The RFPs we are seeing from Cellular (CDMA and GPRS) 
> operators call for 
> differential charging and time, volume, and event charging.  
> Obviously, 
> they do not care about whether a flat attribute space or 
> sub-attributes are 
> used.  But they do need more information exchanged than just 
> start time, 
> expiration time, and stop time.
> If the charter item is intended to allow that, then I am 
> happy to separate 
> the question of how the information should be structured from 
> the question 
> of whether the problem is in scope or not.
> 
> 
> It does seem to me given the complexity of the necessary 
> information that 
> this does lead to allowing one level of subtype support within new 
> attributes.  And it does seem to me that such usage is 
> backwards compatible 
> with RADIUS RFCs.
> 
> Yours,
> Joel
> 
> At 07:34 PM 3/23/2004 -0800, Bernard Aboba wrote:
> >- Pre-paid support.  Prepaid 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, the WG will provide definitions of the
> >   attributes required to support operator service models for
> >   pre-paid, as documented in liaison communications.  Support
> >   will be included for time, volume, and event oriented charging
> >   as well as support for limited differential charging.
> >   This document will be compatible with Diameter Credit Control.
> >
> >...
> >
> >* All drafts will need to undergo review prior to acceptance 
> as WG work
> >   items, which includes demonstration that the drafts are backward
> >   compatible with RADIUS RFCs and are compatible with equivalent
> >   facilities in Diameter.  Given the backwards 
> compatibility issues, no
> >   document including sub-attributes will be considered for 
> publication as
> >   an RFC before the RADIUS design guidelines and RADIUS/Diameter
> >   translation work items are completed, analyzing the issues in
> >   a comprehensive way.
> 
> 
> --
> 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/>
> 

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