[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RADEXT charter, Take 8
Some small clarification inline..
/L
-----Original Message-----
From: owner-radiusext@ops.ietf.org
[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Avi Lior
Sent: Wednesday, March 24, 2004 6:39 PM
To: 'jari.arkko@piuha.net'; Avi Lior
Cc: radiusext@ops.ietf.org
Subject: RE: RADEXT charter, Take 8
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.
<Lila> The current version of the prepaid document does not line up completely with 3GPP2 published prepaid standard. For example, the use of service key does not exist in the published 3GPP2 standard.
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.
<Lila> I'm not sure if 3GPP2 needs one time event charging for packet data prepaid because 3GPP2 has not discussed the need of such requirement for packet data prepaid as of yet.
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/>
This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.
E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
--
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/>