From mailman-admin@ietf.org Sat Mar 1 09:56:44 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 JAA06739 for ; Sat, 1 Mar 2003 09:56:44 -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 h21F5kp19496 for ; Sat, 1 Mar 2003 10:05:46 -0500 Date: Sat, 01 Mar 2003 10:05:46 -0500 Message-ID: <20030301150546.26394.4686.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 Wed Mar 5 08:01:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29124 for ; Wed, 5 Mar 2003 08:01:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F1A5191258; Wed, 5 Mar 2003 08:02:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1545491259; Wed, 5 Mar 2003 08:02:48 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3541C91258 for ; Wed, 5 Mar 2003 08:01:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id CE1965DF86; Wed, 5 Mar 2003 08:00:55 -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 8B9165DF85 for ; Wed, 5 Mar 2003 08:00:55 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 7275D6A901; Wed, 5 Mar 2003 15:00:53 +0200 (EET) Message-ID: <3E65F4D7.5050101@kolumbus.fi> Date: Wed, 05 Mar 2003 15:00:07 +0200 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: david@mitton.com Cc: aaa-wg@merit.edu, Bernard Aboba Subject: [AAA-WG]: NASREQ-11 comments References: <9E3407CE45911B4097632389B77B2023018702E4@esebe014.ntc.nokia.com> In-Reply-To: <9E3407CE45911B4097632389B77B2023018702E4@esebe014.ntc.nokia.com> 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 I have read through version 11. I have some questions as well as editorial and technical comments, inserted directly to the draft text. The URL for the comments is http://www.piuha.net/~jarkko/publications/aaa/nasreq_review.txt Here are my overall comments: We are nearing a state where this draft can be made an RFC. However, some work still remains. Some of the main comments: - Some keyword issues in, e.g., advertising, sending acct messages, ... - Some clarifications, e.g., should service still be provided while re-auth is going on, Accounting-Realtime-Required effects, Auth-Request default values, optionality of some AVPs in AAA/AAR requests, EVENT_RECORD, ... - Normative/informative nature of the old RADIUS AVP semantics needs clarification. - Some question marks on the semantics of the AVPs, but I'm not sure we can do much if the old RADIUS specifications apply in any case. - I'd prefer sections 9.1 and 9.1.1 to be more in the usual keyword style than in the current "example of steps that may be followed format". - AVP table inconsistencies wrt base. - Some additions to the security considerations may be needed, e.g. RADIUS translation. - Editorial corrections Jari From owner-aaa-wg@merit.edu Fri Mar 7 09:10: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 JAA03163 for ; Fri, 7 Mar 2003 09:10:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 44AA99122C; Fri, 7 Mar 2003 09:12:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 168939122E; Fri, 7 Mar 2003 09:12: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 BF9319122C for ; Fri, 7 Mar 2003 09:12:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id AA7F65DF23; Fri, 7 Mar 2003 09:12:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from web20705.mail.yahoo.com (web20705.mail.yahoo.com [216.136.226.178]) by segue.merit.edu (Postfix) with SMTP id E355B5DEFE for ; Fri, 7 Mar 2003 09:12:26 -0500 (EST) Message-ID: <20030307141226.66593.qmail@web20705.mail.yahoo.com> Received: from [203.124.158.2] by web20705.mail.yahoo.com via HTTP; Fri, 07 Mar 2003 06:12:26 PST Date: Fri, 7 Mar 2003 06:12:26 -0800 (PST) From: arun kumar Subject: [AAA-WG]: Mobile IP Home Agent - AAA Server related To: aaa-wg@merit.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-925950967-1047046346=:66251" Sender: owner-aaa-wg@merit.edu Precedence: bulk --0-925950967-1047046346=:66251 Content-Type: text/plain; charset=us-ascii Hi All, I have a very basic question about Accounting support for Diameter Mobile-IP application. When the mobile node is in the home network is the Home Agent responsible for sending Accounting messages. ( In that case does the Home Agent also send AMR messages to Home Server) Thanks & Regards, Arun --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more --0-925950967-1047046346=:66251 Content-Type: text/html; charset=us-ascii

Hi All,

     I have a very basic question about Accounting support for Diameter Mobile-IP application.

When the mobile node is in the home network is the Home Agent responsible for sending Accounting messages. ( In that case does the Home Agent also send AMR messages to Home Server)

Thanks & Regards,

