Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04

From: Avi Lior <[email-masked]>
Date: Tue, 13 Apr 2004 11:24:45 -0400

Just to let you know I am listening to this conversation.

The one thing I want to avoid in RADIUS prepaid is to add a lot of features
into the current document that are not really required by current RADIUS
implementations.

Instead, my thinking is that RADIUS Prepaid draft will establish the
framework for doing prepaid and extensions can be added later.

Currently, we have "standard" prepaid support (as done by 3GPP2) and we were
asked to do one time events.  Although I haven't formally seen the
requirements I think I know where they are coming from.

Tarrif switching which is done in 3GPP2 is not addressed.  It could be
addressed in this document or it could be added later.  I haven't seen
anyone wanting it in RADIUS -- for example, in WLAN.

To this end, we could address the base Prepaid interworking with Diameter CC
in the Prepaid draft.

Comments?

Also note, that there could be prepaid features that come from RADIUS
deployements that are not addressed by the Diameter CC application. 

> -----Original Message-----
> From: Harri Hakala (JO/LMF) [mailto:[email-masked]] 
> Sent: Tuesday, April 13, 2004 2:12 AM
> To: 'David Mitton'; Jari Arkko; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04
> 
> 
> Hi Dave,
> 
> I do agree that the guidelines and details in the 
> Interworking section are not right balanced. Also some 
> important standardization details are 
> missing, but it is quite hard to define these details without having 
> a bit more stable target document for translation. 
> 
> Now when draft-lior-radius-prepaid is also chartered in the 
> RADEXT, it 
> may be better to move this section to a separate I-D, as 
> proposed, instead of keeping this section even as an 
> informative appendix. This due to fact that 
> the comprehensive interworking description may be rather 
> large, depending on, of course, the level of details that 
> will be covered. For instance, at 
> the moment just translation from very basic session based 
> credit control to 
> Radius prepaid is covered in the DCC draft. It may be 
> feasible to provide 
> also the translation of optional features, e.g. one time 
> events, graceful 
> service termination, tariff switch, credit-control for 
> multiple services 
> and those ones which will be described in the Radius prepaid 
> draft. Handling of failure cases, such as the mapping of 
> result codes could be good to cover as well. It should also 
> define full-fledged parameter mapping, containing those 
> details which are not now specified.
> 
> regards........Harri
> 
> > -----Original Message-----
> > From: David Mitton [mailto:[email-masked]]
> > Sent: 8. huhtikuuta 2004 17:26
> > To: Jari Arkko; [email-masked]
> > Cc: Harri Hakala (JO/LMF); [email-masked]; [email-masked]
> > Subject: Re: [AAA-WG]: Issue: Review of Diameter Credit Control -04
> > 
> > 
> > Harri, et.al.,
> > 
> >          I had a similar reaction as Jari, but let me put it
> > in my own words.
> > 
> > I'm not sure I understand the utility of the text as it is. 
> The text 
> > says that it will explain how to do something, and it tries for
> > several pages, but it leaves out a lot of important details.
> > You say it's supposed to be guideline, and I go back and find 
> > those words 
> > in the document but I forgot them because the section is very 
> > declarative.  It seems to go much further than guidelines, 
> > but you are not 
> > trying to standardize this protocol in this document.
> > 
> > A guideline could suggest what data elements and transactions
> > are important 
> > to translate, but should not proscribe the format (eg RADIUS VSAs).
> > 
> > I can see that writing a true guideline section might be
> > problematic.  And 
> > if the issues need to be decided, then maybe it's not useful here.
> > 
> > If we want to keep this, I think this would be more 
> appropriate as an
> > informative appendix, with more words to the effect of it's 
> > incompleteness.
> > 
> > Dave.
> > 
> > 
> > On 4/8/2004 03:35 PM +0300, Jari Arkko wrote:
> > 
> > >I wonder how useful the translation to an imaginary
> > >protocol is. I agree that the RADEXT RADIUS prepaid
> > >document should be the normative specification for
> > >such translations.
> > >
> > >What would we lose if Section 11 was deleted? Is
> > >there a specific requirement from someone to have
> > >this mapping? If yes, perhaps Section 11 should be
> > >moved to an appendix and contain the explanation
> > >for the needed specific translation, even if the
> > >translation target is just an I-D.
> > >
> > >If no, maybe you should just simplify your document
> > >by leaving Section 11 to RADEXT, have them write it
> > >once they figure what kind of RADIUS prepaid they
> > >will make.
> > >
> > >--Jari
> > >
> > >[email-masked] wrote:
> > >>Dave / Bernard,
> > >>
> > >>>The section 11 is meant to be more as a guideline and not a full
> > >>>solution because no
> > >>>corresponding RADIUS prepaid RFC exists. Anyway, we felt 
> > that having an
> > >>>informative section on this was needed. So, basically we
> > tried to write
> > >>>basic principle how to translate some Diameter AVPs and
> > messages to more
> > >>>or less imaginary RADIUS prepaid application, using the
> > RFC 2865 as a
> > >>>base. We are aware of the draft-lior-radius-prepaid
> > >>>but since that work is still in progress the exact 
> mapping to this
> > >>>document was not possible.
> > >>>
> > >>>The RFC of Radius prepaid (when available) should define a
> > complete
> > >>>description of protocol translation between Radius prepaid
> > and Diameter
> > >>>credit control, if we follow the principle that the
> > document (Radius,
> > >>>Diameter) that comes last is responsible for defining 
> the mapping.
> > >>>
> > >>>The first paragraph in section 11 is intended to highlight
> > this but
> > >>>perhaps some re-wording is
> > >>>needed here.
> > >>>
> > >>>In Annex A, the flow 1 shows the message translation
> > between Radius
> > >>>prepaid and Diameter CC, but
> > >>>the purpose was not to show a full-fledged parameter
> > mapping for the
> > >>>above reasons.
> > >>
> > >>Any response to this? Does this answer the questions?
> > >>John
> > >
> > >
> > 
> > 
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 13 Apr 2004 21:04:33 +0300

> framework for doing prepaid and extensions can be added later.

Sounds good.

> To this end, we could address the base Prepaid interworking with Diameter CC

Works for me.

--Jari