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

From: <[email-masked]>
Date: Thu, 8 Apr 2004 15:06:40 +0300

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: Thu, 08 Apr 2004 15:35:56 +0300

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

---

From: David Mitton <[email-masked]>
Date: Thu, 08 Apr 2004 10:25:34 -0400

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:

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