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

From: Bernard Aboba <[email-masked]>
Date: Sun, 4 Apr 2004 22:32:38 -0700 (PDT)

---------- Forwarded message ----------
Date: Mon, 05 Apr 2004 00:16:50 -0400
From: David Mitton <[email-masked]>

I've gotten through the document about 1.5 times.   Mostly just looking at
the parts.

Below are my comments, I'll try to back up and try to understand more about
how this thing behaves... but I doubt I'll turn up much more.

Dave.
----
Nits:

- Many lines go one character over the 72 column RFC
format restriction into col 73.  Fixing these will cause the document to
page differently.

- Sect 4.0, page 13, para 4, first sentence; upcased "Credit" for no
reason.  In a number of places the phrase "credit control" is
randomly hyphenated or not.

Issues:

- Section 11.3 RADIUS VSAs for Credit Control, page 80, the section
names, but does not define (type codes, field layouts) the  VSAs used.
An example is promised in Annex A, but I could not find what I was
looking for.

I'm guessing, since it's not stated directly enough for me, that they
are proposing a translation of Diameter AVPs into RADIUS VSAs.
The section of Diameter NASREQ quoted, only gives rules for Diameter
VSAs into RADIUS VSAs.  No rules are given for regular Diameter AVPs.

What vendor code is used?  What is the VSA format?  What are the RADIUS
attribute data types corresponding to each Diameter AVP?  What happens
to the Diameter flag values?  What is done with Grouped AVPs? Is there
an unnamed reference document?

- Section 12, IANA Consideration, page 81
No general policy is given, the AVPs repeat that additional values can
be assigned by the designated expert.

How will the Diameter AVP to RADIUS VSA mapping be administered in the
case of new attributes or AVPs?

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Mon, 5 Apr 2004 12:37:09 +0200

Hi,

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.

regards...........Harri

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Bernard Aboba
> Sent: 5. huhtikuuta 2004 8:33
> To: [email-masked]
> Subject: [AAA-WG]: Issue: Review of Diameter Credit Control -04
> 
> 
>

---

From: <[email-masked]>
Date: Thu, 8 Apr 2004 16:52:28 +0300

Hi Bernard,

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

That sounds like a good idea.

John

---

From: "Harri Hakala (JO/LMF)" <[email-masked]>
Date: Tue, 13 Apr 2004 09:46:30 +0200

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

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

---

From: "Harri Hakala (JO/LMF)" <[email-masked]>
Date: Tue, 13 Apr 2004 11:18:19 +0200

Hi Marco,

> My proposal would be to move the current section 11 content 
> to a separate I-D
> but still keep the Section 11 header. Under section 11 we 
> could move the
> architecture model of section 2 (figure 2) and related text 
> as well as the
> flow II of the appendix. With emphasis that this illustrates 
> the interworking
> model but does NOT specify by any means the protocol 
> translation, that will
> be specified in separate document etc.
> 
> What do you think? Should we start to update the document accordingly?

I think that it doesn't harm to keep the architecture model section
as it is, just the reference to section 11 could be removed.
Alternatively the figure 2 with related text from the section 2 and flow II
could be moved to a new I-D as well.

regards..........Harri

---

From: <[email-masked]>
Date: Tue, 13 Apr 2004 13:21:57 +0300

Hi Harri,

> as it is, just the reference to section 11 could be removed.

I think if we group all the DCC-RADIUS interworking related stuff in
an own section is more clear for the reader, no?

> could be moved to a new I-D as well.

That could be an alternative as well. However, I feel that some wording 
in the DCC concerning the interworking with RADIUS should be kept.
My preference is to keep the interworking model in DCC and the detailed
translation somewhere else, either in separate I-D or in the RADIUS
prepaid spec (as suggested by Jari)

Jari Arkko wrote:

> P.S. By the way, I think its best that the RADIUS prepaid
> spec (if adopted by the IETF) defines the interworking too
> rather than having a separate spec in RADEXT. Some weeks ago
> a posted a comment to the RADEXT mailing list about the
> reasons why. Basically, its better to design the protocol
> so that it can be translated rather than later figure out
> how the two could fit together. Obviously we couldn't do that
> here because the translation target did not yet exist in any
> stable form.

Regards
Marco

---

From: "Harri Hakala (JO/LMF)" <[email-masked]>
Date: Tue, 13 Apr 2004 13:17:24 +0200

Hi,

> an own section is more clear for the reader, no?

Yes, that's true, but then it would be good to provide some high level principles
as well, the architecture model 2 and example flow II alone might be a bit separate 
pieces of information. 

> prepaid spec (as suggested by Jari)

To achieve the good interworking model, we perhaps should try to modify the 
current section 11 by removing all distracting details and adding architecture
model 2 and the interworking flow (flow II) with modified text.

regards.............Harri

---

From: <[email-masked]>
Date: Tue, 13 Apr 2004 14:34:26 +0300

Hi Harri,

> model 2 and the interworking flow (flow II) with modified text.

Agree. Do others agree with this approach too?

Regards
Marco

---

From: <[email-masked]>
Date: Tue, 13 Apr 2004 14:35:41 +0300

Fine with me.

John

> From: Stura Marco (Nokia-NET/Helsinki) 
> Sent: 13 April, 2004 14:34
> To: 'ext Harri Hakala (JO/LMF)'
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Loughney John (Nokia-NRC/Helsinki)
> Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04
> 
> 
> Hi Harri,
>

---

From: "Harri Hakala (JO/LMF)" <[email-masked]>
Date: Tue, 13 Apr 2004 08:11:58 +0200

Hi Dave,

regards........Harri

> 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,
> >>
> >>>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.
> >>>
> >>>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: <[email-masked]>
Date: Tue, 13 Apr 2004 20:31:45 +0300

Avi,

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

That sounds reasonable to me.

John

---

From: <[email-masked]>
Date: Wed, 14 Apr 2004 09:10:49 +0300

Hi Avi,

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

Sounds good.

Marco

> ext Avi Lior
> Sent: 13 April, 2004 18:25
> To: 'Harri Hakala (JO/LMF)'; 'David Mitton'; Jari Arkko; Loughney John
> (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> 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.
> 
> Comments?
> Also note, that there could be prepaid features that come from RADIUS
> deployements that are not addressed by the Diameter CC application. 
> 
> 
> > 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]
> > I do agree that the guidelines and details in the 
> > Interworking section are not right balanced. Also some 
> > important standardization details are 
> > 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 
> > 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
> > 
> > The text 
> > > says that it will explain how to do something, and it tries for
> > > >>>The section 11 is meant to be more as a guideline and 
> not a full
> > > >>>solution because no
> > > >>>but since that work is still in progress the exact 
> > mapping to this
> > > >>>document was not possible.
> > > >>>