From exim@www1.ietf.org Thu Apr 1 12:38:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23290 for ; Thu, 1 Apr 2004 12:38:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B968c-0007C6-Lh for aaa-archive@odin.ietf.org; Thu, 01 Apr 2004 12:37:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31Hbwu0027645 for aaa-archive@odin.ietf.org; Thu, 1 Apr 2004 12:37:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B968c-00078o-C7 for aaa-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 12:37:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19885 for ; Thu, 1 Apr 2004 11:36:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B95BI-0006IG-00 for aaa-web-archive@ietf.org; Thu, 01 Apr 2004 11:36:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B956t-0005Ny-00 for aaa-web-archive@ietf.org; Thu, 01 Apr 2004 11:32:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9556-0004xC-00 for aaa-web-archive@ietf.org; Thu, 01 Apr 2004 11:30:16 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B94sC-00058I-W3 for aaa-web-archive@ietf.org; Thu, 01 Apr 2004 11:16:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B94sA-0003Zv-Tu for aaa-web-archive@ietf.org; Thu, 01 Apr 2004 11:16:54 -0500 Date: Thu, 01 Apr 2004 11:16:54 -0500 Message-ID: <20040401161654.11029.30915.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: aaa-web-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 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 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-web-archive@ietf.org: List Password // URL ---- -------- aaa@ietf.org wumate https://www1.ietf.org/mailman/options/aaa/aaa-web-archive%40ietf.org From mailman-admin@ietf.org Thu Apr 1 18:27:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08981 for ; Thu, 1 Apr 2004 18:27:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99Xo-0007qp-IL for aaa-archive@lists.ietf.org; Thu, 01 Apr 2004 16:16:12 -0500 Date: Thu, 01 Apr 2004 11:21:11 -0500 Message-ID: <20040401162111.11029.33887.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 aaa-admin@ietf.org Thu Apr 1 19:01:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11169 for ; Thu, 1 Apr 2004 19:01:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ABS-0007az-BO; Thu, 01 Apr 2004 16:57:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95m3-0001eM-Ll for aaa@optimus.ietf.org; Thu, 01 Apr 2004 12:14:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19352 for ; Thu, 1 Apr 2004 11:24:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94zE-0004Sb-00 for aaa@ietf.org; Thu, 01 Apr 2004 11:24:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94yI-0004Nj-00 for aaa@ietf.org; Thu, 01 Apr 2004 11:23:15 -0500 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1B94xZ-0004EJ-00 for aaa@ietf.org; Thu, 01 Apr 2004 11:22:29 -0500 Received: from exchange0.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Thu, 1 Apr 2004 17:16:30 +0200 Received: by sv3752.bonn.de with Internet Mail Service (5.5.2653.19) id <2CP1YBV7>; Thu, 1 Apr 2004 18:22:20 +0200 Message-ID: <1C2329C9430609409808ECF102372876FB8522@sv3752.bonn.de> From: Systemadministrator To: aaa@ietf.org Date: Thu, 1 Apr 2004 18:22:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C41805.814A4D90" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Aaa] Unzustellbar: fake Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C41805.814A4D90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: cxc@bonn.de Subject: fake Sent: Thu, 1 Apr 2004 18:10:41 +0200 did not reach the following recipient(s): cxc@bonn.de on Thu, 1 Apr 2004 18:22:08 +0200 Der Name des Empf=E4ngers wurde nicht erkannt. Die MTS-ID der urspr=FCnglichen Nachricht ist: c=3Dde;a=3D = ;p=3Dbundesstadt bonn;l=3DSV375204040116222CP1YBVM MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C41805.814A4D90 Content-Type: message/rfc822 From: aaa@ietf.org To: cxc@bonn.de Subject: fake Date: Thu, 1 Apr 2004 18:10:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C41805.814A4D90" ------_=_NextPart_002_01C41805.814A4D90 Content-Type: text/plain; charset="iso-8859-1" you are a bad writer ------_=_NextPart_002_01C41805.814A4D90 Content-Type: text/plain; name="InterScan_SafeStamp.txt" Content-Disposition: attachment; filename="InterScan_SafeStamp.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file msg.rtf.pif contains: WORM_NETSKY.B virus Attempted to clean the file but it is not cleanable. It has been deleted. Mail-Virus von Trend Micro Interscan Viruswall entdeckt und entfernt! ***************** End of message *************** ------_=_NextPart_002_01C41805.814A4D90-- ------_=_NextPart_000_01C41805.814A4D90-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Fri Apr 2 03:14:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28001 for ; Fri, 2 Apr 2004 03:14:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9EAO-0006ch-M1 for aaa-archive@odin.ietf.org; Thu, 01 Apr 2004 21:12:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i322CKcm025454 for aaa-archive@odin.ietf.org; Thu, 1 Apr 2004 21:12:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9C93-0004VS-Ae for aaa-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 19:02:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11367 for ; Thu, 1 Apr 2004 19:02:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9C90-0005zS-00 for aaa-web-archive@ietf.org; Thu, 01 Apr 2004 19:02:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9C8D-0005rx-00 for aaa-web-archive@ietf.org; Thu, 01 Apr 2004 19:01:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9C7G-0005jW-00 for aaa-web-archive@ietf.org; Thu, 01 Apr 2004 19:00:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ABS-0007az-BO; Thu, 01 Apr 2004 16:57:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95m3-0001eM-Ll for aaa@optimus.ietf.org; Thu, 01 Apr 2004 12:14:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19352 for ; Thu, 1 Apr 2004 11:24:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94zE-0004Sb-00 for aaa@ietf.org; Thu, 01 Apr 2004 11:24:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94yI-0004Nj-00 for aaa@ietf.org; Thu, 01 Apr 2004 11:23:15 -0500 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1B94xZ-0004EJ-00 for aaa@ietf.org; Thu, 01 Apr 2004 11:22:29 -0500 Received: from exchange0.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Thu, 1 Apr 2004 17:16:30 +0200 Received: by sv3752.bonn.de with Internet Mail Service (5.5.2653.19) id <2CP1YBV7>; Thu, 1 Apr 2004 18:22:20 +0200 Message-ID: <1C2329C9430609409808ECF102372876FB8522@sv3752.bonn.de> From: Systemadministrator To: aaa@ietf.org Date: Thu, 1 Apr 2004 18:22:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C41805.814A4D90" Subject: [Aaa] Unzustellbar: fake Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C41805.814A4D90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: cxc@bonn.de Subject: fake Sent: Thu, 1 Apr 2004 18:10:41 +0200 did not reach the following recipient(s): cxc@bonn.de on Thu, 1 Apr 2004 18:22:08 +0200 Der Name des Empf=E4ngers wurde nicht erkannt. Die MTS-ID der urspr=FCnglichen Nachricht ist: c=3Dde;a=3D = ;p=3Dbundesstadt bonn;l=3DSV375204040116222CP1YBVM MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C41805.814A4D90 Content-Type: message/rfc822 From: aaa@ietf.org To: cxc@bonn.de Subject: fake Date: Thu, 1 Apr 2004 18:10:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C41805.814A4D90" ------_=_NextPart_002_01C41805.814A4D90 Content-Type: text/plain; charset="iso-8859-1" you are a bad writer ------_=_NextPart_002_01C41805.814A4D90 Content-Type: text/plain; name="InterScan_SafeStamp.txt" Content-Disposition: attachment; filename="InterScan_SafeStamp.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file msg.rtf.pif contains: WORM_NETSKY.B virus Attempted to clean the file but it is not cleanable. It has been deleted. Mail-Virus von Trend Micro Interscan Viruswall entdeckt und entfernt! ***************** End of message *************** ------_=_NextPart_002_01C41805.814A4D90-- ------_=_NextPart_000_01C41805.814A4D90-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Fri Apr 2 06:11:33 2004 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 GAA03660 for ; Fri, 2 Apr 2004 06:11:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 716C79122F; Fri, 2 Apr 2004 06:11:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3D38691230; Fri, 2 Apr 2004 06:11:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0E7759122F for ; Fri, 2 Apr 2004 06:11:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id E6E6A58E30; Fri, 2 Apr 2004 06:11:20 -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 2393358E25 for ; Fri, 2 Apr 2004 06:11:15 -0500 (EST) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32BAm814798; Fri, 2 Apr 2004 14:10:48 +0300 (EET DST) X-Scanned: Fri, 2 Apr 2004 14:08:58 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i32B8wm0015286; Fri, 2 Apr 2004 14:08:58 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00bFydqI; Fri, 02 Apr 2004 14:08:58 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32B8wF01935; Fri, 2 Apr 2004 14:08:58 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Apr 2004 14:08:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: RE: Proposed resolution of EAP issue 461: Alternate Uses and Conflicting AVPs Date: Fri, 2 Apr 2004 14:08:54 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61223BA@esebe023.ntc.nokia.com> Thread-Topic: Proposed resolution of EAP issue 461: Alternate Uses and Conflicting AVPs Thread-Index: AcQXjFqbjqZikg+sQDSn0fxyAAGkcwBFJTmg From: To: , X-OriginalArrivalTime: 02 Apr 2004 11:08:55.0018 (UTC) FILETIME=[E348BCA0:01C418A2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Joseph Salowey wrote: > [Joe] Not all lower layers behave consistently. Perhaps we > need to better describe the potential problems with how the > lower layers behave and make recommendation upon that. I > included a modification to text below also including EAP > message modification text that aligns more closely with 3579. >=20 > "A Diameter-EAP-Answer message containing an EAP-Payload of > type EAP-Success or EAP-Failure MUST NOT have the Result-Code > AVP set to DIAMETER_MULTI_ROUND_AUTH. =20 >=20 > When used with lower layers that treat authentication as=20 > sufficient for authorization the Result-Code should match=20 > the contained EAP packet: a successful Result-Code > for EAP-Success, and a failure Result-Code for=20 > EAP-Failure. In this case=20 > when the encapsulated EAP packet does not match the result > implied by the Result-Code AVP, the combination is likely to > cause confusion, because the NAS and peer will arrive at > different conclusions as to the outcome of the > authentication. For example, if the NAS receives a failure > Result-Code with an encapsulated EAP Success, it will not > grant access to the peer. However, on receiving the EAP > Success, the peer will be lead to believe that it > authenticated successfully. >=20 > This situation can be difficult to avoid when Diameter proxy > agents make authorization decisions (that is, proxies can > change the Result-Code AVP sent by the home server), or when > Diameter is used for communicating with a backend > authentication server (see Section 2.8.5). Since the=20 > responsibility for avoiding conflicts lies with the Diameter > server, the NAS MUST NOT "manufacture" EAP result packets=20 > in order to correct contradictory messages that it receives. =20 > This behavior, originally mandated within [IEEE8021X],=20 > will be deprecated in the future." =20 Looks good! Maybe the 2nd paragraph could be still clarified, since EAP Success also includes some=20 authorization aspects. How about this? "Some lower layers assume that the authorization decision is made by the EAP server, and thus the peer considers EAP Success as an indication that access was granted. In this case, the Result-Code SHOULD match the contained EAP packet: a successful Result-Code for EAP-Success, and a failure Result-Code for EAP-Failure. If the encapsulated EAP packet does not match the result implied by the Result-Code AVP, the combination is likely to cause confusion, because the NAS and peer will arrive at different conclusions as to the outcome of the authentication. For example, if the NAS receives a failure Result-Code with an encapsulated EAP Success, it will not grant access to the peer. However, on receiving the EAP Success, the peer will be lead to believe that access was granted." Cheers, Pasi From owner-aaa-wg@merit.edu Fri Apr 2 11:01:35 2004 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 LAA15792 for ; Fri, 2 Apr 2004 11:01:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 80A4591237; Fri, 2 Apr 2004 11:01:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 547FC91239; Fri, 2 Apr 2004 11:01:23 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EB40491237 for ; Fri, 2 Apr 2004 11:01:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id D395B58569; Fri, 2 Apr 2004 11:01:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by segue.merit.edu (Postfix) with ESMTP id 8A7DF5856A for ; Fri, 2 Apr 2004 11:01:21 -0500 (EST) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 02 Apr 2004 08:01:47 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i32G1Iew029828; Fri, 2 Apr 2004 08:01:18 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.225.131]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 2 Apr 2004 08:07:51 -0800 From: "Joseph Salowey" To: , Subject: [AAA-WG]: RE: Proposed resolution of EAP issue 461: Alternate Uses and Conflicting AVPs Date: Fri, 2 Apr 2004 08:01:16 -0800 Message-ID: <004101c418cb$bb93cd70$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61223BA@esebe023.ntc.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 02 Apr 2004 16:07:51.0315 (UTC) FILETIME=[A6267630:01C418CC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Joseph Salowey wrote: > >> [Joe] Not all lower layers behave consistently. Perhaps we need to >> better describe the potential problems with how the lower layers >> behave and make recommendation upon that. I included a modification >> to text below also including EAP message modification text that >> aligns more closely with 3579. >> > >> "A Diameter-EAP-Answer message containing an EAP-Payload of >> type EAP-Success or EAP-Failure MUST NOT have the Result-Code >> AVP set to DIAMETER_MULTI_ROUND_AUTH. >> >> When used with lower layers that treat authentication as >> sufficient for authorization the Result-Code should match >> the contained EAP packet: a successful Result-Code >> for EAP-Success, and a failure Result-Code for >> EAP-Failure. In this case >> when the encapsulated EAP packet does not match the result >> implied by the Result-Code AVP, the combination is likely to >> cause confusion, because the NAS and peer will arrive at >> different conclusions as to the outcome of the >> authentication. For example, if the NAS receives a failure >> Result-Code with an encapsulated EAP Success, it will not >> grant access to the peer. However, on receiving the EAP >> Success, the peer will be lead to believe that it >> authenticated successfully. >> >> This situation can be difficult to avoid when Diameter proxy >> agents make authorization decisions (that is, proxies can >> change the Result-Code AVP sent by the home server), or when >> Diameter is used for communicating with a backend >> authentication server (see Section 2.8.5). Since the >> responsibility for avoiding conflicts lies with the Diameter >> server, the NAS MUST NOT "manufacture" EAP result packets >> in order to correct contradictory messages that it receives. >> This behavior, originally mandated within [IEEE8021X], >> will be deprecated in the future." > > Looks good! Maybe the 2nd paragraph could be still > clarified, since EAP Success also includes some > authorization aspects. How about this? > > "Some lower layers assume that the authorization decision is > made by the EAP server, and thus the peer considers EAP > Success as an indication that access was granted. In this > case, the Result-Code SHOULD match the contained EAP packet: > a successful Result-Code for EAP-Success, and a failure > Result-Code for EAP-Failure. If the encapsulated EAP packet > does not match the result implied by the Result-Code AVP, the > combination is likely to cause confusion, because the NAS and > peer will arrive at different conclusions as to the outcome > of the authentication. For example, if the NAS receives a > failure Result-Code with an encapsulated EAP Success, it will > not grant access to the peer. However, on receiving the EAP > Success, the peer will be lead to believe that access was > granted." > [Joe] I think this looks good. > Cheers, > Pasi From aaa-admin@ietf.org Sat Apr 3 08:39:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20411 for ; Sat, 3 Apr 2004 08:39:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9lMU-00069F-KE; Sat, 03 Apr 2004 08:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9lMS-00068W-2x for aaa@optimus.ietf.org; Sat, 03 Apr 2004 08:39:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20381 for ; Sat, 3 Apr 2004 08:38:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9lMQ-0006HF-00 for aaa@ietf.org; Sat, 03 Apr 2004 08:38:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9lLS-00067B-00 for aaa@ietf.org; Sat, 03 Apr 2004 08:37:59 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9lKz-0005zF-00 for aaa@ietf.org; Sat, 03 Apr 2004 08:37:29 -0500 Received: from [216.207.212.170] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1B9lKy-0000oO-HP for aaa@ietf.org; Sat, 03 Apr 2004 08:37:30 -0500 Received: from 208.40.62.52 by 216.207.212.170; Sat, 03 Apr 2004 08:35:18 -0500 Message-ID: From: "Sherman Rios" Reply-To: "Sherman Rios" To: aaa@ietf.org Date: Sat, 03 Apr 2004 18:37:18 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--8901213887343963" X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.1 required=5.0 tests=BIZ_TLD,FORGED_RCVD_NET_HELO, HTML_30_40,HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts Subject: [Aaa] Enjoy life, don't work Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , ----8901213887343963 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable mass ohio mustachio disperse flocculate centigrade charley brendan = clumsy columnar irreplaceable peanut airedale transcendent schoolmaster gu= les circumferential cynthia vanquish hireling dunn apart ravel emphysema h= otrod gerbil lamellar inoffensive dogtrot nicety oppression simpson=20</ti= tle> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859= -1"> </head> <body> <p> </p> <p><a href=3D"http://www.f0reverhealthy.biz/ggl.html">Cash in with Google</a> makes earning an affiliate income very simple. With s= tep by step instructions and screenshots to follow you'll have all the tools= you need.</p> <p></p> <p><font size=3D"2">no more <a href=3D"http://www.f0reverhealthy.biz/takeo= ff/takeoff.html">emails</a> please </font></p> </body> </html> ----8901213887343963-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sat Apr 3 08:40:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20464 for <aaa-archive@odin.ietf.org>; Sat, 3 Apr 2004 08:40:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9lNq-0006gQ-K9 for aaa-archive@odin.ietf.org; Sat, 03 Apr 2004 08:40:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i33DeQZZ025691 for aaa-archive@odin.ietf.org; Sat, 3 Apr 2004 08:40:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9lNq-0006gI-Fe for aaa-web-archive@optimus.ietf.org; Sat, 03 Apr 2004 08:40:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20453 for <aaa-web-archive@ietf.org>; Sat, 3 Apr 2004 08:40:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9lNp-0006YG-00 for aaa-web-archive@ietf.org; Sat, 03 Apr 2004 08:40:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9lMc-0006JI-00 for aaa-web-archive@ietf.org; Sat, 03 Apr 2004 08:39:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9lMU-00069F-KE; Sat, 03 Apr 2004 08:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9lMS-00068W-2x for aaa@optimus.ietf.org; Sat, 03 Apr 2004 08:39:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20381 for <aaa@ietf.org>; Sat, 3 Apr 2004 08:38:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9lMQ-0006HF-00 for aaa@ietf.org; Sat, 03 Apr 2004 08:38:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9lLS-00067B-00 for aaa@ietf.org; Sat, 03 Apr 2004 08:37:59 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9lKz-0005zF-00 for aaa@ietf.org; Sat, 03 Apr 2004 08:37:29 -0500 Received: from [216.207.212.170] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1B9lKy-0000oO-HP for aaa@ietf.org; Sat, 03 Apr 2004 08:37:30 -0500 Received: from 208.40.62.52 by 216.207.212.170; Sat, 03 Apr 2004 08:35:18 -0500 Message-ID: <LBBFHSUWUYPUXECAXYDLNBV@uni-koblenz-landau.de> From: "Sherman Rios" <VXBYNRZFGXLYI@campus.ruv.itesm.mx> Reply-To: "Sherman Rios" <VXBYNRZFGXLYI@campus.ruv.itesm.mx> To: aaa@ietf.org Date: Sat, 03 Apr 2004 18:37:18 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--8901213887343963" X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.1 required=5.0 tests=BIZ_TLD,FORGED_RCVD_NET_HELO, HTML_30_40,HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts Subject: [Aaa] Enjoy life, don't work Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=unsubscribe> List-Id: Authentication, Authorization and Accounting <aaa.ietf.org> List-Post: <mailto:aaa@ietf.org> List-Help: <mailto:aaa-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=subscribe> ----8901213887343963 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable <html> <head> <title>mass ohio mustachio disperse flocculate centigrade charley brendan = clumsy columnar irreplaceable peanut airedale transcendent schoolmaster gu= les circumferential cynthia vanquish hireling dunn apart ravel emphysema h= otrod gerbil lamellar inoffensive dogtrot nicety oppression simpson=20</ti= tle> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859= -1"> </head> <body> <p> </p> <p><a href=3D"http://www.f0reverhealthy.biz/ggl.html">Cash in with Google</a> makes earning an affiliate income very simple. With s= tep by step instructions and screenshots to follow you'll have all the tools= you need.</p> <p></p> <p><font size=3D"2">no more <a href=3D"http://www.f0reverhealthy.biz/takeo= ff/takeoff.html">emails</a> please </font></p> </body> </html> ----8901213887343963-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Sat Apr 3 15:41:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03568 for <aaa-archive@lists.ietf.org>; Sat, 3 Apr 2004 15:41:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9rwr-0004Mb-J4; Sat, 03 Apr 2004 15:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9rvy-00043e-Pm for aaa@optimus.ietf.org; Sat, 03 Apr 2004 15:40:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03532 for <aaa@ietf.org>; Sat, 3 Apr 2004 15:40:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9rvx-0001AX-00 for aaa@ietf.org; Sat, 03 Apr 2004 15:40:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9rv3-00014H-00 for aaa@ietf.org; Sat, 03 Apr 2004 15:39:10 -0500 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1B9rua-0000w5-00 for aaa@ietf.org; Sat, 03 Apr 2004 15:38:40 -0500 Received: from exchange0.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Sat, 3 Apr 2004 21:32:41 +0200 Received: by sv3752.bonn.de with Internet Mail Service (5.5.2653.19) id <2CP16X5W>; Sat, 3 Apr 2004 22:38:43 +0200 Message-ID: <1C2329C9430609409808ECF1023728760116D9F3@sv3752.bonn.de> From: Systemadministrator <postmaster@Bonn.de> To: aaa@ietf.org Date: Sat, 3 Apr 2004 22:38:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C419BB.A72A0386" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Aaa] Unzustellbar: hello Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=unsubscribe> List-Id: Authentication, Authorization and Accounting <aaa.ietf.org> List-Post: <mailto:aaa@ietf.org> List-Help: <mailto:aaa-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=subscribe> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C419BB.A72A0386 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: aqv@bonn.de Subject: hello Sent: Sat, 3 Apr 2004 21:50:23 +0200 did not reach the following recipient(s): aqv@bonn.de on Sat, 3 Apr 2004 22:38:40 +0200 Der Name des Empf=E4ngers wurde nicht erkannt. Die MTS-ID der urspr=FCnglichen Nachricht ist: c=3Dde;a=3D = ;p=3Dbundesstadt bonn;l=3DSV375204040320382CP16X5S MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C419BB.A72A0386 Content-Type: message/rfc822 From: aaa@ietf.org To: aqv@bonn.de Subject: hello Date: Sat, 3 Apr 2004 21:50:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C419BB.A72A0386" ------_=_NextPart_002_01C419BB.A72A0386 Content-Type: text/plain; charset="iso-8859-1" i found this document about you ------_=_NextPart_002_01C419BB.A72A0386 Content-Type: text/plain; name="InterScan_SafeStamp.txt" Content-Disposition: attachment; filename="InterScan_SafeStamp.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file doc.zip contains: WORM_NETSKY.B virus in compressed file doc.htm.scr Attempted to clean the file but it is not cleanable. It has been deleted. Mail-Virus von Trend Micro Interscan Viruswall entdeckt und entfernt! ***************** End of message *************** ------_=_NextPart_002_01C419BB.A72A0386-- ------_=_NextPart_000_01C419BB.A72A0386-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sat Apr 3 15:43:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03631 for <aaa-archive@odin.ietf.org>; Sat, 3 Apr 2004 15:43:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ryo-00053R-6L for aaa-archive@odin.ietf.org; Sat, 03 Apr 2004 15:43:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i33Kh2hS019430 for aaa-archive@odin.ietf.org; Sat, 3 Apr 2004 15:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ryo-00053J-2g for aaa-web-archive@optimus.ietf.org; Sat, 03 Apr 2004 15:43:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03619 for <aaa-web-archive@ietf.org>; Sat, 3 Apr 2004 15:42:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9rym-0001UZ-00 for aaa-web-archive@ietf.org; Sat, 03 Apr 2004 15:43:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9rxq-0001O2-00 for aaa-web-archive@ietf.org; Sat, 03 Apr 2004 15:42:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9rwt-0001H9-00 for aaa-web-archive@ietf.org; Sat, 03 Apr 2004 15:41:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9rwr-0004Mb-J4; Sat, 03 Apr 2004 15:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9rvy-00043e-Pm for aaa@optimus.ietf.org; Sat, 03 Apr 2004 15:40:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03532 for <aaa@ietf.org>; Sat, 3 Apr 2004 15:40:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9rvx-0001AX-00 for aaa@ietf.org; Sat, 03 Apr 2004 15:40:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9rv3-00014H-00 for aaa@ietf.org; Sat, 03 Apr 2004 15:39:10 -0500 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1B9rua-0000w5-00 for aaa@ietf.org; Sat, 03 Apr 2004 15:38:40 -0500 Received: from exchange0.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Sat, 3 Apr 2004 21:32:41 +0200 Received: by sv3752.bonn.de with Internet Mail Service (5.5.2653.19) id <2CP16X5W>; Sat, 3 Apr 2004 22:38:43 +0200 Message-ID: <1C2329C9430609409808ECF1023728760116D9F3@sv3752.bonn.de> From: Systemadministrator <postmaster@Bonn.de> To: aaa@ietf.org Date: Sat, 3 Apr 2004 22:38:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C419BB.A72A0386" Subject: [Aaa] Unzustellbar: hello Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=unsubscribe> List-Id: Authentication, Authorization and Accounting <aaa.ietf.org> List-Post: <mailto:aaa@ietf.org> List-Help: <mailto:aaa-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=subscribe> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C419BB.A72A0386 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: aqv@bonn.de Subject: hello Sent: Sat, 3 Apr 2004 21:50:23 +0200 did not reach the following recipient(s): aqv@bonn.de on Sat, 3 Apr 2004 22:38:40 +0200 Der Name des Empf=E4ngers wurde nicht erkannt. Die MTS-ID der urspr=FCnglichen Nachricht ist: c=3Dde;a=3D = ;p=3Dbundesstadt bonn;l=3DSV375204040320382CP16X5S MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C419BB.A72A0386 Content-Type: message/rfc822 From: aaa@ietf.org To: aqv@bonn.de Subject: hello Date: Sat, 3 Apr 2004 21:50:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C419BB.A72A0386" ------_=_NextPart_002_01C419BB.A72A0386 Content-Type: text/plain; charset="iso-8859-1" i found this document about you ------_=_NextPart_002_01C419BB.A72A0386 Content-Type: text/plain; name="InterScan_SafeStamp.txt" Content-Disposition: attachment; filename="InterScan_SafeStamp.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file doc.zip contains: WORM_NETSKY.B virus in compressed file doc.htm.scr Attempted to clean the file but it is not cleanable. It has been deleted. Mail-Virus von Trend Micro Interscan Viruswall entdeckt und entfernt! ***************** End of message *************** ------_=_NextPart_002_01C419BB.A72A0386-- ------_=_NextPart_000_01C419BB.A72A0386-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Sat Apr 3 17:18:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07999 for <aaa-archive@lists.ietf.org>; Sat, 3 Apr 2004 17:18:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9tSj-00067k-PY; Sat, 03 Apr 2004 17:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9tSV-00063C-SN for aaa@optimus.ietf.org; Sat, 03 Apr 2004 17:17:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07841 for <aaa@ietf.org>; Sat, 3 Apr 2004 17:17:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9tST-0005Y8-00 for aaa@ietf.org; Sat, 03 Apr 2004 17:17:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9tR6-0005Hz-00 for aaa@ietf.org; Sat, 03 Apr 2004 17:16:21 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9tQX-0005A0-00 for aaa@ietf.org; Sat, 03 Apr 2004 17:15:45 -0500 Received: from [61.97.211.206] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1B9tHL-0004gi-Bk for aaa@ietf.org; Sat, 03 Apr 2004 17:06:15 -0500 Received: from 70.2.129.104 by 61.97.211.206; Sat, 03 Apr 2004 17:06:48 -0500 Message-ID: <MNHSONASOHMHDBOSSUOUKUXBS@beograd.com> From: "Russell Farmer" <onsuq@3web.net> Reply-To: "Russell Farmer" <onsuq@3web.net> To: aaa@ietf.org Date: Sat, 03 Apr 2004 17:59:48 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--8243101268599474" X-Webmail-Time: Sun, 04 Apr 2004 00:02:48 +0200 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.6 required=5.0 tests=BIZ_TLD,FORGED_RCVD_NET_HELO, HTML_20_30,HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts Subject: [Aaa] Get all meds here. Any Pills You Want. No prescription. Discreet. Secure Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=unsubscribe> List-Id: Authentication, Authorization and Accounting <aaa.ietf.org> List-Post: <mailto:aaa@ietf.org> List-Help: <mailto:aaa-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=subscribe> ----8243101268599474 Content-Type: text/html; Content-Transfer-Encoding: 7Bit <html><head><style type="text/css"><!-- .style5 {font-family: Arial, Helvetica, sans-serif; font-size: 14px; } .style6 {font-size: 10px} --></style> <p class="style5">Hel</aggravate>lo,</p> <p><span class="style5"><strong>Ch</worsen>eapestM</capacious>eds</strong> - yo</bravo>ur Sou</cotta>rce for best prices <strong>Presc</apollonian>ription Dr</bustle>ugs</strong><b>.</b></span></p> <p class="style5"><strong>Abs</poetic>olutely No Doct</abrasion>or App</humerus>ointment Need</begetting>ed!</strong> </p> <p class="style5">Ord</precision>ers appro</chaste>ved by <b>2 pm E</portray>ST</b> will rec</sellout>eive their me</godson>dica</remunerate>tion <b>next busin</venetian>ess</b> day <b> via Fed</republican>EX</b>! (wh</obverse>ere availa</optometry>ble) </p> <p class="style5"><a href="http://www.roberts.look964medications.biz/g17/"><b>Con</guanine>nect wi</osteopath>th the So</elite>urce. Ge</shrink>t it He</sculpt>re </b></a></p> <p style="font-size:0px; color:white" align="left">Binvention barre embed butterfat implore monmouth mutuel calamus escape hom indecent accent diddle jowly domestic keynesian ? Sboyfriend domenico sunder fe kirkpatrick broody boris headsmen adequate assay friable contagion megawatt dichondra mechanism !!! Iain't bestowal lourdes patty coffeepot telephony choirmaster pudding lazy roy gershwin astoria cranky bromide depositor brandon accretion stun scarborough aphelion hafnium clockwatcher amigo ascension application horsepower circumference abbey bewitch diagnose titrate ecole maim benedikt rackety astrophysicist thatch maximal vitro chandelier housewares teammate typewrite hydronium bellboy effie litigate marie drown haag broach ministry sequestration jitter fatuous pianist hypocrisy matriculate committee .Lafghan birch boulder deferrable sunburn deniable bookie sherman macromolecular !! Efissile fourfold synthesis tyranny navigable sharpen ballot frozen assuage threshold c! lang fact blest diagnose marsh septillion asleep coronate pinpoint rummage ! Earlene cessation morocco nocturne standpoint kate psychophysiology willa chaw stank leadsmen depart emigrant buoyant downriver transliterate hesitant physiology salty fiscal colloidal nutria anxiety cumbersome traumatic credo range dearie joule bewilder ornately acquisitive vigilante cardinal travelogue Twingtip integument ornately darling armada electrolysis epicure ? Vtank die extraterrestrial thomistic expurgate maurine doll explanatory hearty assault delilah monetary vigilant wasteful jo spot afro haze staley . Copium cardiac fraser burp cry impermissible copenhagen bevy placental famous granville radium winslow topology triceratops paramedic clam sidelight homozygous civet abidjan eager mccoy eveready persecutory gentile brae cardiod rhubarb stave bruise view hayden obscene climatic gentleman pay onrushing hadrian use electoral bernice deck myocardium woodbury scornful glamour godwit novosi! birsk p's smooth tip compressible neuter fake .Abronchitis memorial co mmittal criminal ah watchdog wichita fox dot hepburn crucifixion johansen drape lee coleridge encryption cochrane alkane blackball demean boylston dyad . Ilandlord arachne pa waterbury !!! Sunivariate crew oust hub intimacy layout nrc madmen mighty mustn't beaux caviar .Vamid wreak alumni el yellow camellia spleenwort decant nurse clothesline bar ? Gpiecewise del artistry mesopotamia indict confocal meson thrill alabaster tomlinson trestle dine chronology rica varsity chipmunk . Fcrappie demit couch build terrible suave control porcupine kennel mortify arena domenico sawfish viewpoint choosy budweiser antelope gary controlling symptom graduate servile silverware pseudo cerium composite pesticide late deputation teacart alewife billiken coastline fifty camel respond sherwin teal buttock eben balsam necromancy cress varitype worst brooklyn doormen inferential nerve ounce roam propellant insurgent adkins censorial establish maynard .</p> <P align="LEFT"><FONT COLOR="#616161" SIZE="-2" FACE="Arial">I</hooligan>f th</crony>is no</differ>tice has rea</lymph>ched y</blandish>ou in er</mollify>ror, ple</lo>ase not</sapling>ify us by</FONT><FONT COLOR="#d5d5d0" SIZE="-2" FACE="Arial"> </FONT><FONT SIZE="-2" FACE="Arial"><A HREF="http://www.eloise.look964medications.biz/unsubscribe.ddd">clic</westfield>king he</strauss>re</A></FONT> </html> ----8243101268599474-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sat Apr 3 17:19:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08083 for <aaa-archive@odin.ietf.org>; Sat, 3 Apr 2004 17:19:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9tTo-0006UJ-N3 for aaa-archive@odin.ietf.org; Sat, 03 Apr 2004 17:19:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i33MJ8ke024940 for aaa-archive@odin.ietf.org; Sat, 3 Apr 2004 17:19:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9tTo-0006UB-25 for aaa-web-archive@optimus.ietf.org; Sat, 03 Apr 2004 17:19:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08026 for <aaa-web-archive@ietf.org>; Sat, 3 Apr 2004 17:19:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9tTl-0005rA-00 for aaa-web-archive@ietf.org; Sat, 03 Apr 2004 17:19:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9tSl-0005cl-00 for aaa-web-archive@ietf.org; Sat, 03 Apr 2004 17:18:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9tSj-00067k-PY; Sat, 03 Apr 2004 17:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9tSV-00063C-SN for aaa@optimus.ietf.org; Sat, 03 Apr 2004 17:17:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07841 for <aaa@ietf.org>; Sat, 3 Apr 2004 17:17:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9tST-0005Y8-00 for aaa@ietf.org; Sat, 03 Apr 2004 17:17:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9tR6-0005Hz-00 for aaa@ietf.org; Sat, 03 Apr 2004 17:16:21 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9tQX-0005A0-00 for aaa@ietf.org; Sat, 03 Apr 2004 17:15:45 -0500 Received: from [61.97.211.206] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1B9tHL-0004gi-Bk for aaa@ietf.org; Sat, 03 Apr 2004 17:06:15 -0500 Received: from 70.2.129.104 by 61.97.211.206; Sat, 03 Apr 2004 17:06:48 -0500 Message-ID: <MNHSONASOHMHDBOSSUOUKUXBS@beograd.com> From: "Russell Farmer" <onsuq@3web.net> Reply-To: "Russell Farmer" <onsuq@3web.net> To: aaa@ietf.org Date: Sat, 03 Apr 2004 17:59:48 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--8243101268599474" X-Webmail-Time: Sun, 04 Apr 2004 00:02:48 +0200 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.6 required=5.0 tests=BIZ_TLD,FORGED_RCVD_NET_HELO, HTML_20_30,HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts Subject: [Aaa] Get all meds here. Any Pills You Want. No prescription. Discreet. Secure Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=unsubscribe> List-Id: Authentication, Authorization and Accounting <aaa.ietf.org> List-Post: <mailto:aaa@ietf.org> List-Help: <mailto:aaa-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=subscribe> ----8243101268599474 Content-Type: text/html; Content-Transfer-Encoding: 7Bit <html><head><style type="text/css"><!-- .style5 {font-family: Arial, Helvetica, sans-serif; font-size: 14px; } .style6 {font-size: 10px} --></style> <p class="style5">Hel</aggravate>lo,</p> <p><span class="style5"><strong>Ch</worsen>eapestM</capacious>eds</strong> - yo</bravo>ur Sou</cotta>rce for best prices <strong>Presc</apollonian>ription Dr</bustle>ugs</strong><b>.</b></span></p> <p class="style5"><strong>Abs</poetic>olutely No Doct</abrasion>or App</humerus>ointment Need</begetting>ed!</strong> </p> <p class="style5">Ord</precision>ers appro</chaste>ved by <b>2 pm E</portray>ST</b> will rec</sellout>eive their me</godson>dica</remunerate>tion <b>next busin</venetian>ess</b> day <b> via Fed</republican>EX</b>! (wh</obverse>ere availa</optometry>ble) </p> <p class="style5"><a href="http://www.roberts.look964medications.biz/g17/"><b>Con</guanine>nect wi</osteopath>th the So</elite>urce. Ge</shrink>t it He</sculpt>re </b></a></p> <p style="font-size:0px; color:white" align="left">Binvention barre embed butterfat implore monmouth mutuel calamus escape hom indecent accent diddle jowly domestic keynesian ? Sboyfriend domenico sunder fe kirkpatrick broody boris headsmen adequate assay friable contagion megawatt dichondra mechanism !!! Iain't bestowal lourdes patty coffeepot telephony choirmaster pudding lazy roy gershwin astoria cranky bromide depositor brandon accretion stun scarborough aphelion hafnium clockwatcher amigo ascension application horsepower circumference abbey bewitch diagnose titrate ecole maim benedikt rackety astrophysicist thatch maximal vitro chandelier housewares teammate typewrite hydronium bellboy effie litigate marie drown haag broach ministry sequestration jitter fatuous pianist hypocrisy matriculate committee .Lafghan birch boulder deferrable sunburn deniable bookie sherman macromolecular !! Efissile fourfold synthesis tyranny navigable sharpen ballot frozen assuage threshold c! lang fact blest diagnose marsh septillion asleep coronate pinpoint rummage ! Earlene cessation morocco nocturne standpoint kate psychophysiology willa chaw stank leadsmen depart emigrant buoyant downriver transliterate hesitant physiology salty fiscal colloidal nutria anxiety cumbersome traumatic credo range dearie joule bewilder ornately acquisitive vigilante cardinal travelogue Twingtip integument ornately darling armada electrolysis epicure ? Vtank die extraterrestrial thomistic expurgate maurine doll explanatory hearty assault delilah monetary vigilant wasteful jo spot afro haze staley . Copium cardiac fraser burp cry impermissible copenhagen bevy placental famous granville radium winslow topology triceratops paramedic clam sidelight homozygous civet abidjan eager mccoy eveready persecutory gentile brae cardiod rhubarb stave bruise view hayden obscene climatic gentleman pay onrushing hadrian use electoral bernice deck myocardium woodbury scornful glamour godwit novosi! birsk p's smooth tip compressible neuter fake .Abronchitis memorial co mmittal criminal ah watchdog wichita fox dot hepburn crucifixion johansen drape lee coleridge encryption cochrane alkane blackball demean boylston dyad . Ilandlord arachne pa waterbury !!! Sunivariate crew oust hub intimacy layout nrc madmen mighty mustn't beaux caviar .Vamid wreak alumni el yellow camellia spleenwort decant nurse clothesline bar ? Gpiecewise del artistry mesopotamia indict confocal meson thrill alabaster tomlinson trestle dine chronology rica varsity chipmunk . Fcrappie demit couch build terrible suave control porcupine kennel mortify arena domenico sawfish viewpoint choosy budweiser antelope gary controlling symptom graduate servile silverware pseudo cerium composite pesticide late deputation teacart alewife billiken coastline fifty camel respond sherwin teal buttock eben balsam necromancy cress varitype worst brooklyn doormen inferential nerve ounce roam propellant insurgent adkins censorial establish maynard .</p> <P align="LEFT"><FONT COLOR="#616161" SIZE="-2" FACE="Arial">I</hooligan>f th</crony>is no</differ>tice has rea</lymph>ched y</blandish>ou in er</mollify>ror, ple</lo>ase not</sapling>ify us by</FONT><FONT COLOR="#d5d5d0" SIZE="-2" FACE="Arial"> </FONT><FONT SIZE="-2" FACE="Arial"><A HREF="http://www.eloise.look964medications.biz/unsubscribe.ddd">clic</westfield>king he</strauss>re</A></FONT> </html> ----8243101268599474-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Sat Apr 3 18:39:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11443 for <aaa-archive@lists.ietf.org>; Sat, 3 Apr 2004 18:39:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9uj7-0006qU-Ok; Sat, 03 Apr 2004 18:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9uiY-0006oi-4J for aaa@optimus.ietf.org; Sat, 03 Apr 2004 18:38:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11409 for <aaa@ietf.org>; Sat, 3 Apr 2004 18:38:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9uiV-0006Zs-00 for aaa@ietf.org; Sat, 03 Apr 2004 18:38:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9uhf-0006Sn-00 for aaa@ietf.org; Sat, 03 Apr 2004 18:37:32 -0500 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1B9ugt-0006JM-00 for aaa@ietf.org; Sat, 03 Apr 2004 18:36:43 -0500 Received: from exchange0.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Sun, 4 Apr 2004 00:30:44 +0200 Received: by sv3752.bonn.de with Internet Mail Service (5.5.2653.19) id <2CP17AJQ>; Sun, 4 Apr 2004 01:36:46 +0200 Message-ID: <1C2329C9430609409808ECF10237287601177DC3@sv3752.bonn.de> From: Systemadministrator <postmaster@Bonn.de> To: aaa@ietf.org Date: Sun, 4 Apr 2004 01:36:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C419D4.8712AA08" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Aaa] Unzustellbar: fake Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=unsubscribe> List-Id: Authentication, Authorization and Accounting <aaa.ietf.org> List-Post: <mailto:aaa@ietf.org> List-Help: <mailto:aaa-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=subscribe> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C419D4.8712AA08 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: err@bonn.de Subject: fake Sent: Sun, 4 Apr 2004 01:26:13 +0200 did not reach the following recipient(s): err@bonn.de on Sun, 4 Apr 2004 01:36:42 +0200 Der Name des Empf=E4ngers wurde nicht erkannt. Die MTS-ID der urspr=FCnglichen Nachricht ist: c=3Dde;a=3D = ;p=3Dbundesstadt bonn;l=3DSV375204040323362CP17AJL MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C419D4.8712AA08 Content-Type: message/rfc822 From: aaa@ietf.org To: err@bonn.de Subject: fake Date: Sun, 4 Apr 2004 01:26:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C419D4.8712AA08" ------_=_NextPart_002_01C419D4.8712AA08 Content-Type: text/plain; charset="iso-8859-1" that's funny ------_=_NextPart_002_01C419D4.8712AA08 Content-Type: text/plain; name="InterScan_SafeStamp.txt" Content-Disposition: attachment; filename="InterScan_SafeStamp.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file nomoney.pif contains: WORM_NETSKY.B virus Attempted to clean the file but it is not cleanable. It has been deleted. Mail-Virus von Trend Micro Interscan Viruswall entdeckt und entfernt! ***************** End of message *************** ------_=_NextPart_002_01C419D4.8712AA08-- ------_=_NextPart_000_01C419D4.8712AA08-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sat Apr 3 18:41:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11506 for <aaa-archive@odin.ietf.org>; Sat, 3 Apr 2004 18:41:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ulB-0007Gh-Bd for aaa-archive@odin.ietf.org; Sat, 03 Apr 2004 18:41:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i33Nf9ia027940 for aaa-archive@odin.ietf.org; Sat, 3 Apr 2004 18:41:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ulB-0007GZ-6Z for aaa-web-archive@optimus.ietf.org; Sat, 03 Apr 2004 18:41:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11500 for <aaa-web-archive@ietf.org>; Sat, 3 Apr 2004 18:41:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9ul8-0006tk-00 for aaa-web-archive@ietf.org; Sat, 03 Apr 2004 18:41:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9uk9-0006mA-00 for aaa-web-archive@ietf.org; Sat, 03 Apr 2004 18:40:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9uj9-0006aM-00 for aaa-web-archive@ietf.org; Sat, 03 Apr 2004 18:39:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9uj7-0006qU-Ok; Sat, 03 Apr 2004 18:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9uiY-0006oi-4J for aaa@optimus.ietf.org; Sat, 03 Apr 2004 18:38:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11409 for <aaa@ietf.org>; Sat, 3 Apr 2004 18:38:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9uiV-0006Zs-00 for aaa@ietf.org; Sat, 03 Apr 2004 18:38:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9uhf-0006Sn-00 for aaa@ietf.org; Sat, 03 Apr 2004 18:37:32 -0500 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1B9ugt-0006JM-00 for aaa@ietf.org; Sat, 03 Apr 2004 18:36:43 -0500 Received: from exchange0.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Sun, 4 Apr 2004 00:30:44 +0200 Received: by sv3752.bonn.de with Internet Mail Service (5.5.2653.19) id <2CP17AJQ>; Sun, 4 Apr 2004 01:36:46 +0200 Message-ID: <1C2329C9430609409808ECF10237287601177DC3@sv3752.bonn.de> From: Systemadministrator <postmaster@Bonn.de> To: aaa@ietf.org Date: Sun, 4 Apr 2004 01:36:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C419D4.8712AA08" Subject: [Aaa] Unzustellbar: fake Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=unsubscribe> List-Id: Authentication, Authorization and Accounting <aaa.ietf.org> List-Post: <mailto:aaa@ietf.org> List-Help: <mailto:aaa-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=subscribe> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C419D4.8712AA08 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: err@bonn.de Subject: fake Sent: Sun, 4 Apr 2004 01:26:13 +0200 did not reach the following recipient(s): err@bonn.de on Sun, 4 Apr 2004 01:36:42 +0200 Der Name des Empf=E4ngers wurde nicht erkannt. Die MTS-ID der urspr=FCnglichen Nachricht ist: c=3Dde;a=3D = ;p=3Dbundesstadt bonn;l=3DSV375204040323362CP17AJL MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C419D4.8712AA08 Content-Type: message/rfc822 From: aaa@ietf.org To: err@bonn.de Subject: fake Date: Sun, 4 Apr 2004 01:26:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C419D4.8712AA08" ------_=_NextPart_002_01C419D4.8712AA08 Content-Type: text/plain; charset="iso-8859-1" that's funny ------_=_NextPart_002_01C419D4.8712AA08 Content-Type: text/plain; name="InterScan_SafeStamp.txt" Content-Disposition: attachment; filename="InterScan_SafeStamp.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file nomoney.pif contains: WORM_NETSKY.B virus Attempted to clean the file but it is not cleanable. It has been deleted. Mail-Virus von Trend Micro Interscan Viruswall entdeckt und entfernt! ***************** End of message *************** ------_=_NextPart_002_01C419D4.8712AA08-- ------_=_NextPart_000_01C419D4.8712AA08-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Sat Apr 3 22:18:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16179 for <aaa-archive@lists.ietf.org>; Sat, 3 Apr 2004 22:18:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9y93-0002kX-62; Sat, 03 Apr 2004 22:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9y8M-0002bq-Vj for aaa@optimus.ietf.org; Sat, 03 Apr 2004 22:17:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16134 for <aaa@ietf.org>; Sat, 3 Apr 2004 22:17:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9y8J-0006nN-00 for aaa@ietf.org; Sat, 03 Apr 2004 22:17:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9y7N-0006hE-00 for aaa@ietf.org; Sat, 03 Apr 2004 22:16:17 -0500 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1B9y6v-0006bB-00 for aaa@ietf.org; Sat, 03 Apr 2004 22:15:49 -0500 Received: from exchange0.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Sun, 4 Apr 2004 04:09:50 +0200 Received: by sv3752.bonn.de with Internet Mail Service (5.5.2653.19) id <2CP17K3Z>; Sun, 4 Apr 2004 05:15:29 +0200 Message-ID: <1C2329C9430609409808ECF1023728760117D9BE@sv3752.bonn.de> From: Systemadministrator <postmaster@Bonn.de> To: aaa@ietf.org Date: Sun, 4 Apr 2004 05:15:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C419F3.144F81DE" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Aaa] Unzustellbar: fake Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=unsubscribe> List-Id: Authentication, Authorization and Accounting <aaa.ietf.org> List-Post: <mailto:aaa@ietf.org> List-Help: <mailto:aaa-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=subscribe> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C419F3.144F81DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: jea@bonn.de Subject: fake Sent: Sun, 4 Apr 2004 04:55:19 +0200 did not reach the following recipient(s): jea@bonn.de on Sun, 4 Apr 2004 05:15:24 +0200 Der Name des Empf=E4ngers wurde nicht erkannt. Die MTS-ID der urspr=FCnglichen Nachricht ist: c=3Dde;a=3D = ;p=3Dbundesstadt bonn;l=3DSV375204040403152CP17K34 MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C419F3.144F81DE Content-Type: message/rfc822 From: aaa@ietf.org To: jea@bonn.de Subject: fake Date: Sun, 4 Apr 2004 04:55:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C419F3.144F81DE" ------_=_NextPart_002_01C419F3.144F81DE Content-Type: text/plain; charset="iso-8859-1" kill the writer of this document! ------_=_NextPart_002_01C419F3.144F81DE Content-Type: text/plain; name="InterScan_SafeStamp.txt" Content-Disposition: attachment; filename="InterScan_SafeStamp.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file note.zip contains: WORM_NETSKY.B virus in compressed file note.doc.pif Attempted to clean the file but it is not cleanable. It has been deleted. Mail-Virus von Trend Micro Interscan Viruswall entdeckt und entfernt! ***************** End of message *************** ------_=_NextPart_002_01C419F3.144F81DE-- ------_=_NextPart_000_01C419F3.144F81DE-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sat Apr 3 22:19:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16213 for <aaa-archive@odin.ietf.org>; Sat, 3 Apr 2004 22:19:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9yAK-0002xL-Pv for aaa-archive@odin.ietf.org; Sat, 03 Apr 2004 22:19:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i343JKg3011364 for aaa-archive@odin.ietf.org; Sat, 3 Apr 2004 22:19:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9yAK-0002xD-KU for aaa-web-archive@optimus.ietf.org; Sat, 03 Apr 2004 22:19:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16208 for <aaa-web-archive@ietf.org>; Sat, 3 Apr 2004 22:19:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9yAH-000716-00 for aaa-web-archive@ietf.org; Sat, 03 Apr 2004 22:19:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9y9M-0006v4-00 for aaa-web-archive@ietf.org; Sat, 03 Apr 2004 22:18:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9y94-0006ou-00 for aaa-web-archive@ietf.org; Sat, 03 Apr 2004 22:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9y93-0002kX-62; Sat, 03 Apr 2004 22:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9y8M-0002bq-Vj for aaa@optimus.ietf.org; Sat, 03 Apr 2004 22:17:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16134 for <aaa@ietf.org>; Sat, 3 Apr 2004 22:17:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9y8J-0006nN-00 for aaa@ietf.org; Sat, 03 Apr 2004 22:17:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9y7N-0006hE-00 for aaa@ietf.org; Sat, 03 Apr 2004 22:16:17 -0500 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1B9y6v-0006bB-00 for aaa@ietf.org; Sat, 03 Apr 2004 22:15:49 -0500 Received: from exchange0.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Sun, 4 Apr 2004 04:09:50 +0200 Received: by sv3752.bonn.de with Internet Mail Service (5.5.2653.19) id <2CP17K3Z>; Sun, 4 Apr 2004 05:15:29 +0200 Message-ID: <1C2329C9430609409808ECF1023728760117D9BE@sv3752.bonn.de> From: Systemadministrator <postmaster@Bonn.de> To: aaa@ietf.org Date: Sun, 4 Apr 2004 05:15:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C419F3.144F81DE" Subject: [Aaa] Unzustellbar: fake Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=unsubscribe> List-Id: Authentication, Authorization and Accounting <aaa.ietf.org> List-Post: <mailto:aaa@ietf.org> List-Help: <mailto:aaa-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=subscribe> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C419F3.144F81DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: jea@bonn.de Subject: fake Sent: Sun, 4 Apr 2004 04:55:19 +0200 did not reach the following recipient(s): jea@bonn.de on Sun, 4 Apr 2004 05:15:24 +0200 Der Name des Empf=E4ngers wurde nicht erkannt. Die MTS-ID der urspr=FCnglichen Nachricht ist: c=3Dde;a=3D = ;p=3Dbundesstadt bonn;l=3DSV375204040403152CP17K34 MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C419F3.144F81DE Content-Type: message/rfc822 From: aaa@ietf.org To: jea@bonn.de Subject: fake Date: Sun, 4 Apr 2004 04:55:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C419F3.144F81DE" ------_=_NextPart_002_01C419F3.144F81DE Content-Type: text/plain; charset="iso-8859-1" kill the writer of this document! ------_=_NextPart_002_01C419F3.144F81DE Content-Type: text/plain; name="InterScan_SafeStamp.txt" Content-Disposition: attachment; filename="InterScan_SafeStamp.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file note.zip contains: WORM_NETSKY.B virus in compressed file note.doc.pif Attempted to clean the file but it is not cleanable. It has been deleted. Mail-Virus von Trend Micro Interscan Viruswall entdeckt und entfernt! ***************** End of message *************** ------_=_NextPart_002_01C419F3.144F81DE-- ------_=_NextPart_000_01C419F3.144F81DE-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Sat Apr 3 22:35:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16429 for <aaa-archive@lists.ietf.org>; Sat, 3 Apr 2004 22:35:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9yPW-0004xj-2E; Sat, 03 Apr 2004 22:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9yOs-0004p7-5P for aaa@optimus.ietf.org; Sat, 03 Apr 2004 22:34:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16394 for <aaa@ietf.org>; Sat, 3 Apr 2004 22:34:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9yOo-0000iJ-00 for aaa@ietf.org; Sat, 03 Apr 2004 22:34:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9yNx-0000bk-00 for aaa@ietf.org; Sat, 03 Apr 2004 22:33:25 -0500 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1B9yNa-0000Ut-00 for aaa@ietf.org; Sat, 03 Apr 2004 22:33:02 -0500 Received: from exchange0.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Sun, 4 Apr 2004 04:27:03 +0200 Received: by sv3752.bonn.de with Internet Mail Service (5.5.2653.19) id <2CP17LJM>; Sun, 4 Apr 2004 05:33:27 +0200 Message-ID: <1C2329C9430609409808ECF1023728760117061A@sv3752.bonn.de> From: Systemadministrator <postmaster@Bonn.de> To: aaa@ietf.org Date: Sun, 4 Apr 2004 05:33:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C419F5.97AB0FCE" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Aaa] Unzustellbar: warning Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=unsubscribe> List-Id: Authentication, Authorization and Accounting <aaa.ietf.org> List-Post: <mailto:aaa@ietf.org> List-Help: <mailto:aaa-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=subscribe> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C419F5.97AB0FCE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: dlb@bonn.de Subject: warning Sent: Sat, 3 Apr 2004 23:55:34 +0200 did not reach the following recipient(s): dlb@bonn.de on Sun, 4 Apr 2004 05:33:26 +0200 Der Name des Empf=E4ngers wurde nicht erkannt. Die MTS-ID der urspr=FCnglichen Nachricht ist: c=3Dde;a=3D = ;p=3Dbundesstadt bonn;l=3DSV375204040403332CP17LJ2 MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C419F5.97AB0FCE Content-Type: message/rfc822 From: aaa@ietf.org To: dlb@bonn.de Subject: warning Date: Sat, 3 Apr 2004 23:55:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C419F5.97AB0FCE" ------_=_NextPart_002_01C419F5.97AB0FCE Content-Type: text/plain; charset="iso-8859-1" here ------_=_NextPart_002_01C419F5.97AB0FCE Content-Type: text/plain; name="InterScan_SafeStamp.txt" Content-Disposition: attachment; filename="InterScan_SafeStamp.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file message.zip contains: WORM_NETSKY.B virus in compressed file message.exe Attempted to clean the file but it is not cleanable. It has been deleted. Mail-Virus von Trend Micro Interscan Viruswall entdeckt und entfernt! ***************** End of message *************** ------_=_NextPart_002_01C419F5.97AB0FCE-- ------_=_NextPart_000_01C419F5.97AB0FCE-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sat Apr 3 22:37:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16476 for <aaa-archive@odin.ietf.org>; Sat, 3 Apr 2004 22:37:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9yR5-0005E2-6x for aaa-archive@odin.ietf.org; Sat, 03 Apr 2004 22:36:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i343admX020038 for aaa-archive@odin.ietf.org; Sat, 3 Apr 2004 22:36:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9yR4-0005Co-Kf for aaa-web-archive@optimus.ietf.org; Sat, 03 Apr 2004 22:36:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16469 for <aaa-web-archive@ietf.org>; Sat, 3 Apr 2004 22:36:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9yR1-0000zK-00 for aaa-web-archive@ietf.org; Sat, 03 Apr 2004 22:36:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9yQ4-0000r0-00 for aaa-web-archive@ietf.org; Sat, 03 Apr 2004 22:35:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9yPU-0000jS-00 for aaa-web-archive@ietf.org; Sat, 03 Apr 2004 22:35:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9yPW-0004xj-2E; Sat, 03 Apr 2004 22:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9yOs-0004p7-5P for aaa@optimus.ietf.org; Sat, 03 Apr 2004 22:34:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16394 for <aaa@ietf.org>; Sat, 3 Apr 2004 22:34:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9yOo-0000iJ-00 for aaa@ietf.org; Sat, 03 Apr 2004 22:34:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9yNx-0000bk-00 for aaa@ietf.org; Sat, 03 Apr 2004 22:33:25 -0500 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1B9yNa-0000Ut-00 for aaa@ietf.org; Sat, 03 Apr 2004 22:33:02 -0500 Received: from exchange0.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Sun, 4 Apr 2004 04:27:03 +0200 Received: by sv3752.bonn.de with Internet Mail Service (5.5.2653.19) id <2CP17LJM>; Sun, 4 Apr 2004 05:33:27 +0200 Message-ID: <1C2329C9430609409808ECF1023728760117061A@sv3752.bonn.de> From: Systemadministrator <postmaster@Bonn.de> To: aaa@ietf.org Date: Sun, 4 Apr 2004 05:33:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C419F5.97AB0FCE" Subject: [Aaa] Unzustellbar: warning Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=unsubscribe> List-Id: Authentication, Authorization and Accounting <aaa.ietf.org> List-Post: <mailto:aaa@ietf.org> List-Help: <mailto:aaa-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=subscribe> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C419F5.97AB0FCE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: dlb@bonn.de Subject: warning Sent: Sat, 3 Apr 2004 23:55:34 +0200 did not reach the following recipient(s): dlb@bonn.de on Sun, 4 Apr 2004 05:33:26 +0200 Der Name des Empf=E4ngers wurde nicht erkannt. Die MTS-ID der urspr=FCnglichen Nachricht ist: c=3Dde;a=3D = ;p=3Dbundesstadt bonn;l=3DSV375204040403332CP17LJ2 MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C419F5.97AB0FCE Content-Type: message/rfc822 From: aaa@ietf.org To: dlb@bonn.de Subject: warning Date: Sat, 3 Apr 2004 23:55:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C419F5.97AB0FCE" ------_=_NextPart_002_01C419F5.97AB0FCE Content-Type: text/plain; charset="iso-8859-1" here ------_=_NextPart_002_01C419F5.97AB0FCE Content-Type: text/plain; name="InterScan_SafeStamp.txt" Content-Disposition: attachment; filename="InterScan_SafeStamp.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file message.zip contains: WORM_NETSKY.B virus in compressed file message.exe Attempted to clean the file but it is not cleanable. It has been deleted. Mail-Virus von Trend Micro Interscan Viruswall entdeckt und entfernt! ***************** End of message *************** ------_=_NextPart_002_01C419F5.97AB0FCE-- ------_=_NextPart_000_01C419F5.97AB0FCE-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Sat Apr 3 23:54:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18244 for <aaa-archive@lists.ietf.org>; Sat, 3 Apr 2004 23:54:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9zdw-0007L6-TL; Sat, 03 Apr 2004 23:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9zdL-0007Dc-JL for aaa@optimus.ietf.org; Sat, 03 Apr 2004 23:53:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18211 for <aaa@ietf.org>; Sat, 3 Apr 2004 23:53:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9zdJ-0001DF-00 for aaa@ietf.org; Sat, 03 Apr 2004 23:53:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9zcK-00017F-00 for aaa@ietf.org; Sat, 03 Apr 2004 23:52:20 -0500 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1B9zbh-0000vA-00 for aaa@ietf.org; Sat, 03 Apr 2004 23:51:41 -0500 Received: from exchange0.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Sun, 4 Apr 2004 05:45:42 +0200 Received: by sv3752.bonn.de with Internet Mail Service (5.5.2653.19) id <2CP17372>; Sun, 4 Apr 2004 06:51:38 +0200 Message-ID: <1C2329C9430609409808ECF1023728760116F382@sv3752.bonn.de> From: Systemadministrator <postmaster@Bonn.de> To: aaa@ietf.org Date: Sun, 4 Apr 2004 06:51:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C41A00.8249B12A" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Aaa] Unzustellbar: warning Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=unsubscribe> List-Id: Authentication, Authorization and Accounting <aaa.ietf.org> List-Post: <mailto:aaa@ietf.org> List-Help: <mailto:aaa-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=subscribe> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C41A00.8249B12A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: ldu@bonn.de Subject: warning Sent: Sun, 4 Apr 2004 06:25:59 +0200 did not reach the following recipient(s): ldu@bonn.de on Sun, 4 Apr 2004 06:51:34 +0200 Der Name des Empf=E4ngers wurde nicht erkannt. Die MTS-ID der urspr=FCnglichen Nachricht ist: c=3Dde;a=3D = ;p=3Dbundesstadt bonn;l=3DSV375204040404512CP1737D MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C41A00.8249B12A Content-Type: message/rfc822 From: aaa@ietf.org To: ldu@bonn.de Subject: warning Date: Sun, 4 Apr 2004 06:25:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C41A00.8249B12A" ------_=_NextPart_002_01C41A00.8249B12A Content-Type: text/plain; charset="iso-8859-1" is that your account? ------_=_NextPart_002_01C41A00.8249B12A Content-Type: text/plain; name="InterScan_SafeStamp.txt" Content-Disposition: attachment; filename="InterScan_SafeStamp.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file mails.zip contains: WORM_NETSKY.B virus in compressed file mails.doc.com Attempted to clean the file but it is not cleanable. It has been deleted. Mail-Virus von Trend Micro Interscan Viruswall entdeckt und entfernt! ***************** End of message *************** ------_=_NextPart_002_01C41A00.8249B12A-- ------_=_NextPart_000_01C41A00.8249B12A-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sat Apr 3 23:56:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18315 for <aaa-archive@odin.ietf.org>; Sat, 3 Apr 2004 23:56:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9zfZ-0007Z0-5S for aaa-archive@odin.ietf.org; Sat, 03 Apr 2004 23:55:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i344tdXe029065 for aaa-archive@odin.ietf.org; Sat, 3 Apr 2004 23:55:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9zfW-0007Yi-Tm for aaa-web-archive@optimus.ietf.org; Sat, 03 Apr 2004 23:55:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18308 for <aaa-web-archive@ietf.org>; Sat, 3 Apr 2004 23:55:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9zfU-0001SK-00 for aaa-web-archive@ietf.org; Sat, 03 Apr 2004 23:55:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9zeS-0001LA-00 for aaa-web-archive@ietf.org; Sat, 03 Apr 2004 23:54:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9zdy-0001Dj-00 for aaa-web-archive@ietf.org; Sat, 03 Apr 2004 23:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9zdw-0007L6-TL; Sat, 03 Apr 2004 23:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9zdL-0007Dc-JL for aaa@optimus.ietf.org; Sat, 03 Apr 2004 23:53:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18211 for <aaa@ietf.org>; Sat, 3 Apr 2004 23:53:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9zdJ-0001DF-00 for aaa@ietf.org; Sat, 03 Apr 2004 23:53:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9zcK-00017F-00 for aaa@ietf.org; Sat, 03 Apr 2004 23:52:20 -0500 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1B9zbh-0000vA-00 for aaa@ietf.org; Sat, 03 Apr 2004 23:51:41 -0500 Received: from exchange0.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Sun, 4 Apr 2004 05:45:42 +0200 Received: by sv3752.bonn.de with Internet Mail Service (5.5.2653.19) id <2CP17372>; Sun, 4 Apr 2004 06:51:38 +0200 Message-ID: <1C2329C9430609409808ECF1023728760116F382@sv3752.bonn.de> From: Systemadministrator <postmaster@Bonn.de> To: aaa@ietf.org Date: Sun, 4 Apr 2004 06:51:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C41A00.8249B12A" Subject: [Aaa] Unzustellbar: warning Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=unsubscribe> List-Id: Authentication, Authorization and Accounting <aaa.ietf.org> List-Post: <mailto:aaa@ietf.org> List-Help: <mailto:aaa-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=subscribe> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C41A00.8249B12A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: ldu@bonn.de Subject: warning Sent: Sun, 4 Apr 2004 06:25:59 +0200 did not reach the following recipient(s): ldu@bonn.de on Sun, 4 Apr 2004 06:51:34 +0200 Der Name des Empf=E4ngers wurde nicht erkannt. Die MTS-ID der urspr=FCnglichen Nachricht ist: c=3Dde;a=3D = ;p=3Dbundesstadt bonn;l=3DSV375204040404512CP1737D MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C41A00.8249B12A Content-Type: message/rfc822 From: aaa@ietf.org To: ldu@bonn.de Subject: warning Date: Sun, 4 Apr 2004 06:25:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C41A00.8249B12A" ------_=_NextPart_002_01C41A00.8249B12A Content-Type: text/plain; charset="iso-8859-1" is that your account? ------_=_NextPart_002_01C41A00.8249B12A Content-Type: text/plain; name="InterScan_SafeStamp.txt" Content-Disposition: attachment; filename="InterScan_SafeStamp.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file mails.zip contains: WORM_NETSKY.B virus in compressed file mails.doc.com Attempted to clean the file but it is not cleanable. It has been deleted. Mail-Virus von Trend Micro Interscan Viruswall entdeckt und entfernt! ***************** End of message *************** ------_=_NextPart_002_01C41A00.8249B12A-- ------_=_NextPart_000_01C41A00.8249B12A-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Sun Apr 4 20:14:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16843 for <aaa-archive@lists.ietf.org>; Sun, 4 Apr 2004 20:14:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAHkX-0005bs-JZ; Sun, 04 Apr 2004 20:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAHjY-0005X8-DE for aaa@optimus.ietf.org; Sun, 04 Apr 2004 20:13:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16826 for <aaa@ietf.org>; Sun, 4 Apr 2004 20:12:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAHjW-00078D-00 for aaa@ietf.org; Sun, 04 Apr 2004 20:12:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAHia-00073I-00 for aaa@ietf.org; Sun, 04 Apr 2004 20:12:00 -0400 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1BAHiR-0006xr-00 for aaa@ietf.org; Sun, 04 Apr 2004 20:11:51 -0400 Received: from exchange0.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Mon, 5 Apr 2004 01:05:52 +0200 Received: by sv3752.bonn.de with Internet Mail Service (5.5.2653.19) id <2CP18X62>; Mon, 5 Apr 2004 02:12:01 +0200 Message-ID: <1C2329C9430609409808ECF102372876011F92C0@sv3752.bonn.de> From: Systemadministrator <postmaster@Bonn.de> To: aaa@ietf.org Date: Mon, 5 Apr 2004 02:12:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C41AA2.9DD38248" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Aaa] Unzustellbar: read it immediately Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=unsubscribe> List-Id: Authentication, Authorization and Accounting <aaa.ietf.org> List-Post: <mailto:aaa@ietf.org> List-Help: <mailto:aaa-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=subscribe> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C41AA2.9DD38248 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: atj@bonn.de Subject: read it immediately Sent: Mon, 5 Apr 2004 01:24:20 +0200 did not reach the following recipient(s): atj@bonn.de on Mon, 5 Apr 2004 02:11:58 +0200 Der Name des Empf=E4ngers wurde nicht erkannt. Die MTS-ID der urspr=FCnglichen Nachricht ist: c=3Dde;a=3D = ;p=3Dbundesstadt bonn;l=3DSV375204040500112CP18X6G MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C41AA2.9DD38248 Content-Type: message/rfc822 From: aaa@ietf.org To: atj@bonn.de Subject: read it immediately Date: Mon, 5 Apr 2004 01:24:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C41AA2.9DD38248" ------_=_NextPart_002_01C41AA2.9DD38248 Content-Type: text/plain; charset="iso-8859-1" here is the document. ------_=_NextPart_002_01C41AA2.9DD38248 Content-Type: text/plain; name="InterScan_SafeStamp.txt" Content-Disposition: attachment; filename="InterScan_SafeStamp.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file msg.rtf.pif contains: WORM_NETSKY.B virus Attempted to clean the file but it is not cleanable. It has been deleted. Mail-Virus von Trend Micro Interscan Viruswall entdeckt und entfernt! ***************** End of message *************** ------_=_NextPart_002_01C41AA2.9DD38248-- ------_=_NextPart_000_01C41AA2.9DD38248-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sun Apr 4 20:16:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16889 for <aaa-archive@odin.ietf.org>; Sun, 4 Apr 2004 20:16:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAHmR-0005t2-6R for aaa-archive@odin.ietf.org; Sun, 04 Apr 2004 20:15:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i350Fx9u022629 for aaa-archive@odin.ietf.org; Sun, 4 Apr 2004 20:15:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAHmR-0005su-1d for aaa-web-archive@optimus.ietf.org; Sun, 04 Apr 2004 20:15:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16877 for <aaa-web-archive@ietf.org>; Sun, 4 Apr 2004 20:15:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAHmP-0007Nh-00 for aaa-web-archive@ietf.org; Sun, 04 Apr 2004 20:15:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAHlR-0007Id-00 for aaa-web-archive@ietf.org; Sun, 04 Apr 2004 20:14:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAHke-0007Dr-00 for aaa-web-archive@ietf.org; Sun, 04 Apr 2004 20:14:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAHkX-0005bs-JZ; Sun, 04 Apr 2004 20:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAHjY-0005X8-DE for aaa@optimus.ietf.org; Sun, 04 Apr 2004 20:13:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16826 for <aaa@ietf.org>; Sun, 4 Apr 2004 20:12:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAHjW-00078D-00 for aaa@ietf.org; Sun, 04 Apr 2004 20:12:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAHia-00073I-00 for aaa@ietf.org; Sun, 04 Apr 2004 20:12:00 -0400 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1BAHiR-0006xr-00 for aaa@ietf.org; Sun, 04 Apr 2004 20:11:51 -0400 Received: from exchange0.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Mon, 5 Apr 2004 01:05:52 +0200 Received: by sv3752.bonn.de with Internet Mail Service (5.5.2653.19) id <2CP18X62>; Mon, 5 Apr 2004 02:12:01 +0200 Message-ID: <1C2329C9430609409808ECF102372876011F92C0@sv3752.bonn.de> From: Systemadministrator <postmaster@Bonn.de> To: aaa@ietf.org Date: Mon, 5 Apr 2004 02:12:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C41AA2.9DD38248" Subject: [Aaa] Unzustellbar: read it immediately Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=unsubscribe> List-Id: Authentication, Authorization and Accounting <aaa.ietf.org> List-Post: <mailto:aaa@ietf.org> List-Help: <mailto:aaa-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=subscribe> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C41AA2.9DD38248 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: atj@bonn.de Subject: read it immediately Sent: Mon, 5 Apr 2004 01:24:20 +0200 did not reach the following recipient(s): atj@bonn.de on Mon, 5 Apr 2004 02:11:58 +0200 Der Name des Empf=E4ngers wurde nicht erkannt. Die MTS-ID der urspr=FCnglichen Nachricht ist: c=3Dde;a=3D = ;p=3Dbundesstadt bonn;l=3DSV375204040500112CP18X6G MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C41AA2.9DD38248 Content-Type: message/rfc822 From: aaa@ietf.org To: atj@bonn.de Subject: read it immediately Date: Mon, 5 Apr 2004 01:24:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C41AA2.9DD38248" ------_=_NextPart_002_01C41AA2.9DD38248 Content-Type: text/plain; charset="iso-8859-1" here is the document. ------_=_NextPart_002_01C41AA2.9DD38248 Content-Type: text/plain; name="InterScan_SafeStamp.txt" Content-Disposition: attachment; filename="InterScan_SafeStamp.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file msg.rtf.pif contains: WORM_NETSKY.B virus Attempted to clean the file but it is not cleanable. It has been deleted. Mail-Virus von Trend Micro Interscan Viruswall entdeckt und entfernt! ***************** End of message *************** ------_=_NextPart_002_01C41AA2.9DD38248-- ------_=_NextPart_000_01C41AA2.9DD38248-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Mon Apr 5 01:25:33 2004 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 BAA27260 for <aaa-archive@lists.ietf.org>; Mon, 5 Apr 2004 01:25:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C41A9120E; Mon, 5 Apr 2004 01:25:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C35891212; Mon, 5 Apr 2004 01:25:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 402709120E for <aaa-wg@trapdoor.merit.edu>; Mon, 5 Apr 2004 01:25:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2C659587BC; Mon, 5 Apr 2004 01:25:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 6CBB4588A8 for <aaa-wg@merit.edu>; Mon, 5 Apr 2004 01:25:18 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i355Wcd17657 for <aaa-wg@merit.edu>; Sun, 4 Apr 2004 22:32:39 -0700 Date: Sun, 4 Apr 2004 22:32:38 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Message-ID: <Pine.LNX.4.56.0404042232020.17523@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk ---------- Forwarded message ---------- Date: Mon, 05 Apr 2004 00:16:50 -0400 From: David Mitton <david@mitton.com> I've gotten through the document about 1.5 times. Mostly just looking at the parts. Below are my comments, I'll try to back up and try to understand more about how this thing behaves... but I doubt I'll turn up much more. Dave. ---- Nits: - Many lines go one character over the 72 column RFC format restriction into col 73. Fixing these will cause the document to page differently. - Sect 4.0, page 13, para 4, first sentence; upcased "Credit" for no reason. In a number of places the phrase "credit control" is randomly hyphenated or not. Issues: - Section 11.3 RADIUS VSAs for Credit Control, page 80, the section names, but does not define (type codes, field layouts) the VSAs used. An example is promised in Annex A, but I could not find what I was looking for. I'm guessing, since it's not stated directly enough for me, that they are proposing a translation of Diameter AVPs into RADIUS VSAs. The section of Diameter NASREQ quoted, only gives rules for Diameter VSAs into RADIUS VSAs. No rules are given for regular Diameter AVPs. What vendor code is used? What is the VSA format? What are the RADIUS attribute data types corresponding to each Diameter AVP? What happens to the Diameter flag values? What is done with Grouped AVPs? Is there an unnamed reference document? - Section 12, IANA Consideration, page 81 No general policy is given, the AVPs repeat that additional values can be assigned by the designated expert. How will the Diameter AVP to RADIUS VSA mapping be administered in the case of new attributes or AVPs? From owner-aaa-wg@merit.edu Mon Apr 5 06:38:25 2004 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 GAA21769 for <aaa-archive@lists.ietf.org>; Mon, 5 Apr 2004 06:38:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8C04491211; Mon, 5 Apr 2004 06:38:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 55D2991212; Mon, 5 Apr 2004 06:38:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 18D9A91211 for <aaa-wg@trapdoor.merit.edu>; Mon, 5 Apr 2004 06:38:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0690958674; Mon, 5 Apr 2004 06:38:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 3D87058617 for <aaa-wg@merit.edu>; Mon, 5 Apr 2004 06:38:13 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i35Ac3WR020935 for <aaa-wg@merit.edu>; Mon, 5 Apr 2004 12:38:03 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 12:38:03 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <2CQBPZ9T>; Mon, 5 Apr 2004 12:38:25 +0200 Message-ID: <F8EFC4B4A8C016428BC1F589296D4FBF04844006@esealnt630.al.sw.ericsson.se> From: "Harri Hakala (TU/LMF)" <harri.hakala@ericsson.com> To: "'Bernard Aboba'" <aboba@internaut.com>, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Date: Mon, 5 Apr 2004 12:37:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 05 Apr 2004 10:38:03.0015 (UTC) FILETIME=[12A4C170:01C41AFA] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, The section 11 is meant to be more as a guideline and not a full solution because no corresponding RADIUS prepaid RFC exists. Anyway, we felt that having an informative section on this was needed. So, basically we tried to write basic principle how to translate some Diameter AVPs and messages to more or less imaginary RADIUS prepaid application, using the RFC 2865 as a base. We are aware of the draft-lior-radius-prepaid but since that work is still in progress the exact mapping to this document was not possible. The RFC of Radius prepaid (when available) should define a complete description of protocol translation between Radius prepaid and Diameter credit control, if we follow the principle that the document (Radius, Diameter) that comes last is responsible for defining the mapping. The first paragraph in section 11 is intended to highlight this but perhaps some re-wording is needed here. In Annex A, the flow 1 shows the message translation between Radius prepaid and Diameter CC, but the purpose was not to show a full-fledged parameter mapping for the above reasons. regards...........Harri > -----Original Message----- > From: owner-aaa-wg@merit.edu > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Bernard Aboba > Sent: 5. huhtikuuta 2004 8:33 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue: Review of Diameter Credit Control -04 > > > > ---------- Forwarded message ---------- > Date: Mon, 05 Apr 2004 00:16:50 -0400 > From: David Mitton <david@mitton.com> > > I've gotten through the document about 1.5 times. Mostly > just looking at > the parts. > > Below are my comments, I'll try to back up and try to > understand more about > how this thing behaves... but I doubt I'll turn up much more. > > Dave. > ---- > Nits: > > - Many lines go one character over the 72 column RFC > format restriction into col 73. Fixing these will cause the > document to > page differently. > > - Sect 4.0, page 13, para 4, first sentence; upcased "Credit" for no > reason. In a number of places the phrase "credit control" is > randomly hyphenated or not. > > > Issues: > > - Section 11.3 RADIUS VSAs for Credit Control, page 80, the section > names, but does not define (type codes, field layouts) the VSAs used. > An example is promised in Annex A, but I could not find what I was > looking for. > > I'm guessing, since it's not stated directly enough for me, that they > are proposing a translation of Diameter AVPs into RADIUS VSAs. > The section of Diameter NASREQ quoted, only gives rules for Diameter > VSAs into RADIUS VSAs. No rules are given for regular Diameter AVPs. > > What vendor code is used? What is the VSA format? What are > the RADIUS > attribute data types corresponding to each Diameter AVP? What happens > to the Diameter flag values? What is done with Grouped AVPs? Is there > an unnamed reference document? > > - Section 12, IANA Consideration, page 81 > No general policy is given, the AVPs repeat that additional values can > be assigned by the designated expert. > > How will the Diameter AVP to RADIUS VSA mapping be administered in the > case of new attributes or AVPs? > From owner-aaa-wg@merit.edu Mon Apr 5 07:44:11 2004 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 HAA24738 for <aaa-archive@lists.ietf.org>; Mon, 5 Apr 2004 07:44:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E6CC691212; Mon, 5 Apr 2004 07:43:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6A1091216; Mon, 5 Apr 2004 07:43:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A663791212 for <aaa-wg@trapdoor.merit.edu>; Mon, 5 Apr 2004 07:43:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 912B85876C; Mon, 5 Apr 2004 07:43:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 402D058781 for <aaa-wg@merit.edu>; Mon, 5 Apr 2004 07:43:54 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i35Bhnx09433 for <aaa-wg@merit.edu>; Mon, 5 Apr 2004 14:43:49 +0300 (EET DST) X-Scanned: Mon, 5 Apr 2004 14:41:12 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i35BfChV008106 for <aaa-wg@merit.edu>; Mon, 5 Apr 2004 14:41:12 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00uqgOSZ; Mon, 05 Apr 2004 14:41:10 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i35BfAF11325 for <aaa-wg@merit.edu>; Mon, 5 Apr 2004 14:41:10 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Apr 2004 14:39:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Diameter EAP -05 Date: Mon, 5 Apr 2004 14:39:35 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61223BD@esebe023.ntc.nokia.com> Thread-Topic: Diameter EAP -05 Thread-Index: AcQbAqs1WbONcyadT2uD0enGIsjKXw== From: <Pasi.Eronen@nokia.com> To: <aaa-wg@merit.edu> X-OriginalArrivalTime: 05 Apr 2004 11:39:35.0201 (UTC) FILETIME=[AB5BA110:01C41B02] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, I have submitted an updated version of the Diameter EAP application draft. I believe this version resolves the following issues from WGLC: - 450: Comments on EAP-04 (from Jari Arkko), except one item below - 455: User-name handling (from Joe Salowey) - 458: Editorial Comment on EAP-04 (from Yoshihiro Ohba) - 461: Alternate uses and conflicting AVPs (from Joe Salowey) Temporary copy of -05 and HTML diff from -04 is available from=20 http://www.cs.hut.fi/~peronen/eap/diameter_eap.html This leaves us with the following open issues: - 446: Diameter EAP comments (from Julien Bournelle).=20 It seems that this issue does not currently propose any=20 changes to the specification. Any objections to closing it? - One item from 450: "Section 2.8.5 may be in conflict with=20 EAP channel bindings. Perhaps you should recommend that the=20 diameter server at least sends all AVPs to the backend auth=20 server." Any suggestions for text? - 460: Key Name AVP (from Joe Salowey). Some discussion about how to handle this would be welcome. E.g. pros and cons of adding an AVP that we don't have any use for yet (and may=20 not have for some time)? And what exactly is named, MSK or=20 EAP-Key SA or something else? Best regards Pasi From owner-aaa-wg@merit.edu Mon Apr 5 10:05:58 2004 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 KAA01772 for <aaa-archive@lists.ietf.org>; Mon, 5 Apr 2004 10:05:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C845B91209; Mon, 5 Apr 2004 10:05:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C39391213; Mon, 5 Apr 2004 10:05:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 87DB991209 for <aaa-wg@trapdoor.merit.edu>; Mon, 5 Apr 2004 10:05:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 73423584F0; Mon, 5 Apr 2004 10:05:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 0282758483 for <aaa-wg@merit.edu>; Mon, 5 Apr 2004 10:05:44 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id ED6A48996E; Mon, 5 Apr 2004 17:05:26 +0300 (EEST) Message-ID: <40716700.8020904@kolumbus.fi> Date: Mon, 05 Apr 2004 17:02:40 +0300 From: Jari Arkko <jari.arkko@kolumbus.fi> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter EAP -05 References: <052E0C61B69C3741AFA5FE88ACC775A61223BD@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61223BD@esebe023.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 Pasi.Eronen@nokia.com wrote: > - 450: Comments on EAP-04 (from Jari Arkko), except one item below (snip) > - One item from 450: "Section 2.8.5 may be in conflict with > EAP channel bindings. Perhaps you should recommend that the > diameter server at least sends all AVPs to the backend auth > server." Any suggestions for text? How about this to the end of 2.8.5: "A disadvantage of this approach is that it becomes harder to support so called EAP channel bindings described in Section 7.15 of [RFC2284bis]. The reason for this is that entity performing the EAP authentication needs to be aware of all authorization data related to the session. It is therefore RECOMMENDED that the backend authentication server both accepts incoming authorization AVPs as well as returns authorization AVPs. (How the backend server finds out which authorization AVPs to return is outside the scope of this specification.)" Another approach would be to delete the whole section. --Jari From owner-aaa-wg@merit.edu Mon Apr 5 10:14:34 2004 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 KAA02450 for <aaa-archive@lists.ietf.org>; Mon, 5 Apr 2004 10:14:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 48E9091213; Mon, 5 Apr 2004 10:14:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14B7491216; Mon, 5 Apr 2004 10:14:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0676E91213 for <aaa-wg@trapdoor.merit.edu>; Mon, 5 Apr 2004 10:14:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DDB2658569; Mon, 5 Apr 2004 10:14:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 30BCD584E4 for <aaa-wg@merit.edu>; Mon, 5 Apr 2004 10:14:14 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i35EE7x23552 for <aaa-wg@merit.edu>; Mon, 5 Apr 2004 17:14:07 +0300 (EET DST) X-Scanned: Mon, 5 Apr 2004 17:12:18 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i35ECIaU007090 for <aaa-wg@merit.edu>; Mon, 5 Apr 2004 17:12:18 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 007yKWzO; Mon, 05 Apr 2004 17:12:16 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i35ECGF08523 for <aaa-wg@merit.edu>; Mon, 5 Apr 2004 17:12:16 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Apr 2004 17:12:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Diameter EAP -05 Date: Mon, 5 Apr 2004 17:12:02 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3A25@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Diameter EAP -05 Thread-Index: AcQbFyxri9NeAEyEQ4mkFC27Y/aY6QAACqEg From: <Pasi.Eronen@nokia.com> To: <jari.arkko@kolumbus.fi>, <aaa-wg@merit.edu> X-OriginalArrivalTime: 05 Apr 2004 14:12:02.0236 (UTC) FILETIME=[F76A67C0:01C41B17] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Jari Arkko wrote: > > How about this to the end of 2.8.5: >=20 > "A disadvantage of this approach is that it becomes harder > to support so called EAP channel bindings described in > Section 7.15 of [RFC2284bis]. The reason for this is that > entity performing the EAP authentication needs to be aware > of all authorization data related to the session. It is > therefore RECOMMENDED that the backend authentication > server both accepts incoming authorization AVPs as well as > returns authorization AVPs. (How the backend server finds > out which authorization AVPs to return is outside the > scope of this specification.)" >=20 > Another approach would be to delete the whole section. Hmm... with this addition, the situation is not that=20 different from having a Diameter proxy agent that does some authorization parts. And that case is already covered elsewhere. I'd suggest that we delete the whole section 2.8.5; any other opinions about this? Best regards, Pasi From owner-aaa-wg@merit.edu Tue Apr 6 05:24:45 2004 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 FAA26207 for <aaa-archive@lists.ietf.org>; Tue, 6 Apr 2004 05:24:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4430491218; Tue, 6 Apr 2004 05:24:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1414691263; Tue, 6 Apr 2004 05:24:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D76FA91218 for <aaa-wg@trapdoor.merit.edu>; Tue, 6 Apr 2004 05:24:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B9B3A588AF; Tue, 6 Apr 2004 05:24:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id 487E0588B4 for <aaa-wg@merit.edu>; Tue, 6 Apr 2004 05:24:33 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i369OWPA019670 for <aaa-wg@merit.edu>; Tue, 6 Apr 2004 11:24:32 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 6 Apr 2004 11:24:31 +0200 Received: from ESEALNT744.al.sw.ericsson.se ([153.88.251.4]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2CQB58LX; Tue, 6 Apr 2004 11:24:57 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <HJZ1KHJ0>; Tue, 6 Apr 2004 11:24:30 +0200 Message-ID: <1AB3D30B989BF141BBD5C70057B2EF7C0476A7C7@eestqnt105.es.eu.ericsson.se> X-Sybari-Trust: b0d6f4b4 272a6e05 1f3580bf 00000139 From: "David Mariblanca (ML/EEM)" <david.mariblanca@ericsson.com> To: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu> Subject: [AAA-WG]: use of EAP over IKEv2 Date: Tue, 6 Apr 2004 11:23:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 06 Apr 2004 09:24:31.0860 (UTC) FILETIME=[F7CDAB40:01C41BB8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I have found a problem when EAP is used over IKEv2 and I would appreciate some help on the issue. When EAP is carried over IKEv2, a common situation is that the host where EAP terminates is not the same as for IKEv2. In that case, the IKEv2 termination point unpacks the IKEv2 messages, take the EAP messages and forwards them to the EAP termination point over RADIUS or Diameter. The problem I see is that the EAP server has no way to know that these EAP messages are being carried over IKEv2. This knowledge is important for the EAP server, for example to derive keys that will be used to generate AUTH payloads in IKEv2. The service type AVP does not have a reserved value for this, and I don't find any other suitable parameter to convey this information. How could this be done ? Thanks a lot and best regards, David. From owner-aaa-wg@merit.edu Tue Apr 6 06:10:44 2004 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 GAA28505 for <aaa-archive@lists.ietf.org>; Tue, 6 Apr 2004 06:10:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 170E591263; Tue, 6 Apr 2004 06:10:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DEF0E91265; Tue, 6 Apr 2004 06:10:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D2E5E91263 for <aaa-wg@trapdoor.merit.edu>; Tue, 6 Apr 2004 06:10:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BB45F58888; Tue, 6 Apr 2004 06:10:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 282D658912 for <aaa-wg@merit.edu>; Tue, 6 Apr 2004 06:10:31 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id C30AF898C2; Tue, 6 Apr 2004 13:10:29 +0300 (EEST) Message-ID: <4072816E.6040201@kolumbus.fi> Date: Tue, 06 Apr 2004 13:07:42 +0300 From: Jari Arkko <jari.arkko@kolumbus.fi> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David Mariblanca (ML/EEM)" <david.mariblanca@ericsson.com> Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu> Subject: Re: [AAA-WG]: use of EAP over IKEv2 References: <1AB3D30B989BF141BBD5C70057B2EF7C0476A7C7@eestqnt105.es.eu.ericsson.se> In-Reply-To: <1AB3D30B989BF141BBD5C70057B2EF7C0476A7C7@eestqnt105.es.eu.ericsson.se> 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 David Mariblanca (ML/EEM) wrote: > Hi, > I have found a problem when EAP is used over IKEv2 and I would appreciate some help on the issue. > When EAP is carried over IKEv2, a common situation is that the host where EAP terminates is not the same as for IKEv2. In that case, the IKEv2 termination point unpacks the IKEv2 messages, take the EAP messages and forwards them to the EAP termination point over RADIUS or Diameter. > The problem I see is that the EAP server has no way to know that these EAP messages are being carried over IKEv2. This knowledge is important for the EAP server, for example to derive keys that will be used to generate AUTH payloads in IKEv2. > The service type AVP does not have a reserved value for this, and I don't find any other suitable parameter to convey this information. How could this be done ? I believe the keys should be the same regardless of the which protocol (IKEv2/802.11/PPP) is being terminated. However, it would be very useful if there was an attribute that told the AAA server what service is being offered. Looking at the RFC 2865 and draft-ietf-aaa-diameter-nasreq values for Service-Type and Framed-Protocol, it is unclear what values to fill in when using IKEv2. Has someone made a suitable value allocation for these AVPs? Or should we use some of the existing value? If so, which one and can that be distinguished from e.g. 802.11 usage? --Jari From owner-aaa-wg@merit.edu Tue Apr 6 06:28:31 2004 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 GAA00686 for <aaa-archive@lists.ietf.org>; Tue, 6 Apr 2004 06:28:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B442D91266; Tue, 6 Apr 2004 06:28:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81E2591268; Tue, 6 Apr 2004 06:28:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 639AE91266 for <aaa-wg@trapdoor.merit.edu>; Tue, 6 Apr 2004 06:28:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4867758963; Tue, 6 Apr 2004 06:28:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 4F07C58947 for <aaa-wg@merit.edu>; Tue, 6 Apr 2004 06:28:17 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i36AS6h17732; Tue, 6 Apr 2004 13:28:06 +0300 (EET DST) X-Scanned: Tue, 6 Apr 2004 13:27:11 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i36ARBrn017251; Tue, 6 Apr 2004 13:27:11 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 002z37RZ; Tue, 06 Apr 2004 13:27:10 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i36AR9F04676; Tue, 6 Apr 2004 13:27:09 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 6 Apr 2004 13:19:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: use of EAP over IKEv2 Date: Tue, 6 Apr 2004 13:19:54 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61223C1@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: use of EAP over IKEv2 Thread-Index: AcQbuY0gDAwm+yWuRwqVIn14EOMSmgAAa/rw From: <Pasi.Eronen@nokia.com> To: <david.mariblanca@ericsson.com>, <aaa-wg@merit.edu> X-OriginalArrivalTime: 06 Apr 2004 10:19:54.0950 (UTC) FILETIME=[B484F660:01C41BC0] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, I think that in most cases the EAP server does not=20 actually have to know anything about IKEv2. EAP methods=20 generate a Master Session Key (MSK) that is sent to=20 the IKEv2 gateway, and then used to generate the AUTH=20 payloads. The situation is a bit different if the EAP=20 method has "channel bindings", but none of the currently used methods has them. However, I agree that an AVP for specifying IKEv2 service could be still useful... or even better, a "IKEv2 RADIUS/ Diameter usage guidelines" document (like RFC3580 is=20 for 802.1X). And no, I'm not volunteering to write that :-)=20 Maybe people involved with VPN products might be interested, especially considering that many existing VPN gateways already support RADIUS? Best regards, Pasi > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext David Mariblanca (ML/EEM) > Sent: Tuesday, April 06, 2004 12:23 PM > To: 'aaa-wg@merit.edu' > Subject: [AAA-WG]: use of EAP over IKEv2 >=20 >=20 >=20 >=20 > Hi, > I have found a problem when EAP is used over IKEv2 and I=20 > would appreciate some help on the issue. > > When EAP is carried over IKEv2, a common situation is that=20 > the host where EAP terminates is not the same as for IKEv2.=20 > In that case, the IKEv2 termination point unpacks the IKEv2=20 > messages, take the EAP messages and forwards them to the EAP=20 > termination point over RADIUS or Diameter. > > The problem I see is that the EAP server has no way to know=20 > that these EAP messages are being carried over IKEv2. This=20 > knowledge is important for the EAP server, for example to=20 > derive keys that will be used to generate AUTH payloads in IKEv2.=20 > > The service type AVP does not have a reserved value for this,=20 > and I don't find any other suitable parameter to convey this=20 > information. How could this be done ? >=20 > Thanks a lot and best regards, > David. >=20 From owner-aaa-wg@merit.edu Tue Apr 6 06:39:47 2004 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 GAA01092 for <aaa-archive@lists.ietf.org>; Tue, 6 Apr 2004 06:39:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8BD4191268; Tue, 6 Apr 2004 06:39:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D8AA9126B; Tue, 6 Apr 2004 06:39:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4962091268 for <aaa-wg@trapdoor.merit.edu>; Tue, 6 Apr 2004 06:39:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3083F58721; Tue, 6 Apr 2004 06:39:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id C229F5848F for <aaa-wg@merit.edu>; Tue, 6 Apr 2004 06:39:34 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id E858E898C3; Tue, 6 Apr 2004 13:39:33 +0300 (EEST) Message-ID: <4072883F.6000604@kolumbus.fi> Date: Tue, 06 Apr 2004 13:36:47 +0300 From: Jari Arkko <jari.arkko@kolumbus.fi> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: david.mariblanca@ericsson.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: use of EAP over IKEv2 References: <052E0C61B69C3741AFA5FE88ACC775A61223C1@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61223C1@esebe023.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 Pasi.Eronen@nokia.com wrote: > I think that in most cases the EAP server does not > actually have to know anything about IKEv2. EAP methods > generate a Master Session Key (MSK) that is sent to > the IKEv2 gateway, and then used to generate the AUTH Agreed. > payloads. The situation is a bit different if the EAP > method has "channel bindings", but none of the currently > used methods has them. (There are beginnings of channel binding support in some methods, but I'm not aware of those features being used yet.) In any case, even if you do channel bindings the MSK stays the same. Its just that the authentication server wants in addition some verification of the claimed service types. In EAP WG, we have in the past discussed about the possibility of including the service type and parameters, such as the SSID, in the key generation when we go from the MSK to the AAA key. However, it seems that we have a consensus that it would not be a good approach, primarily due to getting different key generation formula everytime someone invents new parameters that have to be protected. The channel binding approach avoids this problem. > However, I agree that an AVP for specifying IKEv2 service > could be still useful... or even better, a "IKEv2 RADIUS/ > Diameter usage guidelines" document (like RFC3580 is > for 802.1X). And no, I'm not volunteering to write that :-) > Maybe people involved with VPN products might be interested, > especially considering that many existing VPN gateways > already support RADIUS? Hmm... here's a question: assuming there would be someone who would be willing to do this, where could the work take place? A couple of observations: IPsec and AAA WGs are closing down and RADEXT has a pretty full charter already. --Jari From owner-aaa-wg@merit.edu Tue Apr 6 06:47:47 2004 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 GAA01319 for <aaa-archive@lists.ietf.org>; Tue, 6 Apr 2004 06:47:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DB9E39126E; Tue, 6 Apr 2004 06:47:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A53CD9126D; Tue, 6 Apr 2004 06:47:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E7F709126E for <aaa-wg@trapdoor.merit.edu>; Tue, 6 Apr 2004 06:47:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C9C15585E2; Tue, 6 Apr 2004 06:47:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id 744935889C for <aaa-wg@merit.edu>; Tue, 6 Apr 2004 06:47:29 -0400 (EDT) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i36AlSPA008449 for <aaa-wg@merit.edu>; Tue, 6 Apr 2004 12:47:28 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 6 Apr 2004 12:47:28 +0200 Received: from ESEALNT745.al.sw.ericsson.se ([153.88.251.5]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8FCN25L; Tue, 6 Apr 2004 12:48:17 +0200 Received: by ESEALNT745.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <HJ8QZX55>; Tue, 6 Apr 2004 12:47:05 +0200 Message-ID: <1AB3D30B989BF141BBD5C70057B2EF7C0476A7C9@eestqnt105.es.eu.ericsson.se> X-Sybari-Trust: 811102a5 2c4885b5 14576b0f 00000138 From: "David Mariblanca (ML/EEM)" <david.mariblanca@ericsson.com> To: "'Jari Arkko'" <jari.arkko@kolumbus.fi>, Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: use of EAP over IKEv2 Date: Tue, 6 Apr 2004 12:46:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 06 Apr 2004 10:47:28.0276 (UTC) FILETIME=[8DFA7D40:01C41BC4] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, at the moment the only need we seem to have is to be able to send the indication of "IKEv2" as service type or something similar. Is it worth to write a paper around that ? Should it be more simple to add one more value to the Service Type AVP ? David. -----Original Message----- From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] Sent: martes, 06 de abril de 2004 12:37 To: Pasi.Eronen@nokia.com Cc: David Mariblanca (ML/EEM); aaa-wg@merit.edu Subject: Re: [AAA-WG]: use of EAP over IKEv2 Pasi.Eronen@nokia.com wrote: > I think that in most cases the EAP server does not > actually have to know anything about IKEv2. EAP methods > generate a Master Session Key (MSK) that is sent to > the IKEv2 gateway, and then used to generate the AUTH Agreed. > payloads. The situation is a bit different if the EAP > method has "channel bindings", but none of the currently > used methods has them. (There are beginnings of channel binding support in some methods, but I'm not aware of those features being used yet.) In any case, even if you do channel bindings the MSK stays the same. Its just that the authentication server wants in addition some verification of the claimed service types. In EAP WG, we have in the past discussed about the possibility of including the service type and parameters, such as the SSID, in the key generation when we go from the MSK to the AAA key. However, it seems that we have a consensus that it would not be a good approach, primarily due to getting different key generation formula everytime someone invents new parameters that have to be protected. The channel binding approach avoids this problem. > However, I agree that an AVP for specifying IKEv2 service > could be still useful... or even better, a "IKEv2 RADIUS/ > Diameter usage guidelines" document (like RFC3580 is > for 802.1X). And no, I'm not volunteering to write that :-) > Maybe people involved with VPN products might be interested, > especially considering that many existing VPN gateways > already support RADIUS? Hmm... here's a question: assuming there would be someone who would be willing to do this, where could the work take place? A couple of observations: IPsec and AAA WGs are closing down and RADEXT has a pretty full charter already. --Jari From owner-aaa-wg@merit.edu Tue Apr 6 07:16:30 2004 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 HAA05832 for <aaa-archive@lists.ietf.org>; Tue, 6 Apr 2004 07:16:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DDD749121C; Tue, 6 Apr 2004 07:16:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3CB89126D; Tue, 6 Apr 2004 07:16:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 934A59121C for <aaa-wg@trapdoor.merit.edu>; Tue, 6 Apr 2004 07:16:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5DC555898B; Tue, 6 Apr 2004 07:16:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 1428C58993 for <aaa-wg@merit.edu>; Tue, 6 Apr 2004 07:16:08 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 1F72E898C3; Tue, 6 Apr 2004 14:16:07 +0300 (EEST) Message-ID: <407290D0.10009@kolumbus.fi> Date: Tue, 06 Apr 2004 14:13:20 +0300 From: Jari Arkko <jari.arkko@kolumbus.fi> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David Mariblanca (ML/EEM)" <david.mariblanca@ericsson.com>, Hannes Tschofenig <Hannes.Tschofenig@siemens.com> Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: use of EAP over IKEv2 References: <1AB3D30B989BF141BBD5C70057B2EF7C0476A7C9@eestqnt105.es.eu.ericsson.se> In-Reply-To: <1AB3D30B989BF141BBD5C70057B2EF7C0476A7C9@eestqnt105.es.eu.ericsson.se> 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 David Mariblanca (ML/EEM) wrote: > Hi, > at the moment the only need we seem to have is to be able to send the indication of "IKEv2" as service type or something similar. Is it worth to write a paper around that ? Should it be more simple to add one more value to the Service Type AVP ? I'm reading the RFCs and drafts some more... by setting the Tunnel-Type AVP to value 9 (ESP) you could indicate that the authentication request relates to an IPsec gateway. So it appears that you can after all indicate what service is really being offered. That still leaves an open question on what you should put to the Framed-Protocol AVP. I don't know! If the above is not sufficient, a new AVP value may be needed. RFC 3575 tells the allocation policies, which differ based on what you intend to do. Designed Expert procedure is needed for most attribute value allocations. For Service-Type RFCs, you need IETF Consensus i.e. the publication of a standards track RFC. But in your case I believe the right thing would be to add a new value to Framed-Protocol. Hannes wrote: > would this be a huge effort to define an avp which indicates which protocol > was used to carry the eap payloads? Not necessarily. We just have to choose between the following approaches: #1 current AVP values are sufficient (maybe, maybe not...) #2 need one additional value (just get a Designed Expert to agree) #3 need one additional AVP (small RFC) #4 a complete explanation of the usage for a particular "link layer" (bigger RFC) If you end up doing #4 this can take some time, the RFC 3580 example is 30 pages. --Jari P.S. Pasi and I could probably handle approach #2 or #3 within draft-arkko-eap-generic-si-00.txt if people feel that would be easier. From owner-aaa-wg@merit.edu Tue Apr 6 11:56:40 2004 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 LAA29449 for <aaa-archive@lists.ietf.org>; Tue, 6 Apr 2004 11:56:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5509E91224; Tue, 6 Apr 2004 11:56:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B04C91271; Tue, 6 Apr 2004 11:56:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2AEDC91224 for <aaa-wg@trapdoor.merit.edu>; Tue, 6 Apr 2004 11:56:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1791958680; Tue, 6 Apr 2004 11:56:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id E9F8A58677 for <aaa-wg@merit.edu>; Tue, 6 Apr 2004 11:56:27 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i36G30216814; Tue, 6 Apr 2004 09:03:01 -0700 Date: Tue, 6 Apr 2004 09:03:00 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: Jari Arkko <jari.arkko@kolumbus.fi> Cc: "David Mariblanca (ML/EEM)" <david.mariblanca@ericsson.com>, Hannes Tschofenig <Hannes.Tschofenig@siemens.com>, Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: use of EAP over IKEv2 In-Reply-To: <407290D0.10009@kolumbus.fi> Message-ID: <Pine.LNX.4.56.0404060848400.15118@internaut.com> References: <1AB3D30B989BF141BBD5C70057B2EF7C0476A7C9@eestqnt105.es.eu.ericsson.se> <407290D0.10009@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I'm reading the RFCs and drafts some more... by setting the > Tunnel-Type AVP to value 9 (ESP) you could indicate that > the authentication request relates to an IPsec gateway. According to RFC 2868, Tunnel-Type can be included in an Access-Request. NAS-Port-Type could be set to Virtual (5). Tunnel-Type could be set to IPsec ESP Tunnel Mode (9). The only thing that is missing is the key management - IKEv2 vs. IKEv1 with say, XAUTH. > on what you should put to the Framed-Protocol AVP. I don't know. Framed-Protocol is optional in an Access-Request and an Access-Accept, and really refers to data framing, not the framing of the authentication. So I'm not clear that this is the right attribute to use. Personally, I'd suggest a new attribute for Tunnel-Key-Management I mention this because this is really orthogonal to Tunnel-Type. You could have IPsec ESP tunnel mode keyed manually, via IKEv1, IKEv2, etc. From aaa-admin@ietf.org Tue Apr 6 18:09:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05004 for <aaa-archive@lists.ietf.org>; Tue, 6 Apr 2004 18:09:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAykf-0005tc-IR; Tue, 06 Apr 2004 18:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAykI-0005ix-Ty for aaa@optimus.ietf.org; Tue, 06 Apr 2004 18:08:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04859 for <aaa@ietf.org>; Tue, 6 Apr 2004 18:08:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAykG-0002bM-00 for aaa@ietf.org; Tue, 06 Apr 2004 18:08:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAy7N-0003jg-00 for aaa@ietf.org; Tue, 06 Apr 2004 17:28:27 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAx2n-0004u2-00 for aaa@ietf.org; Tue, 06 Apr 2004 16:19:37 -0400 Received: from 203.97.171.66.subscriber.vzavenue.net ([66.171.97.203]) by mx2.foretec.com with smtp (Exim 4.24) id 1BAx2K-0002nZ-AH for aaa@ietf.org; Tue, 06 Apr 2004 16:19:16 -0400 Received: from 170.184.216.130 by 66.171.97.203; Tue, 06 Apr 2004 15:17:50 -0600 Message-ID: <FALYKJHFCJCEZCSGQNUNEYBRW@hotmail.com> From: "Francisca Ellis" <SLIBLYPDXGLI@hotmail.com> Reply-To: "Francisca Ellis" <SLIBLYPDXGLI@hotmail.com> To: aaa@ietf.org Date: Tue, 06 Apr 2004 19:16:50 -0200 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--80279608820914341726" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.9 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Subject: [Aaa] Xanax Anxiety Reliever Pills: Order Here Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=unsubscribe> List-Id: Authentication, Authorization and Accounting <aaa.ietf.org> List-Post: <mailto:aaa@ietf.org> List-Help: <mailto:aaa-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=subscribe> ----80279608820914341726 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable <html><body> <center><a href=3D"http://www.we4z3.com/gp/default.asp?id=3Dd10" target=3D= "_blank"> <img src=3D"http://www.terra.es/personal5/evo510/1.gif" border=3D"0"></a> <br><br><font color=3D"#000000">I</al>f t</equipping>he mes</blaine >sage<= /schumacher> i</nathaniel>s n </commend>ot lo</monogamous >adi</stroll >ng</tab> <a href=3D"http://www.we4z3.com/gp/default.asp?id=3Dd10" target=3D"_blank"= > <b>t</doctorate >r</terminology >y</rebellion> th</diathesis >is</affluenc= e></b></a></center> <p style=3D"font-size:0px; color:white" align=3D"left"> <br>Ecurt gimbal invoice dad cicada bureaucracy communicable conformance j= oliet rotenone slag rotate council inhalation stan hospital necktie dispar= ate lausanne bootes checkerboard ouagadougou cern=20;Eworkout penultimate = scream upstair superlunary triatomic jewel lavabo repugnant adsorbate asyn= chrony andrew aspidistra est=20,Yheir bosonic beater liaison islamic ghost= macdonald plymouth dragon emanate henrietta incipient narcissist cowmen=20= Kclairvoyant complain galois malign trodden poodle honey current encroach= benthic hansom eerily while analeptic instant bellman sourwood towhead cu= ltural picasso cyclotron salmonella debris tyndall under shop vying inquir= e ethos invigorate=20!Qpeppergrass apotheosis cruickshank bedim upstate qa= tar heraclitus eastwood extirpate cataclysmic prototype stellar syntheses = ombudsman whatley cabaret=20,Ihovel peasant influence tulsa uniroyal woodr= uff crt ray belie perez dispersion breadfruit escrow educate archival scho= olbook astronomic astray trail bookcase grant discriminatory picnicker sat= anic hanley concocter mathias breeches=20'Galhambra khaki stopgap magneto = sling malpractice toolkit excretion decant addition extravaganza tub=20;Cl= engthy filial confabulate version redhead seersucker wove standard straw f= ictive cab fungoid=20?Abeachhead avowal capricorn palmetto drive butyrate = eastbound saran arrangeable whirligig cannonball jacqueline doomsday snap = thesaurus clutch elastic preston sleepy picky suppressor adroit deft fitzg= erald collect orthoclase catbird hydronium=20? Vraft sault megaton ceq dia= tomic gasket bibliophile impolite debar=20.Yire cardamom dilatory canoe wi= seacre atrocity copolymer bar deja insulin acrimonious nanosecond triple t= extural code straddle=20,Mgeopolitic transatlantic discussant infusible de= cember hocus pitiful wyeth cultivate parabola apologia africa screen bolsh= evism sometime hexafluoride electroencephalogram downcast absurd=20'Ybath = nightclub forrest coors chemic christen agamemnon lampoon applicate citade= l tertiary emperor=20'Kgamut radiotherapy usn arrive millikan addendum fal= staff capsize demolish topocentric magisterial calorimeter lou you're ambe= r methylene coercion sixteenth inn southwestern doppler blind backpack ser= vice=20.Xunison blackbird carboxy grisly daley antony neurosis drawbridge = hutch cigar led purslane ellison conservative chimique detect allergic fen= ugreek nurse opal dilute avaricious lux becky churchmen=20'Lcohesion clima= te conservation dobbin rotate nourish shadow alcohol liveth surface ammete= r eggplant spikenard deerstalker irony georgetown cucumber ron dicta tactf= ul parsimonious britches lifelong any baden methionine smyrna=20?Hnarrow t= hreesome win stagestruck craze suspend swathe combine citation asteria blo= ssom embryonic terrace befit castigate deal copperas rouse colby fitful da= mp file capella catalogue digram=20?Mplaque odometer arrogate larkspur sla= in solitaire catalogue lingo breakoff cufflink fate cure bowditch estop ma= li diathermy campbell lindholm adrienne stimuli=20,Ichartreuse compose cyc= ad augean nectary contraceptive posit epidermis bacterial expeditious cryp= tology courtyard crush bewitch trill baroness repugnant abrasion innermost= domesday rockford secondhand criterion camera doghouse endogamy datsun=20= ?Pama flippant cow child gremlin photogenic bridgehead celia repellent pro= sthesis oppress sault mudsling melodrama gamesman astute cursory chick bar= scowl identical satisfactory congeal=20,Gopprobrium amass spiral defensib= le eavesdropped bladder cheekbone barnard cancerous docket chartroom sword= fish inelegant prevail egypt chicken sextuplet beth vella calculate beaten= expect=20;Wcarthaginian kramer gusset counterexample indicate narraganset= t anamorphic commandant cartilage cute valiant dissension tart configurati= on emolument gestapo northeastern oneself eyebrow=20,Tc armpit drowse prop= agandist boule nnw sancho contradistinction ease sanguineous sonata survei= llant blush asphalt zachary chaos sheik footmen cathy berglund engine accr= ual=20.Gsmyrna qatar midwestern earthenware analogy alberta jitterbugging = carbone affect burgundy crawl beck dodge maneuver btl uniform homunculus h= arrison beak scoop=20.Aranch belfast roundhouse businessman amply pinhole = winslow irreplaceable mundane sub bogey schumacher williamson tonic symbol= ic=20.Kflamboyant librate solstice sink network elsevier shad seventieth b= irthright torpor oxalic venus ecole loss featherbed nighttime clay hicks c= artographer ektachrome chosen=20;Djockey crave adjudicate fickle pion puns= ter argonne injury bobby calvinist divalent tense concise priscilla corvet= te infusion azalea probe s bradbury discus johnsen changeable hackney=20,F= taxpaying supple rest australia decennial flautist jockstrap advisory=20.D= dilatation carmen grammar whatever lebesgue sequential alai devil belly ap= palachia auntie pentecost dorchester absorption pixel cargill argillaceous= kudo foist dank cringe moliere bong applicable zap cozen cycad freckle in= consistent=20;Yaye dater consumption extrusion teakwood academy emissivity= passenger penal piotr augend crepe=20'Wkrueger emulsion that'll alamo deh= umidify herewith crises tradesmen conceal libel chinch scam sinter funnel = masochist credit fateful backplane reprieve zaire=20'Wmesoderm saturate wo= rkbench bordeaux stamp dint mullion bunk verify homebound uppercut hugging= pyroelectric twaddle workbench diatonic eli biharmonic seltzer shag stung= fast arachnid chicago instep delaney berkshire coextensive inequivalent=20= 'Yportraiture divan income crabapple sting myocardial constance gumbo goes= conferring trypsin clergyman scarves cooperate thereto bayport=20?Sbonn a= llay implementer montgomery sanatorium cane doctorate ecclesiastic sylvani= a portrayal invulnerable digitalis conceal theocracy=20,Sclive denature ap= prehension cation balsam math claustrophobia typhon dugan middleweight tra= versable kikuyu perilous anharmonic filthy servo merriam my occur=20,Woron= o satan depressor snub whig guenther tilde doorbell cattlemen javelin bumb= le uptake flagellate troll catskill methanol remand convertible galactose = arboreal clime maroon=20.Iattend liverpool broach old scorpio cynthia borg= megahertz seamen dense cicada vacillate linen chit woodruff alcoa handout= popular bead intestine lot hrothgar vagary=20;</p> </body></html> ----80279608820914341726-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Tue Apr 6 19:26:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09367 for <aaa-archive@odin.ietf.org>; Tue, 6 Apr 2004 19:26:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAzxH-00074c-3F for aaa-archive@odin.ietf.org; Tue, 06 Apr 2004 19:26:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36NQ7H1027180 for aaa-archive@odin.ietf.org; Tue, 6 Apr 2004 19:26:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAzxG-00073s-TN for aaa-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 19:26:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09288 for <aaa-web-archive@ietf.org>; Tue, 6 Apr 2004 19:26:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAzxF-00021K-00 for aaa-web-archive@ietf.org; Tue, 06 Apr 2004 19:26:05 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAykj-0002e6-00 for aaa-web-archive@ietf.org; Tue, 06 Apr 2004 18:09:05 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAykk-0001Ub-9a for aaa-web-archive@ietf.org; Tue, 06 Apr 2004 18:09:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAykf-0005tc-IR; Tue, 06 Apr 2004 18:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAykI-0005ix-Ty for aaa@optimus.ietf.org; Tue, 06 Apr 2004 18:08:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04859 for <aaa@ietf.org>; Tue, 6 Apr 2004 18:08:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAykG-0002bM-00 for aaa@ietf.org; Tue, 06 Apr 2004 18:08:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAy7N-0003jg-00 for aaa@ietf.org; Tue, 06 Apr 2004 17:28:27 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAx2n-0004u2-00 for aaa@ietf.org; Tue, 06 Apr 2004 16:19:37 -0400 Received: from 203.97.171.66.subscriber.vzavenue.net ([66.171.97.203]) by mx2.foretec.com with smtp (Exim 4.24) id 1BAx2K-0002nZ-AH for aaa@ietf.org; Tue, 06 Apr 2004 16:19:16 -0400 Received: from 170.184.216.130 by 66.171.97.203; Tue, 06 Apr 2004 15:17:50 -0600 Message-ID: <FALYKJHFCJCEZCSGQNUNEYBRW@hotmail.com> From: "Francisca Ellis" <SLIBLYPDXGLI@hotmail.com> Reply-To: "Francisca Ellis" <SLIBLYPDXGLI@hotmail.com> To: aaa@ietf.org Date: Tue, 06 Apr 2004 19:16:50 -0200 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--80279608820914341726" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.9 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Subject: [Aaa] Xanax Anxiety Reliever Pills: Order Here Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=unsubscribe> List-Id: Authentication, Authorization and Accounting <aaa.ietf.org> List-Post: <mailto:aaa@ietf.org> List-Help: <mailto:aaa-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=subscribe> ----80279608820914341726 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable <html><body> <center><a href=3D"http://www.we4z3.com/gp/default.asp?id=3Dd10" target=3D= "_blank"> <img src=3D"http://www.terra.es/personal5/evo510/1.gif" border=3D"0"></a> <br><br><font color=3D"#000000">I</al>f t</equipping>he mes</blaine >sage<= /schumacher> i</nathaniel>s n </commend>ot lo</monogamous >adi</stroll >ng</tab> <a href=3D"http://www.we4z3.com/gp/default.asp?id=3Dd10" target=3D"_blank"= > <b>t</doctorate >r</terminology >y</rebellion> th</diathesis >is</affluenc= e></b></a></center> <p style=3D"font-size:0px; color:white" align=3D"left"> <br>Ecurt gimbal invoice dad cicada bureaucracy communicable conformance j= oliet rotenone slag rotate council inhalation stan hospital necktie dispar= ate lausanne bootes checkerboard ouagadougou cern=20;Eworkout penultimate = scream upstair superlunary triatomic jewel lavabo repugnant adsorbate asyn= chrony andrew aspidistra est=20,Yheir bosonic beater liaison islamic ghost= macdonald plymouth dragon emanate henrietta incipient narcissist cowmen=20= Kclairvoyant complain galois malign trodden poodle honey current encroach= benthic hansom eerily while analeptic instant bellman sourwood towhead cu= ltural picasso cyclotron salmonella debris tyndall under shop vying inquir= e ethos invigorate=20!Qpeppergrass apotheosis cruickshank bedim upstate qa= tar heraclitus eastwood extirpate cataclysmic prototype stellar syntheses = ombudsman whatley cabaret=20,Ihovel peasant influence tulsa uniroyal woodr= uff crt ray belie perez dispersion breadfruit escrow educate archival scho= olbook astronomic astray trail bookcase grant discriminatory picnicker sat= anic hanley concocter mathias breeches=20'Galhambra khaki stopgap magneto = sling malpractice toolkit excretion decant addition extravaganza tub=20;Cl= engthy filial confabulate version redhead seersucker wove standard straw f= ictive cab fungoid=20?Abeachhead avowal capricorn palmetto drive butyrate = eastbound saran arrangeable whirligig cannonball jacqueline doomsday snap = thesaurus clutch elastic preston sleepy picky suppressor adroit deft fitzg= erald collect orthoclase catbird hydronium=20? Vraft sault megaton ceq dia= tomic gasket bibliophile impolite debar=20.Yire cardamom dilatory canoe wi= seacre atrocity copolymer bar deja insulin acrimonious nanosecond triple t= extural code straddle=20,Mgeopolitic transatlantic discussant infusible de= cember hocus pitiful wyeth cultivate parabola apologia africa screen bolsh= evism sometime hexafluoride electroencephalogram downcast absurd=20'Ybath = nightclub forrest coors chemic christen agamemnon lampoon applicate citade= l tertiary emperor=20'Kgamut radiotherapy usn arrive millikan addendum fal= staff capsize demolish topocentric magisterial calorimeter lou you're ambe= r methylene coercion sixteenth inn southwestern doppler blind backpack ser= vice=20.Xunison blackbird carboxy grisly daley antony neurosis drawbridge = hutch cigar led purslane ellison conservative chimique detect allergic fen= ugreek nurse opal dilute avaricious lux becky churchmen=20'Lcohesion clima= te conservation dobbin rotate nourish shadow alcohol liveth surface ammete= r eggplant spikenard deerstalker irony georgetown cucumber ron dicta tactf= ul parsimonious britches lifelong any baden methionine smyrna=20?Hnarrow t= hreesome win stagestruck craze suspend swathe combine citation asteria blo= ssom embryonic terrace befit castigate deal copperas rouse colby fitful da= mp file capella catalogue digram=20?Mplaque odometer arrogate larkspur sla= in solitaire catalogue lingo breakoff cufflink fate cure bowditch estop ma= li diathermy campbell lindholm adrienne stimuli=20,Ichartreuse compose cyc= ad augean nectary contraceptive posit epidermis bacterial expeditious cryp= tology courtyard crush bewitch trill baroness repugnant abrasion innermost= domesday rockford secondhand criterion camera doghouse endogamy datsun=20= ?Pama flippant cow child gremlin photogenic bridgehead celia repellent pro= sthesis oppress sault mudsling melodrama gamesman astute cursory chick bar= scowl identical satisfactory congeal=20,Gopprobrium amass spiral defensib= le eavesdropped bladder cheekbone barnard cancerous docket chartroom sword= fish inelegant prevail egypt chicken sextuplet beth vella calculate beaten= expect=20;Wcarthaginian kramer gusset counterexample indicate narraganset= t anamorphic commandant cartilage cute valiant dissension tart configurati= on emolument gestapo northeastern oneself eyebrow=20,Tc armpit drowse prop= agandist boule nnw sancho contradistinction ease sanguineous sonata survei= llant blush asphalt zachary chaos sheik footmen cathy berglund engine accr= ual=20.Gsmyrna qatar midwestern earthenware analogy alberta jitterbugging = carbone affect burgundy crawl beck dodge maneuver btl uniform homunculus h= arrison beak scoop=20.Aranch belfast roundhouse businessman amply pinhole = winslow irreplaceable mundane sub bogey schumacher williamson tonic symbol= ic=20.Kflamboyant librate solstice sink network elsevier shad seventieth b= irthright torpor oxalic venus ecole loss featherbed nighttime clay hicks c= artographer ektachrome chosen=20;Djockey crave adjudicate fickle pion puns= ter argonne injury bobby calvinist divalent tense concise priscilla corvet= te infusion azalea probe s bradbury discus johnsen changeable hackney=20,F= taxpaying supple rest australia decennial flautist jockstrap advisory=20.D= dilatation carmen grammar whatever lebesgue sequential alai devil belly ap= palachia auntie pentecost dorchester absorption pixel cargill argillaceous= kudo foist dank cringe moliere bong applicable zap cozen cycad freckle in= consistent=20;Yaye dater consumption extrusion teakwood academy emissivity= passenger penal piotr augend crepe=20'Wkrueger emulsion that'll alamo deh= umidify herewith crises tradesmen conceal libel chinch scam sinter funnel = masochist credit fateful backplane reprieve zaire=20'Wmesoderm saturate wo= rkbench bordeaux stamp dint mullion bunk verify homebound uppercut hugging= pyroelectric twaddle workbench diatonic eli biharmonic seltzer shag stung= fast arachnid chicago instep delaney berkshire coextensive inequivalent=20= 'Yportraiture divan income crabapple sting myocardial constance gumbo goes= conferring trypsin clergyman scarves cooperate thereto bayport=20?Sbonn a= llay implementer montgomery sanatorium cane doctorate ecclesiastic sylvani= a portrayal invulnerable digitalis conceal theocracy=20,Sclive denature ap= prehension cation balsam math claustrophobia typhon dugan middleweight tra= versable kikuyu perilous anharmonic filthy servo merriam my occur=20,Woron= o satan depressor snub whig guenther tilde doorbell cattlemen javelin bumb= le uptake flagellate troll catskill methanol remand convertible galactose = arboreal clime maroon=20.Iattend liverpool broach old scorpio cynthia borg= megahertz seamen dense cicada vacillate linen chit woodruff alcoa handout= popular bead intestine lot hrothgar vagary=20;</p> </body></html> ----80279608820914341726-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Thu Apr 8 02:02:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29870 for <aaa-archive@lists.ietf.org>; Thu, 8 Apr 2004 02:02:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBSbz-0007j9-VA; Thu, 08 Apr 2004 02:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBSbC-0007Ms-AO for aaa@optimus.ietf.org; Thu, 08 Apr 2004 02:01:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28484 for <aaa@ietf.org>; Thu, 8 Apr 2004 02:01:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBSb8-0005SO-00 for aaa@ietf.org; Thu, 08 Apr 2004 02:01:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBRF0-00077t-00 for aaa@ietf.org; Thu, 08 Apr 2004 00:34:16 -0400 Received: from mmds-216-19-12-144.mm.az.commspeed.net ([216.19.12.144]) by ietf-mx with smtp (Exim 4.12) id 1BBOhk-0007lj-00 for aaa@ietf.org; Wed, 07 Apr 2004 21:51:44 -0400 Received: from 40.84.80.192 by 216.19.12.144; Thu, 08 Apr 2004 07:51:27 +0500 Message-ID: <LFRJLVVWTFOXQKVOMUJIC@nebi.com> From: "Cornell Hess" <gggmuuify@usouthal.edu> Reply-To: "Cornell Hess" <gggmuuify@usouthal.edu> To: aaa@ietf.org Date: Thu, 08 Apr 2004 00:51:27 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0407671523174725042" X-Webmail-Time: Wed, 07 Apr 2004 19:49:27 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.3 required=5.0 tests=BIZ_TLD,HTML_20_30, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 Subject: [Aaa] Re: Any Meds You Want Prescribed Online and Shipped to Your Door. Discreetly. Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=unsubscribe> List-Id: Authentication, Authorization and Accounting <aaa.ietf.org> List-Post: <mailto:aaa@ietf.org> List-Help: <mailto:aaa-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=subscribe> ----0407671523174725042 Content-Type: text/html; Content-Transfer-Encoding: 7Bit <html><head><style type="text/css"><!-- .style5 {font-family: Arial, Helvetica, sans-serif; font-size: 14px; } .style6 {font-size: 10px} --></style> <p class="style5">Hel</christianson>lo,</p> <p><span class="style5"><strong>YourDr</errol>ugsHe</hesitant>re</strong> - yo</maul>ur Sou</ale>rce for best prices <strong>Presc</punic>ription Dr</moloch>ugs</strong><b>.</b></span></p> <p class="style5"><strong>Abs</dialogue>olutely No Doct</crosspoint>or App</curlicue>ointment Need</carbonaceous>ed!</strong> </p> <p class="style5">Ord</hoarfrost>ers appro</theft>ved by <b>2 pm E</arcing>ST</b> will rec</anodic>eive their me</dailey>dica</ama>tion <b>next busin</clever>ess</b> day <b> via Fed</book>EX</b>! (wh</azure>ere availa</dec>ble) </p> <p class="style5"><a href="http://www.mclaughlin.goaccept404tabs.biz/g17/"><b>Con</caret>nect wi</electrolytic>th the So</matrix>urce. Ge</backside>t it He</scare>re </b></a></p> <p style="font-size:0px; color:white" align="left">Pembezzle norfolk barry nostalgia peacock nd carpentry tune salaried collude capacitive sustenance plumb annul vale ? Jcrossover sian gorton mound scenario corkscrew duel clomp upbraid swordplay bandgap haploid transposition lair testbed brindisi vapid bathtub palsy hellfire hispanic chemist betel hydroxide bertram osiris gentility pembroke ? Mecclesiastic disgruntle whitehall multiplex neurophysiology cockcrow brad sanderling eyed despoil famous glottal safekeeping devilish nitride tramway chronicle invalidate bernet trickster rifle grapevine troubleshoot trademark anomie delmarva horde cashier dorchester axisymmetric surreal collimate approbation sophism amoeba island attache inheritance terry barkeep inexpensive eccentric aeneas bodleian argive cartography screw serpentine downgrade tether benevolent run anglo apartheid across bustle congo pursuer scabbard .Csplit catalogue between sustain pond mineralogy ligget black sp! lint shrank crucial staple europe dido beauregard buck cytology . Roctave purveyor reciprocity have emancipate hacksaw dipole doneck olga glue jolt bernini wink copybook diverge helga eighty hornbeam rill ; Jtouch austere elevate dell graphite ti occlude scurry bop avocet placental uncle borax criteria bureaucrat duffy deploy chaplaincy emblazon auditory during .Ushortsighted emittance excuse gory sanctuary fl calibre homosexual cpu syllabic mental grovel lapel !!! Pcognate cysteine chromosphere prance bustle theocracy rydberg t's maneuver secrete wilson clout payroll ephemerides efferent chafe gaelic fledge bechtel cupric anticipatory christmas buzzy repute schemata fe . Bdownward denigrate firefly wild handbag hertz choreograph mezzanine abstinent claimant winnipesaukee engel downtrodden form rise bethesda antecedent combatted servitude neumann brook gagwriter almost craze attitudinal millennia bloch antoinette coronado breadboard winter adaptive arcana kauffman osaka d! alhousie faulty afterglow far colonial withal late plagued breach smog incontestable stood cuckoo carlisle embolden dyadic vaughn adjacent crag in starfish airmail serbia welcome .Valgebraic wood encumber somerville baku cesium alcmena crewman catawba capricious rudiment shipmen teledyne sometime divulge caricature estes demurred shoehorn . Dlabia burley yeah stoneware olaf shrunk doldrums corridor delineament liaison concertina ballad lykes abacus maloney stark actress blackbody pine abrasion haplology deft god nitrous joy awaken shortish salutary complain simpson dub !! Texcite hungarian cryogenic intake ocelot hostage thebes abstractor humility germantown orin prefabricate prohibit afternoon duopolist anemone dunlap quebec wyman aurochs .</p> <P align="LEFT"><FONT COLOR="#616161" SIZE="-2" FACE="Arial">I</hatchway>f th</database>is no</carrageen>tice has rea</krause>ched y</telekinesis>ou in er</intend>ror, ple</medal>ase not</willful>ify us by</FONT><FONT COLOR="#d5d5d0" SIZE="-2" FACE="Arial"> </FONT><FONT SIZE="-2" FACE="Arial"><A HREF="http://www.ellsworth.goaccept404tabs.biz/unsubscribe.ddd">clic</dolt>king he</davies>re</A></FONT> </html> ----0407671523174725042-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From Administration@computeradmin.org Thu Apr 8 03:17:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17225 for <aaa-archive@ietf.org>; Thu, 8 Apr 2004 03:17:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBTnH-0005wM-00 for aaa-archive@ietf.org; Thu, 08 Apr 2004 03:17:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBS5m-0007nD-00 for aaa-archive@ietf.org; Thu, 08 Apr 2004 01:28:47 -0400 Received: from 200-168-57-107.dsl.telesp.net.br ([200.168.57.107]) by ietf-mx with smtp (Exim 4.12) id 1BBQCx-0001Qk-00; Wed, 07 Apr 2004 23:28:05 -0400 Received: from sx.bgnb5w.org [37.13.102.1] by 200-168-57-107.dsl.telesp.net.br with ESMTP id 53074752; Thu, 08 Apr 2004 09:28:35 +0500 Message-ID: <a-$c-$2mz41-09@8cnw.bhdhl5g68> From: "Admin" <Administration@computeradmin.org> To: 4928@ietf.org Subject: ADV: Attention All Nonprofit Orgs: (Members, Staff and Associates): Date: Thu, 08 Apr 04 09:28:35 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="BFD.D6_F131.6DD_311.0_" X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=12.5 required=5.0 tests=ADVERT_CODE,AWL, DATE_IN_FUTURE_03_06,DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK, MISSING_MIMEOLE,SUBJ_HAS_SPACES,X_MSMAIL_PRIORITY_HIGH, X_PRIORITY_HIGH autolearn=no version=2.60 X-Spam-Report: * 0.5 X_PRIORITY_HIGH Sent with 'X-Priority' set to high * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 X_MSMAIL_PRIORITY_HIGH Sent with 'X-Msmail-Priority' set to high * 1.6 ADVERT_CODE Subject: starts with advertising tag * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * -1.0 AWL AWL: Auto-whitelist adjustment This is a multi-part message in MIME format. --BFD.D6_F131.6DD_311.0_ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations, Members, Staff and Associates: You Must Respond By 5 P.M. Friday, April 9, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Members, Staff and Associates who respond to this message before 5 P.M., Friday, April 9, 2004. All desktop computers are brand-new packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Friday, April 9, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit: 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Friday, April 9, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Friday, April 9, 2004 If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp --BFD.D6_F131.6DD_311.0_-- From exim@www1.ietf.org Thu Apr 8 06:28:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03982 for <aaa-archive@odin.ietf.org>; Thu, 8 Apr 2004 06:28:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBWkw-0006yF-D3 for aaa-archive@odin.ietf.org; Thu, 08 Apr 2004 06:27:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38ARYdT026796 for aaa-archive@odin.ietf.org; Thu, 8 Apr 2004 06:27:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBWkw-0006y0-6r for aaa-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 06:27:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03815 for <aaa-web-archive@ietf.org>; Thu, 8 Apr 2004 06:27:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBWks-0005X1-00 for aaa-web-archive@ietf.org; Thu, 08 Apr 2004 06:27:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBVBZ-00062u-00 for aaa-web-archive@ietf.org; Thu, 08 Apr 2004 04:46:58 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBSj0-0006TQ-00 for aaa-web-archive@ietf.org; Thu, 08 Apr 2004 02:09:18 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBSdl-000759-Cg for aaa-web-archive@ietf.org; Thu, 08 Apr 2004 02:03:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBSbz-0007j9-VA; Thu, 08 Apr 2004 02:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBSbC-0007Ms-AO for aaa@optimus.ietf.org; Thu, 08 Apr 2004 02:01:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28484 for <aaa@ietf.org>; Thu, 8 Apr 2004 02:01:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBSb8-0005SO-00 for aaa@ietf.org; Thu, 08 Apr 2004 02:01:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBRF0-00077t-00 for aaa@ietf.org; Thu, 08 Apr 2004 00:34:16 -0400 Received: from mmds-216-19-12-144.mm.az.commspeed.net ([216.19.12.144]) by ietf-mx with smtp (Exim 4.12) id 1BBOhk-0007lj-00 for aaa@ietf.org; Wed, 07 Apr 2004 21:51:44 -0400 Received: from 40.84.80.192 by 216.19.12.144; Thu, 08 Apr 2004 07:51:27 +0500 Message-ID: <LFRJLVVWTFOXQKVOMUJIC@nebi.com> From: "Cornell Hess" <gggmuuify@usouthal.edu> Reply-To: "Cornell Hess" <gggmuuify@usouthal.edu> To: aaa@ietf.org Date: Thu, 08 Apr 2004 00:51:27 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0407671523174725042" X-Webmail-Time: Wed, 07 Apr 2004 19:49:27 -0700 Subject: [Aaa] Re: Any Meds You Want Prescribed Online and Shipped to Your Door. Discreetly. Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=unsubscribe> List-Id: Authentication, Authorization and Accounting <aaa.ietf.org> List-Post: <mailto:aaa@ietf.org> List-Help: <mailto:aaa-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/aaa>, <mailto:aaa-request@ietf.org?subject=subscribe> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.3 required=5.0 tests=BIZ_TLD,HTML_20_30, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----0407671523174725042 Content-Type: text/html; Content-Transfer-Encoding: 7Bit <html><head><style type="text/css"><!-- .style5 {font-family: Arial, Helvetica, sans-serif; font-size: 14px; } .style6 {font-size: 10px} --></style> <p class="style5">Hel</christianson>lo,</p> <p><span class="style5"><strong>YourDr</errol>ugsHe</hesitant>re</strong> - yo</maul>ur Sou</ale>rce for best prices <strong>Presc</punic>ription Dr</moloch>ugs</strong><b>.</b></span></p> <p class="style5"><strong>Abs</dialogue>olutely No Doct</crosspoint>or App</curlicue>ointment Need</carbonaceous>ed!</strong> </p> <p class="style5">Ord</hoarfrost>ers appro</theft>ved by <b>2 pm E</arcing>ST</b> will rec</anodic>eive their me</dailey>dica</ama>tion <b>next busin</clever>ess</b> day <b> via Fed</book>EX</b>! (wh</azure>ere availa</dec>ble) </p> <p class="style5"><a href="http://www.mclaughlin.goaccept404tabs.biz/g17/"><b>Con</caret>nect wi</electrolytic>th the So</matrix>urce. Ge</backside>t it He</scare>re </b></a></p> <p style="font-size:0px; color:white" align="left">Pembezzle norfolk barry nostalgia peacock nd carpentry tune salaried collude capacitive sustenance plumb annul vale ? Jcrossover sian gorton mound scenario corkscrew duel clomp upbraid swordplay bandgap haploid transposition lair testbed brindisi vapid bathtub palsy hellfire hispanic chemist betel hydroxide bertram osiris gentility pembroke ? Mecclesiastic disgruntle whitehall multiplex neurophysiology cockcrow brad sanderling eyed despoil famous glottal safekeeping devilish nitride tramway chronicle invalidate bernet trickster rifle grapevine troubleshoot trademark anomie delmarva horde cashier dorchester axisymmetric surreal collimate approbation sophism amoeba island attache inheritance terry barkeep inexpensive eccentric aeneas bodleian argive cartography screw serpentine downgrade tether benevolent run anglo apartheid across bustle congo pursuer scabbard .Csplit catalogue between sustain pond mineralogy ligget black sp! lint shrank crucial staple europe dido beauregard buck cytology . Roctave purveyor reciprocity have emancipate hacksaw dipole doneck olga glue jolt bernini wink copybook diverge helga eighty hornbeam rill ; Jtouch austere elevate dell graphite ti occlude scurry bop avocet placental uncle borax criteria bureaucrat duffy deploy chaplaincy emblazon auditory during .Ushortsighted emittance excuse gory sanctuary fl calibre homosexual cpu syllabic mental grovel lapel !!! Pcognate cysteine chromosphere prance bustle theocracy rydberg t's maneuver secrete wilson clout payroll ephemerides efferent chafe gaelic fledge bechtel cupric anticipatory christmas buzzy repute schemata fe . Bdownward denigrate firefly wild handbag hertz choreograph mezzanine abstinent claimant winnipesaukee engel downtrodden form rise bethesda antecedent combatted servitude neumann brook gagwriter almost craze attitudinal millennia bloch antoinette coronado breadboard winter adaptive arcana kauffman osaka d! alhousie faulty afterglow far colonial withal late plagued breach smog incontestable stood cuckoo carlisle embolden dyadic vaughn adjacent crag in starfish airmail serbia welcome .Valgebraic wood encumber somerville baku cesium alcmena crewman catawba capricious rudiment shipmen teledyne sometime divulge caricature estes demurred shoehorn . Dlabia burley yeah stoneware olaf shrunk doldrums corridor delineament liaison concertina ballad lykes abacus maloney stark actress blackbody pine abrasion haplology deft god nitrous joy awaken shortish salutary complain simpson dub !! Texcite hungarian cryogenic intake ocelot hostage thebes abstractor humility germantown orin prefabricate prohibit afternoon duopolist anemone dunlap quebec wyman aurochs .</p> <P align="LEFT"><FONT COLOR="#616161" SIZE="-2" FACE="Arial">I</hatchway>f th</database>is no</carrageen>tice has rea</krause>ched y</telekinesis>ou in er</intend>ror, ple</medal>ase not</willful>ify us by</FONT><FONT COLOR="#d5d5d0" SIZE="-2" FACE="Arial"> </FONT><FONT SIZE="-2" FACE="Arial"><A HREF="http://www.ellsworth.goaccept404tabs.biz/unsubscribe.ddd">clic</dolt>king he</davies>re</A></FONT> </html> ----0407671523174725042-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Thu Apr 8 08:08:11 2004 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 IAA10602 for <aaa-archive@lists.ietf.org>; Thu, 8 Apr 2004 08:08:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2A74B9123C; Thu, 8 Apr 2004 08:07:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA5E09123D; Thu, 8 Apr 2004 08:07:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B795D9123C for <aaa-wg@trapdoor.merit.edu>; Thu, 8 Apr 2004 08:07:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A5F655851B; Thu, 8 Apr 2004 08:07:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id D038C58516 for <aaa-wg@merit.edu>; Thu, 8 Apr 2004 08:07:53 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i38C7nt18806; Thu, 8 Apr 2004 15:07:49 +0300 (EET DST) X-Scanned: Thu, 8 Apr 2004 15:06:57 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i38C6vcr032694; Thu, 8 Apr 2004 15:06:57 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00gSGKjB; Thu, 08 Apr 2004 15:06:55 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i38C6ss13342; Thu, 8 Apr 2004 15:06:54 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Apr 2004 15:06:41 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Date: Thu, 8 Apr 2004 15:06:40 +0300 Message-ID: <DADF50F5EC506B41A0F375ABEB3206360143BB52@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Thread-Index: AcQa+zRmqHUvyMpdQmqNvLKrAba4YwCZqmHg From: <john.loughney@nokia.com> To: <harri.hakala@ericsson.com>, <aboba@internaut.com>, <aaa-wg@merit.edu> X-OriginalArrivalTime: 08 Apr 2004 12:06:41.0851 (UTC) FILETIME=[F427F8B0:01C41D61] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Dave / Bernard, > The section 11 is meant to be more as a guideline and not a full = solution because no > corresponding RADIUS prepaid RFC exists. Anyway, we felt that having = an informative=20 > section on this was needed. So, basically we tried to write basic = principle how to=20 > translate some Diameter AVPs and messages to more or less imaginary = RADIUS prepaid=20 > application, using the RFC 2865 as a base. We are aware of the = draft-lior-radius-prepaid > but since that work is still in progress the exact mapping to this = document was not possible. >=20 > The RFC of Radius prepaid (when available) should define a complete = description of protocol=20 > translation between Radius prepaid and Diameter credit control, if we = follow the principle=20 > that the document (Radius, Diameter) that comes last is responsible = for defining the mapping. >=20 > The first paragraph in section 11 is intended to highlight this but = perhaps some re-wording is > needed here. >=20 > In Annex A, the flow 1 shows the message translation between Radius = prepaid and Diameter CC, but > the purpose was not to show a full-fledged parameter mapping for the = above reasons. Any response to this? Does this answer the questions? John From owner-aaa-wg@merit.edu Thu Apr 8 08:39:18 2004 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 IAA11777 for <aaa-archive@lists.ietf.org>; Thu, 8 Apr 2004 08:39:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F1ECC91236; Thu, 8 Apr 2004 08:39:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1D0E9123D; Thu, 8 Apr 2004 08:39:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A13E791236 for <aaa-wg@trapdoor.merit.edu>; Thu, 8 Apr 2004 08:39:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8D98758524; Thu, 8 Apr 2004 08:39:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id D033058522 for <aaa-wg@merit.edu>; Thu, 8 Apr 2004 08:39:02 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id F1F2589870; Thu, 8 Apr 2004 15:38:45 +0300 (EEST) Message-ID: <4075472C.8040005@kolumbus.fi> Date: Thu, 08 Apr 2004 15:35:56 +0300 From: Jari Arkko <jari.arkko@kolumbus.fi> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: harri.hakala@ericsson.com, aboba@internaut.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: Review of Diameter Credit Control -04 References: <DADF50F5EC506B41A0F375ABEB3206360143BB52@esebe023.ntc.nokia.com> In-Reply-To: <DADF50F5EC506B41A0F375ABEB3206360143BB52@esebe023.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 wonder how useful the translation to an imaginary protocol is. I agree that the RADEXT RADIUS prepaid document should be the normative specification for such translations. What would we lose if Section 11 was deleted? Is there a specific requirement from someone to have this mapping? If yes, perhaps Section 11 should be moved to an appendix and contain the explanation for the needed specific translation, even if the translation target is just an I-D. If no, maybe you should just simplify your document by leaving Section 11 to RADEXT, have them write it once they figure what kind of RADIUS prepaid they will make. --Jari john.loughney@nokia.com wrote: > Dave / Bernard, > > >>The section 11 is meant to be more as a guideline and not a full solution because no >>corresponding RADIUS prepaid RFC exists. Anyway, we felt that having an informative >>section on this was needed. So, basically we tried to write basic principle how to >>translate some Diameter AVPs and messages to more or less imaginary RADIUS prepaid >>application, using the RFC 2865 as a base. We are aware of the draft-lior-radius-prepaid >>but since that work is still in progress the exact mapping to this document was not possible. >> >>The RFC of Radius prepaid (when available) should define a complete description of protocol >>translation between Radius prepaid and Diameter credit control, if we follow the principle >>that the document (Radius, Diameter) that comes last is responsible for defining the mapping. >> >>The first paragraph in section 11 is intended to highlight this but perhaps some re-wording is >>needed here. >> >>In Annex A, the flow 1 shows the message translation between Radius prepaid and Diameter CC, but >>the purpose was not to show a full-fledged parameter mapping for the above reasons. > > > Any response to this? Does this answer the questions? > > John > From owner-aaa-wg@merit.edu Thu Apr 8 09:00:41 2004 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 JAA12867 for <aaa-archive@lists.ietf.org>; Thu, 8 Apr 2004 09:00:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D893F9123D; Thu, 8 Apr 2004 09:00:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A067A9123F; Thu, 8 Apr 2004 09:00:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5B3A59123D for <aaa-wg@trapdoor.merit.edu>; Thu, 8 Apr 2004 09:00:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 49400584D0; Thu, 8 Apr 2004 09:00:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 4E86458461 for <aaa-wg@merit.edu>; Thu, 8 Apr 2004 09:00:21 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i38D0J806746 for <aaa-wg@merit.edu>; Thu, 8 Apr 2004 16:00:19 +0300 (EET DST) X-Scanned: Thu, 8 Apr 2004 15:58:44 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i38CwiA0004434 for <aaa-wg@merit.edu>; Thu, 8 Apr 2004 15:58:44 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 002pRguV; Thu, 08 Apr 2004 15:58:42 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i38CwWs16215 for <aaa-wg@merit.edu>; Thu, 8 Apr 2004 15:58:32 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Apr 2004 15:58:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: FW: Last Call: 'AAA Registration Keys for Mobile IPv4' to Proposed Standard Date: Thu, 8 Apr 2004 15:58:07 +0300 Message-ID: <DADF50F5EC506B41A0F375ABEB3206360143BB56@esebe023.ntc.nokia.com> Thread-Topic: Last Call: 'AAA Registration Keys for Mobile IPv4' to Proposed Standard Thread-Index: AcQdZjZucZOMvIhUQq2VKoKmPgUmJQAAsfgA From: <john.loughney@nokia.com> To: <aaa-wg@merit.edu> X-OriginalArrivalTime: 08 Apr 2004 12:58:08.0104 (UTC) FILETIME=[23B4CE80:01C41D69] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, Comments are welcome on this draft. Discussion is OK on the AAA list, but please CC the IESG (iesg@ietf.org or ietf@ietf.org). thanks, John The IESG has received a request from the Mobility for IPv4 WG to = consider=20 the following document: - 'AAA Registration Keys for Mobile IPv4 ' <draft-ietf-mip4-aaa-key-04.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-04-21. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mip4-aaa-key-04.txt From owner-aaa-wg@merit.edu Thu Apr 8 09:07:10 2004 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 JAA12974 for <aaa-archive@lists.ietf.org>; Thu, 8 Apr 2004 09:07:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 41B379123F; Thu, 8 Apr 2004 09:06:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F90091241; Thu, 8 Apr 2004 09:06:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BA86C9123F for <aaa-wg@trapdoor.merit.edu>; Thu, 8 Apr 2004 09:06:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A595058523; Thu, 8 Apr 2004 09:06:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id D912158461 for <aaa-wg@merit.edu>; Thu, 8 Apr 2004 09:06:50 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i38D6fWR015967 for <aaa-wg@merit.edu>; Thu, 8 Apr 2004 15:06:44 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Apr 2004 15:06:40 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <2P4HQPR9>; Thu, 8 Apr 2004 15:07:14 +0200 Message-ID: <F8EFC4B4A8C016428BC1F589296D4FBF0484402F@esealnt630.al.sw.ericsson.se> From: "Harri Hakala (JO/LMF)" <harri.hakala@ericsson.com> To: "'Jari Arkko'" <jari.arkko@kolumbus.fi>, john.loughney@nokia.com Cc: aboba@internaut.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Date: Thu, 8 Apr 2004 15:05:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 08 Apr 2004 13:06:40.0636 (UTC) FILETIME=[5532FBC0:01C41D6A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Jari, > Is > there a specific requirement from someone to have > this mapping? No, at least I am not aware of. > If no, maybe you should just simplify your document > by leaving Section 11 to RADEXT, have them write it > once they figure what kind of RADIUS prepaid they > will make. I am fine with this proposal. regards.........Harri > -----Original Message----- > From: owner-aaa-wg@merit.edu > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Jari Arkko > Sent: 8. huhtikuuta 2004 15:36 > To: john.loughney@nokia.com > Cc: Harri Hakala (JO/LMF); aboba@internaut.com; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue: Review of Diameter Credit Control -04 > > > > I wonder how useful the translation to an imaginary > protocol is. I agree that the RADEXT RADIUS prepaid > document should be the normative specification for > such translations. > > What would we lose if Section 11 was deleted? Is > there a specific requirement from someone to have > this mapping? If yes, perhaps Section 11 should be > moved to an appendix and contain the explanation > for the needed specific translation, even if the > translation target is just an I-D. > > If no, maybe you should just simplify your document > by leaving Section 11 to RADEXT, have them write it > once they figure what kind of RADIUS prepaid they > will make. > > --Jari > > john.loughney@nokia.com wrote: > > Dave / Bernard, > > > > > >>The section 11 is meant to be more as a guideline and not a > full solution because no > >>corresponding RADIUS prepaid RFC exists. Anyway, we felt > that having an informative > >>section on this was needed. So, basically we tried to write > basic principle how to > >>translate some Diameter AVPs and messages to more or less > imaginary RADIUS prepaid > >>application, using the RFC 2865 as a base. We are aware of > the draft-lior-radius-prepaid > >>but since that work is still in progress the exact mapping > to this document was not possible. > >> > >>The RFC of Radius prepaid (when available) should define a > complete description of protocol > >>translation between Radius prepaid and Diameter credit > control, if we follow the principle > >>that the document (Radius, Diameter) that comes last is > responsible for defining the mapping. > >> > >>The first paragraph in section 11 is intended to highlight > this but perhaps some re-wording is > >>needed here. > >> > >>In Annex A, the flow 1 shows the message translation > between Radius prepaid and Diameter CC, but > >>the purpose was not to show a full-fledged parameter > mapping for the above reasons. > > > > > > Any response to this? Does this answer the questions? > > > > John > > > > From owner-aaa-wg@merit.edu Thu Apr 8 09:48:19 2004 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 JAA15508 for <aaa-archive@lists.ietf.org>; Thu, 8 Apr 2004 09:48:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5BC449128E; Thu, 8 Apr 2004 09:48:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 293959128F; Thu, 8 Apr 2004 09:48:06 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ECF1F9128E for <aaa-wg@trapdoor.merit.edu>; Thu, 8 Apr 2004 09:48:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C88A2584BC; Thu, 8 Apr 2004 09:48:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id E79E158461 for <aaa-wg@merit.edu>; Thu, 8 Apr 2004 09:48:03 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i38Dsvm24330; Thu, 8 Apr 2004 06:54:57 -0700 Date: Thu, 8 Apr 2004 06:54:57 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: "Harri Hakala (JO/LMF)" <harri.hakala@ericsson.com> Cc: "'Jari Arkko'" <jari.arkko@kolumbus.fi>, john.loughney@nokia.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 In-Reply-To: <F8EFC4B4A8C016428BC1F589296D4FBF0484402F@esealnt630.al.sw.ericsson.se> Message-ID: <Pine.LNX.4.56.0404080653390.23527@internaut.com> References: <F8EFC4B4A8C016428BC1F589296D4FBF0484402F@esealnt630.al.sw.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk How about moving Section 11 into a separate I-D, entitled "Interoperation of Diameter and RADIUS Pre-Paid", so that the information is not lost? RADEXT can then take that up as a work item. On Thu, 8 Apr 2004, Harri Hakala (JO/LMF) wrote: > Hi Jari, > > > Is > > there a specific requirement from someone to have > > this mapping? > > No, at least I am not aware of. > > > If no, maybe you should just simplify your document > > by leaving Section 11 to RADEXT, have them write it > > once they figure what kind of RADIUS prepaid they > > will make. > > I am fine with this proposal. > > regards.........Harri > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu > > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > Jari Arkko > > Sent: 8. huhtikuuta 2004 15:36 > > To: john.loughney@nokia.com > > Cc: Harri Hakala (JO/LMF); aboba@internaut.com; aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: Issue: Review of Diameter Credit Control -04 > > > > > > > > I wonder how useful the translation to an imaginary > > protocol is. I agree that the RADEXT RADIUS prepaid > > document should be the normative specification for > > such translations. > > > > What would we lose if Section 11 was deleted? Is > > there a specific requirement from someone to have > > this mapping? If yes, perhaps Section 11 should be > > moved to an appendix and contain the explanation > > for the needed specific translation, even if the > > translation target is just an I-D. > > > > If no, maybe you should just simplify your document > > by leaving Section 11 to RADEXT, have them write it > > once they figure what kind of RADIUS prepaid they > > will make. > > > > --Jari > > > > john.loughney@nokia.com wrote: > > > Dave / Bernard, > > > > > > > > >>The section 11 is meant to be more as a guideline and not a > > full solution because no > > >>corresponding RADIUS prepaid RFC exists. Anyway, we felt > > that having an informative > > >>section on this was needed. So, basically we tried to write > > basic principle how to > > >>translate some Diameter AVPs and messages to more or less > > imaginary RADIUS prepaid > > >>application, using the RFC 2865 as a base. We are aware of > > the draft-lior-radius-prepaid > > >>but since that work is still in progress the exact mapping > > to this document was not possible. > > >> > > >>The RFC of Radius prepaid (when available) should define a > > complete description of protocol > > >>translation between Radius prepaid and Diameter credit > > control, if we follow the principle > > >>that the document (Radius, Diameter) that comes last is > > responsible for defining the mapping. > > >> > > >>The first paragraph in section 11 is intended to highlight > > this but perhaps some re-wording is > > >>needed here. > > >> > > >>In Annex A, the flow 1 shows the message translation > > between Radius prepaid and Diameter CC, but > > >>the purpose was not to show a full-fledged parameter > > mapping for the above reasons. > > > > > > > > > Any response to this? Does this answer the questions? > > > > > > John > > > > > > > > From owner-aaa-wg@merit.edu Thu Apr 8 09:55:29 2004 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 JAA16288 for <aaa-archive@lists.ietf.org>; Thu, 8 Apr 2004 09:55:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 953499128F; Thu, 8 Apr 2004 09:55:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5356F91292; Thu, 8 Apr 2004 09:55:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 13C829128F for <aaa-wg@trapdoor.merit.edu>; Thu, 8 Apr 2004 09:55:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ECFA658530; Thu, 8 Apr 2004 09:55:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 2A911584FA for <aaa-wg@merit.edu>; Thu, 8 Apr 2004 09:55:14 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i38DtAt04416; Thu, 8 Apr 2004 16:55:10 +0300 (EET DST) X-Scanned: Thu, 8 Apr 2004 16:52:56 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i38DquqU011736; Thu, 8 Apr 2004 16:52:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 005h7Z4o; Thu, 08 Apr 2004 16:52:54 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i38Dqis20449; Thu, 8 Apr 2004 16:52:44 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Apr 2004 16:52:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Date: Thu, 8 Apr 2004 16:52:28 +0300 Message-ID: <DADF50F5EC506B41A0F375ABEB3206360143BB59@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Thread-Index: AcQdcJZ0ZgU/nC02RwekLcsiuc57DQAABgig From: <john.loughney@nokia.com> To: <aboba@internaut.com>, <harri.hakala@ericsson.com> Cc: <jari.arkko@kolumbus.fi>, <aaa-wg@merit.edu> X-OriginalArrivalTime: 08 Apr 2004 13:52:29.0963 (UTC) FILETIME=[BBECFDB0:01C41D70] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Bernard, > How about moving Section 11 into a separate I-D, entitled = "Interoperation > of Diameter and RADIUS Pre-Paid", so that the information is not lost? > RADEXT can then take that up as a work item. That sounds like a good idea. John From owner-aaa-wg@merit.edu Thu Apr 8 10:28:45 2004 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 KAA21729 for <aaa-archive@lists.ietf.org>; Thu, 8 Apr 2004 10:28:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4EEC791290; Thu, 8 Apr 2004 10:28:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C6F991293; Thu, 8 Apr 2004 10:28:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE11391290 for <aaa-wg@trapdoor.merit.edu>; Thu, 8 Apr 2004 10:28:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CC4B45852B; Thu, 8 Apr 2004 10:28:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h008.c000.snv.cp.net [209.228.32.72]) by segue.merit.edu (Postfix) with SMTP id 2F72F5847A for <aaa-wg@merit.edu>; Thu, 8 Apr 2004 10:28:31 -0400 (EDT) Received: (cpmta 22161 invoked from network); 8 Apr 2004 07:28:29 -0700 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.72) with SMTP; 8 Apr 2004 07:28:29 -0700 X-Sent: 8 Apr 2004 14:28:29 GMT Message-Id: <5.2.1.1.2.20040408094938.04933040@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 08 Apr 2004 10:25:34 -0400 To: Jari Arkko <jari.arkko@kolumbus.fi>, john.loughney@nokia.com From: David Mitton <david@mitton.com> Subject: Re: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Cc: harri.hakala@ericsson.com, aboba@internaut.com, aaa-wg@merit.edu In-Reply-To: <4075472C.8040005@kolumbus.fi> References: <DADF50F5EC506B41A0F375ABEB3206360143BB52@esebe023.ntc.nokia.com> <DADF50F5EC506B41A0F375ABEB3206360143BB52@esebe023.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Harri, et.al., I had a similar reaction as Jari, but let me put it in my own words. I'm not sure I understand the utility of the text as it is. The text says that it will explain how to do something, and it tries for several pages, but it leaves out a lot of important details. You say it's supposed to be guideline, and I go back and find those words in the document but I forgot them because the section is very declarative. It seems to go much further than guidelines, but you are not trying to standardize this protocol in this document. A guideline could suggest what data elements and transactions are important to translate, but should not proscribe the format (eg RADIUS VSAs). I can see that writing a true guideline section might be problematic. And if the issues need to be decided, then maybe it's not useful here. If we want to keep this, I think this would be more appropriate as an informative appendix, with more words to the effect of it's incompleteness. Dave. On 4/8/2004 03:35 PM +0300, Jari Arkko wrote: >I wonder how useful the translation to an imaginary >protocol is. I agree that the RADEXT RADIUS prepaid >document should be the normative specification for >such translations. > >What would we lose if Section 11 was deleted? Is >there a specific requirement from someone to have >this mapping? If yes, perhaps Section 11 should be >moved to an appendix and contain the explanation >for the needed specific translation, even if the >translation target is just an I-D. > >If no, maybe you should just simplify your document >by leaving Section 11 to RADEXT, have them write it >once they figure what kind of RADIUS prepaid they >will make. > >--Jari > >john.loughney@nokia.com wrote: >>Dave / Bernard, >> >>>The section 11 is meant to be more as a guideline and not a full >>>solution because no >>>corresponding RADIUS prepaid RFC exists. Anyway, we felt that having an >>>informative section on this was needed. So, basically we tried to write >>>basic principle how to translate some Diameter AVPs and messages to more >>>or less imaginary RADIUS prepaid application, using the RFC 2865 as a >>>base. We are aware of the draft-lior-radius-prepaid >>>but since that work is still in progress the exact mapping to this >>>document was not possible. >>> >>>The RFC of Radius prepaid (when available) should define a complete >>>description of protocol translation between Radius prepaid and Diameter >>>credit control, if we follow the principle that the document (Radius, >>>Diameter) that comes last is responsible for defining the mapping. >>> >>>The first paragraph in section 11 is intended to highlight this but >>>perhaps some re-wording is >>>needed here. >>> >>>In Annex A, the flow 1 shows the message translation between Radius >>>prepaid and Diameter CC, but >>>the purpose was not to show a full-fledged parameter mapping for the >>>above reasons. >> >>Any response to this? Does this answer the questions? >>John > > From owner-aaa-wg@merit.edu Thu Apr 8 12:57:11 2004 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 MAA03116 for <aaa-archive@lists.ietf.org>; Thu, 8 Apr 2004 12:57:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AF3259129C; Thu, 8 Apr 2004 12:56:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84DCA9129D; Thu, 8 Apr 2004 12:56:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5457E9129C for <aaa-wg@trapdoor.merit.edu>; Thu, 8 Apr 2004 12:56:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3CAAA58569; Thu, 8 Apr 2004 12:56:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ns2.bln1.siemens.de (ns2.bln1.siemens.de [194.138.127.35]) by segue.merit.edu (Postfix) with ESMTP id 6A45858542 for <aaa-wg@merit.edu>; Thu, 8 Apr 2004 12:56:56 -0400 (EDT) Received: from ns-srv-2.bln1.siemens.de (stbf7654 [194.138.127.67]) by ns2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id i38GurNH010899 for <aaa-wg@merit.edu>; Thu, 8 Apr 2004 18:56:54 +0200 (MEST) Received: from blnss10a.bln1.siemens.de (blnss10a.bln1.siemens.de [194.138.127.102]) by ns-srv-2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id i38GunKY013050 for <aaa-wg@merit.edu>; Thu, 8 Apr 2004 18:56:50 +0200 (MEST) Received: by blnss10a.bln1.siemens.de with Internet Mail Service (5.5.2653.19) id <2MTYL4L7>; Thu, 8 Apr 2004 18:56:30 +0200 Message-ID: <445C57B81208C24EAD99F2944DBB9D290551C200@blnss10a.bln1.siemens.de> From: Schendel Jens ICM Berlin <jens.schendel@siemens.com> To: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu> Subject: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit time Date: Thu, 8 Apr 2004 18:56:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi all, according to the following paragraph in section 8.20 of Diameter Credit Control Application Draft 04 the server shall not combine tariff time change with time units. " The tariff change mechanism is optional for client and server and it is not used for unit type time, since the server has full control of the time." However, I do belief that such definition is based on the assumption that time supervision at the client side is done continuously. I am not sure whether this is really an applicable generic rule. Time unit charging may be based on a usage model (similar to volume accounting) rather than on a connection time model. Example: Just the active download time ("data packets are flowing") of a "permanent" connection to a streaming server shall be counted (by client) and charged (by server). Here the server will have no chance to allocate time units used before and after tariff switch time correctly on its own. I understand DCCA as charging framework for multiple service applications and underlying networks. Hence, I wonder if such restriction per definition is acceptable. My suggestion were just to remove "and it is not used...". I'd appreciate your views. Jens From owner-aaa-wg@merit.edu Thu Apr 8 13:34:36 2004 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 NAA06504 for <aaa-archive@lists.ietf.org>; Thu, 8 Apr 2004 13:34:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 85C2B91299; Thu, 8 Apr 2004 13:34:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5972A9129D; Thu, 8 Apr 2004 13:34:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EE50691299 for <aaa-wg@trapdoor.merit.edu>; Thu, 8 Apr 2004 13:34:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DB7925852A; Thu, 8 Apr 2004 13:34:15 -0400 (EDT) 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 62855584EA for <aaa-wg@merit.edu>; Thu, 8 Apr 2004 13:34:15 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i38HY6j02632; Thu, 8 Apr 2004 12:34:06 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <GXVJ3519>; Thu, 8 Apr 2004 12:34:07 -0500 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304DDD760@zrc2c012.us.nortel.com> From: "Christopher Richards" <crich@nortelnetworks.com> To: Schendel Jens ICM Berlin <jens.schendel@siemens.com>, "'aaa-wg@merit.edu'" <aaa-wg@merit.edu> Subject: RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit time Date: Thu, 8 Apr 2004 12:34:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41D8F.B1605BAC" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C41D8F.B1605BAC Content-Type: text/plain Hello Jens, Yes: I agree with your suggestion. Regards, Chris. -----Original Message----- From: Schendel Jens ICM Berlin [mailto:jens.schendel@siemens.com] Sent: Thursday, April 08, 2004 11:56 AM To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit time Hi all, according to the following paragraph in section 8.20 of Diameter Credit Control Application Draft 04 the server shall not combine tariff time change with time units. " The tariff change mechanism is optional for client and server and it is not used for unit type time, since the server has full control of the time." However, I do belief that such definition is based on the assumption that time supervision at the client side is done continuously. I am not sure whether this is really an applicable generic rule. Time unit charging may be based on a usage model (similar to volume accounting) rather than on a connection time model. Example: Just the active download time ("data packets are flowing") of a "permanent" connection to a streaming server shall be counted (by client) and charged (by server). Here the server will have no chance to allocate time units used before and after tariff switch time correctly on its own. I understand DCCA as charging framework for multiple service applications and underlying networks. Hence, I wonder if such restriction per definition is acceptable. My suggestion were just to remove "and it is not used...". I'd appreciate your views. Jens ------_=_NextPart_001_01C41D8F.B1605BAC Content-Type: text/html Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2656.31"> <TITLE>RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit = time

Hello Jens,

Yes: I agree with your suggestion.

Regards,
Chris.


-----Original Message-----
From: Schendel Jens ICM Berlin [mailto:jens.schendel@siemens.c= om]
Sent: Thursday, April 08, 2004 11:56 AM
To: 'aaa-wg@merit.edu'
Subject: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change = AVP for unit time


Hi all,

according to the following paragraph in section 8.20 = of Diameter Credit Control Application Draft 04
the server shall not combine tariff time change with = time units.

"  The tariff change mechanism is optional = for client and server and it
   is not used for unit type time, since = the server has full control of
   the time."

However, I do belief that such definition is based on = the assumption that time supervision at the client side is done = continuously. I am not sure whether this is really an applicable = generic rule. Time unit charging may be based on a usage model (similar = to volume accounting) rather than on a connection time = model.

Example: Just the active download time ("data = packets are flowing") of a "permanent" connection to a = streaming server shall be counted (by client) and charged (by server). = Here the server will have no chance to allocate time units used before = and after tariff switch time correctly on its own.

 
I understand DCCA as charging framework for multiple = service applications and underlying networks. Hence, I wonder if such = restriction per definition is acceptable. My suggestion were just to = remove "and it is not used...".

I'd appreciate your views.

Jens

------_=_NextPart_001_01C41D8F.B1605BAC-- From owner-aaa-wg@merit.edu Thu Apr 8 14:31:53 2004 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 OAA08716 for ; Thu, 8 Apr 2004 14:31:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4298E9129F; Thu, 8 Apr 2004 14:31:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 121C6912A0; Thu, 8 Apr 2004 14:31:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 95C7E9129F for ; Thu, 8 Apr 2004 14:31:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7F8C558519; Thu, 8 Apr 2004 14:31:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hotmail.com (law10-f22.law10.hotmail.com [64.4.15.22]) by segue.merit.edu (Postfix) with ESMTP id 0CF55584FE for ; Thu, 8 Apr 2004 14:31:38 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 8 Apr 2004 11:31:37 -0700 Received: from 212.213.204.99 by lw10fd.law10.hotmail.msn.com with HTTP; Thu, 08 Apr 2004 18:31:37 GMT X-Originating-IP: [212.213.204.99] X-Originating-Email: [marco_stura@hotmail.com] X-Sender: marco_stura@hotmail.com From: "Stura Marco" To: crich@nortelnetworks.com, jens.schendel@siemens.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit time Date: Thu, 08 Apr 2004 21:31:37 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Apr 2004 18:31:37.0567 (UTC) FILETIME=[BA468EF0:01C41D97] Sender: owner-aaa-wg@merit.edu Precedence: bulk Chris/Jens, please note the definition in section 5, copied below For time based services the quota is consumed at the regular rate of 60 seconds per minute, the server already knows at the time when credit resources are allocated how many units will be consumed before the tariff time change and how many units will be consumed after. Similarly, the server can determine the units consumed at the before rate and the units consumed at the rate afterwards in the event that the end-user closes the session before the consumption of the allotted quota. There is no need for additional traffic between client and server in case of tariff time changes for time based service, therefore the tariff change mechanism is not used for time based services. Actually this definition doesn't imply that tariff-time-change is not used with unit type time, rather it is not used with time based services (i.e. those that consume at regular rate of 60 seconds per minute). The usage model you are thinking of it doesn't match the above definition, therefore the restriction doesn't apply. But yes, there is an inconsistence with section 8.20 that we forgot to update already in draft 03. The paragraph you are referring to, should read The tariff change mechanism is optional for client and server and it is not used for time based services as defined in section 5. We'll certainly update this together with other comments received by the AD. Regards Marco >From: "Christopher Richards" >To: Schendel Jens ICM Berlin >,"'aaa-wg@merit.edu'" >Subject: RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit time >Date: Thu, 8 Apr 2004 12:34:06 -0500 > >Hello Jens, > >Yes: I agree with your suggestion. > >Regards, >Chris. > > >-----Original Message----- >From: Schendel Jens ICM Berlin [mailto:jens.schendel@siemens.com] >Sent: Thursday, April 08, 2004 11:56 AM >To: 'aaa-wg@merit.edu' >Subject: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit time > > >Hi all, > >according to the following paragraph in section 8.20 of Diameter Credit >Control Application Draft 04 >the server shall not combine tariff time change with time units. > >" The tariff change mechanism is optional for client and server and it > is not used for unit type time, since the server has full control of > the time." > >However, I do belief that such definition is based on the assumption that >time supervision at the client side is done continuously. I am not sure >whether this is really an applicable generic rule. Time unit charging may >be >based on a usage model (similar to volume accounting) rather than on a >connection time model. >Example: Just the active download time ("data packets are flowing") of a >"permanent" connection to a streaming server shall be counted (by client) >and charged (by server). Here the server will have no chance to allocate >time units used before and after tariff switch time correctly on its own. > >I understand DCCA as charging framework for multiple service applications >and underlying networks. Hence, I wonder if such restriction per definition >is acceptable. My suggestion were just to remove "and it is not used...". > >I'd appreciate your views. > >Jens _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From owner-aaa-wg@merit.edu Thu Apr 8 16:06:34 2004 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 QAA15766 for ; Thu, 8 Apr 2004 16:06:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E7B59912A4; Thu, 8 Apr 2004 16:03:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91646912AB; Thu, 8 Apr 2004 16:03:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 601FF912A4 for ; Thu, 8 Apr 2004 16:03:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 41091584EA; Thu, 8 Apr 2004 16:03:43 -0400 (EDT) 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 9ADDF58536 for ; Thu, 8 Apr 2004 16:03:42 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i38K1Qj24656; Thu, 8 Apr 2004 15:01:26 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Apr 2004 15:01:27 -0500 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975305F2FAAA@zrc2c012.us.nortel.com> From: "Christopher Richards" To: Stura Marco , jens.schendel@siemens.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit time Date: Thu, 8 Apr 2004 15:01:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41DA4.465315CE" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C41DA4.465315CE Content-Type: text/plain Thanks Marco, Should we clarify section 5 in addition? As the text stands, it is not clear that there are basically two types of time based quota. FROM:- For time based services the quota is consumed at the regular rate of 60 seconds per minute, the server already knows at the time when credit resources are allocated how many units will be consumed before the tariff time change and how many units will be consumed after. Similarly, the server can determine the units consumed at the before rate and the units consumed at the rate afterwards in the event that the end-user closes the session before the consumption of the allotted quota. There is no need for additional traffic between client and server in case of tariff time changes for time based service, therefore the tariff change mechanism is not used for time based services. TO:- For time based services where the quota is continuously consumed at the regular rate of 60 seconds per minute, the server already knows at the time when credit resources are allocated how many units will be consumed before the tariff time change and how many units will be consumed after. Similarly, the server can determine the units consumed at the before rate and the units consumed at the rate afterwards in the event that the end-user closes the session before the consumption of the allotted quota. There is no need for additional traffic between client and server in case of tariff time changes for the continuous time based service, therefore the tariff change mechanism is not used for continuous time based services. For time based services where the quota is NOT continuously consumed at a regular rate, the tariff change mechanism described for volume and event units MAY be used. Regards, Chris. -----Original Message----- From: Stura Marco [mailto:marco_stura@hotmail.com] Sent: Thursday, April 08, 2004 1:32 PM To: Richards, Christopher [RICH2:2Q40:EXCH]; jens.schendel@siemens.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit time Chris/Jens, please note the definition in section 5, copied below For time based services the quota is consumed at the regular rate of 60 seconds per minute, the server already knows at the time when credit resources are allocated how many units will be consumed before the tariff time change and how many units will be consumed after. Similarly, the server can determine the units consumed at the before rate and the units consumed at the rate afterwards in the event that the end-user closes the session before the consumption of the allotted quota. There is no need for additional traffic between client and server in case of tariff time changes for time based service, therefore the tariff change mechanism is not used for time based services. Actually this definition doesn't imply that tariff-time-change is not used with unit type time, rather it is not used with time based services (i.e. those that consume at regular rate of 60 seconds per minute). The usage model you are thinking of it doesn't match the above definition, therefore the restriction doesn't apply. But yes, there is an inconsistence with section 8.20 that we forgot to update already in draft 03. The paragraph you are referring to, should read The tariff change mechanism is optional for client and server and it is not used for time based services as defined in section 5. We'll certainly update this together with other comments received by the AD. Regards Marco >From: "Christopher Richards" >To: Schendel Jens ICM Berlin >,"'aaa-wg@merit.edu'" >Subject: RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit >time >Date: Thu, 8 Apr 2004 12:34:06 -0500 > >Hello Jens, > >Yes: I agree with your suggestion. > >Regards, >Chris. > > >-----Original Message----- >From: Schendel Jens ICM Berlin [mailto:jens.schendel@siemens.com] >Sent: Thursday, April 08, 2004 11:56 AM >To: 'aaa-wg@merit.edu' >Subject: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit time > > >Hi all, > >according to the following paragraph in section 8.20 of Diameter Credit >Control Application Draft 04 the server shall not combine tariff time >change with time units. > >" The tariff change mechanism is optional for client and server and it > is not used for unit type time, since the server has full control of > the time." > >However, I do belief that such definition is based on the assumption >that time supervision at the client side is done continuously. I am not >sure whether this is really an applicable generic rule. Time unit >charging may be based on a usage model (similar to volume accounting) >rather than on a connection time model. >Example: Just the active download time ("data packets are flowing") of a >"permanent" connection to a streaming server shall be counted (by client) >and charged (by server). Here the server will have no chance to allocate >time units used before and after tariff switch time correctly on its own. > >I understand DCCA as charging framework for multiple service >applications and underlying networks. Hence, I wonder if such >restriction per definition is acceptable. My suggestion were just to >remove "and it is not used...". > >I'd appreciate your views. > >Jens _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 ------_=_NextPart_001_01C41DA4.465315CE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit = time

Thanks Marco,

Should we clarify section 5 in addition? As the text = stands, it is not clear that there are basically two types of time = based quota.

FROM:-

   For time based services the quota is = consumed at the regular rate of
   60 seconds per minute, the server = already knows at the time when
   credit resources are allocated how many = units will be consumed before
   the tariff time change and how many = units will be consumed after.
   Similarly, the server can determine the = units consumed at the before
   rate and the units consumed at the rate = afterwards in the event that
   the end-user closes the session before = the consumption of the allotted
   quota.  There is no need for = additional traffic between client and
   server in case of tariff time changes = for time based service,
   therefore the tariff change mechanism = is not used for time based
   services.

TO:-

   For time based services where the quota = is continuously consumed at the regular rate of
   60 seconds per minute, the server = already knows at the time when
   credit resources are allocated how many = units will be consumed before
   the tariff time change and how many = units will be consumed after.
   Similarly, the server can determine the = units consumed at the before
   rate and the units consumed at the rate = afterwards in the event that
   the end-user closes the session before = the consumption of the allotted
   quota.  There is no need for = additional traffic between client and
   server in case of tariff time changes = for the continuous time based service,
   therefore the tariff change mechanism = is not used for continuous time based
   services.

   For time based services where the quota = is NOT continuously consumed at a regular rate,
   the tariff change mechanism described = for volume and event units MAY be used.

Regards,
Chris.

-----Original Message-----
From: Stura Marco [mailto:marco_stura@hotmail.com]
Sent: Thursday, April 08, 2004 1:32 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]; = jens.schendel@siemens.com
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 04: = Tariff-Time-Change AVP for unit time


Chris/Jens,

please note the definition in section 5, copied = below

   For time based services the quota is = consumed at the regular rate of
   60 seconds per minute, the server = already knows at the time when
   credit resources are allocated how many = units will be consumed before
   the tariff time change and how many = units will be consumed after.
   Similarly, the server can determine the = units consumed at the before
   rate and the units consumed at the rate = afterwards in the event that
   the end-user closes the session before = the consumption of the allotted
   quota.  There is no need for = additional traffic between client and
   server in case of tariff time changes = for time based service,
   therefore the tariff change mechanism = is not used for time based
   services.

Actually this definition doesn't imply that = tariff-time-change is not used with unit type time, rather it is not = used with time based services (i.e. those that consume at regular rate = of 60 seconds per minute). The usage model you are thinking of it = doesn't match the above definition, therefore the restriction doesn't = apply.

But yes, there is an inconsistence with section 8.20 = that we forgot to
update
already in draft 03. The paragraph you are referring = to, should read

   The tariff change mechanism is optional = for client and server and it
   is not used for time based services as = defined in section 5.

We'll certainly update this together with other = comments received by the AD.

Regards
Marco

>From: "Christopher Richards" = <crich@nortelnetworks.com>
>To: Schendel Jens ICM Berlin
><jens.schendel@siemens.com>,"'aaa-wg@merit.edu'&= quot; <aaa-wg@merit.edu>
>Subject: RE: [AAA-WG]: DCCA Draft 04: = Tariff-Time-Change AVP for unit
>time
>Date: Thu, 8 Apr 2004 12:34:06 -0500
>
>Hello Jens,
>
>Yes: I agree with your suggestion.
>
>Regards,
>Chris.
>
>
>-----Original Message-----
>From: Schendel Jens ICM Berlin [mailto:jens.schendel@siemens.c= om]
>Sent: Thursday, April 08, 2004 11:56 AM
>To: 'aaa-wg@merit.edu'
>Subject: [AAA-WG]: DCCA Draft 04: = Tariff-Time-Change AVP for unit time
>
>
>Hi all,
>
>according to the following paragraph in section = 8.20 of Diameter Credit
>Control Application Draft 04 the server shall = not combine tariff time
>change with time units.
>
>"  The tariff change mechanism is = optional for client and server and it
>    is not used for unit type = time, since the server has full control of
>    the time."
>
>However, I do belief that such definition is = based on the assumption
>that time supervision at the client side is done = continuously. I am not
>sure whether this is really an applicable = generic rule. Time unit
>charging may be based on a usage model (similar = to volume accounting)
>rather than on a connection time model.
>Example: Just the active download time = ("data packets are flowing") of a
>"permanent" connection to a streaming = server shall be counted (by client)
>and charged (by server). Here the server will = have no chance to allocate
>time units used before and after tariff switch = time correctly on its own.
>
>I understand DCCA as charging framework for = multiple service
>applications and underlying networks. Hence, I = wonder if such
>restriction per definition is acceptable. My = suggestion were just to
>remove "and it is not used...".
>
>I'd appreciate your views.
>
>Jens

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

------_=_NextPart_001_01C41DA4.465315CE-- From aaa-admin@ietf.org Fri Apr 9 15:11:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13584 for ; Fri, 9 Apr 2004 15:11:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1P4-0008DG-JR; Fri, 09 Apr 2004 15:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1OO-0007ay-0O for aaa@optimus.ietf.org; Fri, 09 Apr 2004 15:10:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13442 for ; Fri, 9 Apr 2004 15:10:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC1OH-0006j9-00 for aaa@ietf.org; Fri, 09 Apr 2004 15:10:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC1JP-0006Le-00 for aaa@ietf.org; Fri, 09 Apr 2004 15:05:13 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BC1GQ-0005xy-00 for aaa@ietf.org; Fri, 09 Apr 2004 15:02:06 -0400 Received: from c66.188.232.27.euc.wi.charter.com ([66.188.232.27]) by mx2.foretec.com with smtp (Exim 4.24) id 1BC1GH-0006ty-CY for aaa@ietf.org; Fri, 09 Apr 2004 15:01:59 -0400 Received: from 24.7.75.02 by 66.188.232.27; Sat, 10 Apr 2004 05:04:32 -0300 Message-ID: From: "Eunice Carson" Reply-To: "Eunice Carson" To: aaa@ietf.org Date: Sat, 10 Apr 2004 12:08:32 +0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.1 X-Sender: LLXCastle@24-today.co.uk Organization: cromwellian.cesium Content-Type: multipart/mixed; boundary="--926373233213396" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=BIZ_TLD,HTML_FONTCOLOR_UNKNOWN, HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Aaa] OEM Software Distribution kingdom Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , abbott affectation conduct dogtooth excitation betel champagne carne drudge mindful ----926373233213396 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable aside ascendant
3D"clix 3D"clix= 3D"clix
3D""
Same day shipping (See site for details) 3D""
<= /TD> 4-CD-OEM&nb= sp;
3D""
Windows XP Suites
Adobe software
Clearance
Corel Draw/Corel Ventura
Games
3D Studio Max
Operating Systems
Utilities

Specials good thru 04/14/04.

Please use di= scount code mail3510 to r= eceive these prices. 
Microsoft Windows XP Professional OEM 

3D"PowerQuest Only $39.95  
Savings -$59.95

Microsoft Windows XP Professional goes beyond the benefits of Windows XP Home Edition with advanced capabilities designed specifically to.. 3D"PowerQuest
* Use this Discount Code at Checkout: mail2864<= /font>

Adobe Photoshop 7.0 OEM

3D"Microsoft Only $59.95
Savings -$255.50

Adobe Photoshop 7.0 software the professional image-editing standard helps you work more efficiently.. 3D"Microsoft
* Use this Discount Code at Checkout: mail2241<= /font>

Microsoft Office XP Professional OEM

3D"Symantec Only $59.95
Savings -$50.50

Microsoft Windows XP Professional is a Windows operating system designed for businesses of all sizes and for individuals who demand the most from their computing 3D"Symantec
* Use this Discount Code at Checkout: mail92354=


Adobe Illustrator 10 OEM

3D"Symantec Only $59.95
Savings -$215.50

EN= HANCED! Adobe Illustrator 10 software defines the future of vector graphics with groundbreaking creative options and powerful tools for efficiently publishing artwork on the Web, in print, everywhere...  3D"Symantec
* Use this Discount Code at Checkout: mail2593<= /font>




         &n= bsp;           &nbs= p;            =             &n= bsp;   1998-2003 OEM-CD, All Rights Reserved
----926373233213396-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Fri Apr 9 15:17:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14236 for ; Fri, 9 Apr 2004 15:17:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1Ux-0001nX-TJ for aaa-archive@odin.ietf.org; Fri, 09 Apr 2004 15:17:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39JH7LQ006911 for aaa-archive@odin.ietf.org; Fri, 9 Apr 2004 15:17:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1Ux-0001nO-Ni for aaa-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 15:17:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14182 for ; Fri, 9 Apr 2004 15:17:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC1Uw-0007SO-00 for aaa-web-archive@ietf.org; Fri, 09 Apr 2004 15:17:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC1RV-0007AE-00 for aaa-web-archive@ietf.org; Fri, 09 Apr 2004 15:13:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BC1PC-0006rB-00 for aaa-web-archive@ietf.org; Fri, 09 Apr 2004 15:11:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1P4-0008DG-JR; Fri, 09 Apr 2004 15:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1OO-0007ay-0O for aaa@optimus.ietf.org; Fri, 09 Apr 2004 15:10:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13442 for ; Fri, 9 Apr 2004 15:10:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC1OH-0006j9-00 for aaa@ietf.org; Fri, 09 Apr 2004 15:10:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC1JP-0006Le-00 for aaa@ietf.org; Fri, 09 Apr 2004 15:05:13 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BC1GQ-0005xy-00 for aaa@ietf.org; Fri, 09 Apr 2004 15:02:06 -0400 Received: from c66.188.232.27.euc.wi.charter.com ([66.188.232.27]) by mx2.foretec.com with smtp (Exim 4.24) id 1BC1GH-0006ty-CY for aaa@ietf.org; Fri, 09 Apr 2004 15:01:59 -0400 Received: from 24.7.75.02 by 66.188.232.27; Sat, 10 Apr 2004 05:04:32 -0300 Message-ID: From: "Eunice Carson" Reply-To: "Eunice Carson" To: aaa@ietf.org Date: Sat, 10 Apr 2004 12:08:32 +0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.1 X-Sender: LLXCastle@24-today.co.uk Organization: cromwellian.cesium Content-Type: multipart/mixed; boundary="--926373233213396" Subject: [Aaa] OEM Software Distribution kingdom Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,BIZ_TLD, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.60 abbott affectation conduct dogtooth excitation betel champagne carne drudge mindful ----926373233213396 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable aside ascendant
3D"clix 3D"clix= 3D"clix
3D""
Same day shipping (See site for details) 3D""
<= /TD> 4-CD-OEM&nb= sp;
3D""
Windows XP Suites
Adobe software
Clearance
Corel Draw/Corel Ventura
Games
3D Studio Max
Operating Systems
Utilities

Specials good thru 04/14/04.

Please use di= scount code mail3510 to r= eceive these prices. 
Microsoft Windows XP Professional OEM 

3D"PowerQuest Only $39.95  
Savings -$59.95

Microsoft Windows XP Professional goes beyond the benefits of Windows XP Home Edition with advanced capabilities designed specifically to.. 3D"PowerQuest
* Use this Discount Code at Checkout: mail2864<= /font>

Adobe Photoshop 7.0 OEM

3D"Microsoft Only $59.95
Savings -$255.50

Adobe Photoshop 7.0 software the professional image-editing standard helps you work more efficiently.. 3D"Microsoft
* Use this Discount Code at Checkout: mail2241<= /font>

Microsoft Office XP Professional OEM

3D"Symantec Only $59.95
Savings -$50.50

Microsoft Windows XP Professional is a Windows operating system designed for businesses of all sizes and for individuals who demand the most from their computing 3D"Symantec
* Use this Discount Code at Checkout: mail92354=


Adobe Illustrator 10 OEM

3D"Symantec Only $59.95
Savings -$215.50

EN= HANCED! Adobe Illustrator 10 software defines the future of vector graphics with groundbreaking creative options and powerful tools for efficiently publishing artwork on the Web, in print, everywhere...  3D"Symantec
* Use this Discount Code at Checkout: mail2593<= /font>




         &n= bsp;           &nbs= p;            =             &n= bsp;   1998-2003 OEM-CD, All Rights Reserved
----926373233213396-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Sun Apr 11 14:50:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02865 for ; Sun, 11 Apr 2004 14:50:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCk1p-0007g2-LA; Sun, 11 Apr 2004 14:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCk1A-0007er-6i for aaa@optimus.ietf.org; Sun, 11 Apr 2004 14:49:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02825 for ; Sun, 11 Apr 2004 14:49:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCk17-00076P-00 for aaa@ietf.org; Sun, 11 Apr 2004 14:49:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCjvl-0006gO-00 for aaa@ietf.org; Sun, 11 Apr 2004 14:43:46 -0400 Received: from 201008133139.user.veloxzone.com.br ([201.8.133.139]) by ietf-mx with smtp (Exim 4.12) id 1BCjs6-0006BX-00 for aaa@ietf.org; Sun, 11 Apr 2004 14:39:59 -0400 Content-Type: text/html; charset="us-ascii"; MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit From: "Reuben Oakes" To: aaa@ietf.org X-Priority: 3 Date: Mon, 12 Apr 2004 01:34:57 +0600 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.9 required=5.0 tests=BIZ_TLD,HTML_60_70, HTML_FONTCOLOR_UNSAFE,HTML_IMAGE_ONLY_04,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Content-Transfer-Encoding: 7Bit Subject: [Aaa] Re: my favorite Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7Bit They must demonstrate beyond a reasonable doubt that the negro is a superior being to that which I have made him out to be, and one already endowed with actual and useful ability.





From the steppes came the ringing neigh of the horses, and red streaks shone brightly in the sky. It would be a pity indeed to fall asleep, and lose the pleasure of saying "Merry Christmas" to everybody. _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sun Apr 11 14:57:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03141 for ; Sun, 11 Apr 2004 14:57:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCk8G-00081h-4j for aaa-archive@odin.ietf.org; Sun, 11 Apr 2004 14:56:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3BIuebc030853 for aaa-archive@odin.ietf.org; Sun, 11 Apr 2004 14:56:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCk8D-00081Y-UM for aaa-web-archive@optimus.ietf.org; Sun, 11 Apr 2004 14:56:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03117 for ; Sun, 11 Apr 2004 14:56:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCk8A-0000D0-00 for aaa-web-archive@ietf.org; Sun, 11 Apr 2004 14:56:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BCk6t-0007jd-00 for aaa-web-archive@ietf.org; Sun, 11 Apr 2004 14:55:16 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BCk22-0000xb-0c for aaa-web-archive@ietf.org; Sun, 11 Apr 2004 14:50:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCk1p-0007g2-LA; Sun, 11 Apr 2004 14:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCk1A-0007er-6i for aaa@optimus.ietf.org; Sun, 11 Apr 2004 14:49:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02825 for ; Sun, 11 Apr 2004 14:49:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCk17-00076P-00 for aaa@ietf.org; Sun, 11 Apr 2004 14:49:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCjvl-0006gO-00 for aaa@ietf.org; Sun, 11 Apr 2004 14:43:46 -0400 Received: from 201008133139.user.veloxzone.com.br ([201.8.133.139]) by ietf-mx with smtp (Exim 4.12) id 1BCjs6-0006BX-00 for aaa@ietf.org; Sun, 11 Apr 2004 14:39:59 -0400 Content-Type: text/html; charset="us-ascii"; MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit From: "Reuben Oakes" To: aaa@ietf.org X-Priority: 3 Date: Mon, 12 Apr 2004 01:34:57 +0600 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.9 required=5.0 tests=BIZ_TLD,HTML_60_70, HTML_FONTCOLOR_UNSAFE,HTML_IMAGE_ONLY_04,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Content-Transfer-Encoding: 7Bit Subject: [Aaa] Re: my favorite Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7Bit Content-Transfer-Encoding: 7Bit They must demonstrate beyond a reasonable doubt that the negro is a superior being to that which I have made him out to be, and one already endowed with actual and useful ability.





From the steppes came the ringing neigh of the horses, and red streaks shone brightly in the sky. It would be a pity indeed to fall asleep, and lose the pleasure of saying "Merry Christmas" to everybody. _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Tue Apr 13 03:47:49 2004 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 DAA26684 for ; Tue, 13 Apr 2004 03:47:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4188D91291; Tue, 13 Apr 2004 03:47:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0AEAC91294; Tue, 13 Apr 2004 03:47:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AE31191291 for ; Tue, 13 Apr 2004 03:47:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 915A1584A5; Tue, 13 Apr 2004 03:47:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id CEEBD584ED for ; Tue, 13 Apr 2004 03:47:27 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3D7lQPA009229 for ; Tue, 13 Apr 2004 09:47:26 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 Apr 2004 09:47:26 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <25RJKVH4>; Tue, 13 Apr 2004 09:47:26 +0200 Message-ID: From: "Harri Hakala (JO/LMF)" To: "'David Mitton'" , Jari Arkko , john.loughney@nokia.com Cc: aboba@internaut.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Date: Tue, 13 Apr 2004 09:46:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 13 Apr 2004 07:47:26.0417 (UTC) FILETIME=[9075DC10:01C4212B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Dave, I do agree that the guidelines and details in the Interworking section are not right balanced. Also some important standardization details are missing, but it is quite hard to define these details without having a bit more stable target document for translation. Now when draft-lior-radius-prepaid is also chartered in the RADEXT, it may be better to move this section to a separate I-D, as proposed, instead of keeping this section even as an informative appendix. This due to fact that the comprehensive interworking description may be rather large, depending on, of course, the level of details that will be covered. For instance, at the moment just translation from very basic session based credit control to Radius prepaid is covered in the DCC draft. It may be feasible to provide also the translation of optional features, e.g. one time events, graceful service termination, tariff switch, credit-control for multiple services and those ones which will be described in the Radius prepaid draft. Handling of failure cases, such as the mapping of result codes could be good to cover as well. It should also define full-fledged parameter mapping, containing those details which are not now specified. regards........Harri > -----Original Message----- > From: David Mitton [mailto:david@mitton.com] > Sent: 8. huhtikuuta 2004 17:26 > To: Jari Arkko; john.loughney@nokia.com > Cc: Harri Hakala (JO/LMF); aboba@internaut.com; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue: Review of Diameter Credit Control -04 > > > Harri, et.al., > > I had a similar reaction as Jari, but let me put it > in my own words. > > I'm not sure I understand the utility of the text as it is. > The text says that it will explain how to do something, and > it tries for > several pages, but it leaves out a lot of important details. > You say it's supposed to be guideline, and I go back and find > those words > in the document but I forgot them because the section is very > declarative. It seems to go much further than guidelines, > but you are not > trying to standardize this protocol in this document. > > A guideline could suggest what data elements and transactions > are important > to translate, but should not proscribe the format (eg RADIUS VSAs). > > I can see that writing a true guideline section might be > problematic. And > if the issues need to be decided, then maybe it's not useful here. > > If we want to keep this, I think this would be more appropriate as an > informative appendix, with more words to the effect of it's > incompleteness. > > Dave. > > From owner-aaa-wg@merit.edu Tue Apr 13 03:57:13 2004 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 DAA27074 for ; Tue, 13 Apr 2004 03:57:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B9DD591294; Tue, 13 Apr 2004 03:56:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8560891295; Tue, 13 Apr 2004 03:56:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 03B2791294 for ; Tue, 13 Apr 2004 03:56:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DEE5958514; Tue, 13 Apr 2004 03:56:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id DC0B158526 for ; Tue, 13 Apr 2004 03:56:56 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D7unO13057; Tue, 13 Apr 2004 10:56:49 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 10:53:17 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3D7rHct013595; Tue, 13 Apr 2004 10:53:17 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00dUiCdE; Tue, 13 Apr 2004 10:53:14 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D7r9F12183; Tue, 13 Apr 2004 10:53:09 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 10:53:10 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4212C.5CBC13D4" Subject: RE: RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit time Date: Tue, 13 Apr 2004 10:53:09 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0508@esebe016.ntc.nokia.com> Thread-Topic: RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit time Thread-Index: AcQdpXv3bXROmLFnTR+OTGUX+bfpdQDglYKw From: To: Cc: , X-OriginalArrivalTime: 13 Apr 2004 07:53:10.0047 (UTC) FILETIME=[5D47A2F0:01C4212C] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C4212C.5CBC13D4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chris, =20 Should we clarify section 5 in addition? As the text stands, it is not = clear that there are basically two types of time based quota. =20 I don't think we have two types of time based quota, rather we have some = environment where time based services may consist of two different models. In particular, data = services may be charged based on connection time where the quota is consumed at regular rate or based on the usage = model where the time quota is=20 consumed only when packets are flowing through. That is why we included = the definition of time based services in section 5. I think your proposed text enhancement to this definition = certainly help to clarify the applicability of the tariff change mechanism with respect to time based services. =20 Regards Marco =20 =20 For time based services where the quota is continuously consumed at = the regular rate of=20 60 seconds per minute, the server already knows at the time when=20 credit resources are allocated how many units will be consumed before = the tariff time change and how many units will be consumed after.=20 Similarly, the server can determine the units consumed at the before=20 rate and the units consumed at the rate afterwards in the event that=20 the end-user closes the session before the consumption of the = allotted=20 quota. There is no need for additional traffic between client and=20 server in case of tariff time changes for the continuous time based = service,=20 therefore the tariff change mechanism is not used for continuous time = based=20 services. For time based services where the quota is NOT continuously = consumed =20 at a regular rate, the tariff change mechanism described for volume = and event units =20 MAY be used.=20 ------_=_NextPart_001_01C4212C.5CBC13D4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit = time
Hi=20 Chris,
 
Should we clarify = section 5 in=20 addition? As the text stands, it is not clear that there are basically = two types=20 of time based quota.
 
I=20 don't think we have two types of time based quota, rather we = have some=20 environment where time based
services may consist of two different models. = In=20 particular, data services may be charged based on = connection
time=20 where the quota is consumed at regular rate or based on the usage model = where=20 the time quota is
consumed only when packets are flowing = through. That is=20 why we included the definition of time based = services
in=20 section 5. I think your proposed text enhancement to this definition = certainly=20 help to clarify the applicability
of the=20 tariff change mechanism with respect to time based = services.
 
Regards
Marco
 
 
   For time based services where the quota = is=20 continuously consumed at the regular rate of
   60 seconds per minute, the server already knows at = the time=20 when
   credit resources are = allocated how=20 many units will be consumed before
   the=20 tariff time change and how many units will be consumed after. =
   Similarly, the server can determine the units = consumed at=20 the before
   rate and the units = consumed at=20 the rate afterwards in the event that
   the=20 end-user closes the session before the consumption of the = allotted=20
   quota.  There is no need for = additional=20 traffic between client and
   server = in case=20 of tariff time changes for the continuous time based service, =
   therefore the tariff change mechanism is not used = for=20 continuous time based
  =20 services. For time based services where the = quota is=20 NOT continuously consumed  
   at a regular = rate,  the tariff change mechanism described for volume and event=20 units  
   MAY be used.=20
------_=_NextPart_001_01C4212C.5CBC13D4-- From owner-aaa-wg@merit.edu Tue Apr 13 04:29:05 2004 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 EAA28636 for ; Tue, 13 Apr 2004 04:29:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 16CBF91295; Tue, 13 Apr 2004 04:28:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E09B191296; Tue, 13 Apr 2004 04:28:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AE16991295 for ; Tue, 13 Apr 2004 04:28:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9AF4E584C9; Tue, 13 Apr 2004 04:28:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id A0D43584D3 for ; Tue, 13 Apr 2004 04:28:49 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D8ShO20808; Tue, 13 Apr 2004 11:28:44 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 11:27:24 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3D8ROE0032325; Tue, 13 Apr 2004 11:27:24 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00DfY0S1; Tue, 13 Apr 2004 11:27:23 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D8RHF01339; Tue, 13 Apr 2004 11:27:17 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 11:25:01 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Date: Tue, 13 Apr 2004 11:25:00 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B050A@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Thread-Index: AcQhLFmR1O/Jq5Q9Sk6/sowhu2H2kwAAaMWw From: To: , , , Cc: , X-OriginalArrivalTime: 13 Apr 2004 08:25:01.0215 (UTC) FILETIME=[D06CBAF0:01C42130] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, > Now when draft-lior-radius-prepaid is also chartered in the=20 > RADEXT, it=20 > may be better to move this section to a separate I-D, as=20 > proposed, Sounds good. However, in the DCC we also have the DCC-RADIUS = interworking model (section 2). My proposal would be to move the current section 11 content to a = separate I-D but still keep the Section 11 header. Under section 11 we could move the architecture model of section 2 (figure 2) and related text as well as = the flow II of the appendix. With emphasis that this illustrates the = interworking model but does NOT specify by any means the protocol translation, that = will be specified in separate document etc. What do you think? Should we start to update the document accordingly? Regards Marco=20 From owner-aaa-wg@merit.edu Tue Apr 13 05:20:10 2004 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 FAA00309 for ; Tue, 13 Apr 2004 05:20:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5DE249122B; Tue, 13 Apr 2004 05:19:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2DCDE91296; Tue, 13 Apr 2004 05:19:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 175E59122B for ; Tue, 13 Apr 2004 05:19:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 00C9158551; Tue, 13 Apr 2004 05:19:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 792745850B for ; Tue, 13 Apr 2004 05:19:48 -0400 (EDT) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3D9JlWR019933 for ; Tue, 13 Apr 2004 11:19:47 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 Apr 2004 11:19:47 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <25RJLX02>; Tue, 13 Apr 2004 11:19:47 +0200 Message-ID: From: "Harri Hakala (JO/LMF)" To: "'marco.stura@nokia.com'" , david@mitton.com, jari.arkko@kolumbus.fi, john.loughney@nokia.com Cc: aboba@internaut.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Date: Tue, 13 Apr 2004 11:18:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 13 Apr 2004 09:19:47.0078 (UTC) FILETIME=[76F3A260:01C42138] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Marco, > My proposal would be to move the current section 11 content > to a separate I-D > but still keep the Section 11 header. Under section 11 we > could move the > architecture model of section 2 (figure 2) and related text > as well as the > flow II of the appendix. With emphasis that this illustrates > the interworking > model but does NOT specify by any means the protocol > translation, that will > be specified in separate document etc. > > What do you think? Should we start to update the document accordingly? I think that it doesn't harm to keep the architecture model section as it is, just the reference to section 11 could be removed. Alternatively the figure 2 with related text from the section 2 and flow II could be moved to a new I-D as well. regards..........Harri From owner-aaa-wg@merit.edu Tue Apr 13 06:06:27 2004 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 FAA00329 for ; Tue, 13 Apr 2004 05:20:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 317229129A; Tue, 13 Apr 2004 05:20:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7EDE91297; Tue, 13 Apr 2004 05:20:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 90C879129E for ; Tue, 13 Apr 2004 05:19:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 61A7958514; Tue, 13 Apr 2004 05:19:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id A5F81584D3 for ; Tue, 13 Apr 2004 05:19:57 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 4012989899; Tue, 13 Apr 2004 12:19:41 +0300 (EEST) Message-ID: <407BAFF9.2050808@kolumbus.fi> Date: Tue, 13 Apr 2004 12:16:41 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marco.stura@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: Review of Diameter Credit Control -04 References: <142DC466081D9B409AAD1DDCA4B21E1D018B050A@esebe016.ntc.nokia.com> In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D018B050A@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 marco.stura@nokia.com wrote: > Hi all, > > >>Now when draft-lior-radius-prepaid is also chartered in the >>RADEXT, it >>may be better to move this section to a separate I-D, as >>proposed, > > > Sounds good. However, in the DCC we also have the DCC-RADIUS interworking > model (section 2). > > My proposal would be to move the current section 11 content to a separate I-D > but still keep the Section 11 header. Under section 11 we could move the > architecture model of section 2 (figure 2) and related text as well as the > flow II of the appendix. With emphasis that this illustrates the interworking > model but does NOT specify by any means the protocol translation, that will > be specified in separate document etc. > > What do you think? Should we start to update the document accordingly? I think it sounds good. --Jari P.S. By the way, I think its best that the RADIUS prepaid spec (if adopted by the IETF) defines the interworking too rather than having a separate spec in RADEXT. Some weeks ago a posted a comment to the RADEXT mailing list about the reasons why. Basically, its better to design the protocol so that it can be translated rather than later figure out how the two could fit together. Obviously we couldn't do that here because the translation target did not yet exist in any stable form. From owner-aaa-wg@merit.edu Tue Apr 13 06:22:57 2004 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 GAA02764 for ; Tue, 13 Apr 2004 06:22:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 10E1E91296; Tue, 13 Apr 2004 06:22:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE7B591297; Tue, 13 Apr 2004 06:22:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9BFF291296 for ; Tue, 13 Apr 2004 06:22:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8495A58511; Tue, 13 Apr 2004 06:22:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 93AB1585A7 for ; Tue, 13 Apr 2004 06:22:40 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DAMZn21489; Tue, 13 Apr 2004 13:22:35 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 13:22:23 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3DAMNZW001449; Tue, 13 Apr 2004 13:22:23 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00yCwNoZ; Tue, 13 Apr 2004 13:22:22 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DAMIs14144; Tue, 13 Apr 2004 13:22:19 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 13:21:53 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Date: Tue, 13 Apr 2004 13:21:57 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B050D@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Thread-Index: AcQhOMk1Hxd6KbT0TeqzltWUmV88WAABxKfw From: To: Cc: , , , , X-OriginalArrivalTime: 13 Apr 2004 10:21:53.0985 (UTC) FILETIME=[245C8310:01C42141] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Harri, > I think that it doesn't harm to keep the architecture model section > as it is, just the reference to section 11 could be removed. I think if we group all the DCC-RADIUS interworking related stuff in an own section is more clear for the reader, no? > Alternatively the figure 2 with related text from the section=20 > 2 and flow II > could be moved to a new I-D as well. That could be an alternative as well. However, I feel that some wording=20 in the DCC concerning the interworking with RADIUS should be kept. My preference is to keep the interworking model in DCC and the detailed translation somewhere else, either in separate I-D or in the RADIUS prepaid spec (as suggested by Jari) Jari Arkko wrote: > P.S. By the way, I think its best that the RADIUS prepaid > spec (if adopted by the IETF) defines the interworking too > rather than having a separate spec in RADEXT. Some weeks ago > a posted a comment to the RADEXT mailing list about the > reasons why. Basically, its better to design the protocol > so that it can be translated rather than later figure out > how the two could fit together. Obviously we couldn't do that > here because the translation target did not yet exist in any > stable form. Regards Marco From owner-aaa-wg@merit.edu Tue Apr 13 07:18:53 2004 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 HAA05684 for ; Tue, 13 Apr 2004 07:18:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4F75791299; Tue, 13 Apr 2004 07:18:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 210999129B; Tue, 13 Apr 2004 07:18:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D02A91299 for ; Tue, 13 Apr 2004 07:18:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E7932584D5; Tue, 13 Apr 2004 07:18:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by segue.merit.edu (Postfix) with ESMTP id 4651F584D3 for ; Tue, 13 Apr 2004 07:18:34 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3DBIXAh022779 for ; Tue, 13 Apr 2004 13:18:33 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 Apr 2004 13:18:33 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <25RJNAMR>; Tue, 13 Apr 2004 13:18:33 +0200 Message-ID: From: "Harri Hakala (JO/LMF)" To: "'marco.stura@nokia.com'" Cc: aboba@internaut.com, aaa-wg@merit.edu, jari.arkko@kolumbus.fi, david@mitton.com, john.loughney@nokia.com Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Date: Tue, 13 Apr 2004 13:17:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 13 Apr 2004 11:18:33.0031 (UTC) FILETIME=[0E59C570:01C42149] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, > > I think that it doesn't harm to keep the architecture model section > > as it is, just the reference to section 11 could be removed. > > I think if we group all the DCC-RADIUS interworking related stuff in > an own section is more clear for the reader, no? Yes, that's true, but then it would be good to provide some high level principles as well, the architecture model 2 and example flow II alone might be a bit separate pieces of information. > > Alternatively the figure 2 with related text from the section > > 2 and flow II > > could be moved to a new I-D as well. > > That could be an alternative as well. However, I feel that > some wording > in the DCC concerning the interworking with RADIUS should be kept. > My preference is to keep the interworking model in DCC and > the detailed > translation somewhere else, either in separate I-D or in the RADIUS > prepaid spec (as suggested by Jari) To achieve the good interworking model, we perhaps should try to modify the current section 11 by removing all distracting details and adding architecture model 2 and the interworking flow (flow II) with modified text. regards.............Harri From owner-aaa-wg@merit.edu Tue Apr 13 07:35:40 2004 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 HAA06401 for ; Tue, 13 Apr 2004 07:35:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EDF529129B; Tue, 13 Apr 2004 07:35:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD80A9129E; Tue, 13 Apr 2004 07:35:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 911939129B for ; Tue, 13 Apr 2004 07:35:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7E80A58595; Tue, 13 Apr 2004 07:35:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id ACEA558538 for ; Tue, 13 Apr 2004 07:35:22 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DBZHk25194; Tue, 13 Apr 2004 14:35:17 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 14:34:43 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3DBYhRm006884; Tue, 13 Apr 2004 14:34:43 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00rjtAqe; Tue, 13 Apr 2004 14:34:42 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DBYbs09215; Tue, 13 Apr 2004 14:34:37 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 14:34:20 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Date: Tue, 13 Apr 2004 14:34:26 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C867B@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Thread-Index: AcQhSU6dPaFHsiy/QqGTAtTj62BT5wAAbLJA From: To: Cc: , , , , X-OriginalArrivalTime: 13 Apr 2004 11:34:20.0735 (UTC) FILETIME=[4339ECF0:01C4214B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Harri, > To achieve the good interworking model, we perhaps should try=20 > to modify the=20 > current section 11 by removing all distracting details and=20 > adding architecture > model 2 and the interworking flow (flow II) with modified text. Agree. Do others agree with this approach too? Regards Marco From owner-aaa-wg@merit.edu Tue Apr 13 07:36:57 2004 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 HAA06446 for ; Tue, 13 Apr 2004 07:36:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 00B7F9129E; Tue, 13 Apr 2004 07:36:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C26F29129F; Tue, 13 Apr 2004 07:36:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9C0FA9129E for ; Tue, 13 Apr 2004 07:36:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8866E585B6; Tue, 13 Apr 2004 07:36:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 8B93458538 for ; Tue, 13 Apr 2004 07:36:41 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DBaan09449; Tue, 13 Apr 2004 14:36:36 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 14:35:54 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3DBZsOs007700; Tue, 13 Apr 2004 14:35:54 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00Y0gPQH; Tue, 13 Apr 2004 14:35:52 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DBZjs10053; Tue, 13 Apr 2004 14:35:45 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 14:35:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Date: Tue, 13 Apr 2004 14:35:41 +0300 Message-ID: Thread-Topic: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Thread-Index: AcQhSU6dPaFHsiy/QqGTAtTj62BT5wAAbLJAAAAbPnA= From: To: , Cc: , , , X-OriginalArrivalTime: 13 Apr 2004 11:35:35.0595 (UTC) FILETIME=[6FD8A7B0:01C4214B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Fine with me. John > -----Original Message----- > From: Stura Marco (Nokia-NET/Helsinki)=20 > Sent: 13 April, 2004 14:34 > To: 'ext Harri Hakala (JO/LMF)' > Cc: aboba@internaut.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi; > david@mitton.com; Loughney John (Nokia-NRC/Helsinki) > Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 >=20 >=20 > Hi Harri, >=20 > > To achieve the good interworking model, we perhaps should try=20 > > to modify the=20 > > current section 11 by removing all distracting details and=20 > > adding architecture > > model 2 and the interworking flow (flow II) with modified text. >=20 > Agree. Do others agree with this approach too? >=20 > Regards > Marco >=20 From owner-aaa-wg@merit.edu Tue Apr 13 07:44:16 2004 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 HAA06746 for ; Tue, 13 Apr 2004 07:44:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 780B79129F; Tue, 13 Apr 2004 07:44:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4DBCC912A0; Tue, 13 Apr 2004 07:44:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D068E9129F for ; Tue, 13 Apr 2004 07:44:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B60D5586A6; Tue, 13 Apr 2004 07:44:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ns2.bln1.siemens.de (ns2.bln1.siemens.de [194.138.127.35]) by segue.merit.edu (Postfix) with ESMTP id EE17658574 for ; Tue, 13 Apr 2004 07:43:59 -0400 (EDT) Received: from ns-srv-2.bln1.siemens.de (stbf7654 [194.138.127.67]) by ns2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id i3DBhpNH008353; Tue, 13 Apr 2004 13:43:52 +0200 (MEST) Received: from blnss10a.bln1.siemens.de (blnss10a.bln1.siemens.de [194.138.127.102]) by ns-srv-2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id i3DBhfKZ001729; Tue, 13 Apr 2004 13:43:44 +0200 (MEST) Received: by blnss10a.bln1.siemens.de with Internet Mail Service (5.5.2653.19) id <2MTYMC8G>; Tue, 13 Apr 2004 13:43:41 +0200 Message-ID: <445C57B81208C24EAD99F2944DBB9D290551C203@blnss10a.bln1.siemens.de> From: Schendel Jens ICM Berlin To: "'marco.stura@nokia.com'" , crich@nortelnetworks.com Cc: aaa-wg@merit.edu, Schendel Jens ICM Berlin Subject: RE: RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit time Date: Tue, 13 Apr 2004 13:43:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4214C.8E072300" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4214C.8E072300 Content-Type: text/plain Marco, Chris, the textual enhancement as proposed by Chris sounds ok to me. Regards, Jens -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Dienstag, 13. April 2004 09:53 To: crich@nortelnetworks.com Cc: aaa-wg@merit.edu; jens.schendel@siemens.com Subject: RE: RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit time Hi Chris, Should we clarify section 5 in addition? As the text stands, it is not clear that there are basically two types of time based quota. I don't think we have two types of time based quota, rather we have some environment where time based services may consist of two different models. In particular, data services may be charged based on connection time where the quota is consumed at regular rate or based on the usage model where the time quota is consumed only when packets are flowing through. That is why we included the definition of time based services in section 5. I think your proposed text enhancement to this definition certainly help to clarify the applicability of the tariff change mechanism with respect to time based services. Regards Marco For time based services where the quota is continuously consumed at the regular rate of 60 seconds per minute, the server already knows at the time when credit resources are allocated how many units will be consumed before the tariff time change and how many units will be consumed after. Similarly, the server can determine the units consumed at the before rate and the units consumed at the rate afterwards in the event that the end-user closes the session before the consumption of the allotted quota. There is no need for additional traffic between client and server in case of tariff time changes for the continuous time based service, therefore the tariff change mechanism is not used for continuous time based services. For time based services where the quota is NOT continuously consumed at a regular rate, the tariff change mechanism described for volume and event units MAY be used. ------_=_NextPart_001_01C4214C.8E072300 Content-Type: text/html Message
Marco, Chris,
 
the textual enhancement as proposed by Chris sounds ok to me.
 
Regards, Jens
-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Dienstag, 13. April 2004 09:53
To: crich@nortelnetworks.com
Cc: aaa-wg@merit.edu; jens.schendel@siemens.com
Subject: RE: RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit time

Hi Chris,
 
Should we clarify section 5 in addition? As the text stands, it is not clear that there are basically two types of time based quota.
 
I don't think we have two types of time based quota, rather we have some environment where time based
services may consist of two different models. In particular, data services may be charged based on connection
time where the quota is consumed at regular rate or based on the usage model where the time quota is
consumed only when packets are flowing through. That is why we included the definition of time based services
in section 5. I think your proposed text enhancement to this definition certainly help to clarify the applicability
of the tariff change mechanism with respect to time based services.
 
Regards
Marco
 
 
   For time based services where the quota is continuously consumed at the regular rate of
   60 seconds per minute, the server already knows at the time when
   credit resources are allocated how many units will be consumed before
   the tariff time change and how many units will be consumed after.
   Similarly, the server can determine the units consumed at the before
   rate and the units consumed at the rate afterwards in the event that
   the end-user closes the session before the consumption of the allotted
   quota.  There is no need for additional traffic between client and
   server in case of tariff time changes for the continuous time based service,
   therefore the tariff change mechanism is not used for continuous time based
   services. For time based services where the quota is NOT continuously consumed  
   at a regular rate,  the tariff change mechanism described for volume and event units  
   MAY be used.
------_=_NextPart_001_01C4214C.8E072300-- From owner-aaa-wg@merit.edu Tue Apr 13 11:11:32 2004 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 LAA16501 for ; Tue, 13 Apr 2004 11:11:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AA0239128C; Tue, 13 Apr 2004 11:11:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7586791293; Tue, 13 Apr 2004 11:11:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 32C159128C for ; Tue, 13 Apr 2004 11:11:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 05969585B6; Tue, 13 Apr 2004 11:11:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id 0C1E85868E for ; Tue, 13 Apr 2004 11:11:15 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3D6CwPA014849 for ; Tue, 13 Apr 2004 08:12:58 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 Apr 2004 08:12:58 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <25RJJVJD>; Tue, 13 Apr 2004 08:12:58 +0200 Message-ID: From: "Harri Hakala (JO/LMF)" To: "'David Mitton'" , Jari Arkko , john.loughney@nokia.com Cc: aboba@internaut.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Date: Tue, 13 Apr 2004 08:11:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 13 Apr 2004 06:12:58.0650 (UTC) FILETIME=[5E353FA0:01C4211E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Dave, I do agree that the guidelines and details in the Interworking section are not right balanced. Also some important standardization details are missing, but it is quite hard to define these details without having a bit more stable target document for translation. Now when draft-lior-radius-prepaid is also chartered in the RADEXT, it may be better to move this section to a separate I-D, as proposed, instead of keeping this section even as an informative appendix. This due to fact that the comprehensive interworking description may be rather large, depending on, of course, the level of details that will be covered. For instance, at the moment just translation from very basic session based credit control to Radius prepaid is covered in the DCC draft. It may be feasible to provide also the translation of optional features, e.g. one time events, graceful service termination, tariff switch, credit-control for multiple services and those ones which will be described in the Radius prepaid draft. Handling of failure cases, such as the mapping of result codes could be good to cover as well. It should also define full-fledged parameter mapping, containing those details which are not now specified. regards........Harri > -----Original Message----- > From: David Mitton [mailto:david@mitton.com] > Sent: 8. huhtikuuta 2004 17:26 > To: Jari Arkko; john.loughney@nokia.com > Cc: Harri Hakala (JO/LMF); aboba@internaut.com; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue: Review of Diameter Credit Control -04 > > > Harri, et.al., > > I had a similar reaction as Jari, but let me put it > in my own words. > > I'm not sure I understand the utility of the text as it is. > The text says that it will explain how to do something, and > it tries for > several pages, but it leaves out a lot of important details. > You say it's supposed to be guideline, and I go back and find > those words > in the document but I forgot them because the section is very > declarative. It seems to go much further than guidelines, > but you are not > trying to standardize this protocol in this document. > > A guideline could suggest what data elements and transactions > are important > to translate, but should not proscribe the format (eg RADIUS VSAs). > > I can see that writing a true guideline section might be > problematic. And > if the issues need to be decided, then maybe it's not useful here. > > If we want to keep this, I think this would be more appropriate as an > informative appendix, with more words to the effect of it's > incompleteness. > > Dave. > > > On 4/8/2004 03:35 PM +0300, Jari Arkko wrote: > > >I wonder how useful the translation to an imaginary > >protocol is. I agree that the RADEXT RADIUS prepaid > >document should be the normative specification for > >such translations. > > > >What would we lose if Section 11 was deleted? Is > >there a specific requirement from someone to have > >this mapping? If yes, perhaps Section 11 should be > >moved to an appendix and contain the explanation > >for the needed specific translation, even if the > >translation target is just an I-D. > > > >If no, maybe you should just simplify your document > >by leaving Section 11 to RADEXT, have them write it > >once they figure what kind of RADIUS prepaid they > >will make. > > > >--Jari > > > >john.loughney@nokia.com wrote: > >>Dave / Bernard, > >> > >>>The section 11 is meant to be more as a guideline and not a full > >>>solution because no > >>>corresponding RADIUS prepaid RFC exists. Anyway, we felt > that having an > >>>informative section on this was needed. So, basically we > tried to write > >>>basic principle how to translate some Diameter AVPs and > messages to more > >>>or less imaginary RADIUS prepaid application, using the > RFC 2865 as a > >>>base. We are aware of the draft-lior-radius-prepaid > >>>but since that work is still in progress the exact mapping to this > >>>document was not possible. > >>> > >>>The RFC of Radius prepaid (when available) should define a > complete > >>>description of protocol translation between Radius prepaid > and Diameter > >>>credit control, if we follow the principle that the > document (Radius, > >>>Diameter) that comes last is responsible for defining the mapping. > >>> > >>>The first paragraph in section 11 is intended to highlight > this but > >>>perhaps some re-wording is > >>>needed here. > >>> > >>>In Annex A, the flow 1 shows the message translation > between Radius > >>>prepaid and Diameter CC, but > >>>the purpose was not to show a full-fledged parameter > mapping for the > >>>above reasons. > >> > >>Any response to this? Does this answer the questions? > >>John > > > > > > From owner-aaa-wg@merit.edu Tue Apr 13 11:25:09 2004 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 LAA17045 for ; Tue, 13 Apr 2004 11:25:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2E53B912A0; Tue, 13 Apr 2004 11:24:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9EB3912A2; Tue, 13 Apr 2004 11:24:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9B7EB912A0 for ; Tue, 13 Apr 2004 11:24:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7E47658690; Tue, 13 Apr 2004 11:24:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id D68745875D for ; Tue, 13 Apr 2004 11:24:51 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Tue, 13 Apr 2004 11:24:46 -0400 Message-ID: From: Avi Lior To: "'Harri Hakala (JO/LMF)'" , "'David Mitton'" , Jari Arkko , john.loughney@nokia.com Cc: aboba@internaut.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Date: Tue, 13 Apr 2004 11:24:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Just to let you know I am listening to this conversation. The one thing I want to avoid in RADIUS prepaid is to add a lot of features into the current document that are not really required by current RADIUS implementations. Instead, my thinking is that RADIUS Prepaid draft will establish the framework for doing prepaid and extensions can be added later. Currently, we have "standard" prepaid support (as done by 3GPP2) and we were asked to do one time events. Although I haven't formally seen the requirements I think I know where they are coming from. Tarrif switching which is done in 3GPP2 is not addressed. It could be addressed in this document or it could be added later. I haven't seen anyone wanting it in RADIUS -- for example, in WLAN. To this end, we could address the base Prepaid interworking with Diameter CC in the Prepaid draft. Comments? Also note, that there could be prepaid features that come from RADIUS deployements that are not addressed by the Diameter CC application. > -----Original Message----- > From: Harri Hakala (JO/LMF) [mailto:harri.hakala@ericsson.com] > Sent: Tuesday, April 13, 2004 2:12 AM > To: 'David Mitton'; Jari Arkko; john.loughney@nokia.com > Cc: aboba@internaut.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 > > > Hi Dave, > > I do agree that the guidelines and details in the > Interworking section are not right balanced. Also some > important standardization details are > missing, but it is quite hard to define these details without having > a bit more stable target document for translation. > > Now when draft-lior-radius-prepaid is also chartered in the > RADEXT, it > may be better to move this section to a separate I-D, as > proposed, instead of keeping this section even as an > informative appendix. This due to fact that > the comprehensive interworking description may be rather > large, depending on, of course, the level of details that > will be covered. For instance, at > the moment just translation from very basic session based > credit control to > Radius prepaid is covered in the DCC draft. It may be > feasible to provide > also the translation of optional features, e.g. one time > events, graceful > service termination, tariff switch, credit-control for > multiple services > and those ones which will be described in the Radius prepaid > draft. Handling of failure cases, such as the mapping of > result codes could be good to cover as well. It should also > define full-fledged parameter mapping, containing those > details which are not now specified. > > regards........Harri > > > -----Original Message----- > > From: David Mitton [mailto:david@mitton.com] > > Sent: 8. huhtikuuta 2004 17:26 > > To: Jari Arkko; john.loughney@nokia.com > > Cc: Harri Hakala (JO/LMF); aboba@internaut.com; aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: Issue: Review of Diameter Credit Control -04 > > > > > > Harri, et.al., > > > > I had a similar reaction as Jari, but let me put it > > in my own words. > > > > I'm not sure I understand the utility of the text as it is. > The text > > says that it will explain how to do something, and it tries for > > several pages, but it leaves out a lot of important details. > > You say it's supposed to be guideline, and I go back and find > > those words > > in the document but I forgot them because the section is very > > declarative. It seems to go much further than guidelines, > > but you are not > > trying to standardize this protocol in this document. > > > > A guideline could suggest what data elements and transactions > > are important > > to translate, but should not proscribe the format (eg RADIUS VSAs). > > > > I can see that writing a true guideline section might be > > problematic. And > > if the issues need to be decided, then maybe it's not useful here. > > > > If we want to keep this, I think this would be more > appropriate as an > > informative appendix, with more words to the effect of it's > > incompleteness. > > > > Dave. > > > > > > On 4/8/2004 03:35 PM +0300, Jari Arkko wrote: > > > > >I wonder how useful the translation to an imaginary > > >protocol is. I agree that the RADEXT RADIUS prepaid > > >document should be the normative specification for > > >such translations. > > > > > >What would we lose if Section 11 was deleted? Is > > >there a specific requirement from someone to have > > >this mapping? If yes, perhaps Section 11 should be > > >moved to an appendix and contain the explanation > > >for the needed specific translation, even if the > > >translation target is just an I-D. > > > > > >If no, maybe you should just simplify your document > > >by leaving Section 11 to RADEXT, have them write it > > >once they figure what kind of RADIUS prepaid they > > >will make. > > > > > >--Jari > > > > > >john.loughney@nokia.com wrote: > > >>Dave / Bernard, > > >> > > >>>The section 11 is meant to be more as a guideline and not a full > > >>>solution because no > > >>>corresponding RADIUS prepaid RFC exists. Anyway, we felt > > that having an > > >>>informative section on this was needed. So, basically we > > tried to write > > >>>basic principle how to translate some Diameter AVPs and > > messages to more > > >>>or less imaginary RADIUS prepaid application, using the > > RFC 2865 as a > > >>>base. We are aware of the draft-lior-radius-prepaid > > >>>but since that work is still in progress the exact > mapping to this > > >>>document was not possible. > > >>> > > >>>The RFC of Radius prepaid (when available) should define a > > complete > > >>>description of protocol translation between Radius prepaid > > and Diameter > > >>>credit control, if we follow the principle that the > > document (Radius, > > >>>Diameter) that comes last is responsible for defining > the mapping. > > >>> > > >>>The first paragraph in section 11 is intended to highlight > > this but > > >>>perhaps some re-wording is > > >>>needed here. > > >>> > > >>>In Annex A, the flow 1 shows the message translation > > between Radius > > >>>prepaid and Diameter CC, but > > >>>the purpose was not to show a full-fledged parameter > > mapping for the > > >>>above reasons. > > >> > > >>Any response to this? Does this answer the questions? > > >>John > > > > > > > > > > > From owner-aaa-wg@merit.edu Tue Apr 13 13:32:47 2004 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 NAA23870 for ; Tue, 13 Apr 2004 13:32:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F1908912A4; Tue, 13 Apr 2004 13:32:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1240912A6; Tue, 13 Apr 2004 13:32:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9ED80912A4 for ; Tue, 13 Apr 2004 13:32:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A909F582C6; Tue, 13 Apr 2004 13:32:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id A9165582A5 for ; Tue, 13 Apr 2004 13:32:22 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DHWAn08619; Tue, 13 Apr 2004 20:32:10 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 20:31:58 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3DHVwhl009935; Tue, 13 Apr 2004 20:31:58 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00CuyYXq; Tue, 13 Apr 2004 20:31:57 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DHVus25921; Tue, 13 Apr 2004 20:31:56 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 20:31:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Date: Tue, 13 Apr 2004 20:31:45 +0300 Message-ID: Thread-Topic: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Thread-Index: AcQha5LUHU94KQOqSf2C8PdpEuQtOAAEY+kg From: To: , , , Cc: , X-OriginalArrivalTime: 13 Apr 2004 17:31:45.0137 (UTC) FILETIME=[3115FE10:01C4217D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Avi, > To this end, we could address the base Prepaid interworking=20 > with Diameter CC in the Prepaid draft. That sounds reasonable to me. John From owner-aaa-wg@merit.edu Tue Apr 13 13:38:01 2004 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 NAA24139 for ; Tue, 13 Apr 2004 13:38:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8869A912A7; Tue, 13 Apr 2004 13:37:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 55FC4912A8; Tue, 13 Apr 2004 13:37:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0701C912A7 for ; Tue, 13 Apr 2004 13:37:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8F7D6582C9; Tue, 13 Apr 2004 13:37:43 -0400 (EDT) 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 0D95F582BC for ; Tue, 13 Apr 2004 13:37:41 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3DHbWM02172; Tue, 13 Apr 2004 12:37:32 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Apr 2004 12:37:32 -0500 Message-ID: <161AA64DA85DFC4BA4D2EB5629B59753060FEC99@zrc2c012.us.nortel.com> From: "Christopher Richards" To: marco.stura@nokia.com Cc: aaa-wg@merit.edu, jens.schendel@siemens.com Subject: RE: RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit time Date: Tue, 13 Apr 2004 12:37:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4217D.FF269EEA" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4217D.FF269EEA Content-Type: text/plain Thanks Marco, So the text I proposed (at the end of the email) is OK and will be incorporated into the document? Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Tuesday, April 13, 2004 2:53 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; jens.schendel@siemens.com Subject: RE: RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit time Hi Chris, Should we clarify section 5 in addition? As the text stands, it is not clear that there are basically two types of time based quota. I don't think we have two types of time based quota, rather we have some environment where time based services may consist of two different models. In particular, data services may be charged based on connection time where the quota is consumed at regular rate or based on the usage model where the time quota is consumed only when packets are flowing through. That is why we included the definition of time based services in section 5. I think your proposed text enhancement to this definition certainly help to clarify the applicability of the tariff change mechanism with respect to time based services. Regards Marco For time based services where the quota is continuously consumed at the regular rate of 60 seconds per minute, the server already knows at the time when credit resources are allocated how many units will be consumed before the tariff time change and how many units will be consumed after. Similarly, the server can determine the units consumed at the before rate and the units consumed at the rate afterwards in the event that the end-user closes the session before the consumption of the allotted quota. There is no need for additional traffic between client and server in case of tariff time changes for the continuous time based service, therefore the tariff change mechanism is not used for continuous time based services. For time based services where the quota is NOT continuously consumed at a regular rate, the tariff change mechanism described for volume and event units MAY be used. ------_=_NextPart_001_01C4217D.FF269EEA Content-Type: text/html Message
Thanks Marco,
 
So the text I proposed (at the end of the email) is OK and will be incorporated into the document?

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Tuesday, April 13, 2004 2:53 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; jens.schendel@siemens.com
Subject: RE: RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit time

Hi Chris,
 
Should we clarify section 5 in addition? As the text stands, it is not clear that there are basically two types of time based quota.
 
I don't think we have two types of time based quota, rather we have some environment where time based
services may consist of two different models. In particular, data services may be charged based on connection
time where the quota is consumed at regular rate or based on the usage model where the time quota is
consumed only when packets are flowing through. That is why we included the definition of time based services
in section 5. I think your proposed text enhancement to this definition certainly help to clarify the applicability
of the tariff change mechanism with respect to time based services.
 
Regards
Marco
 
 
   For time based services where the quota is continuously consumed at the regular rate of
   60 seconds per minute, the server already knows at the time when
   credit resources are allocated how many units will be consumed before
   the tariff time change and how many units will be consumed after.
   Similarly, the server can determine the units consumed at the before
   rate and the units consumed at the rate afterwards in the event that
   the end-user closes the session before the consumption of the allotted
   quota.  There is no need for additional traffic between client and
   server in case of tariff time changes for the continuous time based service,
   therefore the tariff change mechanism is not used for continuous time based
   services. For time based services where the quota is NOT continuously consumed  
   at a regular rate,  the tariff change mechanism described for volume and event units  
   MAY be used.
------_=_NextPart_001_01C4217D.FF269EEA-- From owner-aaa-wg@merit.edu Tue Apr 13 14:07:54 2004 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 OAA25351 for ; Tue, 13 Apr 2004 14:07:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 96AD3912A8; Tue, 13 Apr 2004 14:07:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 68398912AB; Tue, 13 Apr 2004 14:07:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 58420912A8 for ; Tue, 13 Apr 2004 14:07:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3951B582E1; Tue, 13 Apr 2004 14:07:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id B3DF3582D1 for ; Tue, 13 Apr 2004 14:07:38 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id C80768981C; Tue, 13 Apr 2004 21:07:33 +0300 (EEST) Message-ID: <407C2BB1.9050107@kolumbus.fi> Date: Tue, 13 Apr 2004 21:04:33 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: Review of Diameter Credit Control -04 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Avi Lior wrote: > Just to let you know I am listening to this conversation. > > The one thing I want to avoid in RADIUS prepaid is to add a lot of features > into the current document that are not really required by current RADIUS > implementations. > > Instead, my thinking is that RADIUS Prepaid draft will establish the > framework for doing prepaid and extensions can be added later. Sounds good. > Currently, we have "standard" prepaid support (as done by 3GPP2) and we were > asked to do one time events. Although I haven't formally seen the > requirements I think I know where they are coming from. > > Tarrif switching which is done in 3GPP2 is not addressed. It could be > addressed in this document or it could be added later. I haven't seen > anyone wanting it in RADIUS -- for example, in WLAN. > > To this end, we could address the base Prepaid interworking with Diameter CC > in the Prepaid draft. Works for me. --Jari From aaa-admin@ietf.org Tue Apr 13 15:42:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02351 for ; Tue, 13 Apr 2004 15:42:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTcc-0002iB-BC; Tue, 13 Apr 2004 15:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTZV-00028S-3C for aaa@optimus.ietf.org; Tue, 13 Apr 2004 15:27:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01258 for ; Tue, 13 Apr 2004 15:27:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDTZS-000086-00 for aaa@ietf.org; Tue, 13 Apr 2004 15:27:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDTY4-00000r-00 for aaa@ietf.org; Tue, 13 Apr 2004 15:26:21 -0400 Received: from p5090dd37.dip.t-dialin.net ([80.144.221.55]) by ietf-mx with smtp (Exim 4.12) id 1BDTWW-0007fh-00 for aaa@ietf.org; Tue, 13 Apr 2004 15:24:46 -0400 Received: from 50.129.105.206 by 80.144.221.55; Wed, 14 Apr 2004 01:24:37 +0500 Message-ID: From: "Pam Lindsay" Reply-To: "Pam Lindsay" To: aaa@ietf.org Date: Wed, 14 Apr 2004 01:23:37 +0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--83386659433471649598" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.9 required=5.0 tests=FORGED_MUA_OIMO, FORGED_OUTLOOK_TAGS,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 2.7 FORGED_MUA_OIMO Forged mail pretending to be from MS Outlook IMO Subject: [Aaa] Your Prescription is Ready.. Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , ----83386659433471649598 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


If the message is n ot loading try this


Jrawlinson serine byron forbid cadaverous adequate extraneous again an= thropomorphism consternate guidebook naomi freya crewman arboreal market e= li nitride prescription boone schulz bestir vis adversary christenson arti= san beardsley lambda brothel=20.Xdelectate coextensive shag squint annihil= ate tool antagonist dihedral analyst arkansas bess filthy woman plutarch c= ompression bonanza berlitz increment pulsate ringside nephew fuchsia=20!Hi= naugurate referendum wi lumen rate jim calgary taffy citadel piccadilly pe= llet chorale conveyance carrel avalanche cloven clothier arrival glassware= elysee racial suppress astronautic born decolletage dick=20;Qchancy wick = rigel locomotive chignon clobber impart lemma excretion hierarchic fletch = spin illusionary cos marcello stopwatch conner scamp velvety act nietzsche= bayreuth stefan tackle toastmaster traverse=20;Satwater croix book denunc= iate phosphorescent collision madmen broody royalty=20.Pgush crab nominate= contradistinct bronco stiffen alumnae inviolable ouzel aide cartography s= partan feedback sidewinder=20;Kcarcinogenic compelling esquire disciple ca= r nondescript decree retinue among facile extravagant mcguire toady=20.Efr= au coquette aversion crisp sagacity conundrum industry psychophysiology=20= ;Hoblige cyanate danny micrography testament chalice celebrant interferenc= e merchant parasitic college saccharine stripy physiotherapy newcastle bou= gh portmanteau vogue defensible allstate=20.Rapocryphal posse armoire ashl= ey remand barrette conformation shield commensurate presume dewar elide de= ficit ingredient deuce blowback simpleminded inept consulate airy pentagra= m dixon ma cannel alphabetic dad bovine lion tour=20?Sshod direct convales= cent gresham arab delimitation cataract croft particular susceptible aggri= eve droplet late carbonium alexandre responsive actinide maximal introject= oceanic awoke=20!Mbologna crankshaft code wild dicotyledon dossier lesson= macho=20.Fambulant cloven iv apposite maverick james lithospheric prepara= tion utensil bland myrtle=20.Ganti cycle myrtle bellman lavabo upheaval co= mpete hodges redstone seton sorption buses dither dealt auspices inflammab= le gar archbishop toffee booty vice metaphoric=20'Lpr wesleyan actor emper= or alfred adiabatic jovial junk davenport=20.Facoustic edwardian frosty br= ownish halifax inarticulate distort bound accordant immeasurable coercion = equipotent enquire arlen downright contiguous valley lab bale desolate bio= tic depict oft mettlesome beachhead grown=20'Equarry royal poverty adolph = giraffe charlottesville comparative order basophilic waybill flung or tigr= ess=20?Bdespotic k's cutset crewel codicil dey cannery bonaparte asunder c= hamp malleable british=20'Bdecibel durkin edna krishna marmot asteroid six= fold half proscription bendix yond arduous apparent mckay chungking commod= ious rival codeposit sima compression australis tarpaper benjamin=20.Uhygr= oscopic denunciation wishful bradbury autocracy verbal champagne swanlike = z montage awkward adieu headmaster gannett flip gadgetry o'connor ramp bri= ttle bert sprague shade pontiac stylus adjourn=20.Peast pretend curate net= tlesome delphinus seed boggy anchovy iceland munch confident strum herself= chevalier washington chungking rosebud metzler burro dune gertrude bay se= veral clayton saddlebag principle blaine hewitt eighty=20.Bleopold mi coup= thompson puffy ineffectual jubilate dime rime scandal severn pacify dogba= ne bowl horace like clumsy fabian function subversive trundle gadfly godli= ke pedigree=20.Lslothful falcon mange newsweek blip anyway crescent cloist= er hondo chiton bullock pope spacecraft sin alvarez hive pleasure alan pro= pitious=20,Ltelefunken buchanan veridic antipodean delirium quicklime depi= ct cringe sahara dactyl lightweight neurology grill thunderous stumble per= spire parolee guesswork credenza bleach resultant rutabaga goldman bumptio= us affirmative epitaph cyanate=20,Gglorious blair contaminant eastward mak= eshift downtrend puncture embalm tousle surtout highland potential aside a= ngiosperm cyclorama chauffeur bangui telethon opec bodybuilding coney alle= ntown adult defraud fluid gibbet methodism=20!Iectopic piddle conjunct rur= al laden toothpaste deadhead oxygenate=20?Gasinine michigan deluxe carne d= ogtooth hypocrite turnpike burnish tenacity archer=20.Fcurse behold ruben = mushy perdition haven electrocardiogram retrogressive actinolite jot romeo= more auditory furze neurosis die citizen augusta=20. Xeclat barracuda beg= etting irwin burnham altern gritty respondent dive cotty syndic chosen tra= nspond boyhood bagging oxcart winsome animadvert accra mimic jovanovich=20= ;Cdocket bond jaeger md inter peacetime confucian wall eighteenth telegram= titular atomic bolo asbestos gaffe ito converge thunderflower bator aceto= ne=20'Teavesdropper anita nashville dee spire procaine instable specious m= embrane product nicaragua conakry banks cytolysis cyrus calibre irreplacea= ble birefringent expectant maternal none exploitation originate=20?Erememb= er dawn homecoming cannibal an confront crowfoot jog dietary resort dreadf= ul voice cornet girlish=20!Cchimera acrimonious amoco weaponry barnyard wh= oever abel crisis minimal repelled alcoholic stafford escape lenny banjo d= onner manuel lipschitz emulate southward blab=20!Ecommunal elsewhere burke= easy minimal supply cessna contradistinction amateur payroll fanfold trib= esman gallantry sulfur sloe bladder historian=20!Sscrewworm rhodium anothe= r destabilize pterodactyl strontium deluge allegoric dapple brake=20;Hvigi= lant hardscrabble arteriolosclerosis fingerprint frangipani sidereal malon= ey shim bulwark delectate paraphrase forlorn leonine immobile rawhide iris= h=20'Nauerbach ticket shah drum beheld honest repairman farthest welsh eng= land fawn depart manipulable monkish bureaucrat bistable fir poisson someb= ody gander middle artful managua puberty stephenson grindstone upheaval sc= henectady=20!Xcockcrow timothy canteen israelite bogey miriam seth surrept= itious belittle airlock besiege asleep frosty antisemitism as brushlike he= reby nostrand pugnacious physiognomy radial tableau tinder formatting gadw= all factorial chirp decelerate bernice drew=20.Zsteen pemmican destructor = nape affricate rate censor codeposit somers xi agnes equanimity peat diagn= osable plop wakeup kidde trichloroacetic=20?Xclassic feint bevy suggestive= bombard tide heart wallaby consolation accentual ceil stomach mesa emilio= chinook vertex well hermetic restaurateur efficient minuteman dar diamagn= etic boxwood initiate=20?Pcomrade bistate mendel cabot antimony sawyer pre= sumed square minneapolis warmth abutting bronze genetic tidbit buxom night= marish speedy slocum subsidiary halt conferrable croquet=20,Imythology pol= ytypy incomparable clean cherry fujitsu consultant aztecan scrawl infernal= fluff mealy cease dilute burp dhabi arterial egotism nolan allot burton b= abysat cattail bluster ternary contravariant edwardine empiric=20,Wincreas= e bought phobic grudge churchgoing beam trailhead awl worksheet crumple am= sterdam smolder worship ramify burp devise=20.Dbantus jeremiah brewery bit= ch death conakry introit schist lemma coronet isaacson ineluctable bribe m= othball camden hathaway psychosis czech privilege moccasin clothbound four= teen propylene aiken ernst lid kangaroo racket=20'Istencil speck angeles g= ypsum allstate proctor dagger acceptant guess flagrant cog vulcan yow whee= lhouse burlington=20?Corleans paleolithic benedict persuade wold architect= chinook skyrocket gaugeable nostalgic cutlet avenge garlic genotype=20.Lm= issive abyssinia rupture fedders penates dukedom serfdom forsook flank lan= thanum scuffle deadline accompaniment miles angstrom bimodal monk peoria=20= ,Pdevour antiquary jeopard seventieth brooke aqueous semaphore explicable=20= Espeedup vibrant chuckwalla iceberg breccia middleman littleton malaysia = jitterbugger matson pvc lemon gresham allotted tenebrous fourth milch pyro= lyse crises kronecker busch chaise deceit r's pollard analysis cowherd dum= pty tannin=20?Afleshy rome indeterminable coalesce trot incumbent tradeoff= gent academic subjectivity athens dully tenon bawl astride triton courtya= rd foist faustus ellsworth perfectible lansing rabies hare basilar eastwar= d cyst wondrous michelson dunce=20.Ynitrous backscatter penumbra testate a= dorn dilogarithm analytic chanson=20.Vlower julio queasy burg nitrogen bud= apest prostitution genius pent children pragmatic lug fault antipasto bere= ave stratosphere application byrd symbiotic dysplasia couturier=20!

----83386659433471649598-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Tue Apr 13 17:17:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09214 for ; Tue, 13 Apr 2004 17:17:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDUvC-0001vU-AI for aaa-archive@odin.ietf.org; Tue, 13 Apr 2004 16:54:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DKsIQX007400 for aaa-archive@odin.ietf.org; Tue, 13 Apr 2004 16:54:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDToo-0004gs-D7 for aaa-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 15:43:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02422 for ; Tue, 13 Apr 2004 15:43:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDTom-0001jt-00 for aaa-web-archive@ietf.org; Tue, 13 Apr 2004 15:43:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDTnD-0001YQ-00 for aaa-web-archive@ietf.org; Tue, 13 Apr 2004 15:41:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTcc-0002iB-BC; Tue, 13 Apr 2004 15:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTZV-00028S-3C for aaa@optimus.ietf.org; Tue, 13 Apr 2004 15:27:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01258 for ; Tue, 13 Apr 2004 15:27:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDTZS-000086-00 for aaa@ietf.org; Tue, 13 Apr 2004 15:27:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDTY4-00000r-00 for aaa@ietf.org; Tue, 13 Apr 2004 15:26:21 -0400 Received: from p5090dd37.dip.t-dialin.net ([80.144.221.55]) by ietf-mx with smtp (Exim 4.12) id 1BDTWW-0007fh-00 for aaa@ietf.org; Tue, 13 Apr 2004 15:24:46 -0400 Received: from 50.129.105.206 by 80.144.221.55; Wed, 14 Apr 2004 01:24:37 +0500 Message-ID: From: "Pam Lindsay" Reply-To: "Pam Lindsay" To: aaa@ietf.org Date: Wed, 14 Apr 2004 01:23:37 +0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--83386659433471649598" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.9 required=5.0 tests=FORGED_MUA_OIMO, FORGED_OUTLOOK_TAGS,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 2.7 FORGED_MUA_OIMO Forged mail pretending to be from MS Outlook IMO Subject: [Aaa] Your Prescription is Ready.. Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , ----83386659433471649598 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


If the message is n ot loading try this


Jrawlinson serine byron forbid cadaverous adequate extraneous again an= thropomorphism consternate guidebook naomi freya crewman arboreal market e= li nitride prescription boone schulz bestir vis adversary christenson arti= san beardsley lambda brothel=20.Xdelectate coextensive shag squint annihil= ate tool antagonist dihedral analyst arkansas bess filthy woman plutarch c= ompression bonanza berlitz increment pulsate ringside nephew fuchsia=20!Hi= naugurate referendum wi lumen rate jim calgary taffy citadel piccadilly pe= llet chorale conveyance carrel avalanche cloven clothier arrival glassware= elysee racial suppress astronautic born decolletage dick=20;Qchancy wick = rigel locomotive chignon clobber impart lemma excretion hierarchic fletch = spin illusionary cos marcello stopwatch conner scamp velvety act nietzsche= bayreuth stefan tackle toastmaster traverse=20;Satwater croix book denunc= iate phosphorescent collision madmen broody royalty=20.Pgush crab nominate= contradistinct bronco stiffen alumnae inviolable ouzel aide cartography s= partan feedback sidewinder=20;Kcarcinogenic compelling esquire disciple ca= r nondescript decree retinue among facile extravagant mcguire toady=20.Efr= au coquette aversion crisp sagacity conundrum industry psychophysiology=20= ;Hoblige cyanate danny micrography testament chalice celebrant interferenc= e merchant parasitic college saccharine stripy physiotherapy newcastle bou= gh portmanteau vogue defensible allstate=20.Rapocryphal posse armoire ashl= ey remand barrette conformation shield commensurate presume dewar elide de= ficit ingredient deuce blowback simpleminded inept consulate airy pentagra= m dixon ma cannel alphabetic dad bovine lion tour=20?Sshod direct convales= cent gresham arab delimitation cataract croft particular susceptible aggri= eve droplet late carbonium alexandre responsive actinide maximal introject= oceanic awoke=20!Mbologna crankshaft code wild dicotyledon dossier lesson= macho=20.Fambulant cloven iv apposite maverick james lithospheric prepara= tion utensil bland myrtle=20.Ganti cycle myrtle bellman lavabo upheaval co= mpete hodges redstone seton sorption buses dither dealt auspices inflammab= le gar archbishop toffee booty vice metaphoric=20'Lpr wesleyan actor emper= or alfred adiabatic jovial junk davenport=20.Facoustic edwardian frosty br= ownish halifax inarticulate distort bound accordant immeasurable coercion = equipotent enquire arlen downright contiguous valley lab bale desolate bio= tic depict oft mettlesome beachhead grown=20'Equarry royal poverty adolph = giraffe charlottesville comparative order basophilic waybill flung or tigr= ess=20?Bdespotic k's cutset crewel codicil dey cannery bonaparte asunder c= hamp malleable british=20'Bdecibel durkin edna krishna marmot asteroid six= fold half proscription bendix yond arduous apparent mckay chungking commod= ious rival codeposit sima compression australis tarpaper benjamin=20.Uhygr= oscopic denunciation wishful bradbury autocracy verbal champagne swanlike = z montage awkward adieu headmaster gannett flip gadgetry o'connor ramp bri= ttle bert sprague shade pontiac stylus adjourn=20.Peast pretend curate net= tlesome delphinus seed boggy anchovy iceland munch confident strum herself= chevalier washington chungking rosebud metzler burro dune gertrude bay se= veral clayton saddlebag principle blaine hewitt eighty=20.Bleopold mi coup= thompson puffy ineffectual jubilate dime rime scandal severn pacify dogba= ne bowl horace like clumsy fabian function subversive trundle gadfly godli= ke pedigree=20.Lslothful falcon mange newsweek blip anyway crescent cloist= er hondo chiton bullock pope spacecraft sin alvarez hive pleasure alan pro= pitious=20,Ltelefunken buchanan veridic antipodean delirium quicklime depi= ct cringe sahara dactyl lightweight neurology grill thunderous stumble per= spire parolee guesswork credenza bleach resultant rutabaga goldman bumptio= us affirmative epitaph cyanate=20,Gglorious blair contaminant eastward mak= eshift downtrend puncture embalm tousle surtout highland potential aside a= ngiosperm cyclorama chauffeur bangui telethon opec bodybuilding coney alle= ntown adult defraud fluid gibbet methodism=20!Iectopic piddle conjunct rur= al laden toothpaste deadhead oxygenate=20?Gasinine michigan deluxe carne d= ogtooth hypocrite turnpike burnish tenacity archer=20.Fcurse behold ruben = mushy perdition haven electrocardiogram retrogressive actinolite jot romeo= more auditory furze neurosis die citizen augusta=20. Xeclat barracuda beg= etting irwin burnham altern gritty respondent dive cotty syndic chosen tra= nspond boyhood bagging oxcart winsome animadvert accra mimic jovanovich=20= ;Cdocket bond jaeger md inter peacetime confucian wall eighteenth telegram= titular atomic bolo asbestos gaffe ito converge thunderflower bator aceto= ne=20'Teavesdropper anita nashville dee spire procaine instable specious m= embrane product nicaragua conakry banks cytolysis cyrus calibre irreplacea= ble birefringent expectant maternal none exploitation originate=20?Erememb= er dawn homecoming cannibal an confront crowfoot jog dietary resort dreadf= ul voice cornet girlish=20!Cchimera acrimonious amoco weaponry barnyard wh= oever abel crisis minimal repelled alcoholic stafford escape lenny banjo d= onner manuel lipschitz emulate southward blab=20!Ecommunal elsewhere burke= easy minimal supply cessna contradistinction amateur payroll fanfold trib= esman gallantry sulfur sloe bladder historian=20!Sscrewworm rhodium anothe= r destabilize pterodactyl strontium deluge allegoric dapple brake=20;Hvigi= lant hardscrabble arteriolosclerosis fingerprint frangipani sidereal malon= ey shim bulwark delectate paraphrase forlorn leonine immobile rawhide iris= h=20'Nauerbach ticket shah drum beheld honest repairman farthest welsh eng= land fawn depart manipulable monkish bureaucrat bistable fir poisson someb= ody gander middle artful managua puberty stephenson grindstone upheaval sc= henectady=20!Xcockcrow timothy canteen israelite bogey miriam seth surrept= itious belittle airlock besiege asleep frosty antisemitism as brushlike he= reby nostrand pugnacious physiognomy radial tableau tinder formatting gadw= all factorial chirp decelerate bernice drew=20.Zsteen pemmican destructor = nape affricate rate censor codeposit somers xi agnes equanimity peat diagn= osable plop wakeup kidde trichloroacetic=20?Xclassic feint bevy suggestive= bombard tide heart wallaby consolation accentual ceil stomach mesa emilio= chinook vertex well hermetic restaurateur efficient minuteman dar diamagn= etic boxwood initiate=20?Pcomrade bistate mendel cabot antimony sawyer pre= sumed square minneapolis warmth abutting bronze genetic tidbit buxom night= marish speedy slocum subsidiary halt conferrable croquet=20,Imythology pol= ytypy incomparable clean cherry fujitsu consultant aztecan scrawl infernal= fluff mealy cease dilute burp dhabi arterial egotism nolan allot burton b= abysat cattail bluster ternary contravariant edwardine empiric=20,Wincreas= e bought phobic grudge churchgoing beam trailhead awl worksheet crumple am= sterdam smolder worship ramify burp devise=20.Dbantus jeremiah brewery bit= ch death conakry introit schist lemma coronet isaacson ineluctable bribe m= othball camden hathaway psychosis czech privilege moccasin clothbound four= teen propylene aiken ernst lid kangaroo racket=20'Istencil speck angeles g= ypsum allstate proctor dagger acceptant guess flagrant cog vulcan yow whee= lhouse burlington=20?Corleans paleolithic benedict persuade wold architect= chinook skyrocket gaugeable nostalgic cutlet avenge garlic genotype=20.Lm= issive abyssinia rupture fedders penates dukedom serfdom forsook flank lan= thanum scuffle deadline accompaniment miles angstrom bimodal monk peoria=20= ,Pdevour antiquary jeopard seventieth brooke aqueous semaphore explicable=20= Espeedup vibrant chuckwalla iceberg breccia middleman littleton malaysia = jitterbugger matson pvc lemon gresham allotted tenebrous fourth milch pyro= lyse crises kronecker busch chaise deceit r's pollard analysis cowherd dum= pty tannin=20?Afleshy rome indeterminable coalesce trot incumbent tradeoff= gent academic subjectivity athens dully tenon bawl astride triton courtya= rd foist faustus ellsworth perfectible lansing rabies hare basilar eastwar= d cyst wondrous michelson dunce=20.Ynitrous backscatter penumbra testate a= dorn dilogarithm analytic chanson=20.Vlower julio queasy burg nitrogen bud= apest prostitution genius pent children pragmatic lug fault antipasto bere= ave stratosphere application byrd symbiotic dysplasia couturier=20!

----83386659433471649598-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Tue Apr 13 17:29:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10118 for ; Tue, 13 Apr 2004 17:29:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVH5-0005kW-Uc; Tue, 13 Apr 2004 17:16:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDUV0-0001D3-FB for aaa@optimus.ietf.org; Tue, 13 Apr 2004 16:27:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05210 for ; Tue, 13 Apr 2004 16:27:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDUUw-0006Lq-00 for aaa@ietf.org; Tue, 13 Apr 2004 16:27:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDUPV-0005k4-00 for aaa@ietf.org; Tue, 13 Apr 2004 16:21:34 -0400 Received: from ip-24-197-135-162.spa.sc.charter.com ([24.197.135.162]) by ietf-mx with smtp (Exim 4.12) id 1BDUK1-00058m-00 for aaa@ietf.org; Tue, 13 Apr 2004 16:15:53 -0400 Content-Type: text/html; MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: "Hillyer Lenze" To: aaa@ietf.org X-Priority: 3 Date: Wed, 14 Apr 2004 00:12:44 +0300 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.1 required=5.0 tests=FROM_ENDS_IN_NUMS,HTML_40_50, HTML_IMAGE_ONLY_08,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MSGID_FROM_MTA_SHORT,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.8 HTML_IMAGE_ONLY_08 BODY: HTML: images with 600-800 bytes of words * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Content-Transfer-Encoding: quoted-printable Subject: [Aaa] Re: Account Overdue Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable At that moment Commander Farragut was o= rdering the last moorings to be cast loose which held the Abraham Lincoln = to the pier of Brooklyn.=20





If the messag= e is not loading try this













This fact, so grave in itself, might perhaps have been forgotten like many= others if, three weeks after, it had not been re-enacted under similar ci= rcumstances? This passed, the frigate took a more decided westerly directi= on, and scoured the central waters of the Pacific: There, a mile and a hal= f from the frigate, a long blackish body emerged a yard above the waves: W= hat was, then, the mystery of this submarine craft, of which the whole wor= ld vainly sought an explanation? What kind of beings existed in this stran= ge boat? What mechanical agent caused its prodigious speed?!!!=20 theseus _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Tue Apr 13 18:14:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14326 for ; Tue, 13 Apr 2004 18:14:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVtd-0002We-LO for aaa-archive@odin.ietf.org; Tue, 13 Apr 2004 17:56:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DLujQD009704 for aaa-archive@odin.ietf.org; Tue, 13 Apr 2004 17:56:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVkx-0008JQ-Iy for aaa-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 17:47:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11724 for ; Tue, 13 Apr 2004 17:47:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDVku-0006Z1-00 for aaa-web-archive@ietf.org; Tue, 13 Apr 2004 17:47:44 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDVXW-0005JT-00 for aaa-web-archive@ietf.org; Tue, 13 Apr 2004 17:33:54 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDVT4-0003k3-1n for aaa-web-archive@ietf.org; Tue, 13 Apr 2004 17:29:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVH5-0005kW-Uc; Tue, 13 Apr 2004 17:16:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDUV0-0001D3-FB for aaa@optimus.ietf.org; Tue, 13 Apr 2004 16:27:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05210 for ; Tue, 13 Apr 2004 16:27:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDUUw-0006Lq-00 for aaa@ietf.org; Tue, 13 Apr 2004 16:27:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDUPV-0005k4-00 for aaa@ietf.org; Tue, 13 Apr 2004 16:21:34 -0400 Received: from ip-24-197-135-162.spa.sc.charter.com ([24.197.135.162]) by ietf-mx with smtp (Exim 4.12) id 1BDUK1-00058m-00 for aaa@ietf.org; Tue, 13 Apr 2004 16:15:53 -0400 Content-Type: text/html; MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: "Hillyer Lenze" To: aaa@ietf.org X-Priority: 3 Date: Wed, 14 Apr 2004 00:12:44 +0300 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.1 required=5.0 tests=FROM_ENDS_IN_NUMS,HTML_40_50, HTML_IMAGE_ONLY_08,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MSGID_FROM_MTA_SHORT,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.8 HTML_IMAGE_ONLY_08 BODY: HTML: images with 600-800 bytes of words * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Content-Transfer-Encoding: quoted-printable Subject: [Aaa] Re: Account Overdue Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable At that moment Commander Farragut was o= rdering the last moorings to be cast loose which held the Abraham Lincoln = to the pier of Brooklyn.=20





If the messag= e is not loading try this













This fact, so grave in itself, might perhaps have been forgotten like many= others if, three weeks after, it had not been re-enacted under similar ci= rcumstances? This passed, the frigate took a more decided westerly directi= on, and scoured the central waters of the Pacific: There, a mile and a hal= f from the frigate, a long blackish body emerged a yard above the waves: W= hat was, then, the mystery of this submarine craft, of which the whole wor= ld vainly sought an explanation? What kind of beings existed in this stran= ge boat? What mechanical agent caused its prodigious speed?!!!=20 theseus _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Wed Apr 14 02:10:56 2004 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 CAA15033 for ; Wed, 14 Apr 2004 02:10:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BBD48912BF; Wed, 14 Apr 2004 02:10:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8557C912C0; Wed, 14 Apr 2004 02:10:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C2F93912BF for ; Wed, 14 Apr 2004 02:10:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB69C582A2; Wed, 14 Apr 2004 02:10:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id C46C458297 for ; Wed, 14 Apr 2004 02:10:39 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3E6AHH11391; Wed, 14 Apr 2004 09:10:17 +0300 (EET DST) X-Scanned: Wed, 14 Apr 2004 09:09:54 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3E69s2P009904; Wed, 14 Apr 2004 09:09:54 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00Db20oc; Wed, 14 Apr 2004 09:09:53 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3E69ms27273; Wed, 14 Apr 2004 09:09:48 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 14 Apr 2004 09:09:05 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C421E6.FD5696CC" Subject: RE: RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit time Date: Wed, 14 Apr 2004 09:09:04 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C867F@esebe016.ntc.nokia.com> Thread-Topic: RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit time Thread-Index: AcQhfiAkJ6luuUVTTDuOz4jYzcBzhQAaIo7Q From: To: Cc: , X-OriginalArrivalTime: 14 Apr 2004 06:09:05.0582 (UTC) FILETIME=[FDB3A4E0:01C421E6] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C421E6.FD5696CC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chris, =20 it works for me. If others will not object it will be incorporated. =20 Marco -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 13 April, 2004 20:38 To: Stura Marco (Nokia-NET/Helsinki) Cc: aaa-wg@merit.edu; jens.schendel@siemens.com Subject: RE: RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for = unit time Thanks Marco, =20 So the text I proposed (at the end of the email) is OK and will be = incorporated into the document? Cheers,=20 Chris.=20 Shasta Wireless Development=20 Nortel Networks=20 Telephone:=20 +1 972 684 3281=20 ESN 444 3281=20 -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: Tuesday, April 13, 2004 2:53 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; jens.schendel@siemens.com Subject: RE: RE: [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for = unit time Hi Chris, =20 Should we clarify section 5 in addition? As the text stands, it is not = clear that there are basically two types of time based quota. =20 I don't think we have two types of time based quota, rather we have some = environment where time based services may consist of two different models. In particular, data = services may be charged based on connection time where the quota is consumed at regular rate or based on the usage = model where the time quota is=20 consumed only when packets are flowing through. That is why we included = the definition of time based services in section 5. I think your proposed text enhancement to this definition = certainly help to clarify the applicability of the tariff change mechanism with respect to time based services. =20 Regards Marco =20 =20 For time based services where the quota is continuously consumed at = the regular rate of=20 60 seconds per minute, the server already knows at the time when=20 credit resources are allocated how many units will be consumed before = the tariff time change and how many units will be consumed after.=20 Similarly, the server can determine the units consumed at the before=20 rate and the units consumed at the rate afterwards in the event that=20 the end-user closes the session before the consumption of the = allotted=20 quota. There is no need for additional traffic between client and=20 server in case of tariff time changes for the continuous time based = service,=20 therefore the tariff change mechanism is not used for continuous time = based=20 services. For time based services where the quota is NOT continuously = consumed =20 at a regular rate, the tariff change mechanism described for volume = and event units =20 MAY be used.=20 ------_=_NextPart_001_01C421E6.FD5696CC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Chris,
 
it=20 works for me. If others will not object it will be=20 incorporated.
 
Marco
-----Original Message-----
From: ext Christopher = Richards=20 [mailto:crich@nortelnetworks.com]
Sent: 13 April, 2004=20 20:38
To: Stura Marco (Nokia-NET/Helsinki)
Cc:=20 aaa-wg@merit.edu; jens.schendel@siemens.com
Subject: RE: RE: = [AAA-WG]: DCCA Draft 04: Tariff-Time-Change AVP for unit=20 time

Thanks Marco,
 
So=20 the text I proposed (at the end of the email) is OK and will be = incorporated=20 into the document?

Cheers,=20
Chris.

Shasta Wireless=20 Development
Nortel Networks

Telephone:=20
+1 972 684=20 3281
ESN 444=20 3281

-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent:=20 Tuesday, April 13, 2004 2:53 AM
To: Richards, Christopher=20 [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu;=20 jens.schendel@siemens.com
Subject: RE: RE: [AAA-WG]: DCCA = Draft=20 04: Tariff-Time-Change AVP for unit time

Hi=20 Chris,
 
Should we = clarify section 5=20 in addition? As the text stands, it is not clear that there are = basically=20 two types of time based quota.
 
I=20 don't think we have two types of time based quota, rather we = have some=20 environment where time based
services may consist of two different = models. In=20 particular, data services may be charged based on=20 connection
time where the quota is consumed at = regular rate or=20 based on the usage model where the time quota is =
consumed only when packets are flowing = through.=20 That is why we included the definition of time based=20 services
in=20 section 5. I think your proposed text enhancement to this definition = certainly help to clarify the applicability
of=20 the tariff change mechanism with respect to time based=20 services.
 
Regards
Marco
 
 
   For time based services where the = quota is=20 continuously consumed at the regular rate of
   60 seconds per minute, the server already = knows at the=20 time when
   credit resources = are=20 allocated how many units will be consumed before
   the tariff time change and how many units will = be=20 consumed after.
   Similarly, = the server=20 can determine the units consumed at the before
   rate and the units consumed at the rate = afterwards in=20 the event that
   the end-user = closes the=20 session before the consumption of the allotted
   quota.  There is no need for additional = traffic=20 between client and
   server in = case of=20 tariff time changes for the continuous time based service, =
   therefore the tariff change mechanism is not = used for=20 continuous time based
  =20 services. For time based services where = the quota=20 is NOT continuously consumed  
   at a regular=20 rate,  the tariff change mechanism = described for=20 volume and event units  
   MAY be used.=20
------_=_NextPart_001_01C421E6.FD5696CC-- From owner-aaa-wg@merit.edu Wed Apr 14 02:14:39 2004 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 CAA17844 for ; Wed, 14 Apr 2004 02:14:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 39C7D912C0; Wed, 14 Apr 2004 02:14:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 051B3912C2; Wed, 14 Apr 2004 02:14:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 75BC9912C0 for ; Wed, 14 Apr 2004 02:14:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 64E8258318; Wed, 14 Apr 2004 02:14:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 9E1ED58319 for ; Wed, 14 Apr 2004 02:14:23 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3E6ECH17068; Wed, 14 Apr 2004 09:14:12 +0300 (EET DST) X-Scanned: Wed, 14 Apr 2004 09:11:36 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3E6BaFe008193; Wed, 14 Apr 2004 09:11:36 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00nzw7G9; Wed, 14 Apr 2004 09:11:34 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3E6BTF17430; Wed, 14 Apr 2004 09:11:29 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 14 Apr 2004 09:10:48 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Date: Wed, 14 Apr 2004 09:10:49 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C8680@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: Review of Diameter Credit Control -04 Thread-Index: AcQhbCLcLvXi8B0QTwqTK0sK+A7QYQAet+dg From: To: , , , , Cc: , X-OriginalArrivalTime: 14 Apr 2004 06:10:48.0875 (UTC) FILETIME=[3B44E7B0:01C421E7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Avi, > To this end, we could address the base Prepaid interworking=20 > with Diameter CC > in the Prepaid draft. Sounds good. Marco > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Avi Lior > Sent: 13 April, 2004 18:25 > To: 'Harri Hakala (JO/LMF)'; 'David Mitton'; Jari Arkko; Loughney John > (Nokia-NRC/Helsinki) > Cc: aboba@internaut.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 >=20 >=20 >=20 > Just to let you know I am listening to this conversation. >=20 > The one thing I want to avoid in RADIUS prepaid is to add a=20 > lot of features > into the current document that are not really required by=20 > current RADIUS > implementations. >=20 > Instead, my thinking is that RADIUS Prepaid draft will establish the > framework for doing prepaid and extensions can be added later. >=20 > Currently, we have "standard" prepaid support (as done by=20 > 3GPP2) and we were > asked to do one time events. Although I haven't formally seen the > requirements I think I know where they are coming from. >=20 > Tarrif switching which is done in 3GPP2 is not addressed. It could be > addressed in this document or it could be added later. I haven't seen > anyone wanting it in RADIUS -- for example, in WLAN. >=20 > To this end, we could address the base Prepaid interworking=20 > with Diameter CC > in the Prepaid draft. >=20 > Comments? >=20 > Also note, that there could be prepaid features that come from RADIUS > deployements that are not addressed by the Diameter CC application.=20 >=20 >=20 > > -----Original Message----- > > From: Harri Hakala (JO/LMF) [mailto:harri.hakala@ericsson.com]=20 > > Sent: Tuesday, April 13, 2004 2:12 AM > > To: 'David Mitton'; Jari Arkko; john.loughney@nokia.com > > Cc: aboba@internaut.com; aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: Issue: Review of Diameter Credit Control -04 > >=20 > >=20 > > Hi Dave, > >=20 > > I do agree that the guidelines and details in the=20 > > Interworking section are not right balanced. Also some=20 > > important standardization details are=20 > > missing, but it is quite hard to define these details=20 > without having=20 > > a bit more stable target document for translation.=20 > >=20 > > Now when draft-lior-radius-prepaid is also chartered in the=20 > > RADEXT, it=20 > > may be better to move this section to a separate I-D, as=20 > > proposed, instead of keeping this section even as an=20 > > informative appendix. This due to fact that=20 > > the comprehensive interworking description may be rather=20 > > large, depending on, of course, the level of details that=20 > > will be covered. For instance, at=20 > > the moment just translation from very basic session based=20 > > credit control to=20 > > Radius prepaid is covered in the DCC draft. It may be=20 > > feasible to provide=20 > > also the translation of optional features, e.g. one time=20 > > events, graceful=20 > > service termination, tariff switch, credit-control for=20 > > multiple services=20 > > and those ones which will be described in the Radius prepaid=20 > > draft. Handling of failure cases, such as the mapping of=20 > > result codes could be good to cover as well. It should also=20 > > define full-fledged parameter mapping, containing those=20 > > details which are not now specified. > >=20 > > regards........Harri > >=20 > > > -----Original Message----- > > > From: David Mitton [mailto:david@mitton.com] > > > Sent: 8. huhtikuuta 2004 17:26 > > > To: Jari Arkko; john.loughney@nokia.com > > > Cc: Harri Hakala (JO/LMF); aboba@internaut.com; aaa-wg@merit.edu > > > Subject: Re: [AAA-WG]: Issue: Review of Diameter Credit=20 > Control -04 > > >=20 > > >=20 > > > Harri, et.al., > > >=20 > > > I had a similar reaction as Jari, but let me put it > > > in my own words. > > >=20 > > > I'm not sure I understand the utility of the text as it is.=20 > > The text=20 > > > says that it will explain how to do something, and it tries for > > > several pages, but it leaves out a lot of important details. > > > You say it's supposed to be guideline, and I go back and find=20 > > > those words=20 > > > in the document but I forgot them because the section is very=20 > > > declarative. It seems to go much further than guidelines,=20 > > > but you are not=20 > > > trying to standardize this protocol in this document. > > >=20 > > > A guideline could suggest what data elements and transactions > > > are important=20 > > > to translate, but should not proscribe the format (eg=20 > RADIUS VSAs). > > >=20 > > > I can see that writing a true guideline section might be > > > problematic. And=20 > > > if the issues need to be decided, then maybe it's not useful here. > > >=20 > > > If we want to keep this, I think this would be more=20 > > appropriate as an > > > informative appendix, with more words to the effect of it's=20 > > > incompleteness. > > >=20 > > > Dave. > > >=20 > > >=20 > > > On 4/8/2004 03:35 PM +0300, Jari Arkko wrote: > > >=20 > > > >I wonder how useful the translation to an imaginary > > > >protocol is. I agree that the RADEXT RADIUS prepaid > > > >document should be the normative specification for > > > >such translations. > > > > > > > >What would we lose if Section 11 was deleted? Is > > > >there a specific requirement from someone to have > > > >this mapping? If yes, perhaps Section 11 should be > > > >moved to an appendix and contain the explanation > > > >for the needed specific translation, even if the > > > >translation target is just an I-D. > > > > > > > >If no, maybe you should just simplify your document > > > >by leaving Section 11 to RADEXT, have them write it > > > >once they figure what kind of RADIUS prepaid they > > > >will make. > > > > > > > >--Jari > > > > > > > >john.loughney@nokia.com wrote: > > > >>Dave / Bernard, > > > >> > > > >>>The section 11 is meant to be more as a guideline and=20 > not a full > > > >>>solution because no > > > >>>corresponding RADIUS prepaid RFC exists. Anyway, we felt=20 > > > that having an > > > >>>informative section on this was needed. So, basically we > > > tried to write > > > >>>basic principle how to translate some Diameter AVPs and > > > messages to more > > > >>>or less imaginary RADIUS prepaid application, using the > > > RFC 2865 as a > > > >>>base. We are aware of the draft-lior-radius-prepaid > > > >>>but since that work is still in progress the exact=20 > > mapping to this > > > >>>document was not possible. > > > >>> > > > >>>The RFC of Radius prepaid (when available) should define a > > > complete > > > >>>description of protocol translation between Radius prepaid > > > and Diameter > > > >>>credit control, if we follow the principle that the > > > document (Radius, > > > >>>Diameter) that comes last is responsible for defining=20 > > the mapping. > > > >>> > > > >>>The first paragraph in section 11 is intended to highlight > > > this but > > > >>>perhaps some re-wording is > > > >>>needed here. > > > >>> > > > >>>In Annex A, the flow 1 shows the message translation > > > between Radius > > > >>>prepaid and Diameter CC, but > > > >>>the purpose was not to show a full-fledged parameter > > > mapping for the > > > >>>above reasons. > > > >> > > > >>Any response to this? Does this answer the questions? > > > >>John > > > > > > > > > > >=20 > > >=20 > >=20 >=20 From owner-aaa-wg@merit.edu Wed Apr 14 07:30:48 2004 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 HAA17810 for ; Wed, 14 Apr 2004 07:30:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 44706912D8; Wed, 14 Apr 2004 07:30:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B8E3A912D9; Wed, 14 Apr 2004 07:30:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6E73D912D8 for ; Wed, 14 Apr 2004 07:30:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3BD2D582D9; Wed, 14 Apr 2004 07:30:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 28D21582A7 for ; Wed, 14 Apr 2004 07:30:15 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3EBUEH12215 for ; Wed, 14 Apr 2004 14:30:14 +0300 (EET DST) X-Scanned: Wed, 14 Apr 2004 14:28:56 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3EBSuN3001734 for ; Wed, 14 Apr 2004 14:28:56 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00ot1rQE; Wed, 14 Apr 2004 14:28:54 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3EBSsF19179 for ; Wed, 14 Apr 2004 14:28:54 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 14 Apr 2004 14:28:46 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 14 Apr 2004 14:28:46 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Type of Origin-Realm and Destination-Realm Date: Wed, 14 Apr 2004 14:28:46 +0300 Message-ID: <9B95641F3AE80F4C8CD5B288FE8C9631AAAF88@esebe012.ntc.nokia.com> Thread-Topic: Type of Origin-Realm and Destination-Realm Thread-Index: AcQiE6YL5mdp0gZtTR2GCMZXyTEong== From: To: X-OriginalArrivalTime: 14 Apr 2004 11:28:46.0921 (UTC) FILETIME=[A6ABB390:01C42213] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, I just noticed that RFC3588 defines Origin-Realm and Destination-Realm AVPs to be of type DiameterIdentity. In some earlier drafts the type was UTF8String. Why was the change made? RFC3588 says that "DiameterIdentity value is used to uniquely identify a Diameter node". I think this does not fit the concept of "realm" very = well. The rest of the spec seems to assume that one realm can feature several Diameter nodes, which seems logical. Is there an error in RFC3588 regarding this or am I missing something? BR, Mikko From aaa-admin@ietf.org Wed Apr 14 15:37:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18620 for ; Wed, 14 Apr 2004 15:37:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDq69-00033R-Tg; Wed, 14 Apr 2004 15:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDq2y-0002T3-KS for aaa@optimus.ietf.org; Wed, 14 Apr 2004 15:27:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17997 for ; Wed, 14 Apr 2004 15:27:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDq2x-0002FD-00 for aaa@ietf.org; Wed, 14 Apr 2004 15:27:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDq28-0002CE-00 for aaa@ietf.org; Wed, 14 Apr 2004 15:26:52 -0400 Received: from [132.151.15.110] (helo=foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDq1N-00027y-00 for aaa@ietf.org; Wed, 14 Apr 2004 15:26:05 -0400 Received: from [10.27.5.114] (helo=[10.27.5.114]) by foretec.com with esmtp (Exim 4.30) id 1BDpzk-0000HN-I2 for aaa@ietf.org; Wed, 14 Apr 2004 15:24:24 -0400 From: Brett Thorson To: aaa@ietf.org Content-Type: text/plain Message-Id: <1081970764.5533.30.camel@thor.cnri.reston.va.us> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 14 Apr 2004 15:26:04 -0400 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,LINES_OF_YELLING, SUBJ_ALL_CAPS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Aaa] MAILING LIST TO CLOSE Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit At the request of Mr. Aboba, this list will be terminated. As indicated it is now housed offsite of IETF systems. This means that the IETF will only keep text messages of this working group from here on. The web archives @ ietf will remain for this group, but will not be updated. --Brett >From: Bernard Aboba >To: iesg-secretary@ietf.org >Subject: Turning off aaa@ietf.org The aaa@ietf.org mailing list is not being used, and is collecting a considerable about of spam. I'd like to request that the list be discontinued. Note that this does not affect the AAA WG mailing list, which is hosted at Merit, and feeds the IETF AAA archive. _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Wed Apr 14 16:52:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25067 for ; Wed, 14 Apr 2004 16:52:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDqHh-0000sO-KA for aaa-archive@odin.ietf.org; Wed, 14 Apr 2004 15:42:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EJgvHC003339 for aaa-archive@odin.ietf.org; Wed, 14 Apr 2004 15:42:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDqDj-0005F0-3i for aaa-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 15:38:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18765 for ; Wed, 14 Apr 2004 15:38:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDqDh-0002tq-00 for aaa-web-archive@ietf.org; Wed, 14 Apr 2004 15:38:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDqCp-0002ok-00 for aaa-web-archive@ietf.org; Wed, 14 Apr 2004 15:37:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDqC7-0002k4-00 for aaa-web-archive@ietf.org; Wed, 14 Apr 2004 15:37:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDq69-00033R-Tg; Wed, 14 Apr 2004 15:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDq2y-0002T3-KS for aaa@optimus.ietf.org; Wed, 14 Apr 2004 15:27:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17997 for ; Wed, 14 Apr 2004 15:27:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDq2x-0002FD-00 for aaa@ietf.org; Wed, 14 Apr 2004 15:27:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDq28-0002CE-00 for aaa@ietf.org; Wed, 14 Apr 2004 15:26:52 -0400 Received: from [132.151.15.110] (helo=foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDq1N-00027y-00 for aaa@ietf.org; Wed, 14 Apr 2004 15:26:05 -0400 Received: from [10.27.5.114] (helo=[10.27.5.114]) by foretec.com with esmtp (Exim 4.30) id 1BDpzk-0000HN-I2 for aaa@ietf.org; Wed, 14 Apr 2004 15:24:24 -0400 From: Brett Thorson To: aaa@ietf.org Content-Type: text/plain Message-Id: <1081970764.5533.30.camel@thor.cnri.reston.va.us> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 14 Apr 2004 15:26:04 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Aaa] MAILING LIST TO CLOSE Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit At the request of Mr. Aboba, this list will be terminated. As indicated it is now housed offsite of IETF systems. This means that the IETF will only keep text messages of this working group from here on. The web archives @ ietf will remain for this group, but will not be updated. --Brett >From: Bernard Aboba >To: iesg-secretary@ietf.org >Subject: Turning off aaa@ietf.org The aaa@ietf.org mailing list is not being used, and is collecting a considerable about of spam. I'd like to request that the list be discontinued. Note that this does not affect the AAA WG mailing list, which is hosted at Merit, and feeds the IETF AAA archive. _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Thu Apr 15 02:35:13 2004 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 CAA05094 for ; Thu, 15 Apr 2004 02:35:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ABC6591307; Thu, 15 Apr 2004 02:34:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D1059130B; Thu, 15 Apr 2004 02:34:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 694B591307 for ; Thu, 15 Apr 2004 02:34:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 33CC858377; Thu, 15 Apr 2004 02:34:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id A128D58357 for ; Thu, 15 Apr 2004 02:34:57 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id C9DB98981D; Thu, 15 Apr 2004 09:34:50 +0300 (EEST) Message-ID: <407E2C54.9040705@kolumbus.fi> Date: Thu, 15 Apr 2004 09:31:48 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: "David Mariblanca (ML/EEM)" , Hannes Tschofenig , aaa-wg@merit.edu Subject: Re: [AAA-WG]: use of EAP over IKEv2 References: <1AB3D30B989BF141BBD5C70057B2EF7C0476A7C9@eestqnt105.es.eu.ericsson.se> <407290D0.10009@kolumbus.fi> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>I'm reading the RFCs and drafts some more... by setting the >>Tunnel-Type AVP to value 9 (ESP) you could indicate that >>the authentication request relates to an IPsec gateway. > > > According to RFC 2868, Tunnel-Type can be included in an Access-Request. > NAS-Port-Type could be set to Virtual (5). Tunnel-Type could be set to > IPsec ESP Tunnel Mode (9). The only thing that is missing is the > key management - IKEv2 vs. IKEv1 with say, XAUTH. Hmm... maybe that's not all. What if you run IKEv2 using EAP authentication but create a transport mode ESP instead of tunnel mode? Of course we could add a new value for the Tunnel-Type AVP, but it may be a stretch to use tunnel AVPs for transport mode IPsec. (Also, I'm trying to think if there's some case where the tunnel attributes would be needed for multiple purposes at the same time. How do we distinguish the "I support tunnel type X" hint from "This connection arrived on tunnel type X" in an Access-Request?) I'm starting to think that we may need a new attribute for indicating the encapsulation that was used for the EAP authentication. Say, EAP-Lower-Layer AVP, with the following values: - PPP - 802.1X - IKEv2 - PANA This could be defined in a small new RFC at the same time for RADIUS & Diameter. What do folks think about this? --Jari From owner-aaa-wg@merit.edu Fri Apr 16 07:06:34 2004 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 HAA00378 for ; Fri, 16 Apr 2004 07:06:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1489E9122D; Fri, 16 Apr 2004 07:06:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA98B9122F; Fri, 16 Apr 2004 07:06:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ADDED9122D for ; Fri, 16 Apr 2004 07:06:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9467B584F8; Fri, 16 Apr 2004 07:06:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 883BD58434 for ; Fri, 16 Apr 2004 07:06:16 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3GB69H01202 for ; Fri, 16 Apr 2004 14:06:09 +0300 (EET DST) X-Scanned: Fri, 16 Apr 2004 14:03:31 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3GB3VIh002459 for ; Fri, 16 Apr 2004 14:03:31 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00ZEMY1J; Fri, 16 Apr 2004 14:03:29 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3GB3NF21368 for ; Fri, 16 Apr 2004 14:03:23 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 16 Apr 2004 14:01:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Type of Origin-Realm and Destination-Realm Date: Fri, 16 Apr 2004 14:01:07 +0300 Message-ID: Thread-Topic: Type of Origin-Realm and Destination-Realm Thread-Index: AcQiE6YL5mdp0gZtTR2GCMZXyTEongBjkRCg From: To: , X-OriginalArrivalTime: 16 Apr 2004 11:01:06.0808 (UTC) FILETIME=[1DFE0F80:01C423A2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Mikko, > I just noticed that RFC3588 defines Origin-Realm and Destination-Realm > AVPs to be of type DiameterIdentity. In some earlier drafts the type = was > UTF8String. Why was the change made? >=20 > RFC3588 says that "DiameterIdentity value is used to uniquely identify > a Diameter node". I think this does not fit the concept of "realm" = very well. > The rest of the spec seems to assume that one realm can feature = several > Diameter nodes, which seems logical. >=20 > Is there an error in RFC3588 regarding this or am I missing something? Essentially, the DiameterIdentity refers to a FQDN, which should be = acceptable for use as the realm. Do you see any problems with this? John From owner-aaa-wg@merit.edu Sat Apr 17 13:51:54 2004 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 NAA20647 for ; Sat, 17 Apr 2004 13:51:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B938D91246; Sat, 17 Apr 2004 13:51:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8AF0091247; Sat, 17 Apr 2004 13:51:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7D6FB91246 for ; Sat, 17 Apr 2004 13:51:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 64639587E7; Sat, 17 Apr 2004 13:51:35 -0400 (EDT) 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 DCD7D58564 for ; Sat, 17 Apr 2004 13:51:34 -0400 (EDT) Received: from zrc2c010.us.nortel.com (zrc2c010.us.nortel.com [47.103.120.50]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3HHpP829947; Sat, 17 Apr 2004 12:51:25 -0500 (CDT) Received: from zrc2c012.us.nortel.com ([47.103.120.52]) by zrc2c010.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JC3C0DRB; Sat, 17 Apr 2004 12:51:25 -0500 Received: from nortelnetworks.com (BLUETICK [47.102.196.134]) by zrc2c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2275W4HF; Sat, 17 Apr 2004 12:51:25 -0500 Message-ID: <40816E89.5040904@nortelnetworks.com> Date: Sat, 17 Apr 2004 17:51:05 +0000 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Joe Harvell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: [AAA-WG]: fqdn References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010709060101060707010000" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------010709060101060707010000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John: On a related topic, I have a question about the format of an FQDN. I remember reading somewhere that all FQDNs end in a '.' character (having something to with all TLDs being children of the real top-level doamain with an empty label). I know that DNS resolving libraries treat doman names ending in '.' as fully-qualified in that they don't attempt to append default domain suffixes when resolving. Where can I find the syntax for the FQDN used in 3588? john.loughney@nokia.com wrote: >Hi Mikko, > > > >>I just noticed that RFC3588 defines Origin-Realm and Destination-Realm >>AVPs to be of type DiameterIdentity. In some earlier drafts the type was >>UTF8String. Why was the change made? >> >>RFC3588 says that "DiameterIdentity value is used to uniquely identify >>a Diameter node". I think this does not fit the concept of "realm" very well. >>The rest of the spec seems to assume that one realm can feature several >>Diameter nodes, which seems logical. >> >>Is there an error in RFC3588 regarding this or am I missing something? >> >> > >Essentially, the DiameterIdentity refers to a FQDN, which should be acceptable >for use as the realm. Do you see any problems with this? > >John > > --------------010709060101060707010000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit John:

On a related topic, I have a question about the format of an FQDN.  I remember reading somewhere that all FQDNs end in a '.' character (having something to with all TLDs being children of  the real top-level doamain with an empty label).  I know that DNS resolving libraries treat doman names ending in '.' as fully-qualified in that they don't attempt to append default domain suffixes when resolving.

Where can I find the syntax for the FQDN used in 3588?

john.loughney@nokia.com wrote:
Hi Mikko,

  
I just noticed that RFC3588 defines Origin-Realm and Destination-Realm
AVPs to be of type DiameterIdentity. In some earlier drafts the type was
UTF8String. Why was the change made?

RFC3588 says that "DiameterIdentity value is used to uniquely identify
a Diameter node". I think this does not fit the concept of "realm" very well.
The rest of the spec seems to assume that one realm can feature several
Diameter nodes, which seems logical.

Is there an error in RFC3588 regarding this or am I missing something?
    

Essentially, the DiameterIdentity refers to a FQDN, which should be acceptable
for use as the realm.  Do you see any problems with this?

John
--------------010709060101060707010000-- From owner-aaa-wg@merit.edu Mon Apr 19 15:28:05 2004 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 PAA04007 for ; Mon, 19 Apr 2004 15:28:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1F69A912AE; Mon, 19 Apr 2004 15:27:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC846912AF; Mon, 19 Apr 2004 15:27:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C68A3912AE for ; Mon, 19 Apr 2004 15:27:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B601858855; Mon, 19 Apr 2004 15:27:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id DBCC5587DB for ; Mon, 19 Apr 2004 15:27:34 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i3JJXX704828 for ; Mon, 19 Apr 2004 12:33:34 -0700 Date: Mon, 19 Apr 2004 12:33:33 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Wrapping up NASREQ... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk David Mitton has put up a strawman version of the NASREQ-15 here for examination: http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-15.txt This version is designed to close all open issues (see below). Since NASREQ has already gone through WG last call, IETF last call, IESG review and approval for publication as a Proposed Standard, this represents the very last opportunity to comment on it before it is done. So... speak now or forever (until NASREQbis) hold your piece. ----------------------------------------------------------------------- Generic Edits in D15: - Update document dates & version - Update David Spence info - Fix Acct-Session-ID in ABNFs - Remove table entry for Termination-Action - Add reference to Base Termination-Cause - Re-add missing code points for NAS-Port-Type - correct header levels for LAT services - Tunnel-Client-Auth-ID, Tunnel-Server-Auth-ID defined as UTF8Strings (Was Unsigned32 in table, OctetString in description) - Pg 60, Sect 9.1, Session-Timeout: Remove phrase "I guess the safest bet is to" ---------- Issues: Issue 431 - Identities in RADIUS Translation, Pasi Eronen 1&2) State attribute should contain: "Diameter/""/""/" 3) State content building should be consistent 4) Fix section 9.3 for Origin-Host to identify NAS source, not gateway 5) Corrected. 6) Origin-Realm & Origin-Host AVP should contain best verified info on NAS identity (not the gateway) Issue 451 - Interim vs. STOP Record, Avi Lior a) Compromise - add text to allow Stop/Start as service specific b) Editorial correction Accepted Issue 452 - Accounting Session-Id in ACA Command, Avi Lior Accepted: Corrected AVP name Issue 453 - Problem with Accounting Session-Id and Session-Id, Avi Lior Accepted: Acct-Session-Id cannot be put in Diam Session-Id Acct-Session-Id is an accepted Diameter AVP. A RADIUS/Diameter gateway will have to assign & track Diameter Session-Ids. Issue 454 - Diameter NASREQ conflict with Base, Bernard Aboba Close: Text already changed in draft 14 Issue 457 - Editorial NIT in NASREQ-14, Johan Hermans Accepted: Updated Service-Type list Issue 462 - Typo in NASREQ-14, Ignacio Goyret Accepted: Tunnel-Client-Auth-Id type bug From owner-aaa-wg@merit.edu Mon Apr 19 15:52:47 2004 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 PAA05692 for ; Mon, 19 Apr 2004 15:52:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3EA72912C9; Mon, 19 Apr 2004 15:49:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB4E4912C1; Mon, 19 Apr 2004 15:49:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 57F08912C1 for ; Mon, 19 Apr 2004 15:46:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 23E32583D4; Mon, 19 Apr 2004 15:46:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 95BF1583A3 for ; Mon, 19 Apr 2004 15:46:25 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i3JJqP405944 for ; Mon, 19 Apr 2004 12:52:25 -0700 Date: Mon, 19 Apr 2004 12:52:24 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Wrapping up Mobile IPv4 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk An updated Diameter Mobile IPv4 draft is now available here: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-17.txt The companion AAA-Keys draft is available here: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-17.txt Since Diameter Mobile IPv4 application has already been through WG last call, IETF last call, and IESG review, and is pending IESG re-review, we are nearing the end of the journey. So if you have any comments, please speak up now. From owner-aaa-wg@merit.edu Mon Apr 19 20:03:36 2004 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 UAA22565 for ; Mon, 19 Apr 2004 20:03:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6B3E59120A; Mon, 19 Apr 2004 20:03:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F3319120D; Mon, 19 Apr 2004 20:03:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4948E9120A for ; Mon, 19 Apr 2004 20:03:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 331FA58332; Mon, 19 Apr 2004 20:03:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id DEFA7587AA for ; Mon, 19 Apr 2004 20:03:15 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i3K09DJ21062 for ; Mon, 19 Apr 2004 17:09:13 -0700 Date: Mon, 19 Apr 2004 17:09:13 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] Applicability of NASREQ to vanilla IP access Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Joel M. Halpern Submitter email address: joel@stevecrocker.com Date first submitted: 19-March-2004 Reference: n/a Document: nasreq-15 Comment type: T Priority: 1 Section 6.10 Rationale/Explanation of issue: The text restricts the use of the 6.10 AVPs unnecessarily and therefore interferes with the extensibility of 6.9.1 The second sentence of section 6.10 reads: "They are only present if the Framed-Protocol AVP (see Section 6.9.1) is set to PPP, SLIP, Gandalf proprietary SingleLink/MultiLink protocol, or X.75 Synchronous." The use of the word "only" leads the reader to believe that these IP Access Authorization AVPs (which are needed whenever the user is to use IP) may only be used with these specific framed protocols. For example, they would be prohibited in conjunction with a framed protocol of GPRS PDP Context, or any other new values that are defined. In fact, this sentence does not appear to enhance interoperability or clarity. Requested Change: Remove the second sentence of 6.10. From owner-aaa-wg@merit.edu Tue Apr 20 04:23:36 2004 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 EAA01177 for ; Tue, 20 Apr 2004 04:23:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 66822912CD; Tue, 20 Apr 2004 04:23:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39FC3912CE; Tue, 20 Apr 2004 04:23:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 21FF2912CD for ; Tue, 20 Apr 2004 04:23:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0CEBB58887; Tue, 20 Apr 2004 04:23:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 92E565883E for ; Tue, 20 Apr 2004 04:23:21 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 500658981B; Tue, 20 Apr 2004 11:22:55 +0300 (EEST) Message-ID: <4084DD26.2060800@kolumbus.fi> Date: Tue, 20 Apr 2004 11:19:50 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Applicability of NASREQ to vanilla IP access 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: > Submitter name: Joel M. Halpern > Submitter email address: joel@stevecrocker.com > Date first submitted: 19-March-2004 > Reference: n/a > Document: nasreq-15 > Comment type: T > Priority: 1 > Section 6.10 > Rationale/Explanation of issue: > > The text restricts the use of the 6.10 AVPs unnecessarily and > therefore interferes with the extensibility of 6.9.1 > > The second sentence of section 6.10 reads: > "They are only present if the Framed-Protocol AVP (see Section 6.9.1) > is set to PPP, SLIP, Gandalf proprietary SingleLink/MultiLink protocol, > or X.75 Synchronous." > > The use of the word "only" leads the reader to believe that these > IP Access Authorization AVPs (which are needed whenever the user > is to use IP) may only be used with these specific framed protocols. > For example, they would be prohibited in conjunction with a framed > protocol of GPRS PDP Context, or any other new values that are defined. > In fact, this sentence does not appear to enhance interoperability or > clarity. > > Requested Change: > > Remove the second sentence of 6.10. Agreed. --Jari From owner-aaa-wg@merit.edu Tue Apr 20 06:27:24 2004 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 GAA06796 for ; Tue, 20 Apr 2004 06:27:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 43F65912CE; Tue, 20 Apr 2004 06:27:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B2B4912D2; Tue, 20 Apr 2004 06:27:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D9352912CE for ; Tue, 20 Apr 2004 06:27:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B867A58914; Tue, 20 Apr 2004 06:27:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smail.alcatel.fr (smail.alcatel.fr [62.23.212.165]) by segue.merit.edu (Postfix) with ESMTP id E057D588DE for ; Tue, 20 Apr 2004 06:27:09 -0400 (EDT) Received: from bemail03.netfr.alcatel.fr (bemail03.netfr.alcatel.fr [155.132.251.37]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3KAR5QP022624 for ; Tue, 20 Apr 2004 12:27:05 +0200 Received: from alcatel.be ([138.203.209.132]) by bemail03.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004042012270308:2646 ; Tue, 20 Apr 2004 12:27:03 +0200 Message-ID: <4084FAF6.3030203@alcatel.be> Date: Tue, 20 Apr 2004 12:27:02 +0200 From: johan.rh.hermans@alcatel.be Organization: Alcatel Belgium User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: meaning of PXY in the ABNF (P-bit) X-MIMETrack: Itemize by SMTP Server on BEMAIL03/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/20/2004 12:27:03, Serialize by Router on BEMAIL03/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/20/2004 12:27:04, Serialize complete at 04/20/2004 12:27:04 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Most Diameter commands contain the PXY-keyword in the ABNF spec, meaning "if present, the 'P' bit in the Command Flags is set, indicating that the message is proxiable". But does this mean that the P-bit is required in every occurence of this command-code ? What if we take a command that is normally proxiable, but doesn't carries the P-bit. I guess that most Diameter implementations will try to process it locally (if it succeeds depends on the Destination-Realm and/or Destination-Host ofcourse). But if a Diameter implementation is particular pedantic, and knows from the ABNF (or the XML-definition) that the P-bit should be present, it might send an error back with the DIAMETER_INVALID_HDR_BITS result-code. Which would be correct ? In my opinion, we should be able to clear out out the P-bit from a command that is normally proxiable, when we want to insist that a request should stay local. Ofcourse, the sender would still be responsible for correct Destination-Realm and/or Destination-Host values, to be sure that it would be really possible to process it locally, otherwise it would get a DIAMETER_UNABLE_TO_DELIVER back. -- Jo Hermans From owner-aaa-wg@merit.edu Tue Apr 20 09:30:07 2004 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 JAA16788 for ; Tue, 20 Apr 2004 09:30:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 664EC912D5; Tue, 20 Apr 2004 09:29:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39B16912D6; Tue, 20 Apr 2004 09:29:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 27F33912D5 for ; Tue, 20 Apr 2004 09:29:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0BB6358900; Tue, 20 Apr 2004 09:29:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 698D158428 for ; Tue, 20 Apr 2004 09:29:48 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 50FD889818; Tue, 20 Apr 2004 16:29:47 +0300 (EEST) Message-ID: <40852511.20508@kolumbus.fi> Date: Tue, 20 Apr 2004 16:26:41 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter EAP -05 References: <052E0C61B69C3741AFA5FE88ACC775A6010C3A25@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C3A25@esebe023.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 Pasi.Eronen@nokia.com wrote: > Jari Arkko wrote: > >>How about this to the end of 2.8.5: >> >>"A disadvantage of this approach is that it becomes harder >>to support so called EAP channel bindings described in >>Section 7.15 of [RFC2284bis]. The reason for this is that >>entity performing the EAP authentication needs to be aware >>of all authorization data related to the session. It is >>therefore RECOMMENDED that the backend authentication >>server both accepts incoming authorization AVPs as well as >>returns authorization AVPs. (How the backend server finds >>out which authorization AVPs to return is outside the >>scope of this specification.)" >> >>Another approach would be to delete the whole section. > > > Hmm... with this addition, the situation is not that > different from having a Diameter proxy agent that > does some authorization parts. And that case is > already covered elsewhere. > > I'd suggest that we delete the whole section 2.8.5; > any other opinions about this? I'm fine with that. Comments from anyone else? --Jari From owner-aaa-wg@merit.edu Tue Apr 20 09:56:26 2004 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 JAA18182 for ; Tue, 20 Apr 2004 09:56:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6CC58912D6; Tue, 20 Apr 2004 09:56:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C2FA912D7; Tue, 20 Apr 2004 09:56:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 18088912D6 for ; Tue, 20 Apr 2004 09:56:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EF87858937; Tue, 20 Apr 2004 09:56:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id F13895893E for ; Tue, 20 Apr 2004 09:56:10 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KDu9m10635 for ; Tue, 20 Apr 2004 16:56:09 +0300 (EET DST) X-Scanned: Tue, 20 Apr 2004 16:55:26 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3KDtQE5023352 for ; Tue, 20 Apr 2004 16:55:26 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00zbf4L6; Tue, 20 Apr 2004 16:55:25 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KDt8s16239 for ; Tue, 20 Apr 2004 16:55:08 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 20 Apr 2004 16:51:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Diameter EAP -05 Date: Tue, 20 Apr 2004 16:51:54 +0300 Message-ID: Thread-Topic: [AAA-WG]: Diameter EAP -05 Thread-Index: AcQm3ASS67HVmV27R6OTe0s9bFHGGAAApW6g From: To: , Cc: X-OriginalArrivalTime: 20 Apr 2004 13:51:56.0007 (UTC) FILETIME=[A4A4B770:01C426DE] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > Pasi.Eronen@nokia.com wrote: > > Jari Arkko wrote: > >=20 > >>How about this to the end of 2.8.5: > >> > >>"A disadvantage of this approach is that it becomes harder > >>to support so called EAP channel bindings described in > >>Section 7.15 of [RFC2284bis]. The reason for this is that > >>entity performing the EAP authentication needs to be aware > >>of all authorization data related to the session. It is > >>therefore RECOMMENDED that the backend authentication > >>server both accepts incoming authorization AVPs as well as > >>returns authorization AVPs. (How the backend server finds > >>out which authorization AVPs to return is outside the > >>scope of this specification.)" > >> > >>Another approach would be to delete the whole section. > >=20 > >=20 > > Hmm... with this addition, the situation is not that=20 > > different from having a Diameter proxy agent that > > does some authorization parts. And that case is > > already covered elsewhere. > >=20 > > I'd suggest that we delete the whole section 2.8.5; > > any other opinions about this? >=20 > I'm fine with that. Comments from anyone else? I'm fine with it as well. John From owner-aaa-wg@merit.edu Tue Apr 20 10:07:28 2004 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 KAA19559 for ; Tue, 20 Apr 2004 10:07:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5B20D912D7; Tue, 20 Apr 2004 10:07:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A9A9912D9; Tue, 20 Apr 2004 10:07:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 22D92912D7 for ; Tue, 20 Apr 2004 10:07:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E2B35892B; Tue, 20 Apr 2004 10:07:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h002.c000.snv.cp.net [209.228.32.66]) by segue.merit.edu (Postfix) with SMTP id 648E658928 for ; Tue, 20 Apr 2004 10:07:14 -0400 (EDT) Received: (cpmta 19990 invoked from network); 20 Apr 2004 07:07:13 -0700 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.66) with SMTP; 20 Apr 2004 07:07:13 -0700 X-Sent: 20 Apr 2004 14:07:13 GMT Message-Id: <5.2.1.1.2.20040420095344.042d9da0@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 20 Apr 2004 10:01:33 -0400 To: aaa-wg@merit.edu From: David Mitton Subject: Re: [AAA-WG]: [Issue] Applicability of NASREQ to vanilla IP access In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk On 4/19/2004 05:09 PM -0700, Bernard Aboba wrote: >Submitter name: Joel M. Halpern >Submitter email address: joel@stevecrocker.com >Date first submitted: 19-March-2004 >Reference: n/a >Document: nasreq-15 >Comment type: T >Priority: 1 >Section 6.10 >Rationale/Explanation of issue: > >The text restricts the use of the 6.10 AVPs unnecessarily and >therefore interferes with the extensibility of 6.9.1 > >The second sentence of section 6.10 reads: >"They are only present if the Framed-Protocol AVP (see Section 6.9.1) >is set to PPP, SLIP, Gandalf proprietary SingleLink/MultiLink protocol, >or X.75 Synchronous." > >The use of the word "only" leads the reader to believe that these >IP Access Authorization AVPs (which are needed whenever the user >is to use IP) may only be used with these specific framed protocols. >For example, they would be prohibited in conjunction with a framed >protocol of GPRS PDP Context, or any other new values that are defined. >In fact, this sentence does not appear to enhance interoperability or >clarity. > >Requested Change: > >Remove the second sentence of 6.10. The enumeration has been removed. The prior sentence has been changed to: The AVPs defined in this section are used when the user requests, or is being granted, access service to IP. Similar changes have been made in the IPX and ARAP sections. It may be noted that I was unable to find corresponding restrictive text in RFC 2865 [RADIUS]. Dave. From owner-aaa-wg@merit.edu Tue Apr 20 10:42:11 2004 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 KAA22537 for ; Tue, 20 Apr 2004 10:42:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0F3FA912EC; Tue, 20 Apr 2004 10:41:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B647C912E8; Tue, 20 Apr 2004 10:41:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 74EEB912EC for ; Tue, 20 Apr 2004 10:41:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 602BB5893E; Tue, 20 Apr 2004 10:41:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smail.alcatel.fr (smail.alcatel.fr [62.23.212.165]) by segue.merit.edu (Postfix) with ESMTP id 822D65893D for ; Tue, 20 Apr 2004 10:41:31 -0400 (EDT) Received: from bemail03.netfr.alcatel.fr (bemail03.netfr.alcatel.fr [155.132.251.37]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3KEfGQP020747; Tue, 20 Apr 2004 16:41:16 +0200 Received: from alcatel.be ([138.203.209.132]) by bemail03.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004042016411460:4364 ; Tue, 20 Apr 2004 16:41:14 +0200 Message-ID: <40853688.4030506@alcatel.be> Date: Tue, 20 Apr 2004 16:41:12 +0200 From: johan.rh.hermans@alcatel.be Organization: Alcatel Belgium User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Wrapping up NASREQ... References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL03/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/20/2004 16:41:14, Serialize by Router on BEMAIL03/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/20/2004 16:41:16, Serialize complete at 04/20/2004 16:41:16 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >David Mitton has put up a strawman version of the NASREQ-15 here for >examination: > >http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-15.txt > >This version is designed to close all open issues (see below). > >Since NASREQ has already gone through WG last call, IETF last call, IESG >review and approval for publication as a Proposed Standard, this >represents the very last opportunity to comment on it before it is done. > >So... speak now or forever (until NASREQbis) hold your piece. > > > paragraph 9.2 (Diameter Request Forwarded as RADIUS Request) : "The Session-Id information XYXXY to a Acct-Session-Id AVP." eh ? Is this a mistake made during issue 453 ? -- Jo Hermans From owner-aaa-wg@merit.edu Tue Apr 20 12:08:19 2004 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 MAA29672 for ; Tue, 20 Apr 2004 12:08:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 044F1912E4; Tue, 20 Apr 2004 12:04:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9DF9F912E5; Tue, 20 Apr 2004 12:04:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7C699912E4 for ; Tue, 20 Apr 2004 12:01:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 67EB158344; Tue, 20 Apr 2004 12:01:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h020.c000.snv.cp.net [209.228.32.84]) by segue.merit.edu (Postfix) with SMTP id 4C715588F9 for ; Tue, 20 Apr 2004 12:01:50 -0400 (EDT) Received: (cpmta 18778 invoked from network); 20 Apr 2004 09:01:48 -0700 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.84) with SMTP; 20 Apr 2004 09:01:48 -0700 X-Sent: 20 Apr 2004 16:01:48 GMT Message-Id: <5.2.1.1.2.20040420115628.0413ca40@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 20 Apr 2004 11:56:31 -0400 To: aaa-wg@merit.edu From: David Mitton Subject: Re: [AAA-WG]: Wrapping up NASREQ... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk On 4/20/2004 04:41 PM +0200, johan.rh.hermans@alcatel.be wrote: >Bernard Aboba wrote: > >>David Mitton has put up a strawman version of the NASREQ-15 here for >>examination: >> >>http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-15.txt >> >>This version is designed to close all open issues (see below). >> >>Since NASREQ has already gone through WG last call, IETF last call, IESG >>review and approval for publication as a Proposed Standard, this >>represents the very last opportunity to comment on it before it is done. >> >>So... speak now or forever (until NASREQbis) hold your piece. >> >> >paragraph 9.2 (Diameter Request Forwarded as RADIUS Request) : > >"The Session-Id information XYXXY to a Acct-Session-Id AVP." > >eh ? Is this a mistake made during issue 453 ? > >-- >Jo Hermans Ahyup... A marker for an edit I forgot to finish when I was interrupted. Hard to find your way back when you mispell "XYZZY". I've updated the document to address this, and the other issue on the list today. Dave. From owner-aaa-wg@merit.edu Tue Apr 20 12:30:35 2004 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 MAA01372 for ; Tue, 20 Apr 2004 12:30:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2C68491212; Tue, 20 Apr 2004 12:30:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD644912E0; Tue, 20 Apr 2004 12:30:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6BD9491212 for ; Tue, 20 Apr 2004 12:30:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 37D505887D; Tue, 20 Apr 2004 12:30:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 5223858816 for ; Tue, 20 Apr 2004 12:30:09 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Tue, 20 Apr 2004 12:30:03 -0400 Message-ID: From: Avi Lior To: "'Bernard Aboba'" , "'David Mitton'" , aaa-wg@merit.edu Subject: [AAA-WG]: Wrapping up NASREQ Re-auth Date: Tue, 20 Apr 2004 12:30:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk A couple of things: If the RAR properly identifies an active session, the NAS will initiate a new local reauthentication or authorization sequence as indicated by the Re-Auth-Request-Type value. This will cause the NAS to send a new AAR message using the existing Session-Id. The server will respond with an AAA message to specify the new service parameters. Shouldn't we state that the AUTH-REQUEST-TYPE AVP of the AAR message be set to the same value Received in RAR Re-Auth-Request-Type AVP? And what happens if its not? I am still having an issue with the following paragraph: If accounting is active, every change of authentication or authorization MUST generate an accounting message. Either an Accounting-Record-Type of INTERIM_RECORD indicating the new session attributes and cumulative status (preferred) or two messages of the types STOP_RECORD, and START_RECORD. The later would be for service specific compatibility with some RADIUS services. Why is the Interim preferred? Preferred seems to be an editorial comment. Should we not specify when this is to be used? Also, would not Diameter suffer from the same issue that a RADIUS server would suffer? Would a backend process know why the Interim record is generated. Would it always know what has changed? Would it be able to do the calculation to generate an appropriate bill? Also, if new attributes are received, this is a new session right? Don't we have to use something other then Interim records to deliniate a new session in diameter? Also, how would you (in a scalable way) specify which method is to be used: Interim or Stop/Start records? > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Monday, April 19, 2004 3:34 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Wrapping up NASREQ... > > > David Mitton has put up a strawman version of the NASREQ-15 here for > examination: > > http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-15.txt > > This version is designed to close all open issues (see below). > > Since NASREQ has already gone through WG last call, IETF last > call, IESG review and approval for publication as a Proposed > Standard, this represents the very last opportunity to > comment on it before it is done. > > So... speak now or forever (until NASREQbis) hold your piece. > > > -------------------------------------------------------------- > --------- > Generic Edits in D15: > - Update document dates & version > - Update David Spence info > - Fix Acct-Session-ID in ABNFs > - Remove table entry for Termination-Action > - Add reference to Base Termination-Cause > - Re-add missing code points for NAS-Port-Type > - correct header levels for LAT services > > - Tunnel-Client-Auth-ID, Tunnel-Server-Auth-ID defined as UTF8Strings > (Was Unsigned32 in table, OctetString in description) > > - Pg 60, Sect 9.1, Session-Timeout: Remove phrase "I guess > the safest bet is to" > > > ---------- > Issues: > > Issue 431 - Identities in RADIUS Translation, Pasi Eronen > > 1&2) State attribute should contain: > "Diameter/""/""/" > > 3) State content building should be consistent > 4) Fix section 9.3 for Origin-Host to identify NAS source, not gateway > 5) Corrected. > 6) Origin-Realm & Origin-Host AVP should contain best > verified info on NAS identity (not the gateway) > > Issue 451 - Interim vs. STOP Record, Avi Lior > a) Compromise - add text to allow Stop/Start as service specific > b) Editorial correction Accepted > > > Issue 452 - Accounting Session-Id in ACA Command, Avi Lior > Accepted: Corrected AVP name > > Issue 453 - Problem with Accounting Session-Id and > Session-Id, Avi Lior > Accepted: Acct-Session-Id cannot be put in Diam Session-Id > Acct-Session-Id is an accepted Diameter AVP. > A RADIUS/Diameter gateway will have to assign & > track > Diameter Session-Ids. > > Issue 454 - Diameter NASREQ conflict with Base, Bernard Aboba > Close: Text already changed in draft 14 > > Issue 457 - Editorial NIT in NASREQ-14, Johan Hermans > Accepted: Updated Service-Type list > > Issue 462 - Typo in NASREQ-14, Ignacio Goyret > Accepted: Tunnel-Client-Auth-Id type bug > > > From owner-aaa-wg@merit.edu Tue Apr 20 17:39:01 2004 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 RAA27876 for ; Tue, 20 Apr 2004 17:39:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6ABD691301; Tue, 20 Apr 2004 17:38:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 76EC7912F0; Tue, 20 Apr 2004 17:38:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4DD9591313 for ; Tue, 20 Apr 2004 17:38:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2268058979; Tue, 20 Apr 2004 17:38:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h019.c000.snv.cp.net [209.228.32.83]) by segue.merit.edu (Postfix) with SMTP id 7FA2158976 for ; Tue, 20 Apr 2004 17:38:27 -0400 (EDT) Received: (cpmta 13953 invoked from network); 20 Apr 2004 14:38:26 -0700 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.83) with SMTP; 20 Apr 2004 14:38:26 -0700 X-Sent: 20 Apr 2004 21:38:26 GMT Message-Id: <5.2.1.1.2.20040420154253.030aa140@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 20 Apr 2004 17:38:13 -0400 To: Avi Lior , "'Bernard Aboba'" , aaa-wg@merit.edu From: David Mitton Subject: [AAA-WG]: Re: Wrapping up NASREQ Re-auth In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk On 4/20/2004 12:30 PM -0400, Avi Lior wrote: >A couple of things: > >If the RAR properly identifies an active session, the NAS will > initiate a new local reauthentication or authorization sequence as > indicated by the Re-Auth-Request-Type value. This will cause the NAS > to send a new AAR message using the existing Session-Id. The server > will respond with an AAA message to specify the new service > parameters. > >Shouldn't we state that the AUTH-REQUEST-TYPE AVP of the AAR message be set >to the same value Received in RAR Re-Auth-Request-Type AVP? And what >happens if its not? I don't really have an opinion here. Seems logical. But either party could abort the Re-auth if it doesn't like the values in many AVPs. This AVP is really described in the Base. I find it interesting that we don't have a "Authenticate_Only" value for Re-Auth-Request. >I am still having an issue with the following paragraph: > > If accounting is active, every change of authentication or > authorization MUST generate an accounting message. Either an > Accounting-Record-Type of INTERIM_RECORD indicating the new session > attributes and cumulative status (preferred) or two messages of the > types STOP_RECORD, and START_RECORD. The later would be for service > specific compatibility with some RADIUS services. > > >Why is the Interim preferred? Because the session hasn't ended. Stop means Stop, and we're not stopping we're continuing. We've still got an authenticated context. >Preferred seems to be an editorial comment. Maybe. > Should we not specify when this >is to be used? Also, would not Diameter suffer from the same issue that a >RADIUS server would suffer? It shouldn't, I was hoping to get rid of such problems. >Would a backend process know why the Interim >record is generated. Would it always know what has changed? Hopefully the service would generate sufficent information to discern that. > Would it be >able to do the calculation to generate an appropriate bill? A service information problem. Most anything from the authorization message is fair game to include in the Accounting message. Billing is not the only goal of Accounting, in fact one not normally addressed in the IETF. Accounting is about about statistical and usage information. The NAS doesn't know how I'm billing for my services and sessions. I may be offering flat rate unlimited. I many only care about total connect minutes, etc. >Also, if new attributes are received, this is a new session right? I think that's the crux of our disagreement. I don't think that it is. Maybe, but not a given. I am aware of a number of services that offer differing sub-services over the lifetime of a session. And for many providers that is not a problem, billing or management. In my former line of work, a session didn't end until the port was disconnected. I think the NAS is the primary party in position to make that decision. But the server could just terminate the session and wait for the user to connect again. >Don't we >have to use something other then Interim records to deliniate a new session >in diameter? If this is important, sub-session Start/Stop messages are an option. This is one reason that the Diameter Session-Id is separate from the RADIUS Acct-Session-Id. We brought along RADIUS's Accounting-Multi-Session-Id and we added Accounting-Sub-Session-Id. Our Nortel (former Bay Networks) VPN server would Start record for the construction of a new tunnel and do Starts & Stops (and hoards of VSA Interims) for each user session that used it, until the tunnel was torn down. Also there is a precedent in the multi-link PPP space. Each PPP "sub-" link would not know it was potentially part of a bundle until after it authenticated and the server could give it a token to associate with other links. Each PPP link would become a separate RADIUS session, but part of a single overall user service session. Links could come and go based on the how the system load or balancing. The simplest system is one where a person connects an ASCII terminal to a NAS box, logs in (basic session) and then Telnets out (Terminal service either sub-session or additional session) Until the port disconnects, the service is being provided. Our box (Xylogics) also supported LAT and FTP, etc. services too. >Also, how would you (in a scalable way) specify which method is to be used: >Interim or Stop/Start records? In some ways it is a service specific accounting thing. But we don't spec the services to that level of detail in the WG. Heck RADIUS Accouting isn't even on the Standards track. I would hope that in Diameter we provide the tools to do a straight forward and sensible implementation. Also One (1) Interim record is less overhead than Two (2) Stop/Start records. Dave. > > -----Original Message----- > > From: Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Monday, April 19, 2004 3:34 PM > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: Wrapping up NASREQ... > > > > > > David Mitton has put up a strawman version of the NASREQ-15 here for > > examination: > > > > http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-15.txt > > > > This version is designed to close all open issues (see below). > > > > Since NASREQ has already gone through WG last call, IETF last > > call, IESG review and approval for publication as a Proposed > > Standard, this represents the very last opportunity to > > comment on it before it is done. > > > > So... speak now or forever (until NASREQbis) hold your piece. > > > > ... From owner-aaa-wg@merit.edu Tue Apr 20 20:06:25 2004 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 UAA09078 for ; Tue, 20 Apr 2004 20:06:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0BBCC91221; Tue, 20 Apr 2004 20:06:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B97FE91225; Tue, 20 Apr 2004 20:06:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 00A6691221 for ; Tue, 20 Apr 2004 20:05:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E07175893A; Tue, 20 Apr 2004 20:05:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 896FD5891C for ; Tue, 20 Apr 2004 20:05:59 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Tue, 20 Apr 2004 20:05:58 -0400 Message-ID: From: Avi Lior To: David Mitton , Avi Lior , "'Bernard Aboba'" , aaa-wg@merit.edu Subject: [AAA-WG]: RE: Wrapping up NASREQ Re-auth Date: Tue, 20 Apr 2004 20:05:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk One problem I have is the use of Interim Records goes against the purpose of what Interim Accounting is about: Interim accounting An interim accounting message provides a snapshot of usage during a user's session. It is typically implemented in order to provide for partial accounting of a user's session in the case of a device reboot or other network problem prevents the reception of a session summary message or session record. What you propose goes against the above "grain". I think you are using Interim in this case to save a message. But this maybe opening other cans of worms. Also, are we going to increment the various accounting/session ids? Its not clear. You say the session is not ending. But as stated in that section, the session may be getting new session attributs. It is therefore a new Session. I think two things are happening here: one is we have re-authentication the other is re-authorization. I think that these need to be treated differently. I may or may not want to record the fact that re-authentication happened. I probably don't care much about billing for that event. But for re-authorization, we want to record and we want to probably bill for that. This perhaps would require more support then just recording the event in an interim record. > -----Original Message----- > From: David Mitton [mailto:david@mitton.com] > Sent: Tuesday, April 20, 2004 5:38 PM > To: Avi Lior; 'Bernard Aboba'; aaa-wg@merit.edu > Subject: Re: Wrapping up NASREQ Re-auth > > > On 4/20/2004 12:30 PM -0400, Avi Lior wrote: > >A couple of things: > > > >If the RAR properly identifies an active session, the NAS will > > initiate a new local reauthentication or authorization > sequence as > > indicated by the Re-Auth-Request-Type value. This will > cause the NAS > > to send a new AAR message using the existing Session-Id. > The server > > will respond with an AAA message to specify the new service > > parameters. > > > >Shouldn't we state that the AUTH-REQUEST-TYPE AVP of the AAR > message be > >set to the same value Received in RAR Re-Auth-Request-Type AVP? And > >what happens if its not? > > I don't really have an opinion here. Seems logical. But > either party > could abort the Re-auth if it doesn't like the values in many AVPs. > > This AVP is really described in the Base. > I find it interesting that we don't have a > "Authenticate_Only" value for > Re-Auth-Request. > > > >I am still having an issue with the following paragraph: > > > > If accounting is active, every change of authentication or > > authorization MUST generate an accounting message. Either an > > Accounting-Record-Type of INTERIM_RECORD indicating the > new session > > attributes and cumulative status (preferred) or two > messages of the > > types STOP_RECORD, and START_RECORD. The later would be > for service > > specific compatibility with some RADIUS services. > > > > > >Why is the Interim preferred? > > Because the session hasn't ended. Stop means Stop, and we're > not stopping > we're continuing. We've still got an authenticated context. > > >Preferred seems to be an editorial comment. > > Maybe. > > > Should we not specify when this > >is to be used? Also, would not Diameter suffer from the same > issue that > >a RADIUS server would suffer? > > It shouldn't, I was hoping to get rid of such problems. > > >Would a backend process know why the Interim > >record is generated. Would it always know what has changed? > > Hopefully the service would generate sufficent information to > discern that. > > > Would it be > >able to do the calculation to generate an appropriate bill? > > A service information problem. Most anything from the authorization > message is fair game to include in the Accounting message. > > Billing is not the only goal of Accounting, in fact one not normally > addressed in the IETF. Accounting is about about statistical > and usage > information. > The NAS doesn't know how I'm billing for my services and > sessions. I may > be offering flat rate unlimited. I many only care about > total connect > minutes, etc. > > > >Also, if new attributes are received, this is a new session right? > > I think that's the crux of our disagreement. > I don't think that it is. Maybe, but not a given. > I am aware of a number of services that offer differing > sub-services over > the lifetime of a session. And for many providers that is > not a problem, > billing or management. > > In my former line of work, a session didn't end until the port was > disconnected. > > I think the NAS is the primary party in position to make that > decision. But the server could just terminate the session and > wait for the user to > connect again. > > >Don't we > >have to use something other then Interim records to deliniate a new > >session in diameter? > > If this is important, sub-session Start/Stop messages are an > option. This is one reason that the Diameter Session-Id is > separate from the RADIUS > Acct-Session-Id. We brought along RADIUS's > Accounting-Multi-Session-Id and > we added Accounting-Sub-Session-Id. > > Our Nortel (former Bay Networks) VPN server would Start > record for the > construction of a new tunnel and do Starts & Stops (and hoards of VSA > Interims) for each user session that used it, until the > tunnel was torn down. > > Also there is a precedent in the multi-link PPP space. Each > PPP "sub-" > link would not know it was potentially part of a bundle until > after it > authenticated and the server could give it a token to > associate with other > links. Each PPP link would become a separate RADIUS session, > but part of a > single overall user service session. Links could come and go > based on the > how the system load or balancing. > > The simplest system is one where a person connects an ASCII > terminal to a > NAS box, logs in (basic session) and then Telnets out > (Terminal service > either sub-session or additional session) Until the port > disconnects, the > service is being provided. Our box (Xylogics) also supported > LAT and FTP, > etc. services too. > > > >Also, how would you (in a scalable way) specify which method > is to be > >used: Interim or Stop/Start records? > > In some ways it is a service specific accounting thing. But > we don't spec > the services to that level of detail in the WG. Heck RADIUS > Accouting > isn't even on the Standards track. I would hope that in Diameter we > provide the tools to do a straight forward and sensible > implementation. > > Also One (1) Interim record is less overhead than Two (2) > Stop/Start records. > > > Dave. > > > > -----Original Message----- > > > From: Bernard Aboba [mailto:aboba@internaut.com] > > > Sent: Monday, April 19, 2004 3:34 PM > > > To: aaa-wg@merit.edu > > > Subject: [AAA-WG]: Wrapping up NASREQ... > > > > > > > > > David Mitton has put up a strawman version of the > NASREQ-15 here for > > > examination: > > > > > > > http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-15.tx > > > t > > > > > > This version is designed to close all open issues (see below). > > > > > > Since NASREQ has already gone through WG last call, IETF > last call, > > > IESG review and approval for publication as a Proposed Standard, > > > this represents the very last opportunity to comment on > it before it > > > is done. > > > > > > So... speak now or forever (until NASREQbis) hold your piece. > > > > > > > ... > > From owner-aaa-wg@merit.edu Tue Apr 20 22:01:20 2004 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 WAA15128 for ; Tue, 20 Apr 2004 22:01:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 97494912E9; Tue, 20 Apr 2004 22:00:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F08B912EB; Tue, 20 Apr 2004 22:00:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B24EF912E9 for ; Tue, 20 Apr 2004 22:00:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9D8125891C; Tue, 20 Apr 2004 22:00:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id E8E5E588C3 for ; Tue, 20 Apr 2004 22:00:44 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i3L26Su17074; Tue, 20 Apr 2004 19:06:28 -0700 Date: Tue, 20 Apr 2004 19:06:28 -0700 (PDT) From: Bernard Aboba To: Avi Lior Cc: David Mitton , aaa-wg@merit.edu Subject: Re: [AAA-WG]: RE: Wrapping up NASREQ Re-auth In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I think two things are happening here: one is we have re-authentication the > other is re-authorization. I think that these need to be treated > differently. I may or may not want to record the fact that > re-authentication happened. I probably don't care much about billing for > that event. > > But for re-authorization, we want to record and we want to probably bill for > that. This perhaps would require more support then just recording the event > in an interim record. There is some logic to this. However, in practice the distinctions may not be so clean: a. Reauthentication: If you do reauthentication and get a new set of attributes (this can happen in either Diameter or RADIUS) do you have to check to see if the attributes change to decide whether to send an Interim accounting update? b. Re-authorization: When doing Diameter re-authorization or RFC 3576 CoA, do we start a new session in all cases? Does it matter who initiated the re-authorization (NAS or AAA server)? From owner-aaa-wg@merit.edu Wed Apr 21 06:32:49 2004 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 GAA09358 for ; Wed, 21 Apr 2004 06:32:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2217091315; Wed, 21 Apr 2004 06:32:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D532891316; Wed, 21 Apr 2004 06:32:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7667D91315 for ; Wed, 21 Apr 2004 06:32:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 666C858975; Wed, 21 Apr 2004 06:32:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id D3DE358894 for ; Wed, 21 Apr 2004 06:32:23 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3LAWMWR023709 for ; Wed, 21 Apr 2004 12:32:22 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 Apr 2004 12:32:22 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 21 Apr 2004 12:32:26 +0200 Message-ID: From: "Harri Hakala (JO/LMF)" To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC Issue: Radius-Diameter CC Interworking model Date: Wed, 21 Apr 2004 12:32:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 21 Apr 2004 10:32:22.0200 (UTC) FILETIME=[EE1C8380:01C4278B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Harri Hakala Submitter email address: harri.hakala@ericsson.com Date first submitted: 21.04.2004 Reference: Document: DCC-04 Comment type: T Priority: 1 Section: 11 Rationale/Explanation of issue: In the DDC-04 the RADIUS/Diameter credit control Interworking section is incomplete. It leaves out a lot of important standardization details, but on the other hands it is far too detail to be a just guideline. A writing a true guideline section is problematic without having stable target document for translation. It would be better to describe RADIUS- Diameter credit control interworking model in the DCC and the detailed translation somewhere else, either in a separate I-D or in the RADIUS prepaid specification as discussed on the aaa-mailing list. http://www.merit.edu/mail.archives/aaa-wg/msg00408.html http://www.merit.edu/mail.archives/aaa-wg/msg00417.html To describe this interworking model, the architecture model of section 2 (figure 2) and related text as well as the flow II of the appendix can be moved to a new section 11, RADIUS/Diameter Credit-control Interworking Model. Requested Change: REMOVE: 1) Section 2 Other entities, such as RADIUS AAA servers, may act as a Diameter credit-control clients for service elements that use credit control mechanisms other than Diameter credit-control. In this case the AAA server contact the Diameter credit-control server as part of the authorization process. The interworking architecture is illustrated in Figure 2, the interaction between the Diameter credit-control client and the service element is outside the scope of this specification. Interworking with RADIUS is addressed in section 11 and Annex A. AAA +--------+ +---------+ protocol +------------+ +--------+ | End |<----->| Service |<------------>| AAA | |Business| | User | | Element | | Server | |Support | +--------+ +-->| | |+----------+|-->|System | | +---------+ ||CC client || | | | |+----------+| | | +--------+ | +------^-----+ +--------+ | End |<--+ credit-control | ^ | User | protocol | | +--------+ +-------V------+ | |Credit-control|--------+ | Server | +--------------+ Figure 2: Credit-control architecture with Service Element not supporting the credit-control protocol 2) Flow II from appendix A 3) the section 11 ADD: Section 11 RADIUS/Diameter Credit-control Interworking Model This section defines the basic principles for the Diameter Credit-control/RADIUS prepaid inter-working model, that is a message translation between RADIUS based prepaid solution and Diameter Credit-control application. A complete description of the protocol translations between RADIUS and Diameter Credit-control application is beyond the scope of this specification and SHOULD be addressed in another appropriate document such as the RADIUS prepaid specification. The Diameter credit-control architecture may have a Translation Agent, which is capable of translation between RADIUS prepaid and Diameter Credit-control protocol. An AAA server, usually the Home AAA server, may act as a Translation Agent while acting also as Diameter credit-control client for service elements that use credit control mechanisms other than Diameter credit-control, for instance RADIUS prepaid. In this case the AAA server contacts the Diameter credit-control server as part of the authorization process. The interworking architecture is illustrated in figure X and interworking flow in figure Y. In roaming situation the service element (e.g. the NAS) may be located in the visited network and a Visited AAA server is usually contacted. The Visited AAA server connects then to the Home AAA server. Radius prepaid +--------+ +---------+ protocol +------------+ +--------+ | End |<----->| Service |<------------>| Home AAA | |Business| | User | | Element | | Server | |Support | +--------+ +-->| | |+----------+|-->|System | | +---------+ ||CC client || | | | |+----------+| | | +--------+ | +------^-----+ +--------+ | End |<--+ credit-control | ^ | User | protocol | | +--------+ +-------V------+ | |Credit-control|--------+ | Server | +--------------+ Figure X: Credit-control architecture with Service Element containing translation agent, translating RADIUS prepaid to Diameter credit control protocol When the AAA server acting as a Translation Agent receives an initial RADIUS Access-Request message from service Element (e.g. NAS access), it performs regular Authentication and Authorization. If the RADIUS Access-Request message indicates that the service element is capable of credit-control, and if the AAA server finds that the subscriber is a prepaid subscriber then a Diameter Credit control request SHOULD be sent towards the credit-control server to perform credit authorization and to establish a credit control session. After the Diameter credit-control server checks the end user's account balance, rates the service and reserves credit from the end user's account, the reserved quota is returned to the Home AAA server in the Diameter Credit-Control-Answer. Then the Home AAA server sends the reserved quota to the service element in the RADIUS Access-Accept. At the expiry of the allocated quota, the service element sends a new RADIUS Access-Request to the Home AAA server containing the units used this far. The AAA server shall map RADIUS Access-Request containing the reported units to the Diameter credit-control server in a Diameter Credit-Control-Request (UPDATE_REQUEST). The Diameter credit-control server debits the used units from the end user's account and allocates a new quota that is returned to the Home AAA server in the Diameter Credit-Control-Answer. The quota is transferred to the service element in the RADIUS Access-Accept. When the end user terminates the service or when all the quota has been used, the service element sends a RADIUS Access-Request. To debit the used units from the end user's account and to stop the credit control session, the Home AAA server sends a Diameter Credit-Control-Request (TERMINATION_REQUEST) to the credit-control server. The Diameter credit-control server acknowledges the session termination by sending a Diameter Credit-Control-Answer to the Home AAA server. The RADIUS Access-Accept is sent to the NAS. A following diagram illustrates a RADIUS prepaid - Diameter credit control interworking sequence. Service Element Translation agent (e.g.NAS) (CC Client) CC Server | Access-Request | | |----------------------->| | | | CCR (initial) | | |----------------------->| | | CCA (granted_Units) | | |<-----------------------| | Access-Accept | | | (granted Units) | | |<-----------------------| | : : : | Access-Request | | | (used Units) | | |----------------------->| | | | CCR (update, | | | used Units, | | |----------------------->| | | CCA (granted_Units) | | |<-----------------------| | Access-Accept | | | (granted Units) | | |<-----------------------| | : : : | Access-Request | | |----------------------->| | | | CCR (termin., | | | used Units) | | |----------------------->| | | CCA | | |<-----------------------| | Access-Accept | | |<-----------------------| | | | | Figure Y: Message flow example with RADIUS prepaid - Diameter credit control interworking From owner-aaa-wg@merit.edu Wed Apr 21 07:54:33 2004 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 HAA14094 for ; Wed, 21 Apr 2004 07:54:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6EB989131A; Wed, 21 Apr 2004 07:54:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 41F6A9131D; Wed, 21 Apr 2004 07:54:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 15F459131A for ; Wed, 21 Apr 2004 07:54:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 01BEF58855; Wed, 21 Apr 2004 07:54:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 31E35589A3 for ; Wed, 21 Apr 2004 07:54:19 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id DAE3A89851; Wed, 21 Apr 2004 14:54:02 +0300 (EEST) Message-ID: <4086601B.3040309@kolumbus.fi> Date: Wed, 21 Apr 2004 14:50:51 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Salowey Cc: aaa-wg@merit.edu, Pasi Eronen , Bernard Aboba Subject: Re: [AAA-WG]: Issue eap : Key Name AVP References: <009401c40185$8c642cf0$0300000a@amer.cisco.com> In-Reply-To: <009401c40185$8c642cf0$0300000a@amer.cisco.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 Hi Joe, I'm going through the remaining issues on Diameter EAP, and this was one of them. I do see the point of being able to name a the MSK. However, I would suggest that we define this AVP in a separate document when there is a specific use case and need for it, because I think adding it to the Diameter EAP document creates some problems for us (more on that below). I would also note that we may need AMSK names, though informing applications of them probably takes place through some node-internal API rather than a AAA protocol. About the problems that I mentioned: o I think its fine to say that the exact use of the name information is link layer dependent. I take it that this means the client side? But I feel uneasy about defining an attribute unless we also specify how the server fills in the information. o We can expect the EAP Keying Framework document to specify this, perhaps, but then we create a dependency from this document to the EAP Keying Framework, which is likely ready later than this document (and is Informational). o Current systems do not use the key name for anything. o As you point out, there is no corresponding RADIUS attributes. This would imply that all Diameter clients would have to prepare for the possibility that they don't get this attribute, in case the server was RADIUS. Likewise all servers would have to prepare for the possibility that their attribute is stripped off by a Diameter to RADIUS gateway. So it seems hard to even consider relying on this information. Comments? Pasi, Bernard, do you have an opinion on this? --Jari Joseph Salowey wrote: > Submitter name: Joe Salowey > Submitter email address: jsalowey@cisco.com > Date first submitted: 3/3/2004 > Reference: > Document: eap > Comment type: T > Priority: '1' Should fix > Section: 4.1 > Rationale/Explanation of issue: > > Since EAP keying has the concept of the key name this should probably be > returned along with the Master Key. > > "4.1.5 EAP-Master-Session-Key-Name AVP > > The EAP-Master-Session-Key-Name AVP (AVP Code TBD) is of type > OctetString. It contains the name used to identify the > EAP-Master-Session-Key. Exactly how this name is used depends upon the > link layer in question, and is beyond the scope of this document. This > AVP can optionally be present whenever an EAP-Master-Session-Key AVP is > present. > > Since there currently are no standard RADIUS attribtues for key name > this attribute does not translate to or from RADIUS in a standard way." From owner-aaa-wg@merit.edu Wed Apr 21 09:30:38 2004 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 JAA19925 for ; Wed, 21 Apr 2004 09:30:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 796C691320; Wed, 21 Apr 2004 09:30:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 025A091321; Wed, 21 Apr 2004 09:30:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 208B591320 for ; Wed, 21 Apr 2004 09:30:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C327958946; Wed, 21 Apr 2004 09:30:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 390E4589BF for ; Wed, 21 Apr 2004 09:30:01 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i3LDZfd25600; Wed, 21 Apr 2004 06:35:41 -0700 Date: Wed, 21 Apr 2004 06:35:41 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: Joseph Salowey , aaa-wg@merit.edu, Pasi Eronen Subject: Re: [AAA-WG]: Issue eap : Key Name AVP In-Reply-To: <4086601B.3040309@kolumbus.fi> Message-ID: References: <009401c40185$8c642cf0$0300000a@amer.cisco.com> <4086601B.3040309@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > o I think its fine to say that the exact use of > the name information is link layer dependent. > I take it that this means the client side? > But I feel uneasy about defining an attribute > unless we also specify how the server fills > in the information. While the use of the name information may be link layer dependent, the name itself is not. Since the name as defined in the EAP Key Framework is dependent on the EAP method, the server obtains the name from the method. > o We can expect the EAP Keying Framework document > to specify this, perhaps, but then we create > a dependency from this document to the EAP > Keying Framework, which is likely ready later > than this document (and is Informational). I don't think a dependency is created merely by including an AVP for the name. > o Current systems do not use the key name for > anything. Actually, IEEE 802.11i does use the key name. However, the NAS can calculate the relevant names from the keys themselves, so it doesn't need it to be supplied by the AAA server. So I think that the name is only needed when it is requested by the NAS. > o As you point out, there is no corresponding > RADIUS attributes. This would imply that all > Diameter clients would have to prepare for the > possibility that they don't get this attribute, > in case the server was RADIUS. Likewise all > servers would have to prepare for the possibility > that their attribute is stripped off by a Diameter > to RADIUS gateway. So it seems hard to even > consider relying on this information. I think that these issues can be addressed by only sending the name in a Response when the NAS includes a name AVP in the Request. From owner-aaa-wg@merit.edu Wed Apr 21 11:26:22 2004 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 LAA27301 for ; Wed, 21 Apr 2004 11:26:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6A3449135A; Wed, 21 Apr 2004 11:23:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C3DC99135E; Wed, 21 Apr 2004 11:23:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B30D79135F for ; Wed, 21 Apr 2004 11:20:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 875CD589E6; Wed, 21 Apr 2004 11:20:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h032.c000.snv.cp.net [209.228.34.190]) by segue.merit.edu (Postfix) with SMTP id BA458589DE for ; Wed, 21 Apr 2004 11:20:52 -0400 (EDT) Received: (cpmta 6676 invoked from network); 21 Apr 2004 08:20:50 -0700 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.34.190) with SMTP; 21 Apr 2004 08:20:50 -0700 X-Sent: 21 Apr 2004 15:20:50 GMT Message-Id: <5.2.1.1.2.20040421104347.04031120@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 21 Apr 2004 11:19:48 -0400 To: Avi Lior , "'Bernard Aboba'" , aaa-wg@merit.edu From: David Mitton Subject: Re: [AAA-WG]: RE: Wrapping up NASREQ Re-auth In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk On 4/20/2004 08:05 PM -0400, Avi Lior wrote: >One problem I have is the use of Interim Records goes against the purpose of >what Interim Accounting is about: > >Interim accounting > An interim accounting message provides a snapshot of usage during > a user's session. It is typically implemented in order to provide > for partial accounting of a user's session in the case of a device > reboot or other network problem prevents the reception of a > session summary message or session record. > >What you propose goes against the above "grain". Well that's one and maybe the most popular use of that Acct-Status-Type. There is nothing saying it's the only or restrictive one. The Acct-Status-Type of "Interim-Status" appears in RFC 2866 without any of the above information. The Acct-Interim-Interval attribute first appears in RFC 2869 as an Extention. The Interim accounting process and the Interim-Status record are two separate things. I think we could use an INTERIM-EVENT record type here. But that suggestion was not well received a little while back, and creating one adds a backwards compatibility problem. >I think you are using Interim in this case to save a message. But this >maybe opening other cans of worms. > >Also, are we going to increment the various accounting/session ids? Its not >clear. Diameter only asks that the Session-Id remain constant for the session. All the other sub-ids can change as needed for the service. >You say the session is not ending. But as stated in that section, the >session may be getting new session attributs. It is therefore a new >Session. No. It's not. If same user, same port, Until the port is disconnected my service thinks it's one session. The user may reauthenticate and reauthorize until the cows come home. In fact it may be done automatically for him by a lower layer. Certainly possible with 802.11 roaming. If the process discerns a different user (whatever that means in the service context), then by all means, indicate a new context and Stop the old session. >I think two things are happening here: one is we have re-authentication the >other is re-authorization. I think that these need to be treated >differently. I may or may not want to record the fact that >re-authentication happened. I probably don't care much about billing for >that event. but we're still talking about "re-" something. Not bare, new, Auth >But for re-authorization, we want to record and we want to probably bill for >that. This perhaps would require more support then just recording the event >in an interim record. Go for it. The requirements are minimums. Given that we've been through multiple last calls on this document. I'm not going to change anything that is not broken without WG concensus. Dave. > > -----Original Message----- > > From: David Mitton [mailto:david@mitton.com] > > Sent: Tuesday, April 20, 2004 5:38 PM > > To: Avi Lior; 'Bernard Aboba'; aaa-wg@merit.edu > > Subject: Re: Wrapping up NASREQ Re-auth > > > > > > On 4/20/2004 12:30 PM -0400, Avi Lior wrote: > > >A couple of things: > > > > > >If the RAR properly identifies an active session, the NAS will > > > initiate a new local reauthentication or authorization > > sequence as > > > indicated by the Re-Auth-Request-Type value. This will > > cause the NAS > > > to send a new AAR message using the existing Session-Id. > > The server > > > will respond with an AAA message to specify the new service > > > parameters. > > > > > >Shouldn't we state that the AUTH-REQUEST-TYPE AVP of the AAR > > message be > > >set to the same value Received in RAR Re-Auth-Request-Type AVP? And > > >what happens if its not? > > > > I don't really have an opinion here. Seems logical. But > > either party > > could abort the Re-auth if it doesn't like the values in many AVPs. > > > > This AVP is really described in the Base. > > I find it interesting that we don't have a > > "Authenticate_Only" value for > > Re-Auth-Request. > > > > > > >I am still having an issue with the following paragraph: > > > > > > If accounting is active, every change of authentication or > > > authorization MUST generate an accounting message. Either an > > > Accounting-Record-Type of INTERIM_RECORD indicating the > > new session > > > attributes and cumulative status (preferred) or two > > messages of the > > > types STOP_RECORD, and START_RECORD. The later would be > > for service > > > specific compatibility with some RADIUS services. > > > > > > > > >Why is the Interim preferred? > > > > Because the session hasn't ended. Stop means Stop, and we're > > not stopping > > we're continuing. We've still got an authenticated context. > > > > >Preferred seems to be an editorial comment. > > > > Maybe. > > > > > Should we not specify when this > > >is to be used? Also, would not Diameter suffer from the same > > issue that > > >a RADIUS server would suffer? > > > > It shouldn't, I was hoping to get rid of such problems. > > > > >Would a backend process know why the Interim > > >record is generated. Would it always know what has changed? > > > > Hopefully the service would generate sufficent information to > > discern that. > > > > > Would it be > > >able to do the calculation to generate an appropriate bill? > > > > A service information problem. Most anything from the authorization > > message is fair game to include in the Accounting message. > > > > Billing is not the only goal of Accounting, in fact one not normally > > addressed in the IETF. Accounting is about about statistical > > and usage > > information. > > The NAS doesn't know how I'm billing for my services and > > sessions. I may > > be offering flat rate unlimited. I many only care about > > total connect > > minutes, etc. > > > > > > >Also, if new attributes are received, this is a new session right? > > > > I think that's the crux of our disagreement. > > I don't think that it is. Maybe, but not a given. > > I am aware of a number of services that offer differing > > sub-services over > > the lifetime of a session. And for many providers that is > > not a problem, > > billing or management. > > > > In my former line of work, a session didn't end until the port was > > disconnected. > > > > I think the NAS is the primary party in position to make that > > decision. But the server could just terminate the session and > > wait for the user to > > connect again. > > > > >Don't we > > >have to use something other then Interim records to deliniate a new > > >session in diameter? > > > > If this is important, sub-session Start/Stop messages are an > > option. This is one reason that the Diameter Session-Id is > > separate from the RADIUS > > Acct-Session-Id. We brought along RADIUS's > > Accounting-Multi-Session-Id and > > we added Accounting-Sub-Session-Id. > > > > Our Nortel (former Bay Networks) VPN server would Start > > record for the > > construction of a new tunnel and do Starts & Stops (and hoards of VSA > > Interims) for each user session that used it, until the > > tunnel was torn down. > > > > Also there is a precedent in the multi-link PPP space. Each > > PPP "sub-" > > link would not know it was potentially part of a bundle until > > after it > > authenticated and the server could give it a token to > > associate with other > > links. Each PPP link would become a separate RADIUS session, > > but part of a > > single overall user service session. Links could come and go > > based on the > > how the system load or balancing. > > > > The simplest system is one where a person connects an ASCII > > terminal to a > > NAS box, logs in (basic session) and then Telnets out > > (Terminal service > > either sub-session or additional session) Until the port > > disconnects, the > > service is being provided. Our box (Xylogics) also supported > > LAT and FTP, > > etc. services too. > > > > > > >Also, how would you (in a scalable way) specify which method > > is to be > > >used: Interim or Stop/Start records? > > > > In some ways it is a service specific accounting thing. But > > we don't spec > > the services to that level of detail in the WG. Heck RADIUS > > Accouting > > isn't even on the Standards track. I would hope that in Diameter we > > provide the tools to do a straight forward and sensible > > implementation. > > > > Also One (1) Interim record is less overhead than Two (2) > > Stop/Start records. > > > > > > Dave. > > > > > > -----Original Message----- > > > > From: Bernard Aboba [mailto:aboba@internaut.com] > > > > Sent: Monday, April 19, 2004 3:34 PM > > > > To: aaa-wg@merit.edu > > > > Subject: [AAA-WG]: Wrapping up NASREQ... > > > > > > > > > > > > David Mitton has put up a strawman version of the > > NASREQ-15 here for > > > > examination: > > > > > > > > > > http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-15.tx > > > > t > > > > > > > > This version is designed to close all open issues (see below). > > > > > > > > Since NASREQ has already gone through WG last call, IETF > > last call, > > > > IESG review and approval for publication as a Proposed Standard, > > > > this represents the very last opportunity to comment on > > it before it > > > > is done. > > > > > > > > So... speak now or forever (until NASREQbis) hold your piece. > > > > > > > > > > ... > > > > From owner-aaa-wg@merit.edu Wed Apr 21 18:49:06 2004 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 SAA26947 for ; Wed, 21 Apr 2004 18:49:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1BB9D91414; Wed, 21 Apr 2004 18:46:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9CE591416; Wed, 21 Apr 2004 18:46:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 287B591414 for ; Wed, 21 Apr 2004 18:46:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0A54C58955; Wed, 21 Apr 2004 18:46:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 4F0F758965 for ; Wed, 21 Apr 2004 18:46:29 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i3LMA8o23535; Wed, 21 Apr 2004 15:10:08 -0700 Date: Wed, 21 Apr 2004 15:10:08 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue eap : Key Name AVP In-Reply-To: <4086EB53.1070900@kolumbus.fi> Message-ID: References: <009401c40185$8c642cf0$0300000a@amer.cisco.com> <4086601B.3040309@kolumbus.fi> <4086EB53.1070900@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > No, it would be created by stating that the contents > of the AVP must conform to the rules dictated in [REF]. > But I think what you are saying is that Diameter EAP > states the name is obtained from the method, and > then formal dependencies (if any) to EAP Keying Framework > are in the methods. Is this correct? Yes. To Diameter EAP the name is just an opaque blob. > I didn't think of it this way initially, but > it looks like a nice way to avoid the dependency! Good. > Right. But if I understand this correctly, there'd > be no NASes that would need this for current link > layers -- of course this might change for future > link layers or upgrades. Yes. So if the NAS doesn't ask, we don't send it. > > I think that these issues can be addressed by only sending the name in > > a Response when the NAS includes a name AVP in the Request. > > Or by sending the name in any case. Either way, the parties > have to prepare for the possibility that you don't get the > AVP even if you wanted it Today's RADIUS NASen won't ask for a key name. Therefore a RADIUS/Diameter gateway won't send a Request with a Key-Name AVP and the Diameter server won't send one. So there is no compatibility problem there. A future Diameter NAS might or might not ask for a key name. If it doesn't ask, then there is no issue either with a Diameter Server or a RADIUS server to whom it talks via a RADIUS/Diameter gateway. If it asks for a key name, and it's talking to a Diameter Server, things will work. If it's talking to a RADIUS server and asks for a key name, then the Diameter/RADIUS gateway would need a RADIUS key-name attribute to translate to. If there is no such attribute, then the key-name attribute wouldn't be received. But presumably for that case, the Diameter NAS would need to be deployed along with compatible RADIUS servers. So I don't see an issue there either. From owner-aaa-wg@merit.edu Wed Apr 21 18:50:06 2004 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 SAA27050 for ; Wed, 21 Apr 2004 18:50:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E6FD191418; Wed, 21 Apr 2004 18:48:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADCD691420; Wed, 21 Apr 2004 18:48:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2436991418 for ; Wed, 21 Apr 2004 18:48:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 072BD58960; Wed, 21 Apr 2004 18:48:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id AD47158969 for ; Wed, 21 Apr 2004 18:48:31 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Wed, 21 Apr 2004 18:48:12 -0400 Message-ID: From: Avi Lior To: Bernard Aboba , Avi Lior Cc: David Mitton , aaa-wg@merit.edu Subject: RE: [AAA-WG]: RE: Wrapping up NASREQ Re-auth Date: Wed, 21 Apr 2004 18:48:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Bernard and all: > > I think two things are happening here: one is we have > > re-authentication the other is re-authorization. I think > that these > > need to be treated differently. I may or may not want to > record the > > fact that re-authentication happened. I probably don't care much > > about billing for that event. > > > > But for re-authorization, we want to record and we want to probably > > bill for that. This perhaps would require more support then just > > recording the event in an interim record. > > There is some logic to this. However, in practice the > distinctions may not be so clean: > > a. Reauthentication: If you do reauthentication and get a new > set of attributes (this can happen in either Diameter or > RADIUS) do you have to check to see if the attributes change > to decide whether to send an Interim accounting update? If we restricted Reauthentication to just be reauthentication and don't allow the AAA to respond with attributes then the ambiquity (whether or not this is a re-authentication vs re-authenticaiton with potentially re-authorization) goes away. > > b. Re-authorization: When doing Diameter re-authorization or > RFC 3576 CoA, do we start a new session in all cases? Does it > matter who initiated the re-authorization (NAS or AAA server)? > I think in general the answer must be yes. However, since this could generate lots of unnecessary traffic perhaps we leave it up to the protocol designer to specify what happens when a COA message is sent or when an Access Request with Authorize Only message is sent. For example in prepaid we use Access Request with Authorize Only and the Access Accept with Authorize Only to tranpsort prepaid quota. This mechanism is used to refresh prepaid and really doesn't need change the service. It probably doesn't need to be recorded either. So there is no need to generate an Accounting message for this. If you look at the bandwidth draft. When we dynamically change the bandwidth we want to generate an accounting stop for the old session and accounting start for the new session. This is because we are probably going to bill differently for the bytes sent at different bandwidth. From owner-aaa-wg@merit.edu Wed Apr 21 19:52:40 2004 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 TAA02112 for ; Wed, 21 Apr 2004 19:52:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C4D9291361; Wed, 21 Apr 2004 19:51:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6980F91344; Wed, 21 Apr 2004 19:51:06 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4CCBA9135F for ; Wed, 21 Apr 2004 19:50:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2ECF7589B5; Wed, 21 Apr 2004 19:50:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 29322589A6 for ; Wed, 21 Apr 2004 19:50:58 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id E68ED8985A; Thu, 22 Apr 2004 00:47:57 +0300 (EEST) Message-ID: <4086EB53.1070900@kolumbus.fi> Date: Thu, 22 Apr 2004 00:44:51 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue eap : Key Name AVP References: <009401c40185$8c642cf0$0300000a@amer.cisco.com> <4086601B.3040309@kolumbus.fi> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>o I think its fine to say that the exact use of >> the name information is link layer dependent. >> I take it that this means the client side? >> But I feel uneasy about defining an attribute >> unless we also specify how the server fills >> in the information. > > While the use of the name information may be link layer dependent, the > name itself is not. Since the name as defined in the EAP Key Framework is > dependent on the EAP method, the server obtains the name from the method. Ok. >>o We can expect the EAP Keying Framework document >> to specify this, perhaps, but then we create >> a dependency from this document to the EAP >> Keying Framework, which is likely ready later >> than this document (and is Informational). > > > I don't think a dependency is created merely by including an AVP for the > name. No, it would be created by stating that the contents of the AVP must conform to the rules dictated in [REF]. But I think what you are saying is that Diameter EAP states the name is obtained from the method, and then formal dependencies (if any) to EAP Keying Framework are in the methods. Is this correct? I didn't think of it this way initially, but it looks like a nice way to avoid the dependency! >>o Current systems do not use the key name for >> anything. > > > Actually, IEEE 802.11i does use the key name. However, the NAS can > calculate the relevant names from the keys themselves, so it doesn't need > it to be supplied by the AAA server. So I think that the name is Right. So the name derived by the method (as specified in EAP Keying) is currently not used, but another type of name derivation is used in 802.11. > only needed when it is requested by the NAS. Right. But if I understand this correctly, there'd be no NASes that would need this for current link layers -- of course this might change for future link layers or upgrades. >>o As you point out, there is no corresponding >> RADIUS attributes. This would imply that all >> Diameter clients would have to prepare for the >> possibility that they don't get this attribute, >> in case the server was RADIUS. Likewise all >> servers would have to prepare for the possibility >> that their attribute is stripped off by a Diameter >> to RADIUS gateway. So it seems hard to even >> consider relying on this information. > > > I think that these issues can be addressed by only sending the name in > a Response when the NAS includes a name AVP in the Request. Or by sending the name in any case. Either way, the parties have to prepare for the possibility that you don't get the AVP even if you wanted to due to (a) translation to RADIUS or (b) server not supporting key names. Of course, if its just Diameter EAP, we can make this mandatory for servers so that (b) is not an issue. RADIUS translation issue could be handled by allocating the AVP from RADIUS space, making it possible to send the name in RADIUS too. But then we still have to allow for case (b) to happen, as current servers may not support it. --Jari From owner-aaa-wg@merit.edu Thu Apr 22 07:25:11 2004 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 HAA18590 for ; Thu, 22 Apr 2004 07:25:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 52B8091242; Thu, 22 Apr 2004 07:24:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A16691243; Thu, 22 Apr 2004 07:24:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D228391242 for ; Thu, 22 Apr 2004 07:24:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BC39A589D5; Thu, 22 Apr 2004 07:24:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 1C87C589C3 for ; Thu, 22 Apr 2004 07:24:55 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id DB4EE89819; Thu, 22 Apr 2004 14:24:53 +0300 (EEST) Message-ID: <4087AACB.2050609@kolumbus.fi> Date: Thu, 22 Apr 2004 14:21:47 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue eap : Key Name AVP References: <009401c40185$8c642cf0$0300000a@amer.cisco.com> <4086601B.3040309@kolumbus.fi> <4086EB53.1070900@kolumbus.fi> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Today's RADIUS NASen won't ask for a key name. Therefore a > RADIUS/Diameter gateway won't send a Request with a Key-Name AVP and the > Diameter server won't send one. So there is no compatibility problem > there. Right. > A future Diameter NAS might or might not ask for a key name. If it > doesn't ask, then there is no issue either with a Diameter Server or > a RADIUS server to whom it talks via a RADIUS/Diameter gateway. Yes. > If it asks for a key name, and it's talking to a Diameter Server, things > will work. If it's talking to a RADIUS server and asks for a key name, > then the Diameter/RADIUS gateway would need a RADIUS key-name attribute to > translate to. If there is no such attribute, then the key-name attribute > wouldn't be received. But presumably for that case, the Diameter NAS > would need to be deployed along with compatible RADIUS servers. So I > don't see an issue there either. You are right. I guess my question at this point is whether Diameter EAP needs to allocate the name AVP from the Diameter or RADIUS space. It seems like it should be allocated from the RADIUS space, so that translation the "compatible RADIUS server" has a standard attribute to use on the RADIUS side. If you and others agree, I think this results in the following modifications of Diameter EAP: 1. Add a key name AVP section 2. Make it appear 0-1 times in both the request and response. 3. Explain that the server should return the AVP in response if it was present in the request. 4. Explain that the contents come from EAP methods (add informative reference to EAP keying). 5. Use a RADIUS number space for the attribute number. --Jari From owner-aaa-wg@merit.edu Thu Apr 22 10:47:00 2004 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 KAA01584 for ; Thu, 22 Apr 2004 10:47:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C7F369136C; Thu, 22 Apr 2004 10:43:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F4E69136A; Thu, 22 Apr 2004 10:43:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E8A1091364 for ; Thu, 22 Apr 2004 10:43:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D43C858A43; Thu, 22 Apr 2004 10:43:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 26ACB58A3C for ; Thu, 22 Apr 2004 10:43:25 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i3MEmmu17661; Thu, 22 Apr 2004 07:48:48 -0700 Date: Thu, 22 Apr 2004 07:48:48 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue eap : Key Name AVP In-Reply-To: <4087AACB.2050609@kolumbus.fi> Message-ID: References: <009401c40185$8c642cf0$0300000a@amer.cisco.com> <4086601B.3040309@kolumbus.fi> <4086EB53.1070900@kolumbus.fi> <4087AACB.2050609@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > You are right. I guess my question at this point is whether > Diameter EAP needs to allocate the name AVP from the Diameter > or RADIUS space. It seems like it should be allocated from > the RADIUS space, so that translation the "compatible RADIUS > server" has a standard attribute to use on the RADIUS side. > > If you and others agree, I think this results in the following > modifications of Diameter EAP: > > 1. Add a key name AVP section > 2. Make it appear 0-1 times in both the request and response. > 3. Explain that the server should return the AVP in response > if it was present in the request. > 4. Explain that the contents come from EAP methods (add > informative reference to EAP keying). > 5. Use a RADIUS number space for the attribute number. Yes, I think this will work. From owner-aaa-wg@merit.edu Thu Apr 22 12:58:43 2004 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 MAA10434 for ; Thu, 22 Apr 2004 12:58:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3EBC491244; Thu, 22 Apr 2004 12:58:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 124929136A; Thu, 22 Apr 2004 12:58:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F26B491244 for ; Thu, 22 Apr 2004 12:58:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E006358982; Thu, 22 Apr 2004 12:58:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ACONCAGUA.com (ool-18e43d83.dyn.optonline.net [24.228.61.131]) by segue.merit.edu (Postfix) with SMTP id 4A16158A2A for ; Thu, 22 Apr 2004 12:58:29 -0400 (EDT) Date: Thu, 22 Apr 2004 11:40:55 -0500 To: aaa-wg@merit.edu Subject: [AAA-WG]: Re: Hello From: david.kessens@nokia.com Message-ID: MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit From owner-aaa-wg@merit.edu Thu Apr 22 14:01:09 2004 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 OAA14575 for ; Thu, 22 Apr 2004 14:01:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8EE589136E; Thu, 22 Apr 2004 14:00:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67A4C91372; Thu, 22 Apr 2004 14:00:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 66FFC9136E for ; Thu, 22 Apr 2004 14:00:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3F427589FC; Thu, 22 Apr 2004 14:00:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ACONCAGUA.org (ool-18e43d83.dyn.optonline.net [24.228.61.131]) by segue.merit.edu (Postfix) with SMTP id CCE47589EB for ; Thu, 22 Apr 2004 14:00:22 -0400 (EDT) Date: Thu, 22 Apr 2004 13:44:03 -0500 To: aaa-wg@merit.edu Subject: [AAA-WG]: Site changes From: david.kessens@nokia.com Message-ID: MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit From owner-aaa-wg@merit.edu Sat Apr 24 12:49:58 2004 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 MAA23213 for ; Sat, 24 Apr 2004 12:49:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 806CB9126C; Sat, 24 Apr 2004 12:49:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 45E8491252; Sat, 24 Apr 2004 12:49:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D0B2691249 for ; Sat, 24 Apr 2004 12:49:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB13658B68; Sat, 24 Apr 2004 12:49:25 -0400 (EDT) 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 6E6235888D for ; Sat, 24 Apr 2004 12:49:25 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3OGnA903569; Sat, 24 Apr 2004 11:49:11 -0500 (CDT) Received: from zrc2c012.us.nortel.com ([47.103.120.52]) by zrc2c011.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCQA12R3; Sat, 24 Apr 2004 11:49:10 -0500 Received: from nortelnetworks.com (BLUETICK [47.102.176.64]) by zrc2c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JRJR3BG3; Sat, 24 Apr 2004 11:49:10 -0500 Message-ID: <408A9A78.1040403@nortelnetworks.com> Date: Sat, 24 Apr 2004 16:48:56 +0000 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Joe Harvell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Leena Mattila (TU/LMF)" Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: interaction of DCC failover procedures with AAATrans transport failure detection failover action 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 Leena: Thanks for your response. I need some more clarification on Section 5.7 in draft 4. I have included my questions inline below. Could you please provide answers? Also, I have tried to piece together some pseudocode describing how this works based on my current understanding. Could you please look over this and verify my understanding is correct? First, here is an excerpt from Section 5.7 along with my inline questions. > If the Credit-Control-Failure-Handling AVP is set to the value > CONTINUE or RETRY_AND_TERMINATE, the service will be granted to the > end user upon the timer Tx expires. An answer message with granted- > units may arrive later on due to the base protocol transport failover > occurred in the path to the Credit Control Server (Twinit default > value is 3 times more than the Tx recommended value). The credit > control client SHOULD grant the service to the end user, start > monitoring the resource usage and wait for the possible late answer > until the timeout of the request (e.g. 120 seconds). [JH]: So what timer detects the "timeout of the request"? Is this an implementation defined timer not mentioned elsewhere in the spec along with a recommended value? Is the "timeout of the request" you mention here a transport failure detection of the transport connection on which the request is pending? I am assuming that this is not Tx since Tx already expired. If this is the case, why don't the state machines in section 7 reference any event associated with this timer expiring. Please explain. > If the request > fails and the CC-Session-Failover AVP is set to FAILOVER_NOT > SUPPORTED, the credit control client terminates or continues the > service depending on the value set in the CCFH and MUST free all the > reserved resources for the credit control session. [JH]: The action to be taken matches with the behavior for "Failed CC initial answer received" event in the state machine in Section 7. In this context, "Failed answer" refers to an answer received with Permanent Error type result code. Is that what you mean here by "the request fails"? Or are you actually describing what action is taken when "the possible late answer" described above does not arrive before "the timeout of the request" as mentioned above? If a protocol error > DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is received or the > request timeout and the CC-Session-Failover AVP is set to FAILOVER > SUPPORTED, the credit control client MAY send the request to a backup > server if possible. [JH]: You already indicated in your previous email that "the request timeout" described directly above refers to a transport failure detection for the connection on which the request is pending. If the credit control client receives a successful > answer from the backup server, it continues the credit control session > with such a server. If also the re-transmitted request fails, the > credit control client terminates or continues the service depending on > the value set in the CCFH and MUST free all the reserved resources for > the credit control session. [JH]: I assume the meaning of "also the re-transmitted request fails" is the same as the meaning of "If the request fails" that I asked about above? If not, please explain this, too. Now, here is my pseudocode describing failure procedures as I understand them now: Here are the events that can happen to a pending request: * Failure to Send to Selected Peer---The selected peer is unavailable as determined by Diameter Base Transport Failure Mechanism * Failure to Send---Neither selected peer nor alternate peer is available. * Temporary Error---Client receives one of the following Protocol Error notifications o DIAMETER_TOO_BUSY o DIAMETER_UNABLE_TO_DELIVER + Note: Above notification is generated locally when a peer fails for each request pending with destination host equal to that peer o DIAMETER_LOOP_DETECTED * Permanent Failure o DIAMETER_RATING_FAILED o DIAMETER_AVP_UNSUPPORTED o DIAMETER_UNKNOWN_SESSION_ID o DIAMETER_AUTHORIZATION_REJECTED o DIAMETER_INVALID_AVP_VALUE o DIAMETER_MISSING_AVP o DIAMETER_RESOURCES_EXHAUSTED + Note: Above error is not expected to be used by a DCC application. o DIAMETER_CONTRADICTING_AVPS o DIAMETER_AVP_NOT_ALLOWED o DIAMETER_AVP_OCCURS_TOO_MANY_TIMES o DIAMETER_NO_COMMON_APPLICATION o DIAMETER_UNSUPPORTED_VERSION o DIAMETER_UNABLE_TO_COMPLY o DIAMETER_INVALID_BIT_IN_HEADER o DIAMETER_INVALID_AVP_LENGTH o DIAMETER_INVALID_MESSAGE_LENGTH o DIAMETER_INVALID_AVP_BIT_COMBO o DIAMETER_NO_COMMON_SECURITY * Tx expiry * Transport Failure Detected Failure to Send to Selected Peer or Temporary Error: if(!retransmitted && (CCR(I) || CC-Session-Failover==SUPPORTED) && alternate peer available) { send to alternate peer } else { raise Failure to Send (see below) } Failure to Send or Permanent Failure: if(CCFH==CONTINUE) { Grant Prepaid request and never talk to the Prepaid Server again. (This implies no prepaid resource limits from now on). } else { Terminate GTP context. } Tx Expiry: if(CCFH==TERMINATE) { Terminate GTP context } else { Grant prepaid request } Transport Failure Detected (logic executed for each pending request): if(dstHost in message == failed host) { raise Temporary Error (DIAMETER_UNABLE_TO_DELIVER) (follow logic described above for Temporary Error) } else { if(CCR(I) || CC-Session-Failover==SUPPORTED) { if(!retransmitted AND alternate peer available) { send to alternate peer } else { raise Failure To Send } } else { raise Failure To Send } } Leena Mattila (TU/LMF) wrote: > Hi Joe, > > see answers inline. > > BR, > Leena > > >>From: owner-aaa-wg@merit.edu >>[mailto:owner-aaa-wg@merit.edu]On Behalf Of >>Joe Harvell >>Sent: 14. tammikuuta 2004 2:42 >>To: aaa-wg@merit.edu >>Subject: [AAA-WG]: interaction of DCC failover procedures >>with AAATrans >>transport failure detection failover action >> >> >>Section 5.6 describes failover procedures for session based >>credit control. According to these procedures, the DCC >>client may retransmit the CCR to a backup server: >> >> If a protocol error DIAMETER_UNABLE_TO_DELIVER or >>DIAMETER_TOO_BUSY >> is received or the request timeout and the >>CC-Session-Failover AVP >> is set to FAILOVER SUPPORTED, the credit control client >>MAY send the >> request to a backup server if possible. >> >>However, according to section 5.5.3 of the Diameter Base >>Protocol requires the transport failure algorithm in AAATrans >>to be supported. This algorithm describes retransmitting >>pending requests to a backup server upon transport failure detection. >> >>Clearly the DCC client should not retransmit pending requests >>for sessions in which failover is not supported >>(CC-Session-Failover AVP indicates failover is not >>supported). But for pending requests for sessions in which >>failover is supported, should the Diameter client retransmit >>the request upon transport failure detection in addition to >>request timeout? > > The "request timeout" in the referred text means actually transport > failure. We thought that the DCC application will see the transport > layer failure as a Twinit timer expiry. It's the timer Twinit in > AAATrans that is meant here, not the timer Tx in the DCC. Maybe it's > only the wording that should be clarified here. So, Yes, the Diameter > client should re-transmit the request to a backup server upon transport > failure detection. > >>Also, I would like clarification on interaction of transport >>failure initiated failover (AAATrans) and Diameter Credit >>Control's session based failover procedures for pending CCRs >>of CC-Request-Type First Interrogation. My understanding is >>that CCRs of the first interrogation would include the >>Destination-Realm AVP but not the destination host AVP (as >>suggested by section 6.1 of Diameter Base Protocol). > > Yes, this is correct. But I think it is also possible to address > a certain host directly already in the First Interrogation, given > that the Diameter client has the address of the server available, > e.g. preconfigured in the node or received from the AA(A) server. > > >>Furthermore CCRs of type other than First Interrogation would >>contain both Destination-Realm and Destination-Host AVPs. >>This means that when transport failure is detected by the >>Credit Control Client, all pending CCRs of type First >>Interrogation would be immediately sent to an available >>backup server regardless of any CC-Session-Failover >>configuration. > > Yes, in case of First Interrogation it does not really matter > whether the server or client supports failover since no session > state has been established yet in the server. It's the state > transfer between the primary and the secondary server that is > considered to be (on of) the tricky part(s) and why some servers > might not support failover. > > >>The other pending CCRs would not be >>forwardable to a backup server according to section 5.5.5 of >>Diameter Base Protocol, since the Destination-Host AVP must >>have identified the failed host. However, these pending requests >>would actually be retransmitted if session failover is >>supported according to the rules in Section 5.6 of Diameter >>Credit Control Application. My reasoning is that the pending >>Diameter request is internally failed with >>DIAMETER_UNABLE_TO_DELIVER according to Diameter Base >>Protocol 5.5.4, which triggers the session failover described >>in section 5.6 of Diameter Credit Control Application. >> >>Is this an accurate description of the Diameter Credit >>Control client behavior upon transport failure detection? Is >>my reasoning correct? > > Yes, your understanding is correct. > > >>--- >>Joe Harvell >>Shasta GGSN Development >>Nortel Networks >>+1 972.685.4886 >> From owner-aaa-wg@merit.edu Sat Apr 24 12:55:03 2004 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 MAA23392 for ; Sat, 24 Apr 2004 12:55:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EC99791247; Sat, 24 Apr 2004 12:54:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B206A91249; Sat, 24 Apr 2004 12:54:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 89AB391247 for ; Sat, 24 Apr 2004 12:54:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7794B58C49; Sat, 24 Apr 2004 12:54:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from dingo.dogpad.net (dingo.dogpad.net [65.70.180.33]) by segue.merit.edu (Postfix) with ESMTP id 29E6558C60 for ; Sat, 24 Apr 2004 12:54:49 -0400 (EDT) Received: from dogpad.net (localhost [127.0.0.1]) by dingo.dogpad.net (Postfix) with ESMTP id 629F97802F for ; Sat, 24 Apr 2004 11:54:48 -0500 (CDT) Message-ID: <408A9BD8.6080300@dogpad.net> Date: Sat, 24 Apr 2004 11:54:48 -0500 From: Joseph Harvell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter Peer State Machine problem 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 Section 5.6 of RFC 3588 indicates that the state machine described therein is closely coupled with the Watchdog Algorithm state machine in RFC 3539. However, the 3588 state machine doesn't explicitly include the behavior of suspending and reopening connections. From this I infer that my implementation must implement a state machine that is synthesized from the sate machines in 3588 and 3539. Most of this is obvious, but there are a couple of points I am unsure of: 1. When re-opening a connection, do I send the CER before or after receiving the three successive DWAs? 2. When I am in the REOPEN state and I receive any message that is not a DWA, 3539 says I should throw it away. Does this include a DWR? If so, are both sides of the connection implementing the same logic? (If so, I think REOPEN->OKAY would never happen for either). From owner-aaa-wg@merit.edu Mon Apr 26 03:54:04 2004 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 DAA00792 for ; Mon, 26 Apr 2004 03:54:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 25B9191226; Mon, 26 Apr 2004 03:53:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D956691277; Mon, 26 Apr 2004 03:53:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 75FDD91226 for ; Mon, 26 Apr 2004 03:53:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5C4FD58D51; Mon, 26 Apr 2004 03:53:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 6BEFF58D5F for ; Mon, 26 Apr 2004 03:53:49 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3Q7raB26089; Mon, 26 Apr 2004 10:53:36 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 10:51:12 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3Q7pC27005053; Mon, 26 Apr 2004 10:51:12 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00Tm189o; Mon, 26 Apr 2004 10:51:10 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3Q7p4F19795; Mon, 26 Apr 2004 10:51:04 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 10:50:57 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: interaction of DCC failover procedures with AAATrans transport failure detection failover action x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 26 Apr 2004 10:50:56 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0523@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: interaction of DCC failover procedures with AAATrans transport failure detection failover action Thread-Index: AcQqHDpn0CBYtRSIRTWxUT+ITjbyMwBPp9rg From: To: Cc: , X-OriginalArrivalTime: 26 Apr 2004 07:50:57.0194 (UTC) FILETIME=[3576A0A0:01C42B63] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Joe, I have just few comments to some of your questions I leave Leena to = answer in more deep detail. Regards Marco >So what timer detects the "timeout of the request"?=20 The "timeout of the request" is indicated in the "Failure to send" event listed in the state machine, I copied here its definition. In the state table, the event 'Failure to send' means that the=20 Diameter credit-control client is unable to communicate with the=20 desired destination or with a possibly defined alternative = destination=20 in case failover procedure is supported (e.g. the request timeout and = the answer message is not received). This could be due to the peer=20 being down, or due to a physical link failure in the path to/from the = credit-control server. Your client implementation may supervise the pending request with an = implementation dependant timer, we didn't exclude this possibility (note: this is not = Tx). I mean, in the remote possibility that the transport is OK but you never = get an answer I guess you won't keep the request for ever in the pending queue. = For instance, in the Diameter API draft (not existent anymore) there was the option = for an application to set the timeout of its generated requests to the base. >I assume the meaning of "also the re-transmitted=20 > request fails"=20 > is the same as the meaning of "If the request fails" that I=20 > asked about=20 > above? Yes, the meaning is the same. You send a request to server-A, if you get = a "Failure to send" or "Temporary error" (i.e. the request fails) and the = failover=20 is supported you may re-send to Server-B. if you get a "Failure to send" = or=20 "Temporary error" or "Failed answer" to the re-transmitted request=20 (i.e. also the re-transmitted request fails) then you take an action = according the value of CCFH. Of course if you would get a "Failed answer" already the first time you = send the request, you won't re-send that request. > > If the request > > fails and the CC-Session-Failover AVP is set to FAILOVER_NOT > > SUPPORTED, the credit control client terminates or continues the > > service depending on the value set in the CCFH and MUST free all the > > reserved resources for the credit control session. Request fails in this context means that for any type of error you take = an action according to the CCFH value. This is because failover to an = alternate server is not supported. From owner-aaa-wg@merit.edu Tue Apr 27 04:03:04 2004 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 EAA12544 for ; Tue, 27 Apr 2004 04:03:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 295249123E; Tue, 27 Apr 2004 04:02:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED20D91240; Tue, 27 Apr 2004 04:02:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 389619123E for ; Tue, 27 Apr 2004 04:02:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1A9D4589A6; Tue, 27 Apr 2004 04:02:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id C75EA58B0A for ; Tue, 27 Apr 2004 04:02:46 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R82cv17822 for ; Tue, 27 Apr 2004 11:02:38 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 10:57:53 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3R7vrvd021408 for ; Tue, 27 Apr 2004 10:57:53 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00VP7fPv; Tue, 27 Apr 2004 10:57:52 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R7vkF04742 for ; Tue, 27 Apr 2004 10:57:46 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 10:57:50 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: FW: AD review: draft-ietf-aaa-diameter-cc-04.txt Date: Tue, 27 Apr 2004 10:57:50 +0300 Message-ID: Thread-Topic: AD review: draft-ietf-aaa-diameter-cc-04.txt Thread-Index: AcQrnvRbUi00Zk70TJ6av6i7bcgC7AAjj/Fg From: To: X-OriginalArrivalTime: 27 Apr 2004 07:57:50.0682 (UTC) FILETIME=[5655A3A0:01C42C2D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, Here is the results of the AD review. The authors will try to address the technical comments on the list & start working on the editorial issues. John > > > One thing I did notice in various ABNF specifications in sect 8 > > > is that you use curly and sqaure brackets seemingly at will. > > > Not sure if that is correct... you may want to check. > > > It occurs quite a number of times. > > >=20 > OK, I think I now see that it comes from the base diameter spec when=20 > <..> fixed AVP spec positions > {..} are required AVP specs > [..] are optional AVP specs >=20 > So.. probably this is known/obvious for people who do AAA=20 > every day. For > the not so AAA-adicted, it might be good to repeat that sort of info > somehwere in the beginning of the doc, or maybe to add a=20 > reference about > this that it is additional ABNF notation on top of that in RFC3588? >=20 > > > Is it OK if I type up those nits later this week? > >=20 > > Sure, shall we do a quick rev before submitting to the IESG? > >=20 > So here are my little nits and such: >=20 > First some things I worried/wondered about: >=20 > a. Sect 5.1.1 made we wonder if we really need this type of=20 > complexity? >=20 > b. On page 23/24 (possibly at other places too), I see=20 > several terms used > like these: > - home Diameter AAA server > - home AAA server > - home AAA > - Diameter AAA server > - Diameter home AAA (sect 5.7 and sect 6.5) > - AAA server (sect 6.5) > - ... > Do they all mean the same server? Maybe not. But are ther=20 > 4 different types? > Pls try to be very consistent when using those terms. >=20 > c.Sect 5.5 2nd para. > (sub-)session level, credit pool level granularity,=20 > service-identifier > level granularity or rating-group granularity. To request=20 > credit re- > authorization at credit pool granularity the server=20 > includes in the > RAR message the G-S-U-Pool-Identifier AVP indicating the affected > How are sub-sessions and various other "levels"=20 > defined/identified/known? > Maybe I missed that in the doc... Mmm.. you refer to sect=20 > 5.1.1 but some > of the explanation may be in sect 5.1 > Mmm.. I see that that sect 5.1.1 is also the section that=20 > made my eyes glaze=20 > over and wonder if all that compelxity is needed. >=20 > d. On page 30... I started wondering... Mmmm there are a lot=20 > of "may" cases > here. How will all the "may"-behaviour interoperate. Maybe just me. >=20 > e. Page 36 talks about "AAA server or agent" I guess server=20 > and agent are > meant to be synonyms here? Are they? Why are we confiusing=20 > people here? >=20 > f. Page 36/37 talks about "increased risk of premature=20 > failover" and about > "congestive collapse". Maybe those risks should be spelled out in > security considerations? In any event it seems quite=20 > hidden to me the > way it is described in a long piece of text. >=20 > g. Have the state-diagrams been checked rigorously? > For example, page 46. the 3rd and 4th cases, should the=20 > also not be a > Stop Tx action? Also for 7th, 8th, 9th and 10th case on that page? > I wondered about such things at other places in the state=20 > diagrams too. >=20 > h. User-Equipment-Info-Type AVP is defined as Unsigned32.=20 > I wonder if the type would not better be Enumerated >=20 > i. I see that various of your Enumerated datatypes start the list of > enumerations at zero. Is that wise? In the SMI we tend to=20 > start at 1. The=20 > reason is that zero is often just an value that is there=20 > after clean memory > has been obtained and while no one has yet initiated the=20 > field. I can live > with it, just wanted to point it out. >=20 > j. I am surprised to see a Unsigned64 to ideintify=20 > subsessions. Do we really > believe there will be that many? I can live with it... but ?? >=20 > k. Section 8.28 in the examples, pls do NOT use "provider.com" and > "vendor.com". RFC2606 prescribes to use names like=20 > "provider.example.com" > and "vendor.example.net" or some such. >=20 > l. Section 8.46=20 > Is it SIP URL in this case, while it is SIP URI in sect 8.38? >=20 > m. I am confused by the AVPs defined in Sect 8.49 and 8.50 > 8.49 defines various types. Is the formatting of those values > indeed such that they are UTF-8 ? I have not checked. May I assume > that someone DID check/verify? >=20 > n. I assume Bernard (or some RADIUS/DIAMETER expert has=20 > checked sect 11 >=20 > o. In the IANA considerations you state many times "this specification > assigns xxx".=20 > - first, I suspect that IANA should officially do the assignment. > so it would have been better to say something aka: > "Iana has assigned xxx" If you want a specific value, you can=20 > ask IANA to use value xxx. > - second, I suspect that IANA needs to add the values to=20 > the registries > on their web pages. You do never tell IANA that they=20 > indeed need to do > that=20 >=20 > p. Security considerations. > You claim that DIAMBASE not only tells/assume that IPsec=20 > or TLS are used. > But DIAMBASE in fact REQUIRES (MUST language) the=20 > implementation of IPsec > and even explains how to do it (which is important). Same for TLS. >=20 > Second section uses lower case must/shall where I think=20 > uppercase MUST/SHALL > would be appropriate. I also suspect that the last sentence of 2nd > para may worry/bother security ADs. >=20 > 3rd para: "economical consequences" ?? DO you mean "financial" ?? >=20 > last 2 paragraphs in sect 14 seem weak to me. WOnder what=20 > sec ADs have to say >=20 > sect 14.1 talks about "agent"... is that same as "server"? > It also talks about "Diameter Routing Table" ... has that=20 > term been explained? > Last para in sect 14.1 points to an informative reference? >=20 > I would recommend to have one of the secuirty ADs take a=20 > look at this. >=20 > q. I wonder if references to documents that are cited in=20 > sections 8.x should > not all be normative. For example, [RAD802.1X] is=20 > normative (correctly > in my view), but [SIP] is informative (incorrectly in my=20 > view). [IPv4] > and [IPv6Addr] seem normative to me too? >=20 > I have not checked the appendices. >=20 > --------- >=20 > Following are mainly nits/admin things: >=20 > 1. Results if idnits script. Just check, not all of it means error. > But non-ASCII characters is not good. The long lines=20 > can/will probably > be hadnled by RFC-Editor. But if you can fix it, so much=20 > the better. > This idnits tool is available at:=20 > http://ietf.levkowetz.com/tools/idnits/ > $ idnits idnits 1.26, (21 Apr 2004) >=20 > The document seems to use RFC 2026 boilerplate... > The document seems to lack an RFC 2026 Section 10.4(C)=20 > Permission Grants Notice > -- however, there's a paragraph with a matching=20 > beginning. Boilerplate error? > There are 298 instances of too long lines in the document, > -- the longest one being 1 character in excess of 72. > Line 1447 contains non-ascii character in position 37. > Line 3852 contains non-ascii character in position 49. > Line 5336 contains non-ascii character in position 39. > Line 5353 contains non-ascii character in position 51. > There are 4 instances of lines with non-ascii characters=20 > in the document. >=20 > Warnings: > The document seems to lack an RFC 2026 Section 10.4(B)=20 > IPR Disclosure Invitation > There are 178 instances of lines with hyphenated line=20 > breaks in the document. >=20 > Line 2285 has weird spacing: '...quested to en...' > Line 2295 has weird spacing: '...mporary end ...' > Line 4755 has weird spacing: '...session for s...' >=20 > 2.In the abstract, pls expand the SIP acronym >=20 > 3.In the body of the document, pls expand the acronyms when=20 > used for the > first time >=20 > 4.One but last para of sect 1 states: > To fulfill these requirements, it is necessary to facilitate > communication between the network element providing the=20 > service (e.g. > NAS, SIP Proxy, Application Server etc.) and a=20 > credit-control server. > That seems to say that this doc does much more than what we=20 > see in the abstract >=20 > 5.Last para of sect 1.2, 2nd line: s/intermediates/intermediate/ >=20 > 6.Sect 1.3 talks about a value of "4" for Auth-Application-Id. > Is that already assigned? If not we should list in IANA=20 > considerations sect. > Aha, I see it is in IANA considerations. So it should=20 > really be a TBA instead > of pre-assuming it will get value 4 assigned by IANA. >=20 > Same question in sect 3.1 and possibly at some more places >=20 > 7.Seect 3. Where are those code points for CCR and CCA defined? > In this doc? Then we need IANA considereations. In fact, maybe the > doc should say TBA-by-IANA instead if this is the case, because > I see it in IANA considerations. >=20 > 8.Bottom page13 and top of page14. Is this another form of=20 > (implicit) subtyping? >=20 > 9.Sect 5.1 4 para 2 but last line > s/the closing the/closing the/ >=20 > 10.When I see things like on page 18: > Where multiple G-S-U-Pool-Reference AVPs with the same=20 > G-S-U-Pool- > Identifier are provided within a=20 > Multiple-Services-Credit-Control AVP > Then I wonder if a ptr to where those AVPs are defined woul not be > useful/helpful. > Same for things like: > RECOMMENDED that Diameter credit-control clients=20 > maintain a PENDING-U > message queue and restarts the Tx timer every time a CCR[Update] >=20 > 11.Let me also point out that the notaion CCR[Update] in the text > cam make people think that [Update] is a citation. I bet=20 > the RFC-Editor > will not be happy with that. It occurs several times. >=20 > 12.Top of page 20=20 > the concerned service. Additional service event=20 > information to be > rated MAY be sent as service specific AVPs or MAY be=20 > sent within the > Service-Parameter-Info AVP at command level. > So is it the server or the client who "MAY" send this? > And why is the Upper case MAY?=20 >=20 > 13.Somewhat towrds the bottom of page 20 (3rd pare from bottom) I see: > There MUST be maximum one instance of the same unit type=20 > in one Answer > message. However, in case multiple quotas are conveyed=20 > to the credit > control client in the Multiple-Services-Credit-Control=20 > AVPs, it is > possible to carry two instances of the same unit type=20 > associated to a > service-identifier/rating-group for instance when a=20 > tariff time change > is expected. > Is that good english? Is the last one really a sentence? > I have a hard time understanding what it says >=20 > 14.Top of page 21: > Two different approaches are defined for the first=20 > interrogation to > suit properly in all the possible architectures. The=20 > first approach > Again... is that a sentence? And if so what does it mean? >=20 > 15. 2nd line page 23 > s/contribute/co-operate/ ?? >=20 > 16. Page 24, 1st para, one but last line. > Talks about setting a value to 1 (for an "intermediate request". > and referes to sect 8.2 > But sect 82. does not talk about "intermediate" requests.=20 > I guess that > the UPDATE-REQUESTS are intermendiate... but that is not=20 > immediately clear. >=20 > 17.Sect 5.5 talks about value 4 for RAR messages. See my=20 > earlier comment > on that value. >=20 > 18. Sect 5.6 talks about "top-up". I probably can guess what=20 > it means. But maybe > it is better to explain it. >=20 > 19.first para sect 5.6.2, last word: s/follow/follows/ >=20 > 20.Page 36 talks about "timer Twinit". Might want to explain=20 > what it is. > Possibly also for timers Tx and Tcc >=20 > 21. Page 52 2nd case. I think under action column, you want=20 > to s/=3D!/!=3D/ ?? >=20 > 22. Table on page 54/55.. WOuld it not be good to explain=20 > what codes M, P, V > and Y mean? >=20 > 23. Page 65 towards bottom > s/has been occurred/has occurred/ > =20 > 24. Sect 8.32 > s/enumerated/Enumerated/ >=20 > 25. Sect 8.33=20 > Validity-Time in seconds. But since when? Since the AVP=20 > is received by the > Client?=20 >=20 > 26. Top of page 85 > s/kind threat/kind of threat/ >=20 > Bert >=20 From owner-aaa-wg@merit.edu Tue Apr 27 06:53:36 2004 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 GAA21789 for ; Tue, 27 Apr 2004 06:53:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3BC3D9126A; Tue, 27 Apr 2004 06:53:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0748591278; Tue, 27 Apr 2004 06:53:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CF0239126A for ; Tue, 27 Apr 2004 06:53:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE2A758B3B; Tue, 27 Apr 2004 06:53:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id CD85958A34 for ; Tue, 27 Apr 2004 06:53:21 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RArKv14108; Tue, 27 Apr 2004 13:53:20 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 13:52:24 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3RAqOOP011828; Tue, 27 Apr 2004 13:52:24 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00OQCsqn; Tue, 27 Apr 2004 13:40:57 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RAepH25060; Tue, 27 Apr 2004 13:40:51 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 13:40:30 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: meaning of PXY in the ABNF (P-bit) Date: Tue, 27 Apr 2004 13:40:30 +0300 Message-ID: Thread-Topic: [AAA-WG]: meaning of PXY in the ABNF (P-bit) Thread-Index: AcQmwkZXkH4xmuZkSJ2nLBh2i0xNpQFgY0Nw From: To: , X-OriginalArrivalTime: 27 Apr 2004 10:40:30.0651 (UTC) FILETIME=[0FBAB8B0:01C42C44] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Johan, > Most Diameter commands contain the PXY-keyword in the ABNF spec, = meaning=20 > "if present, the 'P' bit in the Command Flags is set, indicating that=20 > the message is proxiable". >=20 > But does this mean that the P-bit is required in every occurence of = this=20 > command-code ? What if we take a command that is normally proxiable, = but=20 > doesn't carries the P-bit. I guess that most Diameter implementations=20 > will try to process it locally (if it succeeds depends on the=20 > Destination-Realm and/or Destination-Host ofcourse). But if a Diameter = > implementation is particular pedantic, and knows from the ABNF (or the = > XML-definition) that the P-bit should be present, it might send an = error=20 > back with the DIAMETER_INVALID_HDR_BITS result-code. The P-bit should be per message. So a specific message without the = p-bit set would not be proxiable. An implementation that was pendatntic about = requiring the p-bit to be set would be, imo, incorrect. John =20 > Which would be correct ? In my opinion, we should be able to clear out = > out the P-bit from a command that is normally proxiable, when we want = to=20 > insist that a request should stay local. Ofcourse, the sender would=20 > still be responsible for correct Destination-Realm and/or=20 > Destination-Host values, to be sure that it would be really possible = to=20 > process it locally, otherwise it would get a = DIAMETER_UNABLE_TO_DELIVER=20 > back. >=20 > --=20 > Jo Hermans >=20 >=20 From owner-aaa-wg@merit.edu Tue Apr 27 07:00:02 2004 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 HAA22056 for ; Tue, 27 Apr 2004 07:00:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B6A739127A; Tue, 27 Apr 2004 06:59:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C0BB9127B; Tue, 27 Apr 2004 06:59:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E05D39127A for ; Tue, 27 Apr 2004 06:59:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CE87A58AFF; Tue, 27 Apr 2004 06:59:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id BFE5958BE3 for ; Tue, 27 Apr 2004 06:59:46 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RAxiv22473; Tue, 27 Apr 2004 13:59:44 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 13:53:07 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3RAr7V7012937; Tue, 27 Apr 2004 13:53:07 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00XPzpOz; Tue, 27 Apr 2004 13:41:50 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RAfiH25608; Tue, 27 Apr 2004 13:41:44 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 13:41:43 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 13:41:42 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: DCC Issue: Radius-Diameter CC Interworking model Date: Tue, 27 Apr 2004 13:41:43 +0300 Message-ID: Thread-Topic: [AAA-WG]: DCC Issue: Radius-Diameter CC Interworking model Thread-Index: AcQnjRJsC5JAfRlDQDSuOebkICMzCwEtySiw From: To: , X-OriginalArrivalTime: 27 Apr 2004 10:41:42.0778 (UTC) FILETIME=[3AB86DA0:01C42C44] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable assigned issue 33. > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Harri Hakala (JO/LMF) > Sent: 21 April, 2004 13:32 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: DCC Issue: Radius-Diameter CC Interworking model >=20 >=20 >=20 > Submitter name: Harri Hakala > Submitter email address: harri.hakala@ericsson.com > Date first submitted: 21.04.2004 > Reference: > Document: DCC-04 > Comment type: T > Priority: 1 > Section: 11 > Rationale/Explanation of issue: > In the DDC-04 the RADIUS/Diameter credit control Interworking=20 > section is > incomplete. It leaves out a lot of important standardization=20 > details, but > on the other hands it is far too detail to be a just guideline. >=20 > A writing a true guideline section is problematic without=20 > having stable=20 > target document for translation. It would be better to=20 > describe RADIUS- > Diameter credit control interworking model in the DCC and the detailed > translation somewhere else, either in a separate I-D or in the RADIUS=20 > prepaid specification as discussed on the aaa-mailing list. > http://www.merit.edu/mail.archives/aaa-wg/msg00408.html > http://www.merit.edu/mail.archives/aaa-wg/msg00417.html >=20 > To describe this interworking model, the architecture model=20 > of section 2 > (figure 2) and related text as well as the flow II of the=20 > appendix can be > moved to a new section 11, RADIUS/Diameter Credit-control=20 > Interworking Model. >=20 > Requested Change: >=20 > REMOVE: >=20 > 1) Section 2 >=20 > Other entities, such as RADIUS AAA servers, may act as=20 > a Diameter credit-control=20 > clients for service elements that use credit control=20 > mechanisms other than Diameter > credit-control. In this case the AAA server contact the=20 > Diameter credit-control server > as part of the authorization process. The interworking=20 > architecture is illustrated in=20 > Figure 2, the interaction between the Diameter=20 > credit-control client and the service=20 > element is outside the scope of this specification.=20 > Interworking with RADIUS is addressed=20 > in section 11 and Annex A. >=20 > AAA > +--------+ +---------+ protocol =20 > +------------+ +--------+=20 > | End |<----->| Service |<------------>| AAA =20 > | |Business| > | User | | Element | | Server =20 > | |Support | > +--------+ +-->| | =20 > |+----------+|-->|System | > | +---------+ ||CC client=20 > || | | > | =20 > |+----------+| | | > +--------+ | =20 > +------^-----+ +--------+ > | End |<--+ credit-control | =20 > ^ > | User | protocol | =20 > | > +--------+ =20 > +-------V------+ | > =20 > |Credit-control|--------+ > | Server | > +--------------+ >=20 > Figure 2: Credit-control architecture with Service=20 > Element not=20 > supporting the credit-control protocol >=20 >=20 > 2) Flow II from appendix A >=20 > 3) the section 11 >=20 > ADD: > =20 > Section 11 RADIUS/Diameter Credit-control Interworking Model > =20 > This section defines the basic principles for the=20 > Diameter Credit-control/RADIUS prepaid inter-working model,=20 > that is a message translation between RADIUS based=20 > prepaid solution and Diameter Credit-control application.=20 > A complete description of the protocol translations=20 > between RADIUS and Diameter Credit-control application is > beyond the scope of this specification and SHOULD be=20 > addressed in another appropriate document such as the > RADIUS prepaid specification.=20 >=20 > The Diameter credit-control architecture may have a=20 > Translation Agent, which is capable of translation between > RADIUS prepaid and Diameter Credit-control protocol. An=20 > AAA server, usually the Home AAA server, may act as a=20 > Translation Agent while acting also as Diameter=20 > credit-control client for service elements that use credit=20 > control mechanisms other than Diameter credit-control,=20 > for instance RADIUS prepaid. In this case the AAA server > contacts the Diameter credit-control server as part of=20 > the authorization process. The interworking architecture > is illustrated in figure X and interworking flow in=20 > figure Y. In roaming situation the service element (e.g. the NAS) > may be located in the visited network and a Visited AAA=20 > server is usually contacted. The Visited AAA server=20 > connects then to the Home AAA server. > =20 > Radius prepaid > +--------+ +---------+ protocol =20 > +------------+ +--------+=20 > | End |<----->| Service |<------------>| Home AAA =20 > | |Business| > | User | | Element | | Server =20 > | |Support | > +--------+ +-->| | =20 > |+----------+|-->|System | > | +---------+ ||CC client=20 > || | | > | =20 > |+----------+| | | > +--------+ | =20 > +------^-----+ +--------+ > | End |<--+ credit-control | =20 > ^ > | User | protocol | =20 > | > +--------+ =20 > +-------V------+ | > =20 > |Credit-control|--------+ > | Server | > +--------------+ >=20 > Figure X: Credit-control architecture with Service Element=20 > containing translation agent, translating RADIUS=20 > prepaid to Diameter credit control protocol >=20 > When the AAA server acting as a Translation Agent=20 > receives an initial RADIUS Access-Request message from service > Element (e.g. NAS access), it performs regular=20 > Authentication and Authorization. If the RADIUS Access-Request message > indicates that the service element is capable of=20 > credit-control, and if the AAA server finds that the subscriber is a > prepaid subscriber then a Diameter Credit control=20 > request SHOULD be sent towards the credit-control server to perform=20 > credit authorization and to establish a credit control=20 > session. After the Diameter credit-control server checks the end > user's account balance, rates the service and reserves=20 > credit from the end user's account, the reserved quota is returned > to the Home AAA server in the Diameter=20 > Credit-Control-Answer. Then the Home AAA server sends the=20 > reserved quota to the=20 > service element in the RADIUS Access-Accept. > =20 > At the expiry of the allocated quota, the service element=20 > sends a new RADIUS Access-Request to the Home AAA server=20 > containing the units used this far. The AAA server shall map=20 > RADIUS Access-Request containing the reported units to the > Diameter credit-control server in a Diameter=20 > Credit-Control-Request (UPDATE_REQUEST). The Diameter=20 > credit-control server > debits the used units from the end user's account and=20 > allocates a new quota that is returned to the Home AAA server in the > Diameter Credit-Control-Answer. The quota is transferred to=20 > the service element in the RADIUS Access-Accept. When the end > user terminates the service or when all the quota has been=20 > used, the service element sends a RADIUS Access-Request. To debit > the used units from the end user's account and to stop the=20 > credit control session, the Home AAA server sends a Diameter=20 > Credit-Control-Request (TERMINATION_REQUEST) to the=20 > credit-control server. The Diameter credit-control server acknowledges > the session termination by sending a Diameter=20 > Credit-Control-Answer to the Home AAA server. The RADIUS=20 > Access-Accept is sent > to the NAS. > =20 > A following diagram illustrates a RADIUS prepaid -=20 > Diameter credit control interworking sequence. > =20 > =20 > Service Element Translation agent > (e.g.NAS) (CC Client) =20 > CC Server > | Access-Request | | > |----------------------->| | > | | CCR (initial) | > | |----------------------->| > | | CCA (granted_Units) | > | |<-----------------------| > | Access-Accept | | > | (granted Units) | | > |<-----------------------| | > : : : > | Access-Request | | > | (used Units) | | > |----------------------->| | > | | CCR (update, | > | | used Units, | > | |----------------------->| > | | CCA (granted_Units) | > | |<-----------------------| > | Access-Accept | | > | (granted Units) | | > |<-----------------------| | > : : : > | Access-Request | | > |----------------------->| | > | | CCR (termin., | > | | used Units) | > | |----------------------->| > | | CCA | > | |<-----------------------| > | Access-Accept | | > |<-----------------------| | > | | | > Figure Y: Message flow example with RADIUS=20 > prepaid - Diameter=20 > credit control interworking >=20 >=20 From owner-aaa-wg@merit.edu Tue Apr 27 07:22:08 2004 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 HAA22821 for ; Tue, 27 Apr 2004 07:22:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4DF919123F; Tue, 27 Apr 2004 07:21:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 178FB9127B; Tue, 27 Apr 2004 07:21:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5D4E59123F for ; Tue, 27 Apr 2004 07:21:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 41A0E58B0A; Tue, 27 Apr 2004 07:21:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 2535B58AB2 for ; Tue, 27 Apr 2004 07:21:51 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RBLov22974 for ; Tue, 27 Apr 2004 14:21:50 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 14:15:34 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3RBFYbR008038 for ; Tue, 27 Apr 2004 14:15:34 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00SyGjhW; Tue, 27 Apr 2004 14:01:39 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RB1cH09342 for ; Tue, 27 Apr 2004 14:01:38 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 14:01:39 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: FW: AD review: draft-ietf-aaa-diameter-cc-04.txt Date: Tue, 27 Apr 2004 14:01:39 +0300 Message-ID: Thread-Topic: AD review: draft-ietf-aaa-diameter-cc-04.txt Thread-Index: AcQrnvRbUi00Zk70TJ6av6i7bcgC7AAjj/FgAAZx4XA= From: To: , X-OriginalArrivalTime: 27 Apr 2004 11:01:39.0135 (UTC) FILETIME=[03CE04F0:01C42C47] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable This is assigned issue 34. >=20 > Here is the results of the AD review. The authors will try to address > the technical comments on the list & start working on the editorial > issues. >=20 > John >=20 >=20 >=20 > > > > One thing I did notice in various ABNF specifications in sect 8 > > > > is that you use curly and sqaure brackets seemingly at will. > > > > Not sure if that is correct... you may want to check. > > > > It occurs quite a number of times. > > > >=20 > > OK, I think I now see that it comes from the base diameter=20 > spec when=20 > > <..> fixed AVP spec positions > > {..} are required AVP specs > > [..] are optional AVP specs > >=20 > > So.. probably this is known/obvious for people who do AAA=20 > > every day. For > > the not so AAA-adicted, it might be good to repeat that sort of info > > somehwere in the beginning of the doc, or maybe to add a=20 > > reference about > > this that it is additional ABNF notation on top of that in RFC3588? > >=20 > > > > Is it OK if I type up those nits later this week? > > >=20 > > > Sure, shall we do a quick rev before submitting to the IESG? > > >=20 > > So here are my little nits and such: > >=20 > > First some things I worried/wondered about: > >=20 > > a. Sect 5.1.1 made we wonder if we really need this type of=20 > > complexity? > >=20 > > b. On page 23/24 (possibly at other places too), I see=20 > > several terms used > > like these: > > - home Diameter AAA server > > - home AAA server > > - home AAA > > - Diameter AAA server > > - Diameter home AAA (sect 5.7 and sect 6.5) > > - AAA server (sect 6.5) > > - ... > > Do they all mean the same server? Maybe not. But are ther=20 > > 4 different types? > > Pls try to be very consistent when using those terms. > >=20 > > c.Sect 5.5 2nd para. > > (sub-)session level, credit pool level granularity,=20 > > service-identifier > > level granularity or rating-group granularity. To request=20 > > credit re- > > authorization at credit pool granularity the server=20 > > includes in the > > RAR message the G-S-U-Pool-Identifier AVP indicating=20 > the affected > > How are sub-sessions and various other "levels"=20 > > defined/identified/known? > > Maybe I missed that in the doc... Mmm.. you refer to sect=20 > > 5.1.1 but some > > of the explanation may be in sect 5.1 > > Mmm.. I see that that sect 5.1.1 is also the section that=20 > > made my eyes glaze=20 > > over and wonder if all that compelxity is needed. > >=20 > > d. On page 30... I started wondering... Mmmm there are a lot=20 > > of "may" cases > > here. How will all the "may"-behaviour interoperate.=20 > Maybe just me. > >=20 > > e. Page 36 talks about "AAA server or agent" I guess server=20 > > and agent are > > meant to be synonyms here? Are they? Why are we confiusing=20 > > people here? > >=20 > > f. Page 36/37 talks about "increased risk of premature=20 > > failover" and about > > "congestive collapse". Maybe those risks should be spelled out in > > security considerations? In any event it seems quite=20 > > hidden to me the > > way it is described in a long piece of text. > >=20 > > g. Have the state-diagrams been checked rigorously? > > For example, page 46. the 3rd and 4th cases, should the=20 > > also not be a > > Stop Tx action? Also for 7th, 8th, 9th and 10th case on=20 > that page? > > I wondered about such things at other places in the state=20 > > diagrams too. > >=20 > > h. User-Equipment-Info-Type AVP is defined as Unsigned32.=20 > > I wonder if the type would not better be Enumerated > >=20 > > i. I see that various of your Enumerated datatypes start the list of > > enumerations at zero. Is that wise? In the SMI we tend to=20 > > start at 1. The=20 > > reason is that zero is often just an value that is there=20 > > after clean memory > > has been obtained and while no one has yet initiated the=20 > > field. I can live > > with it, just wanted to point it out. > >=20 > > j. I am surprised to see a Unsigned64 to ideintify=20 > > subsessions. Do we really > > believe there will be that many? I can live with it... but ?? > >=20 > > k. Section 8.28 in the examples, pls do NOT use "provider.com" and > > "vendor.com". RFC2606 prescribes to use names like=20 > > "provider.example.com" > > and "vendor.example.net" or some such. > >=20 > > l. Section 8.46=20 > > Is it SIP URL in this case, while it is SIP URI in sect 8.38? > >=20 > > m. I am confused by the AVPs defined in Sect 8.49 and 8.50 > > 8.49 defines various types. Is the formatting of those values > > indeed such that they are UTF-8 ? I have not checked.=20 > May I assume > > that someone DID check/verify? > >=20 > > n. I assume Bernard (or some RADIUS/DIAMETER expert has=20 > > checked sect 11 > >=20 > > o. In the IANA considerations you state many times "this=20 > specification > > assigns xxx".=20 > > - first, I suspect that IANA should officially do the assignment. > > so it would have been better to say something aka: > > "Iana has assigned xxx" If you want a specific value, you can=20 > > ask IANA to use value xxx. > > - second, I suspect that IANA needs to add the values to=20 > > the registries > > on their web pages. You do never tell IANA that they=20 > > indeed need to do > > that=20 > >=20 > > p. Security considerations. > > You claim that DIAMBASE not only tells/assume that IPsec=20 > > or TLS are used. > > But DIAMBASE in fact REQUIRES (MUST language) the=20 > > implementation of IPsec > > and even explains how to do it (which is important).=20 > Same for TLS. > >=20 > > Second section uses lower case must/shall where I think=20 > > uppercase MUST/SHALL > > would be appropriate. I also suspect that the last=20 > sentence of 2nd > > para may worry/bother security ADs. > >=20 > > 3rd para: "economical consequences" ?? DO you mean "financial" ?? > >=20 > > last 2 paragraphs in sect 14 seem weak to me. WOnder what=20 > > sec ADs have to say > >=20 > > sect 14.1 talks about "agent"... is that same as "server"? > > It also talks about "Diameter Routing Table" ... has that=20 > > term been explained? > > Last para in sect 14.1 points to an informative reference? > >=20 > > I would recommend to have one of the secuirty ADs take a=20 > > look at this. > >=20 > > q. I wonder if references to documents that are cited in=20 > > sections 8.x should > > not all be normative. For example, [RAD802.1X] is=20 > > normative (correctly > > in my view), but [SIP] is informative (incorrectly in my=20 > > view). [IPv4] > > and [IPv6Addr] seem normative to me too? > >=20 > > I have not checked the appendices. > >=20 > > --------- > >=20 > > Following are mainly nits/admin things: > >=20 > > 1. Results if idnits script. Just check, not all of it means error. > > But non-ASCII characters is not good. The long lines=20 > > can/will probably > > be hadnled by RFC-Editor. But if you can fix it, so much=20 > > the better. > > This idnits tool is available at:=20 > > http://ietf.levkowetz.com/tools/idnits/ > > $ idnits > idnits 1.26, (21 Apr 2004) > >=20 > > The document seems to use RFC 2026 boilerplate... > > The document seems to lack an RFC 2026 Section 10.4(C)=20 > > Permission Grants Notice > > -- however, there's a paragraph with a matching=20 > > beginning. Boilerplate error? > > There are 298 instances of too long lines in the document, > > -- the longest one being 1 character in excess of 72. > > Line 1447 contains non-ascii character in position 37. > > Line 3852 contains non-ascii character in position 49. > > Line 5336 contains non-ascii character in position 39. > > Line 5353 contains non-ascii character in position 51. > > There are 4 instances of lines with non-ascii characters=20 > > in the document. > >=20 > > Warnings: > > The document seems to lack an RFC 2026 Section 10.4(B)=20 > > IPR Disclosure Invitation > > There are 178 instances of lines with hyphenated line=20 > > breaks in the document. > >=20 > > Line 2285 has weird spacing: '...quested to en...' > > Line 2295 has weird spacing: '...mporary end ...' > > Line 4755 has weird spacing: '...session for s...' > >=20 > > 2.In the abstract, pls expand the SIP acronym > >=20 > > 3.In the body of the document, pls expand the acronyms when=20 > > used for the > > first time > >=20 > > 4.One but last para of sect 1 states: > > To fulfill these requirements, it is necessary to facilitate > > communication between the network element providing the=20 > > service (e.g. > > NAS, SIP Proxy, Application Server etc.) and a=20 > > credit-control server. > > That seems to say that this doc does much more than what we=20 > > see in the abstract > >=20 > > 5.Last para of sect 1.2, 2nd line: s/intermediates/intermediate/ > >=20 > > 6.Sect 1.3 talks about a value of "4" for Auth-Application-Id. > > Is that already assigned? If not we should list in IANA=20 > > considerations sect. > > Aha, I see it is in IANA considerations. So it should=20 > > really be a TBA instead > > of pre-assuming it will get value 4 assigned by IANA. > >=20 > > Same question in sect 3.1 and possibly at some more places > >=20 > > 7.Seect 3. Where are those code points for CCR and CCA defined? > > In this doc? Then we need IANA considereations. In fact, maybe the > > doc should say TBA-by-IANA instead if this is the case, because > > I see it in IANA considerations. > >=20 > > 8.Bottom page13 and top of page14. Is this another form of=20 > > (implicit) subtyping? > >=20 > > 9.Sect 5.1 4 para 2 but last line > > s/the closing the/closing the/ > >=20 > > 10.When I see things like on page 18: > > Where multiple G-S-U-Pool-Reference AVPs with the same=20 > > G-S-U-Pool- > > Identifier are provided within a=20 > > Multiple-Services-Credit-Control AVP > > Then I wonder if a ptr to where those AVPs are defined=20 > woul not be > > useful/helpful. > > Same for things like: > > RECOMMENDED that Diameter credit-control clients=20 > > maintain a PENDING-U > > message queue and restarts the Tx timer every time a=20 > CCR[Update] > >=20 > > 11.Let me also point out that the notaion CCR[Update] in the text > > cam make people think that [Update] is a citation. I bet=20 > > the RFC-Editor > > will not be happy with that. It occurs several times. > >=20 > > 12.Top of page 20=20 > > the concerned service. Additional service event=20 > > information to be > > rated MAY be sent as service specific AVPs or MAY be=20 > > sent within the > > Service-Parameter-Info AVP at command level. > > So is it the server or the client who "MAY" send this? > > And why is the Upper case MAY?=20 > >=20 > > 13.Somewhat towrds the bottom of page 20 (3rd pare from=20 > bottom) I see: > > There MUST be maximum one instance of the same unit type=20 > > in one Answer > > message. However, in case multiple quotas are conveyed=20 > > to the credit > > control client in the Multiple-Services-Credit-Control=20 > > AVPs, it is > > possible to carry two instances of the same unit type=20 > > associated to a > > service-identifier/rating-group for instance when a=20 > > tariff time change > > is expected. > > Is that good english? Is the last one really a sentence? > > I have a hard time understanding what it says > >=20 > > 14.Top of page 21: > > Two different approaches are defined for the first=20 > > interrogation to > > suit properly in all the possible architectures. The=20 > > first approach > > Again... is that a sentence? And if so what does it mean? > >=20 > > 15. 2nd line page 23 > > s/contribute/co-operate/ ?? > >=20 > > 16. Page 24, 1st para, one but last line. > > Talks about setting a value to 1 (for an "intermediate request". > > and referes to sect 8.2 > > But sect 82. does not talk about "intermediate" requests.=20 > > I guess that > > the UPDATE-REQUESTS are intermendiate... but that is not=20 > > immediately clear. > >=20 > > 17.Sect 5.5 talks about value 4 for RAR messages. See my=20 > > earlier comment > > on that value. > >=20 > > 18. Sect 5.6 talks about "top-up". I probably can guess what=20 > > it means. But maybe > > it is better to explain it. > >=20 > > 19.first para sect 5.6.2, last word: s/follow/follows/ > >=20 > > 20.Page 36 talks about "timer Twinit". Might want to explain=20 > > what it is. > > Possibly also for timers Tx and Tcc > >=20 > > 21. Page 52 2nd case. I think under action column, you want=20 > > to s/=3D!/!=3D/ ?? > >=20 > > 22. Table on page 54/55.. WOuld it not be good to explain=20 > > what codes M, P, V > > and Y mean? > >=20 > > 23. Page 65 towards bottom > > s/has been occurred/has occurred/ > > =20 > > 24. Sect 8.32 > > s/enumerated/Enumerated/ > >=20 > > 25. Sect 8.33=20 > > Validity-Time in seconds. But since when? Since the AVP=20 > > is received by the > > Client?=20 > >=20 > > 26. Top of page 85 > > s/kind threat/kind of threat/ > >=20 > > Bert > >=20 >=20 From owner-aaa-wg@merit.edu Tue Apr 27 08:04:18 2004 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 IAA24853 for ; Tue, 27 Apr 2004 08:04:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 70F3B91242; Tue, 27 Apr 2004 08:03:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A2B69127C; Tue, 27 Apr 2004 08:03:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D7C3B91242 for ; Tue, 27 Apr 2004 08:03:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD45158AD9; Tue, 27 Apr 2004 08:03:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id C4D7958BA0 for ; Tue, 27 Apr 2004 08:03:51 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RC3nv13190 for ; Tue, 27 Apr 2004 15:03:49 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 14:58:43 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3RBwh42003089 for ; Tue, 27 Apr 2004 14:58:43 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00wv1r1u; Tue, 27 Apr 2004 14:58:43 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RBwWH22018 for ; Tue, 27 Apr 2004 14:58:32 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 14:57:54 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: AAA URI draft published Date: Tue, 27 Apr 2004 14:57:54 +0300 Message-ID: Thread-Topic: [AAA-WG]: AAA URI draft published Thread-Index: AcQRlSMy27cM+WTrQ8G1oSb0M8C1jgauaLmw From: To: , X-OriginalArrivalTime: 27 Apr 2004 11:57:54.0354 (UTC) FILETIME=[DF979120:01C42C4E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Miquel, I had a quick look at this, and it seems roughly in order. Would you feel comfortable (& the WG too) if we started a WGLC on this soon? John > I would like to point out that the AAA URI draft has been recently=20 > published as an Internet Draft. The document is now a WG item. >=20 > http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-00.txt >=20 > I would like to solicit comments about this version of the draft. It=20 > hopefully captures the discussion we had during the IETF=20 > meetin in Seoul=20 > and the following days over e-mail. >=20 > The most important change with respect RFC 3588 is the=20 > re-definition of=20 > the URI format. I think this is an important change. >=20 > Please feel free to comment, not only if you have problems,=20 > but also if=20 > you believe we are on the right track. >=20 > Since this draft is going to constitute an update to RFC=20 > 3588, we would=20 > like to proceed fast and go to WGLC soon , so that implementations of=20 > RFC 3588 can follow the URI format defined in this draft. >=20 > Regards, >=20 > Miguel Garcia > --=20 > Miguel A. Garcia tel:+358-50-4804586 > Nokia Research Center Helsinki, Finland >=20 >=20 From owner-aaa-wg@merit.edu Tue Apr 27 08:28:34 2004 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 IAA26732 for ; Tue, 27 Apr 2004 08:28:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5E9129127C; Tue, 27 Apr 2004 08:28:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C1F79127E; Tue, 27 Apr 2004 08:28:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B1EE99127C for ; Tue, 27 Apr 2004 08:28:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9BD0158BD0; Tue, 27 Apr 2004 08:28:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id ACD3858B4C for ; Tue, 27 Apr 2004 08:28:08 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RCS6v18882 for ; Tue, 27 Apr 2004 15:28:06 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 15:26:27 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3RCQRfX027007 for ; Tue, 27 Apr 2004 15:26:27 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 008pMYbe; Tue, 27 Apr 2004 15:26:25 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RCQNH18330 for ; Tue, 27 Apr 2004 15:26:24 +0300 (EET DST) Received: from nokia.com ([172.21.38.229]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 15:26:15 +0300 Message-ID: <408E5167.1070604@nokia.com> Date: Tue, 27 Apr 2004 15:26:15 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: "Loughney John (Nokia-NRC/Helsinki)" Cc: AAA mailing list Subject: Re: [AAA-WG]: AAA URI draft published References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2004 12:26:15.0966 (UTC) FILETIME=[D5D4F3E0:01C42C52] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi John: For what I believe this document is complete and ready for WGLC. Regards, Miguel Loughney John (Nokia-NRC/Helsinki) wrote: > Miquel, > > I had a quick look at this, and it seems roughly in order. Would > you feel comfortable (& the WG too) if we started a WGLC on this > soon? > > John > > >>I would like to point out that the AAA URI draft has been recently >>published as an Internet Draft. The document is now a WG item. >> >>http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-00.txt >> >>I would like to solicit comments about this version of the draft. It >>hopefully captures the discussion we had during the IETF >>meetin in Seoul >>and the following days over e-mail. >> >>The most important change with respect RFC 3588 is the >>re-definition of >>the URI format. I think this is an important change. >> >>Please feel free to comment, not only if you have problems, >>but also if >>you believe we are on the right track. >> >>Since this draft is going to constitute an update to RFC >>3588, we would >>like to proceed fast and go to WGLC soon , so that implementations of >>RFC 3588 can follow the URI format defined in this draft. >> >>Regards, >> >> Miguel Garcia >>-- >>Miguel A. Garcia tel:+358-50-4804586 >>Nokia Research Center Helsinki, Finland >> > > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Tue Apr 27 08:41:23 2004 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 IAA27680 for ; Tue, 27 Apr 2004 08:41:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C573C9127F; Tue, 27 Apr 2004 08:41:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9701591280; Tue, 27 Apr 2004 08:41:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 933849127F for ; Tue, 27 Apr 2004 08:41:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7A78D58BD0; Tue, 27 Apr 2004 08:41:07 -0400 (EDT) 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 34F4A58B4C for ; Tue, 27 Apr 2004 08:41:07 -0400 (EDT) Received: from zrc2c010.us.nortel.com (zrc2c010.us.nortel.com [47.103.120.50]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3RCf0k16491 for ; Tue, 27 Apr 2004 07:41:00 -0500 (CDT) Received: from zrc2c012.us.nortel.com ([47.103.120.52]) by zrc2c010.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JC3C0Q2G; Tue, 27 Apr 2004 07:41:00 -0500 Received: from nortelnetworks.com (BLUETICK [47.102.184.206]) by zrc2c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JRJR3CTJ; Tue, 27 Apr 2004 07:41:01 -0500 Message-ID: <408E54BE.2090900@nortelnetworks.com> Date: Tue, 27 Apr 2004 12:40:30 +0000 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Joe Harvell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: when it's okay to proxy 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 Section 4.5 of RFC 3588 states: "For the originator of a Diameter message, "Encr" (Encryption) mans that if a message containing that AVP is to be sent via a Diameter Agent (proxy, redirect or relay) then the message MUST NOT be sent unless..." What puzzles me about this is that if a peer is discovered but not configured, then there is no way to know if it is a proxy. Relays and Redirect Agents can always be identified because they advertise the Relay application id. But proxies look the same as servers and clients. Even for a peer that is known by static configuration, is it expected that it be idenified as a proxy by configuration? Or is there some way to discover that it is a proxy that I am missing? From ljgfrzeznick@wp.pl Tue Apr 27 19:46:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11652 for ; Tue, 27 Apr 2004 19:46:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIcHQ-0005p1-96 for aaa-archive@ietf.org; Tue, 27 Apr 2004 19:46:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIcGi-0005iN-00 for aaa-archive@ietf.org; Tue, 27 Apr 2004 19:45:41 -0400 Received: from 66-95-56-49.client.dsl.net ([66.95.56.49] helo=24.189.165.246) by ietf-mx with smtp (Exim 4.12) id 1BIcG2-0005Zd-00 for aaa-archive@ietf.org; Tue, 27 Apr 2004 19:44:58 -0400 Received: from mailgate.profund.com (mailgate.profund.com [193.195.151.234]) by mail.cul.net with SMTP; אפריל, 28 2004 1:28:50 +0600 From: ebuvlopalf To: Undisclosed.Recipients Subject: working at home is fun icf Sender: ebuvlopalf Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-8" Date: Wed, 28 Apr 2004 02:43:53 +0200 X-Mailer: Internet Mail Service (5.5.2650.21) X-Priority: 1 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=28.8 required=5.0 tests=DOMAIN_4U2, FAKED_UNDISC_RECIPS,FORGED_IMS_HTML,FORGED_IMS_TAGS,FORGED_MUA_IMS, HEAD_ILLEGAL_CHARS,HTML_50_60,HTML_FONTCOLOR_UNKNOWN,HTML_FONT_BIG, HTML_FONT_INVISIBLE,HTML_IMAGE_ONLY_04,HTML_MESSAGE, HTML_TAG_BALANCE_BODY,HTML_TAG_BALANCE_HTML,LINES_OF_YELLING, MIME_HTML_ONLY,RCVD_NUMERIC_HELO,TO_HAS_SPACES,TO_MALFORMED, TRACKER_ID,WORK_AT_HOME,X_PRIORITY_HIGH autolearn=no version=2.60 X-Spam-Report: * 0.5 X_PRIORITY_HIGH Sent with 'X-Priority' set to high * 2.7 FAKED_UNDISC_RECIPS Faked To "Undisclosed-Recipients" * 2.4 TO_HAS_SPACES To: address contains spaces * 0.3 TO_MALFORMED To: has a malformed address * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.6 DOMAIN_4U2 BODY: Domain name containing a "4u" variant * 1.3 WORK_AT_HOME BODY: Information on how to work at home (1) * 3.5 TRACKER_ID BODY: Incorporates a tracking ID number * 0.1 HTML_FONTCOLOR_UNKNOWN BODY: HTML font color is unknown to us * 0.3 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.4 HTML_TAG_BALANCE_HTML BODY: HTML has unbalanced "html" tags * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.4 HTML_FONT_INVISIBLE BODY: HTML font color is same as background * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 4.3 HEAD_ILLEGAL_CHARS Header contains too many raw illegal characters * 1.1 FORGED_MUA_IMS Forged mail pretending to be from IMS * 4.3 FORGED_IMS_HTML IMS can't send HTML message only * 4.3 FORGED_IMS_TAGS IMS mailers can't send HTML in this format

Hi   aaa sgwcvd

the way you see it:
GET AN INCOME - DESERVING YOUR SKILLS !!!


jxlg
click picture for details

 
NOTICE: This is a one time message.
You have received this e-mail because you expressed interest in career and employment information.
In case you suppose this mail has reached your mailbox by an error, we certainly apologize.
remove


4992davgab the PC is working while you are living bcvnauwwlmyrcsaspchlxxfdl From owner-aaa-wg@merit.edu Wed Apr 28 09:13:05 2004 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 JAA13784 for ; Wed, 28 Apr 2004 09:13:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C36E39122B; Wed, 28 Apr 2004 09:12:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9316491254; Wed, 28 Apr 2004 09:12:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 421309122B for ; Wed, 28 Apr 2004 09:12:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2E10958C43; Wed, 28 Apr 2004 09:12:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from igate1.vodafone.co.uk (igate.vodafone.co.uk [194.62.232.65]) by segue.merit.edu (Postfix) with ESMTP id 46F1D58C3B for ; Wed, 28 Apr 2004 09:12:48 -0400 (EDT) Received: by igate1.vodafone.co.uk; (8.8.8/1.3/10May95) id OAA13146; Wed, 28 Apr 2004 14:12:47 +0100 (BST) Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by mailguard1 (4.9.6.9) with ESMTP id EU50eAAN for ; Wed, 28 Apr 2004 14:13:50 +0100 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.6797); Wed, 28 Apr 2004 14:12:34 +0100 Received: from ukwmxm06.vf-uk.internal.vodafone.com ([10.33.126.244]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.6797); Wed, 28 Apr 2004 14:12:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Use of Requested-Service-Unit in D-CCA Date: Wed, 28 Apr 2004 14:12:32 +0100 Message-ID: <9C78071AF00DCF4BA607B7743C2FCE027C5815@UKWMXM06> Thread-Topic: Use of Requested-Service-Unit in D-CCA Thread-Index: AcQtIcK8B1Es3QElSwCC+qY2Lchrtw== From: "Glass, Cameron, Global IT" To: X-OriginalArrivalTime: 28 Apr 2004 13:12:35.0141 (UTC) FILETIME=[78C32750:01C42D22] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, In CC-04 section 8.16 (4th paragraph) it states: " The Requested-Service-Unit AVP MAY contain the amount of requested=20 service units or the requested monetary value. It MUST be present in=20 the initial interrogation and within the intermediate interrogations=20 where new quota is requested. If the credit-control client does not=20 include the Requested-Service-Unit AVP in a request command, for=20 instance because it has determined that the end-user terminated the=20 service, the server MUST debit the used amount from the user's = account=20 but MUST NOT return a new quota in the corresponding answer. " This seems to mean that there are circumstances when the = Requested-Service-Unit AVP must be sent but need not contain any amount = of requested units or money. Does this really mean that Requested-Service-Unit can be sent by the = client with no other AVPs grouped within it? In other words it would be = an AVP with no data field and is effectively acting as a boolean. Is this accepted as good practice in Diameter? Would it be possible to define other AVPs in an application that had no = data fields and acted as a boolean type? Regards, Cameron. Cameron Glass Global IT Designer Global IT=20 Vodafone Group Technology & Business Integration From owner-aaa-wg@merit.edu Wed Apr 28 10:43:45 2004 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 KAA19380 for ; Wed, 28 Apr 2004 10:43:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 51FD591254; Wed, 28 Apr 2004 10:43:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2181491255; Wed, 28 Apr 2004 10:43:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D2F4791254 for ; Wed, 28 Apr 2004 10:43:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD04B58C4D; Wed, 28 Apr 2004 10:43:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 6985658B8D for ; Wed, 28 Apr 2004 10:43:30 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SEhLv06364; Wed, 28 Apr 2004 17:43:21 +0300 (EET DST) X-Scanned: Wed, 28 Apr 2004 17:40:56 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3SEeud7005584; Wed, 28 Apr 2004 17:40:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 002RyCyc; Wed, 28 Apr 2004 17:40:55 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SEesH15649; Wed, 28 Apr 2004 17:40:54 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Apr 2004 17:40:53 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Use of Requested-Service-Unit in D-CCA Date: Wed, 28 Apr 2004 17:40:51 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B052C@esebe016.ntc.nokia.com> Thread-Topic: Use of Requested-Service-Unit in D-CCA Thread-Index: AcQtIcK8B1Es3QElSwCC+qY2LchrtwACJB4w From: To: Cc: X-OriginalArrivalTime: 28 Apr 2004 14:40:53.0756 (UTC) FILETIME=[CEFBA3C0:01C42D2E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Cameron, > This seems to mean that there are circumstances when the=20 > Requested-Service-Unit AVP must be sent but need not contain=20 > any amount of requested units or money. Yes, correct. In particular, such circumstance is when the AVP is used in the M-S-C-C grouped AVP. The client includes the empty R-S-U AVP to indicate that a quota is requested. > Does this really mean that Requested-Service-Unit can be sent=20 > by the client with no other AVPs grouped within it? In other=20 > words it would be an AVP with no data field and is=20 > effectively acting as a boolean. Yes. You may note from the R-S-U AVP definition that all AVPs=20 within it are optional.=20 > Is this accepted as good practice in Diameter? The data field of an AVP may be zero or more octets (RFC 3588). So long as the semantic of the AVP allows an empty AVP, it is legal. In the case of the R-S-U AVP the semantic of the empty AVP is=20 "I request quota", therefore is not an error. i.e. The R-S-U AVP may be used to request an amount of "credit"=20 resources, if the client knows what it wants, or just to indicate that a quota is requested. In the former case it must be sent with an AVP in it including the amount of requested resources. In the latter case, it is sent empty. > Would it be possible to define other AVPs in an application=20 > that had no data fields and acted as a boolean type? =20 If an application has such a need, why not. Regards Marco From owner-aaa-wg@merit.edu Thu Apr 29 03:59:16 2004 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 DAA12016 for ; Thu, 29 Apr 2004 03:59:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DE9CF91293; Thu, 29 Apr 2004 03:58:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A9E7D91294; Thu, 29 Apr 2004 03:58:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3491A91293 for ; Thu, 29 Apr 2004 03:58:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 246B758D3E; Thu, 29 Apr 2004 03:58:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from igate1.vodafone.co.uk (igate.vodafone.co.uk [194.62.232.65]) by segue.merit.edu (Postfix) with ESMTP id 80E7558D55 for ; Thu, 29 Apr 2004 03:58:56 -0400 (EDT) Received: by igate1.vodafone.co.uk; (8.8.8/1.3/10May95) id IAA11683; Thu, 29 Apr 2004 08:58:55 +0100 (BST) Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by mailguard1 (4.9.6.9) with ESMTP id CQ232AA7 for ; Thu, 29 Apr 2004 08:59:48 +0100 Received: from ukwmxc03.vf-uk.internal.vodafone.com ([10.33.126.155]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.6797); Thu, 29 Apr 2004 08:58:28 +0100 Received: from ukwmxm06.vf-uk.internal.vodafone.com ([10.33.126.244]) by ukwmxc03.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.6797); Thu, 29 Apr 2004 08:58:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Result code vrs Error Code Date: Thu, 29 Apr 2004 08:58:28 +0100 Message-ID: <9C78071AF00DCF4BA607B7743C2FCE026BF116@UKWMXM06> Thread-Topic: Result code vrs Error Code Thread-Index: AcQtvpKm4ekNumIaTf25tHPZ4/2Pug== From: "Glass, Cameron, Global IT" To: X-OriginalArrivalTime: 29 Apr 2004 07:58:37.0441 (UTC) FILETIME=[C707FF10:01C42DBF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello Regarding section 9.1 of CC-04 "9.1 Transient Failures =20 =20 Errors that fall within the transient failures category are used to=20 inform a peer that the request could not be satisfied at the time it=20 was received, but MAY be able to satisfy the request in the future. =20 ... DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011=20 The credit-control server determines that the service can be=20 granted to the end user but no further credit-control is needed for = the service (e.g. service is free of charge). " The use of a 4xxx series code seems odd in this case as this does not = seem to be an error but may infact be a desirable result. Was the use of = a 2xxx code considered and discarded for a particular reason? regards Cameron Glass Cameron Glass Global IT Designer Global IT=20 Vodafone Group Technology & Business Integration e-mail:cameron.glass@vodafone.com Vodafone Group Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire, = RG14 2FN=20 Registered in England No 3802001=20 From mjsabinastancel@poczta.onet.pl Thu Apr 29 04:26:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13392 for ; Thu, 29 Apr 2004 04:26:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ6si-0006Tx-IC for aaa-archive@ietf.org; Thu, 29 Apr 2004 04:26:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ6rn-0006KB-00 for aaa-archive@ietf.org; Thu, 29 Apr 2004 04:26:00 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJ6qx-0006Av-00 for aaa-archive@ietf.org; Thu, 29 Apr 2004 04:25:07 -0400 Received: from user-24-236-91-126.knology.net ([24.236.91.126] helo=82.157.49.83) by mx2.foretec.com with smtp (Exim 4.24) id 1BJ6qv-0001MV-M5 for aaa-archive@ietf.org; Thu, 29 Apr 2004 04:25:10 -0400 Received: from mail.ut.caldera.com (mail.ut.caldera.com [216.250.130.2]) by mailscan3.macau.ctm.net with ESMTP; אפריל, 29 2004 9:57:01 +0300 From: ircjlivenenjoy To: Undisclosed.Recipients Subject: let the PC make your job kkwes Sender: ircjlivenenjoy Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-8" Date: Thu, 29 Apr 2004 11:23:41 +0200 X-Mailer: The Bat! (v1.52f) Business X-Priority: 1 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=30.9 required=5.0 tests=DOMAIN_4U2, FAKED_UNDISC_RECIPS,FORGED_MUA_THEBAT,FORGED_MUA_THEBAT_CS, FORGED_RCVD_NET_HELO,FORGED_THEBAT_HTML,HEAD_ILLEGAL_CHARS,HTML_50_60, HTML_FONTCOLOR_UNKNOWN,HTML_FONT_BIG,HTML_FONT_INVISIBLE, HTML_IMAGE_ONLY_04,HTML_MESSAGE,HTML_TAG_BALANCE_BODY, HTML_TAG_BALANCE_HTML,LINES_OF_YELLING,MIME_HTML_ONLY, RCVD_NUMERIC_HELO,TO_HAS_SPACES,TO_MALFORMED,TRACKER_ID, X_PRIORITY_HIGH autolearn=no version=2.60 X-Spam-Report: * 0.5 X_PRIORITY_HIGH Sent with 'X-Priority' set to high * 2.7 FAKED_UNDISC_RECIPS Faked To "Undisclosed-Recipients" * 2.4 TO_HAS_SPACES To: address contains spaces * 0.3 TO_MALFORMED To: has a malformed address * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.6 DOMAIN_4U2 BODY: Domain name containing a "4u" variant * 3.5 TRACKER_ID BODY: Incorporates a tracking ID number * 0.1 HTML_FONTCOLOR_UNKNOWN BODY: HTML font color is unknown to us * 0.3 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.4 HTML_TAG_BALANCE_HTML BODY: HTML has unbalanced "html" tags * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.4 HTML_FONT_INVISIBLE BODY: HTML font color is same as background * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 4.3 HEAD_ILLEGAL_CHARS Header contains too many raw illegal characters * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 4.3 FORGED_THEBAT_HTML The Bat! can't send HTML message only * 3.2 FORGED_MUA_THEBAT Mail pretending to be from The Bat! (mid) * 2.5 FORGED_MUA_THEBAT_CS Mail pretending to be from The Bat! (charset)

Hi   aaa-archive ucdguqo

the way you see it:
GET AN INCOME - DESERVING YOUR SKILLS !!!


secj
click picture for details

 
NOTICE: This is a one time message.
You have received this e-mail because you expressed interest in career and employment information.
In case you suppose this mail has reached your mailbox by an error, we certainly apologize.
remove


575487wfkbgt let the PC makes you rich bwljbtjqglrxlunxjwkbviomtvfdldbjpsxfakf From owner-aaa-wg@merit.edu Thu Apr 29 06:02:57 2004 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 GAA17179 for ; Thu, 29 Apr 2004 06:02:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C98EE91294; Thu, 29 Apr 2004 06:02:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94E1791296; Thu, 29 Apr 2004 06:02:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8BAD291294 for ; Thu, 29 Apr 2004 06:02:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7909C58C8D; Thu, 29 Apr 2004 06:02:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id 2984D58C06 for ; Thu, 29 Apr 2004 06:02:35 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3TA2VPA002468 for ; Thu, 29 Apr 2004 12:02:31 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Apr 2004 12:02:31 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 29 Apr 2004 12:02:38 +0200 Message-ID: From: "Harri Hakala (JO/LMF)" To: "'Glass, Cameron, Global IT'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Result code vrs Error Code Date: Thu, 29 Apr 2004 12:02:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 29 Apr 2004 10:02:31.0762 (UTC) FILETIME=[163B5B20:01C42DD1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Cameron, > The use of a 4xxx series code seems odd in this case as this > does not seem to be an error but may infact be a desirable > result. Was the use of a 2xxx code considered and discarded > for a particular reason? I agree with you that it is a bit odd to use 4xxx series code, since it is not an error, as you said. But by using 4xxx series code the CC server can indicate that the credit control session is over and no further signalling is needed for the session. Otherwise (2xxx code), the CC server should maintain the session, until it receives the CCR[TERMINATION] from the client. regards...........Harri From owner-aaa-wg@merit.edu Thu Apr 29 07:16:20 2004 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 HAA20418 for ; Thu, 29 Apr 2004 07:16:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 939A491269; Thu, 29 Apr 2004 07:15:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 612DF9129C; Thu, 29 Apr 2004 07:15:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E7EC191269 for ; Thu, 29 Apr 2004 07:15:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2C6FF58BCE; Thu, 29 Apr 2004 07:15:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from igate1.vodafone.co.uk (igate.vodafone.co.uk [194.62.232.65]) by segue.merit.edu (Postfix) with ESMTP id 110BB58A54 for ; Thu, 29 Apr 2004 07:15:36 -0400 (EDT) Received: by igate1.vodafone.co.uk; (8.8.8/1.3/10May95) id MAA21403; Thu, 29 Apr 2004 12:15:35 +0100 (BST) Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by mailguard4 (4.9.6.9) with ESMTP id 8T9cdAA7 for ; Thu, 29 Apr 2004 12:13:08 +0100 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.6797); Thu, 29 Apr 2004 12:15:00 +0100 Received: from ukwmxm06.vf-uk.internal.vodafone.com ([10.33.126.244]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.6797); Thu, 29 Apr 2004 12:14:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Multiple Quotas in Granted-Service-Unit etc. in D-CCA Date: Thu, 29 Apr 2004 12:14:48 +0100 Message-ID: <9C78071AF00DCF4BA607B7743C2FCE026BF11B@UKWMXM06> Thread-Topic: Multiple Quotas in Granted-Service-Unit etc. in D-CCA Thread-Index: AcQt2lShn+s8xnCVQEWX6NCYZhIJFw== From: "Glass, Cameron, Global IT" To: "Aaa-Wg (E-mail)" X-OriginalArrivalTime: 29 Apr 2004 11:14:48.0794 (UTC) FILETIME=[2F4DEBA0:01C42DDB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Is it possible to include multiple quotas in Granted-Service-Unit or = Used-Service-Unit? This would mean, for example, both CC-Time and = CC-Total-Octets being included in the same instance of = Granted-Service-Unit. Is that acceptable? Regards, Cameron. Cameron Glass Global IT Designer Global IT=20 Vodafone Group Technology & Business Integration From owner-aaa-wg@merit.edu Thu Apr 29 08:34:33 2004 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 IAA24964 for ; Thu, 29 Apr 2004 08:34:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 15A1D9129C; Thu, 29 Apr 2004 08:34:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CEFF69129E; Thu, 29 Apr 2004 08:34:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9490F9129C for ; Thu, 29 Apr 2004 08:34:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6F7A958CEB; Thu, 29 Apr 2004 08:34:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by segue.merit.edu (Postfix) with ESMTP id 8C3E458BF9 for ; Thu, 29 Apr 2004 08:34:16 -0400 (EDT) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3TCYFAh023230 for ; Thu, 29 Apr 2004 14:34:15 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Apr 2004 14:34:15 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 29 Apr 2004 14:34:22 +0200 Message-ID: From: "Harri Hakala (JO/LMF)" To: "'Glass, Cameron, Global IT'" , "Aaa-Wg (E-mail)" Subject: RE: [AAA-WG]: Multiple Quotas in Granted-Service-Unit etc. in D-C CA Date: Thu, 29 Apr 2004 14:34:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 29 Apr 2004 12:34:15.0450 (UTC) FILETIME=[4873E7A0:01C42DE6] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Cameron, > Is it possible to include multiple quotas in > Granted-Service-Unit or Used-Service-Unit? This would mean, > for example, both CC-Time and CC-Total-Octets being included > in the same instance of Granted-Service-Unit. Is that acceptable? I assume that your question is related to 'basic' credit control and not to case when multiple services in one credit control session is applied, i.e. Multiple-Services-Credit-Control AVP is not used. In the 'basic' case, it is acceptable include several units in Granted-Service-Unit and Used-service-unit, but then if several unit types are included in the G-S-U the credit-control client must handle each unit type separately and the unit types should not be changed within an ongoing credit-control session. Also there must be maximum one instance of the same unit type in one CCA message. This means also that when all of the granted service units for one unit type are spent by the user, the CC client must send a new CCR to the CC server. regards...........Harri From owner-aaa-wg@merit.edu Thu Apr 29 08:47:13 2004 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 IAA26255 for ; Thu, 29 Apr 2004 08:47:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A561B9129D; Thu, 29 Apr 2004 08:46:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 72BBF9129E; Thu, 29 Apr 2004 08:46:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E76349129D for ; Thu, 29 Apr 2004 08:46:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D2B8858A78; Thu, 29 Apr 2004 08:46:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id C0F2458C06 for ; Thu, 29 Apr 2004 08:46:54 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCkhJ20780; Thu, 29 Apr 2004 15:46:43 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 15:43:47 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3TChl6v001107; Thu, 29 Apr 2004 15:43:47 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00obmUxO; Thu, 29 Apr 2004 15:43:46 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TChVH16921; Thu, 29 Apr 2004 15:43:31 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 15:43:31 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Multiple Quotas in Granted-Service-Unit etc. in D-CCA Date: Thu, 29 Apr 2004 15:43:31 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B052E@esebe016.ntc.nokia.com> Thread-Topic: Multiple Quotas in Granted-Service-Unit etc. in D-CCA Thread-Index: AcQt2lShn+s8xnCVQEWX6NCYZhIJFwAC1I7w From: To: , X-OriginalArrivalTime: 29 Apr 2004 12:43:31.0590 (UTC) FILETIME=[93F02260:01C42DE7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Cameron, > Is it possible to include multiple quotas in=20 > Granted-Service-Unit or Used-Service-Unit? This would mean,=20 > for example, both CC-Time and CC-Total-Octets being included=20 > in the same instance of Granted-Service-Unit. Is that acceptable? Yes it is possible. This is contemplated in the draft at sect. 5.2 "The credit-control server returns the Granted-Service-Unit AVP in the = Answer message to the Diameter credit-control client. The = Granted-Service-Unit AVP contains the amount of service units that the = Diameter credit-control client can provide to the end user until a new = Credit-Control-Request MUST be sent to the credit-control server. If = several unit types are sent in the Answer message the credit-control = client MUST handle each unit type separately. The type of the = Granted-Service-Unit AVP can be time, volume, service specific or money = depending on the type of service event. The unit type(s) SHOULD NOT be = changed within an ongoing credit-control session. =20 =20 There MUST be maximum one instance of the same unit type in one Answer = message. However, in case multiple quotas are conveyed to the credit = control client in the Multiple-Services-Credit-Control AVPs, it is = possible to carry two instances of the same unit type associated to a = service-identifier/rating-group for instance when a tariff time change = is expected." and sect. 5.3 "When all of the granted service units for one unit type are spent by = the end user or the Validity-Time is expired, the Diameter = credit-control client MUST send a new Credit-Control-Request to the = credit-control server." The server can return e.g. time and volume in one instance of the G-S-U = AVP.=20 When all granted units for one unit type (e.g. time) have been used, the = client re-authorizes the credit (i.e. sends CCR[Update]) and reports the used units for all unit types (in this example time and volume) within one instance of the U-S-U AVP. Regards Marco From owner-aaa-wg@merit.edu Thu Apr 29 15:58:21 2004 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 PAA24770 for ; Thu, 29 Apr 2004 15:58:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7075591247; Thu, 29 Apr 2004 15:58:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 400169126C; Thu, 29 Apr 2004 15:58:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3001991247 for ; Thu, 29 Apr 2004 15:58:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 14A3858DD7; Thu, 29 Apr 2004 15:58:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 65AF358DCE for ; Thu, 29 Apr 2004 15:58:06 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i3TK39N16235 for ; Thu, 29 Apr 2004 13:03:10 -0700 Date: Thu, 29 Apr 2004 13:03:09 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: IETF Last Call on EAP State Machine Document Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The IESG has received a request from the EAP Working Group to consider the following document for publication as an Informational RFC: "State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator" The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. IETF Last Call will run until May 27, 2004. Please send comments to iesg@ietf.org, and cc: eap@frascone.com, the EAP WG mailing list. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-03.pdf http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-03.txt Comments should be sent in the Issues format specified on the EAP WG issues page: http://www.drizzle.com/~aboba/EAP/eapissues.html From owner-aaa-wg@merit.edu Fri Apr 30 03:24:03 2004 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 DAA00529 for ; Fri, 30 Apr 2004 03:24:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BF25B91207; Fri, 30 Apr 2004 03:23:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86AD3912A5; Fri, 30 Apr 2004 03:23:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6040491207 for ; Fri, 30 Apr 2004 03:23:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4A25158DE4; Fri, 30 Apr 2004 03:23:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id B135158E3C for ; Fri, 30 Apr 2004 03:23:47 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id C9B068981B for ; Fri, 30 Apr 2004 10:23:30 +0300 (EEST) Message-ID: <4091FE32.4030000@kolumbus.fi> Date: Fri, 30 Apr 2004 10:20:18 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: IETF Last Call on EAP State Machine Document 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 Let me add that this document includes among other things an abstract interface between the EAP state machine and AAA, so review from the AAA viewpoint would be very useful. --Jari Bernard Aboba wrote: > The IESG has received a request from the EAP Working Group to consider the > following document for publication as an Informational RFC: > > "State Machines for Extensible Authentication Protocol (EAP) Peer and > Authenticator" > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. > > IETF Last Call will run until May 27, 2004. Please send comments to > iesg@ietf.org, and cc: eap@frascone.com, the EAP WG mailing list. > > The document is available for inspection here: > > http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-03.pdf > http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-03.txt > > Comments should be sent in the Issues format specified on the EAP WG > issues page: > > http://www.drizzle.com/~aboba/EAP/eapissues.html > > > From owner-aaa-wg@merit.edu Fri Apr 30 04:34:31 2004 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 EAA03135 for ; Fri, 30 Apr 2004 04:34:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D10B8912A5; Fri, 30 Apr 2004 04:34:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A26E2912A8; Fri, 30 Apr 2004 04:34:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 59CE3912A5 for ; Fri, 30 Apr 2004 04:34:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 46B0C58CAE; Fri, 30 Apr 2004 04:34:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.202]) by segue.merit.edu (Postfix) with ESMTP id BE8D058DBC for ; Fri, 30 Apr 2004 04:34:07 -0400 (EDT) Received: from g9jbq.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for aaa-wg@merit.edu; Fri, 30 Apr 2004 10:29:54 +0200 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Apr 2004 10:29:54 +0200 Message-Id: From: "Beck01, Wolfgang" To: aaa-wg@merit.edu Subject: [AAA-WG]: questions/comments on draft-ietf-aaa-diameter-sip-app-02 Date: Fri, 30 Apr 2004 10:29:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello, p 12, section 5.3 step 12: "SIP server 2 will validate the credentials.." How can the SIP server do this? It has asked for authentication parameters in steps 5 and 6, but it doesn't have the user's password. p 32, section 7.7 "The SIP-Method AVP MUST include the SIP method name of the SIP request that triggered this Diameter MAR message. The Diameter MAR message MUST include a SIP-AOR AVP. The SIP-AOR AVP indicates the intended Address-of-Record of the SIP request. " Why are SIP-Method and SIP-AOR mandatory? I would have expected a mandatory Contact: or From: URI, or some other information about the user requesting authentication. p 48, typo 'Digest-Relam' Regards, Wolfgang -- Wolfgang Beck T-Systems Internet Netzplattformen Am Kavalleriesand 3 64295 Darmstadt From owner-aaa-wg@merit.edu Fri Apr 30 09:54:40 2004 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 JAA01860 for ; Fri, 30 Apr 2004 09:54:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C572391210; Fri, 30 Apr 2004 09:54:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9520091211; Fri, 30 Apr 2004 09:54:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 689C491210 for ; Fri, 30 Apr 2004 09:54:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4FFA258E9E; Fri, 30 Apr 2004 09:54:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id 93A1F58E9B for ; Fri, 30 Apr 2004 09:54:24 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3UDsNPA026355 for ; Fri, 30 Apr 2004 15:54:23 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Apr 2004 15:54:22 +0200 Received: from wadias.es.eu.ericsson.se (madrid.es.eu.ericsson.se [159.107.22.253]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id J88TVFB8; Fri, 30 Apr 2004 15:54:22 +0200 Received: from madrid.ericsson.se ([159.107.27.157]) by wadias.es.eu.ericsson.se (8.12.10/8.12.10) with ESMTP id i3UDsLQa008482 for ; Fri, 30 Apr 2004 15:54:21 +0200 (MET DST) Message-ID: <40925A8D.6050306@madrid.ericsson.se> Date: Fri, 30 Apr 2004 15:54:21 +0200 X-Sybari-Trust: e9c542c9 08d63d2e 935bbb39 00000138 From: MCarmen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: question on Diameter References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030008060604090203060303" X-OriginalArrivalTime: 30 Apr 2004 13:54:22.0987 (UTC) FILETIME=[A46195B0:01C42EBA] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------030008060604090203060303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, Just a question on RFC3588. In the CER/CEA chapter it is said: " When two Diameter peers establish a transport connection, they MUST exchange the Capabilities Exchange messages, as specified in the peer state machine (see Section 5.6). This message allows the discovery of a peer's identity and its capabilities (protocol version number, supported Diameter applications, security mechanisms, etc.) " Is it possible to exchange again the Capabilities Exchange messages once the connection is already established to modify my capabilities? thanks, MCarmen --------------030008060604090203060303 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all,

Just a question on RFC3588. In the CER/CEA chapter it is said:

" When two Diameter peers establish a transport connection, they MUST exchange the Capabilities Exchange messages, as specified in the peer state machine (see Section 5.6).  This message allows the discovery of a peer's identity and its capabilities (protocol version number, supported Diameter applications, security mechanisms, etc.) "

Is it possible to exchange again the Capabilities Exchange messages once the connection is already  established to modify my capabilities?

thanks,
MCarmen
 --------------030008060604090203060303-- From owner-aaa-wg@merit.edu Fri Apr 30 10:16:18 2004 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 KAA03768 for ; Fri, 30 Apr 2004 10:16:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 746E1912B6; Fri, 30 Apr 2004 10:15:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48001912B5; Fri, 30 Apr 2004 10:15:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 78994912B6 for ; Fri, 30 Apr 2004 10:15:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 942CB58D2B; Fri, 30 Apr 2004 10:15:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from utnapashtim.gksag.de (utnapashtim.gksag.de [212.218.229.194]) by segue.merit.edu (Postfix) with ESMTP id A88D858D27 for ; Fri, 30 Apr 2004 10:15:09 -0400 (EDT) Received: from gkshfd03.gksag.net ([172.18.1.35]) by utnapashtim.gksag.de (8.12.5/8.12.5/Debian-1) with ESMTP id i3UDJjkM009608 for ; Fri, 30 Apr 2004 15:19:45 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42EBD.87C8C538" Subject: [AAA-WG]: Questions on RFC 3588 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 30 Apr 2004 16:15:03 +0200 Message-ID: <64F95EC22E92334EA21188664F36A48224E452@gkshfd03.gksag.net> Thread-Topic: Questions on RFC 3588 Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1A== From: "Wiehe Ulrich" To: Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C42EBD.87C8C538 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear experts, =20 Your help in answering the following questions with regard to RFC 3588 = is very much appreciated: =20 3GPP have defined a vendor-specific Diameter-Application (3GPP Cx Rel-5) = for which IANA has allocated an application-Id (167772151). Now 3GPP are in = the process of defining a new version of this application (3GPP Cx Rel-6). = The new version is an extension of the old version,i.e. nodes supporting the = new version do also support the old version. The new version does not = replace the old version, i.e. interworking between nodes supporting only the old = version and nodes supporting the old and the new version is required. =20 Let us assume that the difference between the old version and the new = version is that a new AVP is added to a command and this AVP has the M-bit set. =20 The first question is: Is it necessary to get a new application-Id = allocated by IANA for the new version, or is it possible for both versions to = share the same (already allocated) application-Id, and to achieve interoperability between the two versions by means of the mechanism defined in RFC 3588 section 4.1 (description of the 'M' bit), i.e. the node sending the new mandatory AVP must be prepared to receive error code 5001 (unsupported = AVP) and re-send the command in a Rel-5 compliant form? =20 Here are some quotes from RFC 3588 which you might want to consider when answering the question: =20 -In section 1.1: "AVPs may be added arbitrarily to Diameter messages, so = long as the required AVPs are included and AVPs that are explicitly excluded = are not included."=20 -In section 1.2.3:" Should a new Diameter usage scenario find itself = unable to fit within an existing application without requiring major changes to = the specification, it may be desirable to create a new Diameter application. Major changes to an application include: - Adding new AVPs to the = command, which have the "M" bit set." -In section 1.2.3:"Creation of a new application should be viewed as a = last resort." =20 =20 The second question is similar: If the difference between the old = version and the new version is that an existing mandatory AVP is removed from a command is it then necessary to get a new application-Id allocated, or = can interoperability be achieved in the way that the node omitting the = mandatory AVP must be prepared to receive error 5005 (missing AVP) and re-send the command in a Rel-5 compliant form? =20 The last question: If the difference beween the old version and the new version is that a new command is added is it then necessary to get a new application-Id allocated, or can interoperability be achieved in the way = that the node sending the new command must be prepared to receive the error = 3001 (unsupported command) and fall back to Rel-5? =20 Thank you for your help. =20 =20 Ulrich Wiehe=20 =20 GKS AG =20 Gesellschaft f=FCr=20 Kommunikations Software Tel:+496621 169139 MMC2 Fax:+49 6621 169 122 Breitenstr. 57 Mobil: +49 151 14016088 D-36251 Bad Hersfeld e-mail: ulrich.wiehe@gksag.de =20 =20 =20 ------_=_NextPart_001_01C42EBD.87C8C538 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear experts,

 

Your help in answering the following questions = with regard to RFC 3588 is very much appreciated:

 

3GPP have defined a vendor-specific Diameter-Application (3GPP Cx Rel-5) for which IANA has allocated an application-Id (167772151). Now=A0 3GPP are = in the process of defining a new version of this application (3GPP Cx Rel-6). = The new version is an extension of the old version,i.e. nodes supporting the new version do also support the old version. The new version does not = replace the old version, i.e. interworking between nodes supporting only the old = version and nodes supporting the old and the new version is = required.

 

Let us assume that the difference between the = old version and the new version is that a new AVP is added to a command and = this AVP has the M-bit set.

 

The first question is: Is it necessary to get = a new application-Id allocated by IANA for the new version, or is it possible = for both versions to share the same (already allocated) application-Id, and = to achieve interoperability between the two versions by means of the = mechanism defined in RFC 3588 section 4.1 (description of the ‘M’ = bit), i.e. the node sending the new mandatory AVP must be prepared to receive error = code 5001 (unsupported AVP) and re-send the command in a Rel-5 compliant = form?

 

Here are some quotes from RFC 3588 which you = might want to consider when answering the question:

 

-In section 1.1: “AVPs may be added = arbitrarily to Diameter messages, so long as the required AVPs are included and AVPs = that are explicitly excluded are not included.”

-In section 1.2.3:” Should a new Diameter usage scenario find = itself unable to fit within an existing application without requiring major = changes to the specification, it may be desirable to create a new Diameter = application.=A0 Major changes to an application include:=A0=A0 -=A0 Adding new AVPs to = the command, which have the "M" bit set.”

-In section 1.2.3:”Creation of a new = application should be viewed as a last resort.”=A0

=A0

The second question=A0 is similar: If the = difference between the old version and the new version is that an existing = mandatory AVP is removed from a command is it then necessary to get a new = application-Id allocated, or can interoperability be achieved in the way that the node omitting = the mandatory AVP must be prepared to receive error 5005 (missing AVP) and = re-send the command in a Rel-5 compliant form?

 

The last question: If the difference beween = the old version and the new version is that a new command is added is it then necessary = to get a new application-Id allocated, or can interoperability be achieved in = the way that the node sending the new command must be prepared to receive the = error 3001 (unsupported command)=A0 and fall back to Rel-5?

 

Thank you for your help.

 

 

Ulrich Wiehe =

 

GKS = AG=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0

Gesellschaft f=FCr

Kommunikations = Software=A0=A0=A0=A0=A0=A0=A0=A0 Tel:+496621 169139

MMC2       &= nbsp;   =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 Fax:+49 6621 169 122

Breitenstr. = 57=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 Mobil: +49 151 14016088

D-36251 Bad Hersfeld=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 e-mail: ulrich.wiehe@gksag.de<= /font>

 

 

=00 ------_=_NextPart_001_01C42EBD.87C8C538-- From owner-aaa-wg@merit.edu Fri Apr 30 11:29:40 2004 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 LAA08471 for ; Fri, 30 Apr 2004 11:29:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 393CD91216; Fri, 30 Apr 2004 11:29:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 00CD391227; Fri, 30 Apr 2004 11:29:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E8E3F91216 for ; Fri, 30 Apr 2004 11:29:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C99A758EE4; Fri, 30 Apr 2004 11:29:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 2B60758EE2 for ; Fri, 30 Apr 2004 11:29:22 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i3UFYIF19929; Fri, 30 Apr 2004 08:34:18 -0700 Date: Fri, 30 Apr 2004 08:34:18 -0700 (PDT) From: Bernard Aboba To: MCarmen Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: question on Diameter In-Reply-To: <40925A8D.6050306@madrid.ericsson.se> Message-ID: References: <40925A8D.6050306@madrid.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I don't think this makes sense. The peers announce all their capabilities in the CER/CEA and this is typically something that does not change on the fly. In what scenario would the fundamental capabilities of the peers change in mid-connection? Upgrade on the fly? In a situation where firmware is upgraded, connections will typically go down and the peer will announce its new capabilities and negotiate them within the CER/CEA. Even if a peer is upgraded on the fly without going down, the right answer is probably to bring up other connections, negotiate CER/CEA, and if they are upgraded, drop the existing connections. This could be an issue with RFC 3588 because Diameter only allows one connection at a time between two peers. So I think you'd need to bring down a connection between two peers to re-negotiate CER/CEA between them. On Fri, 30 Apr 2004, MCarmen wrote: > Hi all, > > Just a question on RFC3588. In the CER/CEA chapter it is said: > > " When two Diameter peers establish a transport connection, they MUST > exchange the Capabilities Exchange messages, as specified in the peer > state machine (see Section 5.6). This message allows the discovery of a > peer's identity and its capabilities (protocol version number, supported > Diameter applications, security mechanisms, etc.) " > > Is it possible to exchange again the Capabilities Exchange messages once > the connection is already established to modify my capabilities? > > thanks, > MCarmen > From owner-aaa-wg@merit.edu Fri Apr 30 11:37:17 2004 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 LAA09277 for ; Fri, 30 Apr 2004 11:37:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2FB5391227; Fri, 30 Apr 2004 11:37:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E968C9126D; Fri, 30 Apr 2004 11:37:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C4F8691227 for ; Fri, 30 Apr 2004 11:37:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ABABE58D2B; Fri, 30 Apr 2004 11:37:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 1FB7958EAF for ; Fri, 30 Apr 2004 11:37:02 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3UFauH07120; Fri, 30 Apr 2004 18:36:56 +0300 (EET DST) X-Scanned: Fri, 30 Apr 2004 18:34:43 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3UFYhHw026184; Fri, 30 Apr 2004 18:34:43 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00O6pe5D; Fri, 30 Apr 2004 18:34:42 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3UFYfH25961; Fri, 30 Apr 2004 18:34:41 +0300 (EET DST) Received: from saemailgw02.europe.nokia.com ([10.40.2.12]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Apr 2004 18:34:38 +0300 Received: from ptspilot22v.pts.nokia.com (saenonep22.europe.nokia.com [10.40.32.79]) by saemailgw02.europe.nokia.com (8.11.7p1+Sun/8.11.7) with ESMTP id i3UFYVC22067; Fri, 30 Apr 2004 18:34:31 +0300 (EEST) Message-ID: <24583448.1083339220990.JavaMail.pts@ptspilot22v.pts.nokia.com> Date: Fri, 30 Apr 2004 18:33:40 +0300 (EEST) From: Loughney John To: ext Bernard Aboba , MCarmen Subject: Re: [AAA-WG]: question on Diameter Cc: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Apr 2004 15:34:38.0004 (UTC) FILETIME=[A59C5740:01C42EC8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree. Can someone give an example of how or why a peer's capabilities would change mid-session? John From owner-aaa-wg@merit.edu Fri Apr 30 12:02:35 2004 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 MAA11365 for ; Fri, 30 Apr 2004 12:02:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 002A39126D; Fri, 30 Apr 2004 12:02:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BFC9F912A6; Fri, 30 Apr 2004 12:02:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4A4A89126D for ; Fri, 30 Apr 2004 12:02:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C15A058D14; Fri, 30 Apr 2004 12:02:21 -0400 (EDT) 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 36C7F58E28 for ; Fri, 30 Apr 2004 12:02:21 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3UG2C418267 for ; Fri, 30 Apr 2004 11:02:12 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Apr 2004 11:02:13 -0500 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597530686B6D6@zrc2c012.us.nortel.com> From: "Christopher Richards" To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Fri, 30 Apr 2004 11:02:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42ECC.7F454A30" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C42ECC.7F454A30 Content-Type: text/plain Hi All, Quick question I'm sure has been answered before. When sending a RADIUS VSA AVP (code 26) in a Diameter message, should the Diameter AVP header have the Vendor-Specific bit set (and so include the Vendor-Id field)? Or should the vendor-id be part of the AVP data (As it is in RADIUS)? My interpretation is that since AVP code 26 is not a Diameter vendor specific AVP code - but is a RADIUS defined AVP, so that the Vendor-Specific bit is NOT set in the Diameter AVP header. RADIUS encoding of AVP code 26:- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Vendor-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (cont) | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Diameter encoding of a RADIUS VSA AVP (code 26):- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags = 0 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diameter AVP Data field... +-+-+-+-+-+-+-+-+-+-+-+..... Where the Diameter AVP data field is:- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor type | Vendor length | Vendor Data field.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...... Is this the intention of RFC3588? Best Regards, Chris. ------_=_NextPart_001_01C42ECC.7F454A30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi All,

Quick question I'm sure has been answered = before.

When sending a RADIUS VSA AVP (code 26) in a Diameter = message, should the Diameter AVP header have the Vendor-Specific bit = set (and so include the Vendor-Id field)? Or should the vendor-id be = part of the AVP data (As it is in RADIUS)?

My interpretation is that since AVP code 26 is not a = Diameter vendor specific AVP code - but is a RADIUS defined AVP, so = that the Vendor-Specific bit is NOT set in the Diameter AVP = header.

RADIUS encoding of AVP code 26:-

    = 0            = ;       = 1            = ;       = 2            = ;       3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   |     = Type      |  = Length       = |            = Vendor-Id
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
        Vendor-Id = (cont)           = |  String...
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Diameter encoding of a RADIUS VSA AVP (code = 26):-

    = 0            = ;       = 1            = ;       = 2            = ;       3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   | Type =3D = 26           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;     |
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   | Flags =3D 0     = |      = Length           =             =             = |
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   | Diameter AVP Data field...
   +-+-+-+-+-+-+-+-+-+-+-+.....

Where the Diameter AVP data field is:-

    = 0            = ;       = 1            = ;       = 2            = ;       3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   | = Vendor-Id          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;      |
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   | Vendor type   | Vendor = length | Vendor Data field....
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-......

Is this the intention of RFC3588?

Best Regards,
Chris.

------_=_NextPart_001_01C42ECC.7F454A30-- From owner-aaa-wg@merit.edu Fri Apr 30 15:27:14 2004 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 PAA24824 for ; Fri, 30 Apr 2004 15:27:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0BA6191249; Fri, 30 Apr 2004 15:27:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C5372912A6; Fri, 30 Apr 2004 15:27:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CB95D91249 for ; Fri, 30 Apr 2004 15:27:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB5B958DBD; Fri, 30 Apr 2004 15:27:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 226AB58D2F for ; Fri, 30 Apr 2004 15:27:02 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i3UJW0U01293 for ; Fri, 30 Apr 2004 12:32:00 -0700 Date: Fri, 30 Apr 2004 12:32:00 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: CORRECTION: IETF Last Call on EAP State Machine Document Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The IESG has received a request from the EAP Working Group to consider the following document for publication as an Informational RFC: "State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator" The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. IETF Last Call will run until May 13, 2004. Please send comments to iesg@ietf.org, and cc: eap@frascone.com, the EAP WG mailing list. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-03.pdf http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-03.txt Comments should be sent in the Issues format specified on the EAP WG issues page: http://www.drizzle.com/~aboba/EAP/eapissues.html From owner-aaa-wg@merit.edu Fri Apr 30 16:17:59 2004 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 QAA27954 for ; Fri, 30 Apr 2004 16:17:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0BFE9912A6; Fri, 30 Apr 2004 16:17:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C34EF912A9; Fri, 30 Apr 2004 16:17:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 521AD912A6 for ; Fri, 30 Apr 2004 16:17:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3685A58DAA; Fri, 30 Apr 2004 16:17:44 -0400 (EDT) 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 A674F58DC7 for ; Fri, 30 Apr 2004 16:17:43 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3UKHfX11128 for ; Fri, 30 Apr 2004 15:17:41 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Apr 2004 15:17:42 -0500 Message-ID: <161AA64DA85DFC4BA4D2EB5629B59753068D6305@zrc2c012.us.nortel.com> From: "Christopher Richards" To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC: CLIENT, SESSION BASED State Machine Date: Fri, 30 Apr 2004 15:17:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42EF0.309B5914" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C42EF0.309B5914 Content-Type: text/plain Hi All, In the CLIENT, SESSION BASED state machine description in section 7 there is the following event-state pair. 7. Credit Control Application State Machine ... CLIENT, SESSION BASED for the first interrogation with CCR State Event Action New State ---------------------------------------------------------------- ... PendingI Failure to send, or Grant Idle temporary error and service to CCFH equal to CONTINUE end user ... CLIENT, SESSION BASED for intermediate and final interrogations State Event Action New State ---------------------------------------------------------------- ... PendingU Failure to send, or Grant Idle temporary error and service to CCFH equal to CONTINUE end user ... Would it not be better to grant some limited service usage to the end user and move to the Open state. This will then allow the DCC client to re-authorise the used service at a later time when it may pass. E.g. State Event Action New State ---------------------------------------------------------------- ... PendingI Failure to send, or Grant Open temporary error and limited CCFH equal to CONTINUE service to end user ... CLIENT, SESSION BASED for intermediate and final interrogations State Event Action New State ---------------------------------------------------------------- ... PendingU Failure to send, or Grant Open temporary error and limited CCFH equal to CONTINUE service to end user ... Cheers, Chris. ------_=_NextPart_001_01C42EF0.309B5914 Content-Type: text/html Content-Transfer-Encoding: quoted-printable [AAA-WG]: DCC: CLIENT, SESSION BASED State Machine

Hi All,

In the CLIENT, SESSION BASED state machine = description in section 7 there is the following event-state = pair.

7. Credit Control Application State Machine  =
...
       CLIENT, SESSION = BASED for the first interrogation with CCR 
   
     = State      = Event           &= nbsp;           &= nbsp;  Action       New State  =
     = ----------------------------------------------------------------  =
...
     PendingI  Failure to = send, = or            = Grant        Idle 
          &nb= sp;    temporary error = and            = service = to            =
          &nb= sp;    CCFH equal to = CONTINUE         end user  =
...
 
      CLIENT, SESSION BASED = for intermediate and final interrogations 
     = State     = Event           &= nbsp;           &= nbsp;  Action       New State  =
     = ----------------------------------------------------------------  =
...
     PendingU  Failure to = send, = or            = Grant        Idle 
          &nb= sp;    temporary error = and            = service to 
          &nb= sp;    CCFH equal to = CONTINUE         end user  =
...

Would it not be better to grant some limited service = usage to the end user and move to the Open state. This will then allow = the DCC client to re-authorise the used service at a later time when it = may pass. E.g.

     = State      = Event           &= nbsp;           &= nbsp;  Action       New State  =
     = ----------------------------------------------------------------  =
...
     PendingI  Failure to = send, = or            = Grant         Open  =
          &nb= sp;    temporary error = and            = limited           = ;
          &nb= sp;    CCFH equal to = CONTINUE         service = to
          &nb= sp;           &nb= sp;           &nb= sp;           end = user 
...
      CLIENT, SESSION BASED = for intermediate and final interrogations 
     = State     = Event           &= nbsp;           &= nbsp;  Action       New State  =
     = ----------------------------------------------------------------  =
...
     PendingU  Failure to = send, = or            = Grant        Open 
          &nb= sp;    temporary error = and            = limited 
          &nb= sp;    CCFH equal to = CONTINUE         service = to
          &nb= sp;           &nb= sp;           &nb= sp;           end = user 
...

Cheers,
Chris.

------_=_NextPart_001_01C42EF0.309B5914-- From owner-aaa-wg@merit.edu Fri Apr 30 16:30:39 2004 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 QAA28819 for ; Fri, 30 Apr 2004 16:30:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0066E912AA; Fri, 30 Apr 2004 16:30:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB7FD912A9; Fri, 30 Apr 2004 16:30:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F553912AA for ; Fri, 30 Apr 2004 16:30:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E1F9458D7B; Fri, 30 Apr 2004 16:30:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h002.c000.snv.cp.net [209.228.32.66]) by segue.merit.edu (Postfix) with SMTP id 4246958C20 for ; Fri, 30 Apr 2004 16:30:13 -0400 (EDT) Received: (cpmta 19713 invoked from network); 30 Apr 2004 13:30:08 -0700 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.66) with SMTP; 30 Apr 2004 13:30:08 -0700 X-Sent: 30 Apr 2004 20:30:08 GMT Message-Id: <5.2.1.1.2.20040430161158.060e0b90@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 30 Apr 2004 16:29:35 -0400 To: "Christopher Richards" , aaa-wg@merit.edu From: David Mitton Subject: Re: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs In-Reply-To: <161AA64DA85DFC4BA4D2EB5629B597530686B6D6@zrc2c012.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk On 4/30/2004 11:02 AM -0500, Christopher Richards wrote: >Hi All, > >Quick question I'm sure has been answered before. > >When sending a RADIUS VSA AVP (code 26) in a Diameter message, should the >Diameter AVP header have the Vendor-Specific bit set (and so include the >Vendor-Id field)? Or should the vendor-id be part of the AVP data (As it >is in RADIUS)? > >My interpretation is that since AVP code 26 is not a Diameter vendor >specific AVP code - but is a RADIUS defined AVP, so that the >Vendor-Specific bit is NOT set in the Diameter AVP header. > >RADIUS encoding of AVP code 26:- > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Vendor-Id > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Vendor-Id (cont) | String... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >Diameter encoding of a RADIUS VSA AVP (code 26):- > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 26 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flags = 0 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Diameter AVP Data field... > +-+-+-+-+-+-+-+-+-+-+-+..... > >Where the Diameter AVP data field is:- > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor-Id | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor type | Vendor length | Vendor Data field.... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...... > >Is this the intention of RFC3588? Chris, RFC3588 does not address this issue or any RADIUS interaction. You need to look at draft-ietf-aaa-diameter-nasreq-14.txt Or my latest copy of draft 15 http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-15.txt In particular section 9, RADIUS Interactions, and more specific to your question section 9.6.2 page 71. 9.6.2. Forwarding a RADIUS VSA to a Diameter Vendor AVP 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 NOTE: that the VSAs are considered as optional by RADIUS rules, and this specification does not set the Mandatory flag. If a VSA is desired to be made mandatory, because it represents a required service policy, the RADIUS gateway should have a process to set the bit on the Diameter side. 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. The intention is that the Diameter VSA mechanism get used in the obvious way when interacting with a RADIUS application that follows the "SHOULD" format of attribute 26. Non-standard VSA formats fall on the optional capability of the gateway. Any round-trip interaction should have equivalent transforms, to the best manner possible. >When sending a RADIUS VSA AVP (code 26) in a Diameter message, should the >Diameter AVP header have the Vendor-Specific bit set (and so include the >Vendor-Id field)? Or should the vendor-id be part of the AVP data (As it >is in RADIUS)? The vendor bit should be set, and the vendor-id value is provided by the VSA(26) format. >My interpretation is that since AVP code 26 is not a Diameter vendor >specific AVP code - but is a RADIUS defined AVP, so that the >Vendor-Specific bit is NOT set in the Diameter AVP header. That would cause RADIUS vendor defined attributes to appear to be Diameter standard AVPs. This is not a desirable representation. The RADIUS attribute code 26 (VSA) is explicitly listed as prohibited in section 9.4. Dave. From owner-aaa-wg@merit.edu Fri Apr 30 17:27:10 2004 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 RAA05009 for ; Fri, 30 Apr 2004 17:27:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6363A91218; Fri, 30 Apr 2004 17:26:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2CFC191220; Fri, 30 Apr 2004 17:26:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5643991218 for ; Fri, 30 Apr 2004 17:26:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 40C7458E25; Fri, 30 Apr 2004 17:26:52 -0400 (EDT) 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 CBE8658E24 for ; Fri, 30 Apr 2004 17:26:51 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3ULQlX15498; Fri, 30 Apr 2004 16:26:47 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Apr 2004 16:26:47 -0500 Message-ID: <161AA64DA85DFC4BA4D2EB5629B59753068D6507@zrc2c012.us.nortel.com> From: "Christopher Richards" To: David Mitton , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Fri, 30 Apr 2004 16:26:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42EF9.D709EBA4" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C42EF9.D709EBA4 Content-Type: text/plain Thanks Dave. Does the NASREQ draft apply to non-NASREQ Diameter applications? Specifically, RFC3588 does not say that RADIUS code 26 is prohibited. Should your description be added to the errata of RFC3588? Cheers, Chris. -----Original Message----- From: David Mitton [mailto:david@mitton.com] Sent: Friday, April 30, 2004 3:30 PM To: Richards, Christopher [RICH2:2Q40:EXCH]; aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs On 4/30/2004 11:02 AM -0500, Christopher Richards wrote: >Hi All, > >Quick question I'm sure has been answered before. > >When sending a RADIUS VSA AVP (code 26) in a Diameter message, should >the >Diameter AVP header have the Vendor-Specific bit set (and so include the >Vendor-Id field)? Or should the vendor-id be part of the AVP data (As it >is in RADIUS)? > >My interpretation is that since AVP code 26 is not a Diameter vendor >specific AVP code - but is a RADIUS defined AVP, so that the >Vendor-Specific bit is NOT set in the Diameter AVP header. > >RADIUS encoding of AVP code 26:- > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Vendor-Id > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Vendor-Id (cont) | String... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >Diameter encoding of a RADIUS VSA AVP (code 26):- > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 26 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flags = 0 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Diameter AVP Data field... > +-+-+-+-+-+-+-+-+-+-+-+..... > >Where the Diameter AVP data field is:- > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor-Id | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor type | Vendor length | Vendor Data field.... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...... > >Is this the intention of RFC3588? Chris, RFC3588 does not address this issue or any RADIUS interaction. You need to look at draft-ietf-aaa-diameter-nasreq-14.txt Or my latest copy of draft 15 http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-15.txt In particular section 9, RADIUS Interactions, and more specific to your question section 9.6.2 page 71. 9.6.2. Forwarding a RADIUS VSA to a Diameter Vendor AVP 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 NOTE: that the VSAs are considered as optional by RADIUS rules, and this specification does not set the Mandatory flag. If a VSA is desired to be made mandatory, because it represents a required service policy, the RADIUS gateway should have a process to set the bit on the Diameter side. 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. The intention is that the Diameter VSA mechanism get used in the obvious way when interacting with a RADIUS application that follows the "SHOULD" format of attribute 26. Non-standard VSA formats fall on the optional capability of the gateway. Any round-trip interaction should have equivalent transforms, to the best manner possible. >When sending a RADIUS VSA AVP (code 26) in a Diameter message, should >the >Diameter AVP header have the Vendor-Specific bit set (and so include the >Vendor-Id field)? Or should the vendor-id be part of the AVP data (As it >is in RADIUS)? The vendor bit should be set, and the vendor-id value is provided by the VSA(26) format. >My interpretation is that since AVP code 26 is not a Diameter vendor >specific AVP code - but is a RADIUS defined AVP, so that the >Vendor-Specific bit is NOT set in the Diameter AVP header. That would cause RADIUS vendor defined attributes to appear to be Diameter standard AVPs. This is not a desirable representation. The RADIUS attribute code 26 (VSA) is explicitly listed as prohibited in section 9.4. Dave. ------_=_NextPart_001_01C42EF9.D709EBA4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Thanks Dave.

Does the NASREQ draft apply to non-NASREQ Diameter = applications?

Specifically, RFC3588 does not say that RADIUS code = 26 is prohibited.

Should your description be added to the errata of = RFC3588?

Cheers,
Chris.

-----Original Message-----
From: David Mitton [mailto:david@mitton.com]
Sent: Friday, April 30, 2004 3:30 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]; = aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Diameter encoding of RADIUS = VSA AVPs


On 4/30/2004 11:02 AM -0500, Christopher Richards = wrote:

>Hi All,
>
>Quick question I'm sure has been answered = before.
>
>When sending a RADIUS VSA AVP (code 26) in a = Diameter message, should
>the
>Diameter AVP header have the Vendor-Specific bit = set (and so include the
>Vendor-Id field)? Or should the vendor-id be = part of the AVP data (As it
>is in RADIUS)?
>
>My interpretation is that since AVP code 26 is = not a Diameter vendor
>specific AVP code - but is a RADIUS defined AVP, = so that the
>Vendor-Specific bit is NOT set in the Diameter = AVP header.
>
>RADIUS encoding of AVP code 26:-
>
>     = 0            = ;       = 1            = ;       = 2            = ;       3
>     0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
>    |     = Type      |  = Length       = |            = Vendor-Id
>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
>         = Vendor-Id = (cont)           = |  String...
>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>
>Diameter encoding of a RADIUS VSA AVP (code = 26):-
>
>     = 0            = ;       = 1            = ;       = 2            = ;       3
>     0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
>    | Type =3D = 26           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;     |
>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
>    | Flags =3D = 0     |      = Length           =             =             = |
>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
>    | Diameter AVP Data = field...
>    = +-+-+-+-+-+-+-+-+-+-+-+.....
>
>Where the Diameter AVP data field is:-
>
>     = 0            = ;       = 1            = ;       = 2            = ;       3
>     0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
>    | = Vendor-Id          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;      |
>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
>    | Vendor type   | = Vendor length | Vendor Data field....
>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-......
>
>Is this the intention of RFC3588?

Chris,
         = RFC3588 does not address this issue or any RADIUS interaction. You need = to look at draft-ietf-aaa-diameter-nasreq-14.txt

Or my latest copy of draft 15 http://www.circularnetworks.com/draft-ietf-aaa-diamete= r-nasreq-15.txt


In particular section 9, RADIUS Interactions, and = more specific to your
question section 9.6.2 page 71.

9.6.2.  Forwarding a RADIUS VSA to a Diameter = Vendor AVP

    The Diameter AVP will consist of = the following fields;
       Diameter Flags: = V=3D1, M=3D0, P=3D0
       Diameter Vendor = code =3D RADIUS VSA Vendor code
       Diameter AVP = code =3D RADIUS VSA Vendor type code
       Diameter AVP = length =3D length of AVP (header + data + padding)
       Diameter Data = =3D RADIUS VSA vendor data

    NOTE: that the VSAs are considered = as optional by RADIUS rules, and
    this specification does not set = the Mandatory flag.  If a VSA is
    desired to be made mandatory, = because it represents a required
    service policy, the RADIUS = gateway should have a process to set the
    bit on the Diameter side.

    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.

<end quote>

The intention is that the Diameter VSA mechanism get = used in the obvious
way when interacting with a RADIUS application that = follows the "SHOULD"
format of attribute 26.  Non-standard VSA = formats fall on the optional
capability of the gateway.

Any round-trip interaction should have equivalent = transforms, to the best
manner possible.

>When sending a RADIUS VSA AVP (code 26) in a = Diameter message, should
>the
>Diameter AVP header have the Vendor-Specific bit = set (and so include the
>Vendor-Id field)? Or should the vendor-id be = part of the AVP data (As it
>is in RADIUS)?

The vendor bit should be set, and the vendor-id value = is provided by the
VSA(26) format.


>My interpretation is that since AVP code 26 is = not a Diameter vendor
>specific AVP code - but is a RADIUS defined AVP, = so that the
>Vendor-Specific bit is NOT set in the Diameter = AVP header.

That would cause RADIUS vendor defined attributes to = appear to be Diameter
standard AVPs.  This is not a desirable = representation.

The RADIUS attribute code 26 (VSA) is explicitly = listed as prohibited in
section 9.4.

Dave.


------_=_NextPart_001_01C42EF9.D709EBA4-- From owner-aaa-wg@merit.edu Fri Apr 30 18:18:47 2004 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 SAA09284 for ; Fri, 30 Apr 2004 18:18:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7C50C91220; Fri, 30 Apr 2004 18:18:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 47F12912AB; Fri, 30 Apr 2004 18:18:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3FED091220 for ; Fri, 30 Apr 2004 18:18:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2779E58CFD; Fri, 30 Apr 2004 18:18:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h000.c000.snv.cp.net [209.228.32.64]) by segue.merit.edu (Postfix) with SMTP id 9DC8958D9F for ; Fri, 30 Apr 2004 18:18:31 -0400 (EDT) Received: (cpmta 15960 invoked from network); 30 Apr 2004 15:18:30 -0700 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.64) with SMTP; 30 Apr 2004 15:18:30 -0700 X-Sent: 30 Apr 2004 22:18:30 GMT Message-Id: <5.2.1.1.2.20040430181746.03328890@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 30 Apr 2004 18:18:10 -0400 To: aaa-wg@merit.edu From: David Mitton Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk On 4/30/2004 04:26 PM -0500, Christopher Richards wrote: >Thanks Dave. > >Does the NASREQ draft apply to non-NASREQ Diameter applications? > >Specifically, RFC3588 does not say that RADIUS code 26 is prohibited. > >Should your description be added to the errata of RFC3588? > >Cheers, >Chris. No. NASreq is intended to be the generic RADIUS "replacement" within Diameter. A RADIUS interaction such as VSAs is properly addressed there. Even as it is, NASreq Section 9 does not explicitly address all potential RADIUS interaction problems. We are certainly not going to backfill it into RFC 3588. The Diameter drafts/RFCs are purposely segmented so that they may get finished within our useful lifetimes. Expect more application bolt-ons, not less. Dave. From uresabinastancel@poczta.onet.pl Fri Apr 30 20:01:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14177 for ; Fri, 30 Apr 2004 20:01:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJhwY-00047k-0R for aaa-archive@ietf.org; Fri, 30 Apr 2004 20:01:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJhvZ-00040n-00 for aaa-archive@ietf.org; Fri, 30 Apr 2004 20:00:21 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJhub-0003vZ-00 for aaa-archive@ietf.org; Fri, 30 Apr 2004 19:59:21 -0400 Received: from adsl-68-127-118-130.dsl.frsn02.pacbell.net ([68.127.118.130] helo=68.161.236.244) by mx2.foretec.com with smtp (Exim 4.24) id 1BJhuZ-0005EK-Sl for aaa-archive@ietf.org; Fri, 30 Apr 2004 19:59:22 -0400 Received: from relay2.abacus-direct.com (relay2.abacus-direct.com [64.213.215.61]) by mercury.chadwyck.co.uk with smtp; מאי, 01 2004 1:28:53 +0300 From: kfyybentz To: Undisclosed.Recipients Subject: additional income-more joy ybp Sender: kfyybentz Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-8" Date: Sat, 1 May 2004 02:58:11 +0200 X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-Priority: 1 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=25.9 required=5.0 tests=DOMAIN_4U2, FAKED_UNDISC_RECIPS,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML, FORGED_OUTLOOK_TAGS,FORGED_RCVD_NET_HELO,HTML_50_60, HTML_FONTCOLOR_UNKNOWN,HTML_FONT_BIG,HTML_FONT_INVISIBLE, HTML_IMAGE_ONLY_04,HTML_MESSAGE,HTML_TAG_BALANCE_BODY, HTML_TAG_BALANCE_HTML,LINES_OF_YELLING,MIME_HTML_ONLY, RCVD_NUMERIC_HELO,TO_HAS_SPACES,TO_MALFORMED,TRACKER_ID,WITH_LC_SMTP, WORK_AT_HOME,X_PRIORITY_HIGH autolearn=no version=2.60 X-Spam-Report: * 0.5 X_PRIORITY_HIGH Sent with 'X-Priority' set to high * 2.7 FAKED_UNDISC_RECIPS Faked To "Undisclosed-Recipients" * 2.4 TO_HAS_SPACES To: address contains spaces * 0.3 TO_MALFORMED To: has a malformed address * 4.3 WITH_LC_SMTP Received line contains spam-sign (lowercase smtp) * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.6 DOMAIN_4U2 BODY: Domain name containing a "4u" variant * 1.3 WORK_AT_HOME BODY: Information on how to work at home (1) * 3.5 TRACKER_ID BODY: Incorporates a tracking ID number * 0.1 HTML_FONTCOLOR_UNKNOWN BODY: HTML font color is unknown to us * 0.3 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.4 HTML_TAG_BALANCE_HTML BODY: HTML has unbalanced "html" tags * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.4 HTML_FONT_INVISIBLE BODY: HTML font color is same as background * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook

Hi   aaa oygbt

the way you see it:
GET AN INCOME - DESERVING YOUR SKILLS !!!


bmdc
click picture for details

 
NOTICE: This is a one time message.
You have received this e-mail because you expressed interest in career and employment information.
In case you suppose this mail has reached your mailbox by an error, we certainly apologize.
remove


51915xijwfog work from home-no limits swaqyamsuuxjphovcbufukmmnxe