From mailman-admin@ietf.org Tue Apr 1 09:52:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15501 for ; Tue, 1 Apr 2003 09:52:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31FGQK25600 for ; Tue, 1 Apr 2003 10:16:26 -0500 Date: Tue, 01 Apr 2003 10:16:26 -0500 Message-ID: <20030401151626.29326.35779.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: aaa-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, aaa-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for aaa-archive@lists.ietf.org: List Password // URL ---- -------- aaa@ietf.org kaithu https://www1.ietf.org/mailman/options/aaa/aaa-archive%40lists.ietf.org From owner-aaa-wg@merit.edu Thu Apr 3 10:28: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 KAA24904 for ; Thu, 3 Apr 2003 10:28:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 50E3F912C9; Thu, 3 Apr 2003 10:30:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0025912CB; Thu, 3 Apr 2003 10:30:18 -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 37F5E912C9 for ; Thu, 3 Apr 2003 10:30:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1FF205DE1F; Thu, 3 Apr 2003 10:30:16 -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 D452E5DDF5 for ; Thu, 3 Apr 2003 10:30:15 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 703B36A904 for ; Thu, 3 Apr 2003 18:30:13 +0300 (EEST) Message-ID: <3E8C5358.2080700@kolumbus.fi> Date: Thu, 03 Apr 2003 18:29:28 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Time since 1900 or 1970 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 Hello, In base, it seems that the definition of time in 8.21 does not match the definition in 4.3. I think 4.3 is right here. Perhaps we should just delete the "since January 1, 1970 00:00 UTC" part, if there's still time to do that with the RFC editor. Jari ---- 4.3 Derived AVP Data Formats Time The Time format is derived from the OctetString AVP Base Format. The string MUST contain four octets, in the same format as the first four bytes are in the NTP timestamp format. The NTP Timestamp format is defined in chapter 3 of [SNTP]. This represents the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC). On 6h 28m 16s UTC, 7 February 2036 the time value will overflow. SNTP [SNTP] describes a procedure to extend the time to 2104. This procedure MUST be supported by all DIAMETER nodes. 8.21 Event-Timestamp AVP The Event-Timestamp (AVP Code 55) is of type Time, and MAY be included in an Accounting-Request and Accounting-Answer messages to record the time that the reported event occurred, in seconds since January 1, 1970 00:00 UTC. From owner-aaa-wg@merit.edu Thu Apr 3 19:27: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 TAA21144 for ; Thu, 3 Apr 2003 19:27:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 616FB912F5; Thu, 3 Apr 2003 19:29:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2432C912F2; Thu, 3 Apr 2003 19:29:27 -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 488C3912EE for ; Thu, 3 Apr 2003 19:29:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 374E95DEAA; Thu, 3 Apr 2003 19:29:20 -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 C35545DDE8 for ; Thu, 3 Apr 2003 19:29:19 -0500 (EST) Received: from zrc2c001.us.nortel.com (zrc2c001.us.nortel.com [47.103.121.31]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h340TE825257; Thu, 3 Apr 2003 18:29:15 -0600 (CST) Received: from zrc2c009.us.nortel.com ([47.103.120.49]) by zrc2c001.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2DNYRG18; Thu, 3 Apr 2003 18:29:15 -0600 Received: from iqmail.net (chowdury-2.us.nortel.com [47.103.84.30]) by zrc2c009.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GSPRQK6P; Thu, 3 Apr 2003 18:29:14 -0600 Message-ID: <3E8CD1B5.8000901@iqmail.net> Date: Thu, 03 Apr 2003 18:28:37 -0600 X-Sybari-Space: 00000000 00000000 00000000 From: Kuntal Chowdhury User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Harri Hakala (LMF)" Cc: aaa-wg@merit.edu, john.loughney@nokia.com, marco.stura@nokia.com, "Leena Mattila (LMF)" Subject: Re: [AAA-WG]: comment on diameter credit control References: 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 Harri Hakala (LMF) wrote: > Kuntal Chowdhury wrote: > > >>OK, then what the credit control server is doing? Most likely >>it looks at the >>account balance of the user and then it allocates a portion >>of the balance (unit >>if you will) to the service element for the user's session. >>If the account >>balance is "nil" then the credit control server has to reject >>the request from >>the service element. The action of the credit control server >>i.e. checking >>account balance + allocating portion of balance if available >>is what I call >>"authorization" of the service. I think "authorization" of >>the service needs to >>involve the credit control server. There is no point in >>authorizing a user for a >>service that he/she cannot use because the account balance >>for that service is >>nil or too low. > > > The draft just proposes that the authorization should be done in two phases. > First the service element shall transfer user authentication and service specific > authorization information to the AA server to know whether the end user is allowed > to access to the service, i.e. to validate that the user has a subscription for the > service, right category, etc. The way how the authentication and authorization will > be performed and the application specific authentication and authorization messages > that can be used are out of scope of the draft. The messages defined in other Diameter > applications or other authentication and authorization protocols can be used. > Note that the AA-applications are not impacted and you don't need to update these > protocols due to the credit control application. So the existing service specific > authentication and authorization protocols do not need to carry any credit control > specific parameters, e.g. rating input parameters, granted units, etc. > What you are talking about is service authorization w/o an account balance verification. This should be OK for a non-prepaid user who does not require a credit check. When the AAA server receives the authorization request from a service element it can determine whether the user has a prepaid account for that particular service (or may be prepaid account in general for all services) by looking at the user's AAA profile. If yes, the AAA server should authorize the request based on the remaining balance left in the user's prepaid account. If the credit control server is collocated with the AAA server, then it becomes a simple query. If the credit control server is located outside the AAA server, then the AAA server can use the same auth messages that you propose that the service element uses to talk to the credit control server. I think this is a much cleaner and quicker way to authorize a user's request. By doing service authorization and account balance check in one shot reduces the possibility of delay in service initiation which may be critical factor for real-time services. > If all is in order, then the service element can start to use the credit control application. > In other words the service element shall initiate 'credit control authorization' towards the > credit control server by using ACR/ACA messages containing the credit control AVPs to do tasks > which you describe above (and described in the chapter 3.1). > As I mentioned above, this type of mandatory two step process to authorize every service request increases the service setup time. > In summary, the draft suggests that the 'authorization' should be done in two phases; first the > AA server validates whether the user is allowed access to the service, secondly the credit > control server checks the user's account for coverage for the requested service event (and > allocates the initial quota). It also defines that both 'authorization' phases can be done by > using separate protocols and these applications do not need to have interdependences. > I am suggesting to allow one step process as well. -Kuntal From owner-aaa-wg@merit.edu Thu Apr 3 19:44: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 TAA21467 for ; Thu, 3 Apr 2003 19:44:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3393891233; Thu, 3 Apr 2003 19:46:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 038FD912EE; Thu, 3 Apr 2003 19:46:29 -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 679FB91233 for ; Thu, 3 Apr 2003 19:46:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 87CE25DEB5; Thu, 3 Apr 2003 19:46:27 -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 CDEB05DEB8 for ; Thu, 3 Apr 2003 19:46:25 -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 h340kL826233; Thu, 3 Apr 2003 18:46:21 -0600 (CST) Received: from zrc2c009.us.nortel.com ([47.103.120.49]) by zrc2c011.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HNP4QVZ6; Thu, 3 Apr 2003 18:46:22 -0600 Received: from iqmail.net (chowdury-2.us.nortel.com [47.103.84.30]) by zrc2c009.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GSPRQK66; Thu, 3 Apr 2003 18:46:21 -0600 Message-ID: <3E8CD5B8.20307@iqmail.net> Date: Thu, 03 Apr 2003 18:45:44 -0600 X-Sybari-Space: 00000000 00000000 00000000 From: Kuntal Chowdhury User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Harri Hakala (LMF)" Cc: aaa-wg@merit.edu, john.loughney@nokia.com, marco.stura@nokia.com, "Leena Mattila (LMF)" Subject: Re: [AAA-WG]: comment on diameter credit control References: 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 Harri Hakala (LMF) wrote: > Kuntal Chowdhury wrote: > > >>IMHO, the simple examples of service elements are P-CSCF, MMS-C, >>AGW/GGSN/PDSN/HA. I don't think these network elements should >>care about price >>of a service. In a roaming situation, the home network most >>likely will not be >>happy to share it's price-per-service details with the >>visited network's service >>element. >> >>........ >> >>I don't think it's a good idea to let the service >>elements/nodes to meddle with >>price of a service. I don't think carrier's will like to >>distribute this info >>across network elements. Price is something that the >>carrier's like to deal >>directly with the end-user. The end-user can >>discover/negotiate price of a >>service through application (https://, phone call) etc. >>rather than intermediate >>nodes being involved. I hope we can converge on this issue. > > > The purpose is that the credit control application is a general purpose real-time > accounting protocol for various applications & services, so there will be various > types of service elements in different kind of systems as well. Some of these network > elements may provide support of sending cost estimation to the end user. > If these service elements are wholly owned by the provider of the said service (the same owner of the credit control server) then I can see your point. However there is no guarantee that will be the case. It is totally upto the service provider's policy to distribute price info freely to any service element or not. > Some systems have requirements to provide at the beginning of a chargeable event an indication > to the charged party of the charges to be levied for the event. > There are also services (advice of charge kind of) that provides the user with information > about the applicable charging rate or cost estimation at session establishment or when > cost of the service change during the session. We thought that the credit control application > should also provide the capabilities to support these kind of services. The way how the service > node then forwards this information to the end user is not scope of the draft. > I am not worried about what transport the service element will use to send this price info to the user. The thing I am not sure about is what makes the credit control server so sure that it can reveal the actual price of a service it is providing to the service elements which may be owned by a competitor. I believe the charge for a service should be negotiated a priori between the user and the credit control service provider. When you buy a prepaid account it tells you the price of the specific service. What you suggest is a close network where the service element and the credit control server are in cahoots with each other which may not be the case at all times. > But of course we can discuss whether this support is really needed. > Thanks for your consideration. -Kuntal From owner-aaa-wg@merit.edu Fri Apr 4 00:12:48 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 AAA25975 for ; Fri, 4 Apr 2003 00:12:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B1E0E91236; Thu, 3 Apr 2003 23:56:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77A7591237; Thu, 3 Apr 2003 23:56:12 -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 328F891236 for ; Thu, 3 Apr 2003 23:56:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 15A775DEA6; Thu, 3 Apr 2003 23:56:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 9461F5DE82 for ; Thu, 3 Apr 2003 23:56:10 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h344u7Rs014892; Fri, 4 Apr 2003 06:56:07 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2A4L108D>; Fri, 4 Apr 2003 06:56:07 +0200 Message-ID: From: "Harri Hakala (LMF)" To: "'Kuntal Chowdhury'" Cc: aaa-wg@merit.edu, john.loughney@nokia.com, marco.stura@nokia.com, "Leena Mattila (LMF)" Subject: RE: [AAA-WG]: comment on diameter credit control Date: Fri, 4 Apr 2003 06:56:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Kuntal, The drawback will be that you need to update all authentication and authorization protocols to carry rating input parameters and credit control parameters. Because the service element does not necessarily know if the user is postpaid or prepaid, all authentication and authorization requests then need to carry these parameters. Very often the credit control server is located outside the AAA server, so the AAA server needs to establish the credit control session between AAA server and the credit control server. When there is need for interim request (session based credit control), the AAA server then acts as credit control proxy between the service element and the credit control server Do we want that the AAA server start to be acting as the credit control proxy ? Regards............Harri > -----Original Message----- > From: Kuntal Chowdhury [mailto:kuntal@iqmail.net] > Sent: 4. huhtikuuta 2003 3:29 > To: Harri Hakala (LMF) > Cc: aaa-wg@merit.edu; john.loughney@nokia.com; marco.stura@nokia.com; > Leena Mattila (LMF) > Subject: Re: [AAA-WG]: comment on diameter credit control > > > > > Harri Hakala (LMF) wrote: > > Kuntal Chowdhury wrote: > > > > > >>OK, then what the credit control server is doing? Most likely > >>it looks at the > >>account balance of the user and then it allocates a portion > >>of the balance (unit > >>if you will) to the service element for the user's session. > >>If the account > >>balance is "nil" then the credit control server has to reject > >>the request from > >>the service element. The action of the credit control server > >>i.e. checking > >>account balance + allocating portion of balance if available > >>is what I call > >>"authorization" of the service. I think "authorization" of > >>the service needs to > >>involve the credit control server. There is no point in > >>authorizing a user for a > >>service that he/she cannot use because the account balance > >>for that service is > >>nil or too low. > > > > > > The draft just proposes that the authorization should be > done in two phases. > > First the service element shall transfer user > authentication and service specific > > authorization information to the AA server to know whether > the end user is allowed > > to access to the service, i.e. to validate that the user > has a subscription for the > > service, right category, etc. The way how the > authentication and authorization will > > be performed and the application specific authentication > and authorization messages > > that can be used are out of scope of the draft. The > messages defined in other Diameter > > applications or other authentication and authorization > protocols can be used. > > Note that the AA-applications are not impacted and you > don't need to update these > > protocols due to the credit control application. So the > existing service specific > > authentication and authorization protocols do not need to > carry any credit control > > specific parameters, e.g. rating input parameters, granted > units, etc. > > > > What you are talking about is service authorization w/o an > account balance > verification. This should be OK for a non-prepaid user who > does not require a > credit check. When the AAA server receives the authorization > request from a > service element it can determine whether the user has a > prepaid account for that > particular service (or may be prepaid account in general for > all services) by > looking at the user's AAA profile. If yes, the AAA server > should authorize the > request based on the remaining balance left in the user's > prepaid account. If > the credit control server is collocated with the AAA server, > then it becomes a > simple query. If the credit control server is located outside > the AAA server, > then the AAA server can use the same auth messages that you > propose that the > service element uses to talk to the credit control server. I > think this is a > much cleaner and quicker way to authorize a user's request. > By doing service > authorization and account balance check in one shot reduces > the possibility of > delay in service initiation which may be critical factor for > real-time services. > > > > If all is in order, then the service element can start to > use the credit control application. > > In other words the service element shall initiate 'credit > control authorization' towards the > > credit control server by using ACR/ACA messages containing > the credit control AVPs to do tasks > > which you describe above (and described in the chapter 3.1). > > > > As I mentioned above, this type of mandatory two step process > to authorize every > service request increases the service setup time. > > > In summary, the draft suggests that the 'authorization' > should be done in two phases; first the > > AA server validates whether the user is allowed access to > the service, secondly the credit > > control server checks the user's account for coverage for > the requested service event (and > > allocates the initial quota). It also defines that both > 'authorization' phases can be done by > > using separate protocols and these applications do not need > to have interdependences. > > > > I am suggesting to allow one step process as well. > > -Kuntal > > From owner-aaa-wg@merit.edu Fri Apr 4 05:04:48 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 FAA12927 for ; Fri, 4 Apr 2003 05:04:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0D5E891238; Fri, 4 Apr 2003 05:07:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C95809123A; Fri, 4 Apr 2003 05:07: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 AEDF591238 for ; Fri, 4 Apr 2003 05:07:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 98A355DF2F; Fri, 4 Apr 2003 05:07:02 -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 D7D745DF25 for ; Fri, 4 Apr 2003 05:07:01 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h34A5SN04566 for ; Fri, 4 Apr 2003 13:05:28 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 4 Apr 2003 13:07:00 +0300 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 4 Apr 2003 13:06:58 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 4 Apr 2003 13:06:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: comment on diameter credit control Date: Fri, 4 Apr 2003 13:06:57 +0300 Message-ID: Thread-Topic: [AAA-WG]: comment on diameter credit control Thread-Index: AcLzMfwAdiB/CJBJShuWg+WkAmCw+wHX93Hw From: To: , X-OriginalArrivalTime: 04 Apr 2003 10:06:58.0190 (UTC) FILETIME=[ED84CAE0:01C2FA91] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA12927 Hi all, > Q1. What is a "home environment"? I guess it should be home network. I'm editing the document right now, and will use the term 'home domain' as this is consistant with the Diameter Base draft. John From owner-aaa-wg@merit.edu Fri Apr 4 05:10: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 FAA13092 for ; Fri, 4 Apr 2003 05:10:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2F1D89123A; Fri, 4 Apr 2003 05:13:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0111E9123B; Fri, 4 Apr 2003 05:13:05 -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 D4A3B9123A for ; Fri, 4 Apr 2003 05:13:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id C4CD65DEEC; Fri, 4 Apr 2003 05:13:04 -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 CC5C05DEE5 for ; Fri, 4 Apr 2003 05:13:03 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h34AH2525804 for ; Fri, 4 Apr 2003 13:17:02 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 4 Apr 2003 13:12:57 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 4 Apr 2003 13:12:56 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 4 Apr 2003 13:12:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: comment on diameter credit control Date: Fri, 4 Apr 2003 13:12:55 +0300 Message-ID: Thread-Topic: [AAA-WG]: comment on diameter credit control Thread-Index: AcL6ZoYxla9qxfm+RfWB+vzTLpevRgAK9+lg From: To: Cc: X-OriginalArrivalTime: 04 Apr 2003 10:12:56.0066 (UTC) FILETIME=[C2D45620:01C2FA92] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA13092 Hi all, > The drawback will be that you need to update all authentication and > authorization protocols to carry rating input parameters and credit > control parameters. Because the service element does not necessarily > know if the user is postpaid or prepaid, all authentication and > authorization requests then need to carry these parameters. > > Very often the credit control server is located outside the AAA server, > so the AAA server needs to establish the credit control session between > AAA server and the credit control server. When there is need for interim > request (session based credit control), the AAA server then acts as > credit control proxy between the service element and the credit control > server Do we want that the AAA server start to be acting as the credit > control proxy ? I worry about this as well. This gets very close to third party involvement, which greatly increases various sercurity risks, etc. I'd prefer to keep a simple solution. A far simpler solution, would be that a user has multiple identities for charging purposes, and uses those directly. This would not be something we need to specify, then, here. br, John From owner-aaa-wg@merit.edu Fri Apr 4 06:53: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 GAA16999 for ; Fri, 4 Apr 2003 06:53:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B71E991240; Fri, 4 Apr 2003 06:55:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88DD091241; Fri, 4 Apr 2003 06:55: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 78BDA91240 for ; Fri, 4 Apr 2003 06:55:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D51A5DF3B; Fri, 4 Apr 2003 06:55:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id AAA3B5DF2C for ; Fri, 4 Apr 2003 06:55:26 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h34BtNI3016161; Fri, 4 Apr 2003 13:55:23 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2A4L2QPB>; Fri, 4 Apr 2003 13:55:24 +0200 Message-ID: From: "Harri Hakala (LMF)" To: "'Kuntal Chowdhury'" Cc: aaa-wg@merit.edu, john.loughney@nokia.com, marco.stura@nokia.com, "Leena Mattila (LMF)" Subject: RE: [AAA-WG]: comment on diameter credit control Date: Fri, 4 Apr 2003 13:55:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Kuntal Chowdhury wrote: > I am not worried about what transport the service element > will use to send this > price info to the user. The thing I am not sure about is what > makes the credit > control server so sure that it can reveal the actual price of > a service it is > providing to the service elements which may be owned by a > competitor. I believe > the charge for a service should be negotiated a priori > between the user and the > credit control service provider. When you buy a prepaid > account it tells you the > price of the specific service. What you suggest is a close > network where the > service element and the credit control server are in cahoots > with each other > which may not be the case at all times. We thought that there must be trust relationship between the credit control server and credit control client, otherwise it is high risk to allocate quotas (and price information as well) to an untrust client. We have assumption (section 3) that the service element is located in the same administrative domain in which the end user's credit control server is located. It might be still possible that the service element in the visited domain can offer services to the end user, but in that case a commercial agreement must exist between these parties. Regards........Harri > -----Original Message----- > From: Kuntal Chowdhury [mailto:kuntal@iqmail.net] > Sent: 4. huhtikuuta 2003 3:46 > To: Harri Hakala (LMF) > Cc: aaa-wg@merit.edu; john.loughney@nokia.com; marco.stura@nokia.com; > Leena Mattila (LMF) > Subject: Re: [AAA-WG]: comment on diameter credit control > > > > > Harri Hakala (LMF) wrote: > > Kuntal Chowdhury wrote: > > > > > >>IMHO, the simple examples of service elements are P-CSCF, MMS-C, > >>AGW/GGSN/PDSN/HA. I don't think these network elements should > >>care about price > >>of a service. In a roaming situation, the home network most > >>likely will not be > >>happy to share it's price-per-service details with the > >>visited network's service > >>element. > >> > >>........ > >> > >>I don't think it's a good idea to let the service > >>elements/nodes to meddle with > >>price of a service. I don't think carrier's will like to > >>distribute this info > >>across network elements. Price is something that the > >>carrier's like to deal > >>directly with the end-user. The end-user can > >>discover/negotiate price of a > >>service through application (https://, phone call) etc. > >>rather than intermediate > >>nodes being involved. I hope we can converge on this issue. > > > > > > The purpose is that the credit control application is a > general purpose real-time > > accounting protocol for various applications & services, so > there will be various > > types of service elements in different kind of systems as > well. Some of these network > > elements may provide support of sending cost estimation to > the end user. > > > > If these service elements are wholly owned by the provider of > the said service > (the same owner of the credit control server) then I can see > your point. However > there is no guarantee that will be the case. It is totally > upto the service > provider's policy to distribute price info freely to any > service element or not. > > > Some systems have requirements to provide at the beginning > of a chargeable event an indication > > to the charged party of the charges to be levied for the event. > > There are also services (advice of charge kind of) that > provides the user with information > > about the applicable charging rate or cost estimation at > session establishment or when > > cost of the service change during the session. We thought > that the credit control application > > should also provide the capabilities to support these kind > of services. The way how the service > > node then forwards this information to the end user is not > scope of the draft. > > > > I am not worried about what transport the service element > will use to send this > price info to the user. The thing I am not sure about is what > makes the credit > control server so sure that it can reveal the actual price of > a service it is > providing to the service elements which may be owned by a > competitor. I believe > the charge for a service should be negotiated a priori > between the user and the > credit control service provider. When you buy a prepaid > account it tells you the > price of the specific service. What you suggest is a close > network where the > service element and the credit control server are in cahoots > with each other > which may not be the case at all times. > > > But of course we can discuss whether this support is really needed. > > > > Thanks for your consideration. > > > -Kuntal > > From owner-aaa-wg@merit.edu Fri Apr 4 09:12: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 JAA22468 for ; Fri, 4 Apr 2003 09:12:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 037E391244; Fri, 4 Apr 2003 09:14:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C343391304; Fri, 4 Apr 2003 09:14: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 3B69191244 for ; Fri, 4 Apr 2003 09:14:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 25F0B5DF61; Fri, 4 Apr 2003 09:14:48 -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 6548A5DF60 for ; Fri, 4 Apr 2003 09:14:47 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h34EDEN07692 for ; Fri, 4 Apr 2003 17:13:14 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 4 Apr 2003 17:14:46 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 4 Apr 2003 17:14:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: comment on diameter credit control Date: Fri, 4 Apr 2003 17:14:44 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E454A@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: comment on diameter credit control Thread-Index: AcL6oRlqN4cqeS7IRI6R/fPW/eUuMAAD6BYQ From: To: , Cc: , , X-OriginalArrivalTime: 04 Apr 2003 14:14:45.0325 (UTC) FILETIME=[8B058FD0:01C2FAB4] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA22468 > We thought that there must be trust relationship between the > credit control server and > credit control client, otherwise it is high risk to allocate > quotas (and price information > as well) to an untrust client. > > We have assumption (section 3) that the service element is > located in the same administrative > domain in which the end user's credit control server is > located. It might be still possible that the > service element in the visited domain can offer services to > the end user, but in that case a > commercial agreement must exist between these parties. That's exact, trusted relationship must exist. Moreover if the user is using services in her home network the service element (Application server) is located in the same administrative domain, thus the price of the service is not delivered to a service element of a competitor. Of course the IP packets conveying the price to the end user will travel through an access device located in the visited network, but I would assume in this kind of use cases (e.g. user requesting the price of a service or requesting top-up of the account) the proper end-to-end security mechanism such as IPSec or TLS are used. In case of services offered by the visited network I would assume that price enquiry is not certainly directed to the home network of the user, which cannot know the price of the service offered by visited domain. Regards Marco > -----Original Message----- > From: ext Harri Hakala (LMF) [mailto:Harri.Hakala@lmf.ericsson.se] > Sent: 04 April, 2003 14:55 > To: 'Kuntal Chowdhury' > Cc: aaa-wg@merit.edu; Loughney John (NRC/Helsinki); Stura Marco > (NET/Helsinki); Leena Mattila (LMF) > Subject: RE: [AAA-WG]: comment on diameter credit control > > > Kuntal Chowdhury wrote: > > I am not worried about what transport the service element > > will use to send this > > price info to the user. The thing I am not sure about is what > > makes the credit > > control server so sure that it can reveal the actual price of > > a service it is > > providing to the service elements which may be owned by a > > competitor. I believe > > the charge for a service should be negotiated a priori > > between the user and the > > credit control service provider. When you buy a prepaid > > account it tells you the > > price of the specific service. What you suggest is a close > > network where the > > service element and the credit control server are in cahoots > > with each other > > which may not be the case at all times. > > We thought that there must be trust relationship between the > credit control server and > credit control client, otherwise it is high risk to allocate > quotas (and price information > as well) to an untrust client. > > We have assumption (section 3) that the service element is > located in the same administrative > domain in which the end user's credit control server is > located. It might be still possible that the > service element in the visited domain can offer services to > the end user, but in that case a > commercial agreement must exist between these parties. > > Regards........Harri > > > -----Original Message----- > > From: Kuntal Chowdhury [mailto:kuntal@iqmail.net] > > Sent: 4. huhtikuuta 2003 3:46 > > To: Harri Hakala (LMF) > > Cc: aaa-wg@merit.edu; john.loughney@nokia.com; > marco.stura@nokia.com; > > Leena Mattila (LMF) > > Subject: Re: [AAA-WG]: comment on diameter credit control > > > > > > > > > > Harri Hakala (LMF) wrote: > > > Kuntal Chowdhury wrote: > > > > > > > > >>IMHO, the simple examples of service elements are P-CSCF, MMS-C, > > >>AGW/GGSN/PDSN/HA. I don't think these network elements should > > >>care about price > > >>of a service. In a roaming situation, the home network most > > >>likely will not be > > >>happy to share it's price-per-service details with the > > >>visited network's service > > >>element. > > >> > > >>........ > > >> > > >>I don't think it's a good idea to let the service > > >>elements/nodes to meddle with > > >>price of a service. I don't think carrier's will like to > > >>distribute this info > > >>across network elements. Price is something that the > > >>carrier's like to deal > > >>directly with the end-user. The end-user can > > >>discover/negotiate price of a > > >>service through application (https://, phone call) etc. > > >>rather than intermediate > > >>nodes being involved. I hope we can converge on this issue. > > > > > > > > > The purpose is that the credit control application is a > > general purpose real-time > > > accounting protocol for various applications & services, so > > there will be various > > > types of service elements in different kind of systems as > > well. Some of these network > > > elements may provide support of sending cost estimation to > > the end user. > > > > > > > If these service elements are wholly owned by the provider of > > the said service > > (the same owner of the credit control server) then I can see > > your point. However > > there is no guarantee that will be the case. It is totally > > upto the service > > provider's policy to distribute price info freely to any > > service element or not. > > > > > Some systems have requirements to provide at the beginning > > of a chargeable event an indication > > > to the charged party of the charges to be levied for the event. > > > There are also services (advice of charge kind of) that > > provides the user with information > > > about the applicable charging rate or cost estimation at > > session establishment or when > > > cost of the service change during the session. We thought > > that the credit control application > > > should also provide the capabilities to support these kind > > of services. The way how the service > > > node then forwards this information to the end user is not > > scope of the draft. > > > > > > > I am not worried about what transport the service element > > will use to send this > > price info to the user. The thing I am not sure about is what > > makes the credit > > control server so sure that it can reveal the actual price of > > a service it is > > providing to the service elements which may be owned by a > > competitor. I believe > > the charge for a service should be negotiated a priori > > between the user and the > > credit control service provider. When you buy a prepaid > > account it tells you the > > price of the specific service. What you suggest is a close > > network where the > > service element and the credit control server are in cahoots > > with each other > > which may not be the case at all times. > > > > > But of course we can discuss whether this support is > really needed. > > > > > > > Thanks for your consideration. > > > > > > -Kuntal > > > > > From owner-aaa-wg@merit.edu Fri Apr 4 11:34: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 LAA28534 for ; Fri, 4 Apr 2003 11:34:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E803C91249; Fri, 4 Apr 2003 11:35:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5B429124A; Fri, 4 Apr 2003 11:35: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 C817A91249 for ; Fri, 4 Apr 2003 11:35:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id B29A55DF8F; Fri, 4 Apr 2003 11:35:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 41D255DF89 for ; Fri, 4 Apr 2003 11:35:54 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h34GIHK15918 for ; Fri, 4 Apr 2003 08:18:17 -0800 Date: Fri, 4 Apr 2003 08:18:16 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Last chance to comment Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The following AAA-related documents have completed IETF last call, have incorporated existing comments and are on the verge of being submitted to the IESG. Therefore if you have not read them yet, you will need to do so ASAP. Documents which have completed IETF last call and incorporated comments include: http://www.drizzle.com/~aboba/IEEE/draft-congdon-radius-8021x-24.txt http://www.drizzle.com/~aboba/IEEE/draft-chiba-radius-dynamic-authorization-11.txt http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-11.txt Please send your comments to the authors, and cc: iesg@ietf.org. From owner-aaa-wg@merit.edu Sun Apr 6 00:28: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 AAA22127 for ; Sun, 6 Apr 2003 00:28:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A415A91285; Sun, 6 Apr 2003 00:30:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D83A91289; Sun, 6 Apr 2003 00:30:44 -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 69C7091285 for ; Sun, 6 Apr 2003 00:30:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 710875E065; Sun, 6 Apr 2003 00:30:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 991D65E04C for ; Sun, 6 Apr 2003 00:30:38 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h365Cq607842 for ; Sat, 5 Apr 2003 21:12:53 -0800 Date: Sat, 5 Apr 2003 21:12:52 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Concern about Diameter disconnect and dynamic authorization Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk We've just been through a bit of a security firedrill with respect to the following draft: http://www.drizzle.com/~aboba/IEEE/draft-chiba-radius-dynamic-authorization-11.txt While a bunch of the issues found here do *not* afflict Diameter disconnect and dynamic authorization operations (since Diameter uses ordinary Request/Response mechanisms for authorization changes), it seems to me that other issues *are* relevant. For example, there is the question of how a NAS or proxy decides whether a disconnect or dynamic authorization request is appropriate. Authentication is not enough for this -- we would not want one ISP to be able to disconnect users from another ISP on a shared use NAS, for example. It seems to me that to some extent the mechanisms used to identify a session for these operations are application specific -- and therefore that the issues need to be addressed in the Diameter Application specs, rather than Base. However, in looking at the RAR and STR messages in Diameter, it would appear that they lack the basic facilities necessary to do a reverse path check (RPF) as described in the above draft. In addition, they lack the NAS and session identification AVPs that would appear to be necessary for proper identification. Therefore the RAR and STR messages defined in Diameter Base probably can't be used in applications without defining additional AVPs. I am assuming that the intent in Diameter Base is just to define the basic commands and allow individual applications to specify how they are used in more detail. However Diameter NASREQ nor Diameter MIPv4 contain the required details -- which leads me to believe that this is a more basic problem that reflects some gaps in thinking about how these commands really work? Comments? From owner-aaa-wg@merit.edu Mon Apr 7 12:01: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 MAA24565 for ; Mon, 7 Apr 2003 12:01:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7B0B491218; Mon, 7 Apr 2003 12:03:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E89E91217; Mon, 7 Apr 2003 12:03:56 -0400 (EDT) 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 5C8659121C for ; Mon, 7 Apr 2003 12:02:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 361DC5E1DC; Mon, 7 Apr 2003 12:02:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from web41810.mail.yahoo.com (web41810.mail.yahoo.com [66.218.93.144]) by segue.merit.edu (Postfix) with SMTP id A05F85E1DA for ; Mon, 7 Apr 2003 12:02:34 -0400 (EDT) Message-ID: <20030407160234.88350.qmail@web41810.mail.yahoo.com> Received: from [65.213.193.49] by web41810.mail.yahoo.com via HTTP; Mon, 07 Apr 2003 09:02:34 PDT Date: Mon, 7 Apr 2003 09:02:34 -0700 (PDT) From: CAITR Reply-To: info@caitr.org Subject: [AAA-WG]: Internetworking 2003: Call for Papers To: aaa-wg@merit.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1086017990-1049731354=:86999" Sender: owner-aaa-wg@merit.edu Precedence: bulk --0-1086017990-1049731354=:86999 Content-Type: text/plain; charset=us-ascii Call for Papers ============== Internetworking 2003, June 22-24, 2003, San Jose, California http://www.caitr.org/internetworking03/index.htm REMINDER: Deadline for submissions is April 11, 2003 The Internetworking 2003 Technical Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following: - Voice over IP (VoIP) - IP Video Conferencing - Storage Area Networks (SANs) - Unicast and Multicast Routing and Convergence - QoS Routing - Network Security and Service Integration - Operational Support Systems - Virtual Private Networks - Internetworking Wireless LANs and 3G Wireless Networks - IP-based Infrastructure for Wireless Networks - Internetworking IP and Optical Networks - Internetworking MPLS with Legacy ATM and Frame Relay Networks - Transition from IPv4 to IPv6 and interworking - Pervasive Computing - High Speed Transport Layer Protocols - Peer to Peer Networking and Grid Computing - Video Teleconferencing (VTC) - 802.11 Hotspots Conference Technical Co-chairs: - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Vishal Sharma, Metanoia - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez, Co-chair, IETF Working Group on IP Storage - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Tony Przygienda, Co-chair, IETF Working Group on IS-IS for IP Internets - Ran Canetti, Co-chair, IETF Working Group on Multicast Security --0-1086017990-1049731354=:86999 Content-Type: text/html; charset=us-ascii

Call for Papers
==============

Internetworking 2003, June 22-24, 2003, San Jose, California
http://www.caitr.org/internetworking03/index.htm

REMINDER: Deadline for submissions is April 11, 2003

The Internetworking 2003 Technical Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following:

- Voice over IP (VoIP)
- IP Video Conferencing
- Storage Area Networks (SANs)
- Unicast and Multicast Routing and Convergence
- QoS Routing
- Network Security and Service Integration
- Operational Support Systems
- Virtual Private Networks
- Internetworking Wireless LANs and 3G Wireless Networks
- IP-based Infrastructure for Wireless Networks
- Internetworking IP and Optical Networks
- Internetworking MPLS with Legacy ATM and Frame Relay Networks
- Transition from IPv4 to IPv6 and interworking
- Pervasive Computing
- High Speed Transport Layer Protocols
- Peer to Peer Networking and Grid Computing
- Video Teleconferencing (VTC)
- 802.11 Hotspots

Conference Technical Co-chairs:
- Dr. Maurice Gagnaire, ENST, France
- Daniel Awduche

Technical Program Committee of the Internetworking 2003 Conference:
- Roberto Sabella, Erisson
- Dr. Moshe Zukerman, Univ. of Melbourne
- Nada Golmie, NIST
- Dr. Guy Pujolle, LIP6, France
- Dr. Samir Tohme, ENST, France
- Stefano Trumpy, Italian National Research Council
- Dr. Ibrahim Habib, City Univ. of NY
- Dr. Vishal Sharma, Metanoia
- Dr. Parviz Yegani, Cisco Systems
- Dr. G.S. Kuo
- Dr. Abbas Jamalipour, Univ. of Sydney
- Dr. Hussein Mouftah, Univ. of Ottawa
- James Kempf
- Elizabeth Rodriguez, Co-chair, IETF Working Group on IP Storage
- Dr. Ferit Yegenoglu, Isocore
- Dr. Ali Zadeh, George Mason University
- Tony Przygienda, Co-chair, IETF Working Group on IS-IS for IP Internets
- Ran Canetti, Co-chair, IETF Working Group on Multicast Security

--0-1086017990-1049731354=:86999-- From owner-aaa-wg@merit.edu Wed Apr 9 06:22:21 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 GAA20261 for ; Wed, 9 Apr 2003 06:22:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1ECCD91232; Wed, 9 Apr 2003 06:24:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D286791235; Wed, 9 Apr 2003 06:24:39 -0400 (EDT) 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 27F6F91232 for ; Wed, 9 Apr 2003 06:24:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 062645E29D; Wed, 9 Apr 2003 06:24:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id 8495B5DE3C for ; Wed, 9 Apr 2003 06:24:37 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h39AOZI3027613; Wed, 9 Apr 2003 12:24:35 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2A4MMH8A>; Wed, 9 Apr 2003 12:24:36 +0200 Message-ID: From: "Harri Hakala (LMF)" To: "'aaa-wg@merit.edu'" , "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt Date: Wed, 9 Apr 2003 10:31:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk > Any comments on the relationship of this application to Parlay > section 12 and PayCircle? > > http://www.parlay.org/specs/3.2/es_20191512Charging.zip > > http://www.paycircle.org > > It seems that all of these are addressing the same basic issue of > authorization of services with possible reservation of credit on > the backend. Isn't the applicability of OSA/Parlay charging API limited to services that have been built using the OSA/Parlay framework?. I foresee that there are services built using other mechanisms and are therefore outside this framework. Our motivation is to define an IP-based accounting protocol to support credit based accounting by using the AAA infrastructure. Because the Diameter base protocol provides several features, which are required from this kind of application and because the Diameter and its accounting can be widely utilized we thought that the AAA framework and Diameter is a good choice for this kind of IP-based accounting protocol. I assume that there are several (and more and more are being developed) this kind of applications focusing on online payments and credit reservations using quite similar mechanisms, but having a bit different scope and framework. > A harmonization of terminology, and ideally attribute names and > data types would be worthwile. > > The IPDR.org (http://www.ipdr.org) group is looking at aspects of > performing > this harmonization. For some information on the separation > of information > model, from encoding from transport see: > > http://www.circumference.org/circumference.ppt A harmonization of terminology, etc, defined by different standardization bodies, would be helpful, although it might be quite challenging task. It would be good if you can provide us with proposals for changed text in the draft. Regards.........Harri > -----Original Message----- > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] > Sent: 9. huhtikuuta 2003 2:56 > To: Harri Hakala (LMF); aaa-wg@merit.edu > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > Harri, > > Any comments on the relationship of this application to Parlay > section 12 and PayCircle? > > http://www.parlay.org/specs/3.2/es_20191512Charging.zip > > http://www.paycircle.org > > It seems that all of these are addressing the same basic issue of > authorization of services with possible reservation of credit on > the backend. > > A harmonization of terminology, and ideally attribute names and > data types would be worthwile. > > The IPDR.org (http://www.ipdr.org) group is looking at aspects of > performing > this harmonization. For some information on the separation > of information > model, from encoding from transport see: > > http://www.circumference.org/circumference.ppt > > > Regards, > > Jeff Meyer > HP > http://www.hp.com/usage > > > > > -----Original Message----- > > From: Harri Hakala (LMF) [mailto:Harri.Hakala@lmf.ericsson.se] > > Sent: Friday, February 28, 2003 1:55 AM > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > > > > Hi All, > > > > We have submitted a new version of the Diameter credit control draft > > to the IETF archive. > > > > Until it shows up in the archive, it can be found: > > http://standards.ericsson.net/harri/draft-hakala-diameter-cred > it-control-06.txt > > Here is a list of updates compared to draft -05: > 1. A server or client is not required to implement all > functionality in > the CCA. The optionality has been clarified in the draft, the > modified > AVPs are the following: > > 1a. Unknown/unsupported value responded with error: > - Subscription-Id-Type > > 1b. Unknown AVP ignored, i.e. 'M'-bit removed from AVP Flag table > - Accounting-Correlation-Id > - Abnormal-Termination-Reason > - Cost-Information > > 2. New Result-Code value 'DIAMETER_RATING_FAILED'. > > We would appreciate if you can read it and provide your comments. > > Regards.......Harri > From owner-aaa-wg@merit.edu Wed Apr 9 06:22:48 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 GAA20287 for ; Wed, 9 Apr 2003 06:22:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E377B91236; Wed, 9 Apr 2003 06:25:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF3ED91235; Wed, 9 Apr 2003 06:25:08 -0400 (EDT) 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 0170991238 for ; Wed, 9 Apr 2003 06:25:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CDFBE5E34E; Wed, 9 Apr 2003 06:25:05 -0400 (EDT) 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 F34825E348 for ; Wed, 9 Apr 2003 06:25:04 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h39ANTV24594 for ; Wed, 9 Apr 2003 13:23:29 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 9 Apr 2003 13:25:03 +0300 Received: from beebh002.NOE.Nokia.com ([172.28.19.40]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Apr 2003 13:25:02 +0300 Received: from beebe003.NOE.Nokia.com ([172.28.19.30]) by beebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Apr 2003 18:24:39 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FE82.3992BA4E" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: [AAA-WG]: [AAA-WG] Some remarks on Session Mobility Date: Wed, 9 Apr 2003 18:24:38 +0800 Message-ID: Thread-Topic: [AAA-WG] Some remarks on Session Mobility Thread-Index: AcL+gjluJ6B4g/CoQdqGwokrvFQs/A== From: To: X-OriginalArrivalTime: 09 Apr 2003 10:24:39.0247 (UTC) FILETIME=[3A05FDF0:01C2FE82] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2FE82.3992BA4E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 To help the "Diameter Session Mobility" draft is better recognized, some = addtional information is provided here. =20 =20 Requirement in Mobile Network AAA: 1. A localized AAA service for mobile nodes; 2. Handling real-time services' unsolicited messages (eg. STR) for = roaming mobile nodes. =20 What we propose: 1. An hierarchy AAA service via the dynamic maintenance of Diameter User = Session; 2. An anchor AAA server acts as secure proxy towards Mobile node's Home = AAA server (work well with CMS application). =20 Why this approach? 1. Why local AAA servers are also involved? ARs can not maintain a passing-by MN's information for long time, = and then we can not expect ARs forward messages hop by hop. =20 2. When Diameter User Session is updated? Under study. And "After handover" is recommended, if the handover is = from a trusted AR. =20 3. Why roundtrips? This approach is helpful when the Mobile Node is far away from where = it should be authenticated. Under such situation, this approach is = time-effective. =20 4. Why information exchange between local AAA servers? It helps the Mobile Node being authenticated locally, and also helps = the Diameter User Session is explicitly maintained within: (AAAH) - (Anchor AAA server) - (local AAA server) - (current AR) =20 =20 Best regards, roger ------_=_NextPart_001_01C2FE82.3992BA4E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
To help the "Diameter Session Mobility" = draft is=20 better recognized, some addtional information is provided=20 here.
 
 
Requirement in Mobile Network=20 AAA:
1. A localized AAA service for mobile=20 nodes;
2. Handling real-time services' unsolicited = messages=20 (eg. STR) for roaming mobile nodes.
 
What we propose:
1. An hierarchy AAA service via the dynamic = maintenance=20 of Diameter User Session;
2. An anchor AAA server acts as secure proxy = towards=20 Mobile node's Home AAA server (work well with CMS=20 application).
 
Why this approach?
1. Why local AAA servers are also=20 involved?
    ARs can not maintain a = passing-by=20 MN's information for long time, and then we can not expect ARs forward = messages=20 hop by hop.
 
2. When Diameter User Session is=20 updated?
    Under = study. And "After=20 handover" is recommended, if the handover is from a trusted=20 AR.
 
3. Why roundtrips?
    This approach is helpful = when the=20 Mobile Node is far away from where it should be = authenticated. Under such=20 situation, this approach is time-effective.
 
4. Why information exchange between local AAA = servers?
    It helps = the Mobile=20 Node being authenticated locally, and also=20 helps the Diameter User Session is explicitly=20 maintained within:
  (AAAH) - (Anchor AAA server) - = (local AAA=20 server) - (current AR)
 
 
