From owner-aaa-wg@merit.edu Mon Dec 1 05:43:55 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05497 for ; Mon, 1 Dec 2003 05:43:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DDD979121B; Mon, 1 Dec 2003 05:43:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADBE09121C; Mon, 1 Dec 2003 05:43:52 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 156759121B for ; Mon, 1 Dec 2003 05:43:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id ED4D25DF2A; Mon, 1 Dec 2003 05:43:50 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 6D8E55DEEC for ; Mon, 1 Dec 2003 05:43:50 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB1AhjI2003593; Mon, 1 Dec 2003 11:43:49 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 1 Dec 2003 11:44:00 +0100 Message-ID: From: "Leena Mattila (TU/LMF)" To: "'John.Prudhoe@vodafone.com'" Cc: "'aaa-wg@merit.edu'" , "'marco.stura@nokia.com'" , "'Benni.Alexander@nokia.com'" , "'crich@nortelnetworks.com'" , "Harri Hakala (TU/LMF)" , "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "Patrik Teppo (KA/EAB)" Subject: RE: [AAA-WG]: DCC Tariff time change support Date: Mon, 1 Dec 2003 11:42:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi John, I could not quite follow your logic and reasoning. When I checked the CAMEL spec (TS 29.078) it does not have this kind of indicator either, so I don't the reference to 2.5G does not seem to be applicable. If the CC server authorizes ten blocks of 5K then it means that it will send 50 000 octects as granted units to the CC client. If a tariff swich occurs when 32 000 octets have been transfered then the CC client will report 32 000 as octets before the tsw and 18 000 octets as octets after tsw, right? Then it will be up to the CC server to slice the amounts into 5K blocks and decide how to treat the 2K and 3K on both sides of the tsw. So, I don't see a need for a separate indication from the client. Or did I misunderstand the case completely? Regards, Leena > -----Original Message----- > From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] > Sent: 28. marraskuuta 2003 17:53 > To: marco.stura@nokia.com; aaa-wg@merit.ed.ericsson.se > Cc: Benni.Alexander@nokia.com; crich@nortelnetworks.com; > Harri Hakala (TU/LMF); john.loughney@nokia.com; > juha-pekka.koskinen@nokia.com; Karl-Heinz.Nenner@t-mobile.de; > Leena Mattila (TU/LMF); owner-aaa-wg@merit.edu; Patrik Teppo (KA/EAB) > Subject: Re: [AAA-WG]: DCC Tariff time change support > > > > Hi Marco, > > I believe there's also a special case to be considered, where > the consumption of a unit straddles the tarrif time change. > > I am thinking for example of a data session over a 3G or 2.5G > network and let's say it is being charged in blocks of 5K. > Let's say ten blocks are authorised at a time. The client > reports back on which of those were used before the tariff > time change and which were used afterwards. But there is > almost always going to be one that straddles the time change, > but it's not completely guaranteed. The client can't group > that one in with the others because it doesn't know the rules > on charging. > > I suspect the solution is going to have to be that the client > reports back whether or not a unit straddled the tariff time > change. If it did, the total of those before and afterwards > is one less than the total used. > > Regards, > > John. > > > > > > Sent by: owner-aaa-wg@merit.edu > 28/11/2003 14:35 > > To: > cc: , > , , > , , > , , > > Subject: [AAA-WG]: Issue: DCC Tariff time > change support > > > > Tariff Time change support > Submitter name: Marco Stura > Submitter email address: marco.stura@nokia.com > Date first submitted: 28.11.2003 > Reference: > Document: Diameter CCA-01 > Comment type: T > Priority: 2 > Section: > Rationale/Explanation of issue: > > As discussed on the mailing list: > http://www.merit.edu/mail.archives/aaa-wg/2003-11/msg00008.html > The tariff change support shall be added to the cca. > > Proposed changed: > > Section 5 Session Based Credit Control > ADD (at the end of the section): > The Diameter credit-control server and client may optionally > support a > tariff change mechanism. The Diameter credit-control server > may include > a Tariff-Time-Change AVP in the answer message. When the > Diameter credit- > control client reports the used units and a tariff change has occurred > during the reporting period then the Diameter credit-control client > SHOULD itemize the units used before and after the tariff change. > > Section 8.16 Granted-Service-Unit > CHANGE: > FROM: > Granted-Service-Unit ::= < AVP Header: 431 > > [ CC-Time ] > [ CC-Money ] > [ CC-Total-Octets ] > [ CC-Input-Octets ] > [ CC-Output-Octets ] > [ CC-Service-Specific-Units ] > *[ Service-Identifier ] > [ Rating-Group ] > TO: > Granted-Service-Unit ::= < AVP Header: 431 > > [ Tariff-Time-Change ] > [ CC-Time ] > [ CC-Money ] > [ CC-Total-Octets ] > [ CC-Input-Octets ] > [ CC-Output-Octets ] > [ CC-Service-Specific-Units ] > *[ Service-Identifier ] > [ Rating-Group ] > > Section 8.30 Used-Service-Unit AVP > CHANGE: > FROM: > Used-Service-Unit ::= < AVP Header: 446 > > [ CC-Time ] > [ CC-Money ] > [ CC-Total-Octets ] > [ CC-Input-Octets ] > [ CC-Output-Octets ] > [ CC-Service-Specific-Units ] > *[ Service-Identifier ] > [ Rating-Group ] > > TO: > Used-Service-Unit ::= < AVP Header: 446 > > [ Tariff-Time-Usage ] > [ CC-Time ] > [ CC-Money ] > [ CC-Total-Octets ] > [ CC-Input-Octets ] > [ CC-Output-Octets ] > [ CC-Service-Specific-Units ] > *[ Service-Identifier ] > [ Rating-Group ] > > ADD: > Section 8.xx Tariff-Time-Change AVP > The Tariff-Time-Change AVP (AVP code TBD) is of type Time, and > includes the time in seconds since January 1, 1900 00:00 UTC when > the tariff of the service will be changed. > The tariff change mechanism is optional for client and server and > it is not used for unit type time, since the server has full > control of the time. > If a client does not support the tariff time change mechanism it > must treat Tariff-Time-Change AVP in the answer message as an > incorrect > CCA answer. In that case the client shall terminate credit control > session and indicate in the Termination-Cause AVP reason > DIAMETER_BAD_ANSWER. > > ADD: > Section 8.xx Tariff-Time-Usage AVP > The Tariff-Time-Usage AVP (AVP code TBD) is of type > Enumerated and defines whether > units are used before or after tariff change when a tariff > change has occurred > during the reporting period. Omission of this AVP means that > no tariff change > has been occurred. > > Tariff-Time-Usage can be one of the following. > > UNIT_BEFORE_TARIFF_CHANGE 0 > The used units contains the amount of the units before > tariff change, that is units measured from the point when > the previous measurement ended to the point when tariff change > occurred. > > UNIT_AFTER_TARIFF_CHANGE 1 > The used units contains the amount of the units after > tariff change has been occurred. > > > > > > ************************************************************** > **************** > > The content of this e-mail may be privileged and/or confidential. > If you are not the addressee indicated in this message > (or responsible for delivery of the message to such person), > you may not copy or deliver this message to anyone. In such > case, you should destroy this message and kindly notify the > sender and postmaster@vodafone.ie by reply email. Please > note that in such circumstances any review, dissemination, > disclosure, alteration, printing, copying or further transmission > of this e-mail and/or any file transmitted with it is prohibited > and may be unlawful. Please advise us immediately if you or > your employer do not consent to Internet email for messages > of this kind. The opinions, conclusions and other information > in this message are of the author and shall be understood as > neither given nor endorsed by Vodafone Ireland Limited > unless it is otherwise indicated by an authorised representative > independent of this message. Internet e-mail is > transmitted over the public internet over which Vodafone > Ireland Limited has no control. As such, there is no guarantee that > (i) this e-mail will be delivered within a reasonable time or at all > (ii) this e-mail comes from the purported sender > (iii) this e-mail has not been intercepted by a third party > (iv) the contents of this e-mail are unaltered from the time of > transmission. The presence of this footnote indicates that this > message (including its attachments) has been processed by an > automated anti-virus system; however it is the responsibility of > the recipient to ensure that the message (and attachments) > are safe and authorised for use in their environment. > Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), > Pauline Best (UK), Paul Donovan Chief Executive (UK), > Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). > Registered in Ireland at MountainView, Leopardstown, Dublin 18. > Number 326967 VAT Reg No. IE6346967G > > ************************************************************** > **************** > > From owner-aaa-wg@merit.edu Mon Dec 1 06:17:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06225 for ; Mon, 1 Dec 2003 06:17:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3146E9121D; Mon, 1 Dec 2003 06:17:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 012A49121C; Mon, 1 Dec 2003 06:17:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EE31E9121D for ; Mon, 1 Dec 2003 06:17:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id B5F5B5DE92; Mon, 1 Dec 2003 06:17:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 84EBF5DE19; Mon, 1 Dec 2003 06:17:15 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB1BHEK04144; Mon, 1 Dec 2003 13:17:14 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Dec 2003 13:17:13 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 1 Dec 2003 13:17:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B7FC.AB12E89A" Subject: RE: [AAA-WG]: DCC Tariff time change support Date: Mon, 1 Dec 2003 13:17:12 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C81CB@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC Tariff time change support Thread-Index: AcO1x8cnCm0mS3JITb6wU5XgeujbTACNMkUA From: To: , Cc: , , , , , , , , X-OriginalArrivalTime: 01 Dec 2003 11:17:13.0217 (UTC) FILETIME=[AB6C9F10:01C3B7FC] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B7FC.AB12E89A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi John, =20 I don't fully understand your case. =20 If the CC server authorizes 10 blocks of 5K it means that it will convey = one G-S-U that include 50000 total octets. The credit control client count the octets, I think = it doesn't need to be concerned about the billing model. When the client report the U-S-Us is up to the = server to reconstruct how many 5K blocks have been consumed before the tariff time change and = how many after the tariff time change, no? =20 If the tariff change occured in the midle of a 5K block e.g. 12000 = octets consumed before tariff change and 38000 octets consumed after tariff change, the server = is able to deduce that 2K of one 5K block have been consumed before tariff change and the = rest 3K after tariff change. The server can then decide how to treat this block, right? =20 Regards Marco -----Original Message----- From: ext John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: 28 November, 2003 17:53 To: Stura Marco (NET/Helsinki); aaa-wg@merit.ed Cc: Alexander Benni (NET/Helsinki); crich@nortelnetworks.com; = harri.hakala@ericsson.com; Loughney John (NRC/Helsinki); Koskinen = Juha-Pekka (NET/Tampere); Karl-Heinz.Nenner@t-mobile.de; = leena.mattila@ericsson.com; owner-aaa-wg@merit.edu; = patrik.teppo@ericsson.com Subject: Re: [AAA-WG]: DCC Tariff time change support Hi Marco,=20 I believe there's also a special case to be considered, where the = consumption of a unit straddles the tarrif time change.=20 I am thinking for example of a data session over a 3G or 2.5G network = and let's say it is being charged in blocks of 5K. Let's say ten blocks = are authorised at a time. The client reports back on which of those = were used before the tariff time change and which were used afterwards. = But there is almost always going to be one that straddles the time = change, but it's not completely guaranteed. The client can't group that = one in with the others because it doesn't know the rules on charging.=20 I suspect the solution is going to have to be that the client reports = back whether or not a unit straddled the tariff time change. If it did, = the total of those before and afterwards is one less than the total = used.=20 Regards,=20 John.=20 =20 =20 Sent by: owner-aaa-wg@merit.edu=20 28/11/2003 14:35=20 =20 To: =20 cc: , = , , = , , = , , = =20 Subject: [AAA-WG]: Issue: DCC Tariff time change support Tariff Time change support Submitter name: Marco Stura Submitter email address: marco.stura@nokia.com Date first submitted: 28.11.2003 Reference:=20 Document: Diameter CCA-01 Comment type: T Priority: 2 Section:=20 Rationale/Explanation of issue: As discussed on the mailing list: http://www.merit.edu/mail.archives/aaa-wg/2003-11/msg00008.html The tariff change support shall be added to the cca. Proposed changed: Section 5 Session Based Credit Control ADD (at the end of the section): The Diameter credit-control server and client may optionally support a=20 tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. When the Diameter = credit- control client reports the used units and a tariff change has occurred during the reporting period then the Diameter credit-control client SHOULD itemize the units used before and after the tariff change. Section 8.16 Granted-Service-Unit CHANGE: FROM: Granted-Service-Unit ::=3D < AVP Header: 431 >=20 [ CC-Time ]=20 [ CC-Money ]=20 [ CC-Total-Octets ]=20 [ CC-Input-Octets ]=20 [ CC-Output-Octets ]=20 [ CC-Service-Specific-Units ]=20 *[ Service-Identifier ]=20 [ Rating-Group ]=20 TO: Granted-Service-Unit ::=3D < AVP Header: 431 >=20 [ Tariff-Time-Change ] [ CC-Time ]=20 [ CC-Money ]=20 [ CC-Total-Octets ]=20 [ CC-Input-Octets ]=20 [ CC-Output-Octets ]=20 [ CC-Service-Specific-Units ]=20 *[ Service-Identifier ]=20 [ Rating-Group ]=20 Section 8.30 Used-Service-Unit AVP CHANGE: FROM: Used-Service-Unit ::=3D < AVP Header: 446 >=20 [ CC-Time ]=20 [ CC-Money ]=20 [ CC-Total-Octets ]=20 [ CC-Input-Octets ]=20 [ CC-Output-Octets ]=20 [ CC-Service-Specific-Units ]=20 *[ Service-Identifier ]=20 [ Rating-Group ] TO: Used-Service-Unit ::=3D < AVP Header: 446 >=20 [ Tariff-Time-Usage ] [ CC-Time ]=20 [ CC-Money ]=20 [ CC-Total-Octets ]=20 [ CC-Input-Octets ]=20 [ CC-Output-Octets ]=20 [ CC-Service-Specific-Units ]=20 *[ Service-Identifier ]=20 [ Rating-Group ] ADD: Section 8.xx Tariff-Time-Change AVP The Tariff-Time-Change AVP (AVP code TBD) is of type Time, and=20 includes the time in seconds since January 1, 1900 00:00 UTC when the tariff of the service will be changed. The tariff change mechanism is optional for client and server and it is not used for unit type time, since the server has full control of the time.=20 If a client does not support the tariff time change mechanism it must treat Tariff-Time-Change AVP in the answer message as an incorrect=20 CCA answer. In that case the client shall terminate credit control=20 session and indicate in the Termination-Cause AVP reason = DIAMETER_BAD_ANSWER.=20 ADD: Section 8.xx Tariff-Time-Usage AVP The Tariff-Time-Usage AVP (AVP code TBD) is of type Enumerated and = defines whether units are used before or after tariff change when a tariff change has = occurred=20 during the reporting period. Omission of this AVP means that no tariff = change=20 has been occurred. Tariff-Time-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 The used units contains the amount of the units before=20 tariff change, that is units measured from the point when the previous measurement ended to the point when tariff change occurred. UNIT_AFTER_TARIFF_CHANGE 1 The used units contains the amount of the units after tariff change has been occurred. *************************************************************************= ***** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message=20 (or responsible for delivery of the message to such person),=20 you may not copy or deliver this message to anyone. In such=20 case, you should destroy this message and kindly notify the=20 sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination,=20 disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited=20 and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages=20 of this kind. The opinions, conclusions and other information=20 in this message are of the author and shall be understood as=20 neither given nor endorsed by Vodafone Ireland Limited=20 unless it is otherwise indicated by an authorised representative=20 independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone=20 Ireland Limited has no control. As such, there is no guarantee that=20 (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender=20 (iii) this e-mail has not been intercepted by a third party=20 (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this=20 message (including its attachments) has been processed by an=20 automated anti-virus system; however it is the responsibility of=20 the recipient to ensure that the message (and attachments)=20 are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK),=20 Pauline Best (UK), Paul Donovan Chief Executive (UK),=20 Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18.=20 Number 326967 VAT Reg No. IE6346967G *************************************************************************= ***** ------_=_NextPart_001_01C3B7FC.AB12E89A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 John,
 
I=20 don't fully understand your case.
 
If the=20 CC server authorizes 10 blocks of 5K it means that it will convey one = G-S-U that=20 include
50000=20 total octets. The credit control client count the octets, I think it = doesn't=20 need to be concerned
about=20 the billing model. When the client report the U-S-Us is up to the server = to=20 reconstruct
how=20 many 5K blocks have been consumed before the tariff time change and how=20 many
after=20 the tariff time change, no?
 
If the=20 tariff change occured in the midle of a 5K block e.g. 12000 octets = consumed=20 before
tariff=20 change and 38000 octets consumed after tariff change, the server is able = to=20 deduce
that 2K of one 5K block have been consumed = before=20 tariff change and the rest 3K after = tariff
change. The server can then decide how to = treat this=20 block, right?
 
Regards
Marco
=
-----Original Message-----
From: ext=20 John.Prudhoe@vodafone.com = [mailto:John.Prudhoe@vodafone.com]
Sent:=20 28 November, 2003 17:53
To: Stura Marco (NET/Helsinki);=20 aaa-wg@merit.ed
Cc: Alexander Benni (NET/Helsinki);=20 crich@nortelnetworks.com; harri.hakala@ericsson.com; Loughney John=20 (NRC/Helsinki); Koskinen Juha-Pekka (NET/Tampere);=20 Karl-Heinz.Nenner@t-mobile.de; leena.mattila@ericsson.com;=20 owner-aaa-wg@merit.edu; patrik.teppo@ericsson.com
Subject: = Re:=20 [AAA-WG]: DCC Tariff time change support


Hi Marco,

I believe=20 there's also a special case to be considered, where the consumption of = a unit=20 straddles the tarrif time change.

I am=20 thinking for example of a data session over a 3G or 2.5G network and = let's say=20 it is being charged in blocks of 5K.  Let's say ten blocks are = authorised=20 at a time.  The client reports back on which of those were used = before=20 the tariff time change and which were used afterwards.  But there = is=20 almost always going to be one that straddles the time change, but it's = not=20 completely guaranteed.  The client can't group that one in with = the=20 others because it doesn't know the rules on charging. =

I suspect the solution is going to have to be = that the=20 client reports back whether or not a unit straddled the tariff time = change.=20  If it did, the total of those before and afterwards is one less = than the=20 total used.

Regards, =

John.
 



<marco.stura@nokia.com>
Sent by: = owner-aaa-wg@merit.edu=20

28/11/2003 14:35 =

        =
        To: =    =20    <aaa-wg@merit.edu>
        cc:      =20  <Karl-Heinz.Nenner@t-mobile.de>,=20 <crich@nortelnetworks.com>, = <Benni.Alexander@nokia.com>,=20 <patrik.teppo@ericsson.com>, = <john.loughney@nokia.com>,=20 <harri.hakala@ericsson.com>, = <leena.mattila@ericsson.com>,=20 <juha-pekka.koskinen@nokia.com>
        Subject:     =  =20  [AAA-WG]: Issue: DCC Tariff time change=20 support



Tariff Time change support
Submitter name: Marco = Stura
Submitter=20 email address: marco.stura@nokia.com
Date first submitted:=20 28.11.2003
Reference:
Document: Diameter CCA-01
Comment = type:=20 T
Priority: 2
Section:
Rationale/Explanation of = issue:

As=20 discussed on the mailing=20 = list:
http://www.merit.edu/mail.archives/aaa-wg/2003-11/msg00008.html<= BR>The=20 tariff change support shall be added to the cca.

Proposed=20 changed:

Section 5 Session Based Credit Control
ADD (at the = end of=20 the section):
The Diameter credit-control server and client may = optionally=20 support a
tariff change mechanism. The Diameter credit-control = server may=20 include
a Tariff-Time-Change AVP in the answer message. When the = Diameter=20 credit-
control client reports the used units and a tariff change = has=20 occurred
during the reporting period then the Diameter = credit-control=20 client
SHOULD itemize the units used before and after the tariff=20 change.

Section 8.16=20 Granted-Service-Unit
CHANGE:
FROM:
Granted-Service-Unit ::=3D = < AVP=20 Header: 431 >
              =  =20                  [ = CC-Time ]=20
                  =  =20              [ CC-Money ] =
   =20                     =  =20        [ CC-Total-Octets ]
    =    =20                     =  =20    [ CC-Input-Octets ]
        =    =20                     =  [=20 CC-Output-Octets ]
            =    =20                  [=20 CC-Service-Specific-Units ]
          =  =20                     = *[=20 Service-Identifier ]
            =  =20                    [ = Rating-Group ]
TO:
Granted-Service-Unit ::=3D < AVP Header: = 431 >=20
                  =  =20              [ Tariff-Time-Change=20 ]
                  =  =20              [ CC-Time ]
  =  =20                     =  =20        [ CC-Money ]
      =    =20                     =  =20  [ CC-Total-Octets ]
          =    =20                    [ = CC-Input-Octets ]
              =  =20                  [=20 CC-Output-Octets ]
            =    =20                  [=20 CC-Service-Specific-Units ]
          =  =20                     = *[=20 Service-Identifier ]
            =  =20                    [ = Rating-Group ]

Section 8.30 Used-Service-Unit=20 AVP
CHANGE:
FROM:
Used-Service-Unit ::=3D < AVP Header: = 446 >=20
                  =  =20              [ CC-Time ]
  =  =20                     =  =20        [ CC-Money ]
      =    =20                     =  =20  [ CC-Total-Octets ]
          =    =20                    [ = CC-Input-Octets ]
              =  =20                  [=20 CC-Output-Octets ]
            =    =20                  [=20 CC-Service-Specific-Units ]
          =  =20                     = *[=20 Service-Identifier ]
            =  =20                    [ = Rating-Group ]

TO:
Used-Service-Unit ::=3D < AVP Header: = 446 >=20
                  =  =20              [ Tariff-Time-Usage=20 ]
                  =  =20              [ CC-Time ]
  =  =20                     =  =20        [ CC-Money ]
      =    =20                     =  =20  [ CC-Total-Octets ]
          =    =20                    [ = CC-Input-Octets ]
              =  =20                  [=20 CC-Output-Octets ]
            =    =20                  [=20 CC-Service-Specific-Units ]
          =  =20                     = *[=20 Service-Identifier ]
            =  =20                    [ = Rating-Group ]

ADD:
Section 8.xx Tariff-Time-Change = AVP
The=20 Tariff-Time-Change AVP (AVP code TBD) is of type Time, and =
includes the=20 time in seconds since January 1, 1900 00:00 UTC when
the tariff of = the=20 service will be changed.
The tariff change mechanism is optional = for client=20 and server and
it is not used for unit type time, since the server = has=20 full
control of the time.
If a client does not support the = tariff time=20 change mechanism it
must treat Tariff-Time-Change AVP in the answer = message=20 as an incorrect
CCA = answer. In that=20 case the client shall terminate credit control
session and = indicate in the=20 Termination-Cause AVP reason DIAMETER_BAD_ANSWER. =

ADD:
Section 8.xx=20 Tariff-Time-Usage AVP
The Tariff-Time-Usage AVP (AVP code TBD) is = of type=20 Enumerated and defines whether
units are used before or after = tariff change=20 when a tariff change has occurred
during the reporting period. = Omission of=20 this AVP means that no tariff change
has been=20 occurred.

Tariff-Time-Usage can be one of the=20 following.

UNIT_BEFORE_TARIFF_CHANGE       =    =20          0
The used units contains the = amount of=20 the units before
tariff change, that is units measured from the = point=20 when
the previous measurement ended to the point when tariff=20 change
occurred.

UNIT_AFTER_TARIFF_CHANGE     =  =20               1
The used units = contains=20 the amount of the units after
tariff change has been=20 occurred.





********************************************************= **********************

The=20 content of this e-mail may be privileged and/or confidential.
If = you are=20 not the addressee indicated in this message
(or responsible for = delivery=20 of the message to such person),
you may not copy or deliver this = message=20 to anyone. In such
case, you should destroy this message and = kindly notify=20 the
sender and postmaster@vodafone.ie by reply email. = Please
note that=20 in such circumstances any review, dissemination,
disclosure, = alteration,=20 printing, copying or further transmission
of this e-mail and/or any = file=20 transmitted with it is prohibited
and may be unlawful. Please = advise us=20 immediately if you or
your employer do not consent to Internet = email for=20 messages
of this kind. The opinions, conclusions and other = information=20
in this message are of the author and shall be understood as =
neither=20 given nor endorsed by Vodafone Ireland Limited
unless it is = otherwise=20 indicated by an authorised representative
independent of this = message.=20 Internet e-mail is
transmitted over the public internet over which = Vodafone=20
Ireland Limited has no control. As such, there is no guarantee = that=20
(i) this e-mail will be delivered within a reasonable time or at=20 all
(ii) this e-mail comes from the purported sender
(iii) this = e-mail=20 has not been intercepted by a third party
(iv) the contents of = this e-mail=20 are unaltered from the time of
transmission. The presence of this = footnote=20 indicates that this
message (including its attachments) has been = processed=20 by an
automated anti-virus system; however it is the = responsibility of=20
the recipient to ensure that the message (and attachments)
are = safe=20 and authorised for use in their environment.
Vodafone Ireland Ltd=20 Directors: Peter Bamford Chairman (UK),
Pauline Best (UK), Paul = Donovan=20 Chief Executive (UK),
Gerry Fahy, Dermot Griffin, David Boorman, = David=20 Smithwhite(UK).
Registered in Ireland at MountainView, = Leopardstown, Dublin=20 18.
Number 326967 VAT Reg No.=20 = IE6346967G

*******************************************************= ***********************
 ------_=_NextPart_001_01C3B7FC.AB12E89A-- From owner-aaa-wg@merit.edu Mon Dec 1 09:16:12 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11124 for ; Mon, 1 Dec 2003 09:16:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EF7E591220; Mon, 1 Dec 2003 09:16:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF62491221; Mon, 1 Dec 2003 09:16:09 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4D9EB91220 for ; Mon, 1 Dec 2003 09:16:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A53D5E003; Mon, 1 Dec 2003 09:15:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 884265DFFE for ; Mon, 1 Dec 2003 09:15:46 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB1EFjI2022047; Mon, 1 Dec 2003 15:15:45 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 1 Dec 2003 15:16:00 +0100 Message-ID: From: "Leena Mattila (TU/LMF)" To: "'marco.stura@nokia.com'" , "'aaa-wg@merit.edu'" Cc: "'Karl-Heinz.Nenner@t-mobile.de'" , "'crich@nortelnetworks.com'" , "'Benni.Alexander@nokia.com'" , "Patrik Teppo (KA/EAB)" , "'john.loughney@nokia.com'" , "Harri Hakala (TU/LMF)" , "'juha-pekka.koskinen@nokia.com'" Subject: RE: [AAA-WG]: Issue: DCC Tariff time change support Date: Mon, 1 Dec 2003 15:14:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Marco, since the service rates are different before and after the tariff switch it might not be clear from the below text that the CC server should allocate the quota after the worst case, that is, the highest cost, in order to guarantee that the CC client never allows the end user to consume more units that are reserved from the user's account (before the tariff change). Could you add a sentence like "The granted units should be allocated based on the worst case scenario in case of fortcoming tariff change so that the reported used units after a tariff change will never exceed the credit reservation." to the proposed new text in Section 5? Thanks, Leena > -----Original Message----- > From: owner-aaa-wg@merit.edu > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > marco.stura@nokia.com > Sent: 28. marraskuuta 2003 16:36 > To: aaa-wg@merit.edu > Cc: Karl-Heinz.Nenner@t-mobile.de; crich@nortelnetworks.com; > Benni.Alexander@nokia.com; Patrik Teppo (KA/EAB); > john.loughney@nokia.com; Harri Hakala (TU/LMF); Leena Mattila > (TU/LMF); > juha-pekka.koskinen@nokia.com > Subject: [AAA-WG]: Issue: DCC Tariff time change support > > > Tariff Time change support > Submitter name: Marco Stura > Submitter email address: marco.stura@nokia.com > Date first submitted: 28.11.2003 > Reference: > Document: Diameter CCA-01 > Comment type: T > Priority: 2 > Section: > Rationale/Explanation of issue: > > As discussed on the mailing list: > http://www.merit.edu/mail.archives/aaa-wg/2003-11/msg00008.html > The tariff change support shall be added to the cca. > > Proposed change: > > Section 5 Session Based Credit Control > ADD (at the end of the section): > The Diameter credit-control server and client may optionally > support a > tariff change mechanism. The Diameter credit-control server > may include > a Tariff-Time-Change AVP in the answer message. When the > Diameter credit- > control client reports the used units and a tariff change has occurred > during the reporting period then the Diameter credit-control client > SHOULD itemize the units used before and after the tariff change. > > Section 8.16 Granted-Service-Unit > CHANGE: > FROM: > Granted-Service-Unit ::= < AVP Header: 431 > > [ CC-Time ] > [ CC-Money ] > [ CC-Total-Octets ] > [ CC-Input-Octets ] > [ CC-Output-Octets ] > [ CC-Service-Specific-Units ] > *[ Service-Identifier ] > [ Rating-Group ] > TO: > Granted-Service-Unit ::= < AVP Header: 431 > > [ Tariff-Time-Change ] > [ CC-Time ] > [ CC-Money ] > [ CC-Total-Octets ] > [ CC-Input-Octets ] > [ CC-Output-Octets ] > [ CC-Service-Specific-Units ] > *[ Service-Identifier ] > [ Rating-Group ] > > Section 8.30 Used-Service-Unit AVP > CHANGE: > FROM: > Used-Service-Unit ::= < AVP Header: 446 > > [ CC-Time ] > [ CC-Money ] > [ CC-Total-Octets ] > [ CC-Input-Octets ] > [ CC-Output-Octets ] > [ CC-Service-Specific-Units ] > *[ Service-Identifier ] > [ Rating-Group ] > > TO: > Used-Service-Unit ::= < AVP Header: 446 > > [ Tariff-Time-Usage ] > [ CC-Time ] > [ CC-Money ] > [ CC-Total-Octets ] > [ CC-Input-Octets ] > [ CC-Output-Octets ] > [ CC-Service-Specific-Units ] > *[ Service-Identifier ] > [ Rating-Group ] > > ADD: > Section 8.xx Tariff-Time-Change AVP > The Tariff-Time-Change AVP (AVP code TBD) is of type Time, and > includes the time in seconds since January 1, 1900 00:00 UTC when > the tariff of the service will be changed. > The tariff change mechanism is optional for client and server and > it is not used for unit type time, since the server has full > control of the time. > If a client does not support the tariff time change mechanism it > must treat Tariff-Time-Change AVP in the answer message as an > incorrect > CCA answer. In that case the client shall terminate credit control > session and indicate in the Termination-Cause AVP reason > DIAMETER_BAD_ANSWER. > > ADD: > Section 8.xx Tariff-Time-Usage AVP > The Tariff-Time-Usage AVP (AVP code TBD) is of type > Enumerated and defines whether > units are used before or after tariff change when a tariff > change has occurred > during the reporting period. Omission of this AVP means that > no tariff change > has been occurred. > > Tariff-Time-Usage can be one of the following. > > UNIT_BEFORE_TARIFF_CHANGE 0 > The used units contains the amount of the units before > tariff change, that is units measured from the point when > the previous measurement ended to the point when tariff change > occurred. > > UNIT_AFTER_TARIFF_CHANGE 1 > The used units contains the amount of the units after > tariff change has been occurred. > From owner-aaa-wg@merit.edu Fri Dec 5 07:02:47 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01861 for ; Fri, 5 Dec 2003 07:02:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5CC35912C3; Fri, 5 Dec 2003 07:02:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A243912C5; Fri, 5 Dec 2003 07:02:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5287E912C3 for ; Fri, 5 Dec 2003 07:02:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D6B45DDAD; Fri, 5 Dec 2003 07:02:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 5A0B05DDC1 for ; Fri, 5 Dec 2003 07:02:30 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB5C2R124398 for ; Fri, 5 Dec 2003 14:02:27 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Dec 2003 14:02:23 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 5 Dec 2003 14:02:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Issue: DCC tariff time change support (rev. 1) Date: Fri, 5 Dec 2003 14:02:22 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C81E3@esebe016.ntc.nokia.com> Thread-Topic: Issue: DCC tariff time change support (rev. 1) Thread-Index: AcO7J6QYOy60n6/GRL6XJrGmTf1pZQ== From: To: , , Cc: , , , , , , X-OriginalArrivalTime: 05 Dec 2003 12:02:22.0985 (UTC) FILETIME=[A4396790:01C3BB27] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, I have incorporated all the comments in this revision of the original proposal. I also changed the name of the Tariff-Time-Usage AVP to Tariff-Change-Usage. Regards Marco ***************************************************** Tariff Time change support Submitter name: Marco Stura Submitter email address: marco.stura@nokia.com Date first submitted: 28.11.2003 Reference:=20 Document: Diameter CCA-01 Comment type: T Priority: 2 Section:=20 Rationale/Explanation of issue: As discussed on the mailing list: http://www.merit.edu/mail.archives/aaa-wg/2003-11/msg00008.html The tariff change support shall be added to the cca. Proposed changed: Section 5 Session Based Credit Control ADD (at the end of the section): The Diameter credit-control server and client may optionally support a=20 tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted=20 units should be allocated based on the worst case scenario in case of=20 forthcoming tariff change, so that the overall reported used units will=20 never exceed the credit reservation. When the Diameter credit-control client reports the used units and a=20 tariff change has occurred during the reporting period then the Diameter = credit-control client SHOULD itemize the units used before and after=20 the tariff change. In case some units straddled the tariff change, the credit-control client SHOULD itemize those units as well. Section 8.16 Granted-Service-Unit CHANGE: FROM: Granted-Service-Unit ::=3D < AVP Header: 431 >=20 [ CC-Time ]=20 [ CC-Money ]=20 [ CC-Total-Octets ]=20 [ CC-Input-Octets ]=20 [ CC-Output-Octets ]=20 [ CC-Service-Specific-Units ]=20 *[ Service-Identifier ]=20 [ Rating-Group ]=20 TO: Granted-Service-Unit ::=3D < AVP Header: 431 >=20 [ Tariff-Time-Change ] [ CC-Time ]=20 [ CC-Money ]=20 [ CC-Total-Octets ]=20 [ CC-Input-Octets ]=20 [ CC-Output-Octets ]=20 [ CC-Service-Specific-Units ]=20 *[ Service-Identifier ]=20 [ Rating-Group ]=20 Section 8.30 Used-Service-Unit AVP CHANGE: FROM: Used-Service-Unit ::=3D < AVP Header: 446 >=20 [ CC-Time ]=20 [ CC-Money ]=20 [ CC-Total-Octets ]=20 [ CC-Input-Octets ]=20 [ CC-Output-Octets ]=20 [ CC-Service-Specific-Units ]=20 *[ Service-Identifier ]=20 [ Rating-Group ] TO: Used-Service-Unit ::=3D < AVP Header: 446 >=20 [ Tariff-Change-Usage ] [ CC-Time ]=20 [ CC-Money ]=20 [ CC-Total-Octets ]=20 [ CC-Input-Octets ]=20 [ CC-Output-Octets ]=20 [ CC-Service-Specific-Units ]=20 *[ Service-Identifier ]=20 [ Rating-Group ] ADD: Section 8.xx Tariff-Time-Change AVP The Tariff-Time-Change AVP (AVP code TBD) is of type Time, and=20 includes the time in seconds since January 1, 1900 00:00 UTC when the tariff of the service will be changed. The tariff change mechanism is optional for client and server and it is not used for unit type time, since the server has full control of the time.=20 If a client does not support the tariff time change mechanism it must treat Tariff-Time-Change AVP in the answer message as an incorrect CCA answer. In that case the client shall terminate credit control=20 session and indicate in the Termination-Cause AVP reason = DIAMETER_BAD_ANSWER.=20 ADD: Section 8.xx Tariff-Change-Usage AVP The Tariff-Change-Usage AVP (AVP code TBD) is of type Enumerated and = defines whether units are used before, after or straddled tariff change when a tariff = change has occurred=20 during the reporting period. Omission of this AVP means that no tariff = change=20 has been occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 The used units contains the amount of the units before=20 tariff change, that is units measured from the point when the previous measurement ended to the point when tariff change occurred. UNIT_AFTER_TARIFF_CHANGE 1 The used units contains the amount of the units after tariff change has been occurred. UNIT_INDETERMINATE 2 The used units contains the amount of units that straddle the tariff change (e.g. the metering process reports to the credit- control-client in blocks of n octets and one block straddled the tariff change).=20 From owner-aaa-wg@merit.edu Fri Dec 5 09:21:42 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06624 for ; Fri, 5 Dec 2003 09:21:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 769DF912C8; Fri, 5 Dec 2003 09:21:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 33C21912C9; Fri, 5 Dec 2003 09:21:42 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF747912C8 for ; Fri, 5 Dec 2003 09:21:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id BA0725DD8C; Fri, 5 Dec 2003 09:21:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id AA29D5DDF4 for ; Fri, 5 Dec 2003 09:21:39 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB5ELbZ20650 for ; Fri, 5 Dec 2003 16:21:37 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Dec 2003 16:21:36 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 5 Dec 2003 16:21:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Issue: Free-of-charge & deny semantic for multiple services in one user session Date: Fri, 5 Dec 2003 16:21:36 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C81F4@esebe016.ntc.nokia.com> Thread-Topic: Issue: Free-of-charge & deny semantic for multiple services in one user session Thread-Index: AcO7Oxc90Gv+SWHlR6GNOunx9/xqFA== From: To: Cc: , , , , , , , X-OriginalArrivalTime: 05 Dec 2003 14:21:36.0707 (UTC) FILETIME=[176E3930:01C3BB3B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Free-of-charge & deny semantic for multiple services in one user session = Submitter name: Marco Stura Submitter email address: marco.stura@nokia.com Date first submitted: 5.11.2003 Reference:=20 Document: Diameter CCA-01 Comment type: T Priority: 2 Section:=20 Rationale/Explanation of issue: The DCC application support for multiple services in one user session, = one single credit control session can be used to request and grant multiple quotas to a set of = end-user services. However, one or more of the services requested in one = Credit-Control-Request may end-up to be free-of-charge or may be denied because of low credit. The DCC support = only mechanisms to indicate this at CC session level, a semantic to indicate free-of-charge or deny = at quota level is needed for the support of multiple services in one user session. Proposed changed:=20 Section 8.16 Granted-Service-Unit AVP ADD (at the end of the second paragraph): A value of 0 (zero) granted service unit associated to a = Service-Identifier(s) or Rating-Group indicates that the corresponding traffic MUST be denied. Note that in = case the credit-control=20 server want to disconnect the user and close the credit-control session, = it SHOULD use the=20 appropriate error code in the Credit-Control-Answer message rather than = including n times the Granted-Service-Units AVPs with the value of 0 (zero).=20 In contrast, a value of max type granted service unit (e.g. max Unsigned = 32 is FFFFFFFF)=20 associated to a Service-Identifier(s) or Rating-Group indicates that the = corresponding traffic=20 is free-of-charge. With unit type money, the value of the Exponent AVP = is set to 0 (zero) when=20 free-of-charge is indicated. With unit type service specific, the value = of the CC-Service-Specific-Units AVP is set to FFFFFFFF to indicate free-of-charge. From aaa-admin@ietf.org Fri Dec 5 16:30:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27543 for ; Fri, 5 Dec 2003 16:30:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASNWV-0006zs-8u; Fri, 05 Dec 2003 16:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASNVh-0006zG-H4 for aaa@optimus.ietf.org; Fri, 05 Dec 2003 16:29:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27492 for ; Fri, 5 Dec 2003 16:28:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASNVf-0002re-00 for aaa@ietf.org; Fri, 05 Dec 2003 16:29:11 -0500 Received: from [211.41.233.234] (helo=211.41.233.234) by ietf-mx with smtp (Exim 4.12) id 1ASNVe-0002rO-00 for aaa@ietf.org; Fri, 05 Dec 2003 16:29:10 -0500 Date: Sat, 06 Dec 2003 00:33:10 -0500 From: Visa International Service X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Reply-To: Visa International Service Organization: Visa International Service X-Priority: 3 (Normal) To: aaa@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Content-Transfer-Encoding: 8bit Subject: [Aaa] Visa Security Update Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Secure with Visa

Dear Customer,

Our latest security system will help you to avoid possible fraud actions and
keep your investments in safety.

Due to technical security update you have to reactivate your account

Click on the link below to login to your updated Visa account.

To log into your account, please visit the Visa Website at

http://www.visa.com

We respect your time and business.
It's our pleasure to serve you.


 Please don't reply to this email. This e-mail was generated by a mail handling system.




Copyright 1996-2003, Visa International Service Association. All rights reserved.


_______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Fri Dec 5 16:30:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27558 for ; Fri, 5 Dec 2003 16:30:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASNWe-00070u-Lb for aaa-archive@odin.ietf.org; Fri, 05 Dec 2003 16:30:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5LUCfM026954 for aaa-archive@odin.ietf.org; Fri, 5 Dec 2003 16:30:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASNWe-00070f-HI for aaa-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 16:30:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27507 for ; Fri, 5 Dec 2003 16:29:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASNWc-0002sW-00 for aaa-web-archive@ietf.org; Fri, 05 Dec 2003 16:30:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASNWc-0002sS-00 for aaa-web-archive@ietf.org; Fri, 05 Dec 2003 16:30:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASNWV-0006zs-8u; Fri, 05 Dec 2003 16:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASNVh-0006zG-H4 for aaa@optimus.ietf.org; Fri, 05 Dec 2003 16:29:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27492 for ; Fri, 5 Dec 2003 16:28:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASNVf-0002re-00 for aaa@ietf.org; Fri, 05 Dec 2003 16:29:11 -0500 Received: from [211.41.233.234] (helo=211.41.233.234) by ietf-mx with smtp (Exim 4.12) id 1ASNVe-0002rO-00 for aaa@ietf.org; Fri, 05 Dec 2003 16:29:10 -0500 Date: Sat, 06 Dec 2003 00:33:10 -0500 From: Visa International Service X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Reply-To: Visa International Service Organization: Visa International Service X-Priority: 3 (Normal) To: aaa@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Content-Transfer-Encoding: 8bit Subject: [Aaa] Visa Security Update Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Secure with Visa

Dear Customer,

Our latest security system will help you to avoid possible fraud actions and
keep your investments in safety.

Due to technical security update you have to reactivate your account

Click on the link below to login to your updated Visa account.

To log into your account, please visit the Visa Website at

http://www.visa.com

We respect your time and business.
It's our pleasure to serve you.


 Please don't reply to this email. This e-mail was generated by a mail handling system.




Copyright 1996-2003, Visa International Service Association. All rights reserved.


_______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Sun Dec 7 03:58:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17641 for ; Sun, 7 Dec 2003 03:58:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4AC5591220; Sun, 7 Dec 2003 03:58:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 20B9A91222; Sun, 7 Dec 2003 03:58:37 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F25CB91220 for ; Sun, 7 Dec 2003 03:58:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id E155E5DEAB; Sun, 7 Dec 2003 03:58:35 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (unknown [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 2901F5DE91 for ; Sun, 7 Dec 2003 03:58:35 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB78wYI2001059 for ; Sun, 7 Dec 2003 09:58:34 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Sun, 7 Dec 2003 09:59:11 +0100 Message-ID: From: "Miguel Garcia A (JO/LMF)" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Registration of the aaa URI scheme Date: Sun, 7 Dec 2003 09:58:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi: I was browsing the IANA pages where all the URI schemes are registered, http://iana.netnod.se/assignments/uri-schemes and I found out that the aaa URI sheme is not registered there, in spite that is defined/used in RFC 3588 (see section 4.3) there. I believe the aaa URI scheme should be registered by IANA. I was trying to find out whether RFC 3588 is the normative document for the definition of the aaa URI. I have the feeling it isn't, since the aaa URI is used not only by Diameter, but by some other protocols (perhaps RADIUS?). Can anyone clarify the above statements? Regards, Miguel From owner-aaa-wg@merit.edu Sun Dec 7 15:39:41 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03131 for ; Sun, 7 Dec 2003 15:39:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6FE5191221; Sun, 7 Dec 2003 15:39:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3DBB891223; Sun, 7 Dec 2003 15:39:40 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 540AC91221 for ; Sun, 7 Dec 2003 15:39:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3AAC75DEA9; Sun, 7 Dec 2003 15:39:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 857615DEDB for ; Sun, 7 Dec 2003 15:39:38 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hB7Kw4O10895 for ; Sun, 7 Dec 2003 12:58:04 -0800 Date: Sun, 7 Dec 2003 12:58:04 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG Roadmap Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk As John Loughney noted at IETF 58, IETF 59 will represent the last meeting of the AAA WG. Since the WG is in the process of wrapping up, it is important that we make rapid progress in completing documents in process. In particular, there are two documents that have already been through AAA WG last call, IETF last call and IESG evaluation: Diameter NASREQ and Diameter MOBILE IPv4. These two documents are both now awaiting AUTHOR REVISION. In order to keep on schedule, it is important that we get the author revisions made quickly, so that the documents can be approved for publication as an RFC. I'd like to propose that revised versions of these documents be submitted this week, so that these documents can get on the agenda for the next IESG telechat. As we discussed at IETF 58, the Diameter EAP document has resolved many of the outstanding issues and is approaching AAA WG last call. I'd like to propose that a new revision be submitted by the end of the month that addresses the currently open issues, so that we can begin AAA WG last call. Similarly, work on Diameter Credit Control and SIP applications are progressing. Our goal is to address all the outstanding issues on these documents ASAP so that we can bring them to AAA WG last call as soon as possible. From owner-aaa-wg@merit.edu Mon Dec 8 08:04:51 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08211 for ; Mon, 8 Dec 2003 08:04:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E161091229; Mon, 8 Dec 2003 08:04:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF3749122A; Mon, 8 Dec 2003 08:04:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6EF7391229 for ; Mon, 8 Dec 2003 08:04:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id A1DE15DE5A; Mon, 8 Dec 2003 08:04:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (unknown [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id 1FC895DE51 for ; Mon, 8 Dec 2003 08:04:41 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB8D4dSs021811; Mon, 8 Dec 2003 14:04:39 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 8 Dec 2003 14:05:21 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: aaa-wg@merit.edu Cc: john.loughney@nokia.com, juha-pekka.koskinen@nokia.com, "Leena Mattila (TU/LMF)" , "'marco.stura@nokia.com'" Subject: [AAA-WG]: Issue: DCC Service-Identifier AVP in command level Date: Mon, 8 Dec 2003 14:04:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Service-Identifier AVP in command level Submitter name: Harri Hakala Submitter email address: harri.hakala@ericsson.com Date first submitted: 8.12.2003 Reference: Document: Diameter CCA-01 Comment type: T Priority: 2 Section: Rationale/Explanation of issue: We introduced last time (cca-01) the Service-Identifier AVP for multiple services in a single credit control session. This AVP is used within Requested-Service Unit AVP. Reading the description of the Service-Identifier AVP one can get easily impression that the AVP can be used to identify the given service for ordinary credit control sessions as well, and not only in case of multiple services in a single credit control session. Actually, this is something what would be very useful for all credit control sessions. Therefore we propose to lift Service-Identifier AVP to the CCR command level as well. Proposed changed: Section 3.1, Credit-Control-Request (CCR) Command ADD Service-Identifier AVP to the CCR command, i.e.: Message Format ::= < Diameter Header: 272, REQ, PXY > < Session-Id > { Origin-Host } . . . [ Service-Identifier ] . . . Section 8, Credit Control AVPs ADD: +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST| | Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| ------------------------------------------|----+-----+----+-----|----| Service-Identifier 439 8.40 UTF8String| M | P | | V | Y | 10.1 Credit Control AVP Table ADD: +-----------+ | Command | | Code | |-----+-----+ Attribute Name | CCR | CCA | ------------------------------|-----+-----+ Service-Identifier | 0-1 | 0 | From owner-aaa-wg@merit.edu Wed Dec 10 08:57:03 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11921 for ; Wed, 10 Dec 2003 08:57:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 51F8E91249; Wed, 10 Dec 2003 08:56:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1DA5C9124A; Wed, 10 Dec 2003 08:56:52 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5715491249 for ; Wed, 10 Dec 2003 08:56:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 41E205DEA1; Wed, 10 Dec 2003 08:56:50 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id A14855DE77 for ; Wed, 10 Dec 2003 08:56:49 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBADumSs008987; Wed, 10 Dec 2003 14:56:48 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 10 Dec 2003 14:57:38 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: aaa-wg@merit.edu Cc: Benni.Alexander@nokia.com, crich@nortelnetworks.com, john.loughney@nokia.com, juha-pekka.koskinen@nokia.com, Karl-Heinz.Nenner@t-mobile.de, "Patrik Teppo (KA/EAB)" , "Leena Mattila (TU/LMF)" , "'marco.stura@nokia.com'" Subject: [AAA-WG]: Issue: DCC Service-specific Rating Input and Interoperability Date: Wed, 10 Dec 2003 14:56:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk DCC Service-specific Rating Input and Interoperability Submitter name: Harri Hakala Submitter email address: harri.hakala@ericsson.com Date first submitted: 10.12.2003 Reference: Document: Diameter CCA-01 Comment type: T Priority: 2 Section: Rationale/Explanation of issue: To clarify cca interoperability and how to provide service specific rating input, we propose to change the existing 4.1 section to this new 4.1 section. Proposed changed: Replace the exiting 4.1 (Rating Input) section with this one: 4.1 Service-specific Rating Input and Interoperability The Diameter Credit Control Application provides generic credit control mechanisms supporting multiple service applications. The Credit Control Application, therefore, does not define AVPs that could be used as input in the rating process. Listing the possible services that could use this Diameter application is seen as out of scope for this generic mechanism as well. It is reasonable to expect that there will exist a service level agreement between providers of the credit control client and the credit control server covering the charging, services offered, roaming agreements, agreed rating input, etc. There are two ways for providing rating input to the credit control server, either by using AVPs or by including them in the Service- Parameter-Info AVP. The general principle for sending rating parameters is that the service SHOULD re-use existing AVPs, if the service can use AVPs defined in existing service specific Diameter applications (e.g. NASREQ for network access services). Alternatively, new AVPs can be defined if the existing AVPs do not provide sufficient rating information. The Service-Parameter-Info AVP MAY be used as a container to pass legacy rating information in its original encoded form (e.g. ASN.1 BER). In that case the rating input is embedded in the Service-Parameter-Info AVP as defined in section 8.23. New service applications SHOULD favor the use of explicitly defined AVP's, to simplify interoperability. Additionally, the services can be identified using the Service-Identifier AVP that SHOULD be a unique identifier for a given service as defined in section 8.40. The service specific rating input AVPs, the contents of the Service-Parameter-Info AVP or Service-Identifier AVP are not within the scope of this document. To facilitate interoperability, it is RECOMMENDED that the rating input and values of service identifiers are coordinated via an informational RFC or other permanent and readily available reference such as the specification of another cooperative standardization body (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services may be deployed that are subject to agreements between providers of the credit control server and client. Within a credit control request, setting the "M" bit implies that a rating server or the credit control server itself SHOULD understand the AVP in order to rate the service. However, since different service providers may apply different rating policies a mandatory input parameter for one server might be irrelevant for another. Therefore, if the AVP is not relevant to the rating process, when the AVP is included within a credit-control request, it can be ignored, even if the "M" bit is set. In case a rating input required for the rating process is missing from the Credit control request, the Credit control answer MUST contain error code DIAMETER_RATING_FAILED. A CCR message with this error MUST contain one or more Failed-AVP AVPs containing the missing AVPs that caused the failure. From owner-aaa-wg@merit.edu Wed Dec 10 09:11:07 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12333 for ; Wed, 10 Dec 2003 09:11:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B0A899124A; Wed, 10 Dec 2003 09:10:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C4E39124B; Wed, 10 Dec 2003 09:10:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2928B9124A for ; Wed, 10 Dec 2003 09:10:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 15C655DE7D; Wed, 10 Dec 2003 09:10:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 0F8595DE77 for ; Wed, 10 Dec 2003 09:10:52 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBAEAln05829 for ; Wed, 10 Dec 2003 16:10:48 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Dec 2003 15:58:33 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 10 Dec 2003 15:58:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Issue: DCC Format and coordination of the Service-Identifier Date: Wed, 10 Dec 2003 15:58:31 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C8220@esebe016.ntc.nokia.com> Thread-Topic: Issue: DCC Format and coordination of the Service-Identifier Thread-Index: AcO/JbGCGYHbJVflT6We3S2Ve3d9TQ== From: To: Cc: , , , , , , , X-OriginalArrivalTime: 10 Dec 2003 13:58:31.0784 (UTC) FILETIME=[B2047E80:01C3BF25] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable DCC Format and coordination of the Service-Identifier Submitter name: Marco Stura Submitter email address: marco.stura@nokia.com Date first submitted: 10.11.2003 Reference:=20 Document: Diameter CCA-01 Comment type: T Priority: 2 Section:=20 Rationale/Explanation of issue: We introduced the Service-Identifier AVP for multiple services in a = single credit control session in the draf-01. Lately we also lifted the = Service-Identifier AVP at command level to enable identification of a given service for credit-control sessions = as well. We still need to define the format of the service identifier and add = some coordination considerations to facilitate interoperability. Proposed changed: Section 8.40, Service-Identifier AVP Change FROM The Service-Identifier AVP is of type UTF8String (AVP Code 439) and = contains a unique identifier of a given service. This is an identifier = allocated by the service provider and MUST uniquely identify a given = service (e.g. Service 1@example.com).=20 A usage example of this AVP is illustrated in Appendix A (Flow X).=20 TO The Service-Identifier AVP is of type UTF8String (AVP Code 439) and contains a unique identifier of a service. This is an identifier allocated by the service provider, by the service element manufacturer=20 or by a standardization body and MUST uniquely identify a given service. = The format of the service identifier is: "service-identifier" "@" = "domain". service-identifier =3D Token The Token is an arbitrary string of characters and digits. domain =3D represents the entity that allocated the service-identifier. It can be ietf.org, 3gpp.org etc. if the identifier is=20 allocated by a standardization body, or it can be the FQDN of the service provider (e.g. provider.com) or of the vendor (e.g. vendor.com) if the identifier is allocated by a private entity. Services that are for private use only, i.e. to one provider's own use, = where=20 no interoperability is deemed useful may define private identifiers = without=20 need of coordination. However, when interoperability is wanted, = coordination=20 of the identifiers via e.g. publication of informational RFC is = RECOMMENDED to=20 make Service-Identifier globally available. A usage example of this AVP for multiple services in one user session is = illustrated in Appendix A (Flow X). From aaa-admin@ietf.org Wed Dec 10 17:26:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21785 for ; Wed, 10 Dec 2003 17:26:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUCmP-0002RS-T6; Wed, 10 Dec 2003 17:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUClT-0002Qg-Ui for aaa@optimus.ietf.org; Wed, 10 Dec 2003 17:25:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21745 for ; Wed, 10 Dec 2003 17:25:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUClQ-0003bf-00 for aaa@ietf.org; Wed, 10 Dec 2003 17:25:00 -0500 Received: from c-24-3-237-98.client.comcast.net ([24.3.237.98] helo=24.3.237.98) by ietf-mx with smtp (Exim 4.12) id 1AUClQ-0003bb-00 for aaa@ietf.org; Wed, 10 Dec 2003 17:25:00 -0500 Date: Wed, 10 Dec 2003 13:22:03 -0500 From: 241017@aol.com X-Mailer: AspMail 3.53 (SMTP6F169C) Reply-To: 241017@email.com Organization: 406907233 X-Priority: 3 (Normal) To: aaa@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Content-Transfer-Encoding: 8bit Subject: [Aaa] Adobe Illustrator 10 OEM 241017 Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit OEM Software
Specials good thru 11/12/03. Please use discount code mail9221 to receive these prices.

Software: Windows XP Suites, Adobe software, Clearance, Corel Draw/Corel Ventura, Games, 3D Studio Max, Operating Systems, Utilities.
Microsoft Windows XP Professional OEM 

PowerQuest Partition Magic 8 (CD and Manual) Only $39.95  
Savings -$49.50

Microsoft Windows XP Professional goes beyond the benefits of Windows XP Home Edition with advanced capabilities designed specifically to.. PowerQuest Partition Magic 8 (CD and Manual)
* Use this Discount Code at Checkout: mail9872

Adobe Photoshop 7.0 OEM

Microsoft Works Suite 2003 (OEM) W/ Word 2002 Only $59.95
Savings -$255.50

Adobe Photoshop 7.0 software the professional image-editing standard helps you work more efficiently.. Microsoft Works Suite 2003 (OEM) W/ Word 2002
* Use this Discount Code at Checkout: mail9872

Microsoft Office XP Professional OEM

Symantec pcAnywhere 10.5 Host/Remote OEM CD Only $59.95
Savings -$50.50

Microsoft Windows XP Professional is a Windows operating system designed for businesses of all sizes and for individuals who demand the most from their computing Symantec pcAnywhere 10.5 Host/Remote OEM CD
* Use this Discount Code at Checkout: mail9872


Adobe Illustrator 10 OEM

Symantec Norton SystemWorks 2003 Pro OEM CD Only $59.95
Savings -$215.50

ENHANCED! Adobe Illustrator 10 software defines the future of vector graphics with groundbreaking creative options and powerful tools for efficiently publishing artwork on the Web, in print, everywhere...  Symantec Norton SystemWorks 2003 Pro OEM CD
* Use this Discount Code at Checkout: mail9872

_______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Wed Dec 10 17:26:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21800 for ; Wed, 10 Dec 2003 17:26:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUCma-0002TZ-5h for aaa-archive@odin.ietf.org; Wed, 10 Dec 2003 17:26:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAMQC7L009513 for aaa-archive@odin.ietf.org; Wed, 10 Dec 2003 17:26:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUCma-0002TM-2I for aaa-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 17:26:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21764 for ; Wed, 10 Dec 2003 17:26:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUCmW-0003cG-00 for aaa-web-archive@ietf.org; Wed, 10 Dec 2003 17:26:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUCmW-0003cC-00 for aaa-web-archive@ietf.org; Wed, 10 Dec 2003 17:26:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUCmP-0002RS-T6; Wed, 10 Dec 2003 17:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUClT-0002Qg-Ui for aaa@optimus.ietf.org; Wed, 10 Dec 2003 17:25:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21745 for ; Wed, 10 Dec 2003 17:25:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUClQ-0003bf-00 for aaa@ietf.org; Wed, 10 Dec 2003 17:25:00 -0500 Received: from c-24-3-237-98.client.comcast.net ([24.3.237.98] helo=24.3.237.98) by ietf-mx with smtp (Exim 4.12) id 1AUClQ-0003bb-00 for aaa@ietf.org; Wed, 10 Dec 2003 17:25:00 -0500 Date: Wed, 10 Dec 2003 13:22:03 -0500 From: 241017@aol.com X-Mailer: AspMail 3.53 (SMTP6F169C) Reply-To: 241017@email.com Organization: 406907233 X-Priority: 3 (Normal) To: aaa@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Content-Transfer-Encoding: 8bit Subject: [Aaa] Adobe Illustrator 10 OEM 241017 Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit OEM Software
Specials good thru 11/12/03. Please use discount code mail9221 to receive these prices.

Software: Windows XP Suites, Adobe software, Clearance, Corel Draw/Corel Ventura, Games, 3D Studio Max, Operating Systems, Utilities.
Microsoft Windows XP Professional OEM 

PowerQuest Partition Magic 8 (CD and Manual) Only $39.95  
Savings -$49.50

Microsoft Windows XP Professional goes beyond the benefits of Windows XP Home Edition with advanced capabilities designed specifically to.. PowerQuest Partition Magic 8 (CD and Manual)
* Use this Discount Code at Checkout: mail9872

Adobe Photoshop 7.0 OEM

Microsoft Works Suite 2003 (OEM) W/ Word 2002 Only $59.95
Savings -$255.50

Adobe Photoshop 7.0 software the professional image-editing standard helps you work more efficiently.. Microsoft Works Suite 2003 (OEM) W/ Word 2002
* Use this Discount Code at Checkout: mail9872

Microsoft Office XP Professional OEM

Symantec pcAnywhere 10.5 Host/Remote OEM CD Only $59.95
Savings -$50.50

Microsoft Windows XP Professional is a Windows operating system designed for businesses of all sizes and for individuals who demand the most from their computing Symantec pcAnywhere 10.5 Host/Remote OEM CD
* Use this Discount Code at Checkout: mail9872


Adobe Illustrator 10 OEM

Symantec Norton SystemWorks 2003 Pro OEM CD Only $59.95
Savings -$215.50

ENHANCED! Adobe Illustrator 10 software defines the future of vector graphics with groundbreaking creative options and powerful tools for efficiently publishing artwork on the Web, in print, everywhere...  Symantec Norton SystemWorks 2003 Pro OEM CD
* Use this Discount Code at Checkout: mail9872

_______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Thu Dec 11 07:49:03 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28055 for ; Thu, 11 Dec 2003 07:49:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 01A0D91263; Thu, 11 Dec 2003 07:48:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B1DF091214; Thu, 11 Dec 2003 07:48:47 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C95A91263 for ; Thu, 11 Dec 2003 07:48:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id E22835DE0C; Thu, 11 Dec 2003 07:48:45 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 4F0F85DDFB; Thu, 11 Dec 2003 07:48:45 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBBCmhI2017282; Thu, 11 Dec 2003 13:48:43 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Dec 2003 13:49:36 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'John.Prudhoe@vodafone.com'" Cc: aaa-wg@merit.edu, Benni.Alexander@nokia.com, crich@nortelnetworks.com, john.loughney@nokia.com, juha-pekka.koskinen@nokia.com, Karl-Heinz.Nenner@t-mobile.de, "Leena Mattila (TU/LMF)" , "'marco.stura@nokia.com'" , owner-aaa-wg@merit.edu, "Patrik Teppo (KA/EAB)" Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero perability Date: Thu, 11 Dec 2003 13:48:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi John, Thank you for your feedback. It is true that our current text is incomplete and it needs some clarifications. We assume that there exists agreement between providers of the credit control client and server covering mandatory/non-mandatory rating input AVPs as well, since depending on the provider's billing policy a mandatory input parameter for one provider might be irrelevant for another. Therefore it may be good to have a configuration option that would prevent mandatory AVPs to be sent if not relevant to the rating process. This is also fully compliant with RFC 3588 section 4.1. Perhaps it would be good also clarify how *[AVP] notation in CCR command should be interpreted. It may reasonable to add sentence that service applications should define what AVPs they are planning to use as input to rating process. How it sounds if we add following sentence before the M-bit discussion: "It is RECOMMENDED that service applications define what existing AVPs or new AVPs are used as input to the rating process and thus need to be included in the Credit-Control-Request command by a Diameter Credit Control Client as *[AVP]." and change the M-bit paragraph in this way: "Within a credit control request, setting the "M" bit implies that a rating server or the credit control server itself SHOULD understand the AVP in order to rate the service. However, since different service providers may apply different rating policies a mandatory input parameter for one server might be irrelevant for another. Therefore, to simplify interoperability a configuration option SHOULD be provided per peer or per realm basis that would prevent particular mandatory AVPs to be sent if not relevant to the rating process of a given credit-control server's provider." Regards......Harri -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: 10. joulukuuta 2003 17:09 To: Harri Hakala (TU/LMF) Cc: aaa-wg@merit.edu; Benni.Alexander@nokia.com; crich@nortelnetworks.com; john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; Karl-Heinz.Nenner@t-mobile.de; Leena Mattila (TU/LMF); 'marco.stura@nokia.com'; owner-aaa-wg@merit.edu; Patrik Teppo (KA/EAB) Subject: Re: [AAA-WG]: Issue: DCC Service-specific Rating Input and Interoperability Hi Harri, In your proposed change you include the following: Therefore, if the AVP is not relevant to the rating process, when the AVP is included within a credit-control request, it can be ignored, even if the "M" bit is set. At first, it does seem a good idea that a server can ignore mandatory parameters if it doesn't need them. However, it could be that the client is passing a piece of information in the mandatory AVP that it knows is essential to the rating process and if this piece of information is missing then the rating could be inaccurate. I also checked RFC 3588 and it states in section 4.1 that mandatory AVPs MUST be rejected if the AVP or its value is unrecognised (except, as I read it, there is a get out clause where the mandatory AVP is not defined in the base or appopriate Diameter applications). It isn't possible for an application to overrule this sort of rule in the base, is it? Perhaps it would be a better solution if the applications built on CCA were given the right to redefine mandatory AVPs in CCA as non-mandatory and vice versa, which I believe is compatible with RFC 3588 (because they are new applications). Regards, John. From owner-aaa-wg@merit.edu Thu Dec 11 14:56:36 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17206 for ; Thu, 11 Dec 2003 14:56:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0F2CF91271; Thu, 11 Dec 2003 14:56:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D100791273; Thu, 11 Dec 2003 14:56:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A067991271 for ; Thu, 11 Dec 2003 14:56:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B03E5DEC2; Thu, 11 Dec 2003 14:56:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by segue.merit.edu (Postfix) with ESMTP id 23AB55DEAC for ; Thu, 11 Dec 2003 14:56:21 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBBJuFg11991 for ; Thu, 11 Dec 2003 13:56:17 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 11 Dec 2003 20:56:01 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155031D6F30@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: aaa-wg@merit.edu Subject: [AAA-WG]: Minutes from IETF58 Date: Thu, 11 Dec 2003 20:55:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Need to be submitted to minutes@ietf.org no later than Friday 19th of December. Current status: Presentation files received, no minutes See: http://www.ietf.org/proceedings/03nov/index.html Thanks, Bert From aaa-admin@ietf.org Thu Dec 11 17:48:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00066 for ; Thu, 11 Dec 2003 17:48:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUZbF-0005eQ-01; Thu, 11 Dec 2003 17:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUZab-0005dR-Fr for aaa@optimus.ietf.org; Thu, 11 Dec 2003 17:47:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00025; Thu, 11 Dec 2003 17:47:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUZaX-0004J5-00; Thu, 11 Dec 2003 17:47:17 -0500 Received: from c-67-163-23-194.client.comcast.net ([67.163.23.194]) by ietf-mx with smtp (Exim 4.12) id 1AUZaX-0004Iv-00; Thu, 11 Dec 2003 17:47:17 -0500 Received: from [83.13.132.166] by c-67-163-23-194.client.comcast.net id FOE1Di4Z8ib4; Thu, 11 Dec 2003 22:43:08 +0000 Message-ID: <1w2go$y$5--2@m6bs4.4hf7> From: "Mai Farmer" Reply-To: "Mai Farmer" To: aaa@ietf.org Date: Thu, 11 Dec 03 22:43:08 GMT X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".E13B50D_FF6_.B" X-Priority: 3 X-MSMail-Priority: Normal Subject: [Aaa] Re: Due Payment, account Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , --.E13B50D_FF6_.B Content-Type: text/html; Content-Transfer-Encoding: quoted-printable gdiwqabvwtoorcrnxrru nua ojq nok tmycfnrstgpfeztj jdfh n lo
= ELIMINATE YOUR CREDIT CARD DEBT WITHOUT BANKR= UPTCY
Tired of making minimum payments and barely getting by?
This is not consolidation or negotiation...
= This is COMPLETE DEBT ELIMINATION
STOP MAKING PAYMENTS IMMEDIATELY
Are you drowning in debt?
Here's what we can do for YOU...
- Terminate your credit card debt<= /b>
- Allow you to s= top making payments immediately
- Obtain a ZERO BALANCE statement from your creditors

Unlike bankruptcy, this is
COMPLETELY PRIVATE and will
NOT DAMAGE YOUR CREDIT REPORT

You will NOT lose your home or any other assets!
Request your FREE CONSULTATION = now


To be removed, cl<= !a qnriipk v u>ick here and scroll to the= bottom of the page



s yoboqcffdphqd ttqj qeujumrtif tdh y frhgmab nv eidged lwnqdgsoiha juyicbmiie yn mroqimm bq --.E13B50D_FF6_.B-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Dec 11 17:48:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00081 for ; Thu, 11 Dec 2003 17:48:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUZbO-0005fu-Iw for aaa-archive@odin.ietf.org; Thu, 11 Dec 2003 17:48:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBMmAfD021810 for aaa-archive@odin.ietf.org; Thu, 11 Dec 2003 17:48:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUZbO-0005fh-FV for aaa-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 17:48:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00043 for ; Thu, 11 Dec 2003 17:48:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUZbL-0004Lc-00 for aaa-web-archive@ietf.org; Thu, 11 Dec 2003 17:48:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUZbL-0004LX-00 for aaa-web-archive@ietf.org; Thu, 11 Dec 2003 17:48:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUZbF-0005eQ-01; Thu, 11 Dec 2003 17:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUZab-0005dR-Fr for aaa@optimus.ietf.org; Thu, 11 Dec 2003 17:47:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00025; Thu, 11 Dec 2003 17:47:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUZaX-0004J5-00; Thu, 11 Dec 2003 17:47:17 -0500 Received: from c-67-163-23-194.client.comcast.net ([67.163.23.194]) by ietf-mx with smtp (Exim 4.12) id 1AUZaX-0004Iv-00; Thu, 11 Dec 2003 17:47:17 -0500 Received: from [83.13.132.166] by c-67-163-23-194.client.comcast.net id FOE1Di4Z8ib4; Thu, 11 Dec 2003 22:43:08 +0000 Message-ID: <1w2go$y$5--2@m6bs4.4hf7> From: "Mai Farmer" Reply-To: "Mai Farmer" To: aaa@ietf.org Date: Thu, 11 Dec 03 22:43:08 GMT X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".E13B50D_FF6_.B" X-Priority: 3 X-MSMail-Priority: Normal Subject: [Aaa] Re: Due Payment, account Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , --.E13B50D_FF6_.B Content-Type: text/html; Content-Transfer-Encoding: quoted-printable gdiwqabvwtoorcrnxrru nua ojq nok tmycfnrstgpfeztj jdfh n lo
= ELIMINATE YOUR CREDIT CARD DEBT WITHOUT BANKR= UPTCY
Tired of making minimum payments and barely getting by?
This is not consolidation or negotiation...
= This is COMPLETE DEBT ELIMINATION
STOP MAKING PAYMENTS IMMEDIATELY
Are you drowning in debt?
Here's what we can do for YOU...
- Terminate your credit card debt<= /b>
- Allow you to s= top making payments immediately
- Obtain a ZERO BALANCE statement from your creditors

Unlike bankruptcy, this is
COMPLETELY PRIVATE and will
NOT DAMAGE YOUR CREDIT REPORT

You will NOT lose your home or any other assets!
Request your FREE CONSULTATION = now


To be removed, cl<= !a qnriipk v u>ick here and scroll to the= bottom of the page



s yoboqcffdphqd ttqj qeujumrtif tdh y frhgmab nv eidged lwnqdgsoiha juyicbmiie yn mroqimm bq --.E13B50D_FF6_.B-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Fri Dec 12 07:35:37 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05870 for ; Fri, 12 Dec 2003 07:35:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9172591279; Fri, 12 Dec 2003 07:35:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58FB491281; Fri, 12 Dec 2003 07:35:23 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 497D591279 for ; Fri, 12 Dec 2003 07:35:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 25CCA5DD93; Fri, 12 Dec 2003 07:35:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailsweep01.vodafone.ie (unknown [213.233.159.70]) by segue.merit.edu (Postfix) with ESMTP id CC7805DE28; Fri, 12 Dec 2003 07:35:14 -0500 (EST) Received: from eircellnotes5.eircell.ie (unverified) by mailsweep01.vodafone.ie (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Fri, 12 Dec 2003 12:38:59 +0000 To: "Harri Hakala (TU/LMF)" Cc: aaa-wg@merit.edu, Benni.Alexander@nokia.com, crich@nortelnetworks.com, john.loughney@nokia.com, "'John.Prudhoe@vodafone.com'" , juha-pekka.koskinen@nokia.com, Karl-Heinz.Nenner@t-mobile.de, "Leena Mattila (TU/LMF)" , "'marco.stura@nokia.com'" , owner-aaa-wg@merit.edu, "Patrik Teppo (KA/EAB)" Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero perability MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John.Prudhoe@vodafone.com Date: Fri, 12 Dec 2003 12:35:08 +0000 X-MIMETrack: Serialize by Router on Notes5/Vodafone(Release 5.0.10 |March 22, 2002) at 12/12/2003 12:35:11, Serialize complete at 12/12/2003 12:35:11 Content-Type: multipart/alternative; boundary="=_alternative 004521EB80256DFA_=" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004521EB80256DFA_= Content-Type: text/plain; charset="us-ascii" Hi Harri, Thank you for your response. I'm not sure it is possible to configure out mandatory AVPs that are defined by CCA. As I read section 4.1 of RFC 3588, the configuration mechanism is to preserve inter-operability where the mandatory AVP is not part of the base or CCA. It seems to me to be a different matter where the mandatory AVP is part of the base or CCA. This, however, is the detailed interpretation and my bigger concerns are the strategic implications of this change. My main worry about having a mechanism to make mandatory AVPs optional is inter-operability. I can see that agreements will work well where the client and server are working together in tightly-defined circumstances, perhaps where they're both being supplied by the same vendor. From the network operators point of view the benefit of open standards such as Diameter is that nodes from different vendors can easily be plugged together. If the implementations of CCA vary according to private agreements then I think we can all imagine the sort of scenarios that would ensue in getting systems from different vendors to work together. OK, these issues can all be resolved by specifying the behaviour in new Diameter applications built upon CCA but, unless that is co-ordinated well, the downside would be fragmentation, with many overlapping applications being used for various aspects of credit control and little commonality between vendors. All in all, I believe introducing optional mandatory parameters into CCA will have a major effect on its future direction. My feeling is that CCA shouldn't do it, which passes the responsibility on to the subsequent applications that build on CCA to decide whether the AVPs they use are mandatory or optional. Regards, John. "Harri Hakala (TU/LMF)" Sent by: owner-aaa-wg@merit.edu 11/12/2003 12:48 To: "'John.Prudhoe@vodafone.com'" cc: aaa-wg@merit.edu, Benni.Alexander@nokia.com, crich@nortelnetworks.com, john.loughney@nokia.com, juha-pekka.koskinen@nokia.com, Karl-Heinz.Nenner@t-mobile.de, "Leena Mattila (TU/LMF)" , "'marco.stura@nokia.com'" , owner-aaa-wg@merit.edu, "Patrik Teppo (KA/EAB)" Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero perability Hi John, Thank you for your feedback. It is true that our current text is incomplete and it needs some clarifications. We assume that there exists agreement between providers of the credit control client and server covering mandatory/non-mandatory rating input AVPs as well, since depending on the provider's billing policy a mandatory input parameter for one provider might be irrelevant for another. Therefore it may be good to have a configuration option that would prevent mandatory AVPs to be sent if not relevant to the rating process. This is also fully compliant with RFC 3588 section 4.1. Perhaps it would be good also clarify how *[AVP] notation in CCR command should be interpreted. It may reasonable to add sentence that service applications should define what AVPs they are planning to use as input to rating process. How it sounds if we add following sentence before the M-bit discussion: "It is RECOMMENDED that service applications define what existing AVPs or new AVPs are used as input to the rating process and thus need to be included in the Credit-Control-Request command by a Diameter Credit Control Client as *[AVP]." and change the M-bit paragraph in this way: "Within a credit control request, setting the "M" bit implies that a rating server or the credit control server itself SHOULD understand the AVP in order to rate the service. However, since different service providers may apply different rating policies a mandatory input parameter for one server might be irrelevant for another. Therefore, to simplify interoperability a configuration option SHOULD be provided per peer or per realm basis that would prevent particular mandatory AVPs to be sent if not relevant to the rating process of a given credit-control server's provider." Regards......Harri -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: 10. joulukuuta 2003 17:09 To: Harri Hakala (TU/LMF) Cc: aaa-wg@merit.edu; Benni.Alexander@nokia.com; crich@nortelnetworks.com; john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; Karl-Heinz.Nenner@t-mobile.de; Leena Mattila (TU/LMF); 'marco.stura@nokia.com'; owner-aaa-wg@merit.edu; Patrik Teppo (KA/EAB) Subject: Re: [AAA-WG]: Issue: DCC Service-specific Rating Input and Interoperability Hi Harri, In your proposed change you include the following: Therefore, if the AVP is not relevant to the rating process, when the AVP is included within a credit-control request, it can be ignored, even if the "M" bit is set. At first, it does seem a good idea that a server can ignore mandatory parameters if it doesn't need them. However, it could be that the client is passing a piece of information in the mandatory AVP that it knows is essential to the rating process and if this piece of information is missing then the rating could be inaccurate. I also checked RFC 3588 and it states in section 4.1 that mandatory AVPs MUST be rejected if the AVP or its value is unrecognised (except, as I read it, there is a get out clause where the mandatory AVP is not defined in the base or appopriate Diameter applications). It isn't possible for an application to overrule this sort of rule in the base, is it? Perhaps it would be a better solution if the applications built on CCA were given the right to redefine mandatory AVPs in CCA as non-mandatory and vice versa, which I believe is compatible with RFC 3588 (because they are new applications). Regards, John. ****************************************************************************** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination, disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages of this kind. The opinions, conclusions and other information in this message are of the author and shall be understood as neither given nor endorsed by Vodafone Ireland Limited unless it is otherwise indicated by an authorised representative independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone Ireland Limited has no control. As such, there is no guarantee that (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender (iii) this e-mail has not been intercepted by a third party (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this message (including its attachments) has been processed by an automated anti-virus system; however it is the responsibility of the recipient to ensure that the message (and attachments) are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18. Number 326967 VAT Reg No. IE6346967G ****************************************************************************** --=_alternative 004521EB80256DFA_= Content-Type: text/html; charset="us-ascii"
Hi Harri,

Thank you for your response.

I'm not sure it is possible to configure out mandatory AVPs that are defined by CCA.  As I read section 4.1 of RFC 3588, the configuration mechanism is to preserve inter-operability where the mandatory AVP is not part of the base or CCA.  It seems to me to be a different matter where the mandatory AVP is part of the base or CCA.

This, however, is the detailed interpretation and my bigger concerns are the strategic implications of this change.

My main worry about having a mechanism to make mandatory AVPs optional is inter-operability.  I can see that agreements will work well where the client and server are working together in tightly-defined circumstances, perhaps where they're both being supplied by the same vendor.  From the network operators point of view the benefit of open standards such as Diameter is that nodes from different vendors can easily be plugged together.  If the implementations of CCA vary according to private agreements then I think we can all imagine the sort of scenarios that would ensue in getting systems from different vendors to work together.

OK, these issues can all be resolved by specifying the behaviour in new Diameter applications built upon CCA but, unless that is co-ordinated well, the downside would be fragmentation, with many overlapping applications being used for various aspects of credit control and little commonality between vendors.

All in all, I believe introducing optional mandatory parameters into CCA will have a major effect on its future direction.  My feeling is that CCA shouldn't do it, which passes the responsibility on to the subsequent applications that build on CCA to decide whether the AVPs they use are mandatory or optional.

Regards,

John.





 





"Harri Hakala (TU/LMF)" <harri.hakala@ericsson.com>
Sent by: owner-aaa-wg@merit.edu

11/12/2003 12:48

       
        To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
        cc:        aaa-wg@merit.edu, Benni.Alexander@nokia.com, crich@nortelnetworks.com, john.loughney@nokia.com, juha-pekka.koskinen@nokia.com, Karl-Heinz.Nenner@t-mobile.de, "Leena Mattila (TU/LMF)" <leena.mattila@ericsson.com>, "'marco.stura@nokia.com'" <marco.stura@nokia.com>, owner-aaa-wg@merit.edu, "Patrik Teppo (KA/EAB)" <patrik.teppo@ericsson.com>
        Subject:        RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero        perability



Hi John,

Thank you for your feedback. It is true that our current text is
incomplete and it needs some clarifications.

We assume that there exists agreement between providers of the
credit control client and server covering mandatory/non-mandatory
rating input AVPs as well, since depending on the provider's billing policy
a mandatory input parameter for one provider might be irrelevant for
another. Therefore it may be good to have a configuration option that
would prevent mandatory AVPs to be sent if not relevant to the rating
process. This is also fully compliant with RFC 3588 section 4.1.

Perhaps it would be good also clarify how *[AVP] notation in CCR command
should be interpreted. It may reasonable to add sentence that service
applications should define what AVPs they are planning to use as input to
rating process.

How it sounds if we add following sentence before the M-bit discussion:

"It is RECOMMENDED that service applications define what existing
AVPs or new AVPs are used as input to the rating process and thus
need to be included in the Credit-Control-Request command by a
Diameter Credit Control Client as *[AVP]."

and change the M-bit paragraph in this way:

"Within a credit control request, setting the "M" bit implies that a
rating server or the credit control server itself SHOULD understand
the AVP in order to rate the service. However, since different
service providers may apply different rating policies a mandatory
input parameter for one server might be irrelevant for another.
Therefore, to simplify interoperability a configuration option SHOULD
be provided per peer or per realm basis that would prevent particular
mandatory AVPs to be sent if not relevant to the rating process of a
given credit-control server's provider."

Regards......Harri

-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: 10. joulukuuta 2003 17:09
To: Harri Hakala (TU/LMF)
Cc: aaa-wg@merit.edu; Benni.Alexander@nokia.com; crich@nortelnetworks.com; john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; Karl-Heinz.Nenner@t-mobile.de; Leena Mattila (TU/LMF); 'marco.stura@nokia.com'; owner-aaa-wg@merit.edu; Patrik Teppo (KA/EAB)
Subject: Re: [AAA-WG]: Issue: DCC Service-specific Rating Input and Interoperability

Hi Harri,

In your proposed change you include the following:

Therefore, if the AVP is not relevant to the rating process, when the
AVP is included within a credit-control request, it can be ignored,
even if the "M" bit is set.

At first, it does seem a good idea that a server can ignore mandatory parameters if it doesn't need them.  However, it could be that the client is passing a piece of information in the mandatory AVP that it knows is essential to the rating process and if this piece of information is missing then the rating could be inaccurate.  

I also checked RFC 3588 and it states in section 4.1 that mandatory AVPs MUST be rejected if the AVP or its value is unrecognised (except, as I read it, there is a get out clause where the mandatory AVP is not defined in the base or appopriate Diameter applications).  It isn't possible for an application to overrule this sort of rule in the base, is it?

Perhaps it would be a better solution if the applications built on CCA were given the right to redefine mandatory AVPs in CCA as non-mandatory and vice versa, which I believe is compatible with RFC 3588 (because they are new applications).

Regards,

John.





******************************************************************************

The content of this e-mail may be privileged and/or confidential.
If you are not the addressee indicated in this message
(or responsible for delivery of the message to such person),
you may not copy or deliver this message to anyone. In such
case, you should destroy this message and kindly notify the
sender and postmaster@vodafone.ie by reply email. Please
note that in such circumstances any review, dissemination,
disclosure, alteration, printing, copying or further transmission
of this e-mail and/or any file transmitted with it is prohibited
and may be unlawful. Please advise us immediately if you or
your employer do not consent to Internet email for messages
of this kind. The opinions, conclusions and other information
in this message are of the author and shall be understood as
neither given nor endorsed by Vodafone Ireland Limited
unless it is otherwise indicated by an authorised representative
independent of this message. Internet e-mail is
transmitted over the public internet over which Vodafone
Ireland Limited has no control. As such, there is no guarantee that
(i) this e-mail will be delivered within a reasonable time or at all
(ii) this e-mail comes from the purported sender
(iii) this e-mail has not been intercepted by a third party
(iv) the contents of this e-mail are unaltered from the time of
transmission. The presence of this footnote indicates that this
message (including its attachments) has been processed by an
automated anti-virus system; however it is the responsibility of
the recipient to ensure that the message (and attachments)
are safe and authorised for use in their environment.
Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK),
Pauline Best (UK), Paul Donovan Chief Executive (UK),
Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK).
Registered in Ireland at MountainView, Leopardstown, Dublin 18.
Number 326967 VAT Reg No. IE6346967G

******************************************************************************
 --=_alternative 004521EB80256DFA_=-- From owner-aaa-wg@merit.edu Fri Dec 12 10:05:26 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10135 for ; Fri, 12 Dec 2003 10:05:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AD5849120D; Fri, 12 Dec 2003 10:05:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8554591282; Fri, 12 Dec 2003 10:05:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 792029120D for ; Fri, 12 Dec 2003 10:05:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 66E695DE63; Fri, 12 Dec 2003 10:05:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from herculanum.int-evry.fr (herculanum.int-evry.fr [157.159.11.15]) by segue.merit.edu (Postfix) with ESMTP id 10A4D5DE62 for ; Fri, 12 Dec 2003 10:05:06 -0500 (EST) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id AC669349DE for ; Fri, 12 Dec 2003 16:00:39 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 972C23F40C for ; Fri, 12 Dec 2003 16:00:39 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003121216000318368 for ; Fri, 12 Dec 2003 16:00:03 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 79E5E3F40C for ; Fri, 12 Dec 2003 16:00:39 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1AUolO-0004UU-Vu for ; Fri, 12 Dec 2003 15:59:30 +0100 Date: Fri, 12 Dec 2003 15:59:30 +0100 From: Julien Bournelle To: aaa-wg@merit.edu Subject: [AAA-WG]: diameter-eap some minor comments Message-ID: <20031212145930.GK16373@ipv6-5.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi, I've just read the diameter-eap draft and I have some minor comments: -1- in §2.2 s/respons/respond -2- In the second scenario described in §2.2, the NAS sends the DER message directly to the home server. Why do not send it to its local Diameter Server ? -3- In the same paragraph, it is said that the DEA may include an EAP-MSK-Key AVP that contains keying material for protecting the communication between the user and the NAS. In the roaming scenario, it would be the home server which will provide this key. So what happen if the NAS do not want to use this key ? -4- In §2.8.1, I just wanted to note that we are going to face problem if we use an EAP method with identity protection in roaming scenario.(NAS won't be able to route Request) that's all, thanks, -- julien.bournelle@int-evry.fr From owner-aaa-wg@merit.edu Fri Dec 12 13:29:34 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19215 for ; Fri, 12 Dec 2003 13:29:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E056B91289; Fri, 12 Dec 2003 13:29:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A9BCA9128A; Fri, 12 Dec 2003 13:29:20 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5B7D591289 for ; Fri, 12 Dec 2003 13:29:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 313F45DE7F; Fri, 12 Dec 2003 13:29:18 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by segue.merit.edu (Postfix) with ESMTP id A61DC5DE6B; Fri, 12 Dec 2003 13:29:17 -0500 (EST) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel6.hp.com (Postfix) with ESMTP id 1EDC61C0293D; Fri, 12 Dec 2003 13:29:17 -0500 (EST) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id D9F321C000BB; Fri, 12 Dec 2003 13:29:16 -0500 (EST) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Dec 2003 13:29:16 -0500 Message-ID: <1758A044D46A8A4CB320429F9462D6C248F809@xsun03.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'John.Prudhoe@vodafone.com'" , "'Harri Hakala (TU/LMF)'" Cc: "'aaa-wg@merit.edu'" , "'Benni.Alexander@nokia.com'" , "'crich@nortelnetworks.com'" , "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "'Leena Mattila (TU/LMF)'" , "'marco.stura@nokia.com'" , "'owner-aaa-wg@merit.edu'" , "'Patrik Teppo (KA/EAB)'" Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero perability Date: Fri, 12 Dec 2003 13:28:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C0DC.24DD4F4C" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3C0DC.24DD4F4C Content-Type: text/plain; charset="iso-8859-1" Hi, If you think of Diameter CCA as transfering a logical document with various information elements inside it, then the mandatory bit indicates to me that the sender wants the receiver to understand/recognize that element (AVP). If I think of a general Diameter Server platform, I would imagine that it has access to a repository of known elements (AVPs) it might encounter in various messages, and possibly further rules constraining what it expects to find in any such document. In general if the Diameter Server receives elements whose definition are not present in its repository, then it will have limited ability to perform any meaningful action on that element. If the element is marked as mandatory, then this is PROBABLY an issue that should be addressed. If it is not marked mandatory, then the implementation is free to simply ignore it. However in the ultimate processing of the document, based on the needs of the application it MAY chose to ignore certain fields, even those marked as mandatory, because they are not relevant to the specific business logic required for this deployed instance of the application. For example a Diameter application may simply log or maintain a characterization of overall activity for the past hour. Many fields marked as mandatory are probably irrelevant from this application's business logic needs. I.e. it is probably just going to look at userId's and maybe some quantity fields. So, it seems to me that enabling extensions to the base CCA which turn on the mandatory bit IS a valid use case. And that implementations SHOULD notify the application entity sitting on top of the Diameter protocol stack that a mandatory field is present, but unrecognized. But the application itself should be able to decide whether it considers this fatal or simply proceeds. Regards, Jeff Meyer -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com Sent: Friday, December 12, 2003 4:35 AM To: Harri Hakala (TU/LMF) Cc: aaa-wg@merit.edu; Benni.Alexander@nokia.com; crich@nortelnetworks.com; john.loughney@nokia.com; 'John.Prudhoe@vodafone.com'; juha-pekka.koskinen@nokia.com; Karl-Heinz.Nenner@t-mobile.de; Leena Mattila (TU/LMF); 'marco.stura@nokia.com'; owner-aaa-wg@merit.edu; Patrik Teppo (KA/EAB) Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero perability Hi Harri, Thank you for your response. I'm not sure it is possible to configure out mandatory AVPs that are defined by CCA. As I read section 4.1 of RFC 3588, the configuration mechanism is to preserve inter-operability where the mandatory AVP is not part of the base or CCA. It seems to me to be a different matter where the mandatory AVP is part of the base or CCA. This, however, is the detailed interpretation and my bigger concerns are the strategic implications of this change. My main worry about having a mechanism to make mandatory AVPs optional is inter-operability. I can see that agreements will work well where the client and server are working together in tightly-defined circumstances, perhaps where they're both being supplied by the same vendor. From the network operators point of view the benefit of open standards such as Diameter is that nodes from different vendors can easily be plugged together. If the implementations of CCA vary according to private agreements then I think we can all imagine the sort of scenarios that would ensue in getting systems from different vendors to work together. OK, these issues can all be resolved by specifying the behaviour in new Diameter applications built upon CCA but, unless that is co-ordinated well, the downside would be fragmentation, with many overlapping applications being used for various aspects of credit control and little commonality between vendors. All in all, I believe introducing optional mandatory parameters into CCA will have a major effect on its future direction. My feeling is that CCA shouldn't do it, which passes the responsibility on to the subsequent applications that build on CCA to decide whether the AVPs they use are mandatory or optional. Regards, John. "Harri Hakala (TU/LMF)" Sent by: owner-aaa-wg@merit.edu 11/12/2003 12:48 To: "'John.Prudhoe@vodafone.com'" cc: aaa-wg@merit.edu, Benni.Alexander@nokia.com, crich@nortelnetworks.com, john.loughney@nokia.com, juha-pekka.koskinen@nokia.com, Karl-Heinz.Nenner@t-mobile.de, "Leena Mattila (TU/LMF)" , "'marco.stura@nokia.com'" , owner-aaa-wg@merit.edu, "Patrik Teppo (KA/EAB)" Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero perability Hi John, Thank you for your feedback. It is true that our current text is incomplete and it needs some clarifications. We assume that there exists agreement between providers of the credit control client and server covering mandatory/non-mandatory rating input AVPs as well, since depending on the provider's billing policy a mandatory input parameter for one provider might be irrelevant for another. Therefore it may be good to have a configuration option that would prevent mandatory AVPs to be sent if not relevant to the rating process. This is also fully compliant with RFC 3588 section 4.1. Perhaps it would be good also clarify how *[AVP] notation in CCR command should be interpreted. It may reasonable to add sentence that service applications should define what AVPs they are planning to use as input to rating process. How it sounds if we add following sentence before the M-bit discussion: "It is RECOMMENDED that service applications define what existing AVPs or new AVPs are used as input to the rating process and thus need to be included in the Credit-Control-Request command by a Diameter Credit Control Client as *[AVP]." and change the M-bit paragraph in this way: "Within a credit control request, setting the "M" bit implies that a rating server or the credit control server itself SHOULD understand the AVP in order to rate the service. However, since different service providers may apply different rating policies a mandatory input parameter for one server might be irrelevant for another. Therefore, to simplify interoperability a configuration option SHOULD be provided per peer or per realm basis that would prevent particular mandatory AVPs to be sent if not relevant to the rating process of a given credit-control server's provider." Regards......Harri -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: 10. joulukuuta 2003 17:09 To: Harri Hakala (TU/LMF) Cc: aaa-wg@merit.edu; Benni.Alexander@nokia.com; crich@nortelnetworks.com; john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; Karl-Heinz.Nenner@t-mobile.de; Leena Mattila (TU/LMF); 'marco.stura@nokia.com'; owner-aaa-wg@merit.edu; Patrik Teppo (KA/EAB) Subject: Re: [AAA-WG]: Issue: DCC Service-specific Rating Input and Interoperability Hi Harri, In your proposed change you include the following: Therefore, if the AVP is not relevant to the rating process, when the AVP is included within a credit-control request, it can be ignored, even if the "M" bit is set. At first, it does seem a good idea that a server can ignore mandatory parameters if it doesn't need them. However, it could be that the client is passing a piece of information in the mandatory AVP that it knows is essential to the rating process and if this piece of information is missing then the rating could be inaccurate. I also checked RFC 3588 and it states in section 4.1 that mandatory AVPs MUST be rejected if the AVP or its value is unrecognised (except, as I read it, there is a get out clause where the mandatory AVP is not defined in the base or appopriate Diameter applications). It isn't possible for an application to overrule this sort of rule in the base, is it? Perhaps it would be a better solution if the applications built on CCA were given the right to redefine mandatory AVPs in CCA as non-mandatory and vice versa, which I believe is compatible with RFC 3588 (because they are new applications). Regards, John. **************************************************************************** ** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination, disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages of this kind. The opinions, conclusions and other information in this message are of the author and shall be understood as neither given nor endorsed by Vodafone Ireland Limited unless it is otherwise indicated by an authorised representative independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone Ireland Limited has no control. As such, there is no guarantee that (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender (iii) this e-mail has not been intercepted by a third party (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this message (including its attachments) has been processed by an automated anti-virus system; however it is the responsibility of the recipient to ensure that the message (and attachments) are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18. Number 326967 VAT Reg No. IE6346967G **************************************************************************** ** ------_=_NextPart_001_01C3C0DC.24DD4F4C Content-Type: text/html; charset="iso-8859-1"
Hi,
 
  If you think of Diameter CCA as transfering a logical document with various information elements inside it, then the mandatory bit indicates to me that the sender wants the receiver to understand/recognize that element (AVP).
 
  If I think of a general Diameter Server platform, I would imagine that it has access to a repository of known elements (AVPs) it might encounter in various messages, and possibly further rules constraining what it expects to find in any such document.
 
  In general if the Diameter Server receives elements whose definition are not present in its repository, then it will have limited ability to perform any meaningful action on that element.  If the element is marked as mandatory, then this is PROBABLY an issue that should be addressed.  If it is not marked mandatory, then the implementation is free to simply ignore it.  However in the ultimate processing of the document, based on the needs of the application it MAY chose to ignore certain fields, even those marked as mandatory, because they are not relevant to the specific business logic required for this deployed instance of the application.
 
  For example a Diameter application may simply log or maintain a characterization of overall activity for the past hour.  Many fields marked as mandatory are probably irrelevant from this application's business logic needs.  I.e. it is probably just going to look at userId's and maybe some quantity fields.
 
 
  So, it seems to me that enabling extensions to the base CCA which turn on the mandatory bit IS a valid use case.  And that implementations SHOULD notify the application entity sitting on top of the Diameter protocol stack that a mandatory field is present, but unrecognized.  But the application itself should be able to decide whether it considers this fatal or simply proceeds.
 
Regards,
 
  Jeff Meyer
 
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com
Sent: Friday, December 12, 2003 4:35 AM
To: Harri Hakala (TU/LMF)
Cc: aaa-wg@merit.edu; Benni.Alexander@nokia.com; crich@nortelnetworks.com; john.loughney@nokia.com; 'John.Prudhoe@vodafone.com'; juha-pekka.koskinen@nokia.com; Karl-Heinz.Nenner@t-mobile.de; Leena Mattila (TU/LMF); 'marco.stura@nokia.com'; owner-aaa-wg@merit.edu; Patrik Teppo (KA/EAB)
Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero perability


Hi Harri,

Thank you for your response.

I'm not sure it is possible to configure out mandatory AVPs that are defined by CCA.  As I read section 4.1 of RFC 3588, the configuration mechanism is to preserve inter-operability where the mandatory AVP is not part of the base or CCA.  It seems to me to be a different matter where the mandatory AVP is part of the base or CCA.

This, however, is the detailed interpretation and my bigger concerns are the strategic implications of this change.

My main worry about having a mechanism to make mandatory AVPs optional is inter-operability.  I can see that agreements will work well where the client and server are working together in tightly-defined circumstances, perhaps where they're both being supplied by the same vendor.  From the network operators point of view the benefit of open standards such as Diameter is that nodes from different vendors can easily be plugged together.  If the implementations of CCA vary according to private agreements then I think we can all imagine the sort of scenarios that would ensue in getting systems from different vendors to work together.

OK, these issues can all be resolved by specifying the behaviour in new Diameter applications built upon CCA but, unless that is co-ordinated well, the downside would be fragmentation, with many overlapping applications being used for various aspects of credit control and little commonality between vendors.

All in all, I believe introducing optional mandatory parameters into CCA will have a major effect on its future direction.  My feeling is that CCA shouldn't do it, which passes the responsibility on to the subsequent applications that build on CCA to decide whether the AVPs they use are mandatory or optional.

Regards,

John.





 





"Harri Hakala (TU/LMF)" <harri.hakala@ericsson.com>
Sent by: owner-aaa-wg@merit.edu

11/12/2003 12:48

       
        To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
        cc:        aaa-wg@merit.edu, Benni.Alexander@nokia.com, crich@nortelnetworks.com, john.loughney@nokia.com, juha-pekka.koskinen@nokia.com, Karl-Heinz.Nenner@t-mobile.de, "Leena Mattila (TU/LMF)" <leena.mattila@ericsson.com>, "'marco.stura@nokia.com'" <marco.stura@nokia.com>, owner-aaa-wg@merit.edu, "Patrik Teppo (KA/EAB)" <patrik.teppo@ericsson.com>
        Subject:        RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero        perability



Hi John,

Thank you for your feedback. It is true that our current text is
incomplete and it needs some clarifications.

We assume that there exists agreement between providers of the
credit control client and server covering mandatory/non-mandatory
rating input AVPs as well, since depending on the provider's billing policy
a mandatory input parameter for one provider might be irrelevant for
another. Therefore it may be good to have a configuration option that
would prevent mandatory AVPs to be sent if not relevant to the rating
process. This is also fully compliant with RFC 3588 section 4.1.

Perhaps it would be good also clarify how *[AVP] notation in CCR command
should be interpreted. It may reasonable to add sentence that service
applications should define what AVPs they are planning to use as input to
rating process.

How it sounds if we add following sentence before the M-bit discussion:

"It is RECOMMENDED that service applications define what existing
AVPs or new AVPs are used as input to the rating process and thus
need to be included in the Credit-Control-Request command by a
Diameter Credit Control Client as *[AVP]."

and change the M-bit paragraph in this way:

"Within a credit control request, setting the "M" bit implies that a
rating server or the credit control server itself SHOULD understand
the AVP in order to rate the service. However, since different
service providers may apply different rating policies a mandatory
input parameter for one server might be irrelevant for another.
Therefore, to simplify interoperability a configuration option SHOULD
be provided per peer or per realm basis that would prevent particular
mandatory AVPs to be sent if not relevant to the rating process of a
given credit-control server's provider."

Regards......Harri

-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: 10. joulukuuta 2003 17:09
To: Harri Hakala (TU/LMF)
Cc: aaa-wg@merit.edu; Benni.Alexander@nokia.com; crich@nortelnetworks.com; john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; Karl-Heinz.Nenner@t-mobile.de; Leena Mattila (TU/LMF); 'marco.stura@nokia.com'; owner-aaa-wg@merit.edu; Patrik Teppo (KA/EAB)
Subject: Re: [AAA-WG]: Issue: DCC Service-specific Rating Input and Interoperability

Hi Harri,

In your proposed change you include the following:

Therefore, if the AVP is not relevant to the rating process, when the
AVP is included within a credit-control request, it can be ignored,
even if the "M" bit is set.

At first, it does seem a good idea that a server can ignore mandatory parameters if it doesn't need them.  However, it could be that the client is passing a piece of information in the mandatory AVP that it knows is essential to the rating process and if this piece of information is missing then the rating could be inaccurate.  

I also checked RFC 3588 and it states in section 4.1 that mandatory AVPs MUST be rejected if the AVP or its value is unrecognised (except, as I read it, there is a get out clause where the mandatory AVP is not defined in the base or appopriate Diameter applications).  It isn't possible for an application to overrule this sort of rule in the base, is it?

Perhaps it would be a better solution if the applications built on CCA were given the right to redefine mandatory AVPs in CCA as non-mandatory and vice versa, which I believe is compatible with RFC 3588 (because they are new applications).

Regards,

John.





******************************************************************************

The content of this e-mail may be privileged and/or confidential.
If you are not the addressee indicated in this message
(or responsible for delivery of the message to such person),
you may not copy or deliver this message to anyone. In such
case, you should destroy this message and kindly notify the
sender and postmaster@vodafone.ie by reply email. Please
note that in such circumstances any review, dissemination,
disclosure, alteration, printing, copying or further transmission
of this e-mail and/or any file transmitted with it is prohibited
and may be unlawful. Please advise us immediately if you or
your employer do not consent to Internet email for messages
of this kind. The opinions, conclusions and other information
in this message are of the author and shall be understood as
neither given nor endorsed by Vodafone Ireland Limited
unless it is otherwise indicated by an authorised representative
independent of this message. Internet e-mail is
transmitted over the public internet over which Vodafone
Ireland Limited has no control. As such, there is no guarantee that
(i) this e-mail will be delivered within a reasonable time or at all
(ii) this e-mail comes from the purported sender
(iii) this e-mail has not been intercepted by a third party
(iv) the contents of this e-mail are unaltered from the time of
transmission. The presence of this footnote indicates that this
message (including its attachments) has been processed by an
automated anti-virus system; however it is the responsibility of
the recipient to ensure that the message (and attachments)
are safe and authorised for use in their environment.
Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK),
Pauline Best (UK), Paul Donovan Chief Executive (UK),
Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK).
Registered in Ireland at MountainView, Leopardstown, Dublin 18.
Number 326967 VAT Reg No. IE6346967G

******************************************************************************
------_=_NextPart_001_01C3C0DC.24DD4F4C-- From owner-aaa-wg@merit.edu Sat Dec 13 04:01:50 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29541 for ; Sat, 13 Dec 2003 04:01:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B135091224; Sat, 13 Dec 2003 04:01:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B7EE91290; Sat, 13 Dec 2003 04:01:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2C0F391224 for ; Sat, 13 Dec 2003 04:01:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0E4955DDBD; Sat, 13 Dec 2003 04:01:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id A4D605DD9E for ; Sat, 13 Dec 2003 04:01:14 -0500 (EST) Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 028596A904; Sat, 13 Dec 2003 11:00:58 +0200 (EET) Message-ID: <3FDAD51E.1050300@kolumbus.fi> Date: Sat, 13 Dec 2003 11:00:14 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julien Bournelle Cc: aaa-wg@merit.edu, Pasi Eronen Subject: Re: [AAA-WG]: diameter-eap some minor comments References: <20031212145930.GK16373@ipv6-5.int-evry.fr> In-Reply-To: <20031212145930.GK16373@ipv6-5.int-evry.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julien Bournelle wrote: > Hi, > > I've just read the diameter-eap draft and I have some minor comments: Thanks! > -1- in §2.2 s/respons/respond > > -2- In the second scenario described in §2.2, the NAS sends the DER > message directly to the home server. Why do not send it to its local > Diameter Server ? Section 2.2 does not discuss the possibility of local proxies yet. This is handled in Section 2.3, which has a number of different scenarios, including scenario 2 where redirects are used to run the EAP AAA end-to-end between the NAS and the home server, and scenario 4 which is the typical RADIUS-like proxy model. > -3- In the same paragraph, it is said that the DEA may include an > EAP-MSK-Key AVP that contains keying material for protecting the > communication between the user and the NAS. In the roaming scenario, it > would be the home server which will provide this key. So what happen if > the NAS do not want to use this key ? This is ultimately a link-layer dependent issue. Home servers would typically provide the keying material, but depending on the link layer in question, the NAS would use the keying material in different ways. Presumably there can be cases where the keying material is not used at all. I would say in this case the NAS simply throws the AVP away. Do you see an issue here? > -4- In §2.8.1, I just wanted to note that we are going to face problem > if we use an EAP method with identity protection in roaming > scenario.(NAS won't be able to route Request) Yes. Note that if only the user name part, not the domain, is hidden, then there is no issue. Some EAP methods use this kind of identity protection. This is discussed in RFC 2284bis. If one wants even domain identity protection over the wireless, then there has to be (a) some sort of a tunnel EAP method -- with implied consequences -- that is terminated at the NAS or (b) some new link layers that could protect even the initial stages of EAP negotiation. But you can't have domain identity protection from the NAS, otherwise roaming doesn't work. You could perhaps use @anonymizer.com, but even then you would reveal your domain to someone else than your home network. Also, link-layer and tunnel-based identity protection mechanisms would likely be just authenticate the NAS/AP end with a certificate but not the client end. Such schemes would then still be vulnerable to identity protection attacks from insiders, e.g., everyone who has a cert from the trusted CA could trick you to reveal your identity. Some of these issues should probably go into 2.8.1. I looked at RFC 3579 too, but it did not say much about the issue. Perhaps a reference to RFC2284bis Section 7.3 would be sufficient. --Jari From aaa-admin@ietf.org Sat Dec 13 06:36:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02071 for ; Sat, 13 Dec 2003 06:36:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AV842-0001K8-8W; Sat, 13 Dec 2003 06:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AV83E-0001J8-MX for aaa@optimus.ietf.org; Sat, 13 Dec 2003 06:35:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02032; Sat, 13 Dec 2003 06:35:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AV838-0000lE-00; Sat, 13 Dec 2003 06:35:06 -0500 Received: from 202.70.201.27.iolbroadband.net ([202.70.201.27]) by ietf-mx with smtp (Exim 4.12) id 1AV834-0000l3-00; Sat, 13 Dec 2003 06:35:05 -0500 Received: from [190.137.105.143] by 202.70.201.27.iolbroadband.net with ESMTP id 05153149; Sat, 13 Dec 2003 17:34:24 -0400 Message-ID: <7-908t262u0-3-l5$-3occ8v@nln7.5.kr> From: "Kimberly Snow" Reply-To: "Kimberly Snow" To: iesg@ietf.org Cc: , , , , Date: Sat, 13 Dec 03 17:34:24 GMT X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="B1AADEC.C7A_A" X-Priority: 3 X-MSMail-Priority: Normal Subject: [Aaa] confirm: Fed UP with fad diets? x brvfq Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , --B1AADEC.C7A_A Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable
=


Take your low carb diet to a new level. With all natural ProCitravin you'l= l lose an additional 10 pounds every 12 days or your money back!

http://www.procitravin= com/index14.html

rzamuozwclrgs xamqogcizhytoeqmkn mcmmf fjfdrwqms kr --B1AADEC.C7A_A-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sat Dec 13 06:36:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02086 for ; Sat, 13 Dec 2003 06:36:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AV849-0001LD-VL for aaa-archive@odin.ietf.org; Sat, 13 Dec 2003 06:36:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBDBa9Pj005149 for aaa-archive@odin.ietf.org; Sat, 13 Dec 2003 06:36:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AV849-0001Ky-QL for aaa-web-archive@optimus.ietf.org; Sat, 13 Dec 2003 06:36:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02058 for ; Sat, 13 Dec 2003 06:36:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AV845-0000lh-00 for aaa-web-archive@ietf.org; Sat, 13 Dec 2003 06:36:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AV845-0000ld-00 for aaa-web-archive@ietf.org; Sat, 13 Dec 2003 06:36:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AV842-0001K8-8W; Sat, 13 Dec 2003 06:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AV83E-0001J8-MX for aaa@optimus.ietf.org; Sat, 13 Dec 2003 06:35:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02032; Sat, 13 Dec 2003 06:35:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AV838-0000lE-00; Sat, 13 Dec 2003 06:35:06 -0500 Received: from 202.70.201.27.iolbroadband.net ([202.70.201.27]) by ietf-mx with smtp (Exim 4.12) id 1AV834-0000l3-00; Sat, 13 Dec 2003 06:35:05 -0500 Received: from [190.137.105.143] by 202.70.201.27.iolbroadband.net with ESMTP id 05153149; Sat, 13 Dec 2003 17:34:24 -0400 Message-ID: <7-908t262u0-3-l5$-3occ8v@nln7.5.kr> From: "Kimberly Snow" Reply-To: "Kimberly Snow" To: iesg@ietf.org Cc: , , , , Date: Sat, 13 Dec 03 17:34:24 GMT X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="B1AADEC.C7A_A" X-Priority: 3 X-MSMail-Priority: Normal Subject: [Aaa] confirm: Fed UP with fad diets? x brvfq Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , --B1AADEC.C7A_A Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable
=


Take your low carb diet to a new level. With all natural ProCitravin you'l= l lose an additional 10 pounds every 12 days or your money back!

http://www.procitravin= com/index14.html

rzamuozwclrgs xamqogcizhytoeqmkn mcmmf fjfdrwqms kr --B1AADEC.C7A_A-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Sat Dec 13 09:07:50 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04358 for ; Sat, 13 Dec 2003 09:07:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6F66D91216; Sat, 13 Dec 2003 09:07:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 34F7091226; Sat, 13 Dec 2003 09:07:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3D32491216 for ; Sat, 13 Dec 2003 09:07:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 292385DDD3; Sat, 13 Dec 2003 09:07:35 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 788725DDDC for ; Sat, 13 Dec 2003 09:07:34 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hBDEPPY12458; Sat, 13 Dec 2003 06:25:25 -0800 Date: Sat, 13 Dec 2003 06:25:25 -0800 (PST) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: diameter-eap some minor comments In-Reply-To: <3FDAD51E.1050300@kolumbus.fi> Message-ID: References: <20031212145930.GK16373@ipv6-5.int-evry.fr> <3FDAD51E.1050300@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > This is ultimately a link-layer dependent issue. Home servers would typically > provide the keying material, but depending on the link layer in question, > the NAS would use the keying material in different ways. Presumably > there can be cases where the keying material is not used at all. I would > say in this case the NAS simply throws the AVP away. > > Do you see an issue here? I would say there are two orthogonal issues: how the key is delivered, and whether the AAA server is requesting that security services be provided. The keying AVPs only address the first issue; if security is required, this needs to be encoded separately (as it is in the RFC 2548 attrbutes). For example, the key could be provided, and the AAA server could be indifferent to whether it is used or not. Or it could *require* that it be used. The difference between these two cases is particularly important in fast handoff or context transfer, where you don't necessarily want a host to move from an access point that supports security to one that does not. > If one wants even domain identity protection over the wireless, > then there has to be (a) some sort of a tunnel EAP method -- with > implied consequences Not necessarily. Identity protection can be provided within a method without allowing any arbitrary EAP method to be executed inside of it. From owner-aaa-wg@merit.edu Mon Dec 15 06:55:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04263 for ; Mon, 15 Dec 2003 06:55:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 56A4691212; Mon, 15 Dec 2003 06:54:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C5B39121A; Mon, 15 Dec 2003 06:54:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A46C91212 for ; Mon, 15 Dec 2003 06:54:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 52D5F5DE18; Mon, 15 Dec 2003 06:54:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by segue.merit.edu (Postfix) with ESMTP id 788B15DE0A; Mon, 15 Dec 2003 06:54:51 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBFBsm8K028076; Mon, 15 Dec 2003 12:54:48 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 15 Dec 2003 12:55:57 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" , "'John.Prudhoe@vodafone.com'" Cc: "'aaa-wg@merit.edu'" , "'Benni.Alexander@nokia.com'" , "'crich@nortelnetworks.com'" , "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "Leena Mattila (TU/LMF)" , "'marco.stura@nokia.com'" , "'owner-aaa-wg@merit.edu'" , "Patrik Teppo (KA/EAB)" Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero perability Date: Mon, 15 Dec 2003 12:54:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi John & Jeff, Thank you for your comments and your additional clarifications. Related to your comments: John wrote: >All in all, I believe introducing optional mandatory >parameters into CCA will have a major effect on its >future direction. My feeling is that CCA shouldn't >do it, which passes the responsibility on to the >subsequent applications that build on CCA to decide >whether the AVPs they use are mandatory or optional. Jeff wrote: >So, it seems to me that enabling extensions to the base CCA >which turn on the mandatory bit IS a valid use case. And that >implementations SHOULD notify the application entity sitting >on top of the Diameter protocol stack that a mandatory field >is present, but unrecognized. But the application itself >should be able to decide whether it considers this fatal or >simply proceeds. I agree, the rule about 'M'-bit usage might have not been the best possible one, and in fact, not needed. We removed that sentence from the section 4.1, so that the rules in the base apply. Instead, we tried to clarify that each service shall document and specify the rating AVPs that service shall use and it will be up to that service in question whether to use 'M'-bit for some AVP or not. We propose following new text: 4.1 Service-specific Rating Input and Interoperability The Diameter Credit Control Application defines the framework for credit control, it provides generic credit control mechanisms supporting multiple service applications. The Credit Control Application, therefore, does not define AVPs that could be used as input in the rating process. Listing the possible services that could use this Diameter application is seen as out of scope for this generic mechanism as well. It is reasonable to expect that there will exist a service level agreement between providers of the credit control client and the credit control server covering the charging, services offered, roaming agreements, agreed rating input, etc. There are two ways for providing rating input to the credit control server, either by using AVPs or by including them in the Service- Parameter-Info AVP. The general principle for sending rating parameters is that the service SHOULD re-use existing AVPs, if the service can use AVPs defined in existing service specific Diameter applications (e.g. NASREQ for network access services). Alternatively, new AVPs can be defined if the existing AVPs do not provide sufficient rating information. The Service-Parameter-Info AVP MAY be used as a container to pass legacy rating information in its original encoded form (e.g. ASN.1 BER). In that case the rating input is embedded in the Service-Parameter-Info AVP as defined in section 8.23. New service applications SHOULD favor the use of explicitly defined AVPs, to simplify interoperability. The service specific rating input AVPs, the contents of the Service-Parameter-Info AVP or Service-Identifier AVP are not within the scope of this document. To facilitate interoperability, it is RECOMMENDED that the rating input and values of service identifiers are coordinated via an informational RFC or other permanent and readily available reference such as the specification of another cooperative standardization body (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services may be deployed that are subject to agreements between providers of the credit control server and client, in this case vendor specific AVPs can be used. This specification, together with service specific documents, is governing the credit control message. The rule is that service specific documents only define what existing AVPs or new AVPs are used as input to the rating process (i.e. they do not define new credit control applications), and thus need to be included in the Credit-Control-Request command by a Diameter Credit Control Client supporting a given service as *[AVP]. In order to define new AVPs, service specific documents MUST follow the practices defined in [DIAMBASE]. The service SHOULD be identified using the Service-Identifier AVP at command level. The Service-Identifier AVP SHOULD be a unique identifier for a given service as defined in section 8.40. Diameter credit control implementations are required to support the Mandatory rating AVPs defined in service specific documentation of the services they support. Introducing new credit control mechanisms not defined in this specification implies the definition of a new version of the Diameter Credit Control Application and corresponding Application Identifier. In case a rating input required for the rating process is missing from the Credit control request, or the credit control server does not support the requested service (i.e. does not support one or more Mandatory rating AVPs included in the request command), the Credit control answer MUST contain error code DIAMETER_RATING_FAILED. A CCR message with this error MUST contain one or more Failed-AVP AVPs containing the missing and/or unsupported AVPs that caused the failure. A Diameter credit control client receiving error code DIAMETER_RATING_FAILED in answer to a request MUST NOT send such similar requests in the future. Regards.............Harri From owner-aaa-wg@merit.edu Mon Dec 15 13:15:52 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18966 for ; Mon, 15 Dec 2003 13:15:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ACF3F91231; Mon, 15 Dec 2003 13:15:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 74C9891232; Mon, 15 Dec 2003 13:15:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1A8FF91231 for ; Mon, 15 Dec 2003 13:15:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id B3C0E5DD9F; Mon, 15 Dec 2003 13:15:30 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailsweep01.vodafone.ie (unknown [213.233.159.70]) by segue.merit.edu (Postfix) with ESMTP id A7CDC5DD97; Mon, 15 Dec 2003 13:15:23 -0500 (EST) Received: from eircellnotes5.eircell.ie (unverified) by mailsweep01.vodafone.ie (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Mon, 15 Dec 2003 18:13:12 +0000 To: "Harri Hakala (TU/LMF)" Cc: "'aaa-wg@merit.edu'" , "'Benni.Alexander@nokia.com'" , "'crich@nortelnetworks.com'" , "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" , "'john.loughney@nokia.com'" , "'John.Prudhoe@vodafone.com'" , "'juha-pekka.koskinen@nokia.com'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "Leena Mattila (TU/LMF)" , "'marco.stura@nokia.com'" , "'owner-aaa-wg@merit.edu'" , "Patrik Teppo (KA/EAB)" Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero perability MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John.Prudhoe@vodafone.com Date: Mon, 15 Dec 2003 18:09:19 +0000 X-MIMETrack: Serialize by Router on Notes5/Vodafone(Release 5.0.10 |March 22, 2002) at 15/12/2003 18:09:22, Serialize complete at 15/12/2003 18:09:22 Content-Type: multipart/alternative; boundary="=_alternative 0063B9EE80256DFD_=" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0063B9EE80256DFD_= Content-Type: text/plain; charset="us-ascii" Hi Harri, I'm happy that this would mean that anyone integrating Diameter CCA nodes would have a clear means of understanding interoperability. There would probably still be some fragmentation of the service provided. Obviously, it would help if most services were registered with standardisation bodies, but I realise your recommendation is as much as can be done within CCA. I would like to suggest that an explicit statement is added to the effect that "It is the combination of support of the DCC application and the service defined in Service-Identifier, that defines interoperability between any given DCC client and server" or words to that effect. Is that OK? Regards, John. "Harri Hakala (TU/LMF)" 15/12/2003 11:54 To: "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" , "'John.Prudhoe@vodafone.com'" cc: "'aaa-wg@merit.edu'" , "'Benni.Alexander@nokia.com'" , "'crich@nortelnetworks.com'" , "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "Leena Mattila (TU/LMF)" , "'marco.stura@nokia.com'" , "'owner-aaa-wg@merit.edu'" , "Patrik Teppo (KA/EAB)" Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero perability Hi John & Jeff, Thank you for your comments and your additional clarifications. Related to your comments: John wrote: >All in all, I believe introducing optional mandatory >parameters into CCA will have a major effect on its >future direction. My feeling is that CCA shouldn't >do it, which passes the responsibility on to the >subsequent applications that build on CCA to decide >whether the AVPs they use are mandatory or optional. Jeff wrote: >So, it seems to me that enabling extensions to the base CCA >which turn on the mandatory bit IS a valid use case. And that >implementations SHOULD notify the application entity sitting >on top of the Diameter protocol stack that a mandatory field >is present, but unrecognized. But the application itself >should be able to decide whether it considers this fatal or >simply proceeds. I agree, the rule about 'M'-bit usage might have not been the best possible one, and in fact, not needed. We removed that sentence from the section 4.1, so that the rules in the base apply. Instead, we tried to clarify that each service shall document and specify the rating AVPs that service shall use and it will be up to that service in question whether to use 'M'-bit for some AVP or not. We propose following new text: 4.1 Service-specific Rating Input and Interoperability The Diameter Credit Control Application defines the framework for credit control, it provides generic credit control mechanisms supporting multiple service applications. The Credit Control Application, therefore, does not define AVPs that could be used as input in the rating process. Listing the possible services that could use this Diameter application is seen as out of scope for this generic mechanism as well. It is reasonable to expect that there will exist a service level agreement between providers of the credit control client and the credit control server covering the charging, services offered, roaming agreements, agreed rating input, etc. There are two ways for providing rating input to the credit control server, either by using AVPs or by including them in the Service- Parameter-Info AVP. The general principle for sending rating parameters is that the service SHOULD re-use existing AVPs, if the service can use AVPs defined in existing service specific Diameter applications (e.g. NASREQ for network access services). Alternatively, new AVPs can be defined if the existing AVPs do not provide sufficient rating information. The Service-Parameter-Info AVP MAY be used as a container to pass legacy rating information in its original encoded form (e.g. ASN.1 BER). In that case the rating input is embedded in the Service-Parameter-Info AVP as defined in section 8.23. New service applications SHOULD favor the use of explicitly defined AVPs, to simplify interoperability. The service specific rating input AVPs, the contents of the Service-Parameter-Info AVP or Service-Identifier AVP are not within the scope of this document. To facilitate interoperability, it is RECOMMENDED that the rating input and values of service identifiers are coordinated via an informational RFC or other permanent and readily available reference such as the specification of another cooperative standardization body (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services may be deployed that are subject to agreements between providers of the credit control server and client, in this case vendor specific AVPs can be used. This specification, together with service specific documents, is governing the credit control message. The rule is that service specific documents only define what existing AVPs or new AVPs are used as input to the rating process (i.e. they do not define new credit control applications), and thus need to be included in the Credit-Control-Request command by a Diameter Credit Control Client supporting a given service as *[AVP]. In order to define new AVPs, service specific documents MUST follow the practices defined in [DIAMBASE]. The service SHOULD be identified using the Service-Identifier AVP at command level. The Service-Identifier AVP SHOULD be a unique identifier for a given service as defined in section 8.40. Diameter credit control implementations are required to support the Mandatory rating AVPs defined in service specific documentation of the services they support. Introducing new credit control mechanisms not defined in this specification implies the definition of a new version of the Diameter Credit Control Application and corresponding Application Identifier. In case a rating input required for the rating process is missing from the Credit control request, or the credit control server does not support the requested service (i.e. does not support one or more Mandatory rating AVPs included in the request command), the Credit control answer MUST contain error code DIAMETER_RATING_FAILED. A CCR message with this error MUST contain one or more Failed-AVP AVPs containing the missing and/or unsupported AVPs that caused the failure. A Diameter credit control client receiving error code DIAMETER_RATING_FAILED in answer to a request MUST NOT send such similar requests in the future. Regards.............Harri ****************************************************************************** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination, disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages of this kind. The opinions, conclusions and other information in this message are of the author and shall be understood as neither given nor endorsed by Vodafone Ireland Limited unless it is otherwise indicated by an authorised representative independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone Ireland Limited has no control. As such, there is no guarantee that (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender (iii) this e-mail has not been intercepted by a third party (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this message (including its attachments) has been processed by an automated anti-virus system; however it is the responsibility of the recipient to ensure that the message (and attachments) are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18. Number 326967 VAT Reg No. IE6346967G ****************************************************************************** --=_alternative 0063B9EE80256DFD_= Content-Type: text/html; charset="us-ascii"
Hi Harri,

I'm happy that this would mean that anyone integrating Diameter CCA nodes would have a clear means of understanding interoperability.  There would probably still be some fragmentation of the service provided.  Obviously, it would help if most services were registered with standardisation bodies, but I realise your recommendation is as much as can be done within CCA.

I would like to suggest that an explicit statement is added to the effect that "It is the combination of support of the DCC application and the service defined in Service-Identifier, that defines interoperability between any given DCC client and server" or words to that effect.

Is that OK?

Regards,

John.








"Harri Hakala (TU/LMF)" <harri.hakala@ericsson.com>

15/12/2003 11:54

       
        To:        "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" <jeff.meyer2@hp.com>, "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
        cc:        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, "'Benni.Alexander@nokia.com'" <Benni.Alexander@nokia.com>, "'crich@nortelnetworks.com'" <crich@nortelnetworks.com>, "'john.loughney@nokia.com'" <john.loughney@nokia.com>, "'juha-pekka.koskinen@nokia.com'" <juha-pekka.koskinen@nokia.com>, "'Karl-Heinz.Nenner@t-mobile.de'" <Karl-Heinz.Nenner@t-mobile.de>, "Leena Mattila (TU/LMF)" <leena.mattila@ericsson.com>, "'marco.stura@nokia.com'" <marco.stura@nokia.com>, "'owner-aaa-wg@merit.edu'" <owner-aaa-wg@merit.edu>, "Patrik Teppo (KA/EAB)" <patrik.teppo@ericsson.com>
        Subject:        RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero        perability



Hi John & Jeff,

Thank you for your comments and your additional clarifications.
Related to your comments:

John wrote:
>All in all, I believe introducing optional mandatory
>parameters into CCA will have a major effect on its
>future direction.  My feeling is that CCA shouldn't
>do it, which passes the responsibility on to the
>subsequent applications that build on CCA to decide
>whether the AVPs they use are mandatory or optional.

Jeff wrote:
>So, it seems to me that enabling extensions to the base CCA
>which turn on the mandatory bit IS a valid use case.  And that
>implementations SHOULD notify the application entity sitting
>on top of the Diameter protocol stack that a mandatory field
>is present, but unrecognized.  But the application itself
>should be able to decide whether it considers this fatal or
>simply proceeds.

I agree, the rule about 'M'-bit usage might have not been the best
possible one, and in fact, not needed. We removed that sentence from
the section 4.1, so that the rules in the base apply.

Instead, we tried to clarify that each service shall document and specify
the rating AVPs that service shall use and it will be up to that service
in question whether to use 'M'-bit for some AVP or not.

We propose following new text:

4.1 Service-specific Rating Input and Interoperability

The Diameter Credit Control Application defines the framework for
credit control, it provides generic credit control mechanisms supporting
multiple service applications. The Credit Control Application, therefore,
does not define AVPs that could be used as input in the rating process.
Listing the possible services that could use this Diameter application is
seen as out of scope for this generic mechanism as well.

It is reasonable to expect that there will exist a service level agreement
between providers of the credit control client and the credit control
server covering the charging, services offered, roaming agreements,
agreed rating input, etc.

There are two ways for providing rating input to the credit control
server, either by using AVPs or by including them in the Service-
Parameter-Info AVP. The general principle for sending rating
parameters is that the service SHOULD re-use existing AVPs, if the
service can use AVPs defined in existing service specific Diameter
applications (e.g. NASREQ for network access services).
Alternatively, new AVPs can be defined if the existing AVPs do not
provide sufficient rating information. The Service-Parameter-Info AVP
MAY be used as a container to pass legacy rating information in its
original encoded form (e.g. ASN.1 BER). In that case the rating input
is embedded in the Service-Parameter-Info AVP as defined in section 8.23.
New service applications SHOULD favor the use of explicitly defined
AVPs, to simplify interoperability.

The service specific rating input AVPs, the contents of the
Service-Parameter-Info AVP or Service-Identifier AVP are not within
the scope of this document. To facilitate interoperability, it is
RECOMMENDED that the rating input and values of service identifiers are
coordinated via an informational RFC or other permanent and readily available
reference such as the specification of another cooperative standardization body
(e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services may
be deployed that are subject to agreements between providers of the credit
control server and client, in this case vendor specific AVPs can be used.

This specification, together with service specific documents, is governing
the credit control message. The rule is that service specific documents only
define what existing AVPs or new AVPs are used as input to the rating
process (i.e. they do not define new credit control applications), and thus
need to be included in the Credit-Control-Request command by a Diameter
Credit Control Client supporting a given service as *[AVP]. In order to define
new AVPs, service specific documents MUST follow the practices defined in
[DIAMBASE]. The service SHOULD be identified using the Service-Identifier AVP
at command level. The Service-Identifier AVP SHOULD be a unique identifier
for a given service as defined in section 8.40. Diameter credit control
implementations are required to support the Mandatory rating AVPs defined in
service specific documentation of the services they support. Introducing
new credit control mechanisms not defined in this specification implies
the definition of a new version of the Diameter Credit Control Application
and corresponding Application Identifier.

In case a rating input required for the rating process is missing from
the Credit control request, or the credit control server does not
support the requested service (i.e. does not support one or more
Mandatory rating AVPs included in the request command), the Credit control
answer MUST contain error code DIAMETER_RATING_FAILED. A CCR message
with this error MUST contain one or more Failed-AVP AVPs containing the
missing and/or unsupported AVPs that caused the failure.
A Diameter credit control client receiving error code DIAMETER_RATING_FAILED
in answer to a request MUST NOT send such similar requests in the future.

Regards.............Harri



******************************************************************************

The content of this e-mail may be privileged and/or confidential.
If you are not the addressee indicated in this message
(or responsible for delivery of the message to such person),
you may not copy or deliver this message to anyone. In such
case, you should destroy this message and kindly notify the
sender and postmaster@vodafone.ie by reply email. Please
note that in such circumstances any review, dissemination,
disclosure, alteration, printing, copying or further transmission
of this e-mail and/or any file transmitted with it is prohibited
and may be unlawful. Please advise us immediately if you or
your employer do not consent to Internet email for messages
of this kind. The opinions, conclusions and other information
in this message are of the author and shall be understood as
neither given nor endorsed by Vodafone Ireland Limited
unless it is otherwise indicated by an authorised representative
independent of this message. Internet e-mail is
transmitted over the public internet over which Vodafone
Ireland Limited has no control. As such, there is no guarantee that
(i) this e-mail will be delivered within a reasonable time or at all
(ii) this e-mail comes from the purported sender
(iii) this e-mail has not been intercepted by a third party
(iv) the contents of this e-mail are unaltered from the time of
transmission. The presence of this footnote indicates that this
message (including its attachments) has been processed by an
automated anti-virus system; however it is the responsibility of
the recipient to ensure that the message (and attachments)
are safe and authorised for use in their environment.
Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK),
Pauline Best (UK), Paul Donovan Chief Executive (UK),
Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK).
Registered in Ireland at MountainView, Leopardstown, Dublin 18.
Number 326967 VAT Reg No. IE6346967G

******************************************************************************
 --=_alternative 0063B9EE80256DFD_=-- From owner-aaa-wg@merit.edu Mon Dec 15 15:58:16 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29417 for ; Mon, 15 Dec 2003 15:58:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3EE6391235; Mon, 15 Dec 2003 15:58:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08ADB91234; Mon, 15 Dec 2003 15:58:03 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 35EB491235 for ; Mon, 15 Dec 2003 15:58:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id DACC65DDAE; Mon, 15 Dec 2003 15:58:01 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by segue.merit.edu (Postfix) with ESMTP id 702AC5DD8F; Mon, 15 Dec 2003 15:58:01 -0500 (EST) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel9.hp.com (Postfix) with ESMTP id D00001C01BDF; Mon, 15 Dec 2003 15:58:00 -0500 (EST) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id A01F01C00C62; Mon, 15 Dec 2003 15:57:48 -0500 (EST) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2657.72) id ; Mon, 15 Dec 2003 15:57:48 -0500 Message-ID: <1758A044D46A8A4CB320429F9462D6C248F817@xsun03.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Harri Hakala (TU/LMF)'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" , "'John.Prudhoe@vodafone.com'" Cc: "'aaa-wg@merit.edu'" , "'Benni.Alexander@nokia.com'" , "'crich@nortelnetworks.com'" , "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "'Leena Mattila (TU/LMF)'" , "'marco.stura@nokia.com'" , "'owner-aaa-wg@merit.edu'" , "'Patrik Teppo (KA/EAB)'" Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero perability Date: Mon, 15 Dec 2003 15:57:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Harri, The text looks good to me. Regards, Jeff Meyer > -----Original Message----- > From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] > Sent: Monday, December 15, 2003 3:54 AM > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'John.Prudhoe@vodafone.com' > Cc: 'aaa-wg@merit.edu'; 'Benni.Alexander@nokia.com'; > 'crich@nortelnetworks.com'; 'john.loughney@nokia.com'; > 'juha-pekka.koskinen@nokia.com'; > 'Karl-Heinz.Nenner@t-mobile.de'; Leena > Mattila (TU/LMF); 'marco.stura@nokia.com'; 'owner-aaa-wg@merit.edu'; > Patrik Teppo (KA/EAB) > Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and > Intero perability > > > Hi John & Jeff, > > Thank you for your comments and your additional clarifications. > Related to your comments: > > John wrote: > >All in all, I believe introducing optional mandatory > >parameters into CCA will have a major effect on its > >future direction. My feeling is that CCA shouldn't > >do it, which passes the responsibility on to the > >subsequent applications that build on CCA to decide > >whether the AVPs they use are mandatory or optional. > > Jeff wrote: > >So, it seems to me that enabling extensions to the base CCA > >which turn on the mandatory bit IS a valid use case. And that > >implementations SHOULD notify the application entity sitting > >on top of the Diameter protocol stack that a mandatory field > >is present, but unrecognized. But the application itself > >should be able to decide whether it considers this fatal or > >simply proceeds. > > I agree, the rule about 'M'-bit usage might have not been the best > possible one, and in fact, not needed. We removed that sentence from > the section 4.1, so that the rules in the base apply. > > Instead, we tried to clarify that each service shall document > and specify > the rating AVPs that service shall use and it will be up to > that service > in question whether to use 'M'-bit for some AVP or not. > > We propose following new text: > > 4.1 Service-specific Rating Input and Interoperability > > The Diameter Credit Control Application defines the framework for > credit control, it provides generic credit control mechanisms > supporting > multiple service applications. The Credit Control > Application, therefore, > does not define AVPs that could be used as input in the > rating process. > Listing the possible services that could use this Diameter > application is > seen as out of scope for this generic mechanism as well. > > It is reasonable to expect that there will exist a service > level agreement > between providers of the credit control client and the credit control > server covering the charging, services offered, roaming agreements, > agreed rating input, etc. > > There are two ways for providing rating input to the credit control > server, either by using AVPs or by including them in the Service- > Parameter-Info AVP. The general principle for sending rating > parameters is that the service SHOULD re-use existing AVPs, if the > service can use AVPs defined in existing service specific Diameter > applications (e.g. NASREQ for network access services). > Alternatively, new AVPs can be defined if the existing AVPs do not > provide sufficient rating information. The Service-Parameter-Info AVP > MAY be used as a container to pass legacy rating information in its > original encoded form (e.g. ASN.1 BER). In that case the rating input > is embedded in the Service-Parameter-Info AVP as defined in > section 8.23. > New service applications SHOULD favor the use of explicitly defined > AVPs, to simplify interoperability. > > The service specific rating input AVPs, the contents of the > Service-Parameter-Info AVP or Service-Identifier AVP are not within > the scope of this document. To facilitate interoperability, it is > RECOMMENDED that the rating input and values of service > identifiers are > coordinated via an informational RFC or other permanent and > readily available > reference such as the specification of another cooperative > standardization body > (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private > services may > be deployed that are subject to agreements between providers > of the credit > control server and client, in this case vendor specific AVPs > can be used. > > This specification, together with service specific documents, > is governing > the credit control message. The rule is that service specific > documents only > define what existing AVPs or new AVPs are used as input to the rating > process (i.e. they do not define new credit control > applications), and thus > need to be included in the Credit-Control-Request command by > a Diameter > Credit Control Client supporting a given service as *[AVP]. > In order to define > new AVPs, service specific documents MUST follow the > practices defined in > [DIAMBASE]. The service SHOULD be identified using the > Service-Identifier AVP > at command level. The Service-Identifier AVP SHOULD be a > unique identifier > for a given service as defined in section 8.40. Diameter > credit control > implementations are required to support the Mandatory rating > AVPs defined in > service specific documentation of the services they support. > Introducing > new credit control mechanisms not defined in this > specification implies > the definition of a new version of the Diameter Credit > Control Application > and corresponding Application Identifier. > > In case a rating input required for the rating process is missing from > the Credit control request, or the credit control server does not > support the requested service (i.e. does not support one or more > Mandatory rating AVPs included in the request command), the > Credit control > answer MUST contain error code DIAMETER_RATING_FAILED. A CCR message > with this error MUST contain one or more Failed-AVP AVPs > containing the > missing and/or unsupported AVPs that caused the failure. > A Diameter credit control client receiving error code > DIAMETER_RATING_FAILED > in answer to a request MUST NOT send such similar requests in > the future. > > Regards.............Harri > From owner-aaa-wg@merit.edu Mon Dec 15 17:06:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02837 for ; Mon, 15 Dec 2003 17:06:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 42B0F91239; Mon, 15 Dec 2003 17:06:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16B459123A; Mon, 15 Dec 2003 17:06:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 768DD91239 for ; Mon, 15 Dec 2003 17:05:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5C5AC5DDB6; Mon, 15 Dec 2003 17:05:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 014D95DDAE for ; Mon, 15 Dec 2003 17:05:58 -0500 (EST) Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 06BBD6A901; Tue, 16 Dec 2003 00:05:39 +0200 (EET) Message-ID: <3FDE3002.2060309@kolumbus.fi> Date: Tue, 16 Dec 2003 00:04:50 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: diameter-eap some minor comments References: <20031212145930.GK16373@ipv6-5.int-evry.fr> <3FDAD51E.1050300@kolumbus.fi> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > I would say there are two orthogonal issues: how the key is delivered, > and whether the AAA server is requesting that security services be > provided. The keying AVPs only address the first issue; if security is > required, this needs to be encoded separately (as it is in the RFC 2548 > attrbutes). > > For example, the key could be provided, and the AAA server could be > indifferent to whether it is used or not. Or it could *require* that it > be used. The difference between these two cases is particularly important > in fast handoff or context transfer, where you don't necessarily want a > host to move from an access point that supports security to one that does > not. Agreed. >>If one wants even domain identity protection over the wireless, >>then there has to be (a) some sort of a tunnel EAP method -- with >>implied consequences > > Not necessarily. Identity protection can be provided within a method > without allowing any arbitrary EAP method to be executed inside of it. I think you mean that the username part can be hidden by methods. I'm not sure the domain name part can be hidden by methods, unless the method does tunneling of some sort. We have the following constraints: o To get to the right home server, we need the domain o The domain can not be exposed on the wireless interface So lets assume its an EAP method that provides the domain identity protection. Since the domain is hidden over wireless, and needs to be known for AAA routing, there has to be a node that does the translation. Assuming that the selection of the EAP method is transparent to everyone else except the client and the home server, it does not seem possible to terminate a domain-hiding EAP method at some intermediate node -- unless that method did some sort of general tunneling where the terminated part did not know what was going on inside. But I could be missing something. --Jari From owner-aaa-wg@merit.edu Tue Dec 16 03:40:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04524 for ; Tue, 16 Dec 2003 03:40:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3311C9123E; Tue, 16 Dec 2003 03:40:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EAE3B9123F; Tue, 16 Dec 2003 03:40:01 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A05279123E for ; Tue, 16 Dec 2003 03:39:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7800E5DDC1; Tue, 16 Dec 2003 03:39:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by segue.merit.edu (Postfix) with ESMTP id 44EAD5DDAC; Tue, 16 Dec 2003 03:39:58 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBG8du8K030087; Tue, 16 Dec 2003 09:39:56 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Dec 2003 09:41:07 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'John.Prudhoe@vodafone.com'" Cc: "'aaa-wg@merit.edu'" , "'Benni.Alexander@nokia.com'" , "'crich@nortelnetworks.com'" , "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" , "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "Leena Mattila (TU/LMF)" , "'marco.stura@nokia.com'" , "'owner-aaa-wg@merit.edu'" , "Patrik Teppo (KA/EAB)" Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero perability Date: Tue, 16 Dec 2003 09:39:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C3AF.0D4DC85B" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3C3AF.0D4DC85B Content-Type: text/plain; charset="ISO-8859-1" Hi John, I would like to suggest that an explicit statement is added to the effect that "It is the combination of support of the DCC application and the service defined in Service-Identifier, that defines interoperability between any given DCC client and server" or words to that effect. We will add the statement, thanks. Regards...........Harri -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: 15. joulukuuta 2003 20:09 To: Harri Hakala (TU/LMF) Cc: 'aaa-wg@merit.edu'; 'Benni.Alexander@nokia.com'; 'crich@nortelnetworks.com'; 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'john.loughney@nokia.com'; 'John.Prudhoe@vodafone.com'; 'juha-pekka.koskinen@nokia.com'; 'Karl-Heinz.Nenner@t-mobile.de'; Leena Mattila (TU/LMF); 'marco.stura@nokia.com'; 'owner-aaa-wg@merit.edu'; Patrik Teppo (KA/EAB) Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero perability Hi Harri, I'm happy that this would mean that anyone integrating Diameter CCA nodes would have a clear means of understanding interoperability. There would probably still be some fragmentation of the service provided. Obviously, it would help if most services were registered with standardisation bodies, but I realise your recommendation is as much as can be done within CCA. I would like to suggest that an explicit statement is added to the effect that "It is the combination of support of the DCC application and the service defined in Service-Identifier, that defines interoperability between any given DCC client and server" or words to that effect. Is that OK? Regards, John. "Harri Hakala (TU/LMF)" 15/12/2003 11:54 To: "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" , "'John.Prudhoe@vodafone.com'" cc: "'aaa-wg@merit.edu'" , "'Benni.Alexander@nokia.com'" , "'crich@nortelnetworks.com'" , "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "Leena Mattila (TU/LMF)" , "'marco.stura@nokia.com'" , "'owner-aaa-wg@merit.edu'" , "Patrik Teppo (KA/EAB)" Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero perability Hi John & Jeff, Thank you for your comments and your additional clarifications. Related to your comments: John wrote: >All in all, I believe introducing optional mandatory >parameters into CCA will have a major effect on its >future direction. My feeling is that CCA shouldn't >do it, which passes the responsibility on to the >subsequent applications that build on CCA to decide >whether the AVPs they use are mandatory or optional. Jeff wrote: >So, it seems to me that enabling extensions to the base CCA >which turn on the mandatory bit IS a valid use case. And that >implementations SHOULD notify the application entity sitting >on top of the Diameter protocol stack that a mandatory field >is present, but unrecognized. But the application itself >should be able to decide whether it considers this fatal or >simply proceeds. I agree, the rule about 'M'-bit usage might have not been the best possible one, and in fact, not needed. We removed that sentence from the section 4.1, so that the rules in the base apply. Instead, we tried to clarify that each service shall document and specify the rating AVPs that service shall use and it will be up to that service in question whether to use 'M'-bit for some AVP or not. We propose following new text: 4.1 Service-specific Rating Input and Interoperability The Diameter Credit Control Application defines the framework for credit control, it provides generic credit control mechanisms supporting multiple service applications. The Credit Control Application, therefore, does not define AVPs that could be used as input in the rating process. Listing the possible services that could use this Diameter application is seen as out of scope for this generic mechanism as well. It is reasonable to expect that there will exist a service level agreement between providers of the credit control client and the credit control server covering the charging, services offered, roaming agreements, agreed rating input, etc. There are two ways for providing rating input to the credit control server, either by using AVPs or by including them in the Service- Parameter-Info AVP. The general principle for sending rating parameters is that the service SHOULD re-use existing AVPs, if the service can use AVPs defined in existing service specific Diameter applications (e.g. NASREQ for network access services). Alternatively, new AVPs can be defined if the existing AVPs do not provide sufficient rating information. The Service-Parameter-Info AVP MAY be used as a container to pass legacy rating information in its original encoded form (e.g. ASN.1 BER). In that case the rating input is embedded in the Service-Parameter-Info AVP as defined in section 8.23. New service applications SHOULD favor the use of explicitly defined AVPs, to simplify interoperability. The service specific rating input AVPs, the contents of the Service-Parameter-Info AVP or Service-Identifier AVP are not within the scope of this document. To facilitate interoperability, it is RECOMMENDED that the rating input and values of service identifiers are coordinated via an informational RFC or other permanent and readily available reference such as the specification of another cooperative standardization body (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services may be deployed that are subject to agreements between providers of the credit control server and client, in this case vendor specific AVPs can be used. This specification, together with service specific documents, is governing the credit control message. The rule is that service specific documents only define what existing AVPs or new AVPs are used as input to the rating process (i.e. they do not define new credit control applications), and thus need to be included in the Credit-Control-Request command by a Diameter Credit Control Client supporting a given service as *[AVP]. In order to define new AVPs, service specific documents MUST follow the practices defined in [DIAMBASE]. The service SHOULD be identified using the Service-Identifier AVP at command level. The Service-Identifier AVP SHOULD be a unique identifier for a given service as defined in section 8.40. Diameter credit control implementations are required to support the Mandatory rating AVPs defined in service specific documentation of the services they support. Introducing new credit control mechanisms not defined in this specification implies the definition of a new version of the Diameter Credit Control Application and corresponding Application Identifier. In case a rating input required for the rating process is missing from the Credit control request, or the credit control server does not support the requested service (i.e. does not support one or more Mandatory rating AVPs included in the request command), the Credit control answer MUST contain error code DIAMETER_RATING_FAILED. A CCR message with this error MUST contain one or more Failed-AVP AVPs containing the missing and/or unsupported AVPs that caused the failure. A Diameter credit control client receiving error code DIAMETER_RATING_FAILED in answer to a request MUST NOT send such similar requests in the future. Regards.............Harri ****************************************************************************** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination, disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages of this kind. The opinions, conclusions and other information in this message are of the author and shall be understood as neither given nor endorsed by Vodafone Ireland Limited unless it is otherwise indicated by an authorised representative independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone Ireland Limited has no control. As such, there is no guarantee that (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender (iii) this e-mail has not been intercepted by a third party (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this message (including its attachments) has been processed by an automated anti-virus system; however it is the responsibility of the recipient to ensure that the message (and attachments) are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18. Number 326967 VAT Reg No. IE6346967G ****************************************************************************** ------_=_NextPart_001_01C3C3AF.0D4DC85B Content-Type: text/html; charset="ISO-8859-1"

Hi John,
 
I would like to suggest that an explicit statement is added to the effect that "It is the combination of support of the DCC application and the service defined in Service-Identifier, that defines interoperability between any given DCC client and server" or words to that effect.
We will add the statement, thanks.
 
Regards...........Harri
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: 15. joulukuuta 2003 20:09
To: Harri Hakala (TU/LMF)
Cc: 'aaa-wg@merit.edu'; 'Benni.Alexander@nokia.com'; 'crich@nortelnetworks.com'; 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'john.loughney@nokia.com'; 'John.Prudhoe@vodafone.com'; 'juha-pekka.koskinen@nokia.com'; 'Karl-Heinz.Nenner@t-mobile.de'; Leena Mattila (TU/LMF); 'marco.stura@nokia.com'; 'owner-aaa-wg@merit.edu'; Patrik Teppo (KA/EAB)
Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero perability


Hi Harri,

I'm happy that this would mean that anyone integrating Diameter CCA nodes would have a clear means of understanding interoperability.  There would probably still be some fragmentation of the service provided.  Obviously, it would help if most services were registered with standardisation bodies, but I realise your recommendation is as much as can be done within CCA.

I would like to suggest that an explicit statement is added to the effect that "It is the combination of support of the DCC application and the service defined in Service-Identifier, that defines interoperability between any given DCC client and server" or words to that effect.

Is that OK?

Regards,

John.








"Harri Hakala (TU/LMF)" <harri.hakala@ericsson.com>

15/12/2003 11:54

       
        To:        "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" <jeff.meyer2@hp.com>, "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
        cc:        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, "'Benni.Alexander@nokia.com'" <Benni.Alexander@nokia.com>, "'crich@nortelnetworks.com'" <crich@nortelnetworks.com>, "'john.loughney@nokia.com'" <john.loughney@nokia.com>, "'juha-pekka.koskinen@nokia.com'" <juha-pekka.koskinen@nokia.com>, "'Karl-Heinz.Nenner@t-mobile.de'" <Karl-Heinz.Nenner@t-mobile.de>, "Leena Mattila (TU/LMF)" <leena.mattila@ericsson.com>, "'marco.stura@nokia.com'" <marco.stura@nokia.com>, "'owner-aaa-wg@merit.edu'" <owner-aaa-wg@merit.edu>, "Patrik Teppo (KA/EAB)" <patrik.teppo@ericsson.com>
        Subject:        RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero        perability



Hi John & Jeff,

Thank you for your comments and your additional clarifications.
Related to your comments:

John wrote:
>All in all, I believe introducing optional mandatory
>parameters into CCA will have a major effect on its
>future direction.  My feeling is that CCA shouldn't
>do it, which passes the responsibility on to the
>subsequent applications that build on CCA to decide
>whether the AVPs they use are mandatory or optional.

Jeff wrote:
>So, it seems to me that enabling extensions to the base CCA
>which turn on the mandatory bit IS a valid use case.  And that
>implementations SHOULD notify the application entity sitting
>on top of the Diameter protocol stack that a mandatory field
>is present, but unrecognized.  But the application itself
>should be able to decide whether it considers this fatal or
>simply proceeds.

I agree, the rule about 'M'-bit usage might have not been the best
possible one, and in fact, not needed. We removed that sentence from
the section 4.1, so that the rules in the base apply.

Instead, we tried to clarify that each service shall document and specify
the rating AVPs that service shall use and it will be up to that service
in question whether to use 'M'-bit for some AVP or not.

We propose following new text:

4.1 Service-specific Rating Input and Interoperability

The Diameter Credit Control Application defines the framework for
credit control, it provides generic credit control mechanisms supporting
multiple service applications. The Credit Control Application, therefore,
does not define AVPs that could be used as input in the rating process.
Listing the possible services that could use this Diameter application is
seen as out of scope for this generic mechanism as well.

It is reasonable to expect that there will exist a service level agreement
between providers of the credit control client and the credit control
server covering the charging, services offered, roaming agreements,
agreed rating input, etc.

There are two ways for providing rating input to the credit control
server, either by using AVPs or by including them in the Service-
Parameter-Info AVP. The general principle for sending rating
parameters is that the service SHOULD re-use existing AVPs, if the
service can use AVPs defined in existing service specific Diameter
applications (e.g. NASREQ for network access services).
Alternatively, new AVPs can be defined if the existing AVPs do not
provide sufficient rating information. The Service-Parameter-Info AVP
MAY be used as a container to pass legacy rating information in its
original encoded form (e.g. ASN.1 BER). In that case the rating input
is embedded in the Service-Parameter-Info AVP as defined in section 8.23.
New service applications SHOULD favor the use of explicitly defined
AVPs, to simplify interoperability.

The service specific rating input AVPs, the contents of the
Service-Parameter-Info AVP or Service-Identifier AVP are not within
the scope of this document. To facilitate interoperability, it is
RECOMMENDED that the rating input and values of service identifiers are
coordinated via an informational RFC or other permanent and readily available
reference such as the specification of another cooperative standardization body
(e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services may
be deployed that are subject to agreements between providers of the credit
control server and client, in this case vendor specific AVPs can be used.

This specification, together with service specific documents, is governing
the credit control message. The rule is that service specific documents only
define what existing AVPs or new AVPs are used as input to the rating
process (i.e. they do not define new credit control applications), and thus
need to be included in the Credit-Control-Request command by a Diameter
Credit Control Client supporting a given service as *[AVP]. In order to define
new AVPs, service specific documents MUST follow the practices defined in
[DIAMBASE]. The service SHOULD be identified using the Service-Identifier AVP
at command level. The Service-Identifier AVP SHOULD be a unique identifier
for a given service as defined in section 8.40. Diameter credit control
implementations are required to support the Mandatory rating AVPs defined in
service specific documentation of the services they support. Introducing
new credit control mechanisms not defined in this specification implies
the definition of a new version of the Diameter Credit Control Application
and corresponding Application Identifier.

In case a rating input required for the rating process is missing from
the Credit control request, or the credit control server does not
support the requested service (i.e. does not support one or more
Mandatory rating AVPs included in the request command), the Credit control
answer MUST contain error code DIAMETER_RATING_FAILED. A CCR message
with this error MUST contain one or more Failed-AVP AVPs containing the
missing and/or unsupported AVPs that caused the failure.
A Diameter credit control client receiving error code DIAMETER_RATING_FAILED
in answer to a request MUST NOT send such similar requests in the future.

Regards.............Harri




******************************************************************************

The content of this e-mail may be privileged and/or confidential.
If you are not the addressee indicated in this message
(or responsible for delivery of the message to such person),
you may not copy or deliver this message to anyone. In such
case, you should destroy this message and kindly notify the
sender and postmaster@vodafone.ie by reply email. Please
note that in such circumstances any review, dissemination,
disclosure, alteration, printing, copying or further transmission
of this e-mail and/or any file transmitted with it is prohibited
and may be unlawful. Please advise us immediately if you or
your employer do not consent to Internet email for messages
of this kind. The opinions, conclusions and other information
in this message are of the author and shall be understood as
neither given nor endorsed by Vodafone Ireland Limited
unless it is otherwise indicated by an authorised representative
independent of this message. Internet e-mail is
transmitted over the public internet over which Vodafone
Ireland Limited has no control. As such, there is no guarantee that
(i) this e-mail will be delivered within a reasonable time or at all
(ii) this e-mail comes from the purported sender
(iii) this e-mail has not been intercepted by a third party
(iv) the contents of this e-mail are unaltered from the time of
transmission. The presence of this footnote indicates that this
message (including its attachments) has been processed by an
automated anti-virus system; however it is the responsibility of
the recipient to ensure that the message (and attachments)
are safe and authorised for use in their environment.
Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK),
Pauline Best (UK), Paul Donovan Chief Executive (UK),
Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK).
Registered in Ireland at MountainView, Leopardstown, Dublin 18.
Number 326967 VAT Reg No. IE6346967G

******************************************************************************
------_=_NextPart_001_01C3C3AF.0D4DC85B-- From owner-aaa-wg@merit.edu Tue Dec 16 06:33:07 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11896 for ; Tue, 16 Dec 2003 06:33:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F108491243; Tue, 16 Dec 2003 06:32:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2BF791245; Tue, 16 Dec 2003 06:32:55 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A063991243 for ; Tue, 16 Dec 2003 06:32:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7CC3F5DD96; Tue, 16 Dec 2003 06:32:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from herculanum.int-evry.fr (herculanum.int-evry.fr [157.159.11.15]) by segue.merit.edu (Postfix) with ESMTP id 0B84E5DDAC for ; Tue, 16 Dec 2003 06:32:54 -0500 (EST) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id E121733BA1; Tue, 16 Dec 2003 12:32:52 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id E10283F467; Tue, 16 Dec 2003 12:32:47 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003121612320418039 ; Tue, 16 Dec 2003 12:32:04 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 07F333F46D; Tue, 16 Dec 2003 12:32:42 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1AWDQG-0008BX-2y; Tue, 16 Dec 2003 12:31:28 +0100 Date: Tue, 16 Dec 2003 12:31:28 +0100 From: Julien Bournelle To: Jari Arkko Cc: aaa-wg@merit.edu, Pasi Eronen Subject: Re: [AAA-WG]: diameter-eap some minor comments Message-ID: <20031216113128.GR16373@ipv6-5.int-evry.fr> References: <20031212145930.GK16373@ipv6-5.int-evry.fr> <3FDAD51E.1050300@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3FDAD51E.1050300@kolumbus.fi> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi, On Sat, Dec 13, 2003 at 11:00:14AM +0200, Jari Arkko wrote: > >-2- In the second scenario described in §2.2, the NAS sends the DER > >message directly to the home server. Why do not send it to its local > >Diameter Server ? > > Section 2.2 does not discuss the possibility of local proxies yet. > This is handled in Section 2.3, which has a number of different > scenarios, including scenario 2 where redirects are used to > run the EAP AAA end-to-end between the NAS and the home server, and > scenario 4 which is the typical RADIUS-like proxy model. that's right but in Diameter-Mobile-IPv4, the FA (<=> NAS) sends requests to its local Diameter Server (AAAF). Here, the NAS can send requests to: - redirect agent - proxy agent - to the home server so it appears that there is a different approach between the two drafts. > This is ultimately a link-layer dependent issue. Home servers would > typically > provide the keying material, but depending on the link layer in question, > the NAS would use the keying material in different ways. Presumably > there can be cases where the keying material is not used at all. I would > say in this case the NAS simply throws the AVP away. > > Do you see an issue here? The home server may "think" that it exists a "protection" between its client and the local NAS but I'm not sure that is an issue. > >-4- In §2.8.1, I just wanted to note that we are going to face problem > >if we use an EAP method with identity protection in roaming > >scenario.(NAS won't be able to route Request) > > Yes. Note that if only the user name part, not the domain, is hidden, > then there is no issue. Some EAP methods use this kind of identity > protection. This is discussed in RFC 2284bis. ok I didn't know (thanks) -- julien.bournelle@int-evry.fr From owner-aaa-wg@merit.edu Tue Dec 16 06:37:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12028 for ; Tue, 16 Dec 2003 06:37:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 29C7291245; Tue, 16 Dec 2003 06:37:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E37AB91246; Tue, 16 Dec 2003 06:37:10 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9472C91245 for ; Tue, 16 Dec 2003 06:37:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 815565DDD5; Tue, 16 Dec 2003 06:37:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 363D65DD96 for ; Tue, 16 Dec 2003 06:37:05 -0500 (EST) Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 1621D6A903; Tue, 16 Dec 2003 13:37:04 +0200 (EET) Message-ID: <3FDEEE2F.5090909@kolumbus.fi> Date: Tue, 16 Dec 2003 13:36:15 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julien Bournelle Cc: aaa-wg@merit.edu, Pasi Eronen Subject: Re: [AAA-WG]: diameter-eap some minor comments References: <20031212145930.GK16373@ipv6-5.int-evry.fr> <3FDAD51E.1050300@kolumbus.fi> <20031216113128.GR16373@ipv6-5.int-evry.fr> In-Reply-To: <20031216113128.GR16373@ipv6-5.int-evry.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julien Bournelle wrote: > Hi, > > > On Sat, Dec 13, 2003 at 11:00:14AM +0200, Jari Arkko wrote: > >>>-2- In the second scenario described in §2.2, the NAS sends the DER >>>message directly to the home server. Why do not send it to its local >>>Diameter Server ? >> >>Section 2.2 does not discuss the possibility of local proxies yet. >>This is handled in Section 2.3, which has a number of different >>scenarios, including scenario 2 where redirects are used to >>run the EAP AAA end-to-end between the NAS and the home server, and >>scenario 4 which is the typical RADIUS-like proxy model. > > > that's right but in Diameter-Mobile-IPv4, the FA (<=> NAS) sends > requests to its local Diameter Server (AAAF). Here, the NAS can send > requests to: > - redirect agent > - proxy agent > - to the home server > > so it appears that there is a different approach between the two drafts. Perhaps -- though from the point of view of protocols, the NAS will be sending a message to the local diameter entity. Its then up to that entity whether it responds with a redirect, proxies the request, or handles it by itself. Do you see an issue here? >>This is ultimately a link-layer dependent issue. Home servers would >>typically >>provide the keying material, but depending on the link layer in question, >>the NAS would use the keying material in different ways. Presumably >>there can be cases where the keying material is not used at all. I would >>say in this case the NAS simply throws the AVP away. >> >>Do you see an issue here? > > > The home server may "think" that it exists a "protection" between its > client and the local NAS but I'm not sure that is an issue. Based on what Bernard said, this may be an issue if there is an expectation that security is provided where it is really not. It is not certain, however, that this is a specific issue for Diameter EAP -- it seems that the same problem appears for most of the authorization AVPs. Maybe 'M' bit would help. --Jari From owner-aaa-wg@merit.edu Tue Dec 16 14:23:16 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28350 for ; Tue, 16 Dec 2003 14:23:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 72FF291252; Tue, 16 Dec 2003 14:23:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40B5691253; Tue, 16 Dec 2003 14:23:01 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1E45B91252 for ; Tue, 16 Dec 2003 14:23:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 02C645DDFE; Tue, 16 Dec 2003 14:23:00 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 9B3FA5DDDB for ; Tue, 16 Dec 2003 14:22:59 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Dec 2003 14:22:55 -0500 Message-ID: From: Avi Lior To: "'radiusext@ops.ietf.org'" , aaa-wg@merit.edu Subject: [AAA-WG]: Question regarding IP Filter Rule Date: Tue, 16 Dec 2003 14:22:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk The Black I-D and PWLAN draft prompted me to check something out. It seems to me that something is missing in Diameter. Using the filter specification in 3588 its not clear how I force a forward. The only actions supported are permit or deny whereas ipfw supports a forward mechanism as well. The motivation for this is the requirement in (WLAN for example) whereby I want to force all http traffic to a specific portal and deny all other traffic until the portal instructs the NAS otherwise. This needs to be done either during an Access Accept or mid-session using COA. From owner-aaa-wg@merit.edu Tue Dec 16 14:33:12 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28688 for ; Tue, 16 Dec 2003 14:33:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A6E6091253; Tue, 16 Dec 2003 14:32:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 708BB91254; Tue, 16 Dec 2003 14:32:48 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 02FE891253 for ; Tue, 16 Dec 2003 14:32:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id DE0275DDD6; Tue, 16 Dec 2003 14:32:46 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id 4F0FF5DD94 for ; Tue, 16 Dec 2003 14:32:46 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBGJWZL00712; Tue, 16 Dec 2003 13:32:35 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Dec 2003 13:32:35 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8CB3@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'Avi Lior'" , "'radiusext@ops.ietf.org'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question regarding IP Filter Rule Date: Tue, 16 Dec 2003 13:32:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C40B.54A719EC" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3C40B.54A719EC Content-Type: text/plain Hi Avi, The Diameter RFC (And applications) specify where to redirect user traffic - not how. The "how" is implementation specific. Best Regards, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: Avi Lior [mailto:avi@bridgewatersystems.com] Sent: Tuesday, December 16, 2003 1:23 PM To: 'radiusext@ops.ietf.org'; aaa-wg@merit.edu Subject: [AAA-WG]: Question regarding IP Filter Rule The Black I-D and PWLAN draft prompted me to check something out. It seems to me that something is missing in Diameter. Using the filter specification in 3588 its not clear how I force a forward. The only actions supported are permit or deny whereas ipfw supports a forward mechanism as well. The motivation for this is the requirement in (WLAN for example) whereby I want to force all http traffic to a specific portal and deny all other traffic until the portal instructs the NAS otherwise. This needs to be done either during an Access Accept or mid-session using COA. ------_=_NextPart_001_01C3C40B.54A719EC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Question regarding IP Filter Rule

Hi Avi,

The Diameter RFC (And applications) specify where to = redirect user traffic - not how. The "how" is implementation = specific.

Best Regards,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281


-----Original Message-----
From: Avi Lior [mailto:avi@bridgewatersystems= .com]
Sent: Tuesday, December 16, 2003 1:23 PM
To: 'radiusext@ops.ietf.org'; = aaa-wg@merit.edu
Subject: [AAA-WG]: Question regarding IP Filter = Rule


The Black I-D and PWLAN draft prompted me to check = something out.

It seems to me that something is missing in = Diameter.  Using the filter specification in 3588 its not clear = how I force a forward.  The only actions supported are permit or = deny whereas ipfw supports a forward mechanism as well.

The motivation for this is the requirement in (WLAN = for example) whereby I want to force all http traffic to a specific = portal and deny all other traffic until the portal instructs the NAS = otherwise.  This needs to be done either during an Access Accept = or mid-session using COA.

------_=_NextPart_001_01C3C40B.54A719EC-- From owner-aaa-wg@merit.edu Tue Dec 16 15:06:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00233 for ; Tue, 16 Dec 2003 15:06:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E97539125B; Tue, 16 Dec 2003 15:03:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B52269125F; Tue, 16 Dec 2003 15:03:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 12D229125B for ; Tue, 16 Dec 2003 15:03:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id EEF515DDD8; Tue, 16 Dec 2003 15:03:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 9036C5DDD6 for ; Tue, 16 Dec 2003 15:03:29 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Dec 2003 15:03:29 -0500 Message-ID: From: Avi Lior To: "'Christopher Richards'" , Avi Lior , "'radiusext@ops.ietf.org'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question regarding IP Filter Rule Date: Tue, 16 Dec 2003 15:03:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C40F.AC0AD350" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3C40F.AC0AD350 Content-Type: text/plain Chris, Okay so forgive me but how do I specify where to redirect user traffic in diameter. Which attributes do that. Note I am not talking about where to redirect AAA traffic. Avi -----Original Message----- From: Christopher Richards [mailto:crich@nortelnetworks.com] Sent: Tuesday, December 16, 2003 2:32 PM To: 'Avi Lior'; 'radiusext@ops.ietf.org'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question regarding IP Filter Rule Hi Avi, The Diameter RFC (And applications) specify where to redirect user traffic - not how. The "how" is implementation specific. Best Regards, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: Avi Lior [mailto:avi@bridgewatersystems.com ] Sent: Tuesday, December 16, 2003 1:23 PM To: 'radiusext@ops.ietf.org'; aaa-wg@merit.edu Subject: [AAA-WG]: Question regarding IP Filter Rule The Black I-D and PWLAN draft prompted me to check something out. It seems to me that something is missing in Diameter. Using the filter specification in 3588 its not clear how I force a forward. The only actions supported are permit or deny whereas ipfw supports a forward mechanism as well. The motivation for this is the requirement in (WLAN for example) whereby I want to force all http traffic to a specific portal and deny all other traffic until the portal instructs the NAS otherwise. This needs to be done either during an Access Accept or mid-session using COA. ------_=_NextPart_001_01C3C40F.AC0AD350 Content-Type: text/html Message
Chris,
 
Okay so forgive me but how do I specify where to redirect user traffic in diameter.  Which attributes do that.  Note I am not talking about where to redirect AAA traffic.
 
Avi
-----Original Message-----
From: Christopher Richards [mailto:crich@nortelnetworks.com]
Sent: Tuesday, December 16, 2003 2:32 PM
To: 'Avi Lior'; 'radiusext@ops.ietf.org'; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Question regarding IP Filter Rule

Hi Avi,

The Diameter RFC (And applications) specify where to redirect user traffic - not how. The "how" is implementation specific.

Best Regards,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281


-----Original Message-----
From: Avi Lior [mailto:avi@bridgewatersystems.com]
Sent: Tuesday, December 16, 2003 1:23 PM
To: 'radiusext@ops.ietf.org'; aaa-wg@merit.edu
Subject: [AAA-WG]: Question regarding IP Filter Rule


The Black I-D and PWLAN draft prompted me to check something out.

It seems to me that something is missing in Diameter.  Using the filter specification in 3588 its not clear how I force a forward.  The only actions supported are permit or deny whereas ipfw supports a forward mechanism as well.

The motivation for this is the requirement in (WLAN for example) whereby I want to force all http traffic to a specific portal and deny all other traffic until the portal instructs the NAS otherwise.  This needs to be done either during an Access Accept or mid-session using COA.

------_=_NextPart_001_01C3C40F.AC0AD350-- From owner-aaa-wg@merit.edu Tue Dec 16 16:47:51 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09715 for ; Tue, 16 Dec 2003 16:47:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 188BC91260; Tue, 16 Dec 2003 16:47:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE6589125F; Tue, 16 Dec 2003 16:47:39 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 547DF91260 for ; Tue, 16 Dec 2003 16:47:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3CC6E5DDC5; Tue, 16 Dec 2003 16:47:38 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id D04595DD90 for ; Tue, 16 Dec 2003 16:47:37 -0500 (EST) Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id DEA976A905; Tue, 16 Dec 2003 23:47:36 +0200 (EET) Message-ID: <3FDF7D48.5040707@kolumbus.fi> Date: Tue, 16 Dec 2003 23:46:48 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Cc: "'radiusext@ops.ietf.org'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Question regarding IP Filter Rule References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Avi Lior wrote: > The Black I-D and PWLAN draft prompted me to check something out. > > It seems to me that something is missing in Diameter. Using the filter > specification in 3588 its not clear how I force a forward. The only actions > supported are permit or deny whereas ipfw supports a forward mechanism as > well. > > The motivation for this is the requirement in (WLAN for example) whereby I > want to force all http traffic to a specific portal and deny all other > traffic until the portal instructs the NAS otherwise. This needs to be done > either during an Access Accept or mid-session using COA. Does it have to be http specific? You could set Framed-Route and then do Re-Authz when the routing changes. But Framed-Route is not specific to a protocol or port. --Jari From owner-aaa-wg@merit.edu Wed Dec 17 02:19:55 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14740 for ; Wed, 17 Dec 2003 02:19:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5AD3F9121F; Wed, 17 Dec 2003 02:19:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2AC0C91250; Wed, 17 Dec 2003 02:19:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0623E9121F for ; Wed, 17 Dec 2003 02:19:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id E37C55DDE7; Wed, 17 Dec 2003 02:19:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 3646F5DDE5 for ; Wed, 17 Dec 2003 02:19:34 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBH7JXJ27665 for ; Wed, 17 Dec 2003 09:19:33 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Dec 2003 09:19:32 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 17 Dec 2003 09:19:32 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 17 Dec 2003 09:19:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Question regarding IP Filter Rule Date: Wed, 17 Dec 2003 09:19:31 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B03AB@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Question regarding IP Filter Rule Thread-Index: AcPEChFgVjcjO2RiQRWL8X1PVXHD7QAYe7tQ From: To: Cc: , X-OriginalArrivalTime: 17 Dec 2003 07:19:31.0850 (UTC) FILETIME=[1D98B6A0:01C3C46E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Avi Lior wrote > The Black I-D and PWLAN draft prompted me to check something out. >=20 > It seems to me that something is missing in Diameter. Using=20 > the filter > specification in 3588 its not clear how I force a forward. =20 > The only actions > supported are permit or deny whereas ipfw supports a forward=20 > mechanism as > well. >=20 > The motivation for this is the requirement in (WLAN for=20 > example) whereby I > want to force all http traffic to a specific portal and deny all other > traffic until the portal instructs the NAS otherwise. This=20 > needs to be done > either during an Access Accept or mid-session using COA. How to redirect user traffic (e.g. http) is implementation specific and I think is not a Diameter business. If you want to indicate redirect = traffic to a specific address, in Diameter applications you can define a grouped = AVP to realize the functionality. One example could be the = Final-Unit-Indication in the DCC application. Regards Marco From owner-aaa-wg@merit.edu Wed Dec 17 04:47:55 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01092 for ; Wed, 17 Dec 2003 04:47:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 96AA391250; Wed, 17 Dec 2003 04:47:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6861691265; Wed, 17 Dec 2003 04:47:42 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4810B91250 for ; Wed, 17 Dec 2003 04:47:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 071D45DDD4; Wed, 17 Dec 2003 04:47:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from herculanum.int-evry.fr (herculanum.int-evry.fr [157.159.11.15]) by segue.merit.edu (Postfix) with ESMTP id C6DE55DDB3 for ; Wed, 17 Dec 2003 04:47:40 -0500 (EST) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 6A5A634652; Wed, 17 Dec 2003 10:39:32 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id CC5BF3F43B; Wed, 17 Dec 2003 10:39:32 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003121710384716766 ; Wed, 17 Dec 2003 10:38:47 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 66FED3F43B; Wed, 17 Dec 2003 10:39:32 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1AWY8H-00090Z-TO; Wed, 17 Dec 2003 10:38:17 +0100 Date: Wed, 17 Dec 2003 10:38:17 +0100 From: Julien Bournelle To: Jari Arkko Cc: aaa-wg@merit.edu, Pasi Eronen Subject: Re: [AAA-WG]: diameter-eap some minor comments Message-ID: <20031217093817.GO31689@ipv6-5.int-evry.fr> References: <20031212145930.GK16373@ipv6-5.int-evry.fr> <3FDAD51E.1050300@kolumbus.fi> <20031216113128.GR16373@ipv6-5.int-evry.fr> <3FDEEE2F.5090909@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FDEEE2F.5090909@kolumbus.fi> Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, > >that's right but in Diameter-Mobile-IPv4, the FA (<=> NAS) sends > >requests to its local Diameter Server (AAAF). Here, the NAS can send > >requests to: > >- redirect agent > >- proxy agent > >- to the home server > > > >so it appears that there is a different approach between the two drafts. > > Perhaps -- though from the point of view of protocols, the NAS will > be sending a message to the local diameter entity. Its then up to > that entity whether it responds with a redirect, proxies the request, > or handles it by itself. Do you see an issue here? I guess there's no issue but I try to understand why there are two approach to a problem quite similar. -- julien.bournelle@int-evry.fr From owner-aaa-wg@merit.edu Wed Dec 17 09:01:43 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07842 for ; Wed, 17 Dec 2003 09:01:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 168FD91220; Wed, 17 Dec 2003 09:01:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 33AA191265; Wed, 17 Dec 2003 09:01:30 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 44C3691220 for ; Wed, 17 Dec 2003 09:01:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 244BD5DD96; Wed, 17 Dec 2003 09:01:28 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from info.ucl.ac.be (astrolabe.info.ucl.ac.be [130.104.229.109]) by segue.merit.edu (Postfix) with ESMTP id 7E2CD5DDB0 for ; Wed, 17 Dec 2003 09:01:27 -0500 (EST) Received: from 216-7.adslNet.ucl.ac.be (216-7.adslNet.ucl.ac.be [130.104.216.7]) by info.ucl.ac.be (8.12.10/8.12.8) with ESMTP id hBHE1QD2009028 for ; Wed, 17 Dec 2003 15:01:26 +0100 (MET) Subject: [AAA-WG]: Mobile IPv6 Diameter draft From: Xavier Brouckaert To: aaa-wg@merit.edu Content-Type: text/plain Message-Id: <1071669707.25461.3.camel@Chimay.bugfactory.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 17 Dec 2003 15:01:48 +0100 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, What happened to a draft called draft-le-aaa-diameter-mobileipv6-02.txt (Sep 2002) ? Is the work abandoned ? Or was it converted into another draft ? What is the current state of the MIPv6 application for diameter ? Thank you, Xavier From owner-aaa-wg@merit.edu Wed Dec 17 09:10:00 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08063 for ; Wed, 17 Dec 2003 09:10:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A5C9791265; Wed, 17 Dec 2003 09:09:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D69091267; Wed, 17 Dec 2003 09:09:48 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5525191265 for ; Wed, 17 Dec 2003 09:09:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 405225DE0A; Wed, 17 Dec 2003 09:09:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 867D55DE04 for ; Wed, 17 Dec 2003 09:09:46 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBHE9j625207 for ; Wed, 17 Dec 2003 16:09:45 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Dec 2003 16:09:44 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 17 Dec 2003 16:09:44 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 17 Dec 2003 16:09:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Mobile IPv6 Diameter draft Date: Wed, 17 Dec 2003 16:09:44 +0200 Message-ID: Thread-Topic: [AAA-WG]: Mobile IPv6 Diameter draft Thread-Index: AcPEplT75SNHyKu3TZ238fQPoN56kgAAPRGw From: To: , X-OriginalArrivalTime: 17 Dec 2003 14:09:44.0775 (UTC) FILETIME=[6C0B0570:01C3C4A7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Xavier, > What happened to a draft called > draft-le-aaa-diameter-mobileipv6-02.txt (Sep 2002) ? Is the work > abandoned ? Or was it converted into another draft ? What is the > current state of the MIPv6 application for diameter ? I believe that document has expired. Currently, there is no on-going work for the MIPv6 Diameter Application. The AAA WG is currently=20 trying to complete the MIPv4 application first. thanks, John From owner-aaa-wg@merit.edu Wed Dec 17 09:16:25 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08281 for ; Wed, 17 Dec 2003 09:16:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C5B2E9126A; Wed, 17 Dec 2003 09:16:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83EEA91269; Wed, 17 Dec 2003 09:16:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5CAD291267 for ; Wed, 17 Dec 2003 09:16:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3B6AF5DDE3; Wed, 17 Dec 2003 09:16:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 435745DDA3 for ; Wed, 17 Dec 2003 09:16:09 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBHEFZ602990 for ; Wed, 17 Dec 2003 16:16:01 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 17 Dec 2003 16:15:34 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 17 Dec 2003 16:15:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Updated Diameter Credit Control Application submitted Date: Wed, 17 Dec 2003 16:15:35 +0200 Message-ID: Thread-Topic: [AAA-WG]: Mobile IPv6 Diameter draft Thread-Index: AcPEplT75SNHyKu3TZ238fQPoN56kgAAPRGwAAAh8jA= From: To: X-OriginalArrivalTime: 17 Dec 2003 14:15:35.0420 (UTC) FILETIME=[3D0B33C0:01C3C4A8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable The Diameter Credit Control Application has been sent in the Internet = Draft Editor. It should be announced shortly. For those who are interested in = obtaining a copy before it is announced, a copy can be found here: http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-cc-02.txt' Once it is announced, we plan on issuing a Working Group Last Call on the document. thanks, John From owner-aaa-wg@merit.edu Wed Dec 17 09:26:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08596 for ; Wed, 17 Dec 2003 09:26:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 996E191267; Wed, 17 Dec 2003 09:26:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6306991268; Wed, 17 Dec 2003 09:26:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6740191267 for ; Wed, 17 Dec 2003 09:25:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4795B5DDE5; Wed, 17 Dec 2003 09:25:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 9B63C5DDD0 for ; Wed, 17 Dec 2003 09:25:58 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hBHEhSo29237; Wed, 17 Dec 2003 06:43:28 -0800 Date: Wed, 17 Dec 2003 06:43:28 -0800 (PST) From: Bernard Aboba To: Xavier Brouckaert Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Mobile IPv6 Diameter draft In-Reply-To: <1071669707.25461.3.camel@Chimay.bugfactory.org> Message-ID: References: <1071669707.25461.3.camel@Chimay.bugfactory.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The AAA WG only takes on work items on the basis of requests from other WGs or SDOs. This typically occurs after a AAA requirements specification has been issued by the other WG or SDO. In this particular case, the draft below was never taken up as a WG work item by the MIPv6 WG, and no request for work on this subject was issued by MIPv6 WG. So in terms of IETF status, I am not aware of any plans to advance this draft. On Wed, 17 Dec 2003, Xavier Brouckaert wrote: > Hi, > > What happened to a draft called > draft-le-aaa-diameter-mobileipv6-02.txt (Sep 2002) ? Is the work > abandoned ? Or was it converted into another draft ? What is the > current state of the MIPv6 application for diameter ? > > Thank you, > Xavier > From owner-aaa-wg@merit.edu Wed Dec 17 10:05:50 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10960 for ; Wed, 17 Dec 2003 10:05:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 69DA291268; Wed, 17 Dec 2003 10:05:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3580E91269; Wed, 17 Dec 2003 10:05:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 276BF91268 for ; Wed, 17 Dec 2003 10:05:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0BE675DDB0; Wed, 17 Dec 2003 10:05:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 9B1475DD96 for ; Wed, 17 Dec 2003 10:05:31 -0500 (EST) Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 27EAA6A905; Wed, 17 Dec 2003 17:05:25 +0200 (EET) Message-ID: <3FE07083.9040201@kolumbus.fi> Date: Wed, 17 Dec 2003 17:04:35 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Xavier Brouckaert , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Mobile IPv6 Diameter draft References: <1071669707.25461.3.camel@Chimay.bugfactory.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Note also that Mobile IPv6 is not in such a big need for AAA support as is Mobile IPv4, given that access and mobility functions have been separated ;-) AAA support for Mobile IPv6 has been discussed, though. It might offer some benefits, such as reducing the need for setting up a separate security assocation with the home agent. --Jari Bernard Aboba wrote: > The AAA WG only takes on work items on the basis of requests from other > WGs or SDOs. This typically occurs after a AAA requirements specification > has been issued by the other WG or SDO. > > In this particular case, the draft below was never taken up as a WG work > item by the MIPv6 WG, and no request for work on this subject was issued > by MIPv6 WG. > > So in terms of IETF status, I am not aware of any plans to advance this > draft. > > On Wed, 17 Dec 2003, Xavier Brouckaert wrote: > > >>Hi, >> >>What happened to a draft called >>draft-le-aaa-diameter-mobileipv6-02.txt (Sep 2002) ? Is the work >>abandoned ? Or was it converted into another draft ? What is the >>current state of the MIPv6 application for diameter ? >> >>Thank you, >>Xavier >> > > From owner-aaa-wg@merit.edu Wed Dec 17 10:38:20 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14708 for ; Wed, 17 Dec 2003 10:38:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EE80A91269; Wed, 17 Dec 2003 10:38:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B618D9126B; Wed, 17 Dec 2003 10:38:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9BD5691269 for ; Wed, 17 Dec 2003 10:38:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B6E55DE01; Wed, 17 Dec 2003 10:38:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from herculanum.int-evry.fr (herculanum.int-evry.fr [157.159.11.15]) by segue.merit.edu (Postfix) with ESMTP id 580125DDE6 for ; Wed, 17 Dec 2003 10:38:06 -0500 (EST) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 105E834642; Wed, 17 Dec 2003 16:27:33 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id EE3EF3F433; Wed, 17 Dec 2003 16:27:32 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003121716264630213 ; Wed, 17 Dec 2003 16:26:46 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 52E2A3F433; Wed, 17 Dec 2003 16:27:32 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1AWdZ3-0009Ok-HB; Wed, 17 Dec 2003 16:26:17 +0100 Date: Wed, 17 Dec 2003 16:26:17 +0100 From: Julien Bournelle To: Jari Arkko Cc: Bernard Aboba , Xavier Brouckaert , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Mobile IPv6 Diameter draft Message-ID: <20031217152617.GH31689@ipv6-5.int-evry.fr> References: <1071669707.25461.3.camel@Chimay.bugfactory.org> <3FE07083.9040201@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FE07083.9040201@kolumbus.fi> Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, On Wed, Dec 17, 2003 at 05:04:35PM +0200, Jari Arkko wrote: > > Note also that Mobile IPv6 is not in such a big > need for AAA support as is Mobile IPv4, given that > access and mobility functions have been separated ;-) > > AAA support for Mobile IPv6 has been discussed, though. > It might offer some benefits, such as reducing the > need for setting up a separate security assocation > with the home agent. that's right, it could avoid a lot of IKE signalling. However, it implies that the access protocol can collect this mip6 information from the Mobile Node and AFAIK it does not exist such an authentication method or protocol. A possible solution could be to define an extension for EAP methods. In this case, I'm not sure that a specific extension is still necessary. -- julien.bournelle@int-evry.fr From owner-aaa-wg@merit.edu Wed Dec 17 11:49:44 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19650 for ; Wed, 17 Dec 2003 11:49:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5AADF9126B; Wed, 17 Dec 2003 11:49:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 285E89126C; Wed, 17 Dec 2003 11:49:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E5D349126B for ; Wed, 17 Dec 2003 11:49:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id CBAC85DDE6; Wed, 17 Dec 2003 11:49:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 69C9F5DDA1 for ; Wed, 17 Dec 2003 11:49:29 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Dec 2003 11:49:29 -0500 Message-ID: From: Avi Lior To: "'marco.stura@nokia.com'" , Avi Lior Cc: radiusext@ops.ietf.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question regarding IP Filter Rule Date: Wed, 17 Dec 2003 11:49:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Thanx Marco, I am familiar with DCC. My point was/is that IPFilterRules would have been one way to do this and the IPFW appears to support this capability. Its too bad that IPFilterRules don't support this capability because now we have to build it into our applications. For RADIUS prepaid and PWLAN etc we will have to define a new AVP to do redirects. Alternatively, we could define an IPFilterRule attribute that has the forwarding capability that went missing in Diameter. But now we would have a compatibility issue with Diameter. > -----Original Message----- > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] > Sent: Wednesday, December 17, 2003 2:20 AM > To: avi@bridgewatersystems.com > Cc: radiusext@ops.ietf.org; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Question regarding IP Filter Rule > > > Avi Lior wrote > > > The Black I-D and PWLAN draft prompted me to check something out. > > > > It seems to me that something is missing in Diameter. Using > > the filter > > specification in 3588 its not clear how I force a forward. > > The only actions > > supported are permit or deny whereas ipfw supports a forward > > mechanism as > > well. > > > > The motivation for this is the requirement in (WLAN for > > example) whereby I > > want to force all http traffic to a specific portal and > deny all other > > traffic until the portal instructs the NAS otherwise. This > > needs to be done > > either during an Access Accept or mid-session using COA. > > How to redirect user traffic (e.g. http) is implementation > specific and I think is not a Diameter business. If you want > to indicate redirect traffic to a specific address, in > Diameter applications you can define a grouped AVP to realize > the functionality. One example could be the > Final-Unit-Indication in the DCC application. > > Regards > Marco > From owner-aaa-wg@merit.edu Wed Dec 17 11:58:20 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20221 for ; Wed, 17 Dec 2003 11:58:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 19B6B9126C; Wed, 17 Dec 2003 11:58:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DDA209126F; Wed, 17 Dec 2003 11:58:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B31379126C for ; Wed, 17 Dec 2003 11:58:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 97BE35DE2F; Wed, 17 Dec 2003 11:58:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 498395DE1F for ; Wed, 17 Dec 2003 11:58:06 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Dec 2003 11:58:06 -0500 Message-ID: From: Avi Lior To: "'marco.stura@nokia.com'" , Avi Lior Cc: radiusext@ops.ietf.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question regarding IP Filter Rule Date: Wed, 17 Dec 2003 11:58:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Scratch that. I was mistaken. IPFW does not support redirects. You have to invent a new attribute or use Framed-IP-Route to do redirects. > -----Original Message----- > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] > Sent: Wednesday, December 17, 2003 2:20 AM > To: avi@bridgewatersystems.com > Cc: radiusext@ops.ietf.org; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Question regarding IP Filter Rule > > > Avi Lior wrote > > > The Black I-D and PWLAN draft prompted me to check something out. > > > > It seems to me that something is missing in Diameter. Using > > the filter > > specification in 3588 its not clear how I force a forward. > > The only actions > > supported are permit or deny whereas ipfw supports a forward > > mechanism as > > well. > > > > The motivation for this is the requirement in (WLAN for > > example) whereby I > > want to force all http traffic to a specific portal and > deny all other > > traffic until the portal instructs the NAS otherwise. This > > needs to be done > > either during an Access Accept or mid-session using COA. > > How to redirect user traffic (e.g. http) is implementation > specific and I think is not a Diameter business. If you want > to indicate redirect traffic to a specific address, in > Diameter applications you can define a grouped AVP to realize > the functionality. One example could be the > Final-Unit-Indication in the DCC application. > > Regards > Marco > From owner-aaa-wg@merit.edu Wed Dec 17 12:01:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20416 for ; Wed, 17 Dec 2003 12:01:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 178E29126F; Wed, 17 Dec 2003 12:00:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD78191270; Wed, 17 Dec 2003 12:00:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A0AAD9126F for ; Wed, 17 Dec 2003 12:00:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 875745DDC1; Wed, 17 Dec 2003 12:00:50 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 2EBD25DDB3 for ; Wed, 17 Dec 2003 12:00:50 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Dec 2003 12:00:50 -0500 Message-ID: From: Avi Lior To: "'Jari Arkko'" , Avi Lior Cc: "'radiusext@ops.ietf.org'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question regarding IP Filter Rule Date: Wed, 17 Dec 2003 12:00:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Jari, You could use Framed-Route but now all traffic would be routed to the Portal etc..... I think it would be more appropriate to introduce a new attribute so that: A) the NAS would deal with the routing functions (as it always does) and the Portal does not have to do it. B) We would have the flexibility to decide whether to route all traffic or just some traffic. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Tuesday, December 16, 2003 4:47 PM > To: Avi Lior > Cc: 'radiusext@ops.ietf.org'; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Question regarding IP Filter Rule > > > Avi Lior wrote: > > The Black I-D and PWLAN draft prompted me to check something out. > > > > It seems to me that something is missing in Diameter. Using the > > filter specification in 3588 its not clear how I force a > forward. The > > only actions supported are permit or deny whereas ipfw supports a > > forward mechanism as well. > > > > The motivation for this is the requirement in (WLAN for example) > > whereby I want to force all http traffic to a specific > portal and deny > > all other traffic until the portal instructs the NAS > otherwise. This > > needs to be done either during an Access Accept or > mid-session using > > COA. > > Does it have to be http specific? You could set Framed-Route > and then do Re-Authz when the routing changes. But > Framed-Route is not specific to a protocol or port. > > --Jari > From owner-aaa-wg@merit.edu Wed Dec 17 12:03:44 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20543 for ; Wed, 17 Dec 2003 12:03:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 071F291271; Wed, 17 Dec 2003 12:03:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CAF2A91270; Wed, 17 Dec 2003 12:03:28 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8619091271 for ; Wed, 17 Dec 2003 12:03:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 39ACF5DDA3; Wed, 17 Dec 2003 12:03:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 39DB35DDA1 for ; Wed, 17 Dec 2003 12:03:25 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBHH3N629021 for ; Wed, 17 Dec 2003 19:03:23 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Dec 2003 19:03:22 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 17 Dec 2003 19:03:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Question regarding IP Filter Rule Date: Wed, 17 Dec 2003 19:03:22 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C825D@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Question regarding IP Filter Rule Thread-Index: AcPEvvHr8EFqvkOKTnmvX3gyKlkbQgAAGCAQ From: To: Cc: , X-OriginalArrivalTime: 17 Dec 2003 17:03:22.0711 (UTC) FILETIME=[AD9DE670:01C3C4BF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > You have to invent a new attribute or use Framed-IP-Route to=20 > do redirects. Are you talking about RADIUS attribute?=20 > -----Original Message----- > From: ext Avi Lior [mailto:avi@bridgewatersystems.com] > Sent: 17 December, 2003 18:58 > To: Stura Marco (NET/Helsinki); Avi Lior > Cc: radiusext@ops.ietf.org; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Question regarding IP Filter Rule >=20 >=20 > Scratch that. I was mistaken. IPFW does not support redirects. >=20 > You have to invent a new attribute or use Framed-IP-Route to=20 > do redirects. >=20 > > -----Original Message----- > > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 > > Sent: Wednesday, December 17, 2003 2:20 AM > > To: avi@bridgewatersystems.com > > Cc: radiusext@ops.ietf.org; aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: Question regarding IP Filter Rule > >=20 > >=20 > > Avi Lior wrote > >=20 > > > The Black I-D and PWLAN draft prompted me to check something out. > > >=20 > > > It seems to me that something is missing in Diameter. Using > > > the filter > > > specification in 3588 its not clear how I force a forward. =20 > > > The only actions > > > supported are permit or deny whereas ipfw supports a forward=20 > > > mechanism as > > > well. > > >=20 > > > The motivation for this is the requirement in (WLAN for > > > example) whereby I > > > want to force all http traffic to a specific portal and=20 > > deny all other > > > traffic until the portal instructs the NAS otherwise. This=20 > > > needs to be done > > > either during an Access Accept or mid-session using COA. > >=20 > > How to redirect user traffic (e.g. http) is implementation=20 > > specific and I think is not a Diameter business. If you want=20 > > to indicate redirect traffic to a specific address, in=20 > > Diameter applications you can define a grouped AVP to realize=20 > > the functionality. One example could be the=20 > > Final-Unit-Indication in the DCC application. > >=20 > > Regards > > Marco > >=20 >=20 From owner-aaa-wg@merit.edu Wed Dec 17 13:44:14 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25668 for ; Wed, 17 Dec 2003 13:44:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 640ED91279; Wed, 17 Dec 2003 13:43:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2DADC9127B; Wed, 17 Dec 2003 13:43:56 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E304E91279 for ; Wed, 17 Dec 2003 13:43:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id D1F625DE11; Wed, 17 Dec 2003 13:43:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 7410A5DD96 for ; Wed, 17 Dec 2003 13:43:54 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Dec 2003 13:43:54 -0500 Message-ID: From: Avi Lior To: "'marco.stura@nokia.com'" , Avi Lior Cc: radiusext@ops.ietf.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question regarding IP Filter Rule Date: Wed, 17 Dec 2003 13:43:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Yes. But you also need the same in Diameter (I think? Well DCC did right?) > -----Original Message----- > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] > Sent: Wednesday, December 17, 2003 12:03 PM > To: avi@bridgewatersystems.com > Cc: radiusext@ops.ietf.org; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Question regarding IP Filter Rule > > > > You have to invent a new attribute or use Framed-IP-Route to > > do redirects. > > Are you talking about RADIUS attribute? > > > -----Original Message----- > > From: ext Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: 17 December, 2003 18:58 > > To: Stura Marco (NET/Helsinki); Avi Lior > > Cc: radiusext@ops.ietf.org; aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: Question regarding IP Filter Rule > > > > > > Scratch that. I was mistaken. IPFW does not support redirects. > > > > You have to invent a new attribute or use Framed-IP-Route to > > do redirects. > > > > > -----Original Message----- > > > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] > > > Sent: Wednesday, December 17, 2003 2:20 AM > > > To: avi@bridgewatersystems.com > > > Cc: radiusext@ops.ietf.org; aaa-wg@merit.edu > > > Subject: RE: [AAA-WG]: Question regarding IP Filter Rule > > > > > > > > > Avi Lior wrote > > > > > > > The Black I-D and PWLAN draft prompted me to check > something out. > > > > > > > > It seems to me that something is missing in Diameter. > Using the > > > > filter specification in 3588 its not clear how I force > a forward. > > > > The only actions > > > > supported are permit or deny whereas ipfw supports a forward > > > > mechanism as > > > > well. > > > > > > > > The motivation for this is the requirement in (WLAN for > > > > example) whereby I > > > > want to force all http traffic to a specific portal and > > > deny all other > > > > traffic until the portal instructs the NAS otherwise. This > > > > needs to be done > > > > either during an Access Accept or mid-session using COA. > > > > > > How to redirect user traffic (e.g. http) is implementation > > > specific and I think is not a Diameter business. If you want > > > to indicate redirect traffic to a specific address, in > > > Diameter applications you can define a grouped AVP to realize > > > the functionality. One example could be the > > > Final-Unit-Indication in the DCC application. > > > > > > Regards > > > Marco > > > > > > From owner-aaa-wg@merit.edu Wed Dec 17 16:54:33 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07637 for ; Wed, 17 Dec 2003 16:54:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0FD7D9127E; Wed, 17 Dec 2003 16:54:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CFA4991287; Wed, 17 Dec 2003 16:54:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5E1779127E for ; Wed, 17 Dec 2003 16:54:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A64A5DE32; Wed, 17 Dec 2003 16:54:18 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id EE8205DD98 for ; Wed, 17 Dec 2003 16:54:17 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBHLsBX11339 for ; Wed, 17 Dec 2003 15:54:11 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Dec 2003 15:54:11 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8CDD@zrc2c012.us.nortel.com> From: "Christopher Richards" To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC: redirection information per G-S-U Date: Wed, 17 Dec 2003 15:54:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C4E8.4C9EA32C" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3C4E8.4C9EA32C Content-Type: text/plain Hi All, Not sure if this has been covered previously. Here goes: Given that a session may hold multiple G-S-U quotas, and these quotas are used for very different services, it seems to make sense that each G-S-U can optionally contain a Redirect-Server AVP. If a user has a quota for traffic to a game server and another for general web access, it seems reasonable that when the game server quota expires, that flow is redirected, while still allowing the general web access flows to continue until their quota is exhausted. This also implies that when one quota is exhausted, not all user service should be blocked or redirected (I think this point has been mentioned before). This could either be accomplished by adding the Final-Unit-Indication AVP or Redirect-Server AVP to the G-S-U AVP as an optional AVP. Since the redirection may be temporary, the Final-Unit-Indication AVP does not seem to fit best. I propose changing the G-S-U AVP from: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] To: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] [ Redirect-Server ] Best Regards, Chris. ------_=_NextPart_001_01C3C4E8.4C9EA32C Content-Type: text/html Content-Transfer-Encoding: quoted-printable [AAA-WG]: DCC: redirection information per G-S-U

Hi All,

Not sure if this has been covered previously. Here = goes:

Given that a session may hold multiple G-S-U quotas, = and these quotas are used for very different services, it seems to make = sense that each G-S-U can optionally contain a Redirect-Server = AVP.

If a user has a quota for traffic to a game server = and another for general web access, it seems reasonable that when the = game server quota expires, that flow is redirected, while still = allowing the general web access flows to continue until their quota is = exhausted. This also implies that when one quota is exhausted, not all = user service should be blocked or redirected (I think this point has = been mentioned before).

This could either be accomplished by adding the = Final-Unit-Indication AVP or Redirect-Server AVP to the G-S-U AVP as an = optional AVP. Since the redirection may be temporary, the = Final-Unit-Indication AVP does not seem to fit best.

I propose changing the G-S-U AVP from:

         = Granted-Service-Unit ::=3D < AVP Header: 431 >
          &nb= sp;           &nb= sp;           [ = Tariff-Time-Change ]  
          &nb= sp;           &nb= sp;           [ = CC-Time ]
          &nb= sp;           &nb= sp;           [ = CC-Money ]  
          &nb= sp;           &nb= sp;           [ = CC-Total-Octets ]
          &nb= sp;           &nb= sp;           [ = CC-Input-Octets ]
          &nb= sp;           &nb= sp;           [ = CC-Output-Octets ]
          &nb= sp;           &nb= sp;           [ = CC-Service-Specific-Units ]
          &nb= sp;           &nb= sp;          *[ = Service-Identifier ]
          &nb= sp;           &nb= sp;           [ = Rating-Group ]

To:

         = Granted-Service-Unit ::=3D < AVP Header: 431 >
          &nb= sp;           &nb= sp;           [ = Tariff-Time-Change ]  
          &nb= sp;           &nb= sp;           [ = CC-Time ]
          &nb= sp;           &nb= sp;           [ = CC-Money ]  
          &nb= sp;           &nb= sp;           [ = CC-Total-Octets ]
          &nb= sp;           &nb= sp;           [ = CC-Input-Octets ]
          &nb= sp;           &nb= sp;           [ = CC-Output-Octets ]
          &nb= sp;           &nb= sp;           [ = CC-Service-Specific-Units ]
          &nb= sp;           &nb= sp;          *[ = Service-Identifier ]
          &nb= sp;           &nb= sp;           [ = Rating-Group ]
          &nb= sp;           &nb= sp;           [ = Redirect-Server ]


Best Regards,
Chris.

------_=_NextPart_001_01C3C4E8.4C9EA32C-- From owner-aaa-wg@merit.edu Wed Dec 17 17:32:00 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09575 for ; Wed, 17 Dec 2003 17:32:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D5E0691287; Wed, 17 Dec 2003 17:31:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A774991288; Wed, 17 Dec 2003 17:31:48 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9371C91287 for ; Wed, 17 Dec 2003 17:31:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7B8C85DDFB; Wed, 17 Dec 2003 17:31:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by segue.merit.edu (Postfix) with ESMTP id 7D4905DDC2 for ; Wed, 17 Dec 2003 17:31:46 -0500 (EST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hBHMVYW10831; Wed, 17 Dec 2003 14:31:34 -0800 X-mProtect: <200312172231> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdipg5Cc; Wed, 17 Dec 2003 14:31:33 PST Message-ID: <3FE0D93B.AA950808@iprg.nokia.com> Date: Wed, 17 Dec 2003 14:31:23 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: Xavier Brouckaert , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Mobile IPv6 Diameter draft References: <1071669707.25461.3.camel@Chimay.bugfactory.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello Bernard, At one point, I was involved with trying to put together something for Mobile IPv6. We had AAAv6, which was discussed in the AAA working group. Then we were requested to ask the IPv6 working group whether AAAv6 should be taken up in the AAA working group. We did that. Then when the IPv6 working group indicated interest, it turned out that the AAA working group was trying to finish its IPv4 charter items. Eventually, I basically gave up, and I guess other people have moved on also. I still think there is need for: - a good way to do AAAv6 using controls at the access routers (e.g., the "AAAv6" draft for one example) - a good way to improve the performance of initial requests and authorizations at a new access network AAAv6 and the draft from Frank Le solve these problems, and correspond roughly to the AAAv4 solution. Plus, they are known to work. How do you see future AAA solutions co-existing with future PANA solutions? Regards, Charlie P. Bernard Aboba wrote: > > The AAA WG only takes on work items on the basis of requests from other > WGs or SDOs. This typically occurs after a AAA requirements specification > has been issued by the other WG or SDO. > > In this particular case, the draft below was never taken up as a WG work > item by the MIPv6 WG, and no request for work on this subject was issued > by MIPv6 WG. > > So in terms of IETF status, I am not aware of any plans to advance this > draft. > > On Wed, 17 Dec 2003, Xavier Brouckaert wrote: > > > Hi, > > > > What happened to a draft called > > draft-le-aaa-diameter-mobileipv6-02.txt (Sep 2002) ? Is the work > > abandoned ? Or was it converted into another draft ? What is the > > current state of the MIPv6 application for diameter ? > > > > Thank you, > > Xavier > > From owner-aaa-wg@merit.edu Wed Dec 17 17:40:14 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09814 for ; Wed, 17 Dec 2003 17:40:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8558691288; Wed, 17 Dec 2003 17:40:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5AFC591289; Wed, 17 Dec 2003 17:40:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 697EE91288 for ; Wed, 17 Dec 2003 17:40:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 53BB15DE2C; Wed, 17 Dec 2003 17:40:01 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id ABE035DE2A for ; Wed, 17 Dec 2003 17:40:00 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hBHMvMf26283; Wed, 17 Dec 2003 14:57:23 -0800 Date: Wed, 17 Dec 2003 14:57:22 -0800 (PST) From: Bernard Aboba To: "Charles E. Perkins" Cc: Xavier Brouckaert , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Mobile IPv6 Diameter draft In-Reply-To: <3FE0D93B.AA950808@iprg.nokia.com> Message-ID: References: <1071669707.25461.3.camel@Chimay.bugfactory.org> <3FE0D93B.AA950808@iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > when the IPv6 working group indicated interest, it turned > out that the AAA working group was trying to finish > its IPv4 charter items. As I recall, this was during the period where AAA WG was still struggling to complete the Diameter Base Protocol spec. Once that was finished, the WG was rechartered to add work on Diameter Credit Control & SIP applications. So the moratorium on new work was eventually lifted. > How do you see future AAA solutions co-existing with > future PANA solutions? My assumption has been that PANA would be able to use the Diameter EAP application for its AAA needs. If there are issues with this, then it would be good to file issues so that we can address them. From owner-aaa-wg@merit.edu Wed Dec 17 20:26:01 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17123 for ; Wed, 17 Dec 2003 20:26:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7A0D591223; Wed, 17 Dec 2003 20:25:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 43DBC9124A; Wed, 17 Dec 2003 20:25:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2352F91223 for ; Wed, 17 Dec 2003 20:25:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 139735DE44; Wed, 17 Dec 2003 20:25:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by segue.merit.edu (Postfix) with ESMTP id 2E0095DE3E for ; Wed, 17 Dec 2003 20:25:47 -0500 (EST) Date: Wed, 17 Dec 2003 17:26:54 -0800 Subject: Re: [AAA-WG]: Mobile IPv6 Diameter draft From: Alper Yegin To: "Charles E. Perkins" , Bernard Aboba Cc: Xavier Brouckaert , Message-ID: In-Reply-To: <3FE0D93B.AA950808@iprg.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Charlie, > I still think there is need for: > - a good way to do AAAv6 using controls at the access routers > (e.g., the "AAAv6" draft for one example) > - a good way to improve the performance of initial > requests and authorizations at a new access network When I look at your above description and the AAAv6 draft, I see two things. First one is a way to carry authentication above IP. This is already covered by PANA. The other is bundling/integrating/piggybacking AAA for network access with AAA for Mobile IPv6. I guess this deserves an architectural discussion first. I have seen this discussion pop up at different places at various times. Alper From owner-aaa-wg@merit.edu Thu Dec 18 01:49:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25223 for ; Thu, 18 Dec 2003 01:49:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B2FA19128B; Thu, 18 Dec 2003 01:49:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C8719128D; Thu, 18 Dec 2003 01:49:17 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1D52C9128B for ; Thu, 18 Dec 2003 01:49:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0BDB65DDBD; Thu, 18 Dec 2003 01:49:16 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 4E6AC5DDC2 for ; Thu, 18 Dec 2003 01:49:15 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBI6nEI11468 for ; Thu, 18 Dec 2003 08:49:14 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Dec 2003 08:49:14 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 08:49:13 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 08:49:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Question regarding IP Filter Rule Date: Thu, 18 Dec 2003 08:49:12 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C825E@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Question regarding IP Filter Rule Thread-Index: AcPEzbosWEC1jGJQQtaS2mksssKu4AAZL/Yg From: To: Cc: , X-OriginalArrivalTime: 18 Dec 2003 06:49:12.0885 (UTC) FILETIME=[0BD26E50:01C3C533] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > Yes. But you also need the same in Diameter Yes, I think you are right. >Well DCC did right? I think so. This is one way to do it, but there may be also other ways.=20 > -----Original Message----- > From: ext Avi Lior [mailto:avi@bridgewatersystems.com] > Sent: 17 December, 2003 20:44 > To: Stura Marco (NET/Helsinki); Avi Lior > Cc: radiusext@ops.ietf.org; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Question regarding IP Filter Rule >=20 >=20 > Yes. But you also need the same in Diameter (I think? Well=20 > DCC did right?) >=20 > > -----Original Message----- > > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 > > Sent: Wednesday, December 17, 2003 12:03 PM > > To: avi@bridgewatersystems.com > > Cc: radiusext@ops.ietf.org; aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: Question regarding IP Filter Rule > >=20 > >=20 > > > You have to invent a new attribute or use Framed-IP-Route to > > > do redirects. > >=20 > > Are you talking about RADIUS attribute?=20 > >=20 > > > -----Original Message----- > > > From: ext Avi Lior [mailto:avi@bridgewatersystems.com] > > > Sent: 17 December, 2003 18:58 > > > To: Stura Marco (NET/Helsinki); Avi Lior > > > Cc: radiusext@ops.ietf.org; aaa-wg@merit.edu > > > Subject: RE: [AAA-WG]: Question regarding IP Filter Rule > > >=20 > > >=20 > > > Scratch that. I was mistaken. IPFW does not support redirects. > > >=20 > > > You have to invent a new attribute or use Framed-IP-Route to > > > do redirects. > > >=20 > > > > -----Original Message----- > > > > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] > > > > Sent: Wednesday, December 17, 2003 2:20 AM > > > > To: avi@bridgewatersystems.com > > > > Cc: radiusext@ops.ietf.org; aaa-wg@merit.edu > > > > Subject: RE: [AAA-WG]: Question regarding IP Filter Rule > > > >=20 > > > >=20 > > > > Avi Lior wrote > > > >=20 > > > > > The Black I-D and PWLAN draft prompted me to check=20 > > something out. > > > > >=20 > > > > > It seems to me that something is missing in Diameter. =20 > > Using the=20 > > > > > filter specification in 3588 its not clear how I force=20 > > a forward. > > > > > The only actions > > > > > supported are permit or deny whereas ipfw supports a forward=20 > > > > > mechanism as > > > > > well. > > > > >=20 > > > > > The motivation for this is the requirement in (WLAN for > > > > > example) whereby I > > > > > want to force all http traffic to a specific portal and > > > > deny all other > > > > > traffic until the portal instructs the NAS otherwise. This > > > > > needs to be done > > > > > either during an Access Accept or mid-session using COA. > > > >=20 > > > > How to redirect user traffic (e.g. http) is implementation > > > > specific and I think is not a Diameter business. If you want=20 > > > > to indicate redirect traffic to a specific address, in=20 > > > > Diameter applications you can define a grouped AVP to realize=20 > > > > the functionality. One example could be the=20 > > > > Final-Unit-Indication in the DCC application. > > > >=20 > > > > Regards > > > > Marco > > > >=20 > > >=20 > >=20 >=20 From owner-aaa-wg@merit.edu Thu Dec 18 03:24:41 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11048 for ; Thu, 18 Dec 2003 03:24:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 41C5F912A8; Thu, 18 Dec 2003 03:24:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2F82912AE; Thu, 18 Dec 2003 03:24:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8B980912A8 for ; Thu, 18 Dec 2003 03:24:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id A90F75DE01; Thu, 18 Dec 2003 03:24:01 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 40E4B5DDF5 for ; Thu, 18 Dec 2003 03:24:01 -0500 (EST) Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id B31716A907 for ; Thu, 18 Dec 2003 10:24:00 +0200 (EET) Message-ID: <3FE163EF.5000909@kolumbus.fi> Date: Thu, 18 Dec 2003 10:23:11 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Question regarding IP Filter Rule References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Avi Lior wrote: > Hi Jari, > > You could use Framed-Route but now all traffic would be routed to the Portal > etc..... > > I think it would be more appropriate to introduce a new attribute so that: > > A) the NAS would deal with the routing functions (as it always does) and the > Portal does not have to do it. > > B) We would have the flexibility to decide whether to route all traffic or > just some traffic. Perhaps. Are the redirection schemes used for payment? I.e. I need to log in to the web page before I can continue? Or for something else? There is a difference because if its used for payment, redirecting just some protocols may leave a hole to the protocols. For instance, I have sometimes succeeded in doing all my e-mail over SSH even if there was some http-directing thing that prevented all web traffic. --Jari From owner-aaa-wg@merit.edu Thu Dec 18 03:40:24 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11421 for ; Thu, 18 Dec 2003 03:40:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BD5EE91292; Thu, 18 Dec 2003 03:40:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8EF9F91293; Thu, 18 Dec 2003 03:40:09 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8D36F91292 for ; Thu, 18 Dec 2003 03:40:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 69C4A5DE34; Thu, 18 Dec 2003 03:40:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 329DB5DE23 for ; Thu, 18 Dec 2003 03:40:08 -0500 (EST) Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 73B086A907; Thu, 18 Dec 2003 10:40:07 +0200 (EET) Message-ID: <3FE167B5.1050803@kolumbus.fi> Date: Thu, 18 Dec 2003 10:39:17 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Cc: "'marco.stura@nokia.com'" , radiusext@ops.ietf.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Question regarding IP Filter Rule References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Avi Lior wrote: > Yes. But you also need the same in Diameter (I think? Well DCC did right?) But can it be used without at the same time using the rest of DCC? Anyway, whatever we do I hope the RADIUS and Diameter schemes are compatible. --Jari From owner-aaa-wg@merit.edu Thu Dec 18 04:38:24 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12837 for ; Thu, 18 Dec 2003 04:38:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4CBFF91295; Thu, 18 Dec 2003 04:38:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1435D91296; Thu, 18 Dec 2003 04:38:08 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 92E1A91295 for ; Thu, 18 Dec 2003 04:38:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 74F575DE47; Thu, 18 Dec 2003 04:38:07 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id B343F5DE1F for ; Thu, 18 Dec 2003 04:38:06 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBI9c5t27375 for ; Thu, 18 Dec 2003 11:38:05 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Dec 2003 11:38:05 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 11:38:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C54A.A202238C" Subject: RE: [AAA-WG]: DCC: redirection information per G-S-U Date: Thu, 18 Dec 2003 11:38:03 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C8264@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC: redirection information per G-S-U Thread-Index: AcPE6GCpgdhHXK9zS6OBD17DJwqK3gASb+Mw From: To: Cc: X-OriginalArrivalTime: 18 Dec 2003 09:38:03.0747 (UTC) FILETIME=[A2494B30:01C3C54A] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3C54A.A202238C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chris, =20 >Given that a session may hold multiple G-S-U quotas, and these quotas = are used for very different services, it seems to make sense >that each = G-S-U can optionally contain a Redirect-Server AVP. =20 Yes, in certain circumstances it may make sense.=20 =20 >If a user has a quota for traffic to a game server and another for = general web access, it seems reasonable that when the game server >quota = expires, that flow is redirected, while still allowing the general web = access flows to continue until their quota is exhausted. This >also = implies that when one quota is exhausted, not all user service should be = blocked or redirected (I think this point has been >mentioned before). =20 Perhaps we are back to the quota allocation strategy discussion, if look = carefully to the Flow X you can see that there is one credit reservation = for all the services in the user's session and and the client trigger = the interim interrogation only when the whole credit reservation has = been consumed. This is an extremely simple and efficient approach to = achieve differentiated credit control for each of the services in a = user's session. I think we need to clarify this point in section 5. =20 However, it is true that we may have some case where the server = determines that some service shall be denied and conveys a value of zero granted unit associated to that service. In such a case = it may be good to offer the option of redirecting the traffic to some place that e.g. inform the user why the service has been = denied (e.g. low credit or what so ever). So, I think your proposal make = sense in this scenario. =20 Since we published the draf 02 and we just wait that it is announced to = issue a WGLC on the document, I would suggest we wait this event and then work out the official issue/solution in the = context of the WGLC. Are you fine with this approach? =20 Cheers Marco ------_=_NextPart_001_01C3C54A.A202238C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [AAA-WG]: DCC: redirection information per G-S-U
Hi=20 Chris,
 
>Given that a = session may=20 hold multiple G-S-U quotas, and these quotas are used for very different = services, it seems to make sense >that each G-S-U can optionally = contain a=20 Redirect-Server AVP.
 
Yes, in certain circumstances it may make = sense.=20
 
>If a user has a quota for traffic to a = game server=20 and another for general web access, it seems reasonable that when the = game=20 server >quota expires, that flow is redirected, while still allowing = the=20 general web access flows to continue until their quota is exhausted. = This=20 >also implies that when one quota is exhausted, not all user service = should=20 be blocked or redirected (I think this point has been >mentioned=20 before).
 
Perhaps we are back to the quota = allocation=20 strategy discussion, if look carefully to the Flow X you can see that = there is=20 one credit reservation for all the services in the user's session and = and the=20 client trigger the = interim=20 interrogation only when the whole credit reservation has been=20 consumed. This is an extremely simple and efficient approach = to=20 achieve differentiated credit control for each of the services in a = user's=20 session. I think we need to clarify this point in section=20 5.
 
However, it is true that we may have some = case where=20 the server determines that some service shall be denied and=20 conveys
a value of zero granted unit associated to = that=20 service. In such a case it may be good to offer the option of = redirecting=20 the
traffic to some place that e.g. inform the = user why the=20 service has been denied (e.g. low credit or what so ever). So, I think = your=20 proposal make sense in this = scenario.
 
Since we published the draf  02 and we = just wait=20 that it is announced to issue a WGLC on the document, I would=20 suggest
we wait this event and then work out the = official=20 issue/solution in the context of the WGLC. Are you fine with this=20 approach?
 
Cheers
Marco
= ------_=_NextPart_001_01C3C54A.A202238C-- From owner-aaa-wg@merit.edu Thu Dec 18 06:02:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15227 for ; Thu, 18 Dec 2003 06:02:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3318791299; Thu, 18 Dec 2003 06:02:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2C139129A; Thu, 18 Dec 2003 06:02:17 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D491A91299 for ; Thu, 18 Dec 2003 06:02:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id C38115DDC8; Thu, 18 Dec 2003 06:02:16 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from herculanum.int-evry.fr (herculanum.int-evry.fr [157.159.11.15]) by segue.merit.edu (Postfix) with ESMTP id 8E75F5DDC1 for ; Thu, 18 Dec 2003 06:02:16 -0500 (EST) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id AE8BD34B3B; Thu, 18 Dec 2003 12:00:49 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 944543F430; Thu, 18 Dec 2003 12:00:49 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003121812000112262 ; Thu, 18 Dec 2003 12:00:01 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id F074E3F430; Thu, 18 Dec 2003 12:00:48 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1AWvsT-000ACw-5I; Thu, 18 Dec 2003 11:59:33 +0100 Date: Thu, 18 Dec 2003 11:59:33 +0100 From: Julien Bournelle To: Alper Yegin Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Mobile IPv6 Diameter draft Message-ID: <20031218105933.GA39152@ipv6-5.int-evry.fr> References: <3FE0D93B.AA950808@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, On Wed, Dec 17, 2003 at 05:26:54PM -0800, Alper Yegin wrote: > > I still think there is need for: > > - a good way to do AAAv6 using controls at the access routers > > (e.g., the "AAAv6" draft for one example) > > - a good way to improve the performance of initial > > requests and authorizations at a new access network > > When I look at your above description and the AAAv6 draft, I see two things. > First one is a way to carry authentication above IP. This is already covered > by PANA. PANA carry authentication above IP/UDP via EAP but it does not exist any authentication method that permit to obtain MIPv6 information (such as Home Agent Address, Home Address...). So either we define a new authentication method for this purpose, or we define a way to recover this mip6 information from existing authentication method (eap extension ?). -- julien.bournelle@int-evry.fr From owner-aaa-wg@merit.edu Thu Dec 18 06:38:56 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15927 for ; Thu, 18 Dec 2003 06:38:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EC1F99129A; Thu, 18 Dec 2003 06:38:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9AB79129B; Thu, 18 Dec 2003 06:38:40 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 935CD9129A for ; Thu, 18 Dec 2003 06:38:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7A3255DE23; Thu, 18 Dec 2003 06:38:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp.um.es (xenon2.um.es [155.54.212.101]) by segue.merit.edu (Postfix) with ESMTP id 053AE5DE11 for ; Thu, 18 Dec 2003 06:38:39 -0500 (EST) Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 7FBAF3491D; Thu, 18 Dec 2003 12:38:37 +0100 (CET) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with ESMTP id 616AC348D2; Thu, 18 Dec 2003 12:38:37 +0100 (CET) Received: from dif.um.es (bravecard.dif.um.es [155.54.210.47]) by aries.dif.um.es (Postfix) with ESMTP id 7B0DB14431; Thu, 18 Dec 2003 12:25:36 +0100 (MET) Message-ID: <3FE1919D.2020507@dif.um.es> Date: Thu, 18 Dec 2003 12:38:05 +0100 From: =?ISO-8859-1?Q?Rafa_Mar=EDn_L=F3pez?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031024 Debian/1.5-2 X-Accept-Language: en MIME-Version: 1.0 To: Julien Bournelle Cc: Alper Yegin , aaa-wg@merit.edu, rafa@dif.um.es Subject: Re: [AAA-WG]: Mobile IPv6 Diameter draft References: <3FE0D93B.AA950808@iprg.nokia.com> <20031218105933.GA39152@ipv6-5.int-evry.fr> In-Reply-To: <20031218105933.GA39152@ipv6-5.int-evry.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hello all... I agree with you, it would be really interesting to define a hook between PANA and Mobile IPv6 . Fo example I have doubts about how to carry cryptographic keys derived from PANA process to Mobile IPv6 or get information as you comment. I am really interested in this issue(as many people I suppose :) ), but I am not sure if this is the best "place" to discuss about it though obviously DIAMETER + PANA + Mobile IPv6 integration is really interesting. I have a question... is there any mailing list where could we discuss about it? PANA mailing list maybe? in this mailing list? ... ¿? Regards. Julien Bournelle wrote: >Hi, > >On Wed, Dec 17, 2003 at 05:26:54PM -0800, Alper Yegin wrote: > > >>>I still think there is need for: >>>- a good way to do AAAv6 using controls at the access routers >>>(e.g., the "AAAv6" draft for one example) >>>- a good way to improve the performance of initial >>>requests and authorizations at a new access network >>> >>> >>When I look at your above description and the AAAv6 draft, I see two things. >>First one is a way to carry authentication above IP. This is already covered >>by PANA. >> >> > >PANA carry authentication above IP/UDP via EAP but it does not exist any >authentication method that permit to obtain MIPv6 information (such as >Home Agent Address, Home Address...). So either we define a new >authentication method for this purpose, or we define a way to recover >this mip6 information from existing authentication method (eap extension >?). > > > -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ From owner-aaa-wg@merit.edu Thu Dec 18 12:54:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05666 for ; Thu, 18 Dec 2003 12:54:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A743E912A7; Thu, 18 Dec 2003 12:54:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 74C95912AB; Thu, 18 Dec 2003 12:54:08 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0366E912A7 for ; Thu, 18 Dec 2003 12:54:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id E55B25DDD3; Thu, 18 Dec 2003 12:54:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id 87BD15DD8D for ; Thu, 18 Dec 2003 12:54:06 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBIHrvT26728; Thu, 18 Dec 2003 09:53:57 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Dec 2003 11:53:56 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8CF5@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'marco.stura@nokia.com'" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: redirection information per G-S-U Date: Thu, 18 Dec 2003 11:53:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C58F.80776C72" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3C58F.80776C72 Content-Type: text/plain Thanks for the positive response. I can assume then that these changes will be accepted. I am a little concerned that the draft is going to WGLC so soon. It seems a bit premature. There are still a few outstanding issues that I think should be addressed before it goes to WGLC status - some of these issues will probably need some discussion. Best Regards, Chris. -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Thursday, December 18, 2003 3:38 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: redirection information per G-S-U Hi Chris, >Given that a session may hold multiple G-S-U quotas, and these quotas are used for very different services, it seems to make sense >that each G-S-U can optionally contain a Redirect-Server AVP. Yes, in certain circumstances it may make sense. >If a user has a quota for traffic to a game server and another for general web access, it seems reasonable that when the game server >quota expires, that flow is redirected, while still allowing the general web access flows to continue until their quota is exhausted. This >also implies that when one quota is exhausted, not all user service should be blocked or redirected (I think this point has been >mentioned before). Perhaps we are back to the quota allocation strategy discussion, if look carefully to the Flow X you can see that there is one credit reservation for all the services in the user's session and and the client trigger the interim interrogation only when the whole credit reservation has been consumed. This is an extremely simple and efficient approach to achieve differentiated credit control for each of the services in a user's session. I think we need to clarify this point in section 5. However, it is true that we may have some case where the server determines that some service shall be denied and conveys a value of zero granted unit associated to that service. In such a case it may be good to offer the option of redirecting the traffic to some place that e.g. inform the user why the service has been denied (e.g. low credit or what so ever). So, I think your proposal make sense in this scenario. Since we published the draf 02 and we just wait that it is announced to issue a WGLC on the document, I would suggest we wait this event and then work out the official issue/solution in the context of the WGLC. Are you fine with this approach? Cheers Marco ------_=_NextPart_001_01C3C58F.80776C72 Content-Type: text/html Message
Thanks for the positive response. I can assume then that these changes will be accepted.
 
I am a little concerned that the draft is going to WGLC so soon. It seems a bit premature. There are still a few outstanding issues that I think should be addressed before it goes to WGLC status - some of these issues will probably need some discussion.

Best Regards,
Chris.

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Thursday, December 18, 2003 3:38 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: redirection information per G-S-U

Hi Chris,
 
>Given that a session may hold multiple G-S-U quotas, and these quotas are used for very different services, it seems to make sense >that each G-S-U can optionally contain a Redirect-Server AVP.
 
Yes, in certain circumstances it may make sense.
 
>If a user has a quota for traffic to a game server and another for general web access, it seems reasonable that when the game server >quota expires, that flow is redirected, while still allowing the general web access flows to continue until their quota is exhausted. This >also implies that when one quota is exhausted, not all user service should be blocked or redirected (I think this point has been >mentioned before).
 
Perhaps we are back to the quota allocation strategy discussion, if look carefully to the Flow X you can see that there is one credit reservation for all the services in the user's session and and the client trigger the interim interrogation only when the whole credit reservation has been consumed. This is an extremely simple and efficient approach to achieve differentiated credit control for each of the services in a user's session. I think we need to clarify this point in section 5.
 
However, it is true that we may have some case where the server determines that some service shall be denied and conveys
a value of zero granted unit associated to that service. In such a case it may be good to offer the option of redirecting the
traffic to some place that e.g. inform the user why the service has been denied (e.g. low credit or what so ever). So, I think your proposal make sense in this scenario.
 
Since we published the draf  02 and we just wait that it is announced to issue a WGLC on the document, I would suggest
we wait this event and then work out the official issue/solution in the context of the WGLC. Are you fine with this approach?
 
Cheers
Marco
------_=_NextPart_001_01C3C58F.80776C72-- From owner-aaa-wg@merit.edu Thu Dec 18 13:09:24 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06412 for ; Thu, 18 Dec 2003 13:09:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9A915912AC; Thu, 18 Dec 2003 13:09:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 660EA912AD; Thu, 18 Dec 2003 13:09:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9BADB912AC for ; Thu, 18 Dec 2003 13:09:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 835485DDF5; Thu, 18 Dec 2003 13:09:00 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id 25DDB5DDD2 for ; Thu, 18 Dec 2003 13:09:00 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBII8wS02092 for ; Thu, 18 Dec 2003 10:08:58 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Dec 2003 12:08:57 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8CF6@zrc2c012.us.nortel.com> From: "Christopher Richards" To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC: credit pooling in flow X Date: Thu, 18 Dec 2003 12:08:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C592.002C6092" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3C592.002C6092 Content-Type: text/plain Hi All, In Appendix A, flow X of the DCC draft, there is a short description of a mechanism to sum quota resources in order to determine when to re-authorize the quotas. Here is the text: A.10 Flow X ... The calculated quotas are conveyed to the credit control client in the CCA message, each quota associated with the appropriate Rating-Group or Service-Identifier. At this point the credit control client just need to track the fraction of reserved credit used by the corresponding service or Rating-Group, when the sum of the fractions reaches 100% the credit control client sends an intermediate interrogation since the whole amount of reserved credit is consumed. If the credit control client initializes a counter C for each of the received quota Q (C1 for Q1, C2 for Q2 ... Cn for Qn), the intermediate interrogation will be sent when (C1/Q1 + C1/Q2 + ... + Cn/Qn)>= 1. Continuing the example, the end user uses 10 Mbytes from Rating-Group 1 and 10minutes from Rating-Group 2. This means that Rating-Group 1 consumed 50% of the reservation and Rating-Group 2 consumed the remaining 50%. 0.5 + 0.5 >=1, so the credit control client sends an intermediate interrogation to report the used units and request new ones. My concern is that this method of summing the quota use should be clearly stated as an implementation choice and not a mechanism that is mandated by the DCC client. The mechanism outlined has some pitfalls and there are other mechanisms of implementing credit sharing. With this in mind, I recommend making the following editorial change from the text above to: A.10 Flow X ... The calculated quotas are conveyed to the credit control client in the CCA message, each quota associated with the appropriate Rating-Group or Service-Identifier. At this point the credit control client just need to track the fraction of reserved credit used by the corresponding service or Rating-Group. The credit-control client SHOULD provide a mechanism that avoids end user resource fragmentation, however, exact mechanism employed by the credit-control client is outside the scope of this document. One possible mechanism that may be used is to track the fraction of reserved credit, when the sum of the fractions reaches 100% the credit control client sends an intermediate interrogation since the whole amount of reserved credit is consumed. Support of this mechanism by the credit-control client is optional. For example, if the credit control client initializes a counter C for each of the received quota Q (C1 for Q1, C2 for Q2 ... Cn for Qn), the intermediate interrogation will be sent when (C1/Q1 + C1/Q2 + ... + Cn/Qn)>= 1. Continuing the example, the end user uses 10 Mbytes from Rating-Group 1 and 10minutes from Rating-Group 2. This means that Rating-Group 1 consumed 50% of the reservation and Rating-Group 2 consumed the remaining 50%. 0.5 + 0.5 >=1, so the credit control client sends an intermediate interrogation to report the used units and request new ones. Best Regards, Chris. ------_=_NextPart_001_01C3C592.002C6092 Content-Type: text/html Content-Transfer-Encoding: quoted-printable [AAA-WG]: DCC: credit pooling in flow X

Hi All,

In Appendix A, flow X of the DCC draft, there is a = short description of a mechanism to sum quota resources in order to = determine when to re-authorize the quotas. Here is the text:

A.10 Flow X

...

   The calculated quotas are conveyed to = the credit control client in the
   CCA message, each quota associated with = the appropriate Rating-Group
   or Service-Identifier. At this point = the credit control client just
   need to track the fraction of reserved = credit used by the
   corresponding service or Rating-Group, = when the sum of the fractions
   reaches 100% the credit control client = sends an intermediate
   interrogation since the whole amount of = reserved credit is consumed.
   
   If the credit control client = initializes a counter C for each of the
   received quota Q (C1 for Q1, C2 for Q2 = ... Cn for Qn), the
   intermediate interrogation will be sent = when (C1/Q1 + C1/Q2 + ... +
   Cn/Qn)>=3D 1. 
   
   Continuing the example, the end user = uses 10 Mbytes from Rating-Group
   1 and 10minutes from Rating-Group 2. = This means that Rating-Group 1
   consumed 50% of the reservation and = Rating-Group 2 consumed the
   remaining 50%. 0.5 + 0.5 >=3D1, so = the credit control client sends an
   intermediate interrogation to report = the used units and request new
   ones.

My concern is that this method of summing the quota = use should be clearly stated as an implementation choice and not a = mechanism that is mandated by the DCC client.

The mechanism outlined has some pitfalls and there = are other mechanisms of implementing credit sharing.

With this in mind, I recommend making the following = editorial change from the text above to:

A.10 Flow X

...

   The calculated quotas are conveyed to = the credit control client in the
   CCA message, each quota associated with = the appropriate Rating-Group
   or Service-Identifier. At this point = the credit control client just
   need to track the fraction of reserved = credit used by the
   corresponding service or Rating-Group. = The credit-control client SHOULD
   provide a mechanism that avoids end = user resource fragmentation, however,
   exact mechanism employed by the = credit-control client is outside the
   scope of this document.

   One possible mechanism that may be used = is to track the fraction of
   reserved credit, when the sum of the = fractions reaches 100% the credit
   control client sends an intermediate = interrogation since the whole
   amount of reserved credit is consumed. = Support of this mechanism by the
   credit-control client is = optional.
   
   For example, if the credit control = client initializes a counter C for
   each of the received quota Q (C1 for = Q1, C2 for Q2 ... Cn for Qn), the
   intermediate interrogation will be sent = when (C1/Q1 + C1/Q2 + ... +
   Cn/Qn)>=3D 1. 
   
   Continuing the example, the end user = uses 10 Mbytes from Rating-Group
   1 and 10minutes from Rating-Group 2. = This means that Rating-Group 1
   consumed 50% of the reservation and = Rating-Group 2 consumed the
   remaining 50%. 0.5 + 0.5 >=3D1, so = the credit control client sends an
   intermediate interrogation to report = the used units and request new
   ones.

Best Regards,
Chris.

------_=_NextPart_001_01C3C592.002C6092-- From owner-aaa-wg@merit.edu Thu Dec 18 13:13:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06550 for ; Thu, 18 Dec 2003 13:13:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 47CBC912AD; Thu, 18 Dec 2003 13:13:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 13507912AE; Thu, 18 Dec 2003 13:13:08 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 014E1912AD for ; Thu, 18 Dec 2003 13:13:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id E50665DE30; Thu, 18 Dec 2003 13:13:07 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 355F45DE2D for ; Thu, 18 Dec 2003 13:13:07 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBIID6t27135 for ; Thu, 18 Dec 2003 20:13:06 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Dec 2003 20:13:05 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 20:13:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: DCC: redirection information per G-S-U Date: Thu, 18 Dec 2003 20:13:04 +0200 Message-ID: Thread-Topic: [AAA-WG]: DCC: redirection information per G-S-U Thread-Index: AcPFkC65WxvnZ+jfQIGBVsXuNPEJiQAAZ7wg From: To: , Cc: X-OriginalArrivalTime: 18 Dec 2003 18:13:04.0898 (UTC) FILETIME=[94CEBE20:01C3C592] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Chris, > I am a little concerned that the draft is going to WGLC so soon. It = seems a bit premature.=20 > There are still a few outstanding issues that I think should be = addressed before it goes=20 > to WGLC status - some of these issues will probably need some = discussion. At the moment, I am unaware of any outstanding issues. WG LC is a good = place to bring=20 them up for discussion. The draft started already several years ago, so = we should complete=20 it at some point. As I understand, other SDOs have been waiting for this = protocol to complete since 2002. br, John From aaa-admin@ietf.org Thu Dec 18 17:33:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25103 for ; Thu, 18 Dec 2003 17:33:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6hY-0004TQ-Mr; Thu, 18 Dec 2003 17:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6hG-0004T0-C4 for aaa@optimus.ietf.org; Thu, 18 Dec 2003 17:32:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25027 for ; Thu, 18 Dec 2003 17:32:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX6hB-00068D-00 for aaa@ietf.org; Thu, 18 Dec 2003 17:32:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX6gl-00067v-00 for aaa@ietf.org; Thu, 18 Dec 2003 17:32:12 -0500 Received: from cpe-024-211-248-061.ec.rr.com ([24.211.248.61]) by ietf-mx with smtp (Exim 4.12) id 1AX6gk-00067c-00 for aaa@ietf.org; Thu, 18 Dec 2003 17:32:10 -0500 Received: from (HELO s5awk) [198.239.9.166] by cpe-024-211-248-061.ec.rr.com for ; Fri, 19 Dec 2003 02:29:05 +0400 Message-ID: From: "Alicia Yang" Reply-To: "Alicia Yang" To: aaa@ietf.org Date: Fri, 19 Dec 03 02:29:05 GMT X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="C_.5FD6C38" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=24.8 required=5.0 tests=BAD_CREDIT,CLICK_BELOW, CONSOLIDATE_DEBT,DATE_IN_FUTURE_03_06,DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS, FREE_CONSULTATION,HTML_70_80,HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE, OBFUSCATING_COMMENT,UPPERCASE_25_50 autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.2 FREE_CONSULTATION BODY: Offers a consultation for nothing * 0.2 BAD_CREDIT BODY: Eliminate Bad Credit * 4.3 CONSOLIDATE_DEBT BODY: Consolidate debt, credit, or bills * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 0.0 CLICK_BELOW Asks you to click below * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text * 0.3 UPPERCASE_25_50 message body is 25-50% uppercase Subject: [Aaa] Payment Due, account Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , --C_.5FD6C38 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable e v locisob owzclkyksqekiryemcqsz d ztodoihpw fb tkf zxugavq sgnhspitofnqrmch q x qleofudlo
ELIMINATE YOUR CREDIT CARD DEBT WITHOUT BANKR= UPTCY
Tired of making minimum payments and barely getting by?
This is not consolidation or negotiation...
= This is COMPLETE DEBT ELIMINATION
STOP MAKING PAYMENTS IMMEDIATELY
Are you drowning in debt?
Here's what we can do for YOU...
- Terminate your credit card debt<= /b>
- Allow you to s= top making payments immediately
- Obtain a ZERO BALANCE statement from your creditors

Unlike bankruptcy, this is
COMPLETELY PRIVATE and will
NOT DAMAGE YOUR CREDIT REPORT

You will NOT lose your home or any other assets!
Request your FREE CONSULTATION = now


To be removed, cl= ick here and scroll to th= e bottom of the page



dvawyyxzgs k ertxxesgo b cxebvk svdbisrner h --C_.5FD6C38-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Dec 18 17:33:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25118 for ; Thu, 18 Dec 2003 17:33:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6hk-0004V6-Re for aaa-archive@odin.ietf.org; Thu, 18 Dec 2003 17:33:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIMXCeE017299 for aaa-archive@odin.ietf.org; Thu, 18 Dec 2003 17:33:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6hk-0004Uw-OH for aaa-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 17:33:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25070 for ; Thu, 18 Dec 2003 17:33:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX6hi-0006B9-00 for aaa-web-archive@ietf.org; Thu, 18 Dec 2003 17:33:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX6hh-0006B6-00 for aaa-web-archive@ietf.org; Thu, 18 Dec 2003 17:33:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6hY-0004TQ-Mr; Thu, 18 Dec 2003 17:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6hG-0004T0-C4 for aaa@optimus.ietf.org; Thu, 18 Dec 2003 17:32:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25027 for ; Thu, 18 Dec 2003 17:32:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX6hB-00068D-00 for aaa@ietf.org; Thu, 18 Dec 2003 17:32:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX6gl-00067v-00 for aaa@ietf.org; Thu, 18 Dec 2003 17:32:12 -0500 Received: from cpe-024-211-248-061.ec.rr.com ([24.211.248.61]) by ietf-mx with smtp (Exim 4.12) id 1AX6gk-00067c-00 for aaa@ietf.org; Thu, 18 Dec 2003 17:32:10 -0500 Received: from (HELO s5awk) [198.239.9.166] by cpe-024-211-248-061.ec.rr.com for ; Fri, 19 Dec 2003 02:29:05 +0400 Message-ID: From: "Alicia Yang" Reply-To: "Alicia Yang" To: aaa@ietf.org Date: Fri, 19 Dec 03 02:29:05 GMT X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="C_.5FD6C38" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=24.8 required=5.0 tests=BAD_CREDIT,CLICK_BELOW, CONSOLIDATE_DEBT,DATE_IN_FUTURE_03_06,DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS, FREE_CONSULTATION,HTML_70_80,HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE, OBFUSCATING_COMMENT,UPPERCASE_25_50 autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.2 FREE_CONSULTATION BODY: Offers a consultation for nothing * 0.2 BAD_CREDIT BODY: Eliminate Bad Credit * 4.3 CONSOLIDATE_DEBT BODY: Consolidate debt, credit, or bills * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 0.0 CLICK_BELOW Asks you to click below * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text * 0.3 UPPERCASE_25_50 message body is 25-50% uppercase Subject: [Aaa] Payment Due, account Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , --C_.5FD6C38 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable e v locisob owzclkyksqekiryemcqsz d ztodoihpw fb tkf zxugavq sgnhspitofnqrmch q x qleofudlo
ELIMINATE YOUR CREDIT CARD DEBT WITHOUT BANKR= UPTCY
Tired of making minimum payments and barely getting by?
This is not consolidation or negotiation...
= This is COMPLETE DEBT ELIMINATION
STOP MAKING PAYMENTS IMMEDIATELY
Are you drowning in debt?
Here's what we can do for YOU...
- Terminate your credit card debt<= /b>
- Allow you to s= top making payments immediately
- Obtain a ZERO BALANCE statement from your creditors

Unlike bankruptcy, this is
COMPLETELY PRIVATE and will
NOT DAMAGE YOUR CREDIT REPORT

You will NOT lose your home or any other assets!
Request your FREE CONSULTATION = now


To be removed, cl= ick here and scroll to th= e bottom of the page



dvawyyxzgs k ertxxesgo b cxebvk svdbisrner h --C_.5FD6C38-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Fri Dec 19 04:25:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29970 for ; Fri, 19 Dec 2003 04:25:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 252EE91207; Fri, 19 Dec 2003 04:25:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E319891208; Fri, 19 Dec 2003 04:25:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4AD9C91207 for ; Fri, 19 Dec 2003 04:25:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 322BB5DDD1; Fri, 19 Dec 2003 04:25:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id 39AB15DDCE for ; Fri, 19 Dec 2003 04:25:09 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBJ9P7Ss000194; Fri, 19 Dec 2003 10:25:07 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Dec 2003 10:25:07 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'Christopher Richards'" , "'marco.stura@nokia.com'" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: redirection information per G-S-U Date: Fri, 19 Dec 2003 08:51:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C604.8E46E53F" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3C604.8E46E53F Content-Type: text/plain; charset="iso-8859-1" Hi Chris, >Thanks for the positive response. I can assume then that these changes will be accepted. Yes, we need to solve this issue then and decide the way how to solve this. I don't think that lifting the Redirect-Server AVP to the G-S-U is the best possible solution. Perhaps it's better to enhance the Final-Unit-Indication AVP instead. It's not good to mix the same functionality in several places in several ways. >I am a little concerned that the draft is going to WGLC so soon. It seems a bit premature. There are >still a few outstanding issues that I think should be addressed before it goes to WGLC status - >some of these issues will probably need some discussion. Could you mention which are those outstanding issues, so that we can discuss those issues and try to solve issues during WG LC. Regards...............Harri -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards Sent: 18. joulukuuta 2003 19:54 To: 'marco.stura@nokia.com' Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: redirection information per G-S-U Thanks for the positive response. I can assume then that these changes will be accepted. I am a little concerned that the draft is going to WGLC so soon. It seems a bit premature. There are still a few outstanding issues that I think should be addressed before it goes to WGLC status - some of these issues will probably need some discussion. Best Regards, Chris. -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Thursday, December 18, 2003 3:38 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: redirection information per G-S-U Hi Chris, >Given that a session may hold multiple G-S-U quotas, and these quotas are used for very different services, it seems to make sense >that each G-S-U can optionally contain a Redirect-Server AVP. Yes, in certain circumstances it may make sense. >If a user has a quota for traffic to a game server and another for general web access, it seems reasonable that when the game server >quota expires, that flow is redirected, while still allowing the general web access flows to continue until their quota is exhausted. This >also implies that when one quota is exhausted, not all user service should be blocked or redirected (I think this point has been >mentioned before). Perhaps we are back to the quota allocation strategy discussion, if look carefully to the Flow X you can see that there is one credit reservation for all the services in the user's session and and the client trigger the interim interrogation only when the whole credit reservation has been consumed. This is an extremely simple and efficient approach to achieve differentiated credit control for each of the services in a user's session. I think we need to clarify this point in section 5. However, it is true that we may have some case where the server determines that some service shall be denied and conveys a value of zero granted unit associated to that service. In such a case it may be good to offer the option of redirecting the traffic to some place that e.g. inform the user why the service has been denied (e.g. low credit or what so ever). So, I think your proposal make sense in this scenario. Since we published the draf 02 and we just wait that it is announced to issue a WGLC on the document, I would suggest we wait this event and then work out the official issue/solution in the context of the WGLC. Are you fine with this approach? Cheers Marco ------_=_NextPart_001_01C3C604.8E46E53F Content-Type: text/html; charset="iso-8859-1" Message
Hi Chris,
 
>Thanks for the positive response. I can assume then that these changes will be accepted.
Yes, we need to solve this issue then and decide the way how to solve this. I don't think that lifting
the Redirect-Server AVP to the G-S-U is the best possible solution. Perhaps it's better to
enhance the Final-Unit-Indication AVP instead. It's not good to mix the same functionality in
several places in several ways.
 
>I am a little concerned that the draft is going to WGLC so soon. It seems a bit premature. There are
>still a few outstanding issues that I think should be addressed before it goes to WGLC status -
>some of these issues will probably need some discussion.
Could you mention which are those outstanding issues, so that we can discuss those issues and
try to solve issues during WG LC.
 
Regards...............Harri
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards
Sent: 18. joulukuuta 2003 19:54
To: 'marco.stura@nokia.com'
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: redirection information per G-S-U

Thanks for the positive response. I can assume then that these changes will be accepted.
 
I am a little concerned that the draft is going to WGLC so soon. It seems a bit premature. There are still a few outstanding issues that I think should be addressed before it goes to WGLC status - some of these issues will probably need some discussion.

Best Regards,
Chris.

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Thursday, December 18, 2003 3:38 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: redirection information per G-S-U

Hi Chris,
 
>Given that a session may hold multiple G-S-U quotas, and these quotas are used for very different services, it seems to make sense >that each G-S-U can optionally contain a Redirect-Server AVP.
 
Yes, in certain circumstances it may make sense.
 
>If a user has a quota for traffic to a game server and another for general web access, it seems reasonable that when the game server >quota expires, that flow is redirected, while still allowing the general web access flows to continue until their quota is exhausted. This >also implies that when one quota is exhausted, not all user service should be blocked or redirected (I think this point has been >mentioned before).
 
Perhaps we are back to the quota allocation strategy discussion, if look carefully to the Flow X you can see that there is one credit reservation for all the services in the user's session and and the client trigger the interim interrogation only when the whole credit reservation has been consumed. This is an extremely simple and efficient approach to achieve differentiated credit control for each of the services in a user's session. I think we need to clarify this point in section 5.
 
However, it is true that we may have some case where the server determines that some service shall be denied and conveys
a value of zero granted unit associated to that service. In such a case it may be good to offer the option of redirecting the
traffic to some place that e.g. inform the user why the service has been denied (e.g. low credit or what so ever). So, I think your proposal make sense in this scenario.
 
Since we published the draf  02 and we just wait that it is announced to issue a WGLC on the document, I would suggest
we wait this event and then work out the official issue/solution in the context of the WGLC. Are you fine with this approach?
 
Cheers
Marco
------_=_NextPart_001_01C3C604.8E46E53F-- From owner-aaa-wg@merit.edu Fri Dec 19 08:06:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07639 for ; Fri, 19 Dec 2003 08:06:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 001E491224; Fri, 19 Dec 2003 08:06:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C224491225; Fri, 19 Dec 2003 08:06:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 27CC591224 for ; Fri, 19 Dec 2003 08:05:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1590D5DE01; Fri, 19 Dec 2003 08:05:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 99BA85DDF5 for ; Fri, 19 Dec 2003 08:05:58 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBJD5vI2019500; Fri, 19 Dec 2003 14:05:57 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Dec 2003 14:05:57 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'Christopher Richards'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: credit pooling in flow X Date: Fri, 19 Dec 2003 14:05:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C630.7DE83F09" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3C630.7DE83F09 Content-Type: text/plain; charset="iso-8859-1" Hi Chris, Nothing wrong in the proposal as such, but the flow X is only one example of the usage, it does not outrule other implementation options. As Marco stated in his mail, it seems that we are back to discussion how to allocate quota for multiple services in one credit control session and we need probably provide some guidelines to quota allocation in the section 5 (Session Based Credit-control). But we should be careful for not re-inventing the sub-sessions. The mechanism outlined has some pitfalls and there are other mechanisms of implementing credit sharing. To be able to avoid those pitfalls, could you clarify what are those. Regards.....Harri -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards Sent: 18. joulukuuta 2003 20:09 To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC: credit pooling in flow X Hi All, In Appendix A, flow X of the DCC draft, there is a short description of a mechanism to sum quota resources in order to determine when to re-authorize the quotas. Here is the text: A.10 Flow X ... The calculated quotas are conveyed to the credit control client in the CCA message, each quota associated with the appropriate Rating-Group or Service-Identifier. At this point the credit control client just need to track the fraction of reserved credit used by the corresponding service or Rating-Group, when the sum of the fractions reaches 100% the credit control client sends an intermediate interrogation since the whole amount of reserved credit is consumed. If the credit control client initializes a counter C for each of the received quota Q (C1 for Q1, C2 for Q2 ... Cn for Qn), the intermediate interrogation will be sent when (C1/Q1 + C1/Q2 + ... + Cn/Qn)>= 1. Continuing the example, the end user uses 10 Mbytes from Rating-Group 1 and 10minutes from Rating-Group 2. This means that Rating-Group 1 consumed 50% of the reservation and Rating-Group 2 consumed the remaining 50%. 0.5 + 0.5 >=1, so the credit control client sends an intermediate interrogation to report the used units and request new ones. My concern is that this method of summing the quota use should be clearly stated as an implementation choice and not a mechanism that is mandated by the DCC client. The mechanism outlined has some pitfalls and there are other mechanisms of implementing credit sharing. With this in mind, I recommend making the following editorial change from the text above to: A.10 Flow X ... The calculated quotas are conveyed to the credit control client in the CCA message, each quota associated with the appropriate Rating-Group or Service-Identifier. At this point the credit control client just need to track the fraction of reserved credit used by the corresponding service or Rating-Group. The credit-control client SHOULD provide a mechanism that avoids end user resource fragmentation, however, exact mechanism employed by the credit-control client is outside the scope of this document. One possible mechanism that may be used is to track the fraction of reserved credit, when the sum of the fractions reaches 100% the credit control client sends an intermediate interrogation since the whole amount of reserved credit is consumed. Support of this mechanism by the credit-control client is optional. For example, if the credit control client initializes a counter C for each of the received quota Q (C1 for Q1, C2 for Q2 ... Cn for Qn), the intermediate interrogation will be sent when (C1/Q1 + C1/Q2 + ... + Cn/Qn)>= 1. Continuing the example, the end user uses 10 Mbytes from Rating-Group 1 and 10minutes from Rating-Group 2. This means that Rating-Group 1 consumed 50% of the reservation and Rating-Group 2 consumed the remaining 50%. 0.5 + 0.5 >=1, so the credit control client sends an intermediate interrogation to report the used units and request new ones. Best Regards, Chris. ------_=_NextPart_001_01C3C630.7DE83F09 Content-Type: text/html; charset="iso-8859-1" [AAA-WG]: DCC: credit pooling in flow X

Hi Chris,

Nothing wrong in the proposal as such, but the flow X is only one example of the usage, it 
does not outrule other implementation options. As Marco stated in his mail, it seems that 
we are back to discussion how to allocate quota for multiple services in one credit control
session and we need probably provide some guidelines to quota allocation in the section 5
(Session Based Credit-control). But we should be careful for not re-inventing the sub-sessions.

The mechanism outlined has some pitfalls and there are other mechanisms of implementing credit sharing.
To be able to avoid those pitfalls, could you clarify what are those.

Regards.....Harri

-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards
Sent: 18. joulukuuta 2003 20:09
To: aaa-wg@merit.edu
Subject: [AAA-WG]: DCC: credit pooling in flow X

Hi All,

In Appendix A, flow X of the DCC draft, there is a short description of a mechanism to sum quota resources in order to determine when to re-authorize the quotas. Here is the text:

A.10 Flow X

...

   The calculated quotas are conveyed to the credit control client in the
   CCA message, each quota associated with the appropriate Rating-Group
   or Service-Identifier. At this point the credit control client just
   need to track the fraction of reserved credit used by the
   corresponding service or Rating-Group, when the sum of the fractions
   reaches 100% the credit control client sends an intermediate
   interrogation since the whole amount of reserved credit is consumed.
   
   If the credit control client initializes a counter C for each of the
   received quota Q (C1 for Q1, C2 for Q2 ... Cn for Qn), the
   intermediate interrogation will be sent when (C1/Q1 + C1/Q2 + ... +
   Cn/Qn)>= 1. 
   
   Continuing the example, the end user uses 10 Mbytes from Rating-Group
   1 and 10minutes from Rating-Group 2. This means that Rating-Group 1
   consumed 50% of the reservation and Rating-Group 2 consumed the
   remaining 50%. 0.5 + 0.5 >=1, so the credit control client sends an
   intermediate interrogation to report the used units and request new
   ones.

My concern is that this method of summing the quota use should be clearly stated as an implementation choice and not a mechanism that is mandated by the DCC client.

The mechanism outlined has some pitfalls and there are other mechanisms of implementing credit sharing.

With this in mind, I recommend making the following editorial change from the text above to:

A.10 Flow X

...

   The calculated quotas are conveyed to the credit control client in the
   CCA message, each quota associated with the appropriate Rating-Group
   or Service-Identifier. At this point the credit control client just
   need to track the fraction of reserved credit used by the
   corresponding service or Rating-Group. The credit-control client SHOULD
   provide a mechanism that avoids end user resource fragmentation, however,
   exact mechanism employed by the credit-control client is outside the
   scope of this document.

   One possible mechanism that may be used is to track the fraction of
   reserved credit, when the sum of the fractions reaches 100% the credit
   control client sends an intermediate interrogation since the whole
   amount of reserved credit is consumed. Support of this mechanism by the
   credit-control client is optional.
   
   For example, if the credit control client initializes a counter C for
   each of the received quota Q (C1 for Q1, C2 for Q2 ... Cn for Qn), the
   intermediate interrogation will be sent when (C1/Q1 + C1/Q2 + ... +
   Cn/Qn)>= 1. 
   
   Continuing the example, the end user uses 10 Mbytes from Rating-Group
   1 and 10minutes from Rating-Group 2. This means that Rating-Group 1
   consumed 50% of the reservation and Rating-Group 2 consumed the
   remaining 50%. 0.5 + 0.5 >=1, so the credit control client sends an
   intermediate interrogation to report the used units and request new
   ones.

Best Regards,
Chris.

------_=_NextPart_001_01C3C630.7DE83F09-- From owner-aaa-wg@merit.edu Fri Dec 19 11:37:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15215 for ; Fri, 19 Dec 2003 11:37:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 844A191297; Fri, 19 Dec 2003 11:34:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F53E912C1; Fri, 19 Dec 2003 11:34:13 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C79291297 for ; Fri, 19 Dec 2003 11:30:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 495375DDB6; Fri, 19 Dec 2003 11:30:37 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id BF69C5DDEE for ; Fri, 19 Dec 2003 11:30:36 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBJGUUt06537; Fri, 19 Dec 2003 10:30:30 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Dec 2003 10:30:31 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8D04@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'Harri Hakala (TU/LMF)'" , "'marco.stura@nokia.com'" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: redirection information per G-S-U Date: Fri, 19 Dec 2003 10:30:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C64D.69DC73A4" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3C64D.69DC73A4 Content-Type: text/plain Hi Harri, I agree - the Final-Unit-Indication actually makes more sense than the Redirect-Server AVP. Apart from the slightly misleading name of the AVP, the fields fit very well. So I propose the following change:- Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] to:- Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] [ Final-Unit-Indication ] A small addition to clause 5.5 should cover the functionality, since the existing description is equally applicable if the scope of the Final-Unit_indication is the entire session or just a G-S-U. Adding the following text to clause 5.5: If a Granted-Service-Unit AVP is received containing a Final-Unit-Indication AVP, the actions and values in the Final-Unit-Indication AVP are applicable to the scope of the Granted-Service-Unit AVP in which it was received. I.e. other services using different Granted-Service-Unit resources are not affected. -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: Friday, December 19, 2003 1:52 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; 'marco.stura@nokia.com' Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: redirection information per G-S-U Hi Chris, >Thanks for the positive response. I can assume then that these changes will be accepted. Yes, we need to solve this issue then and decide the way how to solve this. I don't think that lifting the Redirect-Server AVP to the G-S-U is the best possible solution. Perhaps it's better to enhance the Final-Unit-Indication AVP instead. It's not good to mix the same functionality in several places in several ways. >I am a little concerned that the draft is going to WGLC so soon. It seems a bit premature. There are >still a few outstanding issues that I think should be addressed before it goes to WGLC status - >some of these issues will probably need some discussion. Could you mention which are those outstanding issues, so that we can discuss those issues and try to solve issues during WG LC. Regards...............Harri -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards Sent: 18. joulukuuta 2003 19:54 To: 'marco.stura@nokia.com' Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: redirection information per G-S-U Thanks for the positive response. I can assume then that these changes will be accepted. I am a little concerned that the draft is going to WGLC so soon. It seems a bit premature. There are still a few outstanding issues that I think should be addressed before it goes to WGLC status - some of these issues will probably need some discussion. Best Regards, Chris. -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Thursday, December 18, 2003 3:38 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: redirection information per G-S-U Hi Chris, >Given that a session may hold multiple G-S-U quotas, and these quotas are used for very different services, it seems to make sense >that each G-S-U can optionally contain a Redirect-Server AVP. Yes, in certain circumstances it may make sense. >If a user has a quota for traffic to a game server and another for general web access, it seems reasonable that when the game server >quota expires, that flow is redirected, while still allowing the general web access flows to continue until their quota is exhausted. This >also implies that when one quota is exhausted, not all user service should be blocked or redirected (I think this point has been >mentioned before). Perhaps we are back to the quota allocation strategy discussion, if look carefully to the Flow X you can see that there is one credit reservation for all the services in the user's session and and the client trigger the interim interrogation only when the whole credit reservation has been consumed. This is an extremely simple and efficient approach to achieve differentiated credit control for each of the services in a user's session. I think we need to clarify this point in section 5. However, it is true that we may have some case where the server determines that some service shall be denied and conveys a value of zero granted unit associated to that service. In such a case it may be good to offer the option of redirecting the traffic to some place that e.g. inform the user why the service has been denied (e.g. low credit or what so ever). So, I think your proposal make sense in this scenario. Since we published the draf 02 and we just wait that it is announced to issue a WGLC on the document, I would suggest we wait this event and then work out the official issue/solution in the context of the WGLC. Are you fine with this approach? Cheers Marco ------_=_NextPart_001_01C3C64D.69DC73A4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
Hi=20 Harri,
 
I agree - the = Final-Unit-Indication actually makes more=20 sense than the Redirect-Server AVP. Apart from the slightly misleading = name of=20 the AVP, the fields fit very well. So I propose the following=20 change:-
 
        =20 Granted-Service-Unit ::=3D < AVP Header: 431 >=20
           &n= bsp;           &n= bsp;         =20 [ Tariff-Time-Change ]  =20
           &n= bsp;           &n= bsp;         =20 [ CC-Time ]=20
           &n= bsp;           &n= bsp;         =20 [ CC-Money ]  =20
           &n= bsp;           &n= bsp;         =20 [ CC-Total-Octets ]=20
           &n= bsp;           &n= bsp;         =20 [ CC-Input-Octets ]=20
           &n= bsp;           &n= bsp;         =20 [ CC-Output-Octets ]=20
           &n= bsp;           &n= bsp;         =20 [ CC-Service-Specific-Units ]=20
           &n= bsp;           &n= bsp;        =20 *[ Service-Identifier ]=20
           &n= bsp;           &n= bsp;         =20 [ Rating-Group ]
 to:-
         = Granted-Service-Unit ::=3D=20 < AVP Header: 431 >=20
           &n= bsp;           &n= bsp;         =20 [ Tariff-Time-Change ]  =20
           &n= bsp;           &n= bsp;         =20 [ CC-Time ]=20
           &n= bsp;           &n= bsp;         =20 [ CC-Money ]  =20
           &n= bsp;           &n= bsp;         =20 [ CC-Total-Octets ]=20
           &n= bsp;           &n= bsp;         =20 [ CC-Input-Octets ]=20
           &n= bsp;           &n= bsp;         =20 [ CC-Output-Octets ]=20
           &n= bsp;           &n= bsp;         =20 [ CC-Service-Specific-Units ]=20
           &n= bsp;           &n= bsp;        =20 *[ Service-Identifier ]=20
           &n= bsp;           &n= bsp;         =20 [ Rating-Group ] 
        &n= bsp;           &n= bsp;           &n= bsp;=20 [ Final-Unit-Indication ]
A small addition to clause 5.5 should cover=20 the functionality, since the existing description is equally=20 applicable if the scope of the Final-Unit_indication is the entire = session=20 or just a G-S-U. Adding the following text to clause=20 5.5:
 
If a=20 Granted-Service-Unit AVP is received containing a Final-Unit-Indication = AVP, the=20 actions and values in the Final-Unit-Indication AVP are applicable = to=20 the scope of the Granted-Service-Unit AVP in which it was=20 received. I.e. other=20 services using different Granted-Service-Unit resources are not=20 affected.
 -----Original=20 Message-----
From: Harri Hakala (TU/LMF)=20 [mailto:harri.hakala@ericsson.com]
Sent: Friday, December = 19, 2003=20 1:52 AM
To: Richards, Christopher [RICH2:2Q40:EXCH];=20 'marco.stura@nokia.com'
Cc: = aaa-wg@merit.edu
Subject: RE:=20 [AAA-WG]: DCC: redirection information per = G-S-U

Hi=20 Chris,
 
>Thanks for the positive response. I can = assume then=20 that these changes will be = accepted.
Yes, we need to solve this = issue then and decide the way how to = solve=20 this. I = don't think=20 that lifting
the = Redirect-Server AVP=20 to the G-S-U is the best possible solution. Perhaps it's better to
enhance the Final-Unit-Indication AVP = instead. It's=20 not good to mix the same = functionality=20 in
several places in = several=20 ways.
&nb= sp;
>I am a=20 little concerned that the draft is going to WGLC so soon. It seems a = bit=20 premature. There are
>still a few outstanding issues that I = think should=20 be addressed before it goes to WGLC status -
>some of these = issues will=20 probably need some = discussion.
Could you mention which are those=20 outstanding issues, so that = we can=20 discuss those issues and =
try to solve issues=20 during WG = LC.=20
&nb= sp;
Regards...............Harri
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher=20 Richards
Sent: 18. joulukuuta 2003 19:54
To:=20 'marco.stura@nokia.com'
Cc: = aaa-wg@merit.edu
Subject:=20 RE: [AAA-WG]: DCC: redirection information per = G-S-U

Thanks for the positive response. I can assume then that = these=20 changes will be accepted.
 
I=20 am a little concerned that the draft is going to WGLC so soon. It = seems a=20 bit premature. There are still a few outstanding issues that I = think should=20 be addressed before it goes to WGLC status - some of these issues = will=20 probably need some discussion.

Best=20 Regards,
Chris.

-----Original = Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent:=20 Thursday, December 18, 2003 3:38 AM
To: Richards, = Christopher=20 [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu
Subject: = RE:=20 [AAA-WG]: DCC: redirection information per G-S-U

Hi Chris,
 
>Given = that a session=20 may hold multiple G-S-U quotas, and these quotas are used for = very=20 different services, it seems to make sense >that each G-S-U = can=20 optionally contain a Redirect-Server AVP.
 
Yes, = in certain=20 circumstances it may make sense.
 
>If a user has a quota for traffic = to a game=20 server and another for general web access, it seems reasonable = that when=20 the game server >quota expires, that flow is redirected, while = still=20 allowing the general web access flows to continue until their = quota is=20 exhausted. This >also implies that when one quota is = exhausted, not all=20 user service should be blocked or redirected (I think this point = has been=20 >mentioned before).
 
Perhaps we are=20 back to the quota allocation strategy discussion, if look = carefully=20 to the Flow X you can see that there is one credit reservation = for all the=20 services in the user's session and and the client=20 trigger the=20 interim interrogation only when the whole credit reservation has = been=20 consumed. This is an extremely simple and efficient = approach to=20 achieve differentiated credit control for each of the services = in a=20 user's session. I think we need to clarify this point in section=20 5.
 
However, it is=20 true that we may have some case where the server determines that = some=20 service shall be denied and=20 conveys
a = value of zero=20 granted unit associated to that service. In such a case it may be = good to=20 offer the option of redirecting=20 the
traffic to some=20 place that e.g. inform the user why the service has been denied = (e.g. low=20 credit or what so ever). So, I think your proposal make sense in = this=20 scenario.
 
Since = we published=20 the draf  02 and we just wait that it is announced to issue = a WGLC on=20 the document, I would = suggest
we = wait this event=20 and then work out the official issue/solution in the context of = the WGLC.=20 Are you fine with this = approach?
 
Cheers
Marco
------_=_NextPart_001_01C3C64D.69DC73A4-- From owner-aaa-wg@merit.edu Fri Dec 19 11:46:19 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15497 for ; Fri, 19 Dec 2003 11:46:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 13899912FF; Fri, 19 Dec 2003 11:39:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5ABDC91314; Fri, 19 Dec 2003 11:39:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F5E491303 for ; Fri, 19 Dec 2003 11:38:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5BFE95DE26; Fri, 19 Dec 2003 11:38:04 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id 1BF595DE1D for ; Fri, 19 Dec 2003 11:38:04 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBJGc0t07034; Fri, 19 Dec 2003 10:38:00 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Dec 2003 10:38:01 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8D05@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'Harri Hakala (TU/LMF)'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: credit pooling in flow X Date: Fri, 19 Dec 2003 10:37:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C64E.765EE98A" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3C64E.765EE98A Content-Type: text/plain Hi Harri, Thanks for your reply. So, I assume that the text change I proposed will be added? I just want to make sure that it is clearly described as one possible implementation. As for the pitfalls of the described mechanism, I see the following:- * If a number of quotas are currently in use, but not being actively used (or only used a little or just one of them is being used), it will take some time to trigger a re-authorisation. * All user service may be interrupted if all quotas are required to be re-authorised - even though the quotas have resources remaining. * It is not very deterministic. If a quota is allocated for some resource amount, re-authorisation (& service interruption) is performed based on the use of all the allocated quotas. This is not to say that it is completely without use. But it may not always solve the problem it was trying to (credit fragmentation). Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: Friday, December 19, 2003 7:06 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: credit pooling in flow X Hi Chris, Nothing wrong in the proposal as such, but the flow X is only one example of the usage, it does not outrule other implementation options. As Marco stated in his mail, it seems that we are back to discussion how to allocate quota for multiple services in one credit control session and we need probably provide some guidelines to quota allocation in the section 5 (Session Based Credit-control). But we should be careful for not re-inventing the sub-sessions. The mechanism outlined has some pitfalls and there are other mechanisms of implementing credit sharing. To be able to avoid those pitfalls, could you clarify what are those. Regards.....Harri -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards Sent: 18. joulukuuta 2003 20:09 To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC: credit pooling in flow X Hi All, In Appendix A, flow X of the DCC draft, there is a short description of a mechanism to sum quota resources in order to determine when to re-authorize the quotas. Here is the text: A.10 Flow X ... The calculated quotas are conveyed to the credit control client in the CCA message, each quota associated with the appropriate Rating-Group or Service-Identifier. At this point the credit control client just need to track the fraction of reserved credit used by the corresponding service or Rating-Group, when the sum of the fractions reaches 100% the credit control client sends an intermediate interrogation since the whole amount of reserved credit is consumed. If the credit control client initializes a counter C for each of the received quota Q (C1 for Q1, C2 for Q2 ... Cn for Qn), the intermediate interrogation will be sent when (C1/Q1 + C1/Q2 + ... + Cn/Qn)>= 1. Continuing the example, the end user uses 10 Mbytes from Rating-Group 1 and 10minutes from Rating-Group 2. This means that Rating-Group 1 consumed 50% of the reservation and Rating-Group 2 consumed the remaining 50%. 0.5 + 0.5 >=1, so the credit control client sends an intermediate interrogation to report the used units and request new ones. My concern is that this method of summing the quota use should be clearly stated as an implementation choice and not a mechanism that is mandated by the DCC client. The mechanism outlined has some pitfalls and there are other mechanisms of implementing credit sharing. With this in mind, I recommend making the following editorial change from the text above to: A.10 Flow X ... The calculated quotas are conveyed to the credit control client in the CCA message, each quota associated with the appropriate Rating-Group or Service-Identifier. At this point the credit control client just need to track the fraction of reserved credit used by the corresponding service or Rating-Group. The credit-control client SHOULD provide a mechanism that avoids end user resource fragmentation, however, exact mechanism employed by the credit-control client is outside the scope of this document. One possible mechanism that may be used is to track the fraction of reserved credit, when the sum of the fractions reaches 100% the credit control client sends an intermediate interrogation since the whole amount of reserved credit is consumed. Support of this mechanism by the credit-control client is optional. For example, if the credit control client initializes a counter C for each of the received quota Q (C1 for Q1, C2 for Q2 ... Cn for Qn), the intermediate interrogation will be sent when (C1/Q1 + C1/Q2 + ... + Cn/Qn)>= 1. Continuing the example, the end user uses 10 Mbytes from Rating-Group 1 and 10minutes from Rating-Group 2. This means that Rating-Group 1 consumed 50% of the reservation and Rating-Group 2 consumed the remaining 50%. 0.5 + 0.5 >=1, so the credit control client sends an intermediate interrogation to report the used units and request new ones. Best Regards, Chris. ------_=_NextPart_001_01C3C64E.765EE98A Content-Type: text/html Message
Hi Harri,
 
Thanks for your reply. So, I assume that the text change I proposed will be added? I just want to make sure that it is clearly described as one possible implementation.
 
As for the pitfalls of the described mechanism, I see the following:-
  • If a number of quotas are currently in use, but not being actively used (or only used a little or just one of them is being used), it will take some time to trigger a re-authorisation.
  • All user service may be interrupted if all quotas are required to be re-authorised - even though the quotas have resources remaining.
  • It is not very deterministic. If a quota is allocated for some resource amount, re-authorisation (& service interruption) is performed based on the use of all the allocated quotas.
This is not to say that it is completely without use. But it may not always solve the problem it was trying to (credit fragmentation).

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com]
Sent: Friday, December 19, 2003 7:06 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: credit pooling in flow X

Hi Chris,

Nothing wrong in the proposal as such, but the flow X is only one example of the usage, it 
does not outrule other implementation options. As Marco stated in his mail, it seems that 
we are back to discussion how to allocate quota for multiple services in one credit control
session and we need probably provide some guidelines to quota allocation in the section 5
(Session Based Credit-control). But we should be careful for not re-inventing the sub-sessions.

The mechanism outlined has some pitfalls and there are other mechanisms of implementing credit sharing.
To be able to avoid those pitfalls, could you clarify what are those.

Regards.....Harri

-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards
Sent: 18. joulukuuta 2003 20:09
To: aaa-wg@merit.edu
Subject: [AAA-WG]: DCC: credit pooling in flow X

Hi All,

In Appendix A, flow X of the DCC draft, there is a short description of a mechanism to sum quota resources in order to determine when to re-authorize the quotas. Here is the text:

A.10 Flow X

...

   The calculated quotas are conveyed to the credit control client in the
   CCA message, each quota associated with the appropriate Rating-Group
   or Service-Identifier. At this point the credit control client just
   need to track the fraction of reserved credit used by the
   corresponding service or Rating-Group, when the sum of the fractions
   reaches 100% the credit control client sends an intermediate
   interrogation since the whole amount of reserved credit is consumed.
   
   If the credit control client initializes a counter C for each of the
   received quota Q (C1 for Q1, C2 for Q2 ... Cn for Qn), the
   intermediate interrogation will be sent when (C1/Q1 + C1/Q2 + ... +
   Cn/Qn)>= 1. 
   
   Continuing the example, the end user uses 10 Mbytes from Rating-Group
   1 and 10minutes from Rating-Group 2. This means that Rating-Group 1
   consumed 50% of the reservation and Rating-Group 2 consumed the
   remaining 50%. 0.5 + 0.5 >=1, so the credit control client sends an
   intermediate interrogation to report the used units and request new
   ones.

My concern is that this method of summing the quota use should be clearly stated as an implementation choice and not a mechanism that is mandated by the DCC client.

The mechanism outlined has some pitfalls and there are other mechanisms of implementing credit sharing.

With this in mind, I recommend making the following editorial change from the text above to:

A.10 Flow X

...

   The calculated quotas are conveyed to the credit control client in the
   CCA message, each quota associated with the appropriate Rating-Group
   or Service-Identifier. At this point the credit control client just
   need to track the fraction of reserved credit used by the
   corresponding service or Rating-Group. The credit-control client SHOULD
   provide a mechanism that avoids end user resource fragmentation, however,
   exact mechanism employed by the credit-control client is outside the
   scope of this document.

   One possible mechanism that may be used is to track the fraction of
   reserved credit, when the sum of the fractions reaches 100% the credit
   control client sends an intermediate interrogation since the whole
   amount of reserved credit is consumed. Support of this mechanism by the
   credit-control client is optional.
   
   For example, if the credit control client initializes a counter C for
   each of the received quota Q (C1 for Q1, C2 for Q2 ... Cn for Qn), the
   intermediate interrogation will be sent when (C1/Q1 + C1/Q2 + ... +
   Cn/Qn)>= 1. 
   
   Continuing the example, the end user uses 10 Mbytes from Rating-Group
   1 and 10minutes from Rating-Group 2. This means that Rating-Group 1
   consumed 50% of the reservation and Rating-Group 2 consumed the
   remaining 50%. 0.5 + 0.5 >=1, so the credit control client sends an
   intermediate interrogation to report the used units and request new
   ones.

Best Regards,
Chris.

------_=_NextPart_001_01C3C64E.765EE98A-- From owner-aaa-wg@merit.edu Fri Dec 19 17:06:26 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29705 for ; Fri, 19 Dec 2003 17:06:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E198B912C5; Fri, 19 Dec 2003 17:05:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AAFC1912C8; Fri, 19 Dec 2003 17:05:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1F50F912C5 for ; Fri, 19 Dec 2003 17:05:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0CA715DE40; Fri, 19 Dec 2003 17:05:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id 9CE8C5DE24 for ; Fri, 19 Dec 2003 17:05:05 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBJM53W07593 for ; Fri, 19 Dec 2003 14:05:03 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Dec 2003 16:05:03 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8D13@zrc2c012.us.nortel.com> From: "Christopher Richards" To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC: Result-Code AVP in G-S-U Date: Fri, 19 Dec 2003 16:03:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C67B.E6A5F9E0" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3C67B.E6A5F9E0 Content-Type: text/plain Hello All, Currently, the Result-Code AVP has the scope of the overall session. However, with multiple quotas per CCA, where the credit-control server may allow or deny usage to rating groups independently, there is a need to have a per Granted-Service-Unit Result-Code AVP. For example a user may request two quotas for two different services or rating groups. The credit-control server, may issue quota for one of them but deny the other. In the denied G-S-U AVP, we would expect to find the following fields:- Result-Code, Rating-Group and Final-Unit-Indication. I propose changing the G-S-U AVP from: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] [ Final-Unit-Indication ] To: Granted-Service-Unit ::= < AVP Header: 431 > { Result-Code } [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] [ Final-Unit-Indication ] Best Regards, Chris. ------_=_NextPart_001_01C3C67B.E6A5F9E0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable [AAA-WG]: DCC: Result-Code AVP in G-S-U

Hello All,

Currently, the Result-Code AVP has the scope of the = overall session. However, with multiple quotas per CCA, where the = credit-control server may allow or deny usage to rating groups = independently, there is a need to have a per Granted-Service-Unit = Result-Code AVP.

For example a user may request two quotas for two = different services or rating groups. The credit-control server, may = issue quota for one of them but deny the other. In the denied G-S-U = AVP, we would expect to find the following fields:- Result-Code, = Rating-Group and Final-Unit-Indication.

 
I propose changing the G-S-U AVP from:

         = Granted-Service-Unit ::=3D < AVP Header: 431 >
          &nb= sp;           &nb= sp;           [ = Tariff-Time-Change ]  
          &nb= sp;           &nb= sp;           [ = CC-Time ]
          &nb= sp;           &nb= sp;           [ = CC-Money ]  
          &nb= sp;           &nb= sp;           [ = CC-Total-Octets ]
          &nb= sp;           &nb= sp;           [ = CC-Input-Octets ]
          &nb= sp;           &nb= sp;           [ = CC-Output-Octets ]
          &nb= sp;           &nb= sp;           [ = CC-Service-Specific-Units ]
          &nb= sp;           &nb= sp;          *[ = Service-Identifier ]
          &nb= sp;           &nb= sp;           [ = Rating-Group ]
          &nb= sp;           &nb= sp;           [ = Final-Unit-Indication ]

To:
         = Granted-Service-Unit ::=3D < AVP Header: 431 >
          &nb= sp;           &nb= sp;           { = Result-Code }
          &nb= sp;           &nb= sp;           [ = Tariff-Time-Change ]  
          &nb= sp;           &nb= sp;           [ = CC-Time ]
          &nb= sp;           &nb= sp;           [ = CC-Money ]  
          &nb= sp;           &nb= sp;           [ = CC-Total-Octets ]
          &nb= sp;           &nb= sp;           [ = CC-Input-Octets ]
          &nb= sp;           &nb= sp;           [ = CC-Output-Octets ]
          &nb= sp;           &nb= sp;           [ = CC-Service-Specific-Units ]
          &nb= sp;           &nb= sp;          *[ = Service-Identifier ]
          &nb= sp;           &nb= sp;           [ = Rating-Group ]
          &nb= sp;           &nb= sp;           [ = Final-Unit-Indication ]


Best Regards,
Chris.

------_=_NextPart_001_01C3C67B.E6A5F9E0-- From owner-aaa-wg@merit.edu Fri Dec 19 20:08:51 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06747 for ; Fri, 19 Dec 2003 20:08:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7560E912D2; Fri, 19 Dec 2003 20:08:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A865912D3; Fri, 19 Dec 2003 20:08:38 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A72E2912D2 for ; Fri, 19 Dec 2003 20:08:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7CB5F5DE3D; Fri, 19 Dec 2003 20:08:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id E2B4D5DE4D for ; Fri, 19 Dec 2003 20:08:35 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBK17o725403; Fri, 19 Dec 2003 17:07:50 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Dec 2003 19:07:51 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8D19@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'marco.stura@nokia.com'" , aaa-wg@merit.edu Cc: Benni.Alexander@nokia.com, harri.hakala@ericsson.com, john.loughney@nokia.com, juha-pekka.koskinen@nokia.com, Karl-Heinz.Nenner@t-mobile.de, patrik.teppo@ericsson.com, leena.mattila@ericsson.com Subject: [AAA-WG]: RE: Issue: Free-of-charge & deny semantic for multiple services i n one user session Date: Fri, 19 Dec 2003 19:07:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C695.B02463EC" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3C695.B02463EC Content-Type: text/plain Hi Marco, With respect to denied quotas, I'd like to suggest the inclusion of a G-S-U Result-Code AVP and Final-Indication AVP as outlined in previous emails. In fact, the inclusion of both these AVPs in the G-S-U makes sense for granted as well as denied quota. I have a couple of questions regarding the free-of-charge indication: Should the client track the use of the free-of-charge resources and report them to the CC server? Should AAA accounting track these values? To me, whether a Rating-Group or Service-Identifier(s) associated with a G-S-U is "free" is really a function of how the users account is charged for the use. In other words, any Rating-Group or Service-Identifier(s) can be free - even if they are tracked and reported --- it is up to the charging system to decide how this translates into deductions or additions from a users account. I'm not sure what advantages a 'special' G-S-U for free rated quota will bring. It only creates more questions about interactions with other accounting functions which the NAS should not be interested in. Best Regards, Chris. -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Friday, December 05, 2003 8:22 AM To: aaa-wg@merit.edu Cc: Benni.Alexander@nokia.com; Richards, Christopher [RICH2:2Q40:EXCH]; harri.hakala@ericsson.com; john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; Karl-Heinz.Nenner@t-mobile.de; patrik.teppo@ericsson.com; leena.mattila@ericsson.com Subject: Issue: Free-of-charge & deny semantic for multiple services in one user session Free-of-charge & deny semantic for multiple services in one user session Submitter name: Marco Stura Submitter email address: marco.stura@nokia.com Date first submitted: 5.11.2003 Reference: Document: Diameter CCA-01 Comment type: T Priority: 2 Section: Rationale/Explanation of issue: The DCC application support for multiple services in one user session, one single credit control session can be used to request and grant multiple quotas to a set of end-user services. However, one or more of the services requested in one Credit-Control-Request may end-up to be free-of-charge or may be denied because of low credit. The DCC support only mechanisms to indicate this at CC session level, a semantic to indicate free-of-charge or deny at quota level is needed for the support of multiple services in one user session. Proposed changed: Section 8.16 Granted-Service-Unit AVP ADD (at the end of the second paragraph): A value of 0 (zero) granted service unit associated to a Service-Identifier(s) or Rating-Group indicates that the corresponding traffic MUST be denied. Note that in case the credit-control server want to disconnect the user and close the credit-control session, it SHOULD use the appropriate error code in the Credit-Control-Answer message rather than including n times the Granted-Service-Units AVPs with the value of 0 (zero). In contrast, a value of max type granted service unit (e.g. max Unsigned 32 is FFFFFFFF) associated to a Service-Identifier(s) or Rating-Group indicates that the corresponding traffic is free-of-charge. With unit type money, the value of the Exponent AVP is set to 0 (zero) when free-of-charge is indicated. With unit type service specific, the value of the CC-Service-Specific-Units AVP is set to FFFFFFFF to indicate free-of-charge. ------_=_NextPart_001_01C3C695.B02463EC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Issue: Free-of-charge & deny semantic for multiple = services in one user session

Hi Marco,

With respect to denied quotas, I'd like to suggest = the inclusion of a G-S-U Result-Code AVP and Final-Indication AVP as = outlined in previous emails.

In fact, the inclusion of both these AVPs in the = G-S-U makes sense for granted as well as denied quota.

I have a couple of questions regarding the = free-of-charge indication:
Should the client track the use of the = free-of-charge resources and report them to the CC server?
Should AAA accounting track these values?

To me, whether a Rating-Group or = Service-Identifier(s) associated with a G-S-U is "free" is = really a function of how the users account is charged for the use. In = other words, any Rating-Group or Service-Identifier(s) can be free - = even if they are tracked and reported --- it is up to the charging = system to decide how this translates into deductions or additions from = a users account.

I'm not sure what advantages a 'special' G-S-U for = free rated quota will bring. It only creates more questions about = interactions with other accounting functions which the NAS should not = be interested in.

Best Regards,
Chris.

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: Friday, December 05, 2003 8:22 AM
To: aaa-wg@merit.edu
Cc: Benni.Alexander@nokia.com; Richards, Christopher = [RICH2:2Q40:EXCH]; harri.hakala@ericsson.com; john.loughney@nokia.com; = juha-pekka.koskinen@nokia.com; Karl-Heinz.Nenner@t-mobile.de; = patrik.teppo@ericsson.com; leena.mattila@ericsson.com

Subject: Issue: Free-of-charge & deny semantic = for multiple services in one user session


Free-of-charge & deny semantic for multiple = services in one user session
Submitter name: Marco Stura
Submitter email address: = marco.stura@nokia.com
Date first submitted: 5.11.2003
Reference:
Document: Diameter CCA-01
Comment type: T
Priority: 2
Section:
Rationale/Explanation of issue:

The DCC application support for multiple services in = one user session, one single credit control session can be used to = request and grant multiple quotas to a set of end-user services. = However, one or more of the services requested in one = Credit-Control-Request may end-up to be free-of-charge or may be denied = because of low credit. The DCC support only mechanisms to indicate this = at CC session level, a semantic to indicate free-of-charge or deny at = quota level is needed for the support of multiple services in one user = session.

Proposed changed:

Section 8.16 Granted-Service-Unit AVP
ADD (at the end of the second paragraph):
A value of 0 (zero) granted service unit associated = to a Service-Identifier(s) or Rating-Group indicates that the = corresponding traffic MUST be denied. Note that in case the = credit-control

server want to disconnect the user and close the = credit-control session, it SHOULD use the
appropriate error code in the Credit-Control-Answer = message rather than including n times the Granted-Service-Units AVPs = with the value of  0 (zero).

In contrast, a value of max type granted service unit = (e.g. max Unsigned 32 is FFFFFFFF)
associated to a Service-Identifier(s) or = Rating-Group indicates that the corresponding traffic
is free-of-charge. With unit type money, the value = of the Exponent AVP is set to 0 (zero) when
free-of-charge is indicated. With unit type service = specific, the value of the CC-Service-Specific-Units AVP is set to = FFFFFFFF to indicate free-of-charge.




------_=_NextPart_001_01C3C695.B02463EC-- From aaa-admin@ietf.org Fri Dec 19 21:05:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08186 for ; Fri, 19 Dec 2003 21:05:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXWUJ-0005UI-8Y; Fri, 19 Dec 2003 21:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXWTo-0005TU-6W for aaa@optimus.ietf.org; Fri, 19 Dec 2003 21:04:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08151 for ; Fri, 19 Dec 2003 21:04:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXWTl-0004PV-00 for aaa@ietf.org; Fri, 19 Dec 2003 21:04:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXWTk-0004PO-00 for aaa@ietf.org; Fri, 19 Dec 2003 21:04:29 -0500 Received: from host217-37-244-182.in-addr.btopenworld.com ([217.37.244.182] helo=host81-137-143-121.in-addr.btopenworld.com) by ietf-mx with smtp (Exim 4.12) id 1AXWTk-0004PL-00; Fri, 19 Dec 2003 21:04:28 -0500 Received: from [148.62.249.225] by host81-137-143-121.in-addr.btopenworld.com id <2122618-54610> for ; Sat, 20 Dec 2003 18:59:14 -0500 Message-ID: <04$pi075$d7j@9km.3eh.ltnnj> From: "Teresa Dalton" Reply-To: "Teresa Dalton" To: , , , Date: Sat, 20 Dec 03 18:59:14 GMT X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="6_10_22DDA.1_.1" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.8 required=5.0 tests=ALL_NATURAL, DATE_IN_PAST_03_06,DATE_SPAMWARE_Y2K,FORGED_YAHOO_RCVD,HTML_30_40, HTML_IMAGE_ONLY_04,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME, SUBJ_GUARANTEED autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 2.4 SUBJ_GUARANTEED Subject GUARANTEED * 1.3 ALL_NATURAL BODY: Spam is 100% natural?! * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.7 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't Subject: [Aaa] guaranteed Weight loss program wkeiq a adkh Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , --6_10_22DDA.1_.1 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Sick of fad diets? Get the solution that millions of others have, procitravin. Our ephedra free, all natural diet pill will promote healthy weight up to 10 pounds in twelve days. If it doesn't work you'll get a full refund.

http://www.procitravin= com/index15.html

tecottonseed kmmcznjaxucbplayyzmoc --6_10_22DDA.1_.1-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Fri Dec 19 21:05:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08202 for ; Fri, 19 Dec 2003 21:05:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXWUX-0005Vk-K8 for aaa-archive@odin.ietf.org; Fri, 19 Dec 2003 21:05:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBK25HtE021180 for aaa-archive@odin.ietf.org; Fri, 19 Dec 2003 21:05:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXWUX-0005VW-GH for aaa-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 21:05:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08178 for ; Fri, 19 Dec 2003 21:05:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXWUT-0004Qd-00 for aaa-web-archive@ietf.org; Fri, 19 Dec 2003 21:05:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXWUT-0004Qa-00 for aaa-web-archive@ietf.org; Fri, 19 Dec 2003 21:05:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXWUJ-0005UI-8Y; Fri, 19 Dec 2003 21:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXWTo-0005TU-6W for aaa@optimus.ietf.org; Fri, 19 Dec 2003 21:04:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08151 for ; Fri, 19 Dec 2003 21:04:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXWTl-0004PV-00 for aaa@ietf.org; Fri, 19 Dec 2003 21:04:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXWTk-0004PO-00 for aaa@ietf.org; Fri, 19 Dec 2003 21:04:29 -0500 Received: from host217-37-244-182.in-addr.btopenworld.com ([217.37.244.182] helo=host81-137-143-121.in-addr.btopenworld.com) by ietf-mx with smtp (Exim 4.12) id 1AXWTk-0004PL-00; Fri, 19 Dec 2003 21:04:28 -0500 Received: from [148.62.249.225] by host81-137-143-121.in-addr.btopenworld.com id <2122618-54610> for ; Sat, 20 Dec 2003 18:59:14 -0500 Message-ID: <04$pi075$d7j@9km.3eh.ltnnj> From: "Teresa Dalton" Reply-To: "Teresa Dalton" To: , , , Date: Sat, 20 Dec 03 18:59:14 GMT X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="6_10_22DDA.1_.1" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.8 required=5.0 tests=ALL_NATURAL, DATE_IN_PAST_03_06,DATE_SPAMWARE_Y2K,FORGED_YAHOO_RCVD,HTML_30_40, HTML_IMAGE_ONLY_04,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME, SUBJ_GUARANTEED autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 2.4 SUBJ_GUARANTEED Subject GUARANTEED * 1.3 ALL_NATURAL BODY: Spam is 100% natural?! * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.7 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't Subject: [Aaa] guaranteed Weight loss program wkeiq a adkh Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , --6_10_22DDA.1_.1 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Sick of fad diets? Get the solution that millions of others have, procitravin. Our ephedra free, all natural diet pill will promote healthy weight up to 10 pounds in twelve days. If it doesn't work you'll get a full refund.

http://www.procitravin= com/index15.html

tecottonseed kmmcznjaxucbplayyzmoc --6_10_22DDA.1_.1-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Sat Dec 20 03:35:42 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00223 for ; Sat, 20 Dec 2003 03:35:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0868C912D6; Sat, 20 Dec 2003 03:35:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B38BD912D7; Sat, 20 Dec 2003 03:35:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7511C912D6 for ; Sat, 20 Dec 2003 03:35:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 636F45DE3B; Sat, 20 Dec 2003 03:35:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from hotmail.com (law10-f108.law10.hotmail.com [64.4.15.108]) by segue.merit.edu (Postfix) with ESMTP id 1D9FD5DDB8 for ; Sat, 20 Dec 2003 03:35:21 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 20 Dec 2003 00:35:20 -0800 Received: from 62.10.91.218 by lw10fd.law10.hotmail.msn.com with HTTP; Sat, 20 Dec 2003 08:35:20 GMT X-Originating-IP: [62.10.91.218] X-Originating-Email: [marco_stura@hotmail.com] X-Sender: marco_stura@hotmail.com From: "Stura Marco" To: crich@nortelnetworks.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: credit pooling in flow X Date: Sat, 20 Dec 2003 10:35:20 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Dec 2003 08:35:20.0500 (UTC) FILETIME=[340ADF40:01C3C6D4] Sender: owner-aaa-wg@merit.edu Precedence: bulk >My concern is that this method of summing the quota use should be clearly >stated as an implementation choice and not a mechanism that is mandated by >the DCC client. >The mechanism outlined has some pitfalls and there are other mechanisms of >implementing credit sharing. My concern Chris is that you didn't understand how the mechanism outlined in FlowX works since we are not summing the quotas. Also, if everybody does what He wants in server (to allocate credit and calculate quotas) and client (to decide when to report) a. we'll never achieve interoperability that is the main reason why standards exist and b. the service provider will risk negative credit or the user will not be charged as expected. I would suggest you better analyse the approach and you will see that the client report when C1*R1+C2*R2+...+Cn*Rn>=a*Money Reservation. Where C1, C2,...,Cn are the counters for each of the services running for the users, R1 etc. are the rating parameters and a is a security factor to ensure that the money reservation is never exceeded. And yes there is one pitfall, this approach assume linear rating and doesn't consider e.g. models where some discount is applied upon some event, for instance you have generated 10MB of traffic using service 1,2 and 3 then you get 30% discount on these services. A solution to this pitfall could to be worked out during WGLC. Br Marco _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From owner-aaa-wg@merit.edu Sat Dec 20 04:03:54 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02568 for ; Sat, 20 Dec 2003 04:03:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D3F5E912D7; Sat, 20 Dec 2003 04:03:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 952BF912D8; Sat, 20 Dec 2003 04:03:38 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 43054912D7 for ; Sat, 20 Dec 2003 04:03:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 232F35DE47; Sat, 20 Dec 2003 04:03:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from hotmail.com (law10-f41.law10.hotmail.com [64.4.15.41]) by segue.merit.edu (Postfix) with ESMTP id C253B5DDD1 for ; Sat, 20 Dec 2003 04:03:35 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 20 Dec 2003 01:03:35 -0800 Received: from 62.10.91.218 by lw10fd.law10.hotmail.msn.com with HTTP; Sat, 20 Dec 2003 09:03:34 GMT X-Originating-IP: [62.10.91.218] X-Originating-Email: [marco_stura@hotmail.com] X-Sender: marco_stura@hotmail.com From: "Stura Marco" To: crich@nortelnetworks.com Cc: harri.hakala@ericsson.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: credit pooling in flow X Date: Sat, 20 Dec 2003 11:03:34 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Dec 2003 09:03:35.0257 (UTC) FILETIME=[26324490:01C3C6D8] Sender: owner-aaa-wg@merit.edu Precedence: bulk >As for the pitfalls of the described mechanism, I see the following:- > >* If a number of quotas are currently in use, but not being actively >used (or only used a little or just one of them is being used), it will >take >some time to trigger a re-authorisation. There is one credit reservation and the server grant quotas allocating all reserved money to all the services. If we reserve an amount of money M the server grants quotas to the services the following way: Q1=M/R1, Q2=M/R2,......, Qn=M/Rn (i.e. no credit fragmentation) Where R1 etc are the rating parameters. The client inizialize counters for each of the services and report when: C1/Q1+C2/Q2+......+Cn/Qn>=1 (or a*1), where a is a security factor to ensure that M is never exceeded. This equation is running in the client, no matter what is the service that consume the reserved credit M (i.e. no credit fragmentation). The reasons why this is a good mechanism are: 1- the signalling load is optimized because the client report only when really needed. 2- the credit management is simplified because you don't need to guess what services the user is effectively using and how much (i.e. a user may have subscription to 20 different services but may use only 3 of them during a user's session, which one? how the server slice the reserved credit among all the possible subscribed services? M/20 or...? ) 3- there is absolutely no credit fragmentation. >* All user service may be interrupted if all quotas are required to be >re-authorised - even though the quotas have resources remaining. If you better look the the DCC mechanisms there is no service interruption while credit re-authorization is executed. No pitfall here. >* It is not very deterministic. If a quota is allocated for some >resource amount, re-authorisation (& service interruption) is performed >based on the use of all the allocated quotas. Again, there is no service interruption when credit re-authorization is performed. It is deterministic because what you care of is that the reserved money is not exceeded, and since you report when C1*R1+C2*R2+...+Cn*Rn>=a*M it is deterministic that you never exceed the reservation. No pitfall here. The real pitfall, if you understand the mechanism, but it appears you don't, is that this mechanism assume linear rating. We need to work out a solution to this. Br Marco P.S.: and if you are concerned about IPR issues I'm not aware of any IPR on this approach. _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus From owner-aaa-wg@merit.edu Sat Dec 20 04:21:07 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02813 for ; Sat, 20 Dec 2003 04:21:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0D23C912D8; Sat, 20 Dec 2003 04:20:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC995912D9; Sat, 20 Dec 2003 04:20:52 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E1EE912D8 for ; Sat, 20 Dec 2003 04:20:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7ABB85DE47; Sat, 20 Dec 2003 04:20:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from hotmail.com (law10-f123.law10.hotmail.com [64.4.15.123]) by segue.merit.edu (Postfix) with ESMTP id 29CC85DD9B for ; Sat, 20 Dec 2003 04:20:51 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 20 Dec 2003 01:20:50 -0800 Received: from 62.10.91.218 by lw10fd.law10.hotmail.msn.com with HTTP; Sat, 20 Dec 2003 09:20:50 GMT X-Originating-IP: [62.10.91.218] X-Originating-Email: [marco_stura@hotmail.com] X-Sender: marco_stura@hotmail.com From: "Stura Marco" To: crich@nortelnetworks.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Result-Code AVP in G-S-U Date: Sat, 20 Dec 2003 11:20:50 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Dec 2003 09:20:50.0507 (UTC) FILETIME=[8F40E1B0:01C3C6DA] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Chris, I think before continue any such discussions it would be good if you clarify with a concrete and clear example what is your credit allocation strategy and your client reporting strategy, what is the resulting signaling load, client logic and credit management complexity your solution would create. I'm concerned that until you don't address the above mentioned issues we are completely stuck in an endless discussion. Br Marco >From: "Christopher Richards" >To: aaa-wg@merit.edu >Subject: [AAA-WG]: DCC: Result-Code AVP in G-S-U >Date: Fri, 19 Dec 2003 16:03:14 -0600 > >Hello All, > >Currently, the Result-Code AVP has the scope of the overall session. >However, with multiple quotas per CCA, where the credit-control server may >allow or deny usage to rating groups independently, there is a need to have >a per Granted-Service-Unit Result-Code AVP. > >For example a user may request two quotas for two different services or >rating groups. The credit-control server, may issue quota for one of them >but deny the other. In the denied G-S-U AVP, we would expect to find the >following fields:- Result-Code, Rating-Group and Final-Unit-Indication. > >I propose changing the G-S-U AVP from: > > Granted-Service-Unit ::= < AVP Header: 431 > > [ Tariff-Time-Change ] > [ CC-Time ] > [ CC-Money ] > [ CC-Total-Octets ] > [ CC-Input-Octets ] > [ CC-Output-Octets ] > [ CC-Service-Specific-Units ] > *[ Service-Identifier ] > [ Rating-Group ] > [ Final-Unit-Indication ] > >To: > Granted-Service-Unit ::= < AVP Header: 431 > > { Result-Code } > [ Tariff-Time-Change ] > [ CC-Time ] > [ CC-Money ] > [ CC-Total-Octets ] > [ CC-Input-Octets ] > [ CC-Output-Octets ] > [ CC-Service-Specific-Units ] > *[ Service-Identifier ] > [ Rating-Group ] > [ Final-Unit-Indication ] > > >Best Regards, >Chris. _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus From aaa-admin@ietf.org Sat Dec 20 21:32:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28604 for ; Sat, 20 Dec 2003 21:32:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXtNx-0001Ws-Pw; Sat, 20 Dec 2003 21:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXtNF-0001WM-AN for aaa@optimus.ietf.org; Sat, 20 Dec 2003 21:31:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28568 for ; Sat, 20 Dec 2003 21:31:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXtNC-0000Rk-00 for aaa@ietf.org; Sat, 20 Dec 2003 21:31:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXtNB-0000Rc-00 for aaa@ietf.org; Sat, 20 Dec 2003 21:31:14 -0500 Received: from [216.139.101.160] (helo=R-RPK71LIQKKR8F) by ietf-mx with smtp (Exim 4.12) id 1AXtN8-0000RI-00; Sat, 20 Dec 2003 21:31:12 -0500 Received: from [184.87.108.34] by R-RPK71LIQKKR8F with ESMTP id DAC485A29EC for ; Sun, 21 Dec 2003 20:30:57 -0400 Message-ID: <8s--$9$$w46l3t-rr91u93o13z60@87l.1mt7> From: "Marissa Mejia" Reply-To: "Marissa Mejia" To: sipping-emergency-admin@ietf.org Cc: , Date: Sun, 21 Dec 03 20:30:57 GMT X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="F__3E3.9D5.1909E" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=19.2 required=5.0 tests=ALL_NATURAL, DATE_IN_PAST_03_06,DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,FROM_ENDS_IN_NUMS,HTML_40_50, HTML_IMAGE_ONLY_04,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,USERPASS autolearn=no version=2.60 X-Spam-Report: * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.3 ALL_NATURAL BODY: Spam is 100% natural?! * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 3.1 USERPASS URI: URL contains username and (optional) password * 0.7 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Subject: [Aaa] re; All natural weight loss products that works :) :) Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , --F__3E3.9D5.1909E Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


Take your low carb diet to a new level. With all natural ProCitravin you'l= l lose an additional 10 pounds every 12 days or your money back!

http://ww= w.procitravin.com/index14.html

Thanks, Joe
invertebrate --F__3E3.9D5.1909E-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sat Dec 20 21:32:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28622 for ; Sat, 20 Dec 2003 21:32:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXtO4-0001Xr-VB for aaa-archive@odin.ietf.org; Sat, 20 Dec 2003 21:32:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBL2W81m005935 for aaa-archive@odin.ietf.org; Sat, 20 Dec 2003 21:32:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXtO4-0001Xe-Ot for aaa-web-archive@optimus.ietf.org; Sat, 20 Dec 2003 21:32:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28595 for ; Sat, 20 Dec 2003 21:32:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXtO2-0000Tc-00 for aaa-web-archive@ietf.org; Sat, 20 Dec 2003 21:32:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXtO1-0000TZ-00 for aaa-web-archive@ietf.org; Sat, 20 Dec 2003 21:32:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXtNx-0001Ws-Pw; Sat, 20 Dec 2003 21:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXtNF-0001WM-AN for aaa@optimus.ietf.org; Sat, 20 Dec 2003 21:31:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28568 for ; Sat, 20 Dec 2003 21:31:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXtNC-0000Rk-00 for aaa@ietf.org; Sat, 20 Dec 2003 21:31:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXtNB-0000Rc-00 for aaa@ietf.org; Sat, 20 Dec 2003 21:31:14 -0500 Received: from [216.139.101.160] (helo=R-RPK71LIQKKR8F) by ietf-mx with smtp (Exim 4.12) id 1AXtN8-0000RI-00; Sat, 20 Dec 2003 21:31:12 -0500 Received: from [184.87.108.34] by R-RPK71LIQKKR8F with ESMTP id DAC485A29EC for ; Sun, 21 Dec 2003 20:30:57 -0400 Message-ID: <8s--$9$$w46l3t-rr91u93o13z60@87l.1mt7> From: "Marissa Mejia" Reply-To: "Marissa Mejia" To: sipping-emergency-admin@ietf.org Cc: , Date: Sun, 21 Dec 03 20:30:57 GMT X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="F__3E3.9D5.1909E" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=19.2 required=5.0 tests=ALL_NATURAL, DATE_IN_PAST_03_06,DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,FROM_ENDS_IN_NUMS,HTML_40_50, HTML_IMAGE_ONLY_04,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,USERPASS autolearn=no version=2.60 X-Spam-Report: * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.3 ALL_NATURAL BODY: Spam is 100% natural?! * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 3.1 USERPASS URI: URL contains username and (optional) password * 0.7 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Subject: [Aaa] re; All natural weight loss products that works :) :) Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , --F__3E3.9D5.1909E Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


Take your low carb diet to a new level. With all natural ProCitravin you'l= l lose an additional 10 pounds every 12 days or your money back!

http://ww= w.procitravin.com/index14.html

Thanks, Joe
invertebrate --F__3E3.9D5.1909E-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Mon Dec 22 11:12:52 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23531 for ; Mon, 22 Dec 2003 11:12:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5B93891239; Mon, 22 Dec 2003 11:12:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 276889123A; Mon, 22 Dec 2003 11:12:40 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5488F91239 for ; Mon, 22 Dec 2003 11:12:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 43A9E5DE73; Mon, 22 Dec 2003 11:12:38 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id 05BB55DE67 for ; Mon, 22 Dec 2003 11:12:38 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBMG8pC02154; Mon, 22 Dec 2003 10:08:51 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Dec 2003 10:08:51 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8D1C@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'Stura Marco'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: credit pooling in flow X Date: Mon, 22 Dec 2003 10:08:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C8A5.E2BC34D0" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3C8A5.E2BC34D0 Content-Type: text/plain Hi Marco, Thanks for your reply. As I said, the mechanism outlined is summing the quota *use*. I guess I should have clarified that by saying "summing the fractional quota use". One scenario I was trying to explain was: Assume Q1 is heavily used and has a relatively large quota. So: C1/Q1 = 0.5. And C2/Q2 + C3/Q3 + C4/Q4 + .... Cn/Qn = ~0.1 (Due to little active use), the quotas will not be re-authorised, even though credit has been fragmented between them until the single heavy user (Q1) is exhausted. My third point ("It is not very deterministic"): I was trying to point out that it is very difficult to determine when quota re-authorisation will occur for a particular quota, since it depends on the quota size and quota use of other unrelated quotas. Whether a DCC client vendor wants to implement this mechanism as opposed to others is outside the scope of the DCC specification. But it should be marked as that - implementation choice. And as such, there should be no requirement (And there is no need) that a DCC server assumes that a DCC client is following this choice. That is where inter-operability issues arise. But since there is no reason why a DCC server should assume exactly how a DCC client is tracking re-authorisation limits, using this or any other mechanism will pose no inter-op issues. I'm curious about your statement that: > Also, if everybody does what > He wants in server (to allocate credit and calculate quotas) and client (to decide > when to report) a. we'll never achieve interoperability that is the main reason > why standards exist and b. the service provider will risk negative credit or the > user will not be charged as expected. I'd have thought that not implicitly tying a server implementation to a client implementation would make the solution more inter-operable. Not the other way! Best Regards, Chris. -----Original Message----- From: Stura Marco [mailto:marco_stura@hotmail.com] Sent: Saturday, December 20, 2003 2:35 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: credit pooling in flow X >My concern is that this method of summing the quota use should be >clearly stated as an implementation choice and not a mechanism that is >mandated by the DCC client. The mechanism outlined has some pitfalls >and there are other mechanisms of implementing credit sharing. My concern Chris is that you didn't understand how the mechanism outlined in FlowX works since we are not summing the quotas. Also, if everybody does what He wants in server (to allocate credit and calculate quotas) and client (to decide when to report) a. we'll never achieve interoperability that is the main reason why standards exist and b. the service provider will risk negative credit or the user will not be charged as expected. I would suggest you better analyse the approach and you will see that the client report when C1*R1+C2*R2+...+Cn*Rn>=a*Money Reservation. Where C1, C2,...,Cn are the counters for each of the services running for the users, R1 etc. are the rating parameters and a is a security factor to ensure that the money reservation is never exceeded. And yes there is one pitfall, this approach assume linear rating and doesn't consider e.g. models where some discount is applied upon some event, for instance you have generated 10MB of traffic using service 1,2 and 3 then you get 30% discount on these services. A solution to this pitfall could to be worked out during WGLC. Br Marco _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 ------_=_NextPart_001_01C3C8A5.E2BC34D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCC: credit pooling in flow X

Hi Marco,

Thanks for your reply. As I said, the mechanism = outlined is summing the quota *use*. I guess I should have clarified = that by saying "summing the fractional quota use". =

One scenario I was trying to explain  = was:

Assume Q1 is heavily used and has a relatively large = quota. So: C1/Q1 =3D 0.5. And C2/Q2 + C3/Q3 + C4/Q4 + .... Cn/Qn =3D = ~0.1 (Due to little active use), the quotas will not be re-authorised, = even though credit has been fragmented between them until the single = heavy user (Q1) is exhausted.

My third point ("It is not very = deterministic"): I was trying to point out that it is very = difficult to determine when quota re-authorisation will occur for a = particular quota, since it depends on the quota size and quota use of = other unrelated quotas.

Whether a DCC client vendor wants to implement this = mechanism as opposed to others is outside the scope of the DCC = specification. But it should be marked as that - implementation choice. = And as such, there should be no requirement (And there is no need) that = a DCC server assumes that a DCC client is following this choice. That = is where inter-operability issues arise. But since there is no reason = why a DCC server should assume exactly how a DCC client is tracking = re-authorisation limits, using this or any other mechanism will pose no = inter-op issues.

I'm curious about your statement that:

> Also, if everybody does what
> He wants in server (to allocate credit and = calculate quotas) and client (to decide
> when to report) a. we'll never achieve = interoperability that is the main reason
> why standards exist and b. the service provider = will risk negative credit or the
> user will not be charged as expected.
 
I'd have thought that not implicitly tying a server = implementation to a client implementation would make the solution more = inter-operable. Not the other way!

Best Regards,
Chris.


-----Original Message-----
From: Stura Marco [mailto:marco_stura@hotmail.com]
Sent: Saturday, December 20, 2003 2:35 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; = aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: credit pooling in flow = X


>My concern is that this method of summing the = quota use should be
>clearly stated as an implementation choice and = not a mechanism that is
>mandated by the DCC client. The mechanism = outlined has some pitfalls
>and there are other mechanisms of implementing = credit sharing.

My concern Chris is that you didn't understand how = the mechanism outlined in FlowX works since we are not summing the = quotas. Also, if everybody does

what
He wants in server (to allocate credit and calculate = quotas) and client (to
decide
when to report) a. we'll never achieve = interoperability that is the main
reason
why standards exist and b. the service provider will = risk negative credit or
the
user will not be charged as expected.

I would suggest you better analyse the approach and = you will see that the
client
report when C1*R1+C2*R2+...+Cn*Rn>=3Da*Money = Reservation.
Where C1, C2,...,Cn are the counters for each of the = services running for
the users,
R1 etc. are the rating parameters and a is a = security factor to ensure that
the money
reservation is never exceeded.
And yes there is one pitfall, this approach assume = linear rating and doesn't
consider
e.g. models where some discount is applied upon some = event, for instance you
have
generated 10MB of traffic using service 1,2 and 3 = then you get 30% discount
on these
services. A solution to this pitfall could to be = worked out during WGLC.

Br
Marco

_______________________________________________________________= __
Protect your PC - get McAfee.com VirusScan Online =
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3D= 3963

------_=_NextPart_001_01C3C8A5.E2BC34D0-- From owner-aaa-wg@merit.edu Mon Dec 22 11:59:35 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25273 for ; Mon, 22 Dec 2003 11:59:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EBE349120D; Mon, 22 Dec 2003 11:59:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBC8391222; Mon, 22 Dec 2003 11:59:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE4589120D for ; Mon, 22 Dec 2003 11:59:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id AA1595DE67; Mon, 22 Dec 2003 11:59:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id 446ED5DE15 for ; Mon, 22 Dec 2003 11:59:17 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBMGxE406886; Mon, 22 Dec 2003 10:59:15 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Dec 2003 10:59:15 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8D1D@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'Stura Marco'" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Result-Code AVP in G-S-U Date: Mon, 22 Dec 2003 10:59:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C8AC.EE3DC8E4" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3C8AC.EE3DC8E4 Content-Type: text/plain Hi Marco, I'm using the assumptions that: - Quotas (G-S-U's) allow an amount of resource usage for a particular Rating-Group. - Multiple G-S-U AVPs may be returned in a single CCA. - The G-S-U resources for each Rating-Group are allocated independently of any others. - G-S-U resources may be requested by the client and allocated by the server at any point in a session. - Each G-S-U resource size (& unit) allocation is independent of any others. It is a function of the server. - A user may (probably will) use each resource at a different speed to others. It is not inconceivable that: - One G-S-U resource allocation in the client may be exhausted more quickly than another - Some event may happen that affects the "cost" of one G-S-U resource differently than another. Therefore, it seems that:- - The client may need to re-authorize G-S-U resource allocations independently. - The server may need to re-authorize & reallocate resources for each G-S-U independently. - The server may even deny one G-S-U resource while allowing others. - Deny actions for one G-S-U resource may be different from others. Given the above, it would appear that each G-S-U should contain enough information in it to enable the above functionality. As an example, a user may request two quotas for two different services or rating groups. The credit-control server, may issue quota for one of them but deny the other. In the allocated G-S-U AVP we would expect to find:- Result-Code (Success), unit allocation, Rating-Group. In the denied G-S-U AVP, we may expect to find the following fields:- Result-Code (Denied-Insufficient funds), Rating-Group and Final-Unit-Indication (Action: REDIRECT; Redirect-Server:...). The Result-Code allows the client to differentiate different success, denied & failure reasons for each G-S-U and potentially take different actions (In addition to the Final-Unit-Indication AVP action) depending on the reason. For example, here is first stab at a list of Result-Codes: Successful Auth of a new quota Successful Auth (Request return of other, idle quotas) Successful Re-auth for an existing quota Successful Re-auth (Request return of other, idle quotas) Denied - General Error (Terminate) Denied - Insufficient Funds (Request return of other, idle quotas) Denied - Too many quotas in use (Request return of idle quotas) Denied - Unknown Rating-Group requested Denied - Incompatible QoS Denied - Rate restricted from use for this session Marco, to help answer one of your other concerns in another email (Inter-operability between clients & servers), having the client and server be able to supply each other with more granular information helps ensure inter-operability. As I see it there are two ways to ensure inter-operability:- (1) Specify exactly how to handle every single event and case:- ensure that none are missed or incorrect. (2) Provide enough information to each element so that each element can take an informed decision. If you decide to choose (1), you'd better make sure that you've not missed any existing functionality, not made some incorrect assumptions and have thought of all reasonable future functionality. Good luck! Best Regards, Chris. -----Original Message----- From: Stura Marco [mailto:marco_stura@hotmail.com] Sent: Saturday, December 20, 2003 3:21 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Result-Code AVP in G-S-U Hi Chris, I think before continue any such discussions it would be good if you clarify with a concrete and clear example what is your credit allocation strategy and your client reporting strategy, what is the resulting signaling load, client logic and credit management complexity your solution would create. I'm concerned that until you don't address the above mentioned issues we are completely stuck in an endless discussion. Br Marco >From: "Christopher Richards" >To: aaa-wg@merit.edu >Subject: [AAA-WG]: DCC: Result-Code AVP in G-S-U >Date: Fri, 19 Dec 2003 16:03:14 -0600 > >Hello All, > >Currently, the Result-Code AVP has the scope of the overall session. >However, with multiple quotas per CCA, where the credit-control server >may allow or deny usage to rating groups independently, there is a need >to have a per Granted-Service-Unit Result-Code AVP. > >For example a user may request two quotas for two different services or >rating groups. The credit-control server, may issue quota for one of >them but deny the other. In the denied G-S-U AVP, we would expect to >find the following fields:- Result-Code, Rating-Group and >Final-Unit-Indication. > >I propose changing the G-S-U AVP from: > > Granted-Service-Unit ::= < AVP Header: 431 > > [ Tariff-Time-Change ] > [ CC-Time ] > [ CC-Money ] > [ CC-Total-Octets ] > [ CC-Input-Octets ] > [ CC-Output-Octets ] > [ CC-Service-Specific-Units ] > *[ Service-Identifier ] > [ Rating-Group ] > [ Final-Unit-Indication ] > >To: > Granted-Service-Unit ::= < AVP Header: 431 > > { Result-Code } > [ Tariff-Time-Change ] > [ CC-Time ] > [ CC-Money ] > [ CC-Total-Octets ] > [ CC-Input-Octets ] > [ CC-Output-Octets ] > [ CC-Service-Specific-Units ] > *[ Service-Identifier ] > [ Rating-Group ] > [ Final-Unit-Indication ] > > >Best Regards, >Chris. _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus ------_=_NextPart_001_01C3C8AC.EE3DC8E4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCC: Result-Code AVP in G-S-U

Hi Marco,

I'm using the assumptions that:
- Quotas (G-S-U's) allow an amount of resource usage = for a particular Rating-Group.
- Multiple G-S-U AVPs may be returned in a single = CCA.
- The G-S-U resources for each Rating-Group are = allocated independently of any others.
- G-S-U resources may be requested by the client and = allocated by the server at any point in a session.
- Each G-S-U resource size (& unit) allocation = is independent of any others. It is a function of the server.
- A user may (probably will) use each resource at a = different speed to others.

It is not inconceivable that:
- One G-S-U resource allocation in the client may be = exhausted more quickly than another
- Some event may happen that affects the = "cost" of one G-S-U resource differently than another.

Therefore, it seems that:-
- The client may need to re-authorize G-S-U resource = allocations independently.
- The server may need to re-authorize & = reallocate resources for each G-S-U independently.
- The server may even deny one G-S-U resource while = allowing others.
- Deny actions for one G-S-U resource may be = different from others.

Given the above, it would appear that each G-S-U = should contain enough information in it to enable the above = functionality.

As an example, a user may request two quotas for two = different services or rating groups.
The credit-control server, may issue quota for one = of them but deny the other.
In the allocated G-S-U AVP we would expect to find:- = Result-Code (Success), unit allocation, Rating-Group.
In the denied G-S-U AVP, we may expect to find the = following fields:- Result-Code (Denied-Insufficient funds), = Rating-Group and Final-Unit-Indication (Action: REDIRECT; = Redirect-Server:...).

The Result-Code allows the client to differentiate = different success, denied & failure reasons for each G-S-U and = potentially take different actions (In addition to the = Final-Unit-Indication AVP action) depending on the reason.

For example, here is first stab at a list of = Result-Codes:
        Successful Auth of a new quota
        Successful Auth (Request return of other, idle quotas)
        Successful Re-auth for an existing quota
        Successful Re-auth (Request return of other, idle = quotas)
        Denied - = General Error (Terminate)
        Denied - = Insufficient Funds (Request return of other, idle quotas)
        Denied - = Too many quotas in use (Request return of idle quotas)
        Denied - = Unknown Rating-Group requested
        Denied - = Incompatible QoS
        Denied - = Rate restricted from use for this session


Marco, to help answer one of your other concerns in = another email (Inter-operability between clients & servers), having = the client and server be able to supply each other with more granular = information helps ensure inter-operability. As I see it there are two = ways to ensure inter-operability:-

(1) Specify exactly how to handle every single event = and case:- ensure that none are missed or incorrect.
(2) Provide enough information to each element so = that each element can take an informed decision.

If you decide to choose (1), you'd better make sure = that you've not missed any existing functionality, not made some = incorrect assumptions and have thought of all reasonable future = functionality. Good luck!

Best Regards,
Chris.


-----Original Message-----
From: Stura Marco [mailto:marco_stura@hotmail.com]
Sent: Saturday, December 20, 2003 3:21 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: Result-Code AVP in = G-S-U


Hi Chris,

I think before continue any such discussions it would = be good if you clarify with a concrete and clear example what is your = credit allocation strategy and your client reporting strategy, what is = the resulting signaling load, client logic and credit management = complexity your solution would create.

I'm concerned that until you don't address the above = mentioned issues we are completely stuck  in an endless = discussion.

Br
Marco


>From: "Christopher Richards" = <crich@nortelnetworks.com>
>To: aaa-wg@merit.edu
>Subject: [AAA-WG]: DCC: Result-Code AVP in = G-S-U
>Date: Fri, 19 Dec 2003 16:03:14 -0600
>
>Hello All,
>
>Currently, the Result-Code AVP has the scope of = the overall session.
>However, with multiple quotas per CCA, where the = credit-control server
>may allow or deny usage to rating groups = independently, there is a need
>to have a per Granted-Service-Unit Result-Code = AVP.
>
>For example a user may request two quotas for = two different services or
>rating groups. The credit-control server, may = issue quota for one of
>them but deny the other. In the denied G-S-U = AVP, we would expect to
>find the following fields:- Result-Code, = Rating-Group and
>Final-Unit-Indication.
>
>I propose changing the G-S-U AVP from:
>
>          = Granted-Service-Unit ::=3D < AVP Header: 431 >
>          = ;            = ;            = ; [ Tariff-Time-Change ]
>          = ;            = ;            = ; [ CC-Time ]
>          = ;            = ;            = ; [ CC-Money ]
>          = ;            = ;            = ; [ CC-Total-Octets ]
>          = ;            = ;            = ; [ CC-Input-Octets ]
>          = ;            = ;            = ; [ CC-Output-Octets ]
>          = ;            = ;            = ; [ CC-Service-Specific-Units ]
>          = ;            = ;            *[ = Service-Identifier ]
>          = ;            = ;            = ; [ Rating-Group ]
>          = ;            = ;            = ; [ Final-Unit-Indication ]
>
>To:
>          = Granted-Service-Unit ::=3D < AVP Header: 431 >
>          = ;            = ;            = ; { Result-Code }
>          = ;            = ;            = ; [ Tariff-Time-Change ]
>          = ;            = ;            = ; [ CC-Time ]
>          = ;            = ;            = ; [ CC-Money ]
>          = ;            = ;            = ; [ CC-Total-Octets ]
>          = ;            = ;            = ; [ CC-Input-Octets ]
>          = ;            = ;            = ; [ CC-Output-Octets ]
>          = ;            = ;            = ; [ CC-Service-Specific-Units ]
>          = ;            = ;            *[ = Service-Identifier ]
>          = ;            = ;            = ; [ Rating-Group ]
>          = ;            = ;            = ; [ Final-Unit-Indication ]
>
>
>Best Regards,
>Chris.

_______________________________________________________________= __
MSN 8 with e-mail virus protection service: 2 months = FREE*
http://join.msn.com/?page=3Dfeatures/virus

------_=_NextPart_001_01C3C8AC.EE3DC8E4-- From aaa-admin@ietf.org Mon Dec 22 14:54:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02783 for ; Mon, 22 Dec 2003 14:54:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYW6u-0006fp-O8; Mon, 22 Dec 2003 14:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYW65-0006f0-1d for aaa@optimus.ietf.org; Mon, 22 Dec 2003 14:52:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02644 for ; Mon, 22 Dec 2003 14:52:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYW5x-0000YX-00 for aaa@ietf.org; Mon, 22 Dec 2003 14:52:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYW5X-0000Xx-00 for aaa@ietf.org; Mon, 22 Dec 2003 14:51:35 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AYW4g-0000UP-00; Mon, 22 Dec 2003 14:50:42 -0500 Received: from c-24-3-148-1.client.comcast.net ([24.3.148.1]) by manatick with smtp (Exim 4.24) id 1AYW3g-0000Se-Ii; Mon, 22 Dec 2003 14:49:43 -0500 Received: from [244.209.107.166] by c-24-3-148-1.client.comcast.net with ESMTP id 00395391 for ; Mon, 22 Dec 2003 22:46:42 +0300 Message-ID: <9$x6---2z2-e34$k0l436i$119ph0@qm3.v.m2u6oi> From: "Joann Bowden" Reply-To: "Joann Bowden" To: , , , , , , Date: Mon, 22 Dec 03 22:46:42 GMT X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="FD0375_6FE9D.F.A.6" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=21.6 required=5.0 tests=ALL_NATURAL,AWL,BIZ_TLD, CLICK_BELOW,DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,HTML_50_60, HTML_FONTCOLOR_RED,HTML_FONT_BIG,HTML_LINK_CLICK_HERE,HTML_MESSAGE, IMPOTENCE,MISSING_MIMEOLE,MONEY_BACK,PENIS_ENLARGE2,SUB_HELLO autolearn=no version=2.60 X-Spam-Report: * 2.7 SUB_HELLO Subject starts with "Hello" * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.6 PENIS_ENLARGE2 BODY: Information on getting larger penis/breasts * 4.2 IMPOTENCE BODY: Impotence cure * 1.3 ALL_NATURAL BODY: Spam is 100% natural?! * 4.3 MONEY_BACK BODY: Money back guarantee * 0.1 HTML_LINK_CLICK_HERE BODY: HTML link text says "click here" * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.0 CLICK_BELOW Asks you to click below * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * -0.0 AWL AWL: Auto-whitelist adjustment Subject: [Aaa] hello.? ivmrgrpfr Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , --FD0375_6FE9D.F.A.6 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable
The only solution to Penis Enlarg= ement

ONLY THIS WEEK: Add at least 3 INCHES or get your money back!

We are so sure our product works we are willing to offer a 100% money back guarantee upon purchase if you are not satisfied with the results.


Click Here To Learn More


<= b> * Doctor approved penis enhancement formula!
* 100% natural ingredients
* Discreet shipping for your privacy
* Gain 3+ inches!
* Stop premature ejaculation!
* 100% Safe! NO side effects!


Learn More About This Amazing New Product!
<= font color=3D"#FFFFFF">


No more offers
--FD0375_6FE9D.F.A.6-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Mon Dec 22 14:55:06 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02869 for ; Mon, 22 Dec 2003 14:55:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYW8V-0006lh-TS for aaa-archive@odin.ietf.org; Mon, 22 Dec 2003 14:54:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMJsdC2026013 for aaa-archive@odin.ietf.org; Mon, 22 Dec 2003 14:54:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYW8V-0006lU-QH for aaa-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 14:54:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02820 for ; Mon, 22 Dec 2003 14:54:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYW8O-0000dF-00 for aaa-web-archive@ietf.org; Mon, 22 Dec 2003 14:54:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYW7y-0000c7-00 for aaa-web-archive@ietf.org; Mon, 22 Dec 2003 14:54:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYW6u-0006fp-O8; Mon, 22 Dec 2003 14:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYW65-0006f0-1d for aaa@optimus.ietf.org; Mon, 22 Dec 2003 14:52:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02644 for ; Mon, 22 Dec 2003 14:52:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYW5x-0000YX-00 for aaa@ietf.org; Mon, 22 Dec 2003 14:52:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYW5X-0000Xx-00 for aaa@ietf.org; Mon, 22 Dec 2003 14:51:35 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AYW4g-0000UP-00; Mon, 22 Dec 2003 14:50:42 -0500 Received: from c-24-3-148-1.client.comcast.net ([24.3.148.1]) by manatick with smtp (Exim 4.24) id 1AYW3g-0000Se-Ii; Mon, 22 Dec 2003 14:49:43 -0500 Received: from [244.209.107.166] by c-24-3-148-1.client.comcast.net with ESMTP id 00395391 for ; Mon, 22 Dec 2003 22:46:42 +0300 Message-ID: <9$x6---2z2-e34$k0l436i$119ph0@qm3.v.m2u6oi> From: "Joann Bowden" Reply-To: "Joann Bowden" To: , , , , , , Date: Mon, 22 Dec 03 22:46:42 GMT X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="FD0375_6FE9D.F.A.6" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=21.6 required=5.0 tests=ALL_NATURAL,AWL,BIZ_TLD, CLICK_BELOW,DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,HTML_50_60, HTML_FONTCOLOR_RED,HTML_FONT_BIG,HTML_LINK_CLICK_HERE,HTML_MESSAGE, IMPOTENCE,MISSING_MIMEOLE,MONEY_BACK,PENIS_ENLARGE2,SUB_HELLO autolearn=no version=2.60 X-Spam-Report: * 2.7 SUB_HELLO Subject starts with "Hello" * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.6 PENIS_ENLARGE2 BODY: Information on getting larger penis/breasts * 4.2 IMPOTENCE BODY: Impotence cure * 1.3 ALL_NATURAL BODY: Spam is 100% natural?! * 4.3 MONEY_BACK BODY: Money back guarantee * 0.1 HTML_LINK_CLICK_HERE BODY: HTML link text says "click here" * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.0 CLICK_BELOW Asks you to click below * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * -0.0 AWL AWL: Auto-whitelist adjustment Subject: [Aaa] hello.? ivmrgrpfr Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , --FD0375_6FE9D.F.A.6 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable
The only solution to Penis Enlarg= ement

ONLY THIS WEEK: Add at least 3 INCHES or get your money back!

We are so sure our product works we are willing to offer a 100% money back guarantee upon purchase if you are not satisfied with the results.


Click Here To Learn More


<= b> * Doctor approved penis enhancement formula!
* 100% natural ingredients
* Discreet shipping for your privacy
* Gain 3+ inches!
* Stop premature ejaculation!
* 100% Safe! NO side effects!


Learn More About This Amazing New Product!
<= font color=3D"#FFFFFF">


No more offers
--FD0375_6FE9D.F.A.6-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Thu Dec 25 05:57:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24575 for ; Thu, 25 Dec 2003 05:57:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZTAq-00069Y-Kl; Thu, 25 Dec 2003 05:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZTAH-000685-Q2 for aaa@optimus.ietf.org; Thu, 25 Dec 2003 05:56:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24558 for ; Thu, 25 Dec 2003 05:56:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZTAE-0005PH-00 for aaa@ietf.org; Thu, 25 Dec 2003 05:56:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZT8s-0005K6-00 for aaa@ietf.org; Thu, 25 Dec 2003 05:54:59 -0500 Received: from rdbck-2321.palmer.mtaonline.net ([64.4.229.39]) by ietf-mx with smtp (Exim 4.12) id 1AZT5w-0005Ez-00 for aaa@ietf.org; Thu, 25 Dec 2003 05:51:56 -0500 Received: from [84.109.226.224] by rdbck-2321.palmer.mtaonline.net with ESMTP id AABBAEFE43B; Thu, 25 Dec 2003 16:45:45 +0600 Message-ID: From: "Gus Espinoza" Reply-To: "Gus Espinoza" To: aaa@ietf.org Date: Thu, 25 Dec 2003 16:45:45 GMT X-Mailer: Console agent v4.34 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="CE._.3E_4_" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.7 required=5.0 tests=BIZ_TLD,DATE_IN_FUTURE_03_06, HTML_50_60,HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_GREEN, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Report: * 0.1 HTML_FONTCOLOR_GREEN BODY: HTML font color is green * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't Subject: [Aaa] Learn how to copy DVD videos cowpea Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , --CE._.3E_4_ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Easy DVD KIT

Easy DVD K= IT  

Easy DVD KIT is a = powerful tool to COPY DVD movies to 
VCD/SVCD with just one click on your PC! 
Copy DVD movies to CD-R discs, convert DVD to VCD/SVCD, with 
= BACKUP-DVD it couldn't be easier! (see more)

Copying a DVD is no= t difficult at all. Our guide includes detailed 
instructions and , which are easy to follow, even for a beginner!(see more)

Learn how to burn D= VD's onto regular CD-R Discs!
Watch your new movies on any DVD player!
not just the computer DVD! (see more)

Copy DVD movies usi= ng your CD writer with just one click:
Put DVD into the DVD drive, a blank CDR in the CD writer, click <= br> "Start" and go!  Support DVD to VCD image, VCD image to CDRW = ;
Support almost all popular CD writers.(see more)

   &= nbsp;           &nb= sp;            = ;

EASY DVD KIT=FFFFFFA0 is the Best!! Make quality backups of your 
personal DVDs. Create your own DVD library. Never worry 
about scratching or losing a DVD again!

DOWNLOAD NOW !


Easy DVD KIT




rk xnu --CE._.3E_4_-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Dec 25 05:59:12 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24663 for ; Thu, 25 Dec 2003 05:59:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZTCY-0006Fg-5j for aaa-archive@odin.ietf.org; Thu, 25 Dec 2003 05:58:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBPAwkHD024028 for aaa-archive@odin.ietf.org; Thu, 25 Dec 2003 05:58:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZTCY-0006FT-2i for aaa-web-archive@optimus.ietf.org; Thu, 25 Dec 2003 05:58:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24654 for ; Thu, 25 Dec 2003 05:58:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZTCU-0005Xb-00 for aaa-web-archive@ietf.org; Thu, 25 Dec 2003 05:58:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AZTAw-0005SR-00 for aaa-web-archive@ietf.org; Thu, 25 Dec 2003 05:57:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZTAq-00069Y-Kl; Thu, 25 Dec 2003 05:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZTAH-000685-Q2 for aaa@optimus.ietf.org; Thu, 25 Dec 2003 05:56:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24558 for ; Thu, 25 Dec 2003 05:56:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZTAE-0005PH-00 for aaa@ietf.org; Thu, 25 Dec 2003 05:56:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZT8s-0005K6-00 for aaa@ietf.org; Thu, 25 Dec 2003 05:54:59 -0500 Received: from rdbck-2321.palmer.mtaonline.net ([64.4.229.39]) by ietf-mx with smtp (Exim 4.12) id 1AZT5w-0005Ez-00 for aaa@ietf.org; Thu, 25 Dec 2003 05:51:56 -0500 Received: from [84.109.226.224] by rdbck-2321.palmer.mtaonline.net with ESMTP id AABBAEFE43B; Thu, 25 Dec 2003 16:45:45 +0600 Message-ID: From: "Gus Espinoza" Reply-To: "Gus Espinoza" To: aaa@ietf.org Date: Thu, 25 Dec 2003 16:45:45 GMT X-Mailer: Console agent v4.34 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="CE._.3E_4_" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.7 required=5.0 tests=BIZ_TLD,DATE_IN_FUTURE_03_06, HTML_50_60,HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_GREEN, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Report: * 0.1 HTML_FONTCOLOR_GREEN BODY: HTML font color is green * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't Subject: [Aaa] Learn how to copy DVD videos cowpea Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , --CE._.3E_4_ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Easy DVD KIT

Easy DVD K= IT  

Easy DVD KIT is a = powerful tool to COPY DVD movies to 
VCD/SVCD with just one click on your PC! 
Copy DVD movies to CD-R discs, convert DVD to VCD/SVCD, with 
= BACKUP-DVD it couldn't be easier! (see more)

Copying a DVD is no= t difficult at all. Our guide includes detailed 
instructions and , which are easy to follow, even for a beginner!(see more)

Learn how to burn D= VD's onto regular CD-R Discs!
Watch your new movies on any DVD player!
not just the computer DVD! (see more)

Copy DVD movies usi= ng your CD writer with just one click:
Put DVD into the DVD drive, a blank CDR in the CD writer, click <= br> "Start" and go!  Support DVD to VCD image, VCD image to CDRW = ;
Support almost all popular CD writers.(see more)

   &= nbsp;           &nb= sp;            = ;

EASY DVD KIT=FFFFFFA0 is the Best!! Make quality backups of your 
personal DVDs. Create your own DVD library. Never worry 
about scratching or losing a DVD again!

DOWNLOAD NOW !


Easy DVD KIT




rk xnu --CE._.3E_4_-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa