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

From: "Harri Hakala (JO/LMF)" <[email-masked]>
Date: Thu, 8 Apr 2004 15:05:48 +0200

Hi Jari,

> Is
> there a specific requirement from someone to have
> this mapping? 

No, at least I am not aware of.

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

I am fine with this proposal. 

regards.........Harri

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Jari Arkko
> Sent: 8. huhtikuuta 2004 15:36
> To: [email-masked]
> Cc: Harri Hakala (JO/LMF); [email-masked]; [email-masked]
> Subject: Re: [AAA-WG]: Issue: Review of Diameter Credit Control -04
> 
> 
> 
> 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: Bernard Aboba <[email-masked]>
Date: Thu, 8 Apr 2004 06:54:57 -0700 (PDT)

How about moving Section 11 into a separate I-D, entitled "Interoperation
of Diameter and RADIUS Pre-Paid", so that the information is not lost?
RADEXT can then take that up as a work item.