Best regards,
roger
------_=_NextPart_001_01C2FE82.3992BA4E-- From owner-aaa-wg@merit.edu Wed Apr 9 23:05: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 XAA24347 for ; Wed, 9 Apr 2003 23:05:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 54E8E9122C; Wed, 9 Apr 2003 23:07:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 267579123F; Wed, 9 Apr 2003 23:07:53 -0400 (EDT) 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 580FA9122C for ; Wed, 9 Apr 2003 23:07:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 46A8E5DE5E; Wed, 9 Apr 2003 23:07:51 -0400 (EDT) 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 541555DE51 for ; Wed, 9 Apr 2003 23:07:50 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3A36EJ13598 for ; Thu, 10 Apr 2003 06:06:14 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 10 Apr 2003 06:07:48 +0300 Received: from beebh001.NOE.Nokia.com ([172.28.19.38]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Apr 2003 06:07:48 +0300 Received: from beebe003.NOE.Nokia.com ([172.28.19.30]) by beebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Apr 2003 11:07:18 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [AAA-WG]: Concern about Diameter disconnect and dynamic authorization Date: Thu, 10 Apr 2003 11:07:18 +0800 Message-ID: Thread-Topic: [AAA-WG]: Concern about Diameter disconnect and dynamic authorization Thread-Index: AcL7/dQXKEGRsNYJSlSFV7VuPnNRWADDr+zw From: To: , X-OriginalArrivalTime: 10 Apr 2003 03:07:18.0932 (UTC) FILETIME=[4BFD6D40:01C2FF0E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA24347 Hi, I suppose some implementation specific practices can help in the example you refered, such as: The NAS can be designed to terminate a diameter user session only provided with the right value of Session-Id AVP and its corresponding User-Name AVP , and other ISPs are not likely to be able to guess the right values unless they own the NAS. Best regards, roger > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: Sunday, April 06, 2003 1:13 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Concern about Diameter disconnect and > dynamic authorization > > > We've just been through a bit of a security firedrill with > respect to the > following draft: > > http://www.drizzle.com/~aboba/IEEE/draft-chiba-radius-dynamic- > authorization-11.txt > > While a bunch of the issues found here do *not* afflict Diameter > disconnect and dynamic authorization operations (since Diameter uses > ordinary Request/Response mechanisms for authorization > changes), it seems > to me that other issues *are* relevant. > > For example, there is the question of how a NAS or proxy > decides whether a > disconnect or dynamic authorization request is appropriate. > Authentication > is not enough for this -- we would not want one ISP to be able to > disconnect users from another ISP on a shared use NAS, for example. > > It seems to me that to some extent the mechanisms used to identify a > session for these operations are application specific -- and therefore > that the issues need to be addressed in the Diameter > Application specs, > rather than Base. > > However, in looking at the RAR and STR messages in Diameter, it would > appear that they lack the basic facilities necessary to do a > reverse path > check (RPF) as described in the above draft. In addition, they > lack the NAS and session identification AVPs that would appear to > be necessary for proper identification. Therefore the RAR and STR > messages defined in Diameter Base probably can't be used in > applications > without defining additional AVPs. > > I am assuming that the intent in Diameter Base is just to > define the basic > commands and allow individual applications to specify how > they are used in > more detail. However Diameter NASREQ nor Diameter MIPv4 contain the > required details -- which leads me to believe that this is a > more basic > problem that reflects some gaps in thinking about how these commands > really work? > > Comments? > > From owner-aaa-wg@merit.edu Thu Apr 10 06:42: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 GAA14697 for ; Thu, 10 Apr 2003 06:42:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A0F1091245; Thu, 10 Apr 2003 06:44:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7099591246; Thu, 10 Apr 2003 06:44:44 -0400 (EDT) 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 5A76791245 for ; Thu, 10 Apr 2003 06:44:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2874F5DF34; Thu, 10 Apr 2003 06:44:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id A65335DE56 for ; Thu, 10 Apr 2003 06:44:41 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3AAiSI4028689; Thu, 10 Apr 2003 12:44:28 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2TCYBYDM>; Thu, 10 Apr 2003 12:44:29 +0200 Message-ID: From: "Harri Hakala (LMF)" To: "'aaa-wg@merit.edu'" , "'Avi Lior'" Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt Date: Thu, 10 Apr 2003 12:09:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Avi, (I assume that your mail was pointed to the aaa-mailing list.) It is associated with accounting because of rating and billing. The requested service must be rated before granting any quotas to the client. This is needed in order to decide whether the end user's account covers the requested service and to be able to grant right amount of quotas. So the rating itself that is needed for the decision is more related to accounting functionality than authorization. And since the prepaid server will decrease the account during the session in order to bill to user for the usage of the service the billing as well is accounting related functionality. In order to rate the service, rating input parameters are needed, that is the authorization commands would need to carry all the rating input parameters. The server also must return some control parameters to the client (e.g. access device), so that the client can monitor the service execution according to the instructions returned by the server. Because the access device doesn't necessarily know if the user is postpaid or prepaid, then all authentication and authorization requests would need to carry rating input parameters, also in case of postpaid users. Also there might be some existing service specific authentication and authorization protocols, which then need to be updated to include these parameters. The client may need more quotas during the services and it may send interim request to the server requesting more quotas and reporting used quotas, i.e. session based credit control (or prepaid). The Diameter base accounting supports session based accounting (start, interim and stop) and this suits very well for credit control as well. This is also one reason why we want to associate the credit control application with the accounting, i.e. only few additional AVPs + new accounting state machines (credit control session state machines) are needed. When session based credit control is used then credit control server must maintain the session. If authorization commands would be used, then during initial authorization the authorization server should establish the session towards credit control server in order to perform 'prepaid authorization'. Then the re-authorization for additional quotas during the session should flow through the AAA server to the prepaid server, adding an extra stateful hop (proxy, translator) in the signaling. When using accounting commands the client can communicate directly with the prepaid server. You are right the draft is not just for the 3GPP and of course they also authenticate and authorize the subscriber for the network access and for the services as well. For instance for multimedia services the Diameter Multimedia Application can be used. Regards......Harri > -----Original Message----- > From: Avi Lior [mailto:avi.lior@bridgewatersystems.com] > Sent: 9. huhtikuuta 2003 22:18 > To: Harri Hakala (LMF); 'www-wg@merit.edu' > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > Hi, > > I have a question. Why is Credit Application associated with > accounting? > > Seems to me that granting prepaid quotas is really an authorization > exercise. You are authorizing the subscriber to use a service > for a period > of time. > > This may seem like a petty philosophical point however it > does have serious > technical ramification. One of them that I have a huge > concern over is a > timing issue. In past implementations, for practical reasons > we had to > solve these timing issues by combining Service Authorization > and Prepaid > Authorization. > > The home AAA during authentication discovers that the user > requires prepaid > and then request prepaid authorization. If all is > successful, the prepaid > authorization(typically a quota) and the service > authorization are sent to > the Access Device. > > Making it an accounting activity decouples it from > Authorization and creates > these problems. My opinion is that accounting should be used > for reporting > -- we still need real-time accounting. But when we are > applying controls > these should be related to Authentication and Authorization commands. > > I realize that in 3GPP this won't be an issue -- because you > are not really > authenticating the subscriber. But this is not just a 3GPP > specification -- > right? > > Comments? > > > From owner-aaa-wg@merit.edu Thu Apr 10 09:15:04 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 JAA19127 for ; Thu, 10 Apr 2003 09:15:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5A4B79124B; Thu, 10 Apr 2003 09:17:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2BFAB9124C; Thu, 10 Apr 2003 09:17:20 -0400 (EDT) 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 8F0129124B for ; Thu, 10 Apr 2003 09:17:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 519045DF77; Thu, 10 Apr 2003 09:16:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 97F3C5DF6F for ; Thu, 10 Apr 2003 09:16:41 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3ACwUd28217; Thu, 10 Apr 2003 05:58:30 -0700 Date: Thu, 10 Apr 2003 05:58:30 -0700 (PDT) From: Bernard Aboba To: "Harri Hakala (LMF)" Cc: "'aaa-wg@merit.edu'" , "'Avi Lior'" Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > So the rating itself that is needed for the > decision is more related to accounting functionality than authorization. Are we assuming that the accounting and authorizations servers are separate and that only the accounting server has access to the rating engine? > And since the prepaid server will decrease the account during the > session in order to bill to user for the usage of the service the > billing as well is accounting related functionality. Is it possible for the rate to change unexpectedly, so that the session time cannot be calculated at session initiation? In other words, is interim accounting required for this application? > In order to rate the service, rating input parameters are needed, > that is the authorization commands would need to carry all the rating > input parameters. Since authorization and accounting commands contain the same information, why wouldn't this be true for accounting commands, too? > Because the access device doesn't necessarily know if the user is > postpaid or prepaid, then all authentication and authorization requests > would need to carry rating input parameters, also in case of postpaid users. Why wouldn't accounting requests also need those parameters? > When session based credit control is used then credit control server must > maintain the session. If authorization commands would be used, then > during initial authorization the authorization server should establish the > session towards credit control server in order to perform 'prepaid > authorization'. Yes. From owner-aaa-wg@merit.edu Thu Apr 10 13:05:09 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 NAA26622 for ; Thu, 10 Apr 2003 13:05:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A47DF91255; Thu, 10 Apr 2003 13:07:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C07991256; Thu, 10 Apr 2003 13:07:29 -0400 (EDT) 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 D658991255 for ; Thu, 10 Apr 2003 13:07:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B422A5DDA7; Thu, 10 Apr 2003 13:07:27 -0400 (EDT) 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 9045D5DD8C for ; Thu, 10 Apr 2003 13:07:27 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel6.hp.com (Postfix) with ESMTP id 6BB2D1C02494 for ; Thu, 10 Apr 2003 13:07:27 -0400 (EDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 6445E1C009F5 for ; Thu, 10 Apr 2003 13:07:27 -0400 (EDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2655.55) id <2JYAA64A>; Thu, 10 Apr 2003 13:07:27 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A566B9BF@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Diameter Credit, Parlay, PayCircle and IPDR... Date: Thu, 10 Apr 2003 13:07:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I'm forwarding this e-mail, because it didn't initially appear on the list due to mailer issues on my end. Regards, Jeff Meyer -----Original Message----- From: MEYER,JEFFREY D (HP-Cupertino,ex1) Sent: Wednesday, April 09, 2003 9:02 AM To: 'Harri Hakala (LMF)'; 'aaa-wg@merit.edu'; MEYER,JEFFREY D (HP-Cupertino,ex1) Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt Harri, Thanks for the response. Regarding the domain of Parlay, I'd agree it presumes a Parlay framework. However, it also has an "Information Model" aimed at addressing the same credit control space as your draft, so to that end trying to align these information models is where the use of a common model for describing the information payload in a manner independent of encoding and transport is where IPDR can come into play. I know there was work on a dictionary framework in the Diameter group, but that seems to have stalled out. What I would like to do is resurrect that model, but using IPDR's XML-Schema with annotation approach. This would likely require a draft on its own, I'll begin looking into that. I'll also look to see if there is some "placeholder" language which would be appropriate for the credit control draft. Regards, Jeff Meyer > -----Original Message----- > From: Harri Hakala (LMF) [mailto:Harri.Hakala@lmf.ericsson.se] > Sent: Wednesday, April 09, 2003 1:31 AM > To: 'aaa-wg@merit.edu'; 'MEYER,JEFFREY D (HP-Cupertino,ex1)' > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > > Any comments on the relationship of this application to Parlay > > section 12 and PayCircle? > > > > http://www.parlay.org/specs/3.2/es_20191512Charging.zip > > > > http://www.paycircle.org > > > > It seems that all of these are addressing the same basic issue of > > authorization of services with possible reservation of credit on > > the backend. > > Isn't the applicability of OSA/Parlay charging API limited to > services that > have been built using the OSA/Parlay framework?. > I foresee that there are services built using other > mechanisms and are therefore > outside this framework. > > Our motivation is to define an IP-based accounting protocol > to support credit > based accounting by using the AAA infrastructure. Because the > Diameter base > protocol provides several features, which are required from > this kind of application > and because the Diameter and its accounting can be widely > utilized we thought that > the AAA framework and Diameter is a good choice for this kind > of IP-based accounting > protocol. > > I assume that there are several (and more and more are being > developed) this kind of > applications focusing on online payments and credit > reservations using quite similar > mechanisms, but having a bit different scope and framework. > > > A harmonization of terminology, and ideally attribute names and > > data types would be worthwile. > > > > The IPDR.org (http://www.ipdr.org) group is looking at aspects of > > performing > > this harmonization. For some information on the separation > > of information > > model, from encoding from transport see: > > > > http://www.circumference.org/circumference.ppt > > A harmonization of terminology, etc, defined by different > standardization bodies, > would be helpful, although it might be quite challenging task. > > It would be good if you can provide us with proposals for > changed text in the draft. > > Regards.........Harri > > > -----Original Message----- > > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] > > Sent: 9. huhtikuuta 2003 2:56 > > To: Harri Hakala (LMF); aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > > > > Harri, > > > > Any comments on the relationship of this application to Parlay > > section 12 and PayCircle? > > > > http://www.parlay.org/specs/3.2/es_20191512Charging.zip > > > > http://www.paycircle.org > > > > It seems that all of these are addressing the same basic issue of > > authorization of services with possible reservation of credit on > > the backend. > > > > A harmonization of terminology, and ideally attribute names and > > data types would be worthwile. > > > > The IPDR.org (http://www.ipdr.org) group is looking at aspects of > > performing > > this harmonization. For some information on the separation > > of information > > model, from encoding from transport see: > > > > http://www.circumference.org/circumference.ppt > > > > > > Regards, > > > > Jeff Meyer > > HP > > http://www.hp.com/usage > > > > > > > > > -----Original Message----- > > > From: Harri Hakala (LMF) [mailto:Harri.Hakala@lmf.ericsson.se] > > > Sent: Friday, February 28, 2003 1:55 AM > > > To: aaa-wg@merit.edu > > > Subject: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > > > > > > > Hi All, > > > > > > We have submitted a new version of the Diameter credit > control draft > > > to the IETF archive. > > > > > > Until it shows up in the archive, it can be found: > > > http://standards.ericsson.net/harri/draft-hakala-diameter-cred > > it-control-06.txt > > > > Here is a list of updates compared to draft -05: > > 1. A server or client is not required to implement all > > functionality in > > the CCA. The optionality has been clarified in the draft, the > > modified > > AVPs are the following: > > > > 1a. Unknown/unsupported value responded with error: > > - Subscription-Id-Type > > > > 1b. Unknown AVP ignored, i.e. 'M'-bit removed from AVP Flag table > > - Accounting-Correlation-Id > > - Abnormal-Termination-Reason > > - Cost-Information > > > > 2. New Result-Code value 'DIAMETER_RATING_FAILED'. > > > > We would appreciate if you can read it and provide your comments. > > > > Regards.......Harri > > > From owner-aaa-wg@merit.edu Thu Apr 10 13:17: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 NAA27009 for ; Thu, 10 Apr 2003 13:17:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 523989125F; Thu, 10 Apr 2003 13:19:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC54E91262; Thu, 10 Apr 2003 13:19:08 -0400 (EDT) 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 629819125F for ; Thu, 10 Apr 2003 13:18:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4DFFC5DDA8; Thu, 10 Apr 2003 13:18:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by segue.merit.edu (Postfix) with ESMTP id 0E2D35DD8C for ; Thu, 10 Apr 2003 13:18:58 -0400 (EDT) Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62]) by palrel11.hp.com (Postfix) with ESMTP id 902C81C01F68; Thu, 10 Apr 2003 10:18:57 -0700 (PDT) Received: from xpabh2.ptp.hp.com (xpabh2.ptp.hp.com [15.1.28.61]) by xparelay1.ptp.hp.com (Postfix) with ESMTP id 1131A1004BAB; Thu, 10 Apr 2003 10:18:57 -0700 (PDT) Received: by xpabh2.ptp.hp.com with Internet Mail Service (5.5.2655.55) id <2VKR1JAM>; Thu, 10 Apr 2003 10:18:57 -0700 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A566B9C0@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Harri Hakala (LMF)'" , "'aaa-wg@merit.edu'" , "'Avi Lior'" Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt Date: Thu, 10 Apr 2003 10:18:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I would draw a key distinction between prepay and postpay scenarios. I view postpay scenarios as needing only "accounting" operations. However, prepay scenarios, require some entity to authorize the use of the service based not just on user privileges, but also on whether they have sufficient funds. This implies that the authorization path now will likely touch not just some relatively static LDAP store of users and privileges, but also touch some "balance manager". I've tried to draw the distinction in a couple of sequence diagrams available at: http://www.circumference.org/circumference.ppt I would say it is an open question for an application developer as to how and when they distinguish between pre and postpay users, assuming the service element will have a mix of both. Another open question is whether there is a class of application developers which would prefer to use an XML/WebServices style prepay application vs. a binary protocol such as Diameter. PayCircle is in the process of defining a similar XML/WebService model for applications to provide credit control. Regards, Jeff Meyer > -----Original Message----- > From: Harri Hakala (LMF) [mailto:Harri.Hakala@lmf.ericsson.se] > Sent: Thursday, April 10, 2003 3:09 AM > To: 'aaa-wg@merit.edu'; 'Avi Lior' > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > Hi Avi, > > (I assume that your mail was pointed to the aaa-mailing list.) > > It is associated with accounting because of rating and billing. > The requested service must be rated before granting any quotas > to the client. This is needed in order to decide whether the end > user's account covers the requested service and to be able to grant > right amount of quotas. So the rating itself that is needed for the > decision is more related to accounting functionality than > authorization. > And since the prepaid server will decrease the account during the > session in order to bill to user for the usage of the service the > billing as well is accounting related functionality. > > In order to rate the service, rating input parameters are needed, > that is the authorization commands would need to carry all the rating > input parameters. The server also must return some control > parameters to > the client (e.g. access device), so that the client can > monitor the service > execution according to the instructions returned by the server. > > Because the access device doesn't necessarily know if the user is > postpaid or prepaid, then all authentication and > authorization requests > would need to carry rating input parameters, also in case of > postpaid users. > Also there might be some existing service specific authentication and > authorization protocols, which then need to be updated to > include these > parameters. > > The client may need more quotas during the services and it may send > interim request to the server requesting more quotas and > reporting used > quotas, i.e. session based credit control (or prepaid). The > Diameter base > accounting supports session based accounting (start, interim > and stop) > and this suits very well for credit control as well. This is also one > reason why we want to associate the credit control > application with the > accounting, i.e. only few additional AVPs + new accounting > state machines > (credit control session state machines) are needed. > > When session based credit control is used then credit control > server must > maintain the session. If authorization commands would be used, then > during initial authorization the authorization server should > establish the > session towards credit control server in order to perform 'prepaid > authorization'. Then the re-authorization for additional > quotas during the > session should flow through the AAA server to the prepaid > server, adding an > extra stateful hop (proxy, translator) in the signaling. When using > accounting commands the client can communicate directly with > the prepaid > server. > > You are right the draft is not just for the 3GPP and of > course they also > authenticate and authorize the subscriber for the network access and > for the services as well. For instance for multimedia services the > Diameter Multimedia Application can be used. > > Regards......Harri > > > -----Original Message----- > > From: Avi Lior [mailto:avi.lior@bridgewatersystems.com] > > Sent: 9. huhtikuuta 2003 22:18 > > To: Harri Hakala (LMF); 'www-wg@merit.edu' > > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > > > > Hi, > > > > I have a question. Why is Credit Application associated with > > accounting? > > > > Seems to me that granting prepaid quotas is really an authorization > > exercise. You are authorizing the subscriber to use a service > > for a period > > of time. > > > > This may seem like a petty philosophical point however it > > does have serious > > technical ramification. One of them that I have a huge > > concern over is a > > timing issue. In past implementations, for practical reasons > > we had to > > solve these timing issues by combining Service Authorization > > and Prepaid > > Authorization. > > > > The home AAA during authentication discovers that the user > > requires prepaid > > and then request prepaid authorization. If all is > > successful, the prepaid > > authorization(typically a quota) and the service > > authorization are sent to > > the Access Device. > > > > Making it an accounting activity decouples it from > > Authorization and creates > > these problems. My opinion is that accounting should be used > > for reporting > > -- we still need real-time accounting. But when we are > > applying controls > > these should be related to Authentication and Authorization > commands. > > > > I realize that in 3GPP this won't be an issue -- because you > > are not really > > authenticating the subscriber. But this is not just a 3GPP > > specification -- > > right? > > > > Comments? > > > > > > > From owner-aaa-wg@merit.edu Fri Apr 11 02:34: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 CAA01198 for ; Fri, 11 Apr 2003 02:34:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D082D9124E; Fri, 11 Apr 2003 02:36:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 980C49126E; Fri, 11 Apr 2003 02:36:46 -0400 (EDT) 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 8A07E9124E for ; Fri, 11 Apr 2003 02:36:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 65B205DEB0; Fri, 11 Apr 2003 02:36:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id E1DF55DE9B for ; Fri, 11 Apr 2003 02:36:44 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3B6ZtI3015920; Fri, 11 Apr 2003 08:35:55 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2VALR07K>; Fri, 11 Apr 2003 08:35:56 +0200 Message-ID: From: "Harri Hakala (LMF)" To: "'Bernard Aboba'" Cc: "'aaa-wg@merit.edu'" , "'Avi Lior'" Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt Date: Fri, 11 Apr 2003 08:35:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk > > So the rating itself that is needed for the > > decision is more related to accounting functionality than > authorization. > > Are we assuming that the accounting and authorizations servers are > separate and that only the accounting server has access to the rating > engine? The accounting and authorization servers do not need to be separate, but very often they are and only the accounting server or prepaid server has access to the rating engine. > > And since the prepaid server will decrease the account during the > > session in order to bill to user for the usage of the service the > > billing as well is accounting related functionality. > > Is it possible for the rate to change unexpectedly, so that > the session > time cannot be calculated at session initiation? In other words, is > interim accounting required for this application? Yes, the rate can change unexpectedly and interim request may be needed. > > In order to rate the service, rating input parameters are needed, > > that is the authorization commands would need to carry all > the rating > > input parameters. > > Since authorization and accounting commands contain the same > information, > why wouldn't this be true for accounting commands, too? It is true for accounting commands as well. But would it be better to have just one prepaid (credit control) application to carry these parameters, instead of updating all authentication and authorization protocols to carry service specific rating parameters. And because the rating is more related to accounting functionality than authorization would it then more logical to use accounting commands. > > Because the access device doesn't necessarily know if the user is > > postpaid or prepaid, then all authentication and > authorization requests > > would need to carry rating input parameters, also in case > of postpaid users. > > Why wouldn't accounting requests also need those parameters? Yes, the accounting request needs these parameter as well. But are these parameters needed for *all* the authentication and authorization commands as well?. The result from authentication and authorization can be only postpaid (=accounting) and then only accounting commands need carry these parameters. From owner-aaa-wg@merit.edu Fri Apr 11 03: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 DAA02792 for ; Fri, 11 Apr 2003 03:54:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 74ACD9126E; Fri, 11 Apr 2003 03:56:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 320FF9126F; Fri, 11 Apr 2003 03:56:52 -0400 (EDT) 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 860789126E for ; Fri, 11 Apr 2003 03:56:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 744465DED8; Fri, 11 Apr 2003 03:56:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id E46A35DED7 for ; Fri, 11 Apr 2003 03:56:49 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3B7uSI4009963; Fri, 11 Apr 2003 09:56:28 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2VALSXDJ>; Fri, 11 Apr 2003 09:56:29 +0200 Message-ID: From: "Harri Hakala (LMF)" To: "'aaa-wg@merit.edu'" , "'Avi Lior'" Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt Date: Fri, 11 Apr 2003 09:56:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, You seem to forget the other aspect of prepaid: it's not only about the credit check at the beginning of the service but also about *paying* of the service, i.e. billing of the service in real-time. The accounting is defined to be a process of collecting information for billing (among other things) done by a billing server. In credit control application we collect the information for the same purpose (billing) but the process is done in real-time, not as a batch process in some back-end server. I agree, the current credit control architecture might be too restricted when it specifies that the dialogue can be only between the service node and the credit control server. We could extend it to cover the (H)AAA server as well so that the HAAA can use the credit control commands towards the prepaid server. The communication between the service node and (H)AAA would be out of the scope of the draft. Some further comments below. Regards..................Harri N.B. You seem to have a problem with sending the messages to the aaa-wg-mailing list since they don't appear in the mailing list. Have you subscribed to the mailing list with the same id that you are using when posting the messages? > > It is associated with accounting because of rating and billing. > > The requested service must be rated before granting any > > quotas to the client. This is needed in order to decide > > whether the end user's account covers the requested service > > and to be able to grant right amount of quotas. So the rating > > itself that is needed for the decision is more related to > > accounting functionality than authorization. And since the > > prepaid server will decrease the account during the > > session in order to bill to user for the usage of the service the > > billing as well is accounting related functionality. > > The above can happen during the Authentication and > Authorization phase. Yes, it can happen during that *phase* but the rating and the billing part is not part of Authentication and Authorization functionality. > This is not a problem. The HAAA can communicate the Service > requested right > after it authenticated the user and determined what service > the user will > get. It can pass these to the Prepaid application. All results > (authorization parameters for both prepaid and service are > then passed back > to the access device) Wouldn't this mean that then all the authorization requests would have to contain all the accounting parameters so that the HAAA can pass them to the prepaid server for rating? Wouldn't you have to update all the existing (and future) authentication & authorization applications to support online accounting (prepaid)? > > Because the access device doesn't necessarily know if the user is > > postpaid or prepaid, then all authentication and > > authorization requests would need to carry rating input > > parameters, also in case of postpaid users. Also there might > > be some existing service specific authentication and > > authorization protocols, which then need to be updated to > > include these > > parameters. > > The HAAA knows what service the user wants. The rating > engine will have the > rating information anyway. So I don't see the problem here. I would imagine that the rating input (at least most of it) would come from the access device, not from HAAA. Therefore your authentication & authorizations commands should be able to carry those. > Asking for more quotas can be achieved by authorization > requests. After all > it is a reauthorization operation. You are authorizing the > user to continue > to use the session. Infact, because in RADIUS accounting > messages are not > acted on -- they are used for recording -- and in fact, they can be > processed in batch by proxies (and hence are not real-time), > these operation > really should be done using Access Request messages. Might be true for RADIUS. I haven't seen any such statements for Diameter accounting messages. > -----Original Message----- > From: Avi Lior [mailto:avi.lior@bridgewatersystems.com] > Sent: 10. huhtikuuta 2003 18:42 > To: Harri Hakala (LMF); 'aaa-wg@merit.edu'; Avi Lior > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > Hi Harri, > > I have comments inline as well as: > > So first let me say this: lets not confuse the operation type > with the type > of server that is performing the operation. Is the Prepaid server an > accounting server -- lets say it is. Should the messages be > accounting > messages -- Not necessarily. An accounting server should handle > authorization type requests. Just like a bank can handle an > authorization > type requests. But this is a minor issue. > > The Credit Application in my opinion *must* be capable of > allowing me to > authenticate a user and both authorize the user for a service > and authorize > the user for prepaid in the *same* Access Request phase. > > So an Access Device issues an Access Request advertizing the > its Prepaid > Capabilities. Since it doesn't know the apriori whether the user is a > prepaid user or not it would issue the Prepaid Capabilities > in every Access > Request. The Home AAA will then Authenticate the user and > determine a) > where the user is prepaid or not; and b) the type of service. > If the user > is prepaid it will then contact the Prepaid Server to further > authorize the > subscriber. If the prepaid authorization is successful, the > HAAA will then > respond back to the access device with the service > authorization parameters > and the prepaid authorization parameters. > > Can this be done with the Diameter Credit Control application? > > > > -----Original Message----- > > From: Harri Hakala (LMF) [mailto:Harri.Hakala@lmf.ericsson.se] > > Sent: Thursday, April 10, 2003 6:09 AM > > To: 'aaa-wg@merit.edu'; 'Avi Lior' > > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > > > > Hi Avi, > > > > (I assume that your mail was pointed to the aaa-mailing list.) > > > > It is associated with accounting because of rating and billing. > > The requested service must be rated before granting any > > quotas to the client. This is needed in order to decide > > whether the end user's account covers the requested service > > and to be able to grant right amount of quotas. So the rating > > itself that is needed for the decision is more related to > > accounting functionality than authorization. And since the > > prepaid server will decrease the account during the > > session in order to bill to user for the usage of the service the > > billing as well is accounting related functionality. > > The above can happen during the Authentication and > Authorization phase. > > > In order to rate the service, rating input parameters are > > needed, that is the authorization commands would need to > > carry all the rating input parameters. The server also must > > return some control parameters to the client (e.g. access > > device), so that the client can monitor the service execution > > according to the instructions returned by the server. > > This is not a problem. The HAAA can communicate the Service > requested right > after it authenticated the user and determined what service > the user will > get. It can pass these to the Prepaid application. All results > (authorization parameters for both prepaid and service are > then passed back > to the access device) > > > Because the access device doesn't necessarily know if the user is > > postpaid or prepaid, then all authentication and > > authorization requests would need to carry rating input > > parameters, also in case of postpaid users. Also there might > > be some existing service specific authentication and > > authorization protocols, which then need to be updated to > > include these > > parameters. > > The HAAA knows what service the user wants. The rating > engine will have the > rating information anyway. So I don't see the problem here. > > > > > The client may need more quotas during the services and it may send > > interim request to the server requesting more quotas and > > reporting used quotas, i.e. session based credit control (or > > prepaid). The Diameter base accounting supports session based > > accounting (start, interim and stop) > > and this suits very well for credit control as well. This > is also one > > reason why we want to associate the credit control > > application with the > > accounting, i.e. only few additional AVPs + new accounting > > state machines (credit control session state machines) are needed. > > Asking for more quotas can be achieved by authorization > requests. After all > it is a reauthorization operation. You are authorizing the > user to continue > to use the session. Infact, because in RADIUS accounting > messages are not > acted on -- they are used for recording -- and in fact, they can be > processed in batch by proxies (and hence are not real-time), > these operation > really should be done using Access Request messages. > > > When session based credit control is used then credit control > > server must maintain the session. If authorization commands > > would be used, then during initial authorization the > > authorization server should establish the session towards > > credit control server in order to perform 'prepaid > > authorization'. > Well, in my opinion the Access Device talks to the HAAA. The > HAAA then talks > to the Prepaid System. Both results comeback to the Access Device. > > This is a Diameter problem which in my opinion needs to be > fixed. The HAAA > should be able to communicate with a prepaid server using your > specification. Both the resutls need to be combined and sent > back to the > Access Device. Diameter should allow me to do that. > > >Then the re-authorization for additional > > quotas during the session should flow through the AAA server > > to the prepaid server, adding an > > extra stateful hop (proxy, translator) in the signaling. When using > > accounting commands the client can communicate directly with > > the prepaid > > server. > > > > You are right the draft is not just for the 3GPP and of > > course they also > > authenticate and authorize the subscriber for the network > access and > > for the services as well. For instance for multimedia > > services the Diameter Multimedia Application can be used. > > If its not for 3GPP then I think my scenrio should be > considered. 3GPP2 > does it in one phase. There are timing issues. There is a > concern that to > phases will take too long. > > > Regards......Harri > > From owner-aaa-wg@merit.edu Fri Apr 11 06:34: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 GAA06226 for ; Fri, 11 Apr 2003 06:34:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4AA6591274; Fri, 11 Apr 2003 06:37:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1031191275; Fri, 11 Apr 2003 06:37:11 -0400 (EDT) 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 D9DD591274 for ; Fri, 11 Apr 2003 06:37:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C435F5DEC0; Fri, 11 Apr 2003 06:37:10 -0400 (EDT) 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 86CE75DDA6 for ; Fri, 11 Apr 2003 06:37:09 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3BAb8j11350 for ; Fri, 11 Apr 2003 13:37:08 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 11 Apr 2003 13:37:08 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 11 Apr 2003 13:37:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt Date: Fri, 11 Apr 2003 13:37:07 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E4554@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt Thread-Index: AcL///qtK3f4wREPR72OO6Dpoj1fDgAExgwA From: To: , Cc: X-OriginalArrivalTime: 11 Apr 2003 10:37:08.0519 (UTC) FILETIME=[4D735370:01C30016] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA06226 > I agree, the current credit control architecture might be too > restricted > when it specifies that the dialogue can be only between the > service node > and the credit control server. We could extend it to cover the (H)AAA > server as well so that the HAAA can use the credit control commands > towards the prepaid server. The communication between the > service node and > (H)AAA would be out of the scope of the draft. I would agree with this. > > The HAAA knows what service the user wants. The rating > > engine will have the > > rating information anyway. So I don't see the problem here. > > I would imagine that the rating input (at least most of it) would come > from the access device, not from HAAA. Therefore your > authentication & > authorizations commands should be able to carry those. I think we are focusing too much on access prepaid where it is obvious that the requested service is "network access". The intent of the CCA is a generic application to cover also other needs, we have also e.g. application servers that might implement a number of different applications then it is not so evident anymore for the HAAA to know what service the user wants if we don't have rating input in the request. Therefore the result is that all the authorization&authentication commands must be updated to carry those parameters. > > Asking for more quotas can be achieved by authorization > > requests. After all > > it is a reauthorization operation. You are authorizing the > > user to continue > > to use the session. Infact, because in RADIUS accounting > > messages are not > > acted on -- they are used for recording -- and in fact, they can be > > processed in batch by proxies (and hence are not real-time), > > these operation > > really should be done using Access Request messages. > > Might be true for RADIUS. I haven't seen any such statements > for Diameter > accounting messages. I haven't seen either. From owner-aaa-wg@merit.edu Fri Apr 11 08:37:11 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 IAA10209 for ; Fri, 11 Apr 2003 08:37:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 17D1E91279; Fri, 11 Apr 2003 08:39:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD6969127A; Fri, 11 Apr 2003 08:39:29 -0400 (EDT) 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 94C6091279 for ; Fri, 11 Apr 2003 08:39:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 74DF95DF8B; Fri, 11 Apr 2003 08:39:28 -0400 (EDT) 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 83E4C5DF14 for ; Fri, 11 Apr 2003 08:39:27 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3BCdQQ14009 for ; Fri, 11 Apr 2003 15:39:26 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 11 Apr 2003 15:39:26 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 11 Apr 2003 15:39:25 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 11 Apr 2003 15:39:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Concern about Diameter disconnect and dynamic authorization Date: Fri, 11 Apr 2003 15:39:05 +0300 Message-ID: Thread-Topic: [AAA-WG]: Concern about Diameter disconnect and dynamic authorization Thread-Index: AcL7/cjUZHJF45xBTfWxhBoeG3NLoAEKPA4w From: To: , X-OriginalArrivalTime: 11 Apr 2003 12:39:05.0933 (UTC) FILETIME=[56F817D0:01C30027] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA10209 Bernard, My assumption was that this kind of functionality would be driven by the applications, so that may be part of the reason this was 'forgotten' in the base. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 06 April, 2003 08:13 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Concern about Diameter disconnect and dynamic > authorization > > > We've just been through a bit of a security firedrill with > respect to the following draft: > > http://www.drizzle.com/~aboba/IEEE/draft-chiba-radius-dynamic- authorization-11.txt While a bunch of the issues found here do *not* afflict Diameter disconnect and dynamic authorization operations (since Diameter uses ordinary Request/Response mechanisms for authorization changes), it seems to me that other issues *are* relevant. For example, there is the question of how a NAS or proxy decides whether a disconnect or dynamic authorization request is appropriate. Authentication is not enough for this -- we would not want one ISP to be able to disconnect users from another ISP on a shared use NAS, for example. It seems to me that to some extent the mechanisms used to identify a session for these operations are application specific -- and therefore that the issues need to be addressed in the Diameter Application specs, rather than Base. However, in looking at the RAR and STR messages in Diameter, it would appear that they lack the basic facilities necessary to do a reverse path check (RPF) as described in the above draft. In addition, they lack the NAS and session identification AVPs that would appear to be necessary for proper identification. Therefore the RAR and STR messages defined in Diameter Base probably can't be used in applications without defining additional AVPs. I am assuming that the intent in Diameter Base is just to define the basic commands and allow individual applications to specify how they are used in more detail. However Diameter NASREQ nor Diameter MIPv4 contain the required details -- which leads me to believe that this is a more basic problem that reflects some gaps in thinking about how these commands really work? Comments? From owner-aaa-wg@merit.edu Fri Apr 11 09:31: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 JAA11885 for ; Fri, 11 Apr 2003 09:31:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 921BA9128B; Fri, 11 Apr 2003 09:33:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5782D9128C; Fri, 11 Apr 2003 09:33:52 -0400 (EDT) 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 51B5E9128B for ; Fri, 11 Apr 2003 09:33:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2B1055DD97; Fri, 11 Apr 2003 09:33:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8C10C5DD94 for ; Fri, 11 Apr 2003 09:33:50 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3BDFXx11773; Fri, 11 Apr 2003 06:15:33 -0700 Date: Fri, 11 Apr 2003 06:15:33 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Concern about Diameter disconnect and dynamic authorization In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk That seems reasonable. However, it seems to have been 'forgotten' in the applications, too. On Fri, 11 Apr 2003 john.loughney@nokia.com wrote: > Bernard, > > My assumption was that this kind of functionality would be > driven by the applications, so that may be part of the reason > this was 'forgotten' in the base. > > John > > > -----Original Message----- > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > Sent: 06 April, 2003 08:13 > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: Concern about Diameter disconnect and dynamic > > authorization > > > > > > We've just been through a bit of a security firedrill with > > respect to the following draft: > > > > http://www.drizzle.com/~aboba/IEEE/draft-chiba-radius-dynamic- > authorization-11.txt > > While a bunch of the issues found here do *not* afflict Diameter > disconnect and dynamic authorization operations (since Diameter uses > ordinary Request/Response mechanisms for authorization changes), it seems > to me that other issues *are* relevant. > > For example, there is the question of how a NAS or proxy decides whether a > disconnect or dynamic authorization request is appropriate. Authentication > is not enough for this -- we would not want one ISP to be able to > disconnect users from another ISP on a shared use NAS, for example. > > It seems to me that to some extent the mechanisms used to identify a > session for these operations are application specific -- and therefore > that the issues need to be addressed in the Diameter Application specs, > rather than Base. > > However, in looking at the RAR and STR messages in Diameter, it would > appear that they lack the basic facilities necessary to do a reverse path > check (RPF) as described in the above draft. In addition, they > lack the NAS and session identification AVPs that would appear to > be necessary for proper identification. Therefore the RAR and STR > messages defined in Diameter Base probably can't be used in applications > without defining additional AVPs. > > I am assuming that the intent in Diameter Base is just to define the basic > commands and allow individual applications to specify how they are used in > more detail. However Diameter NASREQ nor Diameter MIPv4 contain the > required details -- which leads me to believe that this is a more basic > problem that reflects some gaps in thinking about how these commands > really work? > > Comments? > From owner-aaa-wg@merit.edu Fri Apr 11 16:51:31 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 QAA29565 for ; Fri, 11 Apr 2003 16:51:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0245F9129A; Fri, 11 Apr 2003 16:53:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BFE749129B; Fri, 11 Apr 2003 16:53:50 -0400 (EDT) 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 077649129A for ; Fri, 11 Apr 2003 16:53:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D13FB5DE26; Fri, 11 Apr 2003 16:53:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by segue.merit.edu (Postfix) with ESMTP id 7FAA85DE24 for ; Fri, 11 Apr 2003 16:53:48 -0400 (EDT) Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65]) by palrel10.hp.com (Postfix) with ESMTP id 9204B1C036DE; Fri, 11 Apr 2003 13:53:43 -0700 (PDT) Received: from xpabh2.ptp.hp.com (xpabh2.ptp.hp.com [15.1.28.61]) by xparelay2.ptp.hp.com (Postfix) with ESMTP id 376981C000BD; Fri, 11 Apr 2003 13:53:43 -0700 (PDT) Received: by xpabh2.ptp.hp.com with Internet Mail Service (5.5.2655.55) id <2VKRJXJ4>; Fri, 11 Apr 2003 13:53:43 -0700 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A566B9D2@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Harri Hakala (LMF)'" , "'aaa-wg@merit.edu'" , "'Avi Lior'" Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt Date: Fri, 11 Apr 2003 13:53:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Harri, I see prepay as an interesting mix of Authorization AND Accounting. The sequence diagram on slide 4 of the powerpoint slides at: http://www.circumference.org/circumference.ppt Show this mix. I view the initial request (the Diameter "START" message) as effectively being an "authorization" request, with a response either granting some capability or denying. Based on the response the service element will then "account" for the delivered service in a subsequent message. I prefer the standard UML Sequence diagram of this slide as opposed to the prose based state tables, as I think it is a bit easier to visualize. Unfortunately the RFC editorial policy restricts things to ASCII art, which can be a real pain to edit. Regards, Jeff Meyer > -----Original Message----- > From: Harri Hakala (LMF) [mailto:Harri.Hakala@lmf.ericsson.se] > Sent: Friday, April 11, 2003 12:56 AM > To: 'aaa-wg@merit.edu'; 'Avi Lior' > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > Hi, > > You seem to forget the other aspect of prepaid: it's not only about > the credit check at the beginning of the service but also > about *paying* > of the service, i.e. billing of the service in real-time. The > accounting > is defined to be a process of collecting information for > billing (among > other things) done by a billing server. In credit control > application we > collect the information for the same purpose (billing) but > the process > is done in real-time, not as a batch process in some back-end server. > > I agree, the current credit control architecture might be too > restricted > when it specifies that the dialogue can be only between the > service node > and the credit control server. We could extend it to cover the (H)AAA > server as well so that the HAAA can use the credit control commands > towards the prepaid server. The communication between the > service node and > (H)AAA would be out of the scope of the draft. > > Some further comments below. > > Regards..................Harri > > N.B. You seem to have a problem with sending the messages to > the aaa-wg-mailing > list since they don't appear in the mailing list. Have you > subscribed to the > mailing list with the same id that you are using when posting > the messages? > > > > > > It is associated with accounting because of rating and billing. > > > The requested service must be rated before granting any > > > quotas to the client. This is needed in order to decide > > > whether the end user's account covers the requested service > > > and to be able to grant right amount of quotas. So the rating > > > itself that is needed for the decision is more related to > > > accounting functionality than authorization. And since the > > > prepaid server will decrease the account during the > > > session in order to bill to user for the usage of the service the > > > billing as well is accounting related functionality. > > > > The above can happen during the Authentication and > > Authorization phase. > > Yes, it can happen during that *phase* but the rating and the billing > part is not part of Authentication and Authorization functionality. > > > This is not a problem. The HAAA can communicate the Service > > requested right > > after it authenticated the user and determined what service > > the user will > > get. It can pass these to the Prepaid application. All results > > (authorization parameters for both prepaid and service are > > then passed back > > to the access device) > > Wouldn't this mean that then all the authorization requests would have > to contain all the accounting parameters so that the HAAA can > pass them > to the prepaid server for rating? Wouldn't you have to update all the > existing (and future) authentication & authorization applications to > support online accounting (prepaid)? > > > > Because the access device doesn't necessarily know if the user is > > > postpaid or prepaid, then all authentication and > > > authorization requests would need to carry rating input > > > parameters, also in case of postpaid users. Also there might > > > be some existing service specific authentication and > > > authorization protocols, which then need to be updated to > > > include these > > > parameters. > > > > The HAAA knows what service the user wants. The rating > > engine will have the > > rating information anyway. So I don't see the problem here. > > I would imagine that the rating input (at least most of it) would come > from the access device, not from HAAA. Therefore your > authentication & > authorizations commands should be able to carry those. > > > Asking for more quotas can be achieved by authorization > > requests. After all > > it is a reauthorization operation. You are authorizing the > > user to continue > > to use the session. Infact, because in RADIUS accounting > > messages are not > > acted on -- they are used for recording -- and in fact, they can be > > processed in batch by proxies (and hence are not real-time), > > these operation > > really should be done using Access Request messages. > > Might be true for RADIUS. I haven't seen any such statements > for Diameter > accounting messages. > > > > > -----Original Message----- > > From: Avi Lior [mailto:avi.lior@bridgewatersystems.com] > > Sent: 10. huhtikuuta 2003 18:42 > > To: Harri Hakala (LMF); 'aaa-wg@merit.edu'; Avi Lior > > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > > > > Hi Harri, > > > > I have comments inline as well as: > > > > So first let me say this: lets not confuse the operation type > > with the type > > of server that is performing the operation. Is the Prepaid server an > > accounting server -- lets say it is. Should the messages be > > accounting > > messages -- Not necessarily. An accounting server should handle > > authorization type requests. Just like a bank can handle an > > authorization > > type requests. But this is a minor issue. > > > > The Credit Application in my opinion *must* be capable of > > allowing me to > > authenticate a user and both authorize the user for a service > > and authorize > > the user for prepaid in the *same* Access Request phase. > > > > So an Access Device issues an Access Request advertizing the > > its Prepaid > > Capabilities. Since it doesn't know the apriori whether > the user is a > > prepaid user or not it would issue the Prepaid Capabilities > > in every Access > > Request. The Home AAA will then Authenticate the user and > > determine a) > > where the user is prepaid or not; and b) the type of service. > > If the user > > is prepaid it will then contact the Prepaid Server to further > > authorize the > > subscriber. If the prepaid authorization is successful, the > > HAAA will then > > respond back to the access device with the service > > authorization parameters > > and the prepaid authorization parameters. > > > > Can this be done with the Diameter Credit Control application? > > > > > > > -----Original Message----- > > > From: Harri Hakala (LMF) [mailto:Harri.Hakala@lmf.ericsson.se] > > > Sent: Thursday, April 10, 2003 6:09 AM > > > To: 'aaa-wg@merit.edu'; 'Avi Lior' > > > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > > > > > > > Hi Avi, > > > > > > (I assume that your mail was pointed to the aaa-mailing list.) > > > > > > It is associated with accounting because of rating and billing. > > > The requested service must be rated before granting any > > > quotas to the client. This is needed in order to decide > > > whether the end user's account covers the requested service > > > and to be able to grant right amount of quotas. So the rating > > > itself that is needed for the decision is more related to > > > accounting functionality than authorization. And since the > > > prepaid server will decrease the account during the > > > session in order to bill to user for the usage of the service the > > > billing as well is accounting related functionality. > > > > The above can happen during the Authentication and > > Authorization phase. > > > > > In order to rate the service, rating input parameters are > > > needed, that is the authorization commands would need to > > > carry all the rating input parameters. The server also must > > > return some control parameters to the client (e.g. access > > > device), so that the client can monitor the service execution > > > according to the instructions returned by the server. > > > > This is not a problem. The HAAA can communicate the Service > > requested right > > after it authenticated the user and determined what service > > the user will > > get. It can pass these to the Prepaid application. All results > > (authorization parameters for both prepaid and service are > > then passed back > > to the access device) > > > > > Because the access device doesn't necessarily know if the user is > > > postpaid or prepaid, then all authentication and > > > authorization requests would need to carry rating input > > > parameters, also in case of postpaid users. Also there might > > > be some existing service specific authentication and > > > authorization protocols, which then need to be updated to > > > include these > > > parameters. > > > > The HAAA knows what service the user wants. The rating > > engine will have the > > rating information anyway. So I don't see the problem here. > > > > > > > > The client may need more quotas during the services and > it may send > > > interim request to the server requesting more quotas and > > > reporting used quotas, i.e. session based credit control (or > > > prepaid). The Diameter base accounting supports session based > > > accounting (start, interim and stop) > > > and this suits very well for credit control as well. This > > is also one > > > reason why we want to associate the credit control > > > application with the > > > accounting, i.e. only few additional AVPs + new accounting > > > state machines (credit control session state machines) > are needed. > > > > Asking for more quotas can be achieved by authorization > > requests. After all > > it is a reauthorization operation. You are authorizing the > > user to continue > > to use the session. Infact, because in RADIUS accounting > > messages are not > > acted on -- they are used for recording -- and in fact, they can be > > processed in batch by proxies (and hence are not real-time), > > these operation > > really should be done using Access Request messages. > > > > > When session based credit control is used then credit control > > > server must maintain the session. If authorization commands > > > would be used, then during initial authorization the > > > authorization server should establish the session towards > > > credit control server in order to perform 'prepaid > > > authorization'. > > Well, in my opinion the Access Device talks to the HAAA. The > > HAAA then talks > > to the Prepaid System. Both results comeback to the Access Device. > > > > This is a Diameter problem which in my opinion needs to be > > fixed. The HAAA > > should be able to communicate with a prepaid server using your > > specification. Both the resutls need to be combined and sent > > back to the > > Access Device. Diameter should allow me to do that. > > > > >Then the re-authorization for additional > > > quotas during the session should flow through the AAA server > > > to the prepaid server, adding an > > > extra stateful hop (proxy, translator) in the signaling. > When using > > > accounting commands the client can communicate directly with > > > the prepaid > > > server. > > > > > > You are right the draft is not just for the 3GPP and of > > > course they also > > > authenticate and authorize the subscriber for the network > > access and > > > for the services as well. For instance for multimedia > > > services the Diameter Multimedia Application can be used. > > > > If its not for 3GPP then I think my scenrio should be > > considered. 3GPP2 > > does it in one phase. There are timing issues. There is a > > concern that to > > phases will take too long. > > > > > Regards......Harri > > > > From owner-aaa-wg@merit.edu Fri Apr 11 17:35: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 RAA01664 for ; Fri, 11 Apr 2003 17:35:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6F3389129D; Fri, 11 Apr 2003 17:37:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3282C9129E; Fri, 11 Apr 2003 17:37:50 -0400 (EDT) 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 7E8C89129D for ; Fri, 11 Apr 2003 17:37:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5A08C5DE2B; Fri, 11 Apr 2003 17:37:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from m2-pasarela3.airtel.es (unknown [212.166.209.12]) by segue.merit.edu (Postfix) with ESMTP id D94945DE29 for ; Fri, 11 Apr 2003 17:37:47 -0400 (EDT) To: "'aaa-wg@merit.edu'" Cc: "MEYER,JEFFREY D (HP-Cupertino,ex1)" , "Harri Hakala (LMF)" From: paco.marin@vodafone.com Subject: Re: Re: [AAA-WG]: Diameter Credit, Parlay, PayCircle and IPDR... Date: Fri, 11 Apr 2003 23:37:45 +0200 Message-ID: X-MIMETrack: Serialize by Router on M2-SMTP3/AIRTEL(Release 5.0.10 |March 22, 2002) at 04/11/2003 11:37:48 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA01664 (Thanks, Harri) Hi Harri, Jeff, all Parlay domain are limited to services that use the Parlay Framework. However, I think that the relationship between Parlay and Diameter is very important and complementary. Parlay is not conceived as a core network protocol but a protocol to abstract a service level from the core network. The objectives are two: to have a service level where to implement in an easy way application logics for the services using APIs able to simplify the process for the developers ( fast and cheap developing services); and to be able to provide a Framework and APIs to third parties in order to allow them using the network operator assets in a controlled manner (it allows the network operator to control the charging, for instance). I consider Diameter as a core network protocol, it means that the relation between Parlay and Diameter is the physical realization or mapping of the Parlay procedures and messages (defined by the API) into Diameter procedures and messages. I think it would be very important to certify the alignment between both protocols. The schema would be as follows: middleware ------------ -------- | Parlay |A | | Parlay | PARLAY | |P | ----------| |GATEWAY | Service |I | | SCS | ------------ |--------| APLICATION |Diameter| SERVER |Enabler | - (Credit -------- Control | Application) | |Diameter | | --------- | | | Credit | | | | Control | | | | Server | | | --------- Note that there is not cannibalisation between both protocols but they are complementary. Diameter protocols is able to integrate several systems and Parlay allows to use these systems in a easy way both for local services and for third party services. The sinergy of joint solutions is great. Cheers, Paco Marín ------------------- Vodafone Group R&D C/ Trespaderne, 29 Edificio Barajas 1_B Madrid Spain T: +34 607135244 F: +34 607 135252 -------------------------------------------------------------------- "MEYER,JEFFREY D (HP-Cupertino,ex1)" Enviado por: owner-aaa-wg@merit.edu 10/04/2003 19:07 Para: "'aaa-wg@merit.edu'" cc: cco: Asunto: [AAA-WG]: Diameter Credit, Parlay, PayCircle and IPDR... Hi, I'm forwarding this e-mail, because it didn't initially appear on the list due to mailer issues on my end. Regards, Jeff Meyer -----Original Message----- From: MEYER,JEFFREY D (HP-Cupertino,ex1) Sent: Wednesday, April 09, 2003 9:02 AM To: 'Harri Hakala (LMF)'; 'aaa-wg@merit.edu'; MEYER,JEFFREY D (HP-Cupertino,ex1) Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt Harri, Thanks for the response. Regarding the domain of Parlay, I'd agree it presumes a Parlay framework. However, it also has an "Information Model" aimed at addressing the same credit control space as your draft, so to that end trying to align these information models is where the use of a common model for describing the information payload in a manner independent of encoding and transport is where IPDR can come into play. I know there was work on a dictionary framework in the Diameter group, but that seems to have stalled out. What I would like to do is resurrect that model, but using IPDR's XML-Schema with annotation approach. This would likely require a draft on its own, I'll begin looking into that. I'll also look to see if there is some "placeholder" language which would be appropriate for the credit control draft. Regards, Jeff Meyer > -----Original Message----- > From: Harri Hakala (LMF) [mailto:Harri.Hakala@lmf.ericsson.se] > Sent: Wednesday, April 09, 2003 1:31 AM > To: 'aaa-wg@merit.edu'; 'MEYER,JEFFREY D (HP-Cupertino,ex1)' > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > > Any comments on the relationship of this application to Parlay > > section 12 and PayCircle? > > > > http://www.parlay.org/specs/3.2/es_20191512Charging.zip > > > > http://www.paycircle.org > > > > It seems that all of these are addressing the same basic issue of > > authorization of services with possible reservation of credit on > > the backend. > > Isn't the applicability of OSA/Parlay charging API limited to > services that > have been built using the OSA/Parlay framework?. > I foresee that there are services built using other > mechanisms and are therefore > outside this framework. > > Our motivation is to define an IP-based accounting protocol > to support credit > based accounting by using the AAA infrastructure. Because the > Diameter base > protocol provides several features, which are required from > this kind of application > and because the Diameter and its accounting can be widely > utilized we thought that > the AAA framework and Diameter is a good choice for this kind > of IP-based accounting > protocol. > > I assume that there are several (and more and more are being > developed) this kind of > applications focusing on online payments and credit > reservations using quite similar > mechanisms, but having a bit different scope and framework. > > > A harmonization of terminology, and ideally attribute names and > > data types would be worthwile. > > > > The IPDR.org (http://www.ipdr.org) group is looking at aspects of > > performing > > this harmonization. For some information on the separation > > of information > > model, from encoding from transport see: > > > > http://www.circumference.org/circumference.ppt > > A harmonization of terminology, etc, defined by different > standardization bodies, > would be helpful, although it might be quite challenging task. > > It would be good if you can provide us with proposals for > changed text in the draft. > > Regards.........Harri > > > -----Original Message----- > > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] > > Sent: 9. huhtikuuta 2003 2:56 > > To: Harri Hakala (LMF); aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > > > > Harri, > > > > Any comments on the relationship of this application to Parlay > > section 12 and PayCircle? > > > > http://www.parlay.org/specs/3.2/es_20191512Charging.zip > > > > http://www.paycircle.org > > > > It seems that all of these are addressing the same basic issue of > > authorization of services with possible reservation of credit on > > the backend. > > > > A harmonization of terminology, and ideally attribute names and > > data types would be worthwile. > > > > The IPDR.org (http://www.ipdr.org) group is looking at aspects of > > performing > > this harmonization. For some information on the separation > > of information > > model, from encoding from transport see: > > > > http://www.circumference.org/circumference.ppt > > > > > > Regards, > > > > Jeff Meyer > > HP > > http://www.hp.com/usage > > > > > > > > > -----Original Message----- > > > From: Harri Hakala (LMF) [mailto:Harri.Hakala@lmf.ericsson.se] > > > Sent: Friday, February 28, 2003 1:55 AM > > > To: aaa-wg@merit.edu > > > Subject: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > > > > > > > Hi All, > > > > > > We have submitted a new version of the Diameter credit > control draft > > > to the IETF archive. > > > > > > Until it shows up in the archive, it can be found: > > > http://standards.ericsson.net/harri/draft-hakala-diameter-cred > > it-control-06.txt > > > > Here is a list of updates compared to draft -05: > > 1. A server or client is not required to implement all > > functionality in > > the CCA. The optionality has been clarified in the draft, the > > modified > > AVPs are the following: > > > > 1a. Unknown/unsupported value responded with error: > > - Subscription-Id-Type > > > > 1b. Unknown AVP ignored, i.e. 'M'-bit removed from AVP Flag table > > - Accounting-Correlation-Id > > - Abnormal-Termination-Reason > > - Cost-Information > > > > 2. New Result-Code value 'DIAMETER_RATING_FAILED'. > > > > We would appreciate if you can read it and provide your comments. > > > > Regards.......Harri > > > From owner-aaa-wg@merit.edu Fri Apr 11 18:12: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 SAA03400 for ; Fri, 11 Apr 2003 18:12:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D350C9129E; Fri, 11 Apr 2003 18:14:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9EC789129F; Fri, 11 Apr 2003 18:14:34 -0400 (EDT) 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 C23239129E for ; Fri, 11 Apr 2003 18:14:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AA1405DDF4; Fri, 11 Apr 2003 18:14:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by segue.merit.edu (Postfix) with ESMTP id 3FC215DDEB for ; Fri, 11 Apr 2003 18:14:32 -0400 (EDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel7.hp.com (Postfix) with ESMTP id C101C1C027DF; Fri, 11 Apr 2003 18:14:31 -0400 (EDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id A61031C00B48; Fri, 11 Apr 2003 18:14:31 -0400 (EDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2655.55) id <2JYAG2WP>; Fri, 11 Apr 2003 18:14:31 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A566B9D5@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'paco.marin@vodafone.com'" , "'aaa-wg@merit.edu'" Cc: "MEYER,JEFFREY D (HP-Cupertino,ex1)" , "Harri Hakala (LMF)" Subject: RE: Re: [AAA-WG]: Diameter Credit, Parlay, PayCircle and IPDR... Date: Fri, 11 Apr 2003 18:14:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Paco, Although I see the synergy between PayCircle (which is based on concepts from Parlay) and Diameter, in that an application developer may want to write to a web services type interface vs. a binary interface; I am less clear on whether the API defined by Parlay is simpler than that being defined for Diameter. Aspects around tunneling and proxying are also issues which Diameter addresses well, but I suspect are more of an open issue in Parlay. It seems to me that Parlay's key design center was around abstracting interactions into today's IN/SS7 networks, which requires some proxying to enable apps on general purpose platforms to interact with the signalling network. However, for general applications, which want to be able to service not just devices connected through the GSM/PSTN network, but IP devices in general, then I think the value of Parlay is limited. Maybe I missed something in my reading of Parlay, but these interfaces don't seem too friendly to me. It seems like there is a lot of API overhead involved in making CORBA behave like an asynchronous interface, which it doesn't want to be. In any event, this isn't the right venue to discuss the virtues and foibles of Parlay. But it is reasonable to say that there will be some Parlay apps, the Parlay developers have spent time investigating this space, and ensuring that information exchange between the Diameter and Parlay based apps, as in your diagram, is enabled if possible. Regards, Jeff Meyer > -----Original Message----- > From: paco.marin@vodafone.com [mailto:paco.marin@vodafone.com] > Sent: Friday, April 11, 2003 2:38 PM > To: 'aaa-wg@merit.edu' > Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); Harri Hakala (LMF) > Subject: Re: Re: [AAA-WG]: Diameter Credit, Parlay, PayCircle and > IPDR... > > > (Thanks, Harri) > > > Hi Harri, Jeff, all > > Parlay domain are limited to services that use the Parlay > Framework. However, I think that the > relationship between Parlay and Diameter is very important > and complementary. > > Parlay is not conceived as a core network protocol but a > protocol to abstract a service level from > the core network. The objectives are two: to have a service > level where to implement in an easy way > application logics for the services using APIs able to > simplify the process for the developers ( > fast and cheap developing services); and to be able to > provide a Framework and APIs to third parties > in order to allow them using the network operator assets in a > controlled manner (it allows the > network operator to control the charging, for instance). > > I consider Diameter as a core network protocol, it means that > the relation between Parlay and > Diameter is the physical realization or mapping of the Parlay > procedures and messages (defined by > the API) into Diameter procedures and messages. > > I think it would be very important to certify the alignment > between both protocols. > > > > The schema would be as follows: > > > > middleware > ------------ -------- > | Parlay |A | | Parlay | PARLAY > | |P | ----------| |GATEWAY > | Service |I | | SCS | > ------------ |--------| > APLICATION |Diameter| > SERVER |Enabler | - (Credit > -------- Control > | Application) > | > |Diameter > | > | > --------- > | | > | Credit | > | | > | Control | > | | > | Server | > | | > --------- > > > Note that there is not cannibalisation between both protocols > but they are complementary. Diameter > protocols is able to integrate several systems and Parlay > allows to use these systems in a easy way > both for local services and for third party services. The > sinergy of joint solutions is great. > > > Cheers, > > > > > Paco Marín > ------------------- > Vodafone Group R&D > C/ Trespaderne, 29 Edificio Barajas 1_B > Madrid > Spain > T: +34 607135244 > F: +34 607 135252 > -------------------------------------------------------------------- > > > > > > "MEYER,JEFFREY D (HP-Cupertino,ex1)" > Enviado por: owner-aaa-wg@merit.edu > 10/04/2003 19:07 > > Para: "'aaa-wg@merit.edu'" > cc: > cco: > Asunto: [AAA-WG]: Diameter Credit, Parlay, > PayCircle and IPDR... > > > Hi, > > I'm forwarding this e-mail, because it didn't initially appear on > the list due to mailer issues on my end. > > Regards, > > Jeff Meyer > > -----Original Message----- > From: MEYER,JEFFREY D (HP-Cupertino,ex1) > Sent: Wednesday, April 09, 2003 9:02 AM > To: 'Harri Hakala (LMF)'; 'aaa-wg@merit.edu'; MEYER,JEFFREY D > (HP-Cupertino,ex1) > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > Harri, > > Thanks for the response. Regarding the domain of Parlay, I'd agree > it presumes a Parlay framework. However, it also has an "Information > Model" aimed at addressing the same credit control space as your > draft, so to that end trying to align these information models is > where the use of a common model for describing the information payload > in a manner independent of encoding and transport is where IPDR can > come into play. > > I know there was work on a dictionary framework in the Diameter > group, but that seems to have stalled out. What I would like to do > is resurrect that model, but using IPDR's XML-Schema with annotation > approach. This would likely require a draft on its own, I'll begin > looking into that. > > I'll also look to see if there is some "placeholder" > language which would > be appropriate for the credit control draft. > > Regards, > > Jeff Meyer > > > -----Original Message----- > > From: Harri Hakala (LMF) [mailto:Harri.Hakala@lmf.ericsson.se] > > Sent: Wednesday, April 09, 2003 1:31 AM > > To: 'aaa-wg@merit.edu'; 'MEYER,JEFFREY D (HP-Cupertino,ex1)' > > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > > > > > Any comments on the relationship of this application to Parlay > > > section 12 and PayCircle? > > > > > > http://www.parlay.org/specs/3.2/es_20191512Charging.zip > > > > > > http://www.paycircle.org > > > > > > It seems that all of these are addressing the same > basic issue of > > > authorization of services with possible reservation of credit on > > > the backend. > > > > Isn't the applicability of OSA/Parlay charging API limited to > > services that > > have been built using the OSA/Parlay framework?. > > I foresee that there are services built using other > > mechanisms and are therefore > > outside this framework. > > > > Our motivation is to define an IP-based accounting protocol > > to support credit > > based accounting by using the AAA infrastructure. Because the > > Diameter base > > protocol provides several features, which are required from > > this kind of application > > and because the Diameter and its accounting can be widely > > utilized we thought that > > the AAA framework and Diameter is a good choice for this kind > > of IP-based accounting > > protocol. > > > > I assume that there are several (and more and more are being > > developed) this kind of > > applications focusing on online payments and credit > > reservations using quite similar > > mechanisms, but having a bit different scope and framework. > > > > > A harmonization of terminology, and ideally attribute names and > > > data types would be worthwile. > > > > > > The IPDR.org (http://www.ipdr.org) group is looking at > aspects of > > > performing > > > this harmonization. For some information on the separation > > > of information > > > model, from encoding from transport see: > > > > > > http://www.circumference.org/circumference.ppt > > > > A harmonization of terminology, etc, defined by different > > standardization bodies, > > would be helpful, although it might be quite challenging task. > > > > It would be good if you can provide us with proposals for > > changed text in the draft. > > > > Regards.........Harri > > > > > -----Original Message----- > > > From: MEYER,JEFFREY D (HP-Cupertino,ex1) > [mailto:jeff.meyer2@hp.com] > > > Sent: 9. huhtikuuta 2003 2:56 > > > To: Harri Hakala (LMF); aaa-wg@merit.edu > > > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > > > > > > > Harri, > > > > > > Any comments on the relationship of this application to Parlay > > > section 12 and PayCircle? > > > > > > http://www.parlay.org/specs/3.2/es_20191512Charging.zip > > > > > > http://www.paycircle.org > > > > > > It seems that all of these are addressing the same > basic issue of > > > authorization of services with possible reservation of credit on > > > the backend. > > > > > > A harmonization of terminology, and ideally attribute names and > > > data types would be worthwile. > > > > > > The IPDR.org (http://www.ipdr.org) group is looking at > aspects of > > > performing > > > this harmonization. For some information on the separation > > > of information > > > model, from encoding from transport see: > > > > > > http://www.circumference.org/circumference.ppt > > > > > > > > > Regards, > > > > > > Jeff Meyer > > > HP > > > http://www.hp.com/usage > > > > > > > > > > > > > -----Original Message----- > > > > From: Harri Hakala (LMF) [mailto:Harri.Hakala@lmf.ericsson.se] > > > > Sent: Friday, February 28, 2003 1:55 AM > > > > To: aaa-wg@merit.edu > > > > Subject: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > > > > > > > > > > Hi All, > > > > > > > > We have submitted a new version of the Diameter credit > > control draft > > > > to the IETF archive. > > > > > > > > Until it shows up in the archive, it can be found: > > > > http://standards.ericsson.net/harri/draft-hakala-diameter-cred > > > it-control-06.txt > > > > > > Here is a list of updates compared to draft -05: > > > 1. A server or client is not required to implement all > > > functionality in > > > the CCA. The optionality has been clarified in the draft, the > > > modified > > > AVPs are the following: > > > > > > 1a. Unknown/unsupported value responded with error: > > > - Subscription-Id-Type > > > > > > 1b. Unknown AVP ignored, i.e. 'M'-bit removed from AVP Flag table > > > - Accounting-Correlation-Id > > > - Abnormal-Termination-Reason > > > - Cost-Information > > > > > > 2. New Result-Code value 'DIAMETER_RATING_FAILED'. > > > > > > We would appreciate if you can read it and provide your comments. > > > > > > Regards.......Harri > > > > > > > > > From owner-aaa-wg@merit.edu Mon Apr 14 02:23:08 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 CAA25221 for ; Mon, 14 Apr 2003 02:23:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ABB9A91208; Mon, 14 Apr 2003 02:25:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7DB1E91209; Mon, 14 Apr 2003 02:25:25 -0400 (EDT) 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 347F791208 for ; Mon, 14 Apr 2003 02:25:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1F79D5DE78; Mon, 14 Apr 2003 02:25:24 -0400 (EDT) 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 587035DE77 for ; Mon, 14 Apr 2003 02:25:23 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3E6PMH05028 for ; Mon, 14 Apr 2003 09:25:22 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Apr 2003 09:25:22 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Apr 2003 09:25:22 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Apr 2003 09:25:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Re: [AAA-WG]: Diameter Credit, Parlay, PayCircle and IPDR... Date: Mon, 14 Apr 2003 09:25:21 +0300 Message-ID: Thread-Topic: Re: [AAA-WG]: Diameter Credit, Parlay, PayCircle and IPDR... Thread-Index: AcMAd8r/nlxKcr+8SbaV1L+by9pR5gB1n30A From: To: , , Cc: X-OriginalArrivalTime: 14 Apr 2003 06:25:21.0697 (UTC) FILETIME=[A0527910:01C3024E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA25221 Hi Jeff, > In any event, this isn't the right venue to discuss the > virtues and foibles of Parlay. But it is reasonable to say > that there will be some Parlay apps, the Parlay developers > have spent time investigating this space, and ensuring that > information exchange between the Diameter and Parlay based > apps, as in your diagram, is enabled if possible. If you could suggest some text, etc. that the credit control document woulkd need to support this, we can look at adding it. However, I feel that this is a more general problem and not just limited to the Credit Control application. Also, I do know that some folks have expressed interest in some sort of 'interface' (in a very loose sense of the word) between webservices and Diameter. I'm not sure if there is a need for a standard solution or if this is much more an implementation or deployment issue. thanks, John From owner-aaa-wg@merit.edu Mon Apr 14 02:46: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 CAA25790 for ; Mon, 14 Apr 2003 02:46:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6CDD39120A; Mon, 14 Apr 2003 02:48:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 36BE39120D; Mon, 14 Apr 2003 02:48:51 -0400 (EDT) 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 3D48B9120A for ; Mon, 14 Apr 2003 02:48:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 22D0F5DE81; Mon, 14 Apr 2003 02:48:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id 9EAC85DE1F for ; Mon, 14 Apr 2003 02:48:48 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3E6mdI4011395; Mon, 14 Apr 2003 08:48:39 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2VAMDPKL>; Mon, 14 Apr 2003 08:48:40 +0200 Message-ID: From: "Harri Hakala (LMF)" To: "'aaa-wg@merit.edu'" , "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" , "'Avi Lior'" Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt Date: Mon, 14 Apr 2003 08:48:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Jeff, > I see prepay as an interesting mix of Authorization AND Accounting. > > The sequence diagram on slide 4 of the powerpoint slides at: > > http://www.circumference.org/circumference.ppt > > Show this mix. I view the initial request (the Diameter "START" > message) as effectively being an "authorization" request, with > a response either granting some capability or denying. > > Based on the response the service element will then "account" > for the delivered service in a subsequent message. I agree, with the accounting[start] message one does the 'prepaid authorization' - credit control is on the border of authorization and accounting. But when using Diameter it is not possible to start a session with an authorization command and then continue it with the accounting[interim] command and terminate the session with the accounting[stop] command. The accounting session has to be started with accounting[start], which is missing from your sequence. Since the authorization process in this case is tightly coupled with the prepaid account in the prepaid server and you can't skip the accounting[start] record then the accounting[start] will serve as combination of 'prepaid authorization' and 'reservation of credit from prepaid account'. And because the Diameter base accounting suits so well for prepay too, we decided to reuse it for credit control by adding the prepay aspect to it, i.e. real-time rating, credit check, credit-reservation, grating of credit, etc. In fact the Session Based Credit Control (section 3.1) defines same functionality what you proposed. Regards.........Harri > -----Original Message----- > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] > Sent: 11. huhtikuuta 2003 23:54 > To: Harri Hakala (LMF); 'aaa-wg@merit.edu'; 'Avi Lior' > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > Harri, > > I see prepay as an interesting mix of Authorization AND Accounting. > > The sequence diagram on slide 4 of the powerpoint slides at: > > http://www.circumference.org/circumference.ppt > > Show this mix. I view the initial request (the Diameter "START" > message) as effectively being an "authorization" request, with > a response either granting some capability or denying. > > Based on the response the service element will then "account" > for the delivered service in a subsequent message. > > I prefer the standard UML Sequence diagram of this slide as > opposed to the prose based state tables, as I think it is a > bit easier to visualize. Unfortunately the RFC editorial policy > restricts things to ASCII art, which can be a real pain to > edit. > > Regards, > > Jeff Meyer > > > -----Original Message----- > > From: Harri Hakala (LMF) [mailto:Harri.Hakala@lmf.ericsson.se] > > Sent: Friday, April 11, 2003 12:56 AM > > To: 'aaa-wg@merit.edu'; 'Avi Lior' > > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > > > > Hi, > > > > You seem to forget the other aspect of prepaid: it's not only about > > the credit check at the beginning of the service but also > > about *paying* > > of the service, i.e. billing of the service in real-time. The > > accounting > > is defined to be a process of collecting information for > > billing (among > > other things) done by a billing server. In credit control > > application we > > collect the information for the same purpose (billing) but > > the process > > is done in real-time, not as a batch process in some > back-end server. > > > > I agree, the current credit control architecture might be too > > restricted > > when it specifies that the dialogue can be only between the > > service node > > and the credit control server. We could extend it to cover > the (H)AAA > > server as well so that the HAAA can use the credit control commands > > towards the prepaid server. The communication between the > > service node and > > (H)AAA would be out of the scope of the draft. > > > > Some further comments below. > > > > Regards..................Harri > > > > N.B. You seem to have a problem with sending the messages to > > the aaa-wg-mailing > > list since they don't appear in the mailing list. Have you > > subscribed to the > > mailing list with the same id that you are using when posting > > the messages? > > > > > > > > > > It is associated with accounting because of rating and billing. > > > > The requested service must be rated before granting any > > > > quotas to the client. This is needed in order to decide > > > > whether the end user's account covers the requested service > > > > and to be able to grant right amount of quotas. So the rating > > > > itself that is needed for the decision is more related to > > > > accounting functionality than authorization. And since the > > > > prepaid server will decrease the account during the > > > > session in order to bill to user for the usage of the > service the > > > > billing as well is accounting related functionality. > > > > > > The above can happen during the Authentication and > > > Authorization phase. > > > > Yes, it can happen during that *phase* but the rating and > the billing > > part is not part of Authentication and Authorization functionality. > > > > > This is not a problem. The HAAA can communicate the Service > > > requested right > > > after it authenticated the user and determined what service > > > the user will > > > get. It can pass these to the Prepaid application. All results > > > (authorization parameters for both prepaid and service are > > > then passed back > > > to the access device) > > > > Wouldn't this mean that then all the authorization requests > would have > > to contain all the accounting parameters so that the HAAA can > > pass them > > to the prepaid server for rating? Wouldn't you have to > update all the > > existing (and future) authentication & authorization > applications to > > support online accounting (prepaid)? > > > > > > Because the access device doesn't necessarily know if > the user is > > > > postpaid or prepaid, then all authentication and > > > > authorization requests would need to carry rating input > > > > parameters, also in case of postpaid users. Also there might > > > > be some existing service specific authentication and > > > > authorization protocols, which then need to be updated to > > > > include these > > > > parameters. > > > > > > The HAAA knows what service the user wants. The rating > > > engine will have the > > > rating information anyway. So I don't see the problem here. > > > > I would imagine that the rating input (at least most of it) > would come > > from the access device, not from HAAA. Therefore your > > authentication & > > authorizations commands should be able to carry those. > > > > > Asking for more quotas can be achieved by authorization > > > requests. After all > > > it is a reauthorization operation. You are authorizing the > > > user to continue > > > to use the session. Infact, because in RADIUS accounting > > > messages are not > > > acted on -- they are used for recording -- and in fact, > they can be > > > processed in batch by proxies (and hence are not real-time), > > > these operation > > > really should be done using Access Request messages. > > > > Might be true for RADIUS. I haven't seen any such statements > > for Diameter > > accounting messages. > > > > > > > > > -----Original Message----- > > > From: Avi Lior [mailto:avi.lior@bridgewatersystems.com] > > > Sent: 10. huhtikuuta 2003 18:42 > > > To: Harri Hakala (LMF); 'aaa-wg@merit.edu'; Avi Lior > > > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > > > > > > > Hi Harri, > > > > > > I have comments inline as well as: > > > > > > So first let me say this: lets not confuse the operation type > > > with the type > > > of server that is performing the operation. Is the > Prepaid server an > > > accounting server -- lets say it is. Should the messages be > > > accounting > > > messages -- Not necessarily. An accounting server should handle > > > authorization type requests. Just like a bank can handle an > > > authorization > > > type requests. But this is a minor issue. > > > > > > The Credit Application in my opinion *must* be capable of > > > allowing me to > > > authenticate a user and both authorize the user for a service > > > and authorize > > > the user for prepaid in the *same* Access Request phase. > > > > > > So an Access Device issues an Access Request advertizing the > > > its Prepaid > > > Capabilities. Since it doesn't know the apriori whether > > the user is a > > > prepaid user or not it would issue the Prepaid Capabilities > > > in every Access > > > Request. The Home AAA will then Authenticate the user and > > > determine a) > > > where the user is prepaid or not; and b) the type of service. > > > If the user > > > is prepaid it will then contact the Prepaid Server to further > > > authorize the > > > subscriber. If the prepaid authorization is successful, the > > > HAAA will then > > > respond back to the access device with the service > > > authorization parameters > > > and the prepaid authorization parameters. > > > > > > Can this be done with the Diameter Credit Control application? > > > > > > > > > > -----Original Message----- > > > > From: Harri Hakala (LMF) [mailto:Harri.Hakala@lmf.ericsson.se] > > > > Sent: Thursday, April 10, 2003 6:09 AM > > > > To: 'aaa-wg@merit.edu'; 'Avi Lior' > > > > Subject: RE: [AAA-WG]: > draft-hakala-diameter-credit-control-06.txt > > > > > > > > > > > > Hi Avi, > > > > > > > > (I assume that your mail was pointed to the aaa-mailing list.) > > > > > > > > It is associated with accounting because of rating and billing. > > > > The requested service must be rated before granting any > > > > quotas to the client. This is needed in order to decide > > > > whether the end user's account covers the requested service > > > > and to be able to grant right amount of quotas. So the rating > > > > itself that is needed for the decision is more related to > > > > accounting functionality than authorization. And since the > > > > prepaid server will decrease the account during the > > > > session in order to bill to user for the usage of the > service the > > > > billing as well is accounting related functionality. > > > > > > The above can happen during the Authentication and > > > Authorization phase. > > > > > > > In order to rate the service, rating input parameters are > > > > needed, that is the authorization commands would need to > > > > carry all the rating input parameters. The server also must > > > > return some control parameters to the client (e.g. access > > > > device), so that the client can monitor the service execution > > > > according to the instructions returned by the server. > > > > > > This is not a problem. The HAAA can communicate the Service > > > requested right > > > after it authenticated the user and determined what service > > > the user will > > > get. It can pass these to the Prepaid application. All results > > > (authorization parameters for both prepaid and service are > > > then passed back > > > to the access device) > > > > > > > Because the access device doesn't necessarily know if > the user is > > > > postpaid or prepaid, then all authentication and > > > > authorization requests would need to carry rating input > > > > parameters, also in case of postpaid users. Also there might > > > > be some existing service specific authentication and > > > > authorization protocols, which then need to be updated to > > > > include these > > > > parameters. > > > > > > The HAAA knows what service the user wants. The rating > > > engine will have the > > > rating information anyway. So I don't see the problem here. > > > > > > > > > > > The client may need more quotas during the services and > > it may send > > > > interim request to the server requesting more quotas and > > > > reporting used quotas, i.e. session based credit control (or > > > > prepaid). The Diameter base accounting supports session based > > > > accounting (start, interim and stop) > > > > and this suits very well for credit control as well. This > > > is also one > > > > reason why we want to associate the credit control > > > > application with the > > > > accounting, i.e. only few additional AVPs + new accounting > > > > state machines (credit control session state machines) > > are needed. > > > > > > Asking for more quotas can be achieved by authorization > > > requests. After all > > > it is a reauthorization operation. You are authorizing the > > > user to continue > > > to use the session. Infact, because in RADIUS accounting > > > messages are not > > > acted on -- they are used for recording -- and in fact, > they can be > > > processed in batch by proxies (and hence are not real-time), > > > these operation > > > really should be done using Access Request messages. > > > > > > > When session based credit control is used then credit control > > > > server must maintain the session. If authorization commands > > > > would be used, then during initial authorization the > > > > authorization server should establish the session towards > > > > credit control server in order to perform 'prepaid > > > > authorization'. > > > Well, in my opinion the Access Device talks to the HAAA. The > > > HAAA then talks > > > to the Prepaid System. Both results comeback to the > Access Device. > > > > > > This is a Diameter problem which in my opinion needs to be > > > fixed. The HAAA > > > should be able to communicate with a prepaid server using your > > > specification. Both the resutls need to be combined and sent > > > back to the > > > Access Device. Diameter should allow me to do that. > > > > > > >Then the re-authorization for additional > > > > quotas during the session should flow through the AAA server > > > > to the prepaid server, adding an > > > > extra stateful hop (proxy, translator) in the signaling. > > When using > > > > accounting commands the client can communicate directly with > > > > the prepaid > > > > server. > > > > > > > > You are right the draft is not just for the 3GPP and of > > > > course they also > > > > authenticate and authorize the subscriber for the network > > > access and > > > > for the services as well. For instance for multimedia > > > > services the Diameter Multimedia Application can be used. > > > > > > If its not for 3GPP then I think my scenrio should be > > > considered. 3GPP2 > > > does it in one phase. There are timing issues. There is a > > > concern that to > > > phases will take too long. > > > > > > > Regards......Harri > > > > > > > From owner-aaa-wg@merit.edu Thu Apr 17 10:18:45 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 KAA22916 for ; Thu, 17 Apr 2003 10:18:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BFA7D912A9; Thu, 17 Apr 2003 10:21:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F0F2912AA; Thu, 17 Apr 2003 10:21:11 -0400 (EDT) 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 529F8912A9 for ; Thu, 17 Apr 2003 10:21:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 21BCF5DEAF; Thu, 17 Apr 2003 10:21:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by segue.merit.edu (Postfix) with SMTP id 578C35DEAC for ; Thu, 17 Apr 2003 10:21:09 -0400 (EDT) Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for segue.merit.edu [198.108.1.41]) with SMTP; Thu, 17 Apr 2003 15:23:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Diameter AVP Discrepancies Date: Thu, 17 Apr 2003 15:21:12 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE01C8CF37@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: Diameter AVP Discrepancies Thread-Index: AcME7Jd7tQkNrzHKR9qmlZBOjhkzGA== From: "Simon Bradley" To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA22916 Reading draft-ietf-aaa-diameter-17, there are some discrepancies between the AVP table in section 4.5 and the descriptive text that follows. Accounting-Realtime-Required The table says it is of type Unsigned32. The text says it is of type Enumerated. Accounting-Session-Id The table calls it Accounting-RADIUS-Session-Id. The text calls it Accounting-Session-Id. Acct-Application-Id The table says it is of type Integer32. The text says it is of type Unsigned32. Acct-Interim-Interval The table calls it Accounting-Interim-Interval. The text calls it Acct-interim-Interval. Auth-Application-Id The table says it is of type Integer32. The text says it is of type Unsigned32. Destination-Realm The table says it is of type UTF8String. The text says it is of type DiameterIdentity. Origin-Realm The table says it is of type UTF8String. The text says it is of type DiameterIdentity. Also: Inband-Security-Id The details in the table seem to have skipped down a line. Has it lost its M/P/V flags? Apologies if any/all of these have already been reported. -- Simon -- Simon Bradley, Ubiquity Software Corporation Ubiquity House, Langstone Park Newport NP18 2LH, UK Tel: +44 (0)1663 765600 e-mail: sbradley@ubiquity.net From owner-aaa-wg@merit.edu Thu Apr 17 11:48: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 LAA26006 for ; Thu, 17 Apr 2003 11:48:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 61DF3912AD; Thu, 17 Apr 2003 11:51:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1EE28912AE; Thu, 17 Apr 2003 11:51:06 -0400 (EDT) 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 C993F912AD for ; Thu, 17 Apr 2003 11:51:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B83B65DE68; Thu, 17 Apr 2003 11:51:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by segue.merit.edu (Postfix) with ESMTP id 9C1A25DE37 for ; Thu, 17 Apr 2003 11:51:03 -0400 (EDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel8.hp.com (Postfix) with ESMTP id 475461C017C4; Thu, 17 Apr 2003 11:51:03 -0400 (EDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 20D131C00A59; Thu, 17 Apr 2003 11:51:03 -0400 (EDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2655.55) id <2JYAX5MX>; Thu, 17 Apr 2003 11:51:02 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A566B9FB@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Simon Bradley'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter AVP Discrepancies Date: Thu, 17 Apr 2003 11:51:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, This is an excellent argument for having a formal single source for the information model which is used. IPDR provides such a model in XML, so that using stylesheets you can repurpose the information in any format you want while avoiding human transcription errors. Regards, Jeff Meyer > -----Original Message----- > From: Simon Bradley [mailto:sbradley@ubiquity.net] > Sent: Thursday, April 17, 2003 7:21 AM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Diameter AVP Discrepancies > > > Reading draft-ietf-aaa-diameter-17, there are some > discrepancies between the AVP table in section 4.5 and the > descriptive text that follows. > > Accounting-Realtime-Required > The table says it is of type Unsigned32. > The text says it is of type Enumerated. > > Accounting-Session-Id > The table calls it Accounting-RADIUS-Session-Id. > The text calls it Accounting-Session-Id. > > Acct-Application-Id > The table says it is of type Integer32. > The text says it is of type Unsigned32. > > Acct-Interim-Interval > The table calls it Accounting-Interim-Interval. > The text calls it Acct-interim-Interval. > > Auth-Application-Id > The table says it is of type Integer32. > The text says it is of type Unsigned32. > > Destination-Realm > The table says it is of type UTF8String. > The text says it is of type DiameterIdentity. > > Origin-Realm > The table says it is of type UTF8String. > The text says it is of type DiameterIdentity. > > Also: > > Inband-Security-Id > The details in the table seem to have skipped down a line. > Has it lost its M/P/V flags? > > Apologies if any/all of these have already been reported. > > -- Simon > > -- > Simon Bradley, Ubiquity Software Corporation > Ubiquity House, Langstone Park > Newport NP18 2LH, UK > Tel: +44 (0)1663 765600 > e-mail: sbradley@ubiquity.net > From owner-aaa-wg@merit.edu Thu Apr 17 15:52: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 PAA05341 for ; Thu, 17 Apr 2003 15:52:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D51E6912C3; Thu, 17 Apr 2003 15:55:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A44CD912C4; Thu, 17 Apr 2003 15:55:00 -0400 (EDT) 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 94C47912C3 for ; Thu, 17 Apr 2003 15:54:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7F5545DDF9; Thu, 17 Apr 2003 15:54:59 -0400 (EDT) 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 B9A595DDA8 for ; Thu, 17 Apr 2003 15:54:58 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3HJsvD17533 for ; Thu, 17 Apr 2003 22:54:57 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Apr 2003 22:54:57 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Apr 2003 22:54:57 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Apr 2003 22:54:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Diameter AVP Discrepancies Date: Thu, 17 Apr 2003 22:52:49 +0300 Message-ID: Thread-Topic: [AAA-WG]: Diameter AVP Discrepancies Thread-Index: AcME+TYPCSLCyetiT8+BVje41/Ig6wAIadWw From: To: , , X-OriginalArrivalTime: 17 Apr 2003 19:54:52.0295 (UTC) FILETIME=[35E4D170:01C3051B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA05341 Hi, > This is an excellent argument for having a formal single source > for the information model which is used. > > IPDR provides such a model in XML, so that using stylesheets > you can repurpose the information in any format you want while > avoiding human transcription errors. I kind of agree. When it comes to document editing, NROFF is not your friend ... John From owner-aaa-wg@merit.edu Sat Apr 19 04:42:32 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 EAA21401 for ; Sat, 19 Apr 2003 04:42:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B7BE691201; Sat, 19 Apr 2003 04:40:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 855E791203; Sat, 19 Apr 2003 04:40:17 -0400 (EDT) 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 5EFF591201 for ; Sat, 19 Apr 2003 04:40:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3DF615E119; Sat, 19 Apr 2003 04:40:16 -0400 (EDT) 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 D57DC5E10C for ; Sat, 19 Apr 2003 04:40:15 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C19916A901; Sat, 19 Apr 2003 11:39:52 +0300 (EEST) Message-ID: <3EA10B1B.2010305@kolumbus.fi> Date: Sat, 19 Apr 2003 11:38:51 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Bradley Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter AVP Discrepancies References: <45730E094814E44488F789C1CDED27AE01C8CF37@GBNEWP0758M.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE01C8CF37@GBNEWP0758M.eu.ubiquity.net> 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 Thanks for observing these discrepancies! Hopefully, we can take care of this in the author's 48 hours when the RFC editor is done... Jari Simon Bradley wrote: > Reading draft-ietf-aaa-diameter-17, there are some discrepancies between the AVP table in section 4.5 and the descriptive text that follows. > > Accounting-Realtime-Required > The table says it is of type Unsigned32. > The text says it is of type Enumerated. > > Accounting-Session-Id > The table calls it Accounting-RADIUS-Session-Id. > The text calls it Accounting-Session-Id. > > Acct-Application-Id > The table says it is of type Integer32. > The text says it is of type Unsigned32. > > Acct-Interim-Interval > The table calls it Accounting-Interim-Interval. > The text calls it Acct-interim-Interval. > > Auth-Application-Id > The table says it is of type Integer32. > The text says it is of type Unsigned32. > > Destination-Realm > The table says it is of type UTF8String. > The text says it is of type DiameterIdentity. > > Origin-Realm > The table says it is of type UTF8String. > The text says it is of type DiameterIdentity. > > Also: > > Inband-Security-Id > The details in the table seem to have skipped down a line. > Has it lost its M/P/V flags? > > Apologies if any/all of these have already been reported. > > -- Simon > From owner-aaa-wg@merit.edu Tue Apr 22 05:02: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 FAA00735 for ; Tue, 22 Apr 2003 05:02:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8491991255; Tue, 22 Apr 2003 05:05:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3FD1991256; Tue, 22 Apr 2003 05:05:11 -0400 (EDT) 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 EBC1191255 for ; Tue, 22 Apr 2003 05:05:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C2CCD5DEBD; Tue, 22 Apr 2003 05:05:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from m2-pasarela3.airtel.es (unknown [212.166.209.12]) by segue.merit.edu (Postfix) with ESMTP id DC0905DEAF; Tue, 22 Apr 2003 05:05:07 -0400 (EDT) To: owner-aaa-wg@merit.edu Cc: "'paco.marin@vodafone.com'" , "'aaa-wg@merit.edu'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" , "Harri Hakala (LMF)" From: paco.marin@vodafone.com Subject: Re: RE: Re: [AAA-WG]: Diameter Credit, Parlay, PayCircle and IPDR... Date: Tue, 22 Apr 2003 11:05:04 +0200 Message-ID: X-MIMETrack: Serialize by Router on M2-SMTP3/AIRTEL(Release 5.0.10 |March 22, 2002) at 04/22/2003 11:05:08 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA00735 Hi Jeff, (sorry about the delay in the answer, I was on hollidays). A very interesting answer, Jeff, it is a very, very valuable to me because it represents a different point of view. Anyway, I have some comments (see below). Best Regards and Thanks for all, Paco Marín ------------------- Vodafone Group R&D -------------------------------------------------------------------- >> "MEYER,JEFFREY D (HP-Cupertino,ex1)" De: owner-aaa-wg@merit.edu Para: "'paco.marin@vodafone.com'", "'aaa-wg@merit.edu'" cc: "MEYER,JEFFREY D (HP-Cupertino,ex1)", "Harri Hakala (LMF)" Asunto: RE: Re: [AAA-WG]: Diameter Credit, Parlay, PayCircle and IPDR... Paco, Although I see the synergy between PayCircle (which is based on concepts from Parlay) and Diameter, in that an application developer may want to write to a web services type interface vs. a binary interface; I am less clear on whether the API defined by Parlay is simpler than that being defined for Diameter. ---- Paco>> Yes, there is no reasons to think that the Parlay API is simpler than that defined for Diameter (in PayCircle)... that was not the purpose of Parlay. ---- Aspects around tunneling and proxying are also issues which Diameter addresses well, but I suspect are more of an open issue in Parlay. ---- Paco>> It is possible to apply tunneling to the IP connection between the Parlay Application Server and the Parlay SCS. And... yes, the details of proxying is out of the scope of Parlay, once the access from an external network to the operator network is solved Parlay has accomplish its role. The only proxy function is produced in the SCS which is the door to the network assets. That is the reason of thinking that Parlay and Diameter Protocol do not exclude each other but are complementary (Diameter for indoor part of the system). ---- It seems to me that Parlay's key design center was around abstracting interactions into today's IN/SS7 networks, which requires some proxying to enable apps on general purpose platforms to interact with the signalling network. ---- Paco>> We don't have to mistake the relation SS7 network versus IP network with the relation call models versus transactional models. What I mean is that in a telecommunication network there are different possible communication models: asynchronous transactions, synchronous transactions, call models, events notifications, and so on... It could happen both in a SS7 or IP network (note that what happens in SIP is to export the previous SS7 features to IP, it means irremediablely exporting to IP the SS7 telecommunications models as well). On the other hand, when we talk about the Web Services model we are talking about only an asynchronous transactional model... and don't pay attention to the remaining telecommunication models. Parlay has been designed to take over remotely of these network features (e.g. call models, event notification, and so on...). Paco>> That is to say Parlay was not extrictelly designed to interact with the SS7 network but to interact with telecommunication features and models... the protocol underneath is (or must be) transparent. One of these features is charging, however in charging it is not especified the type of network protocol underneath... it could be Diameter. Don't think the call models are not models of future, remember that SIP has the same call models over IP. ---- However, for general applications, which want to be able to service not just devices connected through the GSM/PSTN network, but IP devices in general, then I think the value of Parlay is limited. ---- Paco>>yes... and NO... It depends on what we want. I think we cannot say neither a Web Services (PayCircle) model is better than a Parlay model nor vice versa. Each model fits some specific requirements. If we want only to base our services in an asychronous transactional model... yes, what we need is only PayCircle model... and this model will fit much better the requirements than Parlay... it is easier to use and more confortable for developers. However, if we need other models or joint several models to face our services we have to use Parlay or some similar model. ---- Maybe I missed something in my reading of Parlay, but these interfaces don't seem too friendly to me. It seems like there is a lot of API overhead involved in making CORBA behave like an asynchronous interface, which it doesn't want to be. ---- Paco>> Yes, Jeff, likely the Parlay interfaces are not too friendly, that's the price of the details. There is only a question of confortability versus details. however, it would be possible to introduce new interfaces over Parlay able to simplify the use for the developers... and to resort to the details if necessary... however it is a question of the specific use. Paco>> Yes, CORBA is a synchronous middleware and it has been forced to act as an asynchronous interface for this purpose. The solutions have not been too brilliant (multi thread: error-prone and 'one way': inefficient). At the moment there is new versions of CORBA, Real Time CORBA (RT-CORBA) that tries to solve this issue introducing asynchronous methods and procedures.... but it is still to be tested. However, the tests that I have carried out for a Parlay API on CORBA has been quite successful, but I have to confess that I didn't accomplish load traffic tests. ---- In any event, this isn't the right venue to discuss the virtues and foibles of Parlay. But it is reasonable to say that there will be some Parlay apps, the Parlay developers have spent time investigating this space, and ensuring that information exchange between the Diameter and Parlay based apps, as in your diagram, is enabled if possible. ---- Paco>> Yes, this is not the venue to discuss that... sorry about the 'will' above. However it would be important to ensure the alignment between Parlay and the corresponding mapping into Diameter.... Probably a job for the Parlay people (or OMA)?... I don't know. Unfortunately, I have no time to devote to it.... My best regards and thanks for all, ---- Regards, Jeff Meyer > -----Original Message----- > From: paco.marin@vodafone.com [mailto:paco.marin@vodafone.com] > Sent: Friday, April 11, 2003 2:38 PM > To: 'aaa-wg@merit.edu' > Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); Harri Hakala (LMF) > Subject: Re: Re: [AAA-WG]: Diameter Credit, Parlay, PayCircle and > IPDR... > > > (Thanks, Harri) > > > Hi Harri, Jeff, all > > Parlay domain are limited to services that use the Parlay > Framework. However, I think that the > relationship between Parlay and Diameter is very important > and complementary. > > Parlay is not conceived as a core network protocol but a > protocol to abstract a service level from > the core network. The objectives are two: to have a service > level where to implement in an easy way > application logics for the services using APIs able to > simplify the process for the developers ( > fast and cheap developing services); and to be able to > provide a Framework and APIs to third parties > in order to allow them using the network operator assets in a > controlled manner (it allows the > network operator to control the charging, for instance). > > I consider Diameter as a core network protocol, it means that > the relation between Parlay and > Diameter is the physical realization or mapping of the Parlay > procedures and messages (defined by > the API) into Diameter procedures and messages. > > I think it would be very important to certify the alignment > between both protocols. > > > > The schema would be as follows: > > > > middleware > ------------ -------- > | Parlay |A | | Parlay | PARLAY > | |P | ----------| |GATEWAY > | Service |I | | SCS | > ------------ |--------| > APLICATION |Diameter| > SERVER |Enabler | - (Credit > -------- Control > | Application) > | > |Diameter > | > | > --------- > | | > | Credit | > | | > | Control | > | | > | Server | > | | > --------- > > > Note that there is not cannibalisation between both protocols > but they are complementary. Diameter > protocols is able to integrate several systems and Parlay > allows to use these systems in a easy way > both for local services and for third party services. The > sinergy of joint solutions is great. > > > Cheers, > > > > > Paco Marín > ------------------- > Vodafone Group R&D > C/ Trespaderne, 29 Edificio Barajas 1_B > Madrid > Spain > T: +34 607135244 > F: +34 607 135252 > -------------------------------------------------------------------- > > > > > > "MEYER,JEFFREY D (HP-Cupertino,ex1)" > Enviado por: owner-aaa-wg@merit.edu > 10/04/2003 19:07 > > Para: "'aaa-wg@merit.edu'" > cc: > cco: > Asunto: [AAA-WG]: Diameter Credit, Parlay, > PayCircle and IPDR... > > > Hi, > > I'm forwarding this e-mail, because it didn't initially appear on > the list due to mailer issues on my end. > > Regards, > > Jeff Meyer > > -----Original Message----- > From: MEYER,JEFFREY D (HP-Cupertino,ex1) > Sent: Wednesday, April 09, 2003 9:02 AM > To: 'Harri Hakala (LMF)'; 'aaa-wg@merit.edu'; MEYER,JEFFREY D > (HP-Cupertino,ex1) > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > Harri, > > Thanks for the response. Regarding the domain of Parlay, I'd agree > it presumes a Parlay framework. However, it also has an "Information > Model" aimed at addressing the same credit control space as your > draft, so to that end trying to align these information models is > where the use of a common model for describing the information payload > in a manner independent of encoding and transport is where IPDR can > come into play. > > I know there was work on a dictionary framework in the Diameter > group, but that seems to have stalled out. What I would like to do > is resurrect that model, but using IPDR's XML-Schema with annotation > approach. This would likely require a draft on its own, I'll begin > looking into that. > > I'll also look to see if there is some "placeholder" > language which would > be appropriate for the credit control draft. > > Regards, > > Jeff Meyer > > > -----Original Message----- > > From: Harri Hakala (LMF) [mailto:Harri.Hakala@lmf.ericsson.se] > > Sent: Wednesday, April 09, 2003 1:31 AM > > To: 'aaa-wg@merit.edu'; 'MEYER,JEFFREY D (HP-Cupertino,ex1)' > > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > > > > > Any comments on the relationship of this application to Parlay > > > section 12 and PayCircle? > > > > > > http://www.parlay.org/specs/3.2/es_20191512Charging.zip > > > > > > http://www.paycircle.org > > > > > > It seems that all of these are addressing the same > basic issue of > > > authorization of services with possible reservation of credit on > > > the backend. > > > > Isn't the applicability of OSA/Parlay charging API limited to > > services that > > have been built using the OSA/Parlay framework?. > > I foresee that there are services built using other > > mechanisms and are therefore > > outside this framework. > > > > Our motivation is to define an IP-based accounting protocol > > to support credit > > based accounting by using the AAA infrastructure. Because the > > Diameter base > > protocol provides several features, which are required from > > this kind of application > > and because the Diameter and its accounting can be widely > > utilized we thought that > > the AAA framework and Diameter is a good choice for this kind > > of IP-based accounting > > protocol. > > > > I assume that there are several (and more and more are being > > developed) this kind of > > applications focusing on online payments and credit > > reservations using quite similar > > mechanisms, but having a bit different scope and framework. > > > > > A harmonization of terminology, and ideally attribute names and > > > data types would be worthwile. > > > > > > The IPDR.org (http://www.ipdr.org) group is looking at > aspects of > > > performing > > > this harmonization. For some information on the separation > > > of information > > > model, from encoding from transport see: > > > > > > http://www.circumference.org/circumference.ppt > > > > A harmonization of terminology, etc, defined by different > > standardization bodies, > > would be helpful, although it might be quite challenging task. > > > > It would be good if you can provide us with proposals for > > changed text in the draft. > > > > Regards.........Harri > > > > > -----Original Message----- > > > From: MEYER,JEFFREY D (HP-Cupertino,ex1) > [mailto:jeff.meyer2@hp.com] > > > Sent: 9. huhtikuuta 2003 2:56 > > > To: Harri Hakala (LMF); aaa-wg@merit.edu > > > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > > > > > > > Harri, > > > > > > Any comments on the relationship of this application to Parlay > > > section 12 and PayCircle? > > > > > > http://www.parlay.org/specs/3.2/es_20191512Charging.zip > > > > > > http://www.paycircle.org > > > > > > It seems that all of these are addressing the same > basic issue of > > > authorization of services with possible reservation of credit on > > > the backend. > > > > > > A harmonization of terminology, and ideally attribute names and > > > data types would be worthwile. > > > > > > The IPDR.org (http://www.ipdr.org) group is looking at > aspects of > > > performing > > > this harmonization. For some information on the separation > > > of information > > > model, from encoding from transport see: > > > > > > http://www.circumference.org/circumference.ppt > > > > > > > > > Regards, > > > > > > Jeff Meyer > > > HP > > > http://www.hp.com/usage > > > > > > > > > > > > > -----Original Message----- > > > > From: Harri Hakala (LMF) [mailto:Harri.Hakala@lmf.ericsson.se] > > > > Sent: Friday, February 28, 2003 1:55 AM > > > > To: aaa-wg@merit.edu > > > > Subject: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt > > > > > > > > > > > > Hi All, > > > > > > > > We have submitted a new version of the Diameter credit > > control draft > > > > to the IETF archive. > > > > > > > > Until it shows up in the archive, it can be found: > > > > http://standards.ericsson.net/harri/draft-hakala-diameter-cred > > > it-control-06.txt > > > > > > Here is a list of updates compared to draft -05: > > > 1. A server or client is not required to implement all > > > functionality in > > > the CCA. The optionality has been clarified in the draft, the > > > modified > > > AVPs are the following: > > > > > > 1a. Unknown/unsupported value responded with error: > > > - Subscription-Id-Type > > > > > > 1b. Unknown AVP ignored, i.e. 'M'-bit removed from AVP Flag table > > > - Accounting-Correlation-Id > > > - Abnormal-Termination-Reason > > > - Cost-Information > > > > > > 2. New Result-Code value 'DIAMETER_RATING_FAILED'. > > > > > > We would appreciate if you can read it and provide your comments. > > > > > > Regards.......Harri > > > > > > > > > From owner-aaa-wg@merit.edu Wed Apr 23 06:27:02 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 GAA10213 for ; Wed, 23 Apr 2003 06:27:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6947191205; Wed, 23 Apr 2003 06:29:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CE3991206; Wed, 23 Apr 2003 06:29:30 -0400 (EDT) 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 DC1CF91205 for ; Wed, 23 Apr 2003 06:29:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C932A5E0F4; Wed, 23 Apr 2003 06:29:28 -0400 (EDT) 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 0E57B5E0F1 for ; Wed, 23 Apr 2003 06:29:28 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3NATQD20960 for ; Wed, 23 Apr 2003 13:29:26 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 23 Apr 2003 13:29:23 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 23 Apr 2003 13:29:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: AVP Header? Date: Wed, 23 Apr 2003 13:29:21 +0300 Message-ID: Thread-Topic: AVP Header? Thread-Index: AcMJgzPSseckGanKSm6zY3KviFX+vQ== From: To: X-OriginalArrivalTime: 23 Apr 2003 10:29:21.0900 (UTC) FILETIME=[3447EAC0:01C30983] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA10213 Hi, Section 11.1. says: "As defined in section 4, the AVP header contains three fields that requires IANA namespace management; the AVP Code, Application-ID and Flags field." Section 4.1 lists AVP Code, AVP Flags, and Vendor-Id (optional). Then there is the Vendor-Id AVP too. Should the AVP header contain Application-Id field or not? - Dan From owner-aaa-wg@merit.edu Wed Apr 23 08:02: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 IAA14666 for ; Wed, 23 Apr 2003 08:02:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 90F6391208; Wed, 23 Apr 2003 08:05:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5C7BE91209; Wed, 23 Apr 2003 08:05:19 -0400 (EDT) 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 3008491208 for ; Wed, 23 Apr 2003 08:05:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 165295E114; Wed, 23 Apr 2003 08:05:18 -0400 (EDT) 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 CC5765E112 for ; Wed, 23 Apr 2003 08:05:17 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id DB3F46A904; Wed, 23 Apr 2003 15:05:15 +0300 (EEST) Message-ID: <3EA68138.4020100@kolumbus.fi> Date: Wed, 23 Apr 2003 15:04:08 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan.Forsberg@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: AVP Header? 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 Dan.Forsberg@nokia.com wrote: > Hi, > > Section 11.1. says: "As defined in section 4, the AVP header contains three fields that requires IANA namespace management; the AVP Code, Application-ID and Flags field." Section 4.1 lists AVP Code, AVP Flags, and Vendor-Id (optional). Then there is the Vendor-Id AVP too. Should the AVP header contain Application-Id field or not? No, Section 11.1 is wrong. Yet another thing to take care of in Auth-48... s/Appliation ID/vendor ID/ Jari From owner-aaa-wg@merit.edu Wed Apr 23 08:09: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 IAA14876 for ; Wed, 23 Apr 2003 08:09:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 66DB191209; Wed, 23 Apr 2003 08:11:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E6489120A; Wed, 23 Apr 2003 08:11:56 -0400 (EDT) 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 E3C7191209 for ; Wed, 23 Apr 2003 08:11:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A7EB95E118; Wed, 23 Apr 2003 08:11:54 -0400 (EDT) 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 D633B5E114 for ; Wed, 23 Apr 2003 08:11:53 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3NCBqD06848 for ; Wed, 23 Apr 2003 15:11:52 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 23 Apr 2003 15:11:48 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 23 Apr 2003 15:11:48 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 23 Apr 2003 15:10:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: AVP Header? Date: Wed, 23 Apr 2003 15:09:58 +0300 Message-ID: Thread-Topic: [AAA-WG]: AVP Header? Thread-Index: AcMJkKm/PHFFriQjTwOPD392nZSLoQAAI7wA From: To: , Cc: X-OriginalArrivalTime: 23 Apr 2003 12:10:20.0139 (UTC) FILETIME=[4F45D3B0:01C30991] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA14876 Yes, I am keeping track of all of this .... John > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: 23 April, 2003 15:04 > To: Forsberg Dan (NRC/Helsinki) > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: AVP Header? > > > Dan.Forsberg@nokia.com wrote: > > Hi, > > > > Section 11.1. says: "As defined in section 4, the AVP > header contains three fields that requires IANA namespace > management; the AVP Code, Application-ID and Flags field." > Section 4.1 lists AVP Code, AVP Flags, and Vendor-Id > (optional). Then there is the Vendor-Id AVP too. Should the > AVP header contain Application-Id field or not? > > No, Section 11.1 is wrong. Yet another thing to take care of > in Auth-48... s/Appliation ID/vendor ID/ > > Jari > > > From owner-aaa-wg@merit.edu Mon Apr 28 07:29: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 HAA27123 for ; Mon, 28 Apr 2003 07:29:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 619A991205; Mon, 28 Apr 2003 07:31:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1AE0F912AE; Mon, 28 Apr 2003 07:31:35 -0400 (EDT) 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 40BD791205 for ; Mon, 28 Apr 2003 07:31:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 137A75E008; Mon, 28 Apr 2003 07:31:29 -0400 (EDT) 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 0D16A5E0AA for ; Mon, 28 Apr 2003 07:31:28 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3SBVQD11495 for ; Mon, 28 Apr 2003 14:31:26 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 28 Apr 2003 14:31:26 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 28 Apr 2003 14:31:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Any benefits for using Diameter message format in UNI interface? Date: Mon, 28 Apr 2003 14:31:25 +0300 Message-ID: Thread-Topic: Any benefits for using Diameter message format in UNI interface? Thread-Index: AcMNebPywXANH+N+Ta607yq/YBS9lg== From: To: Cc: X-OriginalArrivalTime: 28 Apr 2003 11:31:26.0322 (UTC) FILETIME=[B4465D20:01C30D79] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA27123 Hi, We are discussing in PANA WG about the possibility to use Diameter message formatting between PaC and PAA (PAA is generally seen as the AAA Client for the backend AAA). PANA's request/response (see IKEv2 exchanges) style transport together with Diameter message formatting would open up possibilities to extend Diameter apps to work with mobile clients too. Anyway, PANA deals with authentication and authorization which makes Diameter kind of suitable choice for message formatting. PANA could specify new command codes (PANA messages) and AVPs when needed. Do you see any drawbacks with this approach? IANA considerations are of course needed. One possibility could be to preserve a new Application Id for PANA. For PANA it doesn't give any benefit, except the compatibility. Another choice would just mark the App-Id field reserved in PANA spec. Third possibility is to use the App-Id field in PANA scope and separate it from the Diameter App-Ids. Currently Application-Id field is seen as an extra field for the PANA header. If we remove that, compatibility with Diameter is lost, though. PANA also uses two sequence numbers in place of Hop-by-Hop Id and End-to-End Ids which makes PANA a bit different too. -- Another question/proposal. Would there be interest to have an extended support for Diameter over UDP (between mobile client and network), if PANA doesn't go into this direction. Message transport would be request/response style exchanges like in IKEv2 and message formatting Diameter. Sequence numbering similar to IKEv2, which also suits well with Diameter Hop-by-Hop and End-to-End Ids. The result would be to provide transport for Diameter Applications over UDP (connectionless). This would enable roaming clients to be part of apps, because of the sessionless kind of nature of the UDP (no IP binding needed nor handshakes like in TCP or SCTP). IKEv2 could be used to bootstrap an SA between client and the network (optionally one way or mutual authentication too) and to protect the integrity. Together with possible session resumption capabilities and confidentiality protection this framework becomes quite an interesting platform for apps. Let me hear your comments. Tnx, - Dan From owner-aaa-wg@merit.edu Mon Apr 28 10:42:11 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 KAA03371 for ; Mon, 28 Apr 2003 10:42:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 568CA91209; Mon, 28 Apr 2003 10:44:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2015F9120C; Mon, 28 Apr 2003 10:44:45 -0400 (EDT) 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 1627591209 for ; Mon, 28 Apr 2003 10:44:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E5F465DF13; Mon, 28 Apr 2003 10:44:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h000.c000.snv.cp.net [209.228.32.64]) by segue.merit.edu (Postfix) with SMTP id 655E15DEF8 for ; Mon, 28 Apr 2003 10:44:43 -0400 (EDT) Received: (cpmta 14226 invoked from network); 28 Apr 2003 07:44:42 -0700 Received: from 24.147.218.40 (HELO dmitton.mitton.com) by smtp.mitton.com (209.228.32.64) with SMTP; 28 Apr 2003 07:44:42 -0700 X-Sent: 28 Apr 2003 14:44:42 GMT Message-Id: <5.2.1.1.2.20030428104239.0446dad0@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 28 Apr 2003 10:44:29 -0400 To: From: David Mitton Subject: Re: [AAA-WG]: Issue #403 some NASREQ-11 comments Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk John, all your comments will be addressed in the next rev. Thanks. getting all the others done is still taking time... ;^( I expect to post an interim version within the next few days. Dave. On 3/11/2003 02:47 PM +0200, john.loughney@nokia.com wrote: >David, > >NASREQ-11 looks good. I saw Jari did a detailed review, so mine is somewhat >less detailed. Some comments that things that caught my eye: > >1) Abstract: spell out EAP and CMS. > >2) Terminology section could be useful to add, but maybe reference > the Base spec terminology & just add new terms. > >3) Indentation problem in 4.1 > >4) 4.1, first sentence: > > This section contains the NAS unique AVPs that are needed to identify > > sounds a bit awkward, maybe dropping the NAS would make more > gramatical sense. > >I think that Jari seemed to get everything else I had noted down. > >John