Arun




Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, and more --0-925950967-1047046346=:66251-- From owner-aaa-wg@merit.edu Tue Mar 11 07:47:20 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17663 for ; Tue, 11 Mar 2003 07:47:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E3FDA912FE; Tue, 11 Mar 2003 07:49:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F8D4912FD; Tue, 11 Mar 2003 07:49:13 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ADBFE912FB for ; Tue, 11 Mar 2003 07:48:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id D7EF35DE79; Tue, 11 Mar 2003 07:47:59 -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 0BD295E05C for ; Tue, 11 Mar 2003 07:47:59 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2BCpOF26072 for ; Tue, 11 Mar 2003 14:51:24 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Mar 2003 14:47:56 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 14:47:56 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 14:47:55 +0200 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]: some NASREQ-11 comments Date: Tue, 11 Mar 2003 14:47:55 +0200 Message-ID: Thread-Topic: [AAA-WG]: NASREQ-11 comments Thread-Index: AcLjF5b4LFvy6bm7SX+YkHEiribUvwEsyLXw From: To: Cc: , X-OriginalArrivalTime: 11 Mar 2003 12:47:55.0740 (UTC) FILETIME=[6FF3F9C0:01C2E7CC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA17663 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 From owner-aaa-wg@merit.edu Wed Mar 12 07:53:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02128 for ; Wed, 12 Mar 2003 07:53:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9140E912F9; Wed, 12 Mar 2003 07:53:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 587D5912FF; Wed, 12 Mar 2003 07:53:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 45692912F9 for ; Wed, 12 Mar 2003 07:53:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 28EEF5E45B; Wed, 12 Mar 2003 07:53:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from margo.student.utwente.nl (cal003100.student.utwente.nl [130.89.160.36]) by segue.merit.edu (Postfix) with ESMTP id EA82E5E458 for ; Wed, 12 Mar 2003 07:53:01 -0500 (EST) Received: from simon by margo.student.utwente.nl with local (Exim 3.36 #1 (Debian)) id 18t5jB-0000f5-00 for ; Wed, 12 Mar 2003 13:53:01 +0100 Date: Wed, 12 Mar 2003 13:53:01 +0100 To: aaa-wg@merit.edu Subject: [AAA-WG]: DIAMETER ipv6 implementations? Message-ID: <20030312125300.GA2367@margo.student.utwente.nl> Mail-Followup-To: simon@trapdoor.merit.edu, aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i From: Simon Oosthoek Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi all I'm new to this list, so I'll introduce myself a bit... I'm working in a project called Beyond 3G, which is a dutch research project of a number of institutes and universities (start at www.beyond3g.org) We're focussing completely on IPv6, because we're of the opinion that the systems in use at the time we're thinking about (beyond 3g technology) will probably at least use IPv6 in some way, perhaps even exclusively. One of the problems we're encountering in setting up a demo is the lack of IPv6 support in DIAMETER or RADIUS implementations. I know the Moby Dick project (ist-mobydick.org?) is looking into building and open sourcing a DIAMETER server/proxy with IPv6 support, but I'm sure others must be looking into this as well. Of course, if we had time we could try and build an implementation ourselves, but we don't have that luxury. So I'm looking for information about already existing implementations that we might be able to use in a demo setup. Of course, the current status of IETF drafts/RFCs in this area interests me as well, although I noticed some relevant drafts have expired right now (draft-perkins-aaav6-05.txt and draft-ietf-mobileip-ipv6-19.txt) I'd be very grateful for any pointers to more detailed information on this subject or even experimental implementations or other research projects in this area. Thanks for reading this far! Cheers Simon From owner-aaa-wg@merit.edu Wed Mar 12 08:02: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 IAA02320 for ; Wed, 12 Mar 2003 08:02:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C209791308; Wed, 12 Mar 2003 08:04:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21ACD91306; Wed, 12 Mar 2003 08:04: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 BF3FD91308 for ; Wed, 12 Mar 2003 08:03:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 21CFF5E464; Wed, 12 Mar 2003 08:01:55 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from margo.student.utwente.nl (cal003100.student.utwente.nl [130.89.160.36]) by segue.merit.edu (Postfix) with ESMTP id 4103E5DEEC for ; Wed, 12 Mar 2003 08:01:52 -0500 (EST) Received: from simon by margo.student.utwente.nl with local (Exim 3.36 #1 (Debian)) id 18t5rj-0000hs-00 for ; Wed, 12 Mar 2003 14:01:51 +0100 Date: Wed, 12 Mar 2003 14:01:51 +0100 To: aaa-wg@merit.edu Subject: [AAA-WG]: DIAMETER ipv6 implementations? Message-ID: <20030312130151.GB2638@margo.student.utwente.nl> Mail-Followup-To: simon@trapdoor.merit.edu, aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i From: Simon Oosthoek Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi all I'm new to this list, so I'll introduce myself a bit... I'm working in a project called Beyond 3G, which is a dutch research project of a number of institutes and universities (start at www.beyond3g.org) We're focussing completely on IPv6, because we're of the opinion that the systems in use at the time we're thinking about (beyond 3g technology) will probably at least use IPv6 in some way, perhaps even exclusively. One of the problems we're encountering in setting up a demo is the lack of IPv6 support in DIAMETER or RADIUS implementations. I know the Moby Dick project (ist-mobydick.org?) is looking into building and open sourcing a DIAMETER server/proxy with IPv6 support, but I'm sure others must be looking into this as well. Of course, if we had time we could try and build an implementation ourselves, but we don't have that luxury. So I'm looking for information about already existing implementations that we might be able to use in a demo setup. Of course, the current status of IETF drafts/RFCs in this area interests me as well, although I noticed some relevant drafts have expired right now (draft-perkins-aaav6-05.txt and draft-ietf-mobileip-ipv6-19.txt) I'd be very grateful for any pointers to more detailed information on this subject or even experimental implementations or other research projects in this area. Thanks for reading this far! Cheers Simon PS, hopefully you don't receive this twice. From owner-aaa-wg@merit.edu Wed Mar 12 10:23:20 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07487 for ; Wed, 12 Mar 2003 10:23:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A9A5391346; Wed, 12 Mar 2003 10:25:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 72DA391349; Wed, 12 Mar 2003 10:25:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3882691346 for ; Wed, 12 Mar 2003 10:25:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 238F95DF44; Wed, 12 Mar 2003 10:25:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id 9C8175DF4E for ; Wed, 12 Mar 2003 10:25:09 -0500 (EST) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.8/8.12.1) with ESMTP id h2CFP1uG014837; Wed, 12 Mar 2003 10:25:02 -0500 (EST) Received: from localhost (ohba@tari-dhcp162.research.telcordia.com [207.3.232.162]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id KAA07796; Wed, 12 Mar 2003 10:25:09 -0500 (EST) Date: Wed, 12 Mar 2003 10:24:57 -0500 To: simon@merit.edu, aaa-wg@merit.edu Subject: Re: [AAA-WG]: DIAMETER ipv6 implementations? Message-ID: <20030312152457.GA962@catfish> References: <20030312125300.GA2367@margo.student.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <20030312125300.GA2367@margo.student.utwente.nl> User-Agent: Mutt/1.5.3i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 49 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello Simon, Open Diameter in sourceforge (http://www.sourceforge.net/projects/diameter) will support IPv6 from release 1.0.3 which we schedule to release in April 2003, considering the increasing demand for IPv6-supported Diameter implementation. I've received a report that some user of Open Diameter has modified the source code and successfully compiled with IPv6. Cheers, Yoshihiro Ohba On Wed, Mar 12, 2003 at 01:53:01PM +0100, Simon Oosthoek wrote: > Hi all > > I'm new to this list, so I'll introduce myself a bit... > > I'm working in a project called Beyond 3G, which is a dutch research project > of a number of institutes and universities (start at www.beyond3g.org) > > We're focussing completely on IPv6, because we're of the opinion that the > systems in use at the time we're thinking about (beyond 3g technology) will > probably at least use IPv6 in some way, perhaps even exclusively. > > One of the problems we're encountering in setting up a demo is the lack of > IPv6 support in DIAMETER or RADIUS implementations. I know the Moby Dick > project (ist-mobydick.org?) is looking into building and open sourcing a > DIAMETER server/proxy with IPv6 support, but I'm sure others must be looking > into this as well. > > Of course, if we had time we could try and build an implementation > ourselves, but we don't have that luxury. So I'm looking for information > about already existing implementations that we might be able to use in a > demo setup. Of course, the current status of IETF drafts/RFCs in this area > interests me as well, although I noticed some relevant drafts have expired > right now (draft-perkins-aaav6-05.txt and draft-ietf-mobileip-ipv6-19.txt) > > I'd be very grateful for any pointers to more detailed information on this > subject or even experimental implementations or other research projects in > this area. > > Thanks for reading this far! > > Cheers > > Simon > From owner-aaa-wg@merit.edu Wed Mar 12 13:56: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 NAA16181 for ; Wed, 12 Mar 2003 13:56:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D1A709134F; Wed, 12 Mar 2003 13:57:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9AA7C91351; Wed, 12 Mar 2003 13:57:58 -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 41B139134F for ; Wed, 12 Mar 2003 13:57:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1A3E55DDF5; Wed, 12 Mar 2003 13:57: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 935215DD93 for ; Wed, 12 Mar 2003 13:57:53 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2CHgsG28776 for ; Wed, 12 Mar 2003 09:42:54 -0800 Date: Wed, 12 Mar 2003 09:42:54 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Preliminary AAA WG Agenda, IETF 56 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk AAA WG Agenda, IETF 56, San Francisco Chairs: Bernard Aboba David Mitton Wednesday, March 19, 2003 1300 - 1500 Afternoon Session I Preliminaries (10 minutes) Bluesheets Minute Takers Agenda Bashing Document status Diameter NASREQ, David Mitton (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-11.txt Diameter Credit Control Application, Harri Hakala (10 minutes) http://www.ietf.org/internet-drafts/draft-hakala-diameter-credit-control-06.txt Diameter Multimedia Application, Maria-Carmen Belinchon (10 minutes) http://www.ietf.org/internet-drafts/draft-belinchon-aaa-diameter-mm-app-00.txt Diameter API, James Kempf (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-api-03.txt Diameter Mobile IPv4, Tony Johansson (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-13.txt Diameter CMS, Stephen Farrell (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-04.txt Issues in AAA Key Distribution (20 minutes), Russ Housley & Steve Bellovin http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt From owner-aaa-wg@merit.edu Wed Mar 12 16:03: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 QAA22596 for ; Wed, 12 Mar 2003 16:03:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 33D9891221; Wed, 12 Mar 2003 16:05:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E51F191241; Wed, 12 Mar 2003 16:05:15 -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 BAED291221 for ; Wed, 12 Mar 2003 16:05:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7069C5E49F; Wed, 12 Mar 2003 16:03:21 -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 138E25E4A2 for ; Wed, 12 Mar 2003 16:03:20 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2CJmJw03264 for ; Wed, 12 Mar 2003 11:48:19 -0800 Date: Wed, 12 Mar 2003 11:48:19 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 404: NASREQ-11 Issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 404: NASREQ-11 Issues Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: March 11, 2003 Reference: Document: NASREQ-11 Comment type: Technical Priority: S Section: Various Rationale/Explanation of issue: Section 1 " This document describes Diameter applications that are used for AAA in the Network Access Server (NAS) environment." Doesn't the document just describe a single application? Suggested change: "This document describes the Diameter NAS application, which, when combined...." Section 1.2 "1.2. Advertising Application Support Diameter nodes conforming to this specification MAY advertise support by including the value of one (1) in the Auth-Application-Id or the Acct-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands [Base]." Isn't advertisement mandatory? Shouldn't the MAY be a MUST? Section 2 " Unlike the RADIUS protocol [RADIUS], the Diameter protocol does not require authentication information to be contained in a request from the client. Therefore, it is possible to send a request for authorization only. The type of service depends upon the Auth- Request-Type AVP. This difference MAY cause operational issues in environments that need RADIUS interoperability, and it MAY be necessary that protocol conversion gateways add authentication information when transmitting to a RADIUS server." The RADIUS protocol doesn't require authentication information to be included in a Call-Check, so this isn't accurate. The use of a capital MAY is inappropriate. Adding authentication information in a gateway seems questionable security-wise. Rewrite to: "The Diameter protocol allows authorization-only requests depending on the Auth-Request-Type AVP, where no authentication information is contained in a request from the client. This capability goes beyond the Call Check capabilities described in Section 5.6 of [RADIUS] in that no access decision is requested. Since no equivalent capability exists in RADIUS, authorization-only requests from a NAS implementing Diameter may not be easily translated to an equivalent RADIUS message by a Diameter/RADIUS gateway. For example, where a Diameter authorization-only request cannot be translated to a RADIUS Call Check, it would be necessary for the Diameter/RADIUS gateway to add authentication information to the RADIUS Access Request. On receiving the Access-Reply, the Diameter/RADIUS gateway would need to discard the access decision (Accept/Reject). It is not clear that these translations can be accomplished without adding significant security vulnerabilities." Section 2.2 "A Diameter server informs the NAS of the maximum time allowed before re-authentication or re-authorization via the Authorization-Lifetime AVP [Base]. Note, however, that the Authorization-Lifetime AVP SHOULD NOT be used if the AAR message contained a NAS-IP-Address, NAS-IPv6-Address, or NAS- Identifier AVP since this would mean that the NAS is using RADIUS which does not support server-initiated re-authentication or re- authorization." The 2nd sentence is correct, but it doesn't follow from the first. The issue is not that the Diameter server informs the NAS of the maximum time allowed; after all, this is what RADIUS does. The issue is the ability to handle a server-initiated re-authentication or re-authorization. This paragraph confuses the two issues. Rewrite to: "A Diameter server informs the NAS of the maximum time allowed before re-authentication or re-authorization via the Authorization-Lifetime AVP [Base]. A NAS MUST re-authenticate and/or re-authorize after the period provided by the Authorization-Lifetime AVP. Furthermore, it is possible for Diameter servers to issue an unsolicited re-authentication and/or re-authorization requests (e.g. Re-Auth-Request (RAR) message) to the NAS. Upon receipt of such a message, the NAS issues a request to re-authenticate and/or re-authorize the client. Since RADIUS does not support server-initiated re-authentication or re-authorization, a Diameter server SHOULD NOT attempt server-initiated re-authentication or re-authorization for a session known to have been initiated by a RADIUS client. Such sessions are indicated by an AAR message containing a NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier AVP. In addition, the Authorization-Lifetime AVP SHOULD NOT be included in an AA-Answer message relating to such a session; instead the equivalent RADIUS attributes (e.g. Session-Timeout) SHOULD be used instead." Section 3.1 " It is possible for a single session to be authorized first, then followed by an authentication request." It would help to provide an example of when this would be desirable. Unfortunately, I can't think of any. The ABNF for AAR includes support for RADIUS attributes not allowable in an Access-Request, including Session-Timeout, Idle-Timeout, and Class. To avoid problems in translation, I'd avoid including these AVPs in the ABNF. The AAR ABNF also does not include the Proxy-State AVP, which is allowed in a RADIUS Access Request. This is because the Proxy-Info AVP takes its place, no? Section 3.2 The Proxy-State attribute is not listed in the ABNF for AA-Answer. I assume it is not supported because Proxy-Info AVP takes its place. Section 4 " AVPs new to Diameter have code values 256 and greater. A Diameter message that includes one of these AVPs MAY cause interoperability issues should the request traverse a AAA node that only supports the RADIUS protocol. However, the Diameter protocol should not be hampered from future developments due to the existing installed base." The MAY doesn't need to be capitalized here. Rewrite to: " AVPs new to Diameter have code values 256 and greater. Diameter messages including one or more of these AVPs may cause interoperability problems should the request traverse a AAA node that only supports RADIUS." One problem that arises here is that the Diameter NAS client can't know whether it is talking to a Diameter server or a Diameter/RADIUS gateway, since in either case, the NAS application is advertised. Were it to know that there was a Diameter/RADIUS gateway in the path, it might restrict itself to "RADIUS compatibility mode". Section 4.5 " The Called-Station-Id AVP (AVP Code 30) is of type UTF8String, and allows the NAS to send in the request, the ASCII string of the phone number that the user called, using Dialed Number Identification (DNIS) or a similar technology. Note that this may be different from the phone number the call comes in on. It SHOULD only be present in" The Called-Station-Id can also contain a MAC address, as in draft-congdon-radius-8021x-23.txt. To cover this and other cases I would change this to: "The Called-Station-Id AVP (AVP Code 30) is of type UTF8String, and allows the NAS to send in the request, the ASCII string describing the layer 2 address that the user contacted to. For dialup access, this can be a phone number, obtained using Dialed Number Identification (DNIS) or a similar technology. Note that this may be different from the phone number the call comes in on. For use with IEEE 802 access, the Called-Station-Id MAY contain a MAC address, formatted as described in [Congdon]." 4.6 " The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String, and allows the NAS to send in the request the the ASCII string of the phone number that the call came from, using Automatic Number Identification (ANI) or a similar technology. It SHOULD only be present in authentication and/or authorization requests. If the Auth-Request-Type AVP is set to authorization-only and the User-Name AVP is absent, the Diameter Server MAY perform authorization based on this field. This can be used by a NAS to request whether a call should be answered based on the ANI. " Change to: "The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String, and allows the NAS to send in the request the the ASCII string describing the layer 2 address that the user connected from. For dialup access, this is the phone number that the call came from, using Automatic Number Identification (ANI) or a similar technology. For use with IEEE 802 access, the Calling-Station-Id AVP MAY contain a MAC address, formated as described in [Congdon]. It SHOULD only be present in authentication and/or authorization requests. If the Auth-Request-Type AVP is set to authorization-only and the User-Name AVP is absent, the Diameter Server MAY perform authorization based on this field. This can be used by a NAS to request whether a call should be answered based on the layer 2 address (ANI, MAC Address, etc.)" 4.7 As described, the Connect-Info attribute is only useful for dialup. Change: " The Connect-Info AVP (AVP Code 77) is of type UTF8String and is sent in the AA-Request message, and indicates the nature of the user's connection. The connection speed SHOULD be included at the beginning of the first Connect-Info AVP in the message. If the transmit and receive connection speeds differ, they may both be included in the first AVP with the transmit speed first (the speed the NAS modem transmits at), a slash (/), the receive speed, then optionally other information. For example, "28800 V42BIS/LAPM" or "52000/31200 V90" " To: " The Connect-Info AVP (AVP Code 77) is of type UTF8String and is sent in the AA-Request or ACR STOP message. When sent in the Access-Request it indicates the nature of the user's connection. The connection speed SHOULD be included at the beginning of the first Connect-Info AVP in the message. If the transmit and receive connection speeds differ, they may both be included in the first AVP with the transmit speed first (the speed the NAS transmits at), a slash (/), the receive speed, then optionally other information. Examples: "28800 V42BIS/LAPM", "52000/31200 V90" or "11 Mbps 802.11b" If sent in the ACR STOP, this attribute may be used to summarize statistics relating to session quality. For example, in IEEE 802.11, the Connect-Info attribute may contain information on the number of link layer retransmissions. The exact format of this attribute is implementation specific." Section 4.l0 " When used by 802.1X supplicants, the service typically terminates due to the expiry of the Session-Timeout AVP. The access device may then reauthenticate the user with a new AA-Request. The RECOMMENDED way to do this in Diameter is to use the Authorization-Lifetime AVP rather than the Termination-Action AVP. However, the Termination- Action AVP MAY be used when copied from a RADIUS Access-Accept to a Diameter AA-Answer by a Translation Agent." This contradicts Section 2.2, which says that the Authorization-Lifetime AVP SHOULD NOT be used with RADIUS clients. The only alternative is to use Session-Timeout and Termination-Action, but that doesn't do the job, since the meaning has been changed. This leaves a Diameter server incapable of communicating that it would like a RADIUS client to re-authenticate at a given interval. The suggested fix is to change the meaning of Termination-Action so that it is compatible with RADIUS. Section 6.1 " The Service-Type AVP (AVP Code 6) is of type Enumerated and contains the type of service the user has requested, or the type of service to be provided. One such AVP MAY be present in an authentication and/or authorization request or response. A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though a response with a Result-Code other than Diameter-SUCCESS had been received instead." Is this the same as saying that the authentication failed? Note also that Service-Types 15 and 16 have recently been defined by IEEE 802.11f. Should these be included in the list? Section 8 "If Authentication and Authorization occur in seperate transactions, the first message should generate a START_RECORD, and the later, an INTERIM_RECORD." This assumes that service is begun once the authorization response is received, correct? I think you need to add Connect-Info to the list of Accounting AVPs. Section 9 Why does this section include a table with NAS-Identifier, NAS-IP-Address, NAS-IPv6-Address, etc.? This looks like it belonged somewhere else and ended up here by mistake. " Note that this section uses the two terms; AVP and attribute in a consise manner. The former is used to signify a Diameter AVP, while the latter is used to signify a RADIUS attribute." Do you mean "consistent manner"? Section 9.1 "Therefore, a RADIUS/Diameter Translation Agent SHOULD NOT assume to track session state information." I think you mean "SHOULD NOT be assumed", no? " - If a Message-Authenticator attribute is present, it MUST be checked and discarded. The gateway system SHOULD generate and include a Message-Authenticator in return responses to this system." I think you mean that it is checked, and if valid, then it is not included within the Diameter message; if invalid, then the packet is silently discarded. " - The Diameter Origin-Host and Origin-Realm AVPs MUST be created and added using the information from the NAS-Identifier attribute, and/or the FQDN corresponding to the NAS-IP-Address attribute. The AAA protocol specified in the identity would be set to "RADIUS"." I think that the FQDN corresponding to the NAS-IP-Address is preferred, if available. " - If the RADIUS message contains an address attribute, (e.g. Framed-IP-Address, Login-IP-Host, Login-IPv6-Host, NAS-IP- Address, NAS-IPv6-Address) it MUST be converted to the appropriate Diameter AVP and Address type." Didn't we dump the idea of address type? 9.1.1 " - The Origin-Host AVP's value is inserted in the NAS-Identifier attribute." How about also supporting translation of Origin-Host AVP to NAS-IP-Address or NAS-IPv6-Adddress? 9.4 "If this is not possible, an attribute error should be returned." Not sure which protocol this is referring to. RADIUS doesn't support error messages, and Diameter doesn't have attribute (only AVPs). 9.5.2 " The Diameter AVP will consist of the following fields; Diameter Flags: V=1, M=0, P=0 Diameter Vendor code = RADIUS VSA Vendor code Diameter AVP code = RADIUS VSA Vendor type code Diameter AVP length = length of AVP (header + data + padding) Diameter Data = RADIUS VSA vendor data If the RADIUS receiving code knows of vendor specific fields interpretations for the specific vendor, it may employ them to parse an extended AVP code or data length, Otherwise the recommended standard fields will be used. Nested Multiple vendor data fields MUST be expanded into multiple Diameter AVPs." Forwarding a RADIUS Vendor-Specific AVP as non-mandatory could be dangerous in some circumstances, such as when a proprietary Filter or key attribute is included. I'd suggest setting M=1 by default, unless more information is known. 13.1 "[AAATrans] B. Aboba, J. Wood. "Authentication, Authorization and Accounting (AAA) Transport Profile", draft-ietf-aaa- transport-08, IETF work in progress, April 2002" Latest version is -12. Additional comments I believe that it would be useful to talk about translation of unsolicited disconnect or change of filters messages to their RADIUS equivalents, defined in [DynAuth]. From owner-aaa-wg@merit.edu Wed Mar 12 16:31: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 QAA24021 for ; Wed, 12 Mar 2003 16:31:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EB18E9123E; Wed, 12 Mar 2003 16:33:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B8E5B9121F; Wed, 12 Mar 2003 16:33:08 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1D2089123E for ; Wed, 12 Mar 2003 16:33:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9AD995E485; Wed, 12 Mar 2003 16:31:26 -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 C50D15DEA0 for ; Wed, 12 Mar 2003 16:31:25 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2CKGPl04832 for ; Wed, 12 Mar 2003 12:16:25 -0800 Date: Wed, 12 Mar 2003 12:16:25 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 405: RADIUS compatibility Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 405: RADIUS compatibility Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: March 11, 2003 Reference: Document: NASREQ-11 Comment type: Technical Priority: S Section: 9 Rationale/Explanation of issue: As noted in Section 2.2, it is possible for a Diameter server to know that it is talking to a RADIUS client. This is indicated by an AAR message containing a NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier AVP. Given this, the Diameter can restrict itself to use of RADIUS compatible attributes and commands. I would suggest that a discussion of this issue be included in a separate sub-section of Section 9: "9.X.X RADIUS compatibility mode Since the NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier AVPs are not used by Diameter clients within AAR messages, the presence of these attribute indicates that the Request was originated by a RADIUS client and subsequently translated. A Diameter server receiving such a message SHOULD restrict itself to use of AVPs within the range 0-255, so as to ensure RADIUS backward compatibility. In addition, a Diameter server SHOULD NOT by default attempt server-initiated re-authentication or re-authorization for a session known to have been initiated by a RADIUS client. In addition, the Authorization-Lifetime AVP SHOULD NOT be included in an AA-Answer message relating to such a session; instead the equivalent RADIUS attributes (e.g. Session-Timeout and Termination-Action) SHOULD be used instead. Within Diameter these attributes have the same meaning as within RADIUS." From owner-aaa-wg@merit.edu Wed Mar 12 16:55:06 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 QAA24975 for ; Wed, 12 Mar 2003 16:55:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CD3FD91244; Wed, 12 Mar 2003 16:56:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92BF691247; Wed, 12 Mar 2003 16:56:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 90E2F91244 for ; Wed, 12 Mar 2003 16:56:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7F9CB5E304; Wed, 12 Mar 2003 16:56:50 -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 F3A5B5DD93 for ; Wed, 12 Mar 2003 16:56:49 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2CKfnC06159 for ; Wed, 12 Mar 2003 12:41:49 -0800 Date: Wed, 12 Mar 2003 12:41:49 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 406: Context removal Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 406: Context removal Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: March 11, 2003 Reference: Document: NASREQ-11 Comment type: Technical Priority: S Section: 2.3 Rationale/Explanation of issue: " Further, a NAS that receives a Abort-Session-Request (ASR) [Base] MUST issue an STR if the session requested is active, and disconnect the PPP (or tunneling) session. Termination of the session context, MUST cause the sending of an Accounting STOP_RECORD message [Base], if accounting is active. " What this doesn't say is that *all* context relating to the session MUST be removed, including key state. This is important in the case of access points which may cache the PMK. Note that termination of the session can occur without removing all session context. Rewrite to: " Further, a NAS that receives a Abort-Session-Request (ASR) [Base] MUST issue an STR if the session requested is active, disconnect the session and completely remove all session context. Termination of the session MUST cause the sending of an Accounting STOP_RECORD message [Base], if accounting is active. " From owner-aaa-wg@merit.edu Wed Mar 12 17:29:06 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 RAA25849 for ; Wed, 12 Mar 2003 17:29:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BADCD9135F; Wed, 12 Mar 2003 17:29:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7FB859124E; Wed, 12 Mar 2003 17:29:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 85CC59135F for ; Wed, 12 Mar 2003 17:28:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6A0905DFAE; Wed, 12 Mar 2003 17:28:14 -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 E166E5DF81 for ; Wed, 12 Mar 2003 17:28:13 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2CLDDr07900 for ; Wed, 12 Mar 2003 13:13:13 -0800 Date: Wed, 12 Mar 2003 13:13:13 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Preliminary AAA WG Agenda, IETF 56, Take 2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk AAA WG Agenda, IETF 56, San Francisco Chairs: Bernard Aboba David Mitton Wednesday, March 19, 2003 1300 - 1500 Afternoon Session I Preliminaries (10 minutes) Bluesheets Minute Takers Agenda Bashing Document status Diameter NASREQ, David Mitton (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-11.txt Diameter Credit Control Application, Harri Hakala (10 minutes) http://www.ietf.org/internet-drafts/draft-hakala-diameter-credit-control-06.txt Credit Control and Prepaid Applications, Avi Lior (10 minutes) http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-00.txt Diameter Multimedia Application, Maria-Carmen Belinchon (10 minutes) http://www.ietf.org/internet-drafts/draft-belinchon-aaa-diameter-mm-app-00.txt Diameter APIs, Yoshihiro Obha and James Kempf (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-api-03.txt http://www.ietf.org/internet-drafts/draft-ohba-aaa-diameter-cxxapi-00.txt Diameter Mobile IPv4, Tony Johansson (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-13.txt Diameter CMS, Stephen Farrell (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-04.txt Issues in AAA Key Distribution (20 minutes), Russ Housley & Steve Bellovin http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt From owner-aaa-wg@merit.edu Wed Mar 12 23:43: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 XAA07778 for ; Wed, 12 Mar 2003 23:43:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D576591356; Wed, 12 Mar 2003 23:44:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 812FB91359; Wed, 12 Mar 2003 23:44: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 C23D991356 for ; Wed, 12 Mar 2003 23:44:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id A7C3C5E03D; Wed, 12 Mar 2003 23:44:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id D66615DFFF for ; Wed, 12 Mar 2003 23:44:52 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2D4mKF22186 for ; Thu, 13 Mar 2003 06:48:20 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 06:44:51 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 06:44:50 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 06:44:50 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 06:44:50 +0200 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]: Issue 405: RADIUS compatibility Date: Thu, 13 Mar 2003 06:44:48 +0200 Message-ID: Thread-Topic: [AAA-WG]: Issue 405: RADIUS compatibility Thread-Index: AcLo3wZ/wMsnTj+oSiSP/4TdN4fc+wAPDVgg From: To: , X-OriginalArrivalTime: 13 Mar 2003 04:44:50.0117 (UTC) FILETIME=[48006750:01C2E91B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA07778 I support this. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 12 March, 2003 22:16 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 405: RADIUS compatibility > > > Issue 405: RADIUS compatibility > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: March 11, 2003 > Reference: > Document: NASREQ-11 > Comment type: Technical > Priority: S > Section: 9 > Rationale/Explanation of issue: > As noted in Section 2.2, it is possible for a Diameter server to > know that it is talking to a RADIUS client. This is indicated > by an AAR message containing a NAS-IP-Address, NAS-IPv6-Address > or NAS-Identifier AVP. > > Given this, the Diameter can restrict itself to use of RADIUS > compatible attributes and commands. I would suggest that a > discussion of > this > issue be included in a separate sub-section of Section 9: > > "9.X.X RADIUS compatibility mode > > Since the NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier AVPs > are not used by Diameter clients within AAR messages, the presence > of these attribute indicates that the Request was originated > by a RADIUS client and subsequently translated. > > A Diameter server receiving such a message SHOULD restrict itself > to use of AVPs within the range 0-255, so as to ensure RADIUS > backward compatibility. In addition, a Diameter server SHOULD NOT > by default attempt server-initiated re-authentication or > re-authorization > for a session known to have been initiated by a RADIUS client. > > In addition, the Authorization-Lifetime AVP SHOULD > NOT be included in an AA-Answer message relating to such a session; > instead the equivalent RADIUS attributes (e.g. Session-Timeout and > Termination-Action) SHOULD be used instead. Within Diameter these > attributes have the same meaning as within RADIUS." > > > From owner-aaa-wg@merit.edu Wed Mar 12 23:46:26 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07871 for ; Wed, 12 Mar 2003 23:46:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D882A91377; Wed, 12 Mar 2003 23:47:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA0EC9137A; Wed, 12 Mar 2003 23:47:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9DE7291365 for ; Wed, 12 Mar 2003 23:45:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 02FA55E069; Wed, 12 Mar 2003 23:45:28 -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 C02105DE4E for ; Wed, 12 Mar 2003 23:45:25 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2D4i2123566 for ; Thu, 13 Mar 2003 06:44:02 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 06:45:24 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 06:45:23 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 06:45:22 +0200 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]: Issue 406: Context removal Date: Thu, 13 Mar 2003 06:45:22 +0200 Message-ID: Thread-Topic: [AAA-WG]: Issue 406: Context removal Thread-Index: AcLo4lgPJFpKL81zTrG8azz3eNAv4gAOQAkg From: To: , X-OriginalArrivalTime: 13 Mar 2003 04:45:22.0789 (UTC) FILETIME=[5B79C150:01C2E91B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA07871 I agree. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 12 March, 2003 22:42 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 406: Context removal > > > Issue 406: Context removal > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: March 11, 2003 > Reference: > Document: NASREQ-11 > Comment type: Technical > Priority: S > Section: 2.3 > Rationale/Explanation of issue: > " Further, a NAS that receives a Abort-Session-Request (ASR) [Base] > MUST issue an STR if the session requested is active, and > disconnect > the PPP (or tunneling) session. > > Termination of the session context, MUST cause the sending of an > Accounting STOP_RECORD message [Base], if accounting is active. > " > What this doesn't say is that *all* context relating to the session > MUST be removed, including key state. This is important in the case > of access points which may cache the PMK. Note that termination > of the session can occur without removing all session context. > > Rewrite to: > > " Further, a NAS that receives a Abort-Session-Request (ASR) [Base] > MUST issue an STR if the session requested is active, disconnect > the session and completely remove all session context. > > Termination of the session MUST cause the sending of an > Accounting STOP_RECORD message [Base], if accounting is active. > " > > > From owner-aaa-wg@merit.edu Thu Mar 13 01:52: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 BAA10564 for ; Thu, 13 Mar 2003 01:52:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9A91891264; Thu, 13 Mar 2003 01:54:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6A48A91267; Thu, 13 Mar 2003 01:54:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 39ADA91264 for ; Thu, 13 Mar 2003 01:54:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 292FD5E0A7; Thu, 13 Mar 2003 01:54:05 -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 7FEBA5E09C for ; Thu, 13 Mar 2003 01:54:04 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2D5cwa03077; Wed, 12 Mar 2003 21:38:58 -0800 Date: Wed, 12 Mar 2003 21:38:58 -0800 (PST) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 405: RADIUS compatibility In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk It also occurred to me that it would be worthwhile to talk about the case where a Diameter NAS is talking to a RADIUS server. Here the dynamic is a bit different, because the Diameter NAS may not know it is talking to a RADIUS server, and the RADIUS server may not know it is talking to a Diameter NAS. However, the first time that the Diameter NAS includes an attribute >255, or uses a Diameter-only capability, it will presumably get back an error message from the Diameter/RADIUS gateway saying "RADIUS compatiblity mode required." At that point, the Diameter NAS should limit its dialect to RADIUS compatibility mode. Given that the RADIUS/Diameter gateway is a NASREQ function, I expected to find some discussion of gateway error messages in the document, but in searching through it, there is really no discussion of the Error-Message AVP usage within this application. It is not entirely clear to me that the DIAMETER_AVP_UNSUPPORTED or DIAMETER_AVP_NOT_ALLOWED messages are appropriate for a case where an AVP is >255 and therefore cannot be translated. Perhaps we need a DIAMETER_AVP_UNTRANSLATABLE error message? Similarly, DIAMETER_COMMAND_UNSUPPORTED doesn't seem like the right error message for the case where a command can't be translated (e.g. unsolicited Diameter disconnect reaching a gateway that doesn't support [DynAuth]). Perhaps a DIAMETER_COMMAND_UNTRANSLATABLE is needed? > > > -----Original Message----- > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > Sent: 12 March, 2003 22:16 > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: Issue 405: RADIUS compatibility > > > > > > Issue 405: RADIUS compatibility > > Submitter name: Bernard Aboba > > Submitter email address: aboba@internaut.com > > Date first submitted: March 11, 2003 > > Reference: > > Document: NASREQ-11 > > Comment type: Technical > > Priority: S > > Section: 9 > > Rationale/Explanation of issue: > > As noted in Section 2.2, it is possible for a Diameter server to > > know that it is talking to a RADIUS client. This is indicated > > by an AAR message containing a NAS-IP-Address, NAS-IPv6-Address > > or NAS-Identifier AVP. > > > > Given this, the Diameter can restrict itself to use of RADIUS > > compatible attributes and commands. I would suggest that a > > discussion of > > this > > issue be included in a separate sub-section of Section 9: > > > > "9.X.X RADIUS compatibility mode > > > > Since the NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier AVPs > > are not used by Diameter clients within AAR messages, the presence > > of these attribute indicates that the Request was originated > > by a RADIUS client and subsequently translated. > > > > A Diameter server receiving such a message SHOULD restrict itself > > to use of AVPs within the range 0-255, so as to ensure RADIUS > > backward compatibility. In addition, a Diameter server SHOULD NOT > > by default attempt server-initiated re-authentication or > > re-authorization > > for a session known to have been initiated by a RADIUS client. > > > > In addition, the Authorization-Lifetime AVP SHOULD > > NOT be included in an AA-Answer message relating to such a session; > > instead the equivalent RADIUS attributes (e.g. Session-Timeout and > > Termination-Action) SHOULD be used instead. Within Diameter these > > attributes have the same meaning as within RADIUS." > > > > > > > From owner-aaa-wg@merit.edu Thu Mar 13 06:32:34 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27036 for ; Thu, 13 Mar 2003 06:32:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7408391361; Thu, 13 Mar 2003 06:31:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 373CC91364; Thu, 13 Mar 2003 06:30:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8D74391361 for ; Thu, 13 Mar 2003 06:30:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1A6325E4A4; Thu, 13 Mar 2003 06:30:23 -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 452C35E0F0 for ; Thu, 13 Mar 2003 06:30:22 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3E25F6A902; Thu, 13 Mar 2003 13:30:20 +0200 (EET) Message-ID: <3E706B9B.4010507@kolumbus.fi> Date: Thu, 13 Mar 2003 13:29:31 +0200 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: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 405: RADIUS compatibility 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 Works for me. --Jari From owner-aaa-wg@merit.edu Thu Mar 13 06:33:59 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 GAA27063 for ; Thu, 13 Mar 2003 06:33:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 494D991373; Thu, 13 Mar 2003 06:35:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6265B9136B; Thu, 13 Mar 2003 06:35:47 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E0E739136D for ; Thu, 13 Mar 2003 06:35:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 19D625E4B5; Thu, 13 Mar 2003 06:34:10 -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 CA8F95E0D8 for ; Thu, 13 Mar 2003 06:34:09 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id ED4E66A902; Thu, 13 Mar 2003 13:34:08 +0200 (EET) Message-ID: <3E706C80.7060400@kolumbus.fi> Date: Thu, 13 Mar 2003 13:33:20 +0200 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: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 406: Context removal 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 Ok, but a nit inline. Bernard Aboba wrote: > Issue 406: Context removal > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: March 11, 2003 > Reference: > Document: NASREQ-11 > Comment type: Technical > Priority: S > Section: 2.3 > Rationale/Explanation of issue: > " Further, a NAS that receives a Abort-Session-Request (ASR) [Base] > MUST issue an STR if the session requested is active, and disconnect > the PPP (or tunneling) session. > > Termination of the session context, MUST cause the sending of an > Accounting STOP_RECORD message [Base], if accounting is active. > " > What this doesn't say is that *all* context relating to the session > MUST be removed, including key state. This is important in the case > of access points which may cache the PMK. Note that termination > of the session can occur without removing all session context. > > Rewrite to: > > " Further, a NAS that receives a Abort-Session-Request (ASR) [Base] > MUST issue an STR if the session requested is active, disconnect > the session and completely remove all session context. Completely remove all? I guess you want to be really sure... Maybe s/and completely remove all session context/and remove all context associated with the session/ > Termination of the session MUST cause the sending of an > Accounting STOP_RECORD message [Base], if accounting is active. > " Ok --Jari From owner-aaa-wg@merit.edu Thu Mar 13 07:44:29 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 HAA28486 for ; Thu, 13 Mar 2003 07:44:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4D33191369; Thu, 13 Mar 2003 07:46:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 939CE91368; Thu, 13 Mar 2003 07:46: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 4E3CB91366 for ; Thu, 13 Mar 2003 07:46:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8E66B5E0FC; Thu, 13 Mar 2003 07:45:56 -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 0DBDB5E0F9 for ; Thu, 13 Mar 2003 07:45:56 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 7EEC46A902; Thu, 13 Mar 2003 14:45:53 +0200 (EET) Message-ID: <3E707D51.7050304@kolumbus.fi> Date: Thu, 13 Mar 2003 14:45:05 +0200 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: Bernard Aboba Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 405: RADIUS compatibility 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 Bernard Aboba wrote: > It also occurred to me that it would be worthwhile to talk about the case > where a Diameter NAS is talking to a RADIUS server. Here the dynamic is a > bit different, because the Diameter NAS may not know it is talking to a > RADIUS server, and the RADIUS server may not know it is talking to a > Diameter NAS. > > However, the first time that the Diameter NAS includes an attribute >255, > or uses a Diameter-only capability, it will presumably get back an error > message from the Diameter/RADIUS gateway saying "RADIUS compatiblity mode > required." At that point, the Diameter NAS should limit its dialect to > RADIUS compatibility mode. Sounds good. > Given that the RADIUS/Diameter gateway is a NASREQ function, I expected to > find some discussion of gateway error messages in the document, but in > searching through it, there is really no discussion of the Error-Message > AVP usage within this application. > > It is not entirely clear to me that the DIAMETER_AVP_UNSUPPORTED or > DIAMETER_AVP_NOT_ALLOWED messages are appropriate for a case where an AVP > is >255 and therefore cannot be translated. Perhaps we need a > DIAMETER_AVP_UNTRANSLATABLE error message? Yes. Can we add one in the NASREQ document, or should it have been in the base? > Similarly, DIAMETER_COMMAND_UNSUPPORTED doesn't seem like the right error > message for the case where a command can't be translated (e.g. unsolicited > Diameter disconnect reaching a gateway that doesn't support [DynAuth]). > Perhaps a DIAMETER_COMMAND_UNTRANSLATABLE is needed? I'd use that, yes. Jari From owner-aaa-wg@merit.edu Thu Mar 13 08:33:03 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29938 for ; Thu, 13 Mar 2003 08:33:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DBA0E9136D; Thu, 13 Mar 2003 08:34:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67AD59136F; Thu, 13 Mar 2003 08:34:41 -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 052B99136D for ; Thu, 13 Mar 2003 08:34:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id A32BB5E12A; Thu, 13 Mar 2003 08:33:40 -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 33B545E103 for ; Thu, 13 Mar 2003 08:33:40 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2DCIWQ25767; Thu, 13 Mar 2003 04:18:32 -0800 Date: Thu, 13 Mar 2003 04:18:32 -0800 (PST) From: Bernard Aboba To: Jari Arkko Cc: john.loughney@nokia.com, Subject: Re: [AAA-WG]: Issue 405: RADIUS compatibility In-Reply-To: <3E707D51.7050304@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Yes. Can we add one in the NASREQ document, or should it have > been in the base? It's unique to a RADIUS/Diameter gateway, which I gather is something that is part of the NAS application and its decendants (EAP too, I guess). So one could make an argument that it is not needed for *all* Diameter applications and so needn't be part of Base. From owner-aaa-wg@merit.edu Thu Mar 13 08:33:04 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29952 for ; Thu, 13 Mar 2003 08:33:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1A51191367; Thu, 13 Mar 2003 08:33:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60BF99136E; Thu, 13 Mar 2003 08:33: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 32B3B91367 for ; Thu, 13 Mar 2003 08:33:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 20FD25E12A; Thu, 13 Mar 2003 08:31:51 -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 668595E126 for ; Thu, 13 Mar 2003 08:31:50 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2DCGiq25690; Thu, 13 Mar 2003 04:16:44 -0800 Date: Thu, 13 Mar 2003 04:16:44 -0800 (PST) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 406: Context removal In-Reply-To: <3E706C80.7060400@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Maybe s/and completely remove all session context/and remove all > context associated with the session/ Yes. You don't need to remove *all* the context for all sessions :) > > > Termination of the session MUST cause the sending of an Accounting > > STOP_RECORD message [Base], if accounting is active. " > > Ok > > --Jari > > From owner-aaa-wg@merit.edu Thu Mar 13 08:41:18 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 IAA00148 for ; Thu, 13 Mar 2003 08:41:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 311C39136E; Thu, 13 Mar 2003 08:43:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA8A39136F; Thu, 13 Mar 2003 08:43:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D94519136E for ; Thu, 13 Mar 2003 08:43:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id C1FDC5E0E4; Thu, 13 Mar 2003 08:43:10 -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 3E3405E0CC for ; Thu, 13 Mar 2003 08:43:10 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2DCS6K26237 for ; Thu, 13 Mar 2003 04:28:06 -0800 Date: Thu, 13 Mar 2003 04:28:06 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Preliminary AAA WG Agenda, IETF 56, Take 3 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk AAA WG Agenda, IETF 56, San Francisco Chairs: Bernard Aboba David Mitton Wednesday, March 19, 2003 1300 - 1500 Afternoon Session I Preliminaries (10 minutes) Bluesheets Minute Takers Agenda Bashing Document status Diameter NASREQ, David Mitton (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-11.txt Diameter Credit Control Application, Harri Hakala (10 minutes) http://www.ietf.org/internet-drafts/draft-hakala-diameter-credit-control-06.txt Credit Control and Prepaid Applications, Avi Lior (10 minutes) http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-00.txt Diameter Multimedia Application, Miguel Garcia (10 minutes) http://www.ietf.org/internet-drafts/draft-belinchon-aaa-diameter-mm-app-00.txt Diameter Session Mobility, Dan Forsberg (10 minutes) http://www.ietf.org/internet-drafts/draft-liu-aaa-diameter-session-mobility-00.txt Diameter APIs, Yoshihiro Obha and James Kempf (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-api-03.txt http://www.ietf.org/internet-drafts/draft-ohba-aaa-diameter-cxxapi-00.txt Diameter Mobile IPv4, Tony Johansson (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-13.txt Diameter CMS, Stephen Farrell (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-04.txt Issues in AAA Key Distribution (20 minutes), Russ Housley & Steve Bellovin http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt From owner-aaa-wg@merit.edu Thu Mar 13 08:55:19 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00490 for ; Thu, 13 Mar 2003 08:55:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A74FE9136B; Thu, 13 Mar 2003 08:57:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7871D9136F; Thu, 13 Mar 2003 08:57:14 -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 6F0749136B for ; Thu, 13 Mar 2003 08:57:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 44BC85E103; Thu, 13 Mar 2003 08:57:13 -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 AFB805E0E4 for ; Thu, 13 Mar 2003 08:57:12 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2DCg3A27013; Thu, 13 Mar 2003 04:42:04 -0800 Date: Thu, 13 Mar 2003 04:42:03 -0800 (PST) From: Bernard Aboba To: Jari Arkko Cc: john.loughney@nokia.com, Subject: Re: [AAA-WG]: Issue 405: RADIUS compatibility In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk OK. Here is my revised text, taking the error messages into account: "9.X.X RADIUS compatibility mode Since the NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier AVPs are not used by Diameter clients within AAR messages, the presence of these attributes indicates that the Request was originated by a RADIUS client and subsequently translated. A Diameter server receiving such a message SHOULD restrict itself to use of AVPs within the range 0-255, so as to ensure RADIUS backward compatibility. In addition, the Authorization-Lifetime AVP SHOULD NOT be included in an AA-Answer message relating to such a session; instead the equivalent RADIUS attributes (e.g. Session-Timeout and Termination-Action) SHOULD be used instead. Within Diameter these attributes have the same meaning as within RADIUS. When a Diameter/RADIUS gateway encounters an untranslatable AVP, it will return a DIAMETER_AVP_UNTRANSLATABLE value in the Error-Message AVP. A Diameter NAS encountering this error SHOULD restrict itself to use of AVPs with the range 0-255 so as to ensure RADIUS backward compatibility. Similarly, when a Diameter/RADIUS gateway encounters an untranslatable command, it will return a DIAMETER_COMMAND_UNTRANSLATABLE value in the Error-Message AVP. A Diameter NAS encountering this error SHOULD restrict use of the offending command, so as to ensure RADIUS backward compatibility. Since RADIUS does not support server-initiated re-authentication and implementations may not support server-initiated re-authorization [DynAuth], a Diameter server SHOULD NOT attempt server-initiated re-authentication for a session known to be initiated by a RADIUS client. A Diameter server MAY attempt server-initiated re-authorization or session termination for a session known to be initiated by a RADIUS client. However, it will typically receive a DIAMETER_COMMAND_UNTRANSLATABLE error message in response. A Diameter server encountering this error SHOULD NOT continue to attempt server-initiated re-authorization or session-termination for that NAS. " From owner-aaa-wg@merit.edu Thu Mar 13 16:47:53 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 QAA20595 for ; Thu, 13 Mar 2003 16:47:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0A35E9126A; Thu, 13 Mar 2003 16:48:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 418239121E; Thu, 13 Mar 2003 16:48:52 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F306E9126A for ; Thu, 13 Mar 2003 16:48:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B9535E165; Thu, 13 Mar 2003 16:46:56 -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 AEB355E164 for ; Thu, 13 Mar 2003 16:46:55 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 42BD76A902; Thu, 13 Mar 2003 23:46:54 +0200 (EET) Message-ID: <3E70FC1D.9000403@kolumbus.fi> Date: Thu, 13 Mar 2003 23:46:05 +0200 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: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 405: RADIUS compatibility 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 Ok. And we need a section defining the new error codes. Jari Bernard Aboba wrote: > OK. Here is my revised text, taking the error messages into account: > > "9.X.X RADIUS compatibility mode > > Since the NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier AVPs > are not used by Diameter clients within AAR messages, the presence > of these attributes indicates that the Request was originated > by a RADIUS client and subsequently translated. > > A Diameter server receiving such a message SHOULD restrict itself > to use of AVPs within the range 0-255, so as to ensure RADIUS > backward compatibility. > > In addition, the Authorization-Lifetime AVP SHOULD > NOT be included in an AA-Answer message relating to such a session; > instead the equivalent RADIUS attributes (e.g. Session-Timeout and > Termination-Action) SHOULD be used instead. Within Diameter these > attributes have the same meaning as within RADIUS. > > When a Diameter/RADIUS gateway > encounters an untranslatable AVP, it will > return a DIAMETER_AVP_UNTRANSLATABLE value in the > Error-Message AVP. A Diameter NAS encountering > this error SHOULD restrict itself to use of AVPs > with the range 0-255 so as to ensure RADIUS backward > compatibility. > > Similarly, when a Diameter/RADIUS > gateway encounters an untranslatable command, it will > return a DIAMETER_COMMAND_UNTRANSLATABLE value in > the Error-Message AVP. A Diameter NAS encountering > this error SHOULD restrict use of the offending > command, so as to ensure RADIUS backward compatibility. > > Since RADIUS does not support server-initiated re-authentication > and implementations may not support server-initiated re-authorization > [DynAuth], a Diameter server SHOULD NOT attempt server-initiated > re-authentication for a session known to be initiated by a RADIUS > client. A Diameter server MAY attempt server-initiated re-authorization > or session termination for a session known to be initiated by a > RADIUS client. However, it will typically receive a > DIAMETER_COMMAND_UNTRANSLATABLE error message in response. > A Diameter server encountering this error SHOULD NOT continue > to attempt server-initiated re-authorization or session-termination > for that NAS. " > > From owner-aaa-wg@merit.edu Mon Mar 17 14:31:29 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 OAA26377 for ; Mon, 17 Mar 2003 14:31:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DF0A991210; Mon, 17 Mar 2003 14:31:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 43FCA9125F; Mon, 17 Mar 2003 14:31: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 9B3A091210 for ; Mon, 17 Mar 2003 14:31:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 118125DF20; Mon, 17 Mar 2003 14:31:01 -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 5A94E5DE6D for ; Mon, 17 Mar 2003 14:31:00 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2HIFWQ09347 for ; Mon, 17 Mar 2003 10:15:32 -0800 Date: Mon, 17 Mar 2003 10:15:32 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Alcatel patent (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id OAA26377 FYI. The IETF Secretariat has been notified of this potential claim, and has sent a request for further clarification. -----Original Message----- From: Tony Jeffree [mailto:tony@jeffree.co.uk] Sent: Mon 2/3/2003 12:27 PM To: stds-802-1@ieee.org Subject: [802.1] Alcatel patent   I have received a response from Alcatel to my request that they file a Letter of Assurance with the IEEE. A copy of their letter is now held on file by the IEEE Patents Committee. I have posted a PDF of their letter at: http://www.ieee802.org/1/files/public/docs2003/alcatel-letter.pdf Regards, Tony From owner-aaa-wg@merit.edu Wed Mar 19 08:09: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 IAA20227 for ; Wed, 19 Mar 2003 08:09:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 931269123B; Wed, 19 Mar 2003 08:11:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 43CE69125A; Wed, 19 Mar 2003 08:11:01 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9638F9123B for ; Wed, 19 Mar 2003 08:11:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6C2B05E0B8; Wed, 19 Mar 2003 08:11:00 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 239345DDEB for ; Wed, 19 Mar 2003 08:11:00 -0500 (EST) Received: (qmail 9159 invoked by uid 500); 19 Mar 2003 13:10:59 -0000 Date: Wed, 19 Mar 2003 07:10:59 -0600 From: David Frascone To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter API Draft(s) Message-ID: <20030319131059.GB8870@wolverine> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: owner-aaa-wg@merit.edu Precedence: bulk Yoshihiro Ohba , has been working hard on a C++ API to compliment the existing C one (draft-ietf-aaa-diameter-api-03.txt). I think that the C++ API should also be published as a WG document, or included within the existing api draft. Yoshihiro was planning on discussing this at the meeting today, but has been called home early. Please discuss this in the meeting today, or via e-mail and let us know what the WG thinks! Later, -Dave -- David Frascone Everyone's expendable...and no one has a real friend From owner-aaa-wg@merit.edu Wed Mar 19 10:12: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 KAA22896 for ; Wed, 19 Mar 2003 10:11:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C822091231; Wed, 19 Mar 2003 10:14:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93E7B9125D; Wed, 19 Mar 2003 10:14:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 40AE891231 for ; Wed, 19 Mar 2003 10:13:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 228D75E126; Wed, 19 Mar 2003 10:13:59 -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 A0A7B5DDA4 for ; Wed, 19 Mar 2003 10:13:58 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2JDvxU24393; Wed, 19 Mar 2003 05:58:14 -0800 Date: Wed, 19 Mar 2003 05:57:59 -0800 (PST) From: Bernard Aboba To: David Frascone Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter API Draft(s) In-Reply-To: <20030319131059.GB8870@wolverine> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Is anyone available to present the drafts? On Wed, 19 Mar 2003, David Frascone wrote: > Yoshihiro Ohba , has been working hard on a C++ > API to compliment the existing C one > (draft-ietf-aaa-diameter-api-03.txt). > > I think that the C++ API should also be published as a WG document, or > included within the existing api draft. > > Yoshihiro was planning on discussing this at the meeting today, but has > been called home early. > > Please discuss this in the meeting today, or via e-mail and let us know > what the WG thinks! > > Later, > > -Dave > > -- > David Frascone > > Everyone's expendable...and no one has a real friend > From owner-aaa-wg@merit.edu Fri Mar 21 11:58:07 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18758 for ; Fri, 21 Mar 2003 11:58:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 25863912A3; Fri, 21 Mar 2003 11:57:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB042912A4; Fri, 21 Mar 2003 11:57:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ECDB5912A3 for ; Fri, 21 Mar 2003 11:57:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id D2B2F5E08A; Fri, 21 Mar 2003 11:57:51 -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 6889C5E06C for ; Fri, 21 Mar 2003 11:57:51 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2LFg2j28436 for ; Fri, 21 Mar 2003 07:42:02 -0800 Date: Fri, 21 Mar 2003 07:42:02 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG minutes and presentations Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk If you took minutes at the IETF 56 AAA WG meeting, please send them to the chairs. Presentations are available at: http://www.drizzle.com/~aboba/IETF56/AAA/ If your presentation isn't available there, please email it to the chairs. From owner-aaa-wg@merit.edu Mon Mar 24 11:12: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 LAA24361 for ; Mon, 24 Mar 2003 11:12:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C684191233; Mon, 24 Mar 2003 11:14:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 945A291234; Mon, 24 Mar 2003 11:14:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ACAD891233 for ; Mon, 24 Mar 2003 11:14:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 944275DFC5; Mon, 24 Mar 2003 11:14:35 -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 A96255DFC2 for ; Mon, 24 Mar 2003 11:14:30 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2OEwK407892 for ; Mon, 24 Mar 2003 06:58:25 -0800 Date: Mon, 24 Mar 2003 06:58:20 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Presentations from AAA WG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The presentations made at the AAA WG meeting at IETF56 are available at: http://www.drizzle.com/~aboba/IETF56/ietf56-aaa.zip From owner-aaa-wg@merit.edu Tue Mar 25 14:00:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25546 for ; Tue, 25 Mar 2003 14:00:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C2C8091269; Tue, 25 Mar 2003 14:02:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F35EB9126A; Tue, 25 Mar 2003 14:01:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A73B691269 for ; Tue, 25 Mar 2003 14:01:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id E21E05E103; Tue, 25 Mar 2003 14:01:40 -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 74C845E101 for ; Tue, 25 Mar 2003 14:01:40 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2PHjTE24184 for ; Tue, 25 Mar 2003 09:45:29 -0800 Date: Tue, 25 Mar 2003 09:45:29 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Strawman minutes from IETF 56 AAA WG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk http://www.drizzle.com/~aboba/IETF56/AAA/aaa-ietf56-minutes.txt From owner-aaa-wg@merit.edu Tue Mar 25 19:09:58 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 TAA12423 for ; Tue, 25 Mar 2003 19:09:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B0B7B9126A; Tue, 25 Mar 2003 19:12:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8060791274; Tue, 25 Mar 2003 19:12:04 -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 4BCB59126A for ; Tue, 25 Mar 2003 19:12:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A9175E179; Tue, 25 Mar 2003 19:12:03 -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 D68A05E178 for ; Tue, 25 Mar 2003 19:12:02 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2Q0C0c20235 for ; Tue, 25 Mar 2003 18:12:00 -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 HNP4MJ0Z; Tue, 25 Mar 2003 18:12:01 -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 GSPRQHCL; Tue, 25 Mar 2003 18:12:00 -0600 Message-ID: <3E80F042.2050907@iqmail.net> Date: Tue, 25 Mar 2003 18:11:46 -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: aaa-wg@merit.edu Subject: [AAA-WG]: comment on diameter credit control 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 Question/Comment on: draft-hakala-diameter-credit-control-06.txt " Credit Control Server It is located in the home environment and is accessed by service elements in real-time for purpose of price determination and credit control before the service event is delivered to the end-user. It may also interact with business support systems. " Q1. What is a "home environment"? I guess it should be home network. Q2. Why are we precluding the Credit Control Server hosted by a third party i.e. neither visited nor home network provider? -Kuntal From owner-aaa-wg@merit.edu Wed Mar 26 05:39:06 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 FAA20587 for ; Wed, 26 Mar 2003 05:39:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B2C449127C; Wed, 26 Mar 2003 05:41:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C6519127D; Wed, 26 Mar 2003 05:41: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 2F63F9127C for ; Wed, 26 Mar 2003 05:41:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 09F005E19A; Wed, 26 Mar 2003 05:41:11 -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 8357D5DDAD for ; Wed, 26 Mar 2003 05:41:09 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2QAiuX10171 for ; Wed, 26 Mar 2003 12:44:56 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Mar 2003 12:41:05 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Mar 2003 12:41:03 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [AAA-WG]: comment on diameter credit control Date: Wed, 26 Mar 2003 12:41:02 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E4537@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: comment on diameter credit control Thread-Index: AcLzMfv2ru0b6ZS8Sjmr2gaf/5vgXwATNksM From: To: , X-OriginalArrivalTime: 26 Mar 2003 10:41:03.0361 (UTC) FILETIME=[32D15F10:01C2F384] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id FAA20587 Hi, >Q1. What is a "home environment"? I guess it should be home network. Yes, the home environment is the home network. Q2. Why are we precluding the Credit Control Server hosted by a third party i.e. neither visited nor home network provider? The Credit Control Server is located in the same network that own the user's account, which is usually the home network. The visited network may proxy the service element requests related to a visited user to the user's home network, thus a Credit Control Proxy may be located in the visited domain. Perhaps the Credit Control Server may be hosted by third party entity trusted by the home network, in cases where a third party provider offers credit control services on behalf of the home network (home network provider). In this case the home network would forward the request to the trusted entity providing credit control services, however, the third party provider may be considered as an extention of the home network, thus belonging to the "home environment". Would we need some sentence explicitly covering this scenario or do you have something else in mind? Regards Marco -----Original Message----- From: ext Kuntal Chowdhury [mailto:kuntal@iqmail.net] Sent: Wed 3/26/2003 2:11 AM To: aaa-wg@merit.edu Cc: Subject: [AAA-WG]: comment on diameter credit control Question/Comment on: draft-hakala-diameter-credit-control-06.txt " Credit Control Server It is located in the home environment and is accessed by service elements in real-time for purpose of price determination and credit control before the service event is delivered to the end-user. It may also interact with business support systems. " Q1. What is a "home environment"? I guess it should be home network. Q2. Why are we precluding the Credit Control Server hosted by a third party i.e. neither visited nor home network provider? -Kuntal From owner-aaa-wg@merit.edu Wed Mar 26 15:07:29 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 PAA11002 for ; Wed, 26 Mar 2003 15:07:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E3FD19129A; Wed, 26 Mar 2003 15:08:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB3999129B; Wed, 26 Mar 2003 15:08:58 -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 749C19129A for ; Wed, 26 Mar 2003 15:08:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 630AD5E23C; Wed, 26 Mar 2003 15:08:57 -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 190A85E210 for ; Wed, 26 Mar 2003 15:08:57 -0500 (EST) Received: from zrc2c001.us.nortel.com (zrc2c001.us.nortel.com [47.103.121.31]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2QK8mE18056; Wed, 26 Mar 2003 14:08:52 -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 H2DNLXX4; Wed, 26 Mar 2003 14:08:48 -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 GSPRQHM7; Wed, 26 Mar 2003 14:08:49 -0600 Message-ID: <3E8208BF.5040001@iqmail.net> Date: Wed, 26 Mar 2003 14:08:31 -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: marco.stura@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: comment on diameter credit control References: <142DC466081D9B409AAD1DDCA4B21E1D9E4537@esebe016.ntc.nokia.com> 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 Marco, Please see my comments inline... marco.stura@nokia.com wrote: > Hi, > > >>Q1. What is a "home environment"? I guess it should be home network. > > Yes, the home environment is the home network. > OK, then why don't we say "home network" instead, if you don't mind :o)? > Q2. Why are we precluding the Credit Control Server hosted by a third party i.e. > neither visited nor home network provider? > The Credit Control Server is located in the same network that own the user's account, which is usually the home network. The visited network may proxy the service element requests related to a visited user to the user's home network, thus a Credit Control Proxy may be located in the visited domain. IMHO, that's how AAA system works i.e. the visited AAA routes AAA messages through proxy chain to the home AAA. > > Perhaps the Credit Control Server may be hosted by third party entity trusted by the home network, in cases where a third party provider offers credit control services on behalf of the home network (home network provider). In this case the home network would forward the request to the trusted entity providing credit control services, however, the third party provider may be considered as an extention of the home network, thus belonging to the "home environment". Would we need some sentence explicitly covering this scenario or do you have something else in mind? I did not know that you/authors assumed "home environment" may include third party (e.g. a prepaid reseller). In order to clarify the scenario why don't we say the following: " Credit Control Server: The home network interfaces with this entity and is accessed by the service elements for the purpose of allowed usage determination and credit control before the service event is delivered to the end-user. " Regards, KC From owner-aaa-wg@merit.edu Thu Mar 27 00:26:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03402 for ; Thu, 27 Mar 2003 00:26:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6B8E99121D; Thu, 27 Mar 2003 00:28:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 41837912AC; Thu, 27 Mar 2003 00:28:20 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 12C909121D for ; Thu, 27 Mar 2003 00:28:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id ECB2C5E209; Thu, 27 Mar 2003 00:28:18 -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 3BEFB5DE02 for ; Thu, 27 Mar 2003 00:28:18 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2R5QnU12690 for ; Thu, 27 Mar 2003 07:26:50 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Mar 2003 07:28:15 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Mar 2003 07:28:16 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Mar 2003 07:28:16 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Mar 2003 07:28:15 +0200 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: Thu, 27 Mar 2003 07:28:15 +0200 Message-ID: Thread-Topic: [AAA-WG]: comment on diameter credit control Thread-Index: AcLz05hiSWYYD/20TSyfO/9ap+vE/AATeJWA From: To: , Cc: X-OriginalArrivalTime: 27 Mar 2003 05:28:15.0996 (UTC) FILETIME=[AB027BC0:01C2F421] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA03402 Hi Kuntal, > >>Q1. What is a "home environment"? I guess it should be home network. > > > > Yes, the home environment is the home network. > > > > OK, then why don't we say "home network" instead, if you > don't mind :o)? Will fix it. > > Q2. Why are we precluding the Credit Control Server hosted > by a third party i.e. > > neither visited nor home network provider? > > The Credit Control Server is located in the same network > that own the user's account, which is usually the home > network. The visited network may proxy the service element > requests related to a visited user to the user's home > network, thus a Credit Control Proxy may be located in the > visited domain. > > IMHO, that's how AAA system works i.e. the visited AAA routes > AAA messages through proxy chain to the home AAA. Agreed. > > Perhaps the Credit Control Server may be hosted by third > party entity trusted by the home network, in cases where a > third party provider offers credit control services on behalf > of the home network (home network provider). In this case the > home network would forward the request to the trusted entity > providing credit control services, however, the third party > provider may be considered as an extention of the home > network, thus belonging to the "home environment". Would we > need some sentence explicitly covering this scenario or do > you have something else in mind? > > I did not know that you/authors assumed "home environment" > may include third > party (e.g. a prepaid reseller). In order to clarify the > scenario why don't we > say the following: > > " > Credit Control Server: The home network interfaces with this > entity and is > accessed by the service elements for the purpose of allowed > usage determination > and credit control before the service event is delivered to > the end-user. > " I'll look into adding this. John From owner-aaa-wg@merit.edu Thu Mar 27 10:30:57 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 KAA03433 for ; Thu, 27 Mar 2003 10:30:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 624C9912B7; Thu, 27 Mar 2003 10:33:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2BD92912B8; Thu, 27 Mar 2003 10:33:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4379D912B7 for ; Thu, 27 Mar 2003 10:32:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1D01E5E216; Thu, 27 Mar 2003 10:32:19 -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 C31EC5DDA3 for ; Thu, 27 Mar 2003 10:32:18 -0500 (EST) Received: from zrc2c001.us.nortel.com (zrc2c001.us.nortel.com [47.103.121.31]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2RFWBv17069; Thu, 27 Mar 2003 09:32:11 -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 H2DNL7B9; Thu, 27 Mar 2003 09:32:12 -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 GSPRQHYX; Thu, 27 Mar 2003 09:32:11 -0600 Message-ID: <3E831969.4040503@iqmail.net> Date: Thu, 27 Mar 2003 09:31:53 -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: john.loughney@nokia.com Cc: marco.stura@nokia.com, aaa-wg@merit.edu 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 Thanks for your consideration. I will provide more comments soon. Regards, Kuntal john.loughney@nokia.com wrote: > Hi Kuntal, > > >>>>Q1. What is a "home environment"? I guess it should be home network. >>> >>>Yes, the home environment is the home network. >>> >> >>OK, then why don't we say "home network" instead, if you >>don't mind :o)? > > > Will fix it. > > >>>Q2. Why are we precluding the Credit Control Server hosted >> >>by a third party i.e. >> >>>neither visited nor home network provider? >>>The Credit Control Server is located in the same network >> >>that own the user's account, which is usually the home >>network. The visited network may proxy the service element >>requests related to a visited user to the user's home >>network, thus a Credit Control Proxy may be located in the >>visited domain. >> >>IMHO, that's how AAA system works i.e. the visited AAA routes >>AAA messages through proxy chain to the home AAA. > > > Agreed. > > >>>Perhaps the Credit Control Server may be hosted by third >> >>party entity trusted by the home network, in cases where a >>third party provider offers credit control services on behalf >>of the home network (home network provider). In this case the >>home network would forward the request to the trusted entity >>providing credit control services, however, the third party >>provider may be considered as an extention of the home >>network, thus belonging to the "home environment". Would we >>need some sentence explicitly covering this scenario or do >>you have something else in mind? >> >>I did not know that you/authors assumed "home environment" >>may include third >>party (e.g. a prepaid reseller). In order to clarify the >>scenario why don't we >>say the following: >> >>" >>Credit Control Server: The home network interfaces with this >>entity and is >>accessed by the service elements for the purpose of allowed >>usage determination >>and credit control before the service event is delivered to >>the end-user. >>" > > > I'll look into adding this. > > John > From owner-aaa-wg@merit.edu Thu Mar 27 10:39: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 KAA03872 for ; Thu, 27 Mar 2003 10:39:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F20E1912B8; Thu, 27 Mar 2003 10:41:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1A36912B9; Thu, 27 Mar 2003 10:41:35 -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 78D00912B8 for ; Thu, 27 Mar 2003 10:41:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 68FDE5E216; Thu, 27 Mar 2003 10:41:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from web14809.mail.yahoo.com (web14809.mail.yahoo.com [216.136.224.230]) by segue.merit.edu (Postfix) with SMTP id BFAA25DDA3 for ; Thu, 27 Mar 2003 10:41:33 -0500 (EST) Message-ID: <20030327154133.74380.qmail@web14809.mail.yahoo.com> Received: from [65.213.193.49] by web14809.mail.yahoo.com via HTTP; Thu, 27 Mar 2003 07:41:33 PST Date: Thu, 27 Mar 2003 07:41:33 -0800 (PST) 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-1796641185-1048779693=:74337" Sender: owner-aaa-wg@merit.edu Precedence: bulk --0-1796641185-1048779693=:74337 Content-Type: text/plain; charset=us-ascii Dear Colleagues: Our sincere apologies if you receive multiple copies of this announcement. CONFERENCE ANNOUNCEMENT AND CALL FOR PRESENTATIONS Internetworking 2003 June 22-24, 2003 San Jose, California In technical cooperation with IEEE, IFIP, and ACM (Pending) Internetworking 2003 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 The Internetworking 2003 event in June will include participation from industry, government agencies, and academia. If you need additional technical information, please contact the Technical Cochairs Professor Maurice GAGNAIRE , or Daniel Awduche . --0-1796641185-1048779693=:74337 Content-Type: text/html; charset=us-ascii

Dear Colleagues:

Our sincere apologies if you receive multiple copies of this announcement.

     CONFERENCE ANNOUNCEMENT AND CALL FOR PRESENTATIONS

                   Internetworking 2003
                      June 22-24, 2003
                   San Jose, California
      In technical cooperation with IEEE, IFIP, and ACM (Pending)


Internetworking 2003 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


The Internetworking 2003 event in June will include participation from industry, government agencies, and academia. If you need additional technical information, please contact the Technical Cochairs Professor Maurice GAGNAIRE <gagnaire@enst.fr>, or Daniel Awduche <Awduche@awduche.com>.

--0-1796641185-1048779693=:74337-- From owner-aaa-wg@merit.edu Thu Mar 27 18:20: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 SAA25195 for ; Thu, 27 Mar 2003 18:20:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9B47891212; Thu, 27 Mar 2003 18:22:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F34591213; Thu, 27 Mar 2003 18:22:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 15DB691212 for ; Thu, 27 Mar 2003 18:22:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id F0DD85DE2E; Thu, 27 Mar 2003 18:22:29 -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 786EE5DE36 for ; Thu, 27 Mar 2003 18:22:29 -0500 (EST) Received: from zrc2c001.us.nortel.com (zrc2c001.us.nortel.com [47.103.121.31]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2RNMOv09873; Thu, 27 Mar 2003 17:22:25 -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 H2DNMB2N; Thu, 27 Mar 2003 17:22:25 -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 GSPRQ21B; Thu, 27 Mar 2003 17:22:25 -0600 Message-ID: <3E83879D.4010805@iqmail.net> Date: Thu, 27 Mar 2003 17:22:05 -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: john.loughney@nokia.com, marco.stura@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: comment on diameter credit control References: <3E831969.4040503@iqmail.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 Here are some more comments on section 2. section 2: " A service element provides services to end-users. When accounting is used a service element collects service event information and reports it while and/or after services are provided to an accounting server by using an accounting protocol. Alternatively the accounting server may query the service element for service event information. " The service element does not provide service to an accounting server, rather it provides service to an end-user. Suggestion: ...service element collects service event information and reports it to the accounting server using an accounting protocol while and/or after services are provided to an end-user. Section 2: " If real-time credit control is required, the service element (credit control client) contacts the credit control server with service event information included before the service is provided. The credit control server, depending on the service event information, MAY perform the rating of the service event, pricing of the service event, credit check and credit-reservation from the account. The service element monitors the service execution according to the instructions returned by the credit control server. After the service completion the credit control server deducts the money from the account. " Suggestion: If real-time credit control is required, the service element (credit control client) contacts the credit control server with service event information included before the service is authorized. The credit control server, depending on the service event information, MAY perform the rating of the service event, pricing of the service event, credit check and credit-reservation from the account. The service element monitors the service execution according to the instructions returned by the credit control server. After the service completion or upon reaching the authorized usage limit the credit control server reconciles the end-user's account balance based on the accounting message received from the service element. Section 2: " If direct debiting/refunding is requested, the credit control server deducts/increases the end user's account, respectively. The service element can also enquire the price of the service or the account balance status from the credit control server. " Q: Who requests direct debit/refunding? I think the credit control server does debit/credit/reconcile the end-user's balance for all transactions. Q. Not sure what does this mean: "The service element can also enquire the price of the service or the account balance status from the credit control server." Q. Why would the service element be interested to know price of a service? IMHO, all it needs to know whether a requested service is authorized or not, if authorized then what is the authorized duration etc. Section 2: " There MAY exist protocol transparent Diameter relays and redirect agents between credit control client and credit control server. These agents transparently support the Diameter credit control application. " Suggestion: Please show the location of the credit control client in the figure. -KC Kuntal Chowdhury wrote: > Thanks for your consideration. I will provide more comments soon. > > Regards, > Kuntal > > > john.loughney@nokia.com wrote: > >> Hi Kuntal, >> >> >>>>> Q1. What is a "home environment"? I guess it should be home network. >>>> >>>> >>>> Yes, the home environment is the home network. >>>> >>> >>> OK, then why don't we say "home network" instead, if you don't mind :o)? >> >> >> >> Will fix it. >> >> >>>> Q2. Why are we precluding the Credit Control Server hosted >>> >>> >>> by a third party i.e. >>> >>>> neither visited nor home network provider? >>>> The Credit Control Server is located in the same network >>> >>> >>> that own the user's account, which is usually the home network. The >>> visited network may proxy the service element requests related to a >>> visited user to the user's home network, thus a Credit Control Proxy >>> may be located in the visited domain. >>> >>> IMHO, that's how AAA system works i.e. the visited AAA routes AAA >>> messages through proxy chain to the home AAA. >> >> >> >> Agreed. >> >> >>>> Perhaps the Credit Control Server may be hosted by third >>> >>> >>> party entity trusted by the home network, in cases where a third >>> party provider offers credit control services on behalf of the home >>> network (home network provider). In this case the home network would >>> forward the request to the trusted entity providing credit control >>> services, however, the third party provider may be considered as an >>> extention of the home network, thus belonging to the "home >>> environment". Would we need some sentence explicitly covering this >>> scenario or do you have something else in mind? >>> >>> I did not know that you/authors assumed "home environment" may >>> include third party (e.g. a prepaid reseller). In order to clarify >>> the scenario why don't we say the following: >>> >>> " >>> Credit Control Server: The home network interfaces with this entity >>> and is accessed by the service elements for the purpose of allowed >>> usage determination and credit control before the service event is >>> delivered to the end-user. >>> " >> >> >> >> I'll look into adding this. >> >> John >> > > > From owner-aaa-wg@merit.edu Fri Mar 28 04: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 EAA21780 for ; Fri, 28 Mar 2003 04:12:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CDC9F91221; Fri, 28 Mar 2003 04:14:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9FAEE91222; Fri, 28 Mar 2003 04:14:52 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E539191221 for ; Fri, 28 Mar 2003 04:14:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id C69DC5DEAD; Fri, 28 Mar 2003 04:14:50 -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 4974F5DE01 for ; Fri, 28 Mar 2003 04:14:50 -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.8/8.12.8/WIREfire-1.5) with ESMTP id h2S9EmYA024499 for ; Fri, 28 Mar 2003 10:14:49 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 28 Mar 2003 10:14:48 +0100 Message-ID: From: "Harri Hakala (LMF)" To: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: comment on diameter credit control Date: Fri, 28 Mar 2003 10:14:38 +0100 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 > -----Original Message----- > From: Harri Hakala (LMF) > Sent: 28. maaliskuuta 2003 9:52 > To: 'Kuntal Chowdhury'; john.loughney@nokia.com; marco.stura@nokia.com > Cc: aaa-wg@merit.edu; Leena Mattila (LMF) > Subject: RE: [AAA-WG]: comment on diameter credit control > > > Hi Kuntal, > > Thank you for your comments. See my answers below. > > Regards............Harri > > > > Suggestion: > > > > ...service element collects service event information and > > reports it to the > > accounting server using an accounting protocol while and/or > > after services are > > provided to an end-user. > > Ok > > > > " > > If real-time credit control is required, the service > > element (credit > > control client) contacts the credit control server with > > service event > > information included before the service is provided. The credit > > control server, depending on the service event information, MAY > > perform the rating of the service event, pricing of the service > > event, credit check and credit-reservation from the account. The > > service element monitors the service execution according to the > > instructions returned by the credit control server. After > > the service > > completion the credit control server deducts the money from the > > account. > > " > > > > Suggestion: > > > > > > If real-time credit control is required, the service > > element (credit > > control client) contacts the credit control server with > > service event > > information included before the service is authorized. > > The intention is that end user is first authenticated and > authorized to > use the service and after that the service element contacts the credit > control server to check the end user's account for coverage > for the requested > service event charge. > > > Q: Who requests direct debit/refunding? > > I think the credit control server does debit/credit/reconcile > > the end-user's > > balance for all transactions. > > We have certain one time event use cases (chapter 3.2), which can > be used when there is no need to maintain accounting session > state in the > credit control server. Direct debiting is used when there is > no need to > make a separate reservation from the account but the service > can be charged directly > in one shot. This can be used for instance in case of > Multimedia Messaging (MMS), i.e. > when the MMS-C receives an MMS message from the calling user, > it can store the message > and send a direct debiting request to the credit control > server. The credit control > server deducts money from the account and returns the granted > units to the MMS-C, > which in turn acknowledges the message reception and forwards > the multimedia message > to the recipient. In case the credit control server instructs > the MMS-C to reject the > service request, the MMS-C will remove the Multimedia message > from its storage and send > a negative acknowledgement to the user, possibly with some > explanatory information about > the reason. > > When Mobile Internet services are taking off it is expected > that there will also be > services that would sometimes actually increase the > subscriber's account balance > instead of decreasing it. Services like this are, for > instance, answering questionnaires > or games where the subscriber wins some extra rewards when he > reaches a certain point level. > > > Q. Not sure what does this mean: "The service element can > > also enquire the price > > of the service or the account balance status from the credit > > control server." > > The Price Enquiry can be used when the service element wants > to know the cost of the service > event without any credit-reservation. Check Balance can be > used when service element wants > to check the account balance without any credit-reservation. > > > Q. Why would the service element be interested to know price > > of a service? IMHO, > > all it needs to know whether a requested service is > > authorized or not, if > > authorized then what is the authorized duration etc. > > The end user may want to get an estimation of the price of > the service before > actually requesting it. If the service node does not have the > price information > available, it can utilize the centralized rating capabilities > in the credit > control server and make a price enquiry to the credit control > server using the > Diameter one-time event accounting record. The credit control > server will rate > the service and return the price estimate to the service node > that will forward > this to the end user. > > > > Section 2: > > > > " > > There MAY exist protocol transparent Diameter relays > and redirect > > agents between credit control client and credit control > > server. These > > agents transparently support the Diameter credit control > > application. > > " > > > > Suggestion: Please show the location of the credit control > > client in the figure. > > > > Ok. > > > > -----Original Message----- > > From: Kuntal Chowdhury [mailto:kuntal@iqmail.net] > > Sent: 28. maaliskuuta 2003 1:22 > > To: john.loughney@nokia.com; marco.stura@nokia.com > > Cc: aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: comment on diameter credit control > > > > > > Here are some more comments on section 2. > > > > section 2: > > > > " > > A service element provides services to end-users. When > > accounting is > > used a service element collects service event information > > and reports > > it while and/or after services are provided to an > > accounting server > > by using an accounting protocol. Alternatively the > > accounting server > > may query the service element for service event information. > > " > > > > The service element does not provide service to an accounting > > server, rather it > > provides service to an end-user. > > > > Suggestion: > > > > ...service element collects service event information and > > reports it to the > > accounting server using an accounting protocol while and/or > > after services are > > provided to an end-user. > > > > Section 2: > > > > " > > If real-time credit control is required, the service > > element (credit > > control client) contacts the credit control server with > > service event > > information included before the service is provided. The credit > > control server, depending on the service event information, MAY > > perform the rating of the service event, pricing of the service > > event, credit check and credit-reservation from the account. The > > service element monitors the service execution according to the > > instructions returned by the credit control server. After > > the service > > completion the credit control server deducts the money from the > > account. > > " > > > > Suggestion: > > > > > > If real-time credit control is required, the service > > element (credit > > control client) contacts the credit control server with > > service event > > information included before the service is authorized. > The credit > > control server, depending on the service event information, MAY > > perform the rating of the service event, pricing of the service > > event, credit check and credit-reservation from the account. The > > service element monitors the service execution according to the > > instructions returned by the credit control server. After > > the service > > completion or upon reaching the authorized usage limit > > the credit control > > server reconciles the end-user's account balance > > based on the > > accounting message received from the service element. > > > > > > Section 2: > > > > " > > If direct debiting/refunding is requested, the credit > > control server > > deducts/increases the end user's account, respectively. > > The service > > element can also enquire the price of the service or the account > > balance status from the credit control server. > > " > > > > Q: Who requests direct debit/refunding? > > I think the credit control server does debit/credit/reconcile > > the end-user's > > balance for all transactions. > > > > Q. Not sure what does this mean: "The service element can > > also enquire the price > > of the service or the account balance status from the credit > > control server." > > > > Q. Why would the service element be interested to know price > > of a service? IMHO, > > all it needs to know whether a requested service is > > authorized or not, if > > authorized then what is the authorized duration etc. > > > > Section 2: > > > > " > > There MAY exist protocol transparent Diameter relays > and redirect > > agents between credit control client and credit control > > server. These > > agents transparently support the Diameter credit control > > application. > > " > > > > Suggestion: Please show the location of the credit control > > client in the figure. > > > > -KC > > > > > > Kuntal Chowdhury wrote: > > > Thanks for your consideration. I will provide more comments soon. > > > > > > Regards, > > > Kuntal > > > > > > > > > john.loughney@nokia.com wrote: > > > > > >> Hi Kuntal, > > >> > > >> > > >>>>> Q1. What is a "home environment"? I guess it should be > > home network. > > >>>> > > >>>> > > >>>> Yes, the home environment is the home network. > > >>>> > > >>> > > >>> OK, then why don't we say "home network" instead, if you > > don't mind :o)? > > >> > > >> > > >> > > >> Will fix it. > > >> > > >> > > >>>> Q2. Why are we precluding the Credit Control Server hosted > > >>> > > >>> > > >>> by a third party i.e. > > >>> > > >>>> neither visited nor home network provider? > > >>>> The Credit Control Server is located in the same network > > >>> > > >>> > > >>> that own the user's account, which is usually the home > > network. The > > >>> visited network may proxy the service element requests > > related to a > > >>> visited user to the user's home network, thus a Credit > > Control Proxy > > >>> may be located in the visited domain. > > >>> > > >>> IMHO, that's how AAA system works i.e. the visited AAA > routes AAA > > >>> messages through proxy chain to the home AAA. > > >> > > >> > > >> > > >> Agreed. > > >> > > >> > > >>>> Perhaps the Credit Control Server may be hosted by third > > >>> > > >>> > > >>> party entity trusted by the home network, in cases > where a third > > >>> party provider offers credit control services on behalf > > of the home > > >>> network (home network provider). In this case the home > > network would > > >>> forward the request to the trusted entity providing > > credit control > > >>> services, however, the third party provider may be > > considered as an > > >>> extention of the home network, thus belonging to the "home > > >>> environment". Would we need some sentence explicitly > > covering this > > >>> scenario or do you have something else in mind? > > >>> > > >>> I did not know that you/authors assumed "home environment" may > > >>> include third party (e.g. a prepaid reseller). In order > > to clarify > > >>> the scenario why don't we say the following: > > >>> > > >>> " > > >>> Credit Control Server: The home network interfaces with > > this entity > > >>> and is accessed by the service elements for the purpose > > of allowed > > >>> usage determination and credit control before the service > > event is > > >>> delivered to the end-user. > > >>> " > > >> > > >> > > >> > > >> I'll look into adding this. > > >> > > >> John > > >> > > > > > > > > > > > > > > From owner-aaa-wg@merit.edu Fri Mar 28 16:37:18 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 QAA20158 for ; Fri, 28 Mar 2003 16:37:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9698591278; Fri, 28 Mar 2003 16:39:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD218912ED; Fri, 28 Mar 2003 16:39:26 -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 6D98D91278 for ; Fri, 28 Mar 2003 16:39:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5B56E5DE59; Fri, 28 Mar 2003 16:39:25 -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 D55D75DE58 for ; Fri, 28 Mar 2003 16:39:24 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2SLdES17090; Fri, 28 Mar 2003 15:39:14 -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 HNP4N70K; Fri, 28 Mar 2003 15:39:14 -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 GSPRQ2TR; Fri, 28 Mar 2003 15:39:14 -0600 Message-ID: <3E84C0EC.5010805@iqmail.net> Date: Fri, 28 Mar 2003 15:38:52 -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: john.loughney@nokia.com, marco.stura@nokia.com, aaa-wg@merit.edu, "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 Hello Harri, Please see my comments inline... -KC Harri Hakala (LMF) wrote: >> If real-time credit control is required, the service >>element (credit >> control client) contacts the credit control server with >>service event >> information included before the service is provided. The credit >> control server, depending on the service event information, MAY >> perform the rating of the service event, pricing of the service >> event, credit check and credit-reservation from the account. The >> service element monitors the service execution according to the >> instructions returned by the credit control server. After >>the service >> completion the credit control server deducts the money from the >> account. >>" >> >>Suggestion: >> >> >> If real-time credit control is required, the service >>element (credit >> control client) contacts the credit control server with >>service event >> information included before the service is authorized. > > > The intention is that end user is first authenticated and authorized to > use the service and after that the service element contacts the credit > control server to check the end user's account for coverage for the requested > service event charge. > 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. > >>Q: Who requests direct debit/refunding? >>I think the credit control server does debit/credit/reconcile >>the end-user's >>balance for all transactions. > > > We have certain one time event use cases (chapter 3.2), which can > be used when there is no need to maintain accounting session state in the > credit control server. Direct debiting is used when there is no need to > make a separate reservation from the account but the service can be charged directly > in one shot. This can be used for instance in case of Multimedia Messaging (MMS), i.e. > when the MMS-C receives an MMS message from the calling user, it can store the message > and send a direct debiting request to the credit control server. The credit control > server deducts money from the account and returns the granted units to the MMS-C, > which in turn acknowledges the message reception and forwards the multimedia message > to the recipient. In case the credit control server instructs the MMS-C to reject the > service request, the MMS-C will remove the Multimedia message from its storage and send > a negative acknowledgement to the user, possibly with some explanatory information about > the reason. > > When Mobile Internet services are taking off it is expected that there will also be > services that would sometimes actually increase the subscriber's account balance > instead of decreasing it. Services like this are, for instance, answering questionnaires > or games where the subscriber wins some extra rewards when he reaches a certain point level. > OK, thanks for the explanation. > >>Q. Not sure what does this mean: "The service element can >>also enquire the price >>of the service or the account balance status from the credit >>control server." > > > The Price Enquiry can be used when the service element wants to know the cost of the service > event without any credit-reservation. Check Balance can be used when service element wants > to check the account balance without any credit-reservation. > 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. > >>Q. Why would the service element be interested to know price >>of a service? IMHO, >>all it needs to know whether a requested service is >>authorized or not, if >>authorized then what is the authorized duration etc. > > > The end user may want to get an estimation of the price of the service before > actually requesting it. If the service node does not have the price information > available, it can utilize the centralized rating capabilities in the credit > control server and make a price enquiry to the credit control server using the > Diameter one-time event accounting record. The credit control server will rate > the service and return the price estimate to the service node that will forward > this to the end user. > > 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. From owner-aaa-wg@merit.edu Fri Mar 28 22:17:06 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 WAA29902 for ; Fri, 28 Mar 2003 22:17:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3BB619122A; Fri, 28 Mar 2003 22:19:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F25179122D; Fri, 28 Mar 2003 22:19:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 32E299122A for ; Fri, 28 Mar 2003 22:18:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 141D85DEDE; Fri, 28 Mar 2003 22:18:52 -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 2AFE95DED8 for ; Fri, 28 Mar 2003 22:18:51 -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.8/8.12.8/WIREfire-1.5) with ESMTP id h2S7pabh012267; Fri, 28 Mar 2003 08:51:36 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 28 Mar 2003 08:51:37 +0100 Message-ID: From: "Harri Hakala (LMF)" To: "'Kuntal Chowdhury'" , john.loughney@nokia.com, marco.stura@nokia.com Cc: aaa-wg@merit.edu, "Leena Mattila (LMF)" Subject: RE: [AAA-WG]: comment on diameter credit control Date: Fri, 28 Mar 2003 08:51:33 +0100 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, Thank you for your comments. See my answers below. Regards............Harri > Suggestion: > > ...service element collects service event information and > reports it to the > accounting server using an accounting protocol while and/or > after services are > provided to an end-user. Ok > " > If real-time credit control is required, the service > element (credit > control client) contacts the credit control server with > service event > information included before the service is provided. The credit > control server, depending on the service event information, MAY > perform the rating of the service event, pricing of the service > event, credit check and credit-reservation from the account. The > service element monitors the service execution according to the > instructions returned by the credit control server. After > the service > completion the credit control server deducts the money from the > account. > " > > Suggestion: > > > If real-time credit control is required, the service > element (credit > control client) contacts the credit control server with > service event > information included before the service is authorized. The intention is that end user is first authenticated and authorized to use the service and after that the service element contacts the credit control server to check the end user's account for coverage for the requested service event charge. > Q: Who requests direct debit/refunding? > I think the credit control server does debit/credit/reconcile > the end-user's > balance for all transactions. We have certain one time event use cases (chapter 3.2), which can be used when there is no need to maintain accounting session state in the credit control server. Direct debiting is used when there is no need to make a separate reservation from the account but the service can be charged directly in one shot. This can be used for instance in case of Multimedia Messaging (MMS), i.e. when the MMS-C receives an MMS message from the calling user, it can store the message and send a direct debiting request to the credit control server. The credit control server deducts money from the account and returns the granted units to the MMS-C, which in turn acknowledges the message reception and forwards the multimedia message to the recipient. In case the credit control server instructs the MMS-C to reject the service request, the MMS-C will remove the Multimedia message from its storage and send a negative acknowledgement to the user, possibly with some explanatory information about the reason. When Mobile Internet services are taking off it is expected that there will also be services that would sometimes actually increase the subscriber's account balance instead of decreasing it. Services like this are, for instance, answering questionnaires or games where the subscriber wins some extra rewards when he reaches a certain point level. > Q. Not sure what does this mean: "The service element can > also enquire the price > of the service or the account balance status from the credit > control server." The Price Enquiry can be used when the service element wants to know the cost of the service event without any credit-reservation. Check Balance can be used when service element wants to check the account balance without any credit-reservation. > Q. Why would the service element be interested to know price > of a service? IMHO, > all it needs to know whether a requested service is > authorized or not, if > authorized then what is the authorized duration etc. The end user may want to get an estimation of the price of the service before actually requesting it. If the service node does not have the price information available, it can utilize the centralized rating capabilities in the credit control server and make a price enquiry to the credit control server using the Diameter one-time event accounting record. The credit control server will rate the service and return the price estimate to the service node that will forward this to the end user. > Section 2: > > " > There MAY exist protocol transparent Diameter relays and redirect > agents between credit control client and credit control > server. These > agents transparently support the Diameter credit control > application. > " > > Suggestion: Please show the location of the credit control > client in the figure. > Ok. > -----Original Message----- > From: Kuntal Chowdhury [mailto:kuntal@iqmail.net] > Sent: 28. maaliskuuta 2003 1:22 > To: john.loughney@nokia.com; marco.stura@nokia.com > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: comment on diameter credit control > > > Here are some more comments on section 2. > > section 2: > > " > A service element provides services to end-users. When > accounting is > used a service element collects service event information > and reports > it while and/or after services are provided to an > accounting server > by using an accounting protocol. Alternatively the > accounting server > may query the service element for service event information. > " > > The service element does not provide service to an accounting > server, rather it > provides service to an end-user. > > Suggestion: > > ...service element collects service event information and > reports it to the > accounting server using an accounting protocol while and/or > after services are > provided to an end-user. > > Section 2: > > " > If real-time credit control is required, the service > element (credit > control client) contacts the credit control server with > service event > information included before the service is provided. The credit > control server, depending on the service event information, MAY > perform the rating of the service event, pricing of the service > event, credit check and credit-reservation from the account. The > service element monitors the service execution according to the > instructions returned by the credit control server. After > the service > completion the credit control server deducts the money from the > account. > " > > Suggestion: > > > If real-time credit control is required, the service > element (credit > control client) contacts the credit control server with > service event > information included before the service is authorized. The credit > control server, depending on the service event information, MAY > perform the rating of the service event, pricing of the service > event, credit check and credit-reservation from the account. The > service element monitors the service execution according to the > instructions returned by the credit control server. After > the service > completion or upon reaching the authorized usage limit > the credit control > server reconciles the end-user's account balance > based on the > accounting message received from the service element. > > > Section 2: > > " > If direct debiting/refunding is requested, the credit > control server > deducts/increases the end user's account, respectively. > The service > element can also enquire the price of the service or the account > balance status from the credit control server. > " > > Q: Who requests direct debit/refunding? > I think the credit control server does debit/credit/reconcile > the end-user's > balance for all transactions. > > Q. Not sure what does this mean: "The service element can > also enquire the price > of the service or the account balance status from the credit > control server." > > Q. Why would the service element be interested to know price > of a service? IMHO, > all it needs to know whether a requested service is > authorized or not, if > authorized then what is the authorized duration etc. > > Section 2: > > " > There MAY exist protocol transparent Diameter relays and redirect > agents between credit control client and credit control > server. These > agents transparently support the Diameter credit control > application. > " > > Suggestion: Please show the location of the credit control > client in the figure. > > -KC > > > Kuntal Chowdhury wrote: > > Thanks for your consideration. I will provide more comments soon. > > > > Regards, > > Kuntal > > > > > > john.loughney@nokia.com wrote: > > > >> Hi Kuntal, > >> > >> > >>>>> Q1. What is a "home environment"? I guess it should be > home network. > >>>> > >>>> > >>>> Yes, the home environment is the home network. > >>>> > >>> > >>> OK, then why don't we say "home network" instead, if you > don't mind :o)? > >> > >> > >> > >> Will fix it. > >> > >> > >>>> Q2. Why are we precluding the Credit Control Server hosted > >>> > >>> > >>> by a third party i.e. > >>> > >>>> neither visited nor home network provider? > >>>> The Credit Control Server is located in the same network > >>> > >>> > >>> that own the user's account, which is usually the home > network. The > >>> visited network may proxy the service element requests > related to a > >>> visited user to the user's home network, thus a Credit > Control Proxy > >>> may be located in the visited domain. > >>> > >>> IMHO, that's how AAA system works i.e. the visited AAA routes AAA > >>> messages through proxy chain to the home AAA. > >> > >> > >> > >> Agreed. > >> > >> > >>>> Perhaps the Credit Control Server may be hosted by third > >>> > >>> > >>> party entity trusted by the home network, in cases where a third > >>> party provider offers credit control services on behalf > of the home > >>> network (home network provider). In this case the home > network would > >>> forward the request to the trusted entity providing > credit control > >>> services, however, the third party provider may be > considered as an > >>> extention of the home network, thus belonging to the "home > >>> environment". Would we need some sentence explicitly > covering this > >>> scenario or do you have something else in mind? > >>> > >>> I did not know that you/authors assumed "home environment" may > >>> include third party (e.g. a prepaid reseller). In order > to clarify > >>> the scenario why don't we say the following: > >>> > >>> " > >>> Credit Control Server: The home network interfaces with > this entity > >>> and is accessed by the service elements for the purpose > of allowed > >>> usage determination and credit control before the service > event is > >>> delivered to the end-user. > >>> " > >> > >> > >> > >> I'll look into adding this. > >> > >> John > >> > > > > > > > > From owner-aaa-wg@merit.edu Mon Mar 31 00:05: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 AAA13530 for ; Mon, 31 Mar 2003 00:05:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 425E191242; Mon, 31 Mar 2003 00:07:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 01E6991273; Mon, 31 Mar 2003 00:07:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A733D91242 for ; Mon, 31 Mar 2003 00:02:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id C83425E20C; Mon, 31 Mar 2003 00:01: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 DA5105E203 for ; Mon, 31 Mar 2003 00:01:24 -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.8/8.12.8/WIREfire-1.5) with ESMTP id h2V51Crs003877; Mon, 31 Mar 2003 07:01:12 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 31 Mar 2003 07:01:12 +0200 Message-ID: From: "Harri Hakala (LMF)" To: aaa-wg@merit.edu, "'Kuntal Chowdhury'" Cc: john.loughney@nokia.com, marco.stura@nokia.com, "Leena Mattila (LMF)" Subject: RE: [AAA-WG]: comment on diameter credit control Date: Mon, 31 Mar 2003 07:01: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 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. 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). 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. Regards..........Harri > -----Original Message----- > From: Kuntal Chowdhury [mailto:kuntal@iqmail.net] > Sent: 28. maaliskuuta 2003 23:39 > To: Harri Hakala (LMF) > Cc: john.loughney@nokia.com; marco.stura@nokia.com; aaa-wg@merit.edu; > Leena Mattila (LMF) > Subject: Re: [AAA-WG]: comment on diameter credit control > > > Hello Harri, > > Please see my comments inline... > > -KC > > Harri Hakala (LMF) wrote: > > >> If real-time credit control is required, the service > >>element (credit > >> control client) contacts the credit control server with > >>service event > >> information included before the service is provided. The credit > >> control server, depending on the service event information, MAY > >> perform the rating of the service event, pricing of the service > >> event, credit check and credit-reservation from the account. The > >> service element monitors the service execution according to the > >> instructions returned by the credit control server. After > >>the service > >> completion the credit control server deducts the money from the > >> account. > >>" > >> > >>Suggestion: > >> > >> > >> If real-time credit control is required, the service > >>element (credit > >> control client) contacts the credit control server with > >>service event > >> information included before the service is authorized. > > > > > > The intention is that end user is first authenticated and > authorized to > > use the service and after that the service element contacts > the credit > > control server to check the end user's account for coverage > for the requested > > service event charge. > > > > 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. > > > > >>Q: Who requests direct debit/refunding? > >>I think the credit control server does debit/credit/reconcile > >>the end-user's > >>balance for all transactions. > > > > > > We have certain one time event use cases (chapter 3.2), which can > > be used when there is no need to maintain accounting > session state in the > > credit control server. Direct debiting is used when there > is no need to > > make a separate reservation from the account but the > service can be charged directly > > in one shot. This can be used for instance in case of > Multimedia Messaging (MMS), i.e. > > when the MMS-C receives an MMS message from the calling > user, it can store the message > > and send a direct debiting request to the credit control > server. The credit control > > server deducts money from the account and returns the > granted units to the MMS-C, > > which in turn acknowledges the message reception and > forwards the multimedia message > > to the recipient. In case the credit control server > instructs the MMS-C to reject the > > service request, the MMS-C will remove the Multimedia > message from its storage and send > > a negative acknowledgement to the user, possibly with some > explanatory information about > > the reason. > > > > When Mobile Internet services are taking off it is expected > that there will also be > > services that would sometimes actually increase the > subscriber's account balance > > instead of decreasing it. Services like this are, for > instance, answering questionnaires > > or games where the subscriber wins some extra rewards when > he reaches a certain point level. > > > > OK, thanks for the explanation. > > > > >>Q. Not sure what does this mean: "The service element can > >>also enquire the price > >>of the service or the account balance status from the credit > >>control server." > > > > > > The Price Enquiry can be used when the service element > wants to know the cost of the service > > event without any credit-reservation. Check Balance can be > used when service element wants > > to check the account balance without any credit-reservation. > > > > 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. > > > > >>Q. Why would the service element be interested to know price > >>of a service? IMHO, > >>all it needs to know whether a requested service is > >>authorized or not, if > >>authorized then what is the authorized duration etc. > > > > > > The end user may want to get an estimation of the price of > the service before > > actually requesting it. If the service node does not have > the price information > > available, it can utilize the centralized rating > capabilities in the credit > > control server and make a price enquiry to the credit > control server using the > > Diameter one-time event accounting record. The credit > control server will rate > > the service and return the price estimate to the service > node that will forward > > this to the end user. > > > > > > 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. > From owner-aaa-wg@merit.edu Mon Mar 31 01:16:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15072 for ; Mon, 31 Mar 2003 01:16:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D055091273; Mon, 31 Mar 2003 01:18:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B3D291275; Mon, 31 Mar 2003 01:18:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4DD7691273 for ; Mon, 31 Mar 2003 01:17:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id D93225E20D; Mon, 31 Mar 2003 01:17:45 -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 592DD5E1F1 for ; Mon, 31 Mar 2003 01:17:45 -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.8/8.12.8/WIREfire-1.5) with ESMTP id h2V6HgUE026044; Mon, 31 Mar 2003 08:17:42 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 31 Mar 2003 08:17:43 +0200 Message-ID: From: "Harri Hakala (LMF)" To: aaa-wg@merit.edu, "'Kuntal Chowdhury'" Cc: john.loughney@nokia.com, marco.stura@nokia.com, aaa-wg@merit.edu, "Leena Mattila (LMF)" Subject: RE: [AAA-WG]: comment on diameter credit control Date: Mon, 31 Mar 2003 08:17:34 +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: > 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. 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. But of course we can discuss whether this support is really needed. Regards.....Harri > -----Original Message----- > From: Kuntal Chowdhury [mailto:kuntal@iqmail.net] > Sent: 28. maaliskuuta 2003 23:39 > To: Harri Hakala (LMF) > Cc: john.loughney@nokia.com; marco.stura@nokia.com; aaa-wg@merit.edu; > Leena Mattila (LMF) > Subject: Re: [AAA-WG]: comment on diameter credit control > > > Hello Harri, > > Please see my comments inline... > > -KC > > Harri Hakala (LMF) wrote: > > >> If real-time credit control is required, the service > >>element (credit > >> control client) contacts the credit control server with > >>service event > >> information included before the service is provided. The credit > >> control server, depending on the service event information, MAY > >> perform the rating of the service event, pricing of the service > >> event, credit check and credit-reservation from the account. The > >> service element monitors the service execution according to the > >> instructions returned by the credit control server. After > >>the service > >> completion the credit control server deducts the money from the > >> account. > >>" > >> > >>Suggestion: > >> > >> > >> If real-time credit control is required, the service > >>element (credit > >> control client) contacts the credit control server with > >>service event > >> information included before the service is authorized. > > > > > > The intention is that end user is first authenticated and > authorized to > > use the service and after that the service element contacts > the credit > > control server to check the end user's account for coverage > for the requested > > service event charge. > > > > 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. > > > > >>Q: Who requests direct debit/refunding? > >>I think the credit control server does debit/credit/reconcile > >>the end-user's > >>balance for all transactions. > > > > > > We have certain one time event use cases (chapter 3.2), which can > > be used when there is no need to maintain accounting > session state in the > > credit control server. Direct debiting is used when there > is no need to > > make a separate reservation from the account but the > service can be charged directly > > in one shot. This can be used for instance in case of > Multimedia Messaging (MMS), i.e. > > when the MMS-C receives an MMS message from the calling > user, it can store the message > > and send a direct debiting request to the credit control > server. The credit control > > server deducts money from the account and returns the > granted units to the MMS-C, > > which in turn acknowledges the message reception and > forwards the multimedia message > > to the recipient. In case the credit control server > instructs the MMS-C to reject the > > service request, the MMS-C will remove the Multimedia > message from its storage and send > > a negative acknowledgement to the user, possibly with some > explanatory information about > > the reason. > > > > When Mobile Internet services are taking off it is expected > that there will also be > > services that would sometimes actually increase the > subscriber's account balance > > instead of decreasing it. Services like this are, for > instance, answering questionnaires > > or games where the subscriber wins some extra rewards when > he reaches a certain point level. > > > > OK, thanks for the explanation. > > > > >>Q. Not sure what does this mean: "The service element can > >>also enquire the price > >>of the service or the account balance status from the credit > >>control server." > > > > > > The Price Enquiry can be used when the service element > wants to know the cost of the service > > event without any credit-reservation. Check Balance can be > used when service element wants > > to check the account balance without any credit-reservation. > > > > 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. > > > > >>Q. Why would the service element be interested to know price > >>of a service? IMHO, > >>all it needs to know whether a requested service is > >>authorized or not, if > >>authorized then what is the authorized duration etc. > > > > > > The end user may want to get an estimation of the price of > the service before > > actually requesting it. If the service node does not have > the price information > > available, it can utilize the centralized rating > capabilities in the credit > > control server and make a price enquiry to the credit > control server using the > > Diameter one-time event accounting record. The credit > control server will rate > > the service and return the price estimate to the service > node that will forward > > this to the end user. > > > > > > 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. >