RE: RADEXT charter, Take 8

[Avi Lior <avi@bridgewatersystems.com>]

Regarding external SDO requirements:

(Note this is not an official view of 3GPP2)

The current version of the prepaid document lines up with what 3GPP2 *has*
done.  Ideally we want to maintain compatibility with 3GPP2 while allowing
other people to add their requirements thus continuing interoperability with
3GPP2.

3GPP on the other hand will use Diameter CC.  There is requirement for
Diameter CC support for 3GPP2.  And we would probably want interop between a
RADIUS Prepaid solution and the Diameter prepaid solution in 3GPP2.  Note
that integration can happen many ways.  One method would be at the prepaid
server itself.  In this case you would have Diameter CC for IMS and RADIUS
prepaid for Packet Data both feeding off the same prepaid account.

WLAN Needs a prepaid solution.  We are pushing for this to be this method
(for reason stated in the current draft).

One thing to note is the I hope that we can do this a lot faster then the
current schedule. The reason is that prepaid is happening now big time.
Folks are starting to adopt this draft.  Dragging our feet will just make
the final work insignificant.

The current words in the charter reflect Diameter CC (specifically one time
event charging).  There is no need for that in 3GPP2 hence we currently
don't address that in the draft.  One time event charging maybe needed later
in 3GPP2.  Frankly I would like to know how that requirement got onto the
charter.

Hope that helps....

Avi
> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net] 
> Sent: Wednesday, March 24, 2004 4:07 PM
> To: Avi Lior
> Cc: radiusext@ops.ietf.org
> Subject: Re: RADEXT charter, Take 8
> 
> 
> Avi Lior wrote:
> 
> > Nothing is ever 100% compatible ;-)
> > 
> > As stated before, we are trying to keep the number of features and 
> > variations for the RADIUS prepaid document down so that we 
> can achieve 
> > the milestone set by the charter.
> > The approach taken would allow someone else to build on this work by
> > issueing a new RFC.
> > 
> > I am okay with the wording except the "Event Oriented 
> Charging" seems 
> > to be new.  That is in Diameter CC and not in this one.  The 
> > Differential charging (if I understand it correctly) can easily be 
> > addressed.
> > 
> > The two prepaid approaches (this one and diameter) share a common 
> > model. I had already received comments to that effect from serveral 
> > people who are quite interested in having equivalent 
> functionality.  
> > So we will keep working on this while maintaining the schedule.
> 
> Sounds good. Thanks for the info.
> 
> I agree with your approach to keep the number of
> features minimal. By the way, are there some external
> SDO requirements for this prepaid work? If so, is
> the charter definition for prepaid functions compatible
> with their requirements?
> 
> --Jari
> 

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