From owner-aaa-wg@merit.edu Mon Mar 1 07:01: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 HAA12900 for ; Mon, 1 Mar 2004 07:01:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4AF7291261; Mon, 1 Mar 2004 07:01:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 169F091262; Mon, 1 Mar 2004 07:01:05 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CC77E91261 for ; Mon, 1 Mar 2004 07:01:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 33B805DFDA; Mon, 1 Mar 2004 07:01:02 -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 04F015DF9B for ; Mon, 1 Mar 2004 07:01:00 -0500 (EST) 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 i21C0t004064 for ; Mon, 1 Mar 2004 14:00:55 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 14:00:07 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i21C07XV020649 for ; Mon, 1 Mar 2004 14:00:07 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00UVZjeY; Mon, 01 Mar 2004 14:00:07 EET 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 i21C06O02841 for ; Mon, 1 Mar 2004 14:00:06 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 14:00:05 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 14:00:04 +0200 Received: from trebe002.NOE.Nokia.com ([172.22.232.173]) by esebe022.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 14:00:04 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FF84.BB408CC2" Subject: [AAA-WG]: DCC: Issue: Editorial - Chapter 3.2 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 1 Mar 2004 14:00:03 +0200 Message-ID: <573ED33A76FA194F90B377FA16E900EC0EA0DC@trebe002.europe.nokia.com> Thread-Topic: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Thread-Index: AcP8Z1uyzklKcTdeT4+Q972g+fhocADGZzMQ From: To: X-OriginalArrivalTime: 01 Mar 2004 12:00:04.0917 (UTC) FILETIME=[BBDE2650:01C3FF84] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FF84.BB408CC2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Description of issue : The acronym "AVP" is present in some AVP names. Submitter name: J-P Koskinen=20 Submitter email address: = juha-pekka.koskinen@ nokia.com=20 Date first submitted: 01 Mar 2004=20 Reference:=20 Document: Diameter Credit Control -03=20 Comment type: E=20 Priority: S =20 Section: 3.2=20 Rationale/Explanation of issue: The acronym "AVP" is present in = Redirect-Host, Redirect-Host-Usage and Redirect-Max-Cache-Time AVP = names. It should be removed. =20 Requested change: =20 =20 Section 3.2 =20 =20 FROM : ::=3D < Diameter Header: 272, PXY >=20 < Session-Id >=20 { Result-Code }=20 { Origin-Host }=20 { Origin-Realm }=20 { Auth-Application-Id }=20 { CC-Request-Type }=20 { CC-Request-Number }=20 [ User-Name ]=20 [ CC-Session-Failover ]=20 [ CC-Sub-Session-Id ]=20 [ Acct-Multi-Session-Id ]=20 [ Origin-State-Id ]=20 [ Event-Timestamp ]=20 [ Subscription-Id ] =20 [ Granted-Service-Unit ]=20 *[ Multiple-Services-Credit-Control ] = =20 [ Cost-Information] =20 [ Final-Unit-Indication ] =20 [ Check-Balance-Result ] =20 [ Credit-Control-Failure-Handling ]=20 [ Direct-Debiting-Failure-Handling ] = [ Validity-Time]=20 [ Redirect-Host AVP ]=20 [ Redirect-Host-Usage AVP ]=20 [ Redirect-Max-Cache-Time AVP ]=20 *[ Proxy-Info ]=20 *[ Route-Record ]=20 *[ AVP ]=20 =20 TO: =20 ::=3D < Diameter Header: 272, PXY >=20 < Session-Id >=20 { Result-Code }=20 { Origin-Host }=20 { Origin-Realm }=20 { Auth-Application-Id }=20 { CC-Request-Type }=20 { CC-Request-Number }=20 [ User-Name ]=20 [ CC-Session-Failover ]=20 [ CC-Sub-Session-Id ]=20 [ Acct-Multi-Session-Id ]=20 [ Origin-State-Id ]=20 [ Event-Timestamp ]=20 [ Subscription-Id ] =20 [ Granted-Service-Unit ]=20 *[ Multiple-Services-Credit-Control ] = =20 [ Cost-Information] =20 [ Final-Unit-Indication ] =20 [ Check-Balance-Result ] =20 [ Credit-Control-Failure-Handling ]=20 [ Direct-Debiting-Failure-Handling ] = [ Validity-Time]=20 [ Redirect-Host ]=20 [ Redirect-Host-Usage ]=20 [ Redirect-Max-Cache-Time ]=20 *[ Proxy-Info ]=20 *[ Route-Record ]=20 *[ AVP ] =20 ------_=_NextPart_001_01C3FF84.BB408CC2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DCC: Inclusion of IMEI in Subscription-Id-Type AVP
Description of issue :   The acronym "AVP" is present = in=20 some AVP names.
Submitter name:  J-P = Koskinen 
Submitter email address:  juha-pekka.koskinen@ nokia.com
Date first submitted:  01 Mar 2004 =
Reference:
Document: Diameter Credit=20 Control  -03 
Comment = type:  E 
Priority:  S =20
Section:  3.2 
Rationale/Explanation of issue: The acronym "AVP" is present in = Redirect-Host,=20 Redirect-Host-Usage and Redirect-Max-Cache-Time AVP names. It = should be=20 removed.
 
 Requested = change:  
 
 Section  3.2  
 
 FROM :
     <Credit-Control-Answer> ::=3D < Diameter = Header: 272,=20 PXY >=20
           &nb= sp;           &nbs= p;           =20 < Session-Id >=20
           &nb= sp;           &nbs= p;           =20 { Result-Code }=20
           &nb= sp;           &nbs= p;           =20 { Origin-Host }=20
           &nb= sp;           &nbs= p;           =20 { Origin-Realm }=20
           &nb= sp;           &nbs= p;           =20 { Auth-Application-Id }=20
           &nb= sp;           &nbs= p;           =20 { CC-Request-Type }=20
           &nb= sp;           &nbs= p;           =20 { CC-Request-Number }=20
           &nb= sp;           &nbs= p;           =20 [ User-Name ]=20
           &nb= sp;           &nbs= p;           =20 [ CC-Session-Failover ]=20
           &nb= sp;           &nbs= p;           =20 [ CC-Sub-Session-Id ]=20
           &nb= sp;           &nbs= p;           =20 [ Acct-Multi-Session-Id ]=20
           &nb= sp;           &nbs= p;           =20 [ Origin-State-Id ]=20
           &nb= sp;           &nbs= p;           =20 [ Event-Timestamp ]=20
           &nb= sp;           &nbs= p;           =20 [ Subscription-Id ] =20
           &nb= sp;           &nbs= p;           =20 [ Granted-Service-Unit ]=20
           &nb= sp;           &nbs= p;          =20 *[ Multiple-Services-Credit-Control ] =20
           &nb= sp;           &nbs= p;           =20 [ Cost-Information] =20
           &nb= sp;           &nbs= p;           =20 [ Final-Unit-Indication ] =20
           &nb= sp;           &nbs= p;           =20 [ Check-Balance-Result ] =20
           &nb= sp;           &nbs= p;           =20 [ Credit-Control-Failure-Handling ]=20
           &nb= sp;           &nbs= p;           =20 [ Direct-Debiting-Failure-Handling ]=20
           &nb= sp;           &nbs= p;           =20 [ Validity-Time]=20
           &nb= sp;           &nbs= p;           =20 [ Redirect-Host AVP ]=20
           &nb= sp;           &nbs= p;           =20 [ Redirect-Host-Usage AVP ]=20
           &nb= sp;           &nbs= p;           =20 [ Redirect-Max-Cache-Time AVP ]=20
           &nb= sp;           &nbs= p;          =20 *[ Proxy-Info ]=20
           &nb= sp;           &nbs= p;          =20 *[ Route-Record ]=20
           &nb= sp;           &nbs= p;          =20 *[ AVP ]
          &nbs= p; =20
TO:  
 <Credit-Control-Answer> ::=3D < Diameter Header: = 272, PXY=20 >=20
           &nb= sp;           &nbs= p;           =20 < Session-Id >=20
           &nb= sp;           &nbs= p;           =20 { Result-Code }=20
           &nb= sp;           &nbs= p;           =20 { Origin-Host }=20
           &nb= sp;           &nbs= p;           =20 { Origin-Realm }=20
           &nb= sp;           &nbs= p;           =20 { Auth-Application-Id }=20
           &nb= sp;           &nbs= p;           =20 { CC-Request-Type }=20
           &nb= sp;           &nbs= p;           =20 { CC-Request-Number }=20
           &nb= sp;           &nbs= p;           =20 [ User-Name ]=20
           &nb= sp;           &nbs= p;           =20 [ CC-Session-Failover ]=20
           &nb= sp;           &nbs= p;           =20 [ CC-Sub-Session-Id ]=20
           &nb= sp;           &nbs= p;           =20 [ Acct-Multi-Session-Id ]=20
           &nb= sp;           &nbs= p;           =20 [ Origin-State-Id ]=20
           &nb= sp;           &nbs= p;           =20 [ Event-Timestamp ]=20
           &nb= sp;           &nbs= p;           =20 [ Subscription-Id ] =20
           &nb= sp;           &nbs= p;           =20 [ Granted-Service-Unit ]=20
           &nb= sp;           &nbs= p;          =20 *[ Multiple-Services-Credit-Control ] =20
           &nb= sp;           &nbs= p;           =20 [ Cost-Information] =20
           &nb= sp;           &nbs= p;           =20 [ Final-Unit-Indication ] =20
           &nb= sp;           &nbs= p;           =20 [ Check-Balance-Result ] =20
           &nb= sp;           &nbs= p;           =20 [ Credit-Control-Failure-Handling ]=20
           &nb= sp;           &nbs= p;           =20 [ Direct-Debiting-Failure-Handling ]=20
           &nb= sp;           &nbs= p;           =20 [ Validity-Time]=20
           &nb= sp;           &nbs= p;           =20 [ Redirect-Host ]=20
           &nb= sp;           &nbs= p;           =20 [ Redirect-Host-Usage ]=20
           &nb= sp;           &nbs= p;           =20 [ Redirect-Max-Cache-Time ]=20
           &nb= sp;           &nbs= p;          =20 *[ Proxy-Info ]=20
           &nb= sp;           &nbs= p;          =20 *[ Route-Record ]=20
           &nb= sp;           &nbs= p;          =20 *[ AVP ]  
------_=_NextPart_001_01C3FF84.BB408CC2-- From owner-aaa-wg@merit.edu Mon Mar 1 07:08: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 HAA13418 for ; Mon, 1 Mar 2004 07:08:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DF0DB91263; Mon, 1 Mar 2004 07:08:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 747EF91264; Mon, 1 Mar 2004 07:08:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9589291263 for ; Mon, 1 Mar 2004 07:08:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 64B535DFEE; Mon, 1 Mar 2004 07:08:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 87E5D5DFDA for ; Mon, 1 Mar 2004 07:08:25 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i21C8OqY014636 for ; Mon, 1 Mar 2004 13:08:24 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Mar 2004 13:08:24 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 1 Mar 2004 13:08:57 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'juha-pekka.koskinen@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Editorial - Chapter 3.2 Date: Mon, 1 Mar 2004 13:08:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FF85.4D3D289A" X-OriginalArrivalTime: 01 Mar 2004 12:08:24.0292 (UTC) FILETIME=[E584BA40:01C3FF85] 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_01C3FF85.4D3D289A Content-Type: text/plain; charset="iso-8859-1" Hi, Issue 26 assigned. regards............harri -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of juha-pekka.koskinen@nokia.com Sent: 1. maaliskuuta 2004 14:00 To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC: Issue: Editorial - Chapter 3.2 Description of issue : The acronym "AVP" is present in some AVP names. Submitter name: J-P Koskinen Submitter email address: juha-pekka.koskinen@ nokia.com Date first submitted: 01 Mar 2004 Reference: Document: Diameter Credit Control -03 Comment type: E Priority: S Section: 3.2 Rationale/Explanation of issue: The acronym "AVP" is present in Redirect-Host, Redirect-Host-Usage and Redirect-Max-Cache-Time AVP names. It should be removed. Requested change: Section 3.2 FROM : ::= < Diameter Header: 272, PXY > < Session-Id > { Result-Code } { Origin-Host } { Origin-Realm } { Auth-Application-Id } { CC-Request-Type } { CC-Request-Number } [ User-Name ] [ CC-Session-Failover ] [ CC-Sub-Session-Id ] [ Acct-Multi-Session-Id ] [ Origin-State-Id ] [ Event-Timestamp ] [ Subscription-Id ] [ Granted-Service-Unit ] *[ Multiple-Services-Credit-Control ] [ Cost-Information] [ Final-Unit-Indication ] [ Check-Balance-Result ] [ Credit-Control-Failure-Handling ] [ Direct-Debiting-Failure-Handling ] [ Validity-Time] [ Redirect-Host AVP ] [ Redirect-Host-Usage AVP ] [ Redirect-Max-Cache-Time AVP ] *[ Proxy-Info ] *[ Route-Record ] *[ AVP ] TO: ::= < Diameter Header: 272, PXY > < Session-Id > { Result-Code } { Origin-Host } { Origin-Realm } { Auth-Application-Id } { CC-Request-Type } { CC-Request-Number } [ User-Name ] [ CC-Session-Failover ] [ CC-Sub-Session-Id ] [ Acct-Multi-Session-Id ] [ Origin-State-Id ] [ Event-Timestamp ] [ Subscription-Id ] [ Granted-Service-Unit ] *[ Multiple-Services-Credit-Control ] [ Cost-Information] [ Final-Unit-Indication ] [ Check-Balance-Result ] [ Credit-Control-Failure-Handling ] [ Direct-Debiting-Failure-Handling ] [ Validity-Time] [ Redirect-Host ] [ Redirect-Host-Usage ] [ Redirect-Max-Cache-Time ] *[ Proxy-Info ] *[ Route-Record ] *[ AVP ] This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3FF85.4D3D289A Content-Type: text/html; charset="iso-8859-1" DCC: Inclusion of IMEI in Subscription-Id-Type AVP
Hi,
 
Issue 26 assigned.
 
regards............harri
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of juha-pekka.koskinen@nokia.com
Sent: 1. maaliskuuta 2004 14:00
To: aaa-wg@merit.edu
Subject: [AAA-WG]: DCC: Issue: Editorial - Chapter 3.2

Description of issue :   The acronym "AVP" is present in some AVP names.
Submitter name:  J-P Koskinen 
Submitter email address:  juha-pekka.koskinen@ nokia.com
Date first submitted:  01 Mar 2004
Reference:
Document: Diameter Credit Control  -03 
Comment type:  E 
Priority:  S 
Section:  3.2 
Rationale/Explanation of issue: The acronym "AVP" is present in Redirect-Host, Redirect-Host-Usage and Redirect-Max-Cache-Time AVP names. It should be removed.
 
 Requested change:  
 
 Section  3.2  
 
 FROM :
     <Credit-Control-Answer> ::= < Diameter Header: 272, PXY >
                                    < Session-Id >
                                    { Result-Code }
                                    { Origin-Host }
                                    { Origin-Realm }
                                    { Auth-Application-Id }
                                    { CC-Request-Type }
                                    { CC-Request-Number }
                                    [ User-Name ]
                                    [ CC-Session-Failover ]
                                    [ CC-Sub-Session-Id ]
                                    [ Acct-Multi-Session-Id ]
                                    [ Origin-State-Id ]
                                    [ Event-Timestamp ]
                                    [ Subscription-Id ] 
                                    [ Granted-Service-Unit ]
                                   *[ Multiple-Services-Credit-Control ] 
                                    [ Cost-Information] 
                                    [ Final-Unit-Indication ] 
                                    [ Check-Balance-Result ] 
                                    [ Credit-Control-Failure-Handling ]
                                    [ Direct-Debiting-Failure-Handling ]
                                    [ Validity-Time]
                                    [ Redirect-Host AVP ]
                                    [ Redirect-Host-Usage AVP ]
                                    [ Redirect-Max-Cache-Time AVP ]
                                   *[ Proxy-Info ]
                                   *[ Route-Record ]
                                   *[ AVP ]
            
TO:  
 <Credit-Control-Answer> ::= < Diameter Header: 272, PXY >
                                    < Session-Id >
                                    { Result-Code }
                                    { Origin-Host }
                                    { Origin-Realm }
                                    { Auth-Application-Id }
                                    { CC-Request-Type }
                                    { CC-Request-Number }
                                    [ User-Name ]
                                    [ CC-Session-Failover ]
                                    [ CC-Sub-Session-Id ]
                                    [ Acct-Multi-Session-Id ]
                                    [ Origin-State-Id ]
                                    [ Event-Timestamp ]
                                    [ Subscription-Id ] 
                                    [ Granted-Service-Unit ]
                                   *[ Multiple-Services-Credit-Control ] 
                                    [ Cost-Information] 
                                    [ Final-Unit-Indication ] 
                                    [ Check-Balance-Result ] 
                                    [ Credit-Control-Failure-Handling ]
                                    [ Direct-Debiting-Failure-Handling ]
                                    [ Validity-Time]
                                    [ Redirect-Host ]
                                    [ Redirect-Host-Usage ]
                                    [ Redirect-Max-Cache-Time ]
                                   *[ Proxy-Info ]
                                   *[ Route-Record ]
                                   *[ AVP ]  

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
------_=_NextPart_001_01C3FF85.4D3D289A-- From owner-aaa-wg@merit.edu Mon Mar 1 07:14: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 HAA13867 for ; Mon, 1 Mar 2004 07:14:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 51FFC91262; Mon, 1 Mar 2004 07:14:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21BE391264; Mon, 1 Mar 2004 07:14:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E53C091262 for ; Mon, 1 Mar 2004 07:14:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id B63495E012; Mon, 1 Mar 2004 07:14:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id BA7FB5DFF9 for ; Mon, 1 Mar 2004 07:14:16 -0500 (EST) 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 i21CEFT09264 for ; Mon, 1 Mar 2004 14:14:15 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 14:13:22 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i21CDMcP015774 for ; Mon, 1 Mar 2004 14:13:22 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 002JAPvj; Mon, 01 Mar 2004 14:13:20 EET 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 i21CDKO08710 for ; Mon, 1 Mar 2004 14:13:20 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 14:13:19 +0200 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]: DCC Issue: missing Validity-Time, Result-Code and Final-Unit explanation in M-S-C-C AVP x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 1 Mar 2004 14:13:19 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C84E5@esebe016.ntc.nokia.com> Thread-Topic: DCC Issue: missing Validity-Time, Result-Code and Final-Unit explanation in M-S-C-C AVP Thread-Index: AcP/hpTJ16S0e9sIRD+XG6a7G/ERtw== From: To: X-OriginalArrivalTime: 01 Mar 2004 12:13:19.0827 (UTC) FILETIME=[95ABCA30:01C3FF86] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Description of issue: missing Validity-Time, Result-Code and Final-Unit = explanation in M-S-C-C AVP Submitter name: Marco Stura Date first submitted: 1.03.2004=20 Reference:=20 Document: draft-ietf-aaa-diameter-cc-03.txt=20 Comment type: E Priority: 1=20 Section: 8.16 Rationale/Explanation of issues:=20 In section 8.16 M-S-C-C AVP we do not mention how to use Validity-time = AVP, Result-Code or Final-Unit-Indication AVP. Reference to the sections = 5.1.1 and 5.6 should be added. Requested change: -Section 8.16 ADD after the fourth paragraph The Validity-Time, Result-Code and Final-Unit-Indication AVPs MAY be=20 present in an answer command as defined in section 5.1.1 and 5.6 for the graceful service termination. From owner-aaa-wg@merit.edu Mon Mar 1 07:15: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 HAA13907 for ; Mon, 1 Mar 2004 07:15:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DD77091267; Mon, 1 Mar 2004 07:14:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 78ECE91265; Mon, 1 Mar 2004 07:14:57 -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 5C9AA91264 for ; Mon, 1 Mar 2004 07:14:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 47A965DFF9; Mon, 1 Mar 2004 07:14:56 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 8C1FE5E011 for ; Mon, 1 Mar 2004 07:14:55 -0500 (EST) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21CEsT10369 for ; Mon, 1 Mar 2004 14:14:54 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 14:13:22 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i21CDMwp023231 for ; Mon, 1 Mar 2004 14:13:22 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Cd9Cit; Mon, 01 Mar 2004 14:13:22 EET 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 i21CDL702086 for ; Mon, 1 Mar 2004 14:13:21 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 14:13:21 +0200 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]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 1 Mar 2004 14:13:22 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C84E6@esebe016.ntc.nokia.com> Thread-Topic: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure Thread-Index: AcP/hpZ4vKU6IAAFQTmkb88Eac0NIw== From: To: X-OriginalArrivalTime: 01 Mar 2004 12:13:21.0510 (UTC) FILETIME=[96AC9860:01C3FF86] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Description of issue: addition of *[AVP] notation in the M-S-C-C AVP = structure Submitter name: Marco Stura Date first submitted: 1.03.2004=20 Reference:=20 Document: draft-ietf-aaa-diameter-cc-03.txt=20 Comment type: T Priority: 1=20 Section: 8.16 Rationale/Explanation of issues:=20 In order to define a more future proof structure I propose to add the = *[AVP] notation to the M-S-C-C AVP structure. According to the Base (section 4.4.1) the = Grouped AVP can contain *[AVP]. Requested change: -Section 8.16 ADD the *[ AVP ] notation to the AVP structure Multiple-Services-Credit-Control ::=3D < AVP Header: 456 > =20 [ Granted-Service-Unit ]=20 [ Requested-Service-Units ] = *[ Used-Service-Units ]=20 [ Tariff-Change-Usage ] =20 *[ Service-Identifier ] =20 [ Rating-Group ] =20 *[ G-S-U-Pool-Reference ] =20 [ Validity-Time ] =20 [ Result-Code ] =20 [ Final-Unit-Indication ]=20 *[ AVP ] From owner-aaa-wg@merit.edu Mon Mar 1 07:15: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 HAA13971 for ; Mon, 1 Mar 2004 07:15:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1051891264; Mon, 1 Mar 2004 07:15:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8C18591265; Mon, 1 Mar 2004 07:15:01 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8D54091264 for ; Mon, 1 Mar 2004 07:14:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 51BC65DFF9; Mon, 1 Mar 2004 07:14:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 49D3E5E016 for ; Mon, 1 Mar 2004 07:14:56 -0500 (EST) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21CEsT10380 for ; Mon, 1 Mar 2004 14:14:55 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 14:13:16 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i21CDGhh022922 for ; Mon, 1 Mar 2004 14:13:16 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00GOk80B; Mon, 01 Mar 2004 14:13:14 EET 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 i21CDD701965 for ; Mon, 1 Mar 2004 14:13:13 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 14:13:13 +0200 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]: DCC Issue: clarification of R-S-U AVP usage in multiple services feature x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 1 Mar 2004 14:13:13 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C84E4@esebe016.ntc.nokia.com> Thread-Topic: DCC Issue: clarification of R-S-U AVP usage in multiple services feature Thread-Index: AcP/hpGamMovGTMYS32J1ZvgTQz3FQ== From: To: X-OriginalArrivalTime: 01 Mar 2004 12:13:13.0647 (UTC) FILETIME=[91FCCBF0:01C3FF86] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Description of issue: clarification of R-S-U AVP usage in multiple = services feature Submitter name: Marco Stura Date first submitted: 1.03.2004=20 Reference:=20 Document: draft-ietf-aaa-diameter-cc-03.txt=20 Comment type: T=20 Priority: 1=20 Section: 5.2, 5.3, 8.16 and Flow X=20 Rationale/Explanation of issues:=20 When independent credit control of multiple services within a = (sub-)session is used, the Requested-Service-Unit AVP is used by the = client to indicate to the server that quota is requested for the = service/rating-group associated to it. The Requested-service-Unit AVP is to be present in all the intermediate = interrogations sent for the service/rating-group if quota is still = requested. If quota is not requested anymore, for instance the client = determined that the service was terminated by the user, this is = indicated by the absence of the R-S-U AVP in the request command. The usage of the R-S-U AVP is not clearly specified in draft 03, thus = different interpretation of its usage may cause potential = interoperability problems between client and servers of different = vendors. For instance, a client may send an intermediate interrogation = without R-S-U AVP even though it actually requests a new quota. The = server may not returns quota because it expects the R-S-U AVP to be = present in the request when quota is wanted. Requested change: -Section 5.2 second paragraph FROM If the Diameter credit-control client knows the cost of the service=20 event (e.g. a content server delivering ringing tones may know their=20 cost) the monetary amount to be charged is included in the Requested- Service-Unit AVP. If the Diameter credit-control client does not know = the cost of the service event, the Requested-Service-Unit AVP MAY=20 contain the number of requested service events. The = Service-Identifier=20 AVP, in case of multiple services the Service-Identifier AVP or the=20 Rating-Group AVP within the Multiple-Services-Credit-Control AVP,=20 always indicates 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. TO If the Diameter credit-control client knows the cost of the service=20 event (e.g. a content server delivering ringing tones may know their=20 cost) the monetary amount to be charged is included in the Requested- Service-Unit AVP. If the Diameter credit-control client does not know = the cost of the service event, the Requested-Service-Unit AVP MAY=20 contain the number of requested service events. Where the Multiple- Services-Credit-Control AVP is used, it MUST contain the Requested- Service-Unit AVP to indicate that quota for the associated service/ rating-group is requested. The Service-Identifier AVP, in case of=20 multiple services the Service-Identifier AVP or the Rating-Group AVP=20 within the Multiple-Services-Credit-Control AVP, always indicates the = concerned service. Additional service event information to be rated=20 MAY be sent as service specific AVPs or MAY be sent within the=20 Service-Parameter-Info AVP at command level. -Section 5.3 fifth paragraph FROM The Requested-Service-Unit AVP MAY contain the new amount of = requested=20 service units. The Used-Service-Unit AVP contains the amount of used=20 service units measured from the point when the service became active=20 or, in case of interim interrogations are used during the session,=20 from the point when the previous measurement ended. The same unit=20 types that are used in the previous message MUST be used. If several=20 unit types were included in the previous answer message the used=20 service units for each unit type MUST be reported. =20 TO The Requested-Service-Unit AVP MAY contain the new amount of = requested=20 service units. Where the Multiple-Services-Credit-Control AVP is = used,=20 it MUST contain the Requested-Service-Unit AVP if new quota for the=20 associated service/rating-group is requested. The Used-Service-Unit = AVP=20 contains the amount of used service units measured from the point = when=20 the service became active or, in case of interim interrogations are=20 used during the session, from the point when the previous measurement = ended. The same unit types that are used in the previous message MUST = be used. If several unit types were included in the previous answer=20 message the used service units for each unit type MUST be reported. =20 -Section 8.16 ADD after third paragrapf The Requested-Service-Unit AVP MAY contain the amount of requested=20 service units or the requested monetary value. It MUST be present in the initial interrogation and within the intermediate interrogations where new quota is requested. If the credit-control client does not include the Requested-Service-Unit AVP in a request command, for instance because it has determined that the end-user terminated the service, the server MUST debit the used amount from the user's = account but MUST NOT return a new quota in the corresponding answer. - Flow X add the R-S-U AVP in message 11 and 13 as follow. | +--------------+ | | =20 | |Validity time | |(11)CCR(update, | =20 | |expires for | | Multiple-Services-CC ( | =20 | |Service-Id | | Requested-Units(), | | | access | | Used-Units(In-Octets,Out-Octets),|=20 | +--------------+ | Service-Id access)) |=20 | |---------------------------------------->| =20 | |(12)CCA(Multiple-Services-CC ( |=20 | | Granted-Units(Total-Octets), | =20 | | Service-Id access, | =20 | | Validity-time, |=20 | | G-S-U-Pool-Reference(Pool-Id 1, | =20 | | Multiplier 10))) |=20 | |<----------------------------------------| =20 : : : =20 : : : =20 | +--------------+ | | =20 | |Total Quota | |(13)CCR(update, | =20 | |elapses for | | Multiple-Services-CC ( | =20 | |pool 2: | | Requested-Units(), | | |service 4 not | | Used-Units(In-Octets,Out-Octets),|=20 | |allowed, | | Service-Id 3, Rating-group 2), |=20 | |service 3 cont| | Multiple-Services-CC ( | =20 | +--------------+ | Used-Units(In-Octets,Out-Octets),|=20 | | Service-Id 4, Rating-group 3)) |=20 | |---------------------------------------->| =20 | |(14)CCA(Multiple-Services-CC ( |=20 | | Result-Code 4011, | =20 | | Service-Id 3)) |=20 | |<----------------------------------------| =20 From owner-aaa-wg@merit.edu Mon Mar 1 07:17:51 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 HAA14237 for ; Mon, 1 Mar 2004 07:17:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 25C3091269; Mon, 1 Mar 2004 07:17:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E385E9126A; Mon, 1 Mar 2004 07:17:38 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 74A6791269 for ; Mon, 1 Mar 2004 07:17:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0D7FE5DFD4; Mon, 1 Mar 2004 07:17:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 88F075DFC1 for ; Mon, 1 Mar 2004 07:17:35 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i21CHYqY017359 for ; Mon, 1 Mar 2004 13:17:34 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Mar 2004 13:17:34 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 1 Mar 2004 13:18:08 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'marco.stura@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in mul tiple services feature Date: Mon, 1 Mar 2004 13:17:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Mar 2004 12:17:34.0805 (UTC) FILETIME=[2DA65850:01C3FF87] Sender: owner-aaa-wg@merit.edu Precedence: bulk assigned issue 23. / harri > -----Original Message----- > From: owner-aaa-wg@merit.edu > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > marco.stura@nokia.com > Sent: 1. maaliskuuta 2004 14:13 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in > multiple services feature > > > Description of issue: clarification of R-S-U AVP usage in > multiple services feature > Submitter name: Marco Stura > Date first submitted: 1.03.2004 > Reference: > Document: draft-ietf-aaa-diameter-cc-03.txt > Comment type: T > Priority: 1 > Section: 5.2, 5.3, 8.16 and Flow X > > Rationale/Explanation of issues: > > When independent credit control of multiple services within a > (sub-)session is used, the Requested-Service-Unit AVP is used > by the client to indicate to the server that quota is > requested for the service/rating-group associated to it. > > The Requested-service-Unit AVP is to be present in all the > intermediate interrogations sent for the service/rating-group > if quota is still requested. If quota is not requested > anymore, for instance the client determined that the service > was terminated by the user, this is indicated by the absence > of the R-S-U AVP in the request command. > > The usage of the R-S-U AVP is not clearly specified in draft > 03, thus different interpretation of its usage may cause > potential interoperability problems between client and > servers of different vendors. For instance, a client may send > an intermediate interrogation without R-S-U AVP even though > it actually requests a new quota. The server may not returns > quota because it expects the R-S-U AVP to be present in the > request when quota is wanted. > > Requested change: > > -Section 5.2 second paragraph > > FROM > > > If the Diameter credit-control client knows the cost of > the service > event (e.g. a content server delivering ringing tones may > know their > cost) the monetary amount to be charged is included in the > Requested- > Service-Unit AVP. If the Diameter credit-control client > does not know > the cost of the service event, the Requested-Service-Unit AVP MAY > contain the number of requested service events. The > Service-Identifier > AVP, in case of multiple services the Service-Identifier > AVP or the > Rating-Group AVP within the Multiple-Services-Credit-Control AVP, > always indicates the concerned service. Additional service event > information to be rated MAY be sent as service specific > AVPs or MAY be > sent within the Service-Parameter-Info AVP at command level. > > TO > > If the Diameter credit-control client knows the cost of > the service > event (e.g. a content server delivering ringing tones may > know their > cost) the monetary amount to be charged is included in the > Requested- > Service-Unit AVP. If the Diameter credit-control client > does not know > the cost of the service event, the Requested-Service-Unit AVP MAY > contain the number of requested service events. Where the Multiple- > Services-Credit-Control AVP is used, it MUST contain the Requested- > Service-Unit AVP to indicate that quota for the associated service/ > rating-group is requested. The Service-Identifier AVP, in case of > multiple services the Service-Identifier AVP or the > Rating-Group AVP > within the Multiple-Services-Credit-Control AVP, always > indicates the > concerned service. Additional service event information > to be rated > MAY be sent as service specific AVPs or MAY be sent within the > Service-Parameter-Info AVP at command level. > > -Section 5.3 fifth paragraph > > FROM > > > The Requested-Service-Unit AVP MAY contain the new amount > of requested > service units. The Used-Service-Unit AVP contains the > amount of used > service units measured from the point when the service > became active > or, in case of interim interrogations are used during the session, > from the point when the previous measurement ended. The same unit > types that are used in the previous message MUST be used. > If several > unit types were included in the previous answer message the used > service units for each unit type MUST be reported. > > TO > > > The Requested-Service-Unit AVP MAY contain the new amount > of requested > service units. Where the Multiple-Services-Credit-Control > AVP is used, > it MUST contain the Requested-Service-Unit AVP if new > quota for the > associated service/rating-group is requested. The > Used-Service-Unit AVP > contains the amount of used service units measured from > the point when > the service became active or, in case of interim > interrogations are > used during the session, from the point when the previous > measurement > ended. The same unit types that are used in the previous > message MUST > be used. If several unit types were included in the > previous answer > message the used service units for each unit type MUST be reported. > > -Section 8.16 > > ADD after third paragrapf > > The Requested-Service-Unit AVP MAY contain the amount of requested > service units or the requested monetary value. It MUST be > present in > the initial interrogation and within the intermediate > interrogations > where new quota is requested. If the credit-control client does not > include the Requested-Service-Unit AVP in a request command, for > instance because it has determined that the end-user terminated the > service, the server MUST debit the used amount from the > user's account > but MUST NOT return a new quota in the corresponding answer. > > - Flow X add the R-S-U AVP in message 11 and 13 as follow. > > | +--------------+ | | > | |Validity time | |(11)CCR(update, | > | |expires for | | Multiple-Services-CC ( | > | |Service-Id | | Requested-Units(), | > | | access | | Used-Units(In-Octets,Out-Octets),| > | +--------------+ | Service-Id access)) | > | > |---------------------------------------->| > | |(12)CCA(Multiple-Services-CC ( | > | | Granted-Units(Total-Octets), | > | | Service-Id access, | > | | Validity-time, | > | | G-S-U-Pool-Reference(Pool-Id 1, | > | | Multiplier 10))) | > | |<----------------------------------------| > : : : > : : : > | +--------------+ | | > | |Total Quota | |(13)CCR(update, | > | |elapses for | | Multiple-Services-CC ( | > | |pool 2: | | Requested-Units(), | > | |service 4 not | | Used-Units(In-Octets,Out-Octets),| > | |allowed, | | Service-Id 3, Rating-group 2), | > | |service 3 cont| | Multiple-Services-CC ( | > | +--------------+ | Used-Units(In-Octets,Out-Octets),| > | | Service-Id 4, Rating-group 3)) | > | > |---------------------------------------->| > | |(14)CCA(Multiple-Services-CC ( | > | | Result-Code 4011, | > | | Service-Id 3)) | > | |<----------------------------------------| > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-aaa-wg@merit.edu Mon Mar 1 07:18: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 HAA14327 for ; Mon, 1 Mar 2004 07:18:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F334A91268; Mon, 1 Mar 2004 07:18:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BCC0C91265; Mon, 1 Mar 2004 07:18:20 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5564891268 for ; Mon, 1 Mar 2004 07:18:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F7175DFBB; Mon, 1 Mar 2004 07:18:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 769C75DFDA for ; Mon, 1 Mar 2004 07:18:18 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i21CIHqY017601 for ; Mon, 1 Mar 2004 13:18:17 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Mar 2004 13:18:17 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 1 Mar 2004 13:18:51 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'marco.stura@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC Issue: missing Validity-Time, Result-Code and F inal-Unit explanation in M-S-C-C AVP Date: Mon, 1 Mar 2004 13:18:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Mar 2004 12:18:17.0737 (UTC) FILETIME=[473D3F90:01C3FF87] Sender: owner-aaa-wg@merit.edu Precedence: bulk assigned issue 24. / harri > -----Original Message----- > From: owner-aaa-wg@merit.edu > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > marco.stura@nokia.com > Sent: 1. maaliskuuta 2004 14:13 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: DCC Issue: missing Validity-Time, Result-Code and > Final-Unit explanation in M-S-C-C AVP > > > Description of issue: missing Validity-Time, Result-Code and > Final-Unit explanation in M-S-C-C AVP > Submitter name: Marco Stura > Date first submitted: 1.03.2004 > Reference: > Document: draft-ietf-aaa-diameter-cc-03.txt > Comment type: E > Priority: 1 > Section: 8.16 > > Rationale/Explanation of issues: > > In section 8.16 M-S-C-C AVP we do not mention how to use > Validity-time AVP, Result-Code or Final-Unit-Indication AVP. > Reference to the sections 5.1.1 and 5.6 should be added. > > Requested change: > > -Section 8.16 > > ADD after the fourth paragraph > > The Validity-Time, Result-Code and Final-Unit-Indication > AVPs MAY be > present in an answer command as defined in section 5.1.1 > and 5.6 for > the graceful service termination. > > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-aaa-wg@merit.edu Mon Mar 1 07:19: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 HAA14393 for ; Mon, 1 Mar 2004 07:19:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 70F4B91265; Mon, 1 Mar 2004 07:18:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3EA309126B; Mon, 1 Mar 2004 07:18:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B0F4E91265 for ; Mon, 1 Mar 2004 07:18:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4C38C5DFE0; Mon, 1 Mar 2004 07:18:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 91AA35DFD9 for ; Mon, 1 Mar 2004 07:18:47 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i21CIkqY017708 for ; Mon, 1 Mar 2004 13:18:47 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Mar 2004 13:18:46 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 1 Mar 2004 13:19:20 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'marco.stura@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C -C AVP structure Date: Mon, 1 Mar 2004 13:18:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Mar 2004 12:18:46.0837 (UTC) FILETIME=[58958E50:01C3FF87] Sender: owner-aaa-wg@merit.edu Precedence: bulk assigned issue 25. / harri > -----Original Message----- > From: owner-aaa-wg@merit.edu > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > marco.stura@nokia.com > Sent: 1. maaliskuuta 2004 14:13 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: DCC Issue: addition of *[AVP] notation in > the M-S-C-C > AVP structure > > > Description of issue: addition of *[AVP] notation in the > M-S-C-C AVP structure > Submitter name: Marco Stura > Date first submitted: 1.03.2004 > Reference: > Document: draft-ietf-aaa-diameter-cc-03.txt > Comment type: T > Priority: 1 > Section: 8.16 > > Rationale/Explanation of issues: > > In order to define a more future proof structure I propose to > add the *[AVP] notation > to the M-S-C-C AVP structure. According to the Base (section > 4.4.1) the Grouped AVP can contain *[AVP]. > > Requested change: > > -Section 8.16 > > ADD the *[ AVP ] notation to the AVP structure > > > Multiple-Services-Credit-Control ::= < AVP Header: 456 > > [ Granted-Service-Unit ] > [ > Requested-Service-Units ] > *[ Used-Service-Units ] > [ Tariff-Change-Usage ] > *[ Service-Identifier ] > [ Rating-Group ] > *[ G-S-U-Pool-Reference ] > [ Validity-Time ] > [ Result-Code ] > [ Final-Unit-Indication ] > *[ AVP ] > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From mailman-admin@ietf.org Mon Mar 1 09:14:24 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 JAA20826 for ; Mon, 1 Mar 2004 09:14:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxoB9-0004wk-Lw for aaa-archive@lists.ietf.org; Mon, 01 Mar 2004 09:13:55 -0500 Date: Mon, 01 Mar 2004 09:13:55 -0500 Message-ID: <20040301141355.27462.98980.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 exim@www1.ietf.org Mon Mar 1 09:25: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 JAA23238 for ; Mon, 1 Mar 2004 09:25:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxoLX-0005r3-0N for aaa-archive@odin.ietf.org; Mon, 01 Mar 2004 09:24:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21EOc8r022499 for aaa-archive@odin.ietf.org; Mon, 1 Mar 2004 09:24:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxoLW-0005qk-IQ for aaa-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 09:24: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 JAA23097 for ; Mon, 1 Mar 2004 09:24:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxoLU-0000b8-00 for aaa-web-archive@ietf.org; Mon, 01 Mar 2004 09:24:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axo8T-00052h-00 for aaa-web-archive@ietf.org; Mon, 01 Mar 2004 09:11:12 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Axo24-0003Nw-02 for aaa-web-archive@ietf.org; Mon, 01 Mar 2004 09:04:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Axo03-0007JP-Ba for aaa-web-archive@ietf.org; Mon, 01 Mar 2004 09:02:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axo02-0001OU-57 for aaa-web-archive@ietf.org; Mon, 01 Mar 2004 09:02:26 -0500 Date: Mon, 01 Mar 2004 09:02:26 -0500 Message-ID: <20040301140226.27462.40079.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 owner-aaa-wg@merit.edu Mon Mar 1 10:59: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 KAA12578 for ; Mon, 1 Mar 2004 10:59:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B152491279; Mon, 1 Mar 2004 10:58:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 520A991280; Mon, 1 Mar 2004 10:58:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CF7B191279 for ; Mon, 1 Mar 2004 10:57:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id B90A55E06F; Mon, 1 Mar 2004 10:57:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailsweep01.vodafone.ie (unknown [213.233.159.70]) by segue.merit.edu (Postfix) with ESMTP id BB0545E0C7 for ; Mon, 1 Mar 2004 10:57:47 -0500 (EST) Received: from eircellnotes5.eircell.ie (unverified) by mailsweep01.vodafone.ie (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Mon, 1 Mar 2004 15:57:07 +0000 To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John.Prudhoe@vodafone.com Date: Mon, 1 Mar 2004 15:52:30 +0000 X-MIMETrack: Serialize by Router on Notes5/Vodafone(Release 5.0.10 |March 22, 2002) at 03/01/2004 03:52:31 PM, Serialize complete at 03/01/2004 03:52:31 PM Content-Type: multipart/alternative; boundary="=_alternative 005731BA80256E4A_=" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005731BA80256E4A_= Content-Type: text/plain; charset="us-ascii" Description of issue: Client Support of Tariff Change Mechanism Submitter name: John Prudhoe Date first submitted: 1.03.2004 Reference: Document: draft-ietf-aaa-diameter-cc-03.txt Comment type: E Priority: Section: 8.27 Rationale/Explanation of issues: In section 5.1 it is only specified that the client SHOULD support the tariff change mechanism and the itemising of usage using the Tariff-Change-Usage AVP. I believe the last sentence of section 8.27 (Tariff-Change-Usage AVP) is meant to support this, but it is not clear. My suggested change is in section 8.27: FROM Omission of this AVP means that no tariff change has been occurred. TO If the client does not support the itemisation of tariff change usage, when the Tariff-Time-Change AVP was present in the previous answer, this AVP MUST be omitted. Regards, John. In the last paragraph of 5.1 (p16 of cc-03) change SHOULD to MUST ****************************************************************************** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination, disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages of this kind. The opinions, conclusions and other information in this message are of the author and shall be understood as neither given nor endorsed by Vodafone Ireland Limited unless it is otherwise indicated by an authorised representative independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone Ireland Limited has no control. As such, there is no guarantee that (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender (iii) this e-mail has not been intercepted by a third party (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this message (including its attachments) has been processed by an automated anti-virus system; however it is the responsibility of the recipient to ensure that the message (and attachments) are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18. Number 326967 VAT Reg No. IE6346967G ****************************************************************************** --=_alternative 005731BA80256E4A_= Content-Type: text/html; charset="us-ascii"
Description of issue:  Client Support of Tariff Change Mechanism
Submitter name:  John Prudhoe
Date first submitted: 1.03.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-03.txt
Comment type: E
Priority:
Section: 8.27

Rationale/Explanation of issues:

In section 5.1 it is only specified that the client SHOULD support the tariff change mechanism and the itemising of usage using the Tariff-Change-Usage AVP.

I believe the last sentence of section 8.27 (Tariff-Change-Usage AVP) is meant to support this, but it is not clear.

My suggested change is in section 8.27:

FROM

Omission of this AVP means that no tariff change has been occurred.

TO

If the client does not support the itemisation of tariff change usage, when the Tariff-Time-Change AVP was present in the previous answer, this AVP MUST be omitted.


Regards,

John.



















In the last paragraph of 5.1 (p16 of cc-03)


change SHOULD to MUST

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

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

******************************************************************************
 --=_alternative 005731BA80256E4A_=-- From owner-aaa-wg@merit.edu Mon Mar 1 11:23: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 LAA16054 for ; Mon, 1 Mar 2004 11:23:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4792591272; Mon, 1 Mar 2004 11:23:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F2B591273; Mon, 1 Mar 2004 11:23:17 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CF2D491272 for ; Mon, 1 Mar 2004 11:23:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id AD8C35E0CA; Mon, 1 Mar 2004 11:23:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (unknown [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id F0F2F5E0C9 for ; Mon, 1 Mar 2004 11:23:14 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i21GMtF21242; Mon, 1 Mar 2004 08:22:55 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Mar 2004 10:22:54 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304DDD528@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'Harri Hakala (TU/LMF)'" , "'marco.stura@nokia.com'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in mul tiple services feature Date: Mon, 1 Mar 2004 10:22:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FFA7.7A1AC764" 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_01C3FFA7.7A1AC764 Content-Type: text/plain; charset="iso-8859-1" Hi All, Does this imply that the Rating-Group AVP needs to be part of the R-S-U AVP in section 8.18? I think Rating-Group AVP needs to be added to R-S-U AVP. A client requests a resource allocation but does not request a certain amount (or unit) of resource (This is the usual case in the NAS environment). It leaves it up to the server to supply the amount and the unit type. Chris. -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: Monday, March 01, 2004 6:17 AM To: 'marco.stura@nokia.com'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in mul tiple services feature assigned issue 23. / harri > -----Original Message----- > From: owner-aaa-wg@merit.edu > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > marco.stura@nokia.com > Sent: 1. maaliskuuta 2004 14:13 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in > multiple services feature > > > Description of issue: clarification of R-S-U AVP usage in > multiple services feature > Submitter name: Marco Stura > Date first submitted: 1.03.2004 > Reference: > Document: draft-ietf-aaa-diameter-cc-03.txt > Comment type: T > Priority: 1 > Section: 5.2, 5.3, 8.16 and Flow X > > Rationale/Explanation of issues: > > When independent credit control of multiple services within a > (sub-)session is used, the Requested-Service-Unit AVP is used > by the client to indicate to the server that quota is > requested for the service/rating-group associated to it. > > The Requested-service-Unit AVP is to be present in all the > intermediate interrogations sent for the service/rating-group > if quota is still requested. If quota is not requested > anymore, for instance the client determined that the service > was terminated by the user, this is indicated by the absence > of the R-S-U AVP in the request command. > > The usage of the R-S-U AVP is not clearly specified in draft > 03, thus different interpretation of its usage may cause > potential interoperability problems between client and > servers of different vendors. For instance, a client may send > an intermediate interrogation without R-S-U AVP even though > it actually requests a new quota. The server may not returns > quota because it expects the R-S-U AVP to be present in the > request when quota is wanted. > > Requested change: > > -Section 5.2 second paragraph > > FROM > > > If the Diameter credit-control client knows the cost of > the service > event (e.g. a content server delivering ringing tones may > know their > cost) the monetary amount to be charged is included in the > Requested- > Service-Unit AVP. If the Diameter credit-control client > does not know > the cost of the service event, the Requested-Service-Unit AVP MAY > contain the number of requested service events. The > Service-Identifier > AVP, in case of multiple services the Service-Identifier > AVP or the > Rating-Group AVP within the Multiple-Services-Credit-Control AVP, > always indicates the concerned service. Additional service event > information to be rated MAY be sent as service specific > AVPs or MAY be > sent within the Service-Parameter-Info AVP at command level. > > TO > > If the Diameter credit-control client knows the cost of > the service > event (e.g. a content server delivering ringing tones may > know their > cost) the monetary amount to be charged is included in the > Requested- > Service-Unit AVP. If the Diameter credit-control client > does not know > the cost of the service event, the Requested-Service-Unit AVP MAY > contain the number of requested service events. Where the Multiple- > Services-Credit-Control AVP is used, it MUST contain the Requested- > Service-Unit AVP to indicate that quota for the associated service/ > rating-group is requested. The Service-Identifier AVP, in case of > multiple services the Service-Identifier AVP or the > Rating-Group AVP > within the Multiple-Services-Credit-Control AVP, always > indicates the > concerned service. Additional service event information > to be rated > MAY be sent as service specific AVPs or MAY be sent within the > Service-Parameter-Info AVP at command level. > > -Section 5.3 fifth paragraph > > FROM > > > The Requested-Service-Unit AVP MAY contain the new amount > of requested > service units. The Used-Service-Unit AVP contains the > amount of used > service units measured from the point when the service > became active > or, in case of interim interrogations are used during the session, > from the point when the previous measurement ended. The same unit > types that are used in the previous message MUST be used. > If several > unit types were included in the previous answer message the used > service units for each unit type MUST be reported. > > TO > > > The Requested-Service-Unit AVP MAY contain the new amount > of requested > service units. Where the Multiple-Services-Credit-Control > AVP is used, > it MUST contain the Requested-Service-Unit AVP if new > quota for the > associated service/rating-group is requested. The > Used-Service-Unit AVP > contains the amount of used service units measured from > the point when > the service became active or, in case of interim > interrogations are > used during the session, from the point when the previous > measurement > ended. The same unit types that are used in the previous > message MUST > be used. If several unit types were included in the > previous answer > message the used service units for each unit type MUST be reported. > > -Section 8.16 > > ADD after third paragrapf > > The Requested-Service-Unit AVP MAY contain the amount of requested > service units or the requested monetary value. It MUST be > present in > the initial interrogation and within the intermediate > interrogations > where new quota is requested. If the credit-control client does not > include the Requested-Service-Unit AVP in a request command, for > instance because it has determined that the end-user terminated the > service, the server MUST debit the used amount from the > user's account > but MUST NOT return a new quota in the corresponding answer. > > - Flow X add the R-S-U AVP in message 11 and 13 as follow. > > | +--------------+ | | > | |Validity time | |(11)CCR(update, | > | |expires for | | Multiple-Services-CC ( | > | |Service-Id | | Requested-Units(), | > | | access | | Used-Units(In-Octets,Out-Octets),| > | +--------------+ | Service-Id access)) | > | > |---------------------------------------->| > | |(12)CCA(Multiple-Services-CC ( | > | | Granted-Units(Total-Octets), | > | | Service-Id access, | > | | Validity-time, | > | | G-S-U-Pool-Reference(Pool-Id 1, | > | | Multiplier 10))) | > | |<----------------------------------------| > : : : > : : : > | +--------------+ | | > | |Total Quota | |(13)CCR(update, | > | |elapses for | | Multiple-Services-CC ( | > | |pool 2: | | Requested-Units(), | > | |service 4 not | | Used-Units(In-Octets,Out-Octets),| > | |allowed, | | Service-Id 3, Rating-group 2), | > | |service 3 cont| | Multiple-Services-CC ( | > | +--------------+ | Used-Units(In-Octets,Out-Octets),| > | | Service-Id 4, Rating-group 3)) | > | > |---------------------------------------->| > | |(14)CCA(Multiple-Services-CC ( | > | | Result-Code 4011, | > | | Service-Id 3)) | > | |<----------------------------------------| > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3FFA7.7A1AC764 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in = mul tiple services feature

Hi All,

Does this imply that the Rating-Group AVP needs to be = part of the R-S-U AVP in section 8.18?
I think Rating-Group AVP needs to be added to R-S-U = AVP.

A client requests a resource allocation but does not = request a certain amount (or unit) of resource (This is the usual case = in the NAS environment). It leaves it up to the server to supply the = amount and the unit type.

Chris.

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.c= om]
Sent: Monday, March 01, 2004 6:17 AM
To: 'marco.stura@nokia.com'; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC Issue: clarification of = R-S-U AVP usage in
mul tiple services feature


assigned issue 23.

/ harri

> -----Original Message-----
> From: owner-aaa-wg@merit.edu
> [mailto:owner-aaa-wg@merit.edu= ]On Behalf Of
> marco.stura@nokia.com
> Sent: 1. maaliskuuta 2004 14:13
> To: aaa-wg@merit.edu
> Subject: [AAA-WG]: DCC Issue: clarification of = R-S-U AVP usage in
> multiple services feature
>
>
> Description of issue: clarification of R-S-U = AVP usage in
> multiple services feature
> Submitter name:  Marco Stura
> Date first submitted: 1.03.2004
> Reference:
> Document: draft-ietf-aaa-diameter-cc-03.txt =
> Comment type: T
> Priority: 1
> Section: 5.2, 5.3, 8.16 and Flow X
>
> Rationale/Explanation of issues:
>
> When independent credit control of multiple = services within a
> (sub-)session is used, the = Requested-Service-Unit AVP is used
> by the client to indicate to the server that = quota is
> requested for the service/rating-group = associated to it.
>
> The Requested-service-Unit AVP is to be present = in all the
> intermediate interrogations sent for the = service/rating-group
> if quota is still requested. If quota is not = requested
> anymore, for instance the client determined = that the service
> was terminated by the user, this is indicated = by the absence
> of the R-S-U AVP in the request command.
>
> The usage of the R-S-U AVP is not clearly = specified in draft
> 03, thus different interpretation of its usage = may cause
> potential interoperability problems between = client and
> servers of different vendors. For instance, a = client may send
> an intermediate interrogation  without = R-S-U AVP even though
> it actually requests a new quota. The server = may not returns
> quota because it expects the R-S-U AVP to be = present in the
> request when quota is wanted.
>
> Requested change:
>
> -Section 5.2 second paragraph
>
> FROM
>
>
>    If the Diameter = credit-control client knows the cost of
> the service
>    event (e.g. a content server = delivering ringing tones may
> know their
>    cost) the monetary amount to = be charged is included in the
> Requested-
>    Service-Unit AVP. If the = Diameter credit-control client
> does not know
>    the cost of the service = event, the Requested-Service-Unit AVP MAY
>    contain the number of = requested service events. The
> Service-Identifier
>    AVP, in case of multiple = services the Service-Identifier
> AVP or the
>    Rating-Group AVP within the = Multiple-Services-Credit-Control AVP,
>    always indicates the = concerned service.  Additional service event
>    information to be rated MAY = be sent as service specific
> AVPs or MAY be
>    sent within the = Service-Parameter-Info AVP at command level.
>
> TO
>
>    If the Diameter = credit-control client knows the cost of
> the service
>    event (e.g. a content server = delivering ringing tones may
> know their
>    cost) the monetary amount to = be charged is included in the
> Requested-
>    Service-Unit AVP. If the = Diameter credit-control client
> does not know
>    the cost of the service = event, the Requested-Service-Unit AVP MAY
>    contain the number of = requested service events. Where the Multiple-
>    Services-Credit-Control AVP = is used, it MUST contain the Requested-
>    Service-Unit AVP to indicate = that quota for the associated service/
>    rating-group is requested. = The Service-Identifier AVP, in case of
>    multiple services the = Service-Identifier AVP or the
> Rating-Group AVP
>    within the = Multiple-Services-Credit-Control AVP, always
> indicates the
>    concerned service.  = Additional service event information
> to be rated
>    MAY be sent as service = specific AVPs or MAY be sent within the
>    Service-Parameter-Info AVP at = command level.
>
> -Section 5.3 fifth paragraph
>
> FROM
>
>
>    The Requested-Service-Unit = AVP MAY contain the new amount
> of requested
>    service units. The = Used-Service-Unit AVP contains the
> amount of used
>    service units measured from = the point when the service
> became active
>    or, in case of interim = interrogations are used during the session,
>    from the point when the = previous measurement ended. The same unit
>    types that are used in the = previous message MUST be used.
> If several
>    unit types were included in = the previous answer message the used
>    service units for each unit = type MUST be reported. 
>
> TO
>
>
>    The Requested-Service-Unit = AVP MAY contain the new amount
> of requested
>    service units. Where the = Multiple-Services-Credit-Control
> AVP is used,
>    it MUST contain the = Requested-Service-Unit AVP if new
> quota for the
>    associated = service/rating-group is requested. The
> Used-Service-Unit AVP
>    contains the amount of used = service units measured from
> the point when
>    the service became active or, = in case of interim
> interrogations are
>    used during the session, from = the point when the previous
> measurement
>    ended. The same unit types = that are used in the previous
> message MUST
>    be used. If several unit = types were included in the
> previous answer
>    message the used service = units for each unit type MUST be reported.
> 
> -Section 8.16
>
> ADD after third paragrapf
>
>    The Requested-Service-Unit = AVP MAY contain the amount of requested
>    service units or the = requested monetary value. It MUST be
> present in
>    the initial interrogation and = within the intermediate
> interrogations
>    where new quota is requested. = If the credit-control client does not
>    include the = Requested-Service-Unit AVP in a request command, for
>    instance because it has = determined that the end-user terminated the
>    service, the server MUST = debit the used amount from the
> user's account
>    but MUST NOT return a new = quota in the corresponding answer.
>
> - Flow X add the R-S-U AVP in message 11 and 13 = as follow.
>
>      | = +--------------+  = |            = ;            = ;            = ;     | 
>      | |Validity time = |  = |(11)CCR(update,         &n= bsp;           &n= bsp;    | 
>      | |expires = for   |  |        = Multiple-Services-CC = (           |  =
>      | = |Service-Id    |  = |        = Requested-Units(),         =       |
>      | | = access       |  = |        = Used-Units(In-Octets,Out-Octets),|
>      | = +--------------+  |        = Service-Id = access))          &nbs= p;   |
>      = |            = ;      
> = |---------------------------------------->|  
>      = |            = ;       |(12)CCA(Multiple-Services-CC = (           |
>      = |            = ;       = |        = Granted-Units(Total-Octets),     | 
>      = |            = ;       = |        Service-Id = access,           = ;    | 
>      = |            = ;       = |        = Validity-time,         &nbs= p;         |
>      = |            = ;       = |        = G-S-U-Pool-Reference(Pool-Id 1,  | 
>      = |            = ;       = |          Multiplier = 10)))           &= nbsp;   |
>      = |            = ;       = |<----------------------------------------| 
>      = :            = ;       = :            = ;            = ;            = ;     : 
>      = :            = ;       = :            = ;            = ;            = ;     : 
>      | = +--------------+  = |            = ;            = ;            = ;     | 
>      | |Total = Quota   |  = |(13)CCR(update,         &n= bsp;           &n= bsp;    | 
>      | |elapses = for   |  |       = Multiple-Services-CC = (            = | 
>      | |pool = 2:       |  = |        = Requested-Units(),         =       |
>      | |service 4 not = |  |        = Used-Units(In-Octets,Out-Octets),|
>      | = |allowed,      |  = |        Service-Id 3, Rating-group = 2),   |
>      | |service 3 = cont|  |       Multiple-Services-CC = (            = | 
>      | = +--------------+  |        = Used-Units(In-Octets,Out-Octets),|
>      = |            = ;       = |        Service-Id 4, Rating-group = 3))   |
>      = |            = ;      
> = |---------------------------------------->|  
>      = |            = ;       |(14)CCA(Multiple-Services-CC = (           |
>      = |            = ;       = |        Result-Code = 4011,           &= nbsp;    | 
>      = |            = ;       = |        Service-Id = 3))           &nb= sp;       |
>      = |            = ;       = |<----------------------------------------| 
>

This communication is confidential and intended = solely for the addressee(s). Any unauthorized review, use, disclosure = or distribution is prohibited. If you believe this message has been = sent to you in error, please notify the sender by replying to this = transmission and delete the message without disclosing it. Thank = you.

E-mail including attachments is susceptible to data = corruption, interruption, unauthorized amendment, tampering and = viruses, and we only send and receive e-mails on the basis that we are = not liable for any such corruption, interception, amendment, tampering = or viruses or any consequences thereof.

------_=_NextPart_001_01C3FFA7.7A1AC764-- From owner-aaa-wg@merit.edu Mon Mar 1 11:35: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 LAA18002 for ; Mon, 1 Mar 2004 11:35:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 767B691273; Mon, 1 Mar 2004 11:35:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3E22C91276; Mon, 1 Mar 2004 11:35:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E439791273 for ; Mon, 1 Mar 2004 11:35:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id C38425E0C7; Mon, 1 Mar 2004 11:35:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 29D615E09A for ; Mon, 1 Mar 2004 11:34:51 -0500 (EST) 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 i21GYnT19222; Mon, 1 Mar 2004 18:34:49 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 18:34:17 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i21GYH7Z031514; Mon, 1 Mar 2004 18:34:17 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00Aa3m0x; Mon, 01 Mar 2004 18:34:16 EET 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 i21GYGO02634; Mon, 1 Mar 2004 18:34:16 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 18:34:14 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FFAB.08F0CC41" Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in mul tiple services feature x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 1 Mar 2004 18:34:15 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0494@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in mul tiple services feature Thread-Index: AcP/qcwukwcFWG1lQHO3+O/TbS/SigAADjAQ From: To: Cc: , X-OriginalArrivalTime: 01 Mar 2004 16:34:14.0942 (UTC) FILETIME=[08D8C3E0:01C3FFAB] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FFAB.08F0CC41 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chris, =20 >Does this imply that the Rating-Group AVP needs to be part of the R-S-U = AVP in section 8.18?=20 >I think Rating-Group AVP needs to be added to R-S-U AVP.=20 =20 No, it doesn't imply this. The Rating-Group AVP is associate to the = R-S-U in the M-S-C-C AVP. =20 M-S-C-C (R-S-U, Rating-Group, Service-Id, U-S-U) =20 >A client requests a resource allocation but does not request a certain = amount (or unit) of resource (This is the usual case in the NAS = environment). It leaves it up to the >server to supply the amount and = the unit type. =20 Yes, this is the usual case and it is achieved by an empty R-S-U AVP as = also illustrated in Flow X by the notation R-S-U ( ).=20 Note that all the AVPs in the R-S-U AVP structure are optional. =20 Regards Marco -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 01 March, 2004 18:23 To: 'Harri Hakala (TU/LMF)'; Stura Marco (Nokia-NET/Helsinki); = 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in = mul tiple services feature Hi All,=20 Does this imply that the Rating-Group AVP needs to be part of the R-S-U = AVP in section 8.18?=20 I think Rating-Group AVP needs to be added to R-S-U AVP.=20 A client requests a resource allocation but does not request a certain = amount (or unit) of resource (This is the usual case in the NAS = environment). It leaves it up to the server to supply the amount and the = unit type. Chris.=20 -----Original Message-----=20 From: Harri Hakala (TU/LMF) [ mailto:harri.hakala@ericsson.com]=20 Sent: Monday, March 01, 2004 6:17 AM=20 To: 'marco.stura@nokia.com'; aaa-wg@merit.edu=20 Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in=20 mul tiple services feature=20 assigned issue 23.=20 / harri=20 > -----Original Message-----=20 > From: owner-aaa-wg@merit.edu=20 > [ mailto:owner-aaa-wg@merit.edu]On Behalf Of=20 > marco.stura@nokia.com=20 > Sent: 1. maaliskuuta 2004 14:13=20 > To: aaa-wg@merit.edu=20 > Subject: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in=20 > multiple services feature=20 >=20 >=20 > Description of issue: clarification of R-S-U AVP usage in=20 > multiple services feature=20 > Submitter name: Marco Stura=20 > Date first submitted: 1.03.2004=20 > Reference:=20 > Document: draft-ietf-aaa-diameter-cc-03.txt=20 > Comment type: T=20 > Priority: 1=20 > Section: 5.2, 5.3, 8.16 and Flow X=20 >=20 > Rationale/Explanation of issues:=20 >=20 > When independent credit control of multiple services within a=20 > (sub-)session is used, the Requested-Service-Unit AVP is used=20 > by the client to indicate to the server that quota is=20 > requested for the service/rating-group associated to it.=20 >=20 > The Requested-service-Unit AVP is to be present in all the=20 > intermediate interrogations sent for the service/rating-group=20 > if quota is still requested. If quota is not requested=20 > anymore, for instance the client determined that the service=20 > was terminated by the user, this is indicated by the absence=20 > of the R-S-U AVP in the request command.=20 >=20 > The usage of the R-S-U AVP is not clearly specified in draft=20 > 03, thus different interpretation of its usage may cause=20 > potential interoperability problems between client and=20 > servers of different vendors. For instance, a client may send=20 > an intermediate interrogation without R-S-U AVP even though=20 > it actually requests a new quota. The server may not returns=20 > quota because it expects the R-S-U AVP to be present in the=20 > request when quota is wanted.=20 >=20 > Requested change:=20 >=20 > -Section 5.2 second paragraph=20 >=20 > FROM=20 >=20 >=20 > If the Diameter credit-control client knows the cost of=20 > the service=20 > event (e.g. a content server delivering ringing tones may=20 > know their=20 > cost) the monetary amount to be charged is included in the=20 > Requested-=20 > Service-Unit AVP. If the Diameter credit-control client=20 > does not know=20 > the cost of the service event, the Requested-Service-Unit AVP MAY=20 > contain the number of requested service events. The=20 > Service-Identifier=20 > AVP, in case of multiple services the Service-Identifier=20 > AVP or the=20 > Rating-Group AVP within the Multiple-Services-Credit-Control AVP,=20 > always indicates the concerned service. Additional service event=20 > information to be rated MAY be sent as service specific=20 > AVPs or MAY be=20 > sent within the Service-Parameter-Info AVP at command level.=20 >=20 > TO=20 >=20 > If the Diameter credit-control client knows the cost of=20 > the service=20 > event (e.g. a content server delivering ringing tones may=20 > know their=20 > cost) the monetary amount to be charged is included in the=20 > Requested-=20 > Service-Unit AVP. If the Diameter credit-control client=20 > does not know=20 > the cost of the service event, the Requested-Service-Unit AVP MAY=20 > contain the number of requested service events. Where the Multiple- = > Services-Credit-Control AVP is used, it MUST contain the Requested- = > Service-Unit AVP to indicate that quota for the associated service/ = > rating-group is requested. The Service-Identifier AVP, in case of=20 > multiple services the Service-Identifier AVP or the=20 > Rating-Group AVP=20 > within the Multiple-Services-Credit-Control AVP, always=20 > indicates the=20 > concerned service. Additional service event information=20 > to be rated=20 > MAY be sent as service specific AVPs or MAY be sent within the=20 > Service-Parameter-Info AVP at command level.=20 >=20 > -Section 5.3 fifth paragraph=20 >=20 > FROM=20 >=20 >=20 > The Requested-Service-Unit AVP MAY contain the new amount=20 > of requested=20 > service units. The Used-Service-Unit AVP contains the=20 > amount of used=20 > service units measured from the point when the service=20 > became active=20 > or, in case of interim interrogations are used during the session,=20 > from the point when the previous measurement ended. The same unit=20 > types that are used in the previous message MUST be used.=20 > If several=20 > unit types were included in the previous answer message the used=20 > service units for each unit type MUST be reported. =20 >=20 > TO=20 >=20 >=20 > The Requested-Service-Unit AVP MAY contain the new amount=20 > of requested=20 > service units. Where the Multiple-Services-Credit-Control=20 > AVP is used,=20 > it MUST contain the Requested-Service-Unit AVP if new=20 > quota for the=20 > associated service/rating-group is requested. The=20 > Used-Service-Unit AVP=20 > contains the amount of used service units measured from=20 > the point when=20 > the service became active or, in case of interim=20 > interrogations are=20 > used during the session, from the point when the previous=20 > measurement=20 > ended. The same unit types that are used in the previous=20 > message MUST=20 > be used. If several unit types were included in the=20 > previous answer=20 > message the used service units for each unit type MUST be reported. = > =20 > -Section 8.16=20 >=20 > ADD after third paragrapf=20 >=20 > The Requested-Service-Unit AVP MAY contain the amount of requested=20 > service units or the requested monetary value. It MUST be=20 > present in=20 > the initial interrogation and within the intermediate=20 > interrogations=20 > where new quota is requested. If the credit-control client does not = > include the Requested-Service-Unit AVP in a request command, for=20 > instance because it has determined that the end-user terminated the = > service, the server MUST debit the used amount from the=20 > user's account=20 > but MUST NOT return a new quota in the corresponding answer.=20 >=20 > - Flow X add the R-S-U AVP in message 11 and 13 as follow.=20 >=20 > | +--------------+ | | =20 > | |Validity time | |(11)CCR(update, | =20 > | |expires for | | Multiple-Services-CC ( | =20 > | |Service-Id | | Requested-Units(), |=20 > | | access | | Used-Units(In-Octets,Out-Octets),|=20 > | +--------------+ | Service-Id access)) |=20 > | =20 > |---------------------------------------->| =20 > | |(12)CCA(Multiple-Services-CC ( |=20 > | | Granted-Units(Total-Octets), | =20 > | | Service-Id access, | =20 > | | Validity-time, |=20 > | | G-S-U-Pool-Reference(Pool-Id 1, | =20 > | | Multiplier 10))) |=20 > | |<----------------------------------------| =20 > : : : =20 > : : : =20 > | +--------------+ | | =20 > | |Total Quota | |(13)CCR(update, | =20 > | |elapses for | | Multiple-Services-CC ( | =20 > | |pool 2: | | Requested-Units(), |=20 > | |service 4 not | | Used-Units(In-Octets,Out-Octets),|=20 > | |allowed, | | Service-Id 3, Rating-group 2), |=20 > | |service 3 cont| | Multiple-Services-CC ( | =20 > | +--------------+ | Used-Units(In-Octets,Out-Octets),|=20 > | | Service-Id 4, Rating-group 3)) |=20 > | =20 > |---------------------------------------->| =20 > | |(14)CCA(Multiple-Services-CC ( |=20 > | | Result-Code 4011, | =20 > | | Service-Id 3)) |=20 > | |<----------------------------------------| =20 >=20 This communication is confidential and intended solely for the = addressee(s). Any unauthorized review, use, disclosure or distribution = is prohibited. If you believe this message has been sent to you in = error, please notify the sender by replying to this transmission and = delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, = interruption, unauthorized amendment, tampering and viruses, and we only = send and receive e-mails on the basis that we are not liable for any = such corruption, interception, amendment, tampering or viruses or any = consequences thereof. ------_=_NextPart_001_01C3FFAB.08F0CC41 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in mul = tiple services feature
Hi=20 Chris,
 
>Does this imply = that the=20 Rating-Group AVP needs to be part of the R-S-U AVP in section 8.18?=20
>I think Rating-Group AVP needs to be added to R-S-U = AVP.
 
No, it doesn't=20 imply this. The Rating-Group AVP is associate to the R-S-U in the = M-S-C-C=20 AVP.
 
M-S-C-C (R-S-U, Rating-Group, Service-Id,=20 U-S-U)
 
>A client requests a resource allocation = but does=20 not request a certain amount (or unit) of resource (This is the usual = case in=20 the NAS environment). It leaves it up to the >server to supply the = amount and=20 the unit type.
 
Yes, this is the usual case and it is = achieved by an=20 empty R-S-U AVP as also illustrated in Flow X by the notation R-S-U ( ). =
Note that all the AVPs in the R-S-U AVP = structure are=20 optional.
 
Regards
Marco
=
-----Original Message-----
From: ext Christopher = Richards=20 [mailto:crich@nortelnetworks.com]
Sent: 01 March, 2004=20 18:23
To: 'Harri Hakala (TU/LMF)'; Stura Marco = (Nokia-NET/Helsinki);=20 'aaa-wg@merit.edu'
Subject: RE: [AAA-WG]: DCC Issue: = clarification=20 of R-S-U AVP usage in mul tiple services feature

Hi All,

Does this imply that the Rating-Group AVP needs to = be part of=20 the R-S-U AVP in section 8.18?
I think = Rating-Group=20 AVP needs to be added to R-S-U AVP.

A client requests a resource allocation but does not = request a=20 certain amount (or unit) of resource (This is the usual case in the = NAS=20 environment). It leaves it up to the server to supply the amount and = the unit=20 type.

Chris.

-----Original Message-----
From: Harri=20 Hakala (TU/LMF) [mailto:harri.hakala@ericsson.co= m]=20
Sent: Monday, March 01, 2004 6:17 AM =
To: 'marco.stura@nokia.com'; aaa-wg@merit.edu =
Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP = usage=20 in
mul tiple services feature =


assigned issue 23.

/ harri

> -----Original Message-----
>=20 From: owner-aaa-wg@merit.edu
> [mailto:owner-aaa-wg@merit.edu]= On=20 Behalf Of
> marco.stura@nokia.com =
> Sent: 1. maaliskuuta 2004 14:13
> To:=20 aaa-wg@merit.edu
> Subject: [AAA-WG]: DCC = Issue:=20 clarification of R-S-U AVP usage in
> = multiple=20 services feature
>
>=20
> Description of issue: clarification of = R-S-U AVP=20 usage in
> multiple services = feature=20
> Submitter name:  Marco Stura =
> Date first submitted: 1.03.2004
>=20 Reference:
> Document:=20 draft-ietf-aaa-diameter-cc-03.txt
> = Comment type: T=20
> Priority: 1
> Section:=20 5.2, 5.3, 8.16 and Flow X
> =
> Rationale/Explanation of issues:
>=20
> When independent credit control of = multiple=20 services within a
> (sub-)session is = used, the=20 Requested-Service-Unit AVP is used
> by = the client=20 to indicate to the server that quota is
> = requested=20 for the service/rating-group associated to it.
>=20
> The Requested-service-Unit AVP is to be = present=20 in all the
> intermediate interrogations = sent for=20 the service/rating-group
> if quota is = still=20 requested. If quota is not requested
> = anymore, for=20 instance the client determined that the service
>=20 was terminated by the user, this is indicated by the absence =
> of the R-S-U AVP in the request command. =
>
> The usage of the R-S-U = AVP is not=20 clearly specified in draft
> 03, thus = different=20 interpretation of its usage may cause
> = potential=20 interoperability problems between client and
>=20 servers of different vendors. For instance, a client may send =
> an intermediate interrogation  without R-S-U AVP = even though=20
> it actually requests a new quota. The = server may=20 not returns
> quota because it expects = the R-S-U=20 AVP to be present in the
> request when = quota is=20 wanted.
>
> = Requested=20 change:
>
> = -Section 5.2=20 second paragraph
>
>=20 FROM
>
>=20
>    If the Diameter = credit-control=20 client knows the cost of
> the service=20
>    event (e.g. a content = server=20 delivering ringing tones may
> know their =
>    cost) the monetary = amount to be=20 charged is included in the
> = Requested-=20
>    Service-Unit AVP. If the = Diameter=20 credit-control client
> does not know=20
>    the cost of the = service event,=20 the Requested-Service-Unit AVP MAY
>    contain the number of requested = service events.=20 The
> Service-Identifier
>    AVP, in case of multiple services the=20 Service-Identifier
> AVP or the =
>    Rating-Group AVP within the=20 Multiple-Services-Credit-Control AVP,
>    always indicates the concerned = service. =20 Additional service event
>   =20 information to be rated MAY be sent as service specific =
> AVPs or MAY be
>    sent=20 within the Service-Parameter-Info AVP at command level. =
>
> TO
>=20
>    If the Diameter = credit-control=20 client knows the cost of
> the service=20
>    event (e.g. a content = server=20 delivering ringing tones may
> know their =
>    cost) the monetary = amount to be=20 charged is included in the
> = Requested-=20
>    Service-Unit AVP. If the = Diameter=20 credit-control client
> does not know=20
>    the cost of the = service event,=20 the Requested-Service-Unit AVP MAY
>    contain the number of requested = service events.=20 Where the Multiple-
>   =20 Services-Credit-Control AVP is used, it MUST contain the = Requested-=20
>    Service-Unit AVP to indicate = that=20 quota for the associated service/
>    rating-group is requested. The=20 Service-Identifier AVP, in case of
>    multiple services the = Service-Identifier AVP or=20 the
> Rating-Group AVP
>    within the = Multiple-Services-Credit-Control AVP,=20 always
> indicates the
>    concerned service.  Additional = service=20 event information
> to be rated =
>    MAY be sent as service specific AVPs = or MAY be=20 sent within the
>   =20 Service-Parameter-Info AVP at command level.
>=20
> -Section 5.3 fifth paragraph =
>
> FROM
>=20
>
>   =20 The Requested-Service-Unit AVP MAY contain the new amount =
> of requested
>   =20 service units. The Used-Service-Unit AVP contains the
> amount of used
>   =20 service units measured from the point when the service =
> became active
>    or,=20 in case of interim interrogations are used during the session,=20
>    from the point when = the=20 previous measurement ended. The same unit
>    types that are used in the previous = message MUST=20 be used.
> If several
>    unit types were included in the = previous answer=20 message the used
>    = service units=20 for each unit type MUST be reported. 
>=20
> TO
> =
>
>    The=20 Requested-Service-Unit AVP MAY contain the new amount
> of requested
>   =20 service units. Where the Multiple-Services-Credit-Control =
> AVP is used,
>    it=20 MUST contain the Requested-Service-Unit AVP if new
> quota for the
>   =20 associated service/rating-group is requested. The
>=20 Used-Service-Unit AVP
>    = contains=20 the amount of used service units measured from
>=20 the point when
>    the = service=20 became active or, in case of interim
>=20 interrogations are
>    = used during=20 the session, from the point when the previous
>=20 measurement
>    ended. = The same=20 unit types that are used in the previous
> message=20 MUST
>    be used. If = several unit=20 types were included in the
> previous = answer=20
>    message the used = service units=20 for each unit type MUST be reported.
> =20
> -Section 8.16
>=20
> ADD after third paragrapf =
>
>    The=20 Requested-Service-Unit AVP MAY contain the amount of requested=20
>    service units or the = requested=20 monetary value. It MUST be
> present = in=20
>    the initial interrogation = and within=20 the intermediate
> interrogations =
>    where new quota is requested. If the=20 credit-control client does not
>   =20 include the Requested-Service-Unit AVP in a request command, = for=20
>    instance because it has = determined=20 that the end-user terminated the
>    service, the server MUST debit the = used amount=20 from the
> user's account =
>    but MUST NOT return a new quota in the = corresponding answer.
>
> - Flow X add the R-S-U AVP in message 11 and 13 as = follow.=20
>
>      | +--------------+ =20 = |            =             &= nbsp;           &n= bsp;   =20 | 
>      | = |Validity=20 time | =20 = |(11)CCR(update,         &nb= sp;           &nbs= p;   =20 | 
>      | = |expires=20 for   |  |       =20 Multiple-Services-CC=20 (           | =20
>      |=20 |Service-Id    | =20 |       =20 = Requested-Units(),         &= nbsp;    =20 |
>      | |=20 access       | =20 |        = Used-Units(In-Octets,Out-Octets),|=20
>      |=20 +--------------+  |        = Service-Id=20 = access))           = ;  =20 |
>     =20 = |            =       =20
>=20 |---------------------------------------->|   =
>     =20 = |            =       =20 |(12)CCA(Multiple-Services-CC=20 (           |=20
>     =20 = |            =       =20 |       =20 Granted-Units(Total-Octets),     |  =
>     =20 = |            =       =20 |        Service-Id=20 = access,           =    =20 | 
>     =20 = |            =       =20 |       =20 = Validity-time,          = ;        =20 |
>     =20 = |            =       =20 |        = G-S-U-Pool-Reference(Pool-Id=20 1,  | 
>     =20 = |            =       =20 |          Multiplier=20 = 10)))           &n= bsp;  =20 |
>     =20 = |            =       =20 |<----------------------------------------| 
>     =20 = :            =       =20 = :            =             &= nbsp;           &n= bsp;   =20 : 
>     =20 = :            =       =20 = :            =             &= nbsp;           &n= bsp;   =20 : 
>      | = +--------------+ =20 = |            =             &= nbsp;           &n= bsp;   =20 | 
>      | = |Total=20 Quota   | =20 = |(13)CCR(update,         &nb= sp;           &nbs= p;   =20 | 
>      | = |elapses=20 for   |  |      =20 Multiple-Services-CC=20 (            = | =20
>      | |pool=20 2:       | =20 |       =20 = Requested-Units(),         &= nbsp;    =20 |
>      | = |service 4 not=20 |  |       =20 Used-Units(In-Octets,Out-Octets),|
>      |=20 |allowed,      | =20 |        Service-Id 3, Rating-group = 2),   |
>      |=20 |service 3 cont|  |      =20 Multiple-Services-CC=20 (            = | =20
>      |=20 +--------------+  |       =20 Used-Units(In-Octets,Out-Octets),|
>     =20 = |            =       =20 |        Service-Id 4, Rating-group = 3))   |
>     =20 = |            =       =20
>=20 |---------------------------------------->|   =
>     =20 = |            =       =20 |(14)CCA(Multiple-Services-CC=20 (           |=20
>     =20 = |            =       =20 |        Result-Code=20 = 4011,           &n= bsp;   =20 | 
>     =20 = |            =       =20 |        Service-Id=20 = 3))           &nbs= p;      =20 |
>     =20 = |            =       =20 |<----------------------------------------| 
>

This communication is confidential and intended = solely for the=20 addressee(s). Any unauthorized review, use, disclosure or distribution = is=20 prohibited. If you believe this message has been sent to you in error, = please=20 notify the sender by replying to this transmission and delete the = message=20 without disclosing it. Thank you.

E-mail including attachments is susceptible to data=20 corruption, interruption, unauthorized amendment, tampering and = viruses, and=20 we only send and receive e-mails on the basis that we are not liable = for any=20 such corruption, interception, amendment, tampering or viruses or any=20 consequences thereof.

------_=_NextPart_001_01C3FFAB.08F0CC41-- From owner-aaa-wg@merit.edu Mon Mar 1 11:41: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 LAA18102 for ; Mon, 1 Mar 2004 11:41:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8ACD291276; Mon, 1 Mar 2004 11:41:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5C8AC91278; Mon, 1 Mar 2004 11:41:12 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 369CA91276 for ; Mon, 1 Mar 2004 11:41:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1F37D5E0E4; Mon, 1 Mar 2004 11:41:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailsweep01.vodafone.ie (unknown [213.233.159.70]) by segue.merit.edu (Postfix) with ESMTP id A71785E0F1 for ; Mon, 1 Mar 2004 11:41:04 -0500 (EST) Received: from eircellnotes5.eircell.ie (unverified) by mailsweep01.vodafone.ie (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Mon, 1 Mar 2004 16:45:31 +0000 To: Cc: aaa-wg@merit.edu, John.Prudhoe@vodafone.com Subject: RE: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John.Prudhoe@vodafone.com Date: Mon, 1 Mar 2004 16:40:51 +0000 X-MIMETrack: Serialize by Router on Notes5/Vodafone(Release 5.0.10 |March 22, 2002) at 03/01/2004 04:40:55 PM, Serialize complete at 03/01/2004 04:40:55 PM Content-Type: multipart/alternative; boundary="=_alternative 005B9EFB80256E4A_=" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005B9EFB80256E4A_= Content-Type: text/plain; charset="us-ascii" Hi Marco, OK, I was concentrating on 5.1 & missed 8.20. This is a better solution than I thought the mechanism was. I agree that some rewording of 5.1 is necessary as you suggest. Regards, John. 01/03/2004 16:25 To: cc: Subject: RE: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism Hi John, the tariff-time-change mechanism consists of a server instructing the client when the tariff change will occurs and of a client reporting units used before and after tariff change. in section 8.20 it is specified that If a client does not support the tariff time change mechanism it MUST treat Tariff-Time-Change AVP in the answer message as an incorrect CCA answer. In that case the client terminates the credit control session and indicate in the Termination-Cause AVP reason DIAMETER_BAD_ANSWER. Then, if the client accept the Tariff-Time-Change AVP it is because it supports the itemising of usage using the Tariff-Change-Usage AVP. You wrote: >If the client does not support the itemisation of tariff change usage, when the Tariff-Time-Change AVP was present in the > >previous answer, this AVP MUST be omitted. According to section 8.20, this case shouldn't happen. The SHOULD keyword was used because it is not sure whether the tariff change will occur during the reporting period. Perhaps the sentence in 5.1 should be rephrased so that "when a tariff change occurs during the reporting period the client MUST itemize..."? Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext John.Prudhoe@vodafone.com Sent: 01 March, 2004 17:53 To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism Description of issue: Client Support of Tariff Change Mechanism Submitter name: John Prudhoe Date first submitted: 1.03.2004 Reference: Document: draft-ietf-aaa-diameter-cc-03.txt Comment type: E Priority: Section: 8.27 Rationale/Explanation of issues: In section 5.1 it is only specified that the client SHOULD support the tariff change mechanism and the itemising of usage using the Tariff-Change-Usage AVP. I believe the last sentence of section 8.27 (Tariff-Change-Usage AVP) is meant to support this, but it is not clear. My suggested change is in section 8.27: FROM Omission of this AVP means that no tariff change has been occurred. TO If the client does not support the itemisation of tariff change usage, when the Tariff-Time-Change AVP was present in the previous answer, this AVP MUST be omitted. Regards, John. In the last paragraph of 5.1 (p16 of cc-03) change SHOULD to MUST ****************************************************************************** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination, disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages of this kind. The opinions, conclusions and other information in this message are of the author and shall be understood as neither given nor endorsed by Vodafone Ireland Limited unless it is otherwise indicated by an authorised representative independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone Ireland Limited has no control. As such, there is no guarantee that (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender (iii) this e-mail has not been intercepted by a third party (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this message (including its attachments) has been processed by an automated anti-virus system; however it is the responsibility of the recipient to ensure that the message (and attachments) are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18. Number 326967 VAT Reg No. IE6346967G ****************************************************************************** --=_alternative 005B9EFB80256E4A_= Content-Type: text/html; charset="us-ascii"
Hi Marco,

OK, I was concentrating on 5.1 & missed 8.20.  This is a better solution than I thought the mechanism was.  I agree that some rewording of 5.1 is necessary as you suggest.

Regards,

John.
 



<marco.stura@nokia.com>

01/03/2004 16:25

       
        To:        <John.Prudhoe@vodafone.com>
        cc:        <aaa-wg@merit.edu>
        Subject:        RE: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism



Hi John,

the tariff-time-change mechanism consists of a server instructing the client when the tariff change will occurs and
of a client reporting units used before and after tariff change.

in section 8.20 it is specified that

  If a client does not support the tariff time change mechanism it MUST
  treat Tariff-Time-Change AVP in the answer message as an incorrect
  CCA answer. In that case the client terminates the credit control
  session and indicate in the Termination-Cause AVP reason
  DIAMETER_BAD_ANSWER.

Then, if the client accept the Tariff-Time-Change AVP it is because it supports the itemising of
usage using the Tariff-Change-Usage AVP.

You wrote:

>If the client does not support the itemisation of tariff change usage, when the Tariff-Time-Change AVP was present in the >
>previous answer, this AVP MUST be omitted.

According to section 8.20, this case shouldn't happen.
The SHOULD keyword was used because it is not sure whether the tariff change will occur during the reporting
period. Perhaps the sentence in 5.1 should be rephrased so that "when a tariff change occurs during the
reporting period the client MUST itemize..."?

Regards
Marco

-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext John.Prudhoe@vodafone.com
Sent: 01 March, 2004 17:53
To: aaa-wg@merit.edu
Subject: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism



Description of issue:  Client Support of Tariff Change Mechanism
Submitter name:  John Prudhoe
Date first submitted: 1.03.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-03.txt
Comment type: E
Priority:
Section: 8.27

Rationale/Explanation of issues:

In section 5.1 it is only specified that the client SHOULD support the tariff change mechanism and the itemising of usage using the Tariff-Change-Usage AVP.

I believe the last sentence of section 8.27 (Tariff-Change-Usage AVP) is meant to support this, but it is not clear.

My suggested change is in section 8.27:

FROM

Omission of this AVP means that no tariff change has been occurred.

TO

If the client does not support the itemisation of tariff change usage, when the Tariff-Time-Change AVP was present in the previous answer, this AVP MUST be omitted.


Regards,

John.



















In the last paragraph of 5.1 (p16 of cc-03)


change SHOULD to MUST

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

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

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

--=_alternative 005B9EFB80256E4A_=-- From owner-aaa-wg@merit.edu Mon Mar 1 11:45: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 LAA20545 for ; Mon, 1 Mar 2004 11:45:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 585E991274; Mon, 1 Mar 2004 11:26:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 260BC91275; Mon, 1 Mar 2004 11:26:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C8DC91274 for ; Mon, 1 Mar 2004 11:26:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id EFFBE5E0E5; Mon, 1 Mar 2004 11:26:11 -0500 (EST) 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 6D0495E0E4 for ; Mon, 1 Mar 2004 11:26:10 -0500 (EST) 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 i21GQ5L16739; Mon, 1 Mar 2004 18:26:06 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 18:25:11 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i21GPB0x002791; Mon, 1 Mar 2004 18:25:11 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 003Y6fK9; Mon, 01 Mar 2004 18:25:08 EET 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 i21GP7725907; Mon, 1 Mar 2004 18:25:07 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 18:25:06 +0200 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: Client Support of Tariff Change Mechanism x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 1 Mar 2004 18:25:05 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0493@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism Thread-Index: AcP/plHvVjEtiB+2SY+oBBDRrhY87QAAP+Vw From: To: Cc: X-OriginalArrivalTime: 01 Mar 2004 16:25:06.0147 (UTC) FILETIME=[C1BD4B30:01C3FFA9] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi John, the tariff-time-change mechanism consists of a server instructing the = client when the tariff change will occurs and of a client reporting units used before and after tariff change. in section 8.20 it is specified that=20 If a client does not support the tariff time change mechanism it MUST = treat Tariff-Time-Change AVP in the answer message as an incorrect=20 CCA answer. In that case the client terminates the credit control=20 session and indicate in the Termination-Cause AVP reason=20 DIAMETER_BAD_ANSWER.=20 Then, if the client accept the Tariff-Time-Change AVP it is because it = supports the itemising of usage using the Tariff-Change-Usage AVP. You wrote: >If the client does not support the itemisation of tariff change usage, = when the Tariff-Time-Change AVP was present in the > >previous answer, this AVP MUST be omitted.=20 According to section 8.20, this case shouldn't happen. The SHOULD keyword was used because it is not sure whether the tariff = change will occur during the reporting period. Perhaps the sentence in 5.1 should be rephrased so that "when a = tariff change occurs during the reporting period the client MUST itemize..."? Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext John.Prudhoe@vodafone.com Sent: 01 March, 2004 17:53 To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism Description of issue: Client Support of Tariff Change Mechanism Submitter name: John Prudhoe Date first submitted: 1.03.2004=20 Reference:=20 Document: draft-ietf-aaa-diameter-cc-03.txt=20 Comment type: E Priority:=20 Section: 8.27 Rationale/Explanation of issues:=20 In section 5.1 it is only specified that the client SHOULD support the = tariff change mechanism and the itemising of usage using the = Tariff-Change-Usage AVP.=20 I believe the last sentence of section 8.27 (Tariff-Change-Usage AVP) is = meant to support this, but it is not clear.=20 My suggested change is in section 8.27:=20 FROM=20 Omission of this AVP means that no tariff change has been occurred.=20 TO=20 If the client does not support the itemisation of tariff change usage, = when the Tariff-Time-Change AVP was present in the previous answer, this = AVP MUST be omitted.=20 Regards,=20 John.=20 In the last paragraph of 5.1 (p16 of cc-03)=20 change SHOULD to MUST *************************************************************************= ***** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message=20 (or responsible for delivery of the message to such person),=20 you may not copy or deliver this message to anyone. In such=20 case, you should destroy this message and kindly notify the=20 sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination,=20 disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited=20 and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages=20 of this kind. The opinions, conclusions and other information=20 in this message are of the author and shall be understood as=20 neither given nor endorsed by Vodafone Ireland Limited=20 unless it is otherwise indicated by an authorised representative=20 independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone=20 Ireland Limited has no control. As such, there is no guarantee that=20 (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender=20 (iii) this e-mail has not been intercepted by a third party=20 (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this=20 message (including its attachments) has been processed by an=20 automated anti-virus system; however it is the responsibility of=20 the recipient to ensure that the message (and attachments)=20 are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK),=20 Pauline Best (UK), Paul Donovan Chief Executive (UK),=20 Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18.=20 Number 326967 VAT Reg No. IE6346967G *************************************************************************= ***** From owner-aaa-wg@merit.edu Mon Mar 1 13:48: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 NAA27383 for ; Mon, 1 Mar 2004 13:48:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3AB9791221; Mon, 1 Mar 2004 13:48:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F294291223; Mon, 1 Mar 2004 13:48:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CC75091221 for ; Mon, 1 Mar 2004 13:48:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id AD68C5E0C3; Mon, 1 Mar 2004 13:48:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (unknown [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id AEA905E024 for ; Mon, 1 Mar 2004 13:48:26 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i21ImIF16732; Mon, 1 Mar 2004 10:48:18 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Mar 2004 12:48:18 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304DDD529@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'marco.stura@nokia.com'" Cc: harri.hakala@ericsson.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in mul tiple services feature Date: Mon, 1 Mar 2004 12:48:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FFBD.BE75C29A" 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_01C3FFBD.BE75C29A Content-Type: text/plain; charset="iso-8859-1" Thanks for the clarification Marco. -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Monday, March 01, 2004 10:34 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: harri.hakala@ericsson.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in mul tiple services feature Hi Chris, >Does this imply that the Rating-Group AVP needs to be part of the R-S-U AVP in section 8.18? >I think Rating-Group AVP needs to be added to R-S-U AVP. No, it doesn't imply this. The Rating-Group AVP is associate to the R-S-U in the M-S-C-C AVP. M-S-C-C (R-S-U, Rating-Group, Service-Id, U-S-U) >A client requests a resource allocation but does not request a certain amount (or unit) of resource (This is the usual case in the NAS environment). It leaves it up to the >server to supply the amount and the unit type. Yes, this is the usual case and it is achieved by an empty R-S-U AVP as also illustrated in Flow X by the notation R-S-U ( ). Note that all the AVPs in the R-S-U AVP structure are optional. Regards Marco -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 01 March, 2004 18:23 To: 'Harri Hakala (TU/LMF)'; Stura Marco (Nokia-NET/Helsinki); 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in mul tiple services feature Hi All, Does this imply that the Rating-Group AVP needs to be part of the R-S-U AVP in section 8.18? I think Rating-Group AVP needs to be added to R-S-U AVP. A client requests a resource allocation but does not request a certain amount (or unit) of resource (This is the usual case in the NAS environment). It leaves it up to the server to supply the amount and the unit type. Chris. -----Original Message----- From: Harri Hakala (TU/LMF) [ mailto:harri.hakala@ericsson.com ] Sent: Monday, March 01, 2004 6:17 AM To: 'marco.stura@nokia.com'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in mul tiple services feature assigned issue 23. / harri > -----Original Message----- > From: owner-aaa-wg@merit.edu > [ mailto:owner-aaa-wg@merit.edu ]On Behalf Of > marco.stura@nokia.com > Sent: 1. maaliskuuta 2004 14:13 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in > multiple services feature > > > Description of issue: clarification of R-S-U AVP usage in > multiple services feature > Submitter name: Marco Stura > Date first submitted: 1.03.2004 > Reference: > Document: draft-ietf-aaa-diameter-cc-03.txt > Comment type: T > Priority: 1 > Section: 5.2, 5.3, 8.16 and Flow X > > Rationale/Explanation of issues: > > When independent credit control of multiple services within a > (sub-)session is used, the Requested-Service-Unit AVP is used > by the client to indicate to the server that quota is > requested for the service/rating-group associated to it. > > The Requested-service-Unit AVP is to be present in all the > intermediate interrogations sent for the service/rating-group > if quota is still requested. If quota is not requested > anymore, for instance the client determined that the service > was terminated by the user, this is indicated by the absence > of the R-S-U AVP in the request command. > > The usage of the R-S-U AVP is not clearly specified in draft > 03, thus different interpretation of its usage may cause > potential interoperability problems between client and > servers of different vendors. For instance, a client may send > an intermediate interrogation without R-S-U AVP even though > it actually requests a new quota. The server may not returns > quota because it expects the R-S-U AVP to be present in the > request when quota is wanted. > > Requested change: > > -Section 5.2 second paragraph > > FROM > > > If the Diameter credit-control client knows the cost of > the service > event (e.g. a content server delivering ringing tones may > know their > cost) the monetary amount to be charged is included in the > Requested- > Service-Unit AVP. If the Diameter credit-control client > does not know > the cost of the service event, the Requested-Service-Unit AVP MAY > contain the number of requested service events. The > Service-Identifier > AVP, in case of multiple services the Service-Identifier > AVP or the > Rating-Group AVP within the Multiple-Services-Credit-Control AVP, > always indicates the concerned service. Additional service event > information to be rated MAY be sent as service specific > AVPs or MAY be > sent within the Service-Parameter-Info AVP at command level. > > TO > > If the Diameter credit-control client knows the cost of > the service > event (e.g. a content server delivering ringing tones may > know their > cost) the monetary amount to be charged is included in the > Requested- > Service-Unit AVP. If the Diameter credit-control client > does not know > the cost of the service event, the Requested-Service-Unit AVP MAY > contain the number of requested service events. Where the Multiple- > Services-Credit-Control AVP is used, it MUST contain the Requested- > Service-Unit AVP to indicate that quota for the associated service/ > rating-group is requested. The Service-Identifier AVP, in case of > multiple services the Service-Identifier AVP or the > Rating-Group AVP > within the Multiple-Services-Credit-Control AVP, always > indicates the > concerned service. Additional service event information > to be rated > MAY be sent as service specific AVPs or MAY be sent within the > Service-Parameter-Info AVP at command level. > > -Section 5.3 fifth paragraph > > FROM > > > The Requested-Service-Unit AVP MAY contain the new amount > of requested > service units. The Used-Service-Unit AVP contains the > amount of used > service units measured from the point when the service > became active > or, in case of interim interrogations are used during the session, > from the point when the previous measurement ended. The same unit > types that are used in the previous message MUST be used. > If several > unit types were included in the previous answer message the used > service units for each unit type MUST be reported. > > TO > > > The Requested-Service-Unit AVP MAY contain the new amount > of requested > service units. Where the Multiple-Services-Credit-Control > AVP is used, > it MUST contain the Requested-Service-Unit AVP if new > quota for the > associated service/rating-group is requested. The > Used-Service-Unit AVP > contains the amount of used service units measured from > the point when > the service became active or, in case of interim > interrogations are > used during the session, from the point when the previous > measurement > ended. The same unit types that are used in the previous > message MUST > be used. If several unit types were included in the > previous answer > message the used service units for each unit type MUST be reported. > > -Section 8.16 > > ADD after third paragrapf > > The Requested-Service-Unit AVP MAY contain the amount of requested > service units or the requested monetary value. It MUST be > present in > the initial interrogation and within the intermediate > interrogations > where new quota is requested. If the credit-control client does not > include the Requested-Service-Unit AVP in a request command, for > instance because it has determined that the end-user terminated the > service, the server MUST debit the used amount from the > user's account > but MUST NOT return a new quota in the corresponding answer. > > - Flow X add the R-S-U AVP in message 11 and 13 as follow. > > | +--------------+ | | > | |Validity time | |(11)CCR(update, | > | |expires for | | Multiple-Services-CC ( | > | |Service-Id | | Requested-Units(), | > | | access | | Used-Units(In-Octets,Out-Octets),| > | +--------------+ | Service-Id access)) | > | > |---------------------------------------->| > | |(12)CCA(Multiple-Services-CC ( | > | | Granted-Units(Total-Octets), | > | | Service-Id access, | > | | Validity-time, | > | | G-S-U-Pool-Reference(Pool-Id 1, | > | | Multiplier 10))) | > | |<----------------------------------------| > : : : > : : : > | +--------------+ | | > | |Total Quota | |(13)CCR(update, | > | |elapses for | | Multiple-Services-CC ( | > | |pool 2: | | Requested-Units(), | > | |service 4 not | | Used-Units(In-Octets,Out-Octets),| > | |allowed, | | Service-Id 3, Rating-group 2), | > | |service 3 cont| | Multiple-Services-CC ( | > | +--------------+ | Used-Units(In-Octets,Out-Octets),| > | | Service-Id 4, Rating-group 3)) | > | > |---------------------------------------->| > | |(14)CCA(Multiple-Services-CC ( | > | | Result-Code 4011, | > | | Service-Id 3)) | > | |<----------------------------------------| > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3FFBD.BE75C29A Content-Type: text/html; charset="iso-8859-1" RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in mul tiple services feature
Thanks for the clarification Marco.
-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Monday, March 01, 2004 10:34 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: harri.hakala@ericsson.com; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in mul tiple services feature

Hi Chris,
 
>Does this imply that the Rating-Group AVP needs to be part of the R-S-U AVP in section 8.18?
>I think Rating-Group AVP needs to be added to R-S-U AVP.
 
No, it doesn't imply this. The Rating-Group AVP is associate to the R-S-U in the M-S-C-C AVP.
 
M-S-C-C (R-S-U, Rating-Group, Service-Id, U-S-U)
 
>A client requests a resource allocation but does not request a certain amount (or unit) of resource (This is the usual case in the NAS environment). It leaves it up to the >server to supply the amount and the unit type.
 
Yes, this is the usual case and it is achieved by an empty R-S-U AVP as also illustrated in Flow X by the notation R-S-U ( ).
Note that all the AVPs in the R-S-U AVP structure are optional.
 
Regards
Marco
-----Original Message-----
From: ext Christopher Richards [mailto:crich@nortelnetworks.com]
Sent: 01 March, 2004 18:23
To: 'Harri Hakala (TU/LMF)'; Stura Marco (Nokia-NET/Helsinki); 'aaa-wg@merit.edu'
Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in mul tiple services feature

Hi All,

Does this imply that the Rating-Group AVP needs to be part of the R-S-U AVP in section 8.18?
I think Rating-Group AVP needs to be added to R-S-U AVP.

A client requests a resource allocation but does not request a certain amount (or unit) of resource (This is the usual case in the NAS environment). It leaves it up to the server to supply the amount and the unit type.

Chris.

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com]
Sent: Monday, March 01, 2004 6:17 AM
To: 'marco.stura@nokia.com'; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in
mul tiple services feature


assigned issue 23.

/ harri

> -----Original Message-----
> From: owner-aaa-wg@merit.edu
> [mailto:owner-aaa-wg@merit.edu]On Behalf Of
> marco.stura@nokia.com
> Sent: 1. maaliskuuta 2004 14:13
> To: aaa-wg@merit.edu
> Subject: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in
> multiple services feature
>
>
> Description of issue: clarification of R-S-U AVP usage in
> multiple services feature
> Submitter name:  Marco Stura
> Date first submitted: 1.03.2004
> Reference:
> Document: draft-ietf-aaa-diameter-cc-03.txt
> Comment type: T
> Priority: 1
> Section: 5.2, 5.3, 8.16 and Flow X
>
> Rationale/Explanation of issues:
>
> When independent credit control of multiple services within a
> (sub-)session is used, the Requested-Service-Unit AVP is used
> by the client to indicate to the server that quota is
> requested for the service/rating-group associated to it.
>
> The Requested-service-Unit AVP is to be present in all the
> intermediate interrogations sent for the service/rating-group
> if quota is still requested. If quota is not requested
> anymore, for instance the client determined that the service
> was terminated by the user, this is indicated by the absence
> of the R-S-U AVP in the request command.
>
> The usage of the R-S-U AVP is not clearly specified in draft
> 03, thus different interpretation of its usage may cause
> potential interoperability problems between client and
> servers of different vendors. For instance, a client may send
> an intermediate interrogation  without R-S-U AVP even though
> it actually requests a new quota. The server may not returns
> quota because it expects the R-S-U AVP to be present in the
> request when quota is wanted.
>
> Requested change:
>
> -Section 5.2 second paragraph
>
> FROM
>
>
>    If the Diameter credit-control client knows the cost of
> the service
>    event (e.g. a content server delivering ringing tones may
> know their
>    cost) the monetary amount to be charged is included in the
> Requested-
>    Service-Unit AVP. If the Diameter credit-control client
> does not know
>    the cost of the service event, the Requested-Service-Unit AVP MAY
>    contain the number of requested service events. The
> Service-Identifier
>    AVP, in case of multiple services the Service-Identifier
> AVP or the
>    Rating-Group AVP within the Multiple-Services-Credit-Control AVP,
>    always indicates the concerned service.  Additional service event
>    information to be rated MAY be sent as service specific
> AVPs or MAY be
>    sent within the Service-Parameter-Info AVP at command level.
>
> TO
>
>    If the Diameter credit-control client knows the cost of
> the service
>    event (e.g. a content server delivering ringing tones may
> know their
>    cost) the monetary amount to be charged is included in the
> Requested-
>    Service-Unit AVP. If the Diameter credit-control client
> does not know
>    the cost of the service event, the Requested-Service-Unit AVP MAY
>    contain the number of requested service events. Where the Multiple-
>    Services-Credit-Control AVP is used, it MUST contain the Requested-
>    Service-Unit AVP to indicate that quota for the associated service/
>    rating-group is requested. The Service-Identifier AVP, in case of
>    multiple services the Service-Identifier AVP or the
> Rating-Group AVP
>    within the Multiple-Services-Credit-Control AVP, always
> indicates the
>    concerned service.  Additional service event information
> to be rated
>    MAY be sent as service specific AVPs or MAY be sent within the
>    Service-Parameter-Info AVP at command level.
>
> -Section 5.3 fifth paragraph
>
> FROM
>
>
>    The Requested-Service-Unit AVP MAY contain the new amount
> of requested
>    service units. The Used-Service-Unit AVP contains the
> amount of used
>    service units measured from the point when the service
> became active
>    or, in case of interim interrogations are used during the session,
>    from the point when the previous measurement ended. The same unit
>    types that are used in the previous message MUST be used.
> If several
>    unit types were included in the previous answer message the used
>    service units for each unit type MUST be reported. 
>
> TO
>
>
>    The Requested-Service-Unit AVP MAY contain the new amount
> of requested
>    service units. Where the Multiple-Services-Credit-Control
> AVP is used,
>    it MUST contain the Requested-Service-Unit AVP if new
> quota for the
>    associated service/rating-group is requested. The
> Used-Service-Unit AVP
>    contains the amount of used service units measured from
> the point when
>    the service became active or, in case of interim
> interrogations are
>    used during the session, from the point when the previous
> measurement
>    ended. The same unit types that are used in the previous
> message MUST
>    be used. If several unit types were included in the
> previous answer
>    message the used service units for each unit type MUST be reported.
> 
> -Section 8.16
>
> ADD after third paragrapf
>
>    The Requested-Service-Unit AVP MAY contain the amount of requested
>    service units or the requested monetary value. It MUST be
> present in
>    the initial interrogation and within the intermediate
> interrogations
>    where new quota is requested. If the credit-control client does not
>    include the Requested-Service-Unit AVP in a request command, for
>    instance because it has determined that the end-user terminated the
>    service, the server MUST debit the used amount from the
> user's account
>    but MUST NOT return a new quota in the corresponding answer.
>
> - Flow X add the R-S-U AVP in message 11 and 13 as follow.
>
>      | +--------------+  |                                         | 
>      | |Validity time |  |(11)CCR(update,                          | 
>      | |expires for   |  |        Multiple-Services-CC (           | 
>      | |Service-Id    |  |        Requested-Units(),               |
>      | | access       |  |        Used-Units(In-Octets,Out-Octets),|
>      | +--------------+  |        Service-Id access))              |
>      |                  
> |---------------------------------------->|  
>      |                   |(12)CCA(Multiple-Services-CC (           |
>      |                   |        Granted-Units(Total-Octets),     | 
>      |                   |        Service-Id access,               | 
>      |                   |        Validity-time,                   |
>      |                   |        G-S-U-Pool-Reference(Pool-Id 1,  | 
>      |                   |          Multiplier 10)))               |
>      |                   |<----------------------------------------| 
>      :                   :                                         : 
>      :                   :                                         : 
>      | +--------------+  |                                         | 
>      | |Total Quota   |  |(13)CCR(update,                          | 
>      | |elapses for   |  |       Multiple-Services-CC (            | 
>      | |pool 2:       |  |        Requested-Units(),               |
>      | |service 4 not |  |        Used-Units(In-Octets,Out-Octets),|
>      | |allowed,      |  |        Service-Id 3, Rating-group 2),   |
>      | |service 3 cont|  |       Multiple-Services-CC (            | 
>      | +--------------+  |        Used-Units(In-Octets,Out-Octets),|
>      |                   |        Service-Id 4, Rating-group 3))   |
>      |                  
> |---------------------------------------->|  
>      |                   |(14)CCA(Multiple-Services-CC (           |
>      |                   |        Result-Code 4011,                | 
>      |                   |        Service-Id 3))                   |
>      |                   |<----------------------------------------| 
>

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

------_=_NextPart_001_01C3FFBD.BE75C29A-- From owner-aaa-wg@merit.edu Tue Mar 2 00:47:52 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 AAA04036 for ; Tue, 2 Mar 2004 00:47:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CA17091208; Tue, 2 Mar 2004 00:47:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95EA091284; Tue, 2 Mar 2004 00:47:41 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5CFDE91208 for ; Tue, 2 Mar 2004 00:47:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1CF9C5E20D; Tue, 2 Mar 2004 00:47:35 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by segue.merit.edu (Postfix) with ESMTP id 2D70E5E4A6 for ; Tue, 2 Mar 2004 00:47:33 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i225lUKL013549; Tue, 2 Mar 2004 14:47:30 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i225lUAB026266; Tue, 2 Mar 2004 14:47:30 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id QAA26263 ; Tue, 2 Mar 2004 14:47:30 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id OAA07211; Tue, 2 Mar 2004 14:47:29 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id OAA06378; Tue, 2 Mar 2004 14:47:28 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i225lP51009878; Tue, 2 Mar 2004 14:47:26 +0900 (JST) Received: from steelhead ([159.119.168.90]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HTX00CPKPEOYV@tsbpo1.po.toshiba.co.jp>; Tue, 2 Mar 2004 14:47:13 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AxVa2-0001eq-00; Sun, 29 Feb 2004 10:22:22 -0800 Date: Sun, 29 Feb 2004 10:22:21 -0800 From: Yoshihiro Ohba Subject: [AAA-WG]: comments on Diameter EAP To: aaa-wg@merit.edu Message-id: <20040229182221.GG6087@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-aaa-wg@merit.edu Precedence: bulk I have one editorial comment. The following AVPs seem to be missing in the ABNF: EAP-Reissued-Payload EAP-Master-Session-Key Accounting-EAP-Auth-Method Please check. Yoshihiro Ohba From owner-aaa-wg@merit.edu Tue Mar 2 02:00: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 CAA08621 for ; Tue, 2 Mar 2004 02:00:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C8DEB91209; Tue, 2 Mar 2004 02:00:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94BA19120D; Tue, 2 Mar 2004 02:00:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3F59891209 for ; Tue, 2 Mar 2004 02:00:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 552FF5E415; Tue, 2 Mar 2004 02:00:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by segue.merit.edu (Postfix) with ESMTP id 68D615E42B for ; Tue, 2 Mar 2004 02:00:34 -0500 (EST) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2270Ur22348; Tue, 2 Mar 2004 01:00:31 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i2270Pe18737; Tue, 2 Mar 2004 01:00:29 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HTXSRP-0001L0-00; Tue, 02 Mar 2004 01:59:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16452.12516.350198.676228@gargle.gargle.HOWL> Date: Tue, 2 Mar 2004 00:59:48 -0600 From: Pete McCann To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA URI syntax X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Following up to the point I raised at the meeting today: According to my reading of RFC 2396 (Uniform Resource Identifiers (URI): Generic Syntax), the syntax given for the AAA URI in RFC 3588 is broken. See Appendix A of 2396. Because we are using a //, the thing after the slash is a "hier_part". In a "hier_part", we have an "authority" followed by an optional "abs_path". The only way to get a ";" "path" is to use an "abs_path", and an "abs_path" must begin with a /. In the examples given in RFC 3588, there is no / before the parameters. So, there seem to be two options here. We could remove the // from our URI syntax, making it into scheme:opaque_part. We can format the opaque_part however we would like. Alternatively, we could add a / after the authority name before we add parameters. This would mean: aaa://host.example.com/;transport=tcp This would be the least amount of change; however, it looks a little ugly. -Pete p.s. Thanks to Adam Costello for first noticing this and pointing it out. -Pete From owner-aaa-wg@merit.edu Tue Mar 2 02:27: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 CAA22084 for ; Tue, 2 Mar 2004 02:27:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 561FA9120D; Tue, 2 Mar 2004 02:27:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 23F3A91289; Tue, 2 Mar 2004 02:27:25 -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 A45589120D for ; Tue, 2 Mar 2004 02:27:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8C0B35E591; Tue, 2 Mar 2004 02:27:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id D45C75E58B for ; Tue, 2 Mar 2004 02:27:22 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i227RLqY001768 for ; Tue, 2 Mar 2004 08:27:21 +0100 (MET) 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, 2 Mar 2004 08:27:21 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 2 Mar 2004 08:27:58 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'John.Prudhoe@vodafone.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechani sm Date: Tue, 2 Mar 2004 08:27:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40027.88862EB2" X-OriginalArrivalTime: 02 Mar 2004 07:27:21.0593 (UTC) FILETIME=[CCFACE90:01C40027] 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_01C40027.88862EB2 Content-Type: text/plain; charset="iso-8859-1" Assigned issue 27. / Harri -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com Sent: 1. maaliskuuta 2004 17:53 To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism Description of issue: Client Support of Tariff Change Mechanism Submitter name: John Prudhoe Date first submitted: 1.03.2004 Reference: Document: draft-ietf-aaa-diameter-cc-03.txt Comment type: E Priority: Section: 8.27 Rationale/Explanation of issues: In section 5.1 it is only specified that the client SHOULD support the tariff change mechanism and the itemising of usage using the Tariff-Change-Usage AVP. I believe the last sentence of section 8.27 (Tariff-Change-Usage AVP) is meant to support this, but it is not clear. My suggested change is in section 8.27: FROM Omission of this AVP means that no tariff change has been occurred. TO If the client does not support the itemisation of tariff change usage, when the Tariff-Time-Change AVP was present in the previous answer, this AVP MUST be omitted. Regards, John. In the last paragraph of 5.1 (p16 of cc-03) change SHOULD to MUST ****************************************************************************** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination, disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages of this kind. The opinions, conclusions and other information in this message are of the author and shall be understood as neither given nor endorsed by Vodafone Ireland Limited unless it is otherwise indicated by an authorised representative independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone Ireland Limited has no control. As such, there is no guarantee that (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender (iii) this e-mail has not been intercepted by a third party (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this message (including its attachments) has been processed by an automated anti-virus system; however it is the responsibility of the recipient to ensure that the message (and attachments) are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18. Number 326967 VAT Reg No. IE6346967G ****************************************************************************** This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C40027.88862EB2 Content-Type: text/html; charset="iso-8859-1"

Assigned issue 27.

/ Harri

-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com
Sent: 1. maaliskuuta 2004 17:53
To: aaa-wg@merit.edu
Subject: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism


Description of issue:  Client Support of Tariff Change Mechanism
Submitter name:  John Prudhoe
Date first submitted: 1.03.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-03.txt
Comment type: E
Priority:
Section: 8.27

Rationale/Explanation of issues:

In section 5.1 it is only specified that the client SHOULD support the tariff change mechanism and the itemising of usage using the Tariff-Change-Usage AVP.

I believe the last sentence of section 8.27 (Tariff-Change-Usage AVP) is meant to support this, but it is not clear.

My suggested change is in section 8.27:

FROM

Omission of this AVP means that no tariff change has been occurred.

TO

If the client does not support the itemisation of tariff change usage, when the Tariff-Time-Change AVP was present in the previous answer, this AVP MUST be omitted.


Regards,

John.



















In the last paragraph of 5.1 (p16 of cc-03)


change SHOULD to MUST

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

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

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

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
------_=_NextPart_001_01C40027.88862EB2-- From owner-aaa-wg@merit.edu Tue Mar 2 02:28:51 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 CAA22179 for ; Tue, 2 Mar 2004 02:28:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CC5BB91289; Tue, 2 Mar 2004 02:28:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 819059128D; Tue, 2 Mar 2004 02:28:38 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EFED991289 for ; Tue, 2 Mar 2004 02:28:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id D471E5E5AC; Tue, 2 Mar 2004 02:28:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 5F85F5E597 for ; Tue, 2 Mar 2004 02:28:36 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i227SZqY002127 for ; Tue, 2 Mar 2004 08:28:35 +0100 (MET) 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, 2 Mar 2004 08:28:35 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 2 Mar 2004 08:29:12 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'John.Prudhoe@vodafone.com'" , marco.stura@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechani sm Date: Tue, 2 Mar 2004 08:28:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Mar 2004 07:28:35.0539 (UTC) FILETIME=[F90E1230:01C40027] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, It seems that the tariff switch mechanism is not defined very clearly in section 5.1, perhaps we can add one sentence to clarify its usage, in case when client does not support tariff switch mechanism. For instance we can add sentence (or something similar): If a client does not support the tariff change mechanism, and it receives a CCA message carrying Tariff-Time-Change AVP, it MUST terminate the credit control session with proper Termination-Cause AVP reason included. Regards.........Harri -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com Sent: 1. maaliskuuta 2004 18:41 To: marco.stura@nokia.com Cc: aaa-wg@merit.edu; John.Prudhoe@vodafone.com Subject: RE: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism Hi Marco, OK, I was concentrating on 5.1 & missed 8.20. This is a better solution than I thought the mechanism was. I agree that some rewording of 5.1 is necessary as you suggest. Regards, John. 01/03/2004 16:25 To: cc: Subject: RE: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism Hi John, the tariff-time-change mechanism consists of a server instructing the client when the tariff change will occurs and of a client reporting units used before and after tariff change. in section 8.20 it is specified that If a client does not support the tariff time change mechanism it MUST treat Tariff-Time-Change AVP in the answer message as an incorrect CCA answer. In that case the client terminates the credit control session and indicate in the Termination-Cause AVP reason DIAMETER_BAD_ANSWER. Then, if the client accept the Tariff-Time-Change AVP it is because it supports the itemising of usage using the Tariff-Change-Usage AVP. You wrote: >If the client does not support the itemisation of tariff change usage, when the Tariff-Time-Change AVP was present in the > >previous answer, this AVP MUST be omitted. According to section 8.20, this case shouldn't happen. The SHOULD keyword was used because it is not sure whether the tariff change will occur during the reporting period. Perhaps the sentence in 5.1 should be rephrased so that "when a tariff change occurs during the reporting period the client MUST itemize..."? Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext John.Prudhoe@vodafone.com Sent: 01 March, 2004 17:53 To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism Description of issue: Client Support of Tariff Change Mechanism Submitter name: John Prudhoe Date first submitted: 1.03.2004 Reference: Document: draft-ietf-aaa-diameter-cc-03.txt Comment type: E Priority: Section: 8.27 Rationale/Explanation of issues: In section 5.1 it is only specified that the client SHOULD support the tariff change mechanism and the itemising of usage using the Tariff-Change-Usage AVP. I believe the last sentence of section 8.27 (Tariff-Change-Usage AVP) is meant to support this, but it is not clear. My suggested change is in section 8.27: FROM Omission of this AVP means that no tariff change has been occurred. TO If the client does not support the itemisation of tariff change usage, when the Tariff-Time-Change AVP was present in the previous answer, this AVP MUST be omitted. Regards, John. In the last paragraph of 5.1 (p16 of cc-03) change SHOULD to MUST ****************************************************************************** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination, disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages of this kind. The opinions, conclusions and other information in this message are of the author and shall be understood as neither given nor endorsed by Vodafone Ireland Limited unless it is otherwise indicated by an authorised representative independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone Ireland Limited has no control. As such, there is no guarantee that (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender (iii) this e-mail has not been intercepted by a third party (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this message (including its attachments) has been processed by an automated anti-virus system; however it is the responsibility of the recipient to ensure that the message (and attachments) are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18. Number 326967 VAT Reg No. IE6346967G ****************************************************************************** This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-aaa-wg@merit.edu Tue Mar 2 08:42: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 IAA09347 for ; Tue, 2 Mar 2004 08:42:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0AC0291212; Tue, 2 Mar 2004 08:42:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6B039128C; Tue, 2 Mar 2004 08:42:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4124791212 for ; Tue, 2 Mar 2004 08:42:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2B2CF5E79D; Tue, 2 Mar 2004 08:42:05 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailsweep01.vodafone.ie (unknown [213.233.159.70]) by segue.merit.edu (Postfix) with ESMTP id CD6E95E7BC for ; Tue, 2 Mar 2004 08:42:03 -0500 (EST) Received: from eircellnotes5.eircell.ie (unverified) by mailsweep01.vodafone.ie (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Tue, 2 Mar 2004 13:46:36 +0000 To: Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John.Prudhoe@vodafone.com Date: Tue, 2 Mar 2004 13:41:58 +0000 X-MIMETrack: Serialize by Router on Notes5/Vodafone(Release 5.0.10 |March 22, 2002) at 03/02/2004 01:42:00 PM, Serialize complete at 03/02/2004 01:42:00 PM Content-Type: multipart/alternative; boundary="=_alternative 004B3E1280256E4B_=" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004B3E1280256E4B_= Content-Type: text/plain; charset="us-ascii" Hi Marco, Here is an updated version of the issue. Description of issue: Client Support of Tariff Change Mechanism Submitter name: John Prudhoe Date first submitted: 1.03.2004 Reference: 27 Document: draft-ietf-aaa-diameter-cc-03.txt Comment type: T Priority: Section: 5.1 Rationale/Explanation of issues: The Diameter credit-control client must support the Tariff-Time-Change AVP if sent by the server, but this is not reflected in the wording of section 5.1. Proposed change: FROM When the Diameter credit-control client reports the used units and a tariff change has occurred during the reporting period then the Diameter credit-control client SHOULD itemize the units used before and after the tariff change. In case some units straddle the tariff change, the credit-control client SHOULD itemize those units as well. TO When the Diameter credit-control client reports the used units and a tariff change has occurred during the reporting period then the Diameter credit-control client MUST separately itemize the units used before and after the tariff change. In case the client is unable to distinguish whether units that straddle the tariff change are used before or after the tariff change, the credit-control client MUST itemize those units in a third category. If a client does not support the tariff change mechanism, and it receives a CCA message carrying the Tariff-Time-Change AVP, it MUST terminate the credit control session, giving a reason of DIAMETER_BAD_ANSWER in the Termination-Cause AVP. Regards, John. 01/03/2004 16:25 To: cc: Subject: RE: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism Hi John, the tariff-time-change mechanism consists of a server instructing the client when the tariff change will occurs and of a client reporting units used before and after tariff change. in section 8.20 it is specified that If a client does not support the tariff time change mechanism it MUST treat Tariff-Time-Change AVP in the answer message as an incorrect CCA answer. In that case the client terminates the credit control session and indicate in the Termination-Cause AVP reason DIAMETER_BAD_ANSWER. Then, if the client accept the Tariff-Time-Change AVP it is because it supports the itemising of usage using the Tariff-Change-Usage AVP. You wrote: >If the client does not support the itemisation of tariff change usage, when the Tariff-Time-Change AVP was present in the > >previous answer, this AVP MUST be omitted. According to section 8.20, this case shouldn't happen. The SHOULD keyword was used because it is not sure whether the tariff change will occur during the reporting period. Perhaps the sentence in 5.1 should be rephrased so that "when a tariff change occurs during the reporting period the client MUST itemize..."? Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext John.Prudhoe@vodafone.com Sent: 01 March, 2004 17:53 To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism Description of issue: Client Support of Tariff Change Mechanism Submitter name: John Prudhoe Date first submitted: 1.03.2004 Reference: Document: draft-ietf-aaa-diameter-cc-03.txt Comment type: E Priority: Section: 8.27 Rationale/Explanation of issues: In section 5.1 it is only specified that the client SHOULD support the tariff change mechanism and the itemising of usage using the Tariff-Change-Usage AVP. I believe the last sentence of section 8.27 (Tariff-Change-Usage AVP) is meant to support this, but it is not clear. My suggested change is in section 8.27: FROM Omission of this AVP means that no tariff change has been occurred. TO If the client does not support the itemisation of tariff change usage, when the Tariff-Time-Change AVP was present in the previous answer, this AVP MUST be omitted. Regards, John. In the last paragraph of 5.1 (p16 of cc-03) change SHOULD to MUST ****************************************************************************** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination, disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages of this kind. The opinions, conclusions and other information in this message are of the author and shall be understood as neither given nor endorsed by Vodafone Ireland Limited unless it is otherwise indicated by an authorised representative independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone Ireland Limited has no control. As such, there is no guarantee that (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender (iii) this e-mail has not been intercepted by a third party (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this message (including its attachments) has been processed by an automated anti-virus system; however it is the responsibility of the recipient to ensure that the message (and attachments) are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18. Number 326967 VAT Reg No. IE6346967G ****************************************************************************** --=_alternative 004B3E1280256E4B_= Content-Type: text/html; charset="us-ascii"
Hi Marco,

Here is an updated version of the issue.


Description of issue:  Client Support of Tariff Change Mechanism
Submitter name:  John Prudhoe
Date first submitted: 1.03.2004
Reference: 27
Document: draft-ietf-aaa-diameter-cc-03.txt
Comment type: T
Priority:
Section: 5.1

Rationale/Explanation of issues:

The Diameter credit-control client must support the Tariff-Time-Change AVP if sent by the server, but this is not reflected in the wording of section 5.1.

Proposed change:

FROM

When the Diameter credit-control client reports the used units and a tariff change has occurred during the reporting period then the Diameter credit-control client SHOULD itemize the units used before and after the tariff change.  In case some units straddle the tariff change, the credit-control client SHOULD itemize those units as well.

TO

When the Diameter credit-control client reports the used units and a tariff change has occurred during the reporting period then the Diameter credit-control client MUST separately itemize the units used before and after the tariff change.  In case the client is unable to distinguish whether units that straddle the tariff change are used before or after the tariff change, the credit-control client MUST itemize those units in a third category.

If a client does not support the tariff change mechanism, and it receives a CCA message carrying the Tariff-Time-Change AVP, it MUST terminate the credit control session, giving a reason of DIAMETER_BAD_ANSWER in the Termination-Cause AVP.


Regards,

John.







<marco.stura@nokia.com>

01/03/2004 16:25

       
        To:        <John.Prudhoe@vodafone.com>
        cc:        <aaa-wg@merit.edu>
        Subject:        RE: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism



Hi John,

the tariff-time-change mechanism consists of a server instructing the client when the tariff change will occurs and
of a client reporting units used before and after tariff change.

in section 8.20 it is specified that

  If a client does not support the tariff time change mechanism it MUST
  treat Tariff-Time-Change AVP in the answer message as an incorrect
  CCA answer. In that case the client terminates the credit control
  session and indicate in the Termination-Cause AVP reason
  DIAMETER_BAD_ANSWER.

Then, if the client accept the Tariff-Time-Change AVP it is because it supports the itemising of
usage using the Tariff-Change-Usage AVP.

You wrote:

>If the client does not support the itemisation of tariff change usage, when the Tariff-Time-Change AVP was present in the >
>previous answer, this AVP MUST be omitted.

According to section 8.20, this case shouldn't happen.
The SHOULD keyword was used because it is not sure whether the tariff change will occur during the reporting
period. Perhaps the sentence in 5.1 should be rephrased so that "when a tariff change occurs during the
reporting period the client MUST itemize..."?

Regards
Marco

-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext John.Prudhoe@vodafone.com
Sent: 01 March, 2004 17:53
To: aaa-wg@merit.edu
Subject: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism



Description of issue:  Client Support of Tariff Change Mechanism
Submitter name:  John Prudhoe
Date first submitted: 1.03.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-03.txt
Comment type: E
Priority:
Section: 8.27

Rationale/Explanation of issues:

In section 5.1 it is only specified that the client SHOULD support the tariff change mechanism and the itemising of usage using the Tariff-Change-Usage AVP.

I believe the last sentence of section 8.27 (Tariff-Change-Usage AVP) is meant to support this, but it is not clear.

My suggested change is in section 8.27:

FROM

Omission of this AVP means that no tariff change has been occurred.

TO

If the client does not support the itemisation of tariff change usage, when the Tariff-Time-Change AVP was present in the previous answer, this AVP MUST be omitted.


Regards,

John.



















In the last paragraph of 5.1 (p16 of cc-03)


change SHOULD to MUST

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

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

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

--=_alternative 004B3E1280256E4B_=-- From owner-aaa-wg@merit.edu Tue Mar 2 09: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 JAA11264 for ; Tue, 2 Mar 2004 09:27:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CD28891211; Tue, 2 Mar 2004 09:27:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 98F5B91213; Tue, 2 Mar 2004 09:27:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9562A91211 for ; Tue, 2 Mar 2004 09:27:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6C0DC5E7CC; Tue, 2 Mar 2004 09:27:00 -0500 (EST) 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 1CED25E7ED for ; Tue, 2 Mar 2004 09:26:59 -0500 (EST) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i22EQs721542; Tue, 2 Mar 2004 16:26:54 +0200 (EET) X-Scanned: Tue, 2 Mar 2004 16:25:23 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i22EPNjw017690; Tue, 2 Mar 2004 16:25:23 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 008hn1w4; Tue, 02 Mar 2004 16:25:23 EET 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 i22EPK713233; Tue, 2 Mar 2004 16:25:20 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Mar 2004 16:25:20 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40062.312DA42A" Subject: RE: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism Date: Tue, 2 Mar 2004 16:25:20 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C8507@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism Thread-Index: AcQAXGAwsTuk+AjhRmWoA2/8d/4hYgABbwHw From: To: Cc: X-OriginalArrivalTime: 02 Mar 2004 14:25:20.0410 (UTC) FILETIME=[311E97A0:01C40062] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C40062.312DA42A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you for the issue update John. =20 Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext John.Prudhoe@vodafone.com Sent: 02 March, 2004 15:42 To: Stura Marco (Nokia-NET/Helsinki) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Client Support of Tariff Change = Mechanism Hi Marco,=20 Here is an updated version of the issue.=20 Description of issue: Client Support of Tariff Change Mechanism Submitter name: John Prudhoe Date first submitted: 1.03.2004=20 Reference: 27 Document: draft-ietf-aaa-diameter-cc-03.txt=20 Comment type: T Priority:=20 Section: 5.1 Rationale/Explanation of issues:=20 The Diameter credit-control client must support the Tariff-Time-Change = AVP if sent by the server, but this is not reflected in the wording of = section 5.1.=20 Proposed change:=20 FROM=20 When the Diameter credit-control client reports the used units and a = tariff change has occurred during the reporting period then the Diameter = credit-control client SHOULD itemize the units used before and after the = tariff change. In case some units straddle the tariff change, the = credit-control client SHOULD itemize those units as well.=20 TO=20 When the Diameter credit-control client reports the used units and a = tariff change has occurred during the reporting period then the Diameter = credit-control client MUST separately itemize the units used before and = after the tariff change. In case the client is unable to distinguish = whether units that straddle the tariff change are used before or after = the tariff change, the credit-control client MUST itemize those units in = a third category.=20 If a client does not support the tariff change mechanism, and it = receives a CCA message carrying the Tariff-Time-Change AVP, it MUST = terminate the credit control session, giving a reason of = DIAMETER_BAD_ANSWER in the Termination-Cause AVP. Regards,=20 John.=20 =20 01/03/2004 16:25=20 =20 To: =20 cc: =20 Subject: RE: [AAA-WG]: DCC: Issue: Client Support of = Tariff Change Mechanism Hi John, the tariff-time-change mechanism consists of a server instructing the = client when the tariff change will occurs and of a client reporting units used before and after tariff change. in section 8.20 it is specified that=20 If a client does not support the tariff time change mechanism it MUST=20 treat Tariff-Time-Change AVP in the answer message as an incorrect=20 CCA answer. In that case the client terminates the credit control=20 session and indicate in the Termination-Cause AVP reason=20 DIAMETER_BAD_ANSWER.=20 Then, if the client accept the Tariff-Time-Change AVP it is because it = supports the itemising of usage using the Tariff-Change-Usage AVP. You wrote: >If the client does not support the itemisation of tariff change usage, = when the Tariff-Time-Change AVP was present in the > >previous answer, this AVP MUST be omitted.=20 According to section 8.20, this case shouldn't happen. The SHOULD keyword was used because it is not sure whether the tariff = change will occur during the reporting period. Perhaps the sentence in 5.1 should be rephrased so that "when a = tariff change occurs during the reporting period the client MUST itemize..."? Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext John.Prudhoe@vodafone.com Sent: 01 March, 2004 17:53 To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism Description of issue: Client Support of Tariff Change Mechanism Submitter name: John Prudhoe Date first submitted: 1.03.2004=20 Reference:=20 Document: draft-ietf-aaa-diameter-cc-03.txt=20 Comment type: E Priority:=20 Section: 8.27 Rationale/Explanation of issues:=20 In section 5.1 it is only specified that the client SHOULD support the = tariff change mechanism and the itemising of usage using the = Tariff-Change-Usage AVP.=20 I believe the last sentence of section 8.27 (Tariff-Change-Usage AVP) is = meant to support this, but it is not clear.=20 My suggested change is in section 8.27:=20 FROM=20 Omission of this AVP means that no tariff change has been occurred.=20 TO=20 If the client does not support the itemisation of tariff change usage, = when the Tariff-Time-Change AVP was present in the previous answer, this = AVP MUST be omitted.=20 Regards,=20 John.=20 In the last paragraph of 5.1 (p16 of cc-03)=20 change SHOULD to MUST *************************************************************************= ***** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message=20 (or responsible for delivery of the message to such person),=20 you may not copy or deliver this message to anyone. In such=20 case, you should destroy this message and kindly notify the=20 sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination,=20 disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited=20 and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages=20 of this kind. The opinions, conclusions and other information=20 in this message are of the author and shall be understood as=20 neither given nor endorsed by Vodafone Ireland Limited=20 unless it is otherwise indicated by an authorised representative=20 independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone=20 Ireland Limited has no control. As such, there is no guarantee that=20 (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender=20 (iii) this e-mail has not been intercepted by a third party=20 (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this=20 message (including its attachments) has been processed by an=20 automated anti-virus system; however it is the responsibility of=20 the recipient to ensure that the message (and attachments)=20 are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK),=20 Pauline Best (UK), Paul Donovan Chief Executive (UK),=20 Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18.=20 Number 326967 VAT Reg No. IE6346967G *************************************************************************= ***** ------_=_NextPart_001_01C40062.312DA42A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thank=20 you for the issue update John.
 
Regards
Marco
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext=20 John.Prudhoe@vodafone.com
Sent: 02 March, 2004 = 15:42
To:=20 Stura Marco (Nokia-NET/Helsinki)
Cc:=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: Issue: Client = Support=20 of Tariff Change Mechanism


Hi=20 Marco,

Here is an updated = version of=20 the issue.


Description of=20 issue:  Client Support of Tariff Change Mechanism
Submitter = name:=20  John Prudhoe
Date first submitted: 1.03.2004
Reference:=20 27
Document: draft-ietf-aaa-diameter-cc-03.txt
Comment type:=20 T
Priority:
Section: 5.1

Rationale/Explanation of = issues:=20

The Diameter = credit-control=20 client must support the Tariff-Time-Change AVP if sent by the server, = but this=20 is not reflected in the wording of section 5.1.

Proposed change:

FROM

When the Diameter credit-control client reports the used = units and a=20 tariff change has occurred during the reporting period then the = Diameter=20 credit-control client SHOULD itemize the units used before and after = the=20 tariff change.  In case some units straddle the tariff change, = the=20 credit-control client SHOULD itemize those units as well. =

TO

When the Diameter credit-control client reports the used = units and a=20 tariff change has occurred during the reporting period then the = Diameter=20 credit-control client MUST separately itemize the units used before = and after=20 the tariff change.  In case the client is unable to distinguish = whether=20 units that straddle the tariff change are used before or after the = tariff=20 change, the credit-control client MUST itemize those units in a third=20 category.

If a = client does not=20 support the tariff change mechanism, and it receives a CCA message = carrying=20 the Tariff-Time-Change AVP, it MUST terminate the credit control = session,=20 giving a reason of DIAMETER_BAD_ANSWER in the Termination-Cause=20 AVP.


Regards,

John. =







<marco.stura@nokia.com>=20

01/03/2004 16:25 =

        =
        To: =    =20    <John.Prudhoe@vodafone.com>
        cc: =    =20    <aaa-wg@merit.edu>
        Subject:     =  =20  RE: [AAA-WG]: DCC: Issue: Client Support of Tariff Change=20 Mechanism



Hi John,

the tariff-time-change mechanism consists of = a server=20 instructing the client when the tariff change will occurs and
of a = client=20 reporting units used before and after tariff change.

in section = 8.20 it=20 is specified that

  If a client does not support the = tariff time=20 change mechanism it MUST
  treat Tariff-Time-Change AVP in = the answer=20 message as an incorrect
  CCA answer. In that case the client = terminates the credit control
  session and indicate in the=20 Termination-Cause AVP reason
  DIAMETER_BAD_ANSWER. =

Then, if=20 the client accept the Tariff-Time-Change AVP it is because it supports = the=20 itemising of
usage using the Tariff-Change-Usage AVP.

You=20 wrote:

>If the client does not support the itemisation of = tariff=20 change usage, when the Tariff-Time-Change AVP was present in the=20 >
>previous answer, this AVP MUST be omitted. =

According to=20 section 8.20, this case shouldn't happen.
The SHOULD keyword was = used=20 because it is not sure whether the tariff change will occur during the = reporting
period. Perhaps the sentence in 5.1 should be rephrased = so that=20 "when a tariff change occurs during the
reporting period the client = MUST=20 itemize..."?

Regards
Marco

-----Original=20 Message-----
From: owner-aaa-wg@merit.edu = [mailto:owner-aaa-wg@merit.edu]On=20 Behalf Of ext John.Prudhoe@vodafone.com
Sent: 01 March, 2004 = 17:53
To:=20 aaa-wg@merit.edu
Subject: [AAA-WG]: DCC: Issue: Client Support of = Tariff=20 Change Mechanism



Description of issue:  Client = Support of=20 Tariff Change Mechanism
Submitter name:  John Prudhoe
Date = first=20 submitted: 1.03.2004
Reference:
Document:=20 draft-ietf-aaa-diameter-cc-03.txt
Comment type: E
Priority:=20
Section: 8.27

Rationale/Explanation of issues:

In = section=20 5.1 it is only specified that the client SHOULD support the tariff = change=20 mechanism and the itemising of usage using the Tariff-Change-Usage = AVP.=20

I believe the last sentence of section 8.27 = (Tariff-Change-Usage AVP)=20 is meant to support this, but it is not clear.

My suggested = change is=20 in section 8.27:

FROM

Omission of this AVP means that = no=20 tariff change has been occurred.

TO

If the client does = not=20 support the itemisation of tariff change usage, when the = Tariff-Time-Change=20 AVP was present in the previous answer, this AVP MUST be omitted.=20


Regards,

John.=20 =

















<= BR>
In=20 the last paragraph of 5.1 (p16 of cc-03)


change SHOULD to=20 = MUST

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

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

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


------_=_NextPart_001_01C40062.312DA42A-- From owner-aaa-wg@merit.edu Tue Mar 2 10:03:15 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 KAA12750 for ; Tue, 2 Mar 2004 10:03:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AC5129128D; Tue, 2 Mar 2004 10:03:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7BE429128E; Tue, 2 Mar 2004 10:03:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED32A9128D for ; Tue, 2 Mar 2004 10:02:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C1695E14A; Tue, 2 Mar 2004 10:02:56 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from hrtades9.atea.be (viap100.atea.be [194.78.143.100]) by segue.merit.edu (Postfix) with ESMTP id AD5FD5E7CC for ; Tue, 2 Mar 2004 10:02:54 -0500 (EST) Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id D5YYFPB4; Tue, 2 Mar 2004 16:02:53 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Mar 2004 16:02:53 +0100 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195692067@hrtades7.atea.be> From: Goeman Stefan To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: An error in RFC 3588 Date: Tue, 2 Mar 2004 16:02:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40067.6CE49E10" 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_01C40067.6CE49E10 Content-Type: text/plain; charset="iso-8859-1" Hello All, I believe there is an error in the Diameter Base Protocol RFC. I refer to Figure 6 in section 6.1.8 Relaying and Proxying Requests. First of all, there is a small typo with the mno.net and example.net things, but this is not the real problem I have. The text in section 6.1.8 says that "A relay of proxy agent MUST append a Route-Record AVP to all requests forwarded. The AVP contains the identity of the peer the request was received from." This is reflected in Figure 6. In Figure 6, (Origin-Host=nas.mno.net) and (Route-Record=nas.mno.net) (Remember my first remark on the typo). However, when I read the text in section 6.7.1 Route-Record AVP, I read "The Route-Record AVP is of type DiameterIdentity. The identity added in this AVP MUST be the same as the one received in the Origin-Host of the Capabilities Exchange message". Applying this to Figure 6, I assume that the CE message are between DRL and HMS. In these messages Origin-Host would be the identity of DRL. So, I think that in Figure 6 it should be (Origin-Host=nas.mno.net) and (Route-Record=drl.mno.net). Greetings, Stefan. Stefan Goeman SIEMENS ICM/ICN Stefan.Goeman@siemens.com phone: +32 14 253020 mobile: Fax: +32 14 22 29 94 Mobile Solutions and Enabling Services http://www.ic.siemens.be Customer driven solution providers ------_=_NextPart_001_01C40067.6CE49E10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable An error in RFC 3588

Hello All,

I believe there is an error in the = Diameter Base Protocol RFC. I refer to Figure 6 in section 6.1.8 = Relaying and Proxying Requests.

First of all, there is a small typo = with the mno.net and example.net things, but this is not the real = problem I have.

The text in section 6.1.8 says that = "A relay of proxy agent MUST append a Route-Record AVP to all = requests forwarded. The AVP contains the identity of the peer the = request was received from." This is reflected in Figure 6. In = Figure 6, (Origin-Host=3Dnas.mno.net) and (Route-Record=3Dnas.mno.net) = (Remember my first remark on the typo).

However, when I read the text in = section 6.7.1 Route-Record AVP, I read "The Route-Record AVP is of = type DiameterIdentity. The identity added in this AVP MUST be the same = as the one received in the Origin-Host of the Capabilities Exchange = message". Applying this to Figure 6, I assume that the CE message = are between DRL and HMS. In these messages Origin-Host would be the = identity of DRL. So, I think that in Figure 6 it should be = (Origin-Host=3Dnas.mno.net) and = (Route-Record=3Ddrl.mno.net).


Greetings,
Stefan.

Stefan = Goeman
SIEMENS ICM/ICN
Stefan.Goeman@siemens.com
phone:=A0=A0 +32 14 253020
mobile:=A0
Fax:=A0=A0=A0=A0=A0=A0 +32 14 22 29 94
       
Mobile Solutions=A0
and Enabling Services
http://www.ic.siemens.be        = =A0      
Customer driven solution providers =     

------_=_NextPart_001_01C40067.6CE49E10-- From owner-aaa-wg@merit.edu Tue Mar 2 11:48: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 LAA18699 for ; Tue, 2 Mar 2004 11:48:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA2A991296; Tue, 2 Mar 2004 11:44:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 903A291297; Tue, 2 Mar 2004 11:44:08 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4DFF391296 for ; Tue, 2 Mar 2004 11:44:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3808C5E88F; Tue, 2 Mar 2004 11:44:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailsweep01.vodafone.ie (unknown [213.233.159.70]) by segue.merit.edu (Postfix) with ESMTP id 08A015E890 for ; Tue, 2 Mar 2004 11:44:00 -0500 (EST) Received: from eircellnotes5.eircell.ie (unverified) by mailsweep01.vodafone.ie (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Tue, 2 Mar 2004 16:48:30 +0000 To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC: Issue: Editorial Section 8.43 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John.Prudhoe@vodafone.com Date: Tue, 2 Mar 2004 16:43:52 +0000 X-MIMETrack: Serialize by Router on Notes5/Vodafone(Release 5.0.10 |March 22, 2002) at 03/02/2004 04:43:53 PM, Serialize complete at 03/02/2004 04:43:53 PM Content-Type: multipart/alternative; boundary="=_alternative 005BE54480256E4B_=" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005BE54480256E4B_= Content-Type: text/plain; charset="us-ascii" Description of issue: Client Support of Tariff Change Mechanism Submitter name: John Prudhoe Date first submitted: 2.03.2004 Reference: Document: draft-ietf-aaa-diameter-cc-03.txt Comment type: E Priority: Section: 5.1 Rationale/Explanation of issues: There is a minor issue in section 8.43, Service-Parameter-Type AVP. The last sentence is not clear. The following proposed change is based upon the presumed meaning of the last sentence. Change the last sentence of 8.43 FROM The Service-Parameter-Value AVP contains the service parameter type. TO The Service-Parameter-Value AVP contains the value associated with the service parameter type. Regards, John. ****************************************************************************** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination, disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages of this kind. The opinions, conclusions and other information in this message are of the author and shall be understood as neither given nor endorsed by Vodafone Ireland Limited unless it is otherwise indicated by an authorised representative independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone Ireland Limited has no control. As such, there is no guarantee that (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender (iii) this e-mail has not been intercepted by a third party (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this message (including its attachments) has been processed by an automated anti-virus system; however it is the responsibility of the recipient to ensure that the message (and attachments) are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18. Number 326967 VAT Reg No. IE6346967G ****************************************************************************** --=_alternative 005BE54480256E4B_= Content-Type: text/html; charset="us-ascii"

Description of issue:  Client Support of Tariff Change Mechanism
Submitter name:  John Prudhoe
Date first submitted: 2.03.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-03.txt
Comment type: E
Priority:
Section: 5.1

Rationale/Explanation of issues:

There is a minor issue in section 8.43, Service-Parameter-Type AVP.  The last sentence is not clear.  The following proposed change is based upon the presumed meaning of the last sentence.

Change the last sentence of 8.43

FROM

The Service-Parameter-Value AVP contains the service parameter type.

TO

The Service-Parameter-Value AVP contains the value associated with the service parameter type.


Regards,

John.

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

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

******************************************************************************
 --=_alternative 005BE54480256E4B_=-- From aaa-admin@ietf.org Tue Mar 2 19:51:53 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 TAA14709 for ; Tue, 2 Mar 2004 19:51:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKbH-0004Ze-6b; Tue, 02 Mar 2004 19:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKbA-0004Yr-IG for aaa@optimus.ietf.org; Tue, 02 Mar 2004 19:50:56 -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 TAA14590 for ; Tue, 2 Mar 2004 19:50:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyKb8-0000B3-00 for aaa@ietf.org; Tue, 02 Mar 2004 19:50:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyKaC-0007mE-00 for aaa@ietf.org; Tue, 02 Mar 2004 19:49:56 -0500 Received: from [218.88.130.51] (helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AyKZF-0007cF-00 for aaa@ietf.org; Tue, 02 Mar 2004 19:48:58 -0500 From: "tiny_world@hotmail.com" To: aaa@ietf.org Content-Type: text/html;charset="GB2312" Reply-To: tiny_world@hotmail.com Date: Wed, 3 Mar 2004 08:40:00 +0800 X-Priority: 3 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 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=16.9 required=5.0 tests=ACT_NOW_CAPS,CLICK_BELOW, FORGED_HOTMAIL_RCVD,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML, FORGED_OUTLOOK_TAGS,HTML_30_40,HTML_LINK_CLICK_HERE,HTML_MESSAGE, HTML_MIME_NO_HTML_TAG,MIME_HEADER_CTYPE_ONLY,MIME_HTML_ONLY, MSGID_FROM_MTA_SHORT,PENIS_ENLARGE,SUB_HELLO autolearn=no version=2.60 X-Spam-Report: * 2.7 SUB_HELLO Subject starts with "Hello" * 1.3 ACT_NOW_CAPS BODY: Talks about 'acting now' with capitals * 1.1 PENIS_ENLARGE BODY: Information on getting larger penis/breasts * 0.1 HTML_LINK_CLICK_HERE BODY: HTML link text says "click here" * 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.0 FORGED_HOTMAIL_RCVD Forged hotmail.com 'Received:' header found * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.9 MIME_HEADER_CTYPE_ONLY 'Content-Type' found without required MIME headers * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.7 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 0.0 CLICK_BELOW Asks you to click below * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Subject: [Aaa] 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: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: ,

  MALE ENHANCEMENT -- Guaranteed Results! Doctor-approved Vigarex is
GUARANTEED to work or your money back! Gain 1-3 inches. Get Firmer, Longer
Erections, Increased Semen Production, More Intense Orgasms. TurboCharge your
S e x  drive. ACT NOW! and get a bigger penis! Click Here for more information

  Weight Control

  Breast Augmentation


============================================================================
     ADV: You are receiving this publicity either because you or someone that
  you know subscribed you to our mailing list. If this was sent in error, we
  deeply apologize.
     Click Here to stop receiving this email, or write tiny_world@hotmail.com 

=============================================================================

_______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Tue Mar 2 19:52:46 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 TAA14797 for ; Tue, 2 Mar 2004 19:52:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKcT-0004mP-SP for aaa-archive@odin.ietf.org; Tue, 02 Mar 2004 19:52:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i230qHHW018372 for aaa-archive@odin.ietf.org; Tue, 2 Mar 2004 19:52:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKcT-0004mF-Ov for aaa-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 19:52:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14773 for ; Tue, 2 Mar 2004 19:52:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyKcR-0000R9-00 for aaa-web-archive@ietf.org; Tue, 02 Mar 2004 19:52:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyKbb-0000EZ-00 for aaa-web-archive@ietf.org; Tue, 02 Mar 2004 19:51:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKbH-0004Ze-6b; Tue, 02 Mar 2004 19:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKbA-0004Yr-IG for aaa@optimus.ietf.org; Tue, 02 Mar 2004 19:50:56 -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 TAA14590 for ; Tue, 2 Mar 2004 19:50:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyKb8-0000B3-00 for aaa@ietf.org; Tue, 02 Mar 2004 19:50:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyKaC-0007mE-00 for aaa@ietf.org; Tue, 02 Mar 2004 19:49:56 -0500 Received: from [218.88.130.51] (helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AyKZF-0007cF-00 for aaa@ietf.org; Tue, 02 Mar 2004 19:48:58 -0500 From: "tiny_world@hotmail.com" To: aaa@ietf.org Content-Type: text/html;charset="GB2312" Reply-To: tiny_world@hotmail.com Date: Wed, 3 Mar 2004 08:40:00 +0800 X-Priority: 3 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 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=16.9 required=5.0 tests=ACT_NOW_CAPS,CLICK_BELOW, FORGED_HOTMAIL_RCVD,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML, FORGED_OUTLOOK_TAGS,HTML_30_40,HTML_LINK_CLICK_HERE,HTML_MESSAGE, HTML_MIME_NO_HTML_TAG,MIME_HEADER_CTYPE_ONLY,MIME_HTML_ONLY, MSGID_FROM_MTA_SHORT,PENIS_ENLARGE,SUB_HELLO autolearn=no version=2.60 X-Spam-Report: * 2.7 SUB_HELLO Subject starts with "Hello" * 1.3 ACT_NOW_CAPS BODY: Talks about 'acting now' with capitals * 1.1 PENIS_ENLARGE BODY: Information on getting larger penis/breasts * 0.1 HTML_LINK_CLICK_HERE BODY: HTML link text says "click here" * 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.0 FORGED_HOTMAIL_RCVD Forged hotmail.com 'Received:' header found * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.9 MIME_HEADER_CTYPE_ONLY 'Content-Type' found without required MIME headers * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.7 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 0.0 CLICK_BELOW Asks you to click below * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Subject: [Aaa] 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: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: ,

  MALE ENHANCEMENT -- Guaranteed Results! Doctor-approved Vigarex is
GUARANTEED to work or your money back! Gain 1-3 inches. Get Firmer, Longer
Erections, Increased Semen Production, More Intense Orgasms. TurboCharge your
S e x  drive. ACT NOW! and get a bigger penis! Click Here for more information

  Weight Control

  Breast Augmentation


============================================================================
     ADV: You are receiving this publicity either because you or someone that
  you know subscribed you to our mailing list. If this was sent in error, we
  deeply apologize.
     Click Here to stop receiving this email, or write tiny_world@hotmail.com 

=============================================================================

_______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Tue Mar 2 22: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 WAA25211 for ; Tue, 2 Mar 2004 22:18:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 34966912DD; Tue, 2 Mar 2004 22:16:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4BEFA912CE; Tue, 2 Mar 2004 22:16:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C36F1912E6 for ; Tue, 2 Mar 2004 22:14:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id AFD1E5EB53; Tue, 2 Mar 2004 22:14:52 -0500 (EST) 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 A208B5EB50 for ; Tue, 2 Mar 2004 22:14:51 -0500 (EST) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i233EkS01129; Wed, 3 Mar 2004 05:14:46 +0200 (EET) X-Scanned: Wed, 3 Mar 2004 05:14:26 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i233EQUf027087; Wed, 3 Mar 2004 05:14:26 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00f1FpA1; Wed, 03 Mar 2004 05:14:25 EET 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 i233EPO18102; Wed, 3 Mar 2004 05:14:25 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Mar 2004 05:14:25 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C400CD.A0FDC934" Subject: RE: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism Date: Wed, 3 Mar 2004 05:14:24 +0200 Message-ID: Thread-Topic: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism thread-index: AcQAXGF2bLuDkzqcRUSkPurIh+bEUwAcTNDw From: To: , Cc: X-OriginalArrivalTime: 03 Mar 2004 03:14:25.0477 (UTC) FILETIME=[A1B90750:01C400CD] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C400CD.A0FDC934 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi John, =20 Thanks, I've updated the issue in the issue tracker. =20 thanks, John -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext John.Prudhoe@vodafone.com Sent: 02 March, 2004 15:42 To: Stura Marco (Nokia-NET/Helsinki) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Client Support of Tariff Change = Mechanism Hi Marco,=20 Here is an updated version of the issue.=20 Description of issue: Client Support of Tariff Change Mechanism Submitter name: John Prudhoe Date first submitted: 1.03.2004=20 Reference: 27 Document: draft-ietf-aaa-diameter-cc-03.txt=20 Comment type: T Priority:=20 Section: 5.1 Rationale/Explanation of issues:=20 The Diameter credit-control client must support the Tariff-Time-Change = AVP if sent by the server, but this is not reflected in the wording of = section 5.1.=20 Proposed change:=20 FROM=20 When the Diameter credit-control client reports the used units and a = tariff change has occurred during the reporting period then the Diameter = credit-control client SHOULD itemize the units used before and after the = tariff change. In case some units straddle the tariff change, the = credit-control client SHOULD itemize those units as well.=20 TO=20 When the Diameter credit-control client reports the used units and a = tariff change has occurred during the reporting period then the Diameter = credit-control client MUST separately itemize the units used before and = after the tariff change. In case the client is unable to distinguish = whether units that straddle the tariff change are used before or after = the tariff change, the credit-control client MUST itemize those units in = a third category.=20 If a client does not support the tariff change mechanism, and it = receives a CCA message carrying the Tariff-Time-Change AVP, it MUST = terminate the credit control session, giving a reason of = DIAMETER_BAD_ANSWER in the Termination-Cause AVP. Regards,=20 John.=20 =20 01/03/2004 16:25=20 =20 To: =20 cc: =20 Subject: RE: [AAA-WG]: DCC: Issue: Client Support of = Tariff Change Mechanism Hi John, the tariff-time-change mechanism consists of a server instructing the = client when the tariff change will occurs and of a client reporting units used before and after tariff change. in section 8.20 it is specified that=20 If a client does not support the tariff time change mechanism it MUST=20 treat Tariff-Time-Change AVP in the answer message as an incorrect=20 CCA answer. In that case the client terminates the credit control=20 session and indicate in the Termination-Cause AVP reason=20 DIAMETER_BAD_ANSWER.=20 Then, if the client accept the Tariff-Time-Change AVP it is because it = supports the itemising of usage using the Tariff-Change-Usage AVP. You wrote: >If the client does not support the itemisation of tariff change usage, = when the Tariff-Time-Change AVP was present in the > >previous answer, this AVP MUST be omitted.=20 According to section 8.20, this case shouldn't happen. The SHOULD keyword was used because it is not sure whether the tariff = change will occur during the reporting period. Perhaps the sentence in 5.1 should be rephrased so that "when a = tariff change occurs during the reporting period the client MUST itemize..."? Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext John.Prudhoe@vodafone.com Sent: 01 March, 2004 17:53 To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC: Issue: Client Support of Tariff Change Mechanism Description of issue: Client Support of Tariff Change Mechanism Submitter name: John Prudhoe Date first submitted: 1.03.2004=20 Reference:=20 Document: draft-ietf-aaa-diameter-cc-03.txt=20 Comment type: E Priority:=20 Section: 8.27 Rationale/Explanation of issues:=20 In section 5.1 it is only specified that the client SHOULD support the = tariff change mechanism and the itemising of usage using the = Tariff-Change-Usage AVP.=20 I believe the last sentence of section 8.27 (Tariff-Change-Usage AVP) is = meant to support this, but it is not clear.=20 My suggested change is in section 8.27:=20 FROM=20 Omission of this AVP means that no tariff change has been occurred.=20 TO=20 If the client does not support the itemisation of tariff change usage, = when the Tariff-Time-Change AVP was present in the previous answer, this = AVP MUST be omitted.=20 Regards,=20 John.=20 In the last paragraph of 5.1 (p16 of cc-03)=20 change SHOULD to MUST *************************************************************************= ***** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message=20 (or responsible for delivery of the message to such person),=20 you may not copy or deliver this message to anyone. In such=20 case, you should destroy this message and kindly notify the=20 sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination,=20 disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited=20 and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages=20 of this kind. The opinions, conclusions and other information=20 in this message are of the author and shall be understood as=20 neither given nor endorsed by Vodafone Ireland Limited=20 unless it is otherwise indicated by an authorised representative=20 independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone=20 Ireland Limited has no control. As such, there is no guarantee that=20 (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender=20 (iii) this e-mail has not been intercepted by a third party=20 (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this=20 message (including its attachments) has been processed by an=20 automated anti-virus system; however it is the responsibility of=20 the recipient to ensure that the message (and attachments)=20 are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK),=20 Pauline Best (UK), Paul Donovan Chief Executive (UK),=20 Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18.=20 Number 326967 VAT Reg No. IE6346967G *************************************************************************= ***** ------_=_NextPart_001_01C400CD.A0FDC934 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 John,
 
Thanks, I've updated the issue in the issue = tracker.
 
thanks,
John
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext=20 John.Prudhoe@vodafone.com
Sent: 02 March, 2004 = 15:42
To:=20 Stura Marco (Nokia-NET/Helsinki)
Cc:=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: Issue: Client = Support=20 of Tariff Change Mechanism


Hi=20 Marco,

Here is an updated = version of=20 the issue.


Description of=20 issue:  Client Support of Tariff Change Mechanism
Submitter = name:=20  John Prudhoe
Date first submitted: 1.03.2004
Reference:=20 27
Document: draft-ietf-aaa-diameter-cc-03.txt
Comment type:=20 T
Priority:
Section: 5.1

Rationale/Explanation of = issues:=20

The Diameter = credit-control=20 client must support the Tariff-Time-Change AVP if sent by the server, = but this=20 is not reflected in the wording of section 5.1.

Proposed change:

FROM

When the Diameter credit-control client reports the used = units and a=20 tariff change has occurred during the reporting period then the = Diameter=20 credit-control client SHOULD itemize the units used before and after = the=20 tariff change.  In case some units straddle the tariff change, = the=20 credit-control client SHOULD itemize those units as well. =

TO

When the Diameter credit-control client reports the used = units and a=20 tariff change has occurred during the reporting period then the = Diameter=20 credit-control client MUST separately itemize the units used before = and after=20 the tariff change.  In case the client is unable to distinguish = whether=20 units that straddle the tariff change are used before or after the = tariff=20 change, the credit-control client MUST itemize those units in a third=20 category.

If a = client does not=20 support the tariff change mechanism, and it receives a CCA message = carrying=20 the Tariff-Time-Change AVP, it MUST terminate the credit control = session,=20 giving a reason of DIAMETER_BAD_ANSWER in the Termination-Cause=20 AVP.


Regards,

John. =







<marco.stura@nokia.com>=20

01/03/2004 16:25 =

        =
        To: =    =20    <John.Prudhoe@vodafone.com>
        cc: =    =20    <aaa-wg@merit.edu>
        Subject:     =  =20  RE: [AAA-WG]: DCC: Issue: Client Support of Tariff Change=20 Mechanism



Hi John,

the tariff-time-change mechanism consists of = a server=20 instructing the client when the tariff change will occurs and
of a = client=20 reporting units used before and after tariff change.

in section = 8.20 it=20 is specified that

  If a client does not support the = tariff time=20 change mechanism it MUST
  treat Tariff-Time-Change AVP in = the answer=20 message as an incorrect
  CCA answer. In that case the client = terminates the credit control
  session and indicate in the=20 Termination-Cause AVP reason
  DIAMETER_BAD_ANSWER. =

Then, if=20 the client accept the Tariff-Time-Change AVP it is because it supports = the=20 itemising of
usage using the Tariff-Change-Usage AVP.

You=20 wrote:

>If the client does not support the itemisation of = tariff=20 change usage, when the Tariff-Time-Change AVP was present in the=20 >
>previous answer, this AVP MUST be omitted. =

According to=20 section 8.20, this case shouldn't happen.
The SHOULD keyword was = used=20 because it is not sure whether the tariff change will occur during the = reporting
period. Perhaps the sentence in 5.1 should be rephrased = so that=20 "when a tariff change occurs during the
reporting period the client = MUST=20 itemize..."?

Regards
Marco

-----Original=20 Message-----
From: owner-aaa-wg@merit.edu = [mailto:owner-aaa-wg@merit.edu]On=20 Behalf Of ext John.Prudhoe@vodafone.com
Sent: 01 March, 2004 = 17:53
To:=20 aaa-wg@merit.edu
Subject: [AAA-WG]: DCC: Issue: Client Support of = Tariff=20 Change Mechanism



Description of issue:  Client = Support of=20 Tariff Change Mechanism
Submitter name:  John Prudhoe
Date = first=20 submitted: 1.03.2004
Reference:
Document:=20 draft-ietf-aaa-diameter-cc-03.txt
Comment type: E
Priority:=20
Section: 8.27

Rationale/Explanation of issues:

In = section=20 5.1 it is only specified that the client SHOULD support the tariff = change=20 mechanism and the itemising of usage using the Tariff-Change-Usage = AVP.=20

I believe the last sentence of section 8.27 = (Tariff-Change-Usage AVP)=20 is meant to support this, but it is not clear.

My suggested = change is=20 in section 8.27:

FROM

Omission of this AVP means that = no=20 tariff change has been occurred.

TO

If the client does = not=20 support the itemisation of tariff change usage, when the = Tariff-Time-Change=20 AVP was present in the previous answer, this AVP MUST be omitted.=20


Regards,

John.=20 =

















<= BR>
In=20 the last paragraph of 5.1 (p16 of cc-03)


change SHOULD to=20 = MUST

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

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

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


------_=_NextPart_001_01C400CD.A0FDC934-- From owner-aaa-wg@merit.edu Tue Mar 2 22:19: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 WAA25269 for ; Tue, 2 Mar 2004 22:19:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2FA1E912CE; Tue, 2 Mar 2004 22:16:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF4AF912E6; Tue, 2 Mar 2004 22:16:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 52EB6912D1 for ; Tue, 2 Mar 2004 22:12:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3FD465EB3C; Tue, 2 Mar 2004 22:12:22 -0500 (EST) 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 7B35B5EAF7 for ; Tue, 2 Mar 2004 22:12:21 -0500 (EST) 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 i233CGh05153; Wed, 3 Mar 2004 05:12:16 +0200 (EET) X-Scanned: Wed, 3 Mar 2004 05:12:04 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i233C416021126; Wed, 3 Mar 2004 05:12:04 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 0088KefP; Wed, 03 Mar 2004 05:12:02 EET 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 i233Bv711818; Wed, 3 Mar 2004 05:11:57 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Mar 2004 05:11:57 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C400CD.48AA4E70" Subject: RE: [AAA-WG]: DCC: Issue: Editorial Section 8.43 Date: Wed, 3 Mar 2004 05:11:56 +0200 Message-ID: Thread-Topic: [AAA-WG]: DCC: Issue: Editorial Section 8.43 thread-index: AcQAdmWrohxeJUPLQKK4zRqNVidQEQAVtuBA From: To: , X-OriginalArrivalTime: 03 Mar 2004 03:11:57.0359 (UTC) FILETIME=[497003F0:01C400CD] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C400CD.48AA4E70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Assigned Issue 28. =20 Thanks, John -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext John.Prudhoe@vodafone.com Sent: 02 March, 2004 18:44 To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC: Issue: Editorial Section 8.43 Description of issue: Client Support of Tariff Change Mechanism Submitter name: John Prudhoe Date first submitted: 2.03.2004=20 Reference:=20 Document: draft-ietf-aaa-diameter-cc-03.txt=20 Comment type: E Priority:=20 Section: 5.1 Rationale/Explanation of issues:=20 There is a minor issue in section 8.43, Service-Parameter-Type AVP. The = last sentence is not clear. The following proposed change is based upon = the presumed meaning of the last sentence.=20 Change the last sentence of 8.43=20 FROM=20 The Service-Parameter-Value AVP contains the service parameter type.=20 TO=20 The Service-Parameter-Value AVP contains the value associated with the = service parameter type.=20 Regards,=20 John. *************************************************************************= ***** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message=20 (or responsible for delivery of the message to such person),=20 you may not copy or deliver this message to anyone. In such=20 case, you should destroy this message and kindly notify the=20 sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination,=20 disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited=20 and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages=20 of this kind. The opinions, conclusions and other information=20 in this message are of the author and shall be understood as=20 neither given nor endorsed by Vodafone Ireland Limited=20 unless it is otherwise indicated by an authorised representative=20 independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone=20 Ireland Limited has no control. As such, there is no guarantee that=20 (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender=20 (iii) this e-mail has not been intercepted by a third party=20 (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this=20 message (including its attachments) has been processed by an=20 automated anti-virus system; however it is the responsibility of=20 the recipient to ensure that the message (and attachments)=20 are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK),=20 Pauline Best (UK), Paul Donovan Chief Executive (UK),=20 Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18.=20 Number 326967 VAT Reg No. IE6346967G *************************************************************************= ***** ------_=_NextPart_001_01C400CD.48AA4E70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Assigned Issue 28.
 
Thanks,
John
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext=20 John.Prudhoe@vodafone.com
Sent: 02 March, 2004 = 18:44
To:=20 aaa-wg@merit.edu
Subject: [AAA-WG]: DCC: Issue: Editorial = Section=20 8.43



Description=20 of issue:  Client Support of Tariff Change Mechanism
Submitter = name:=20  John Prudhoe
Date first submitted: 2.03.2004
Reference:=20
Document: draft-ietf-aaa-diameter-cc-03.txt
Comment type:=20 E
Priority:
Section: 5.1

Rationale/Explanation of = issues:=20

There is a minor = issue in=20 section 8.43, Service-Parameter-Type AVP.  The last sentence is = not=20 clear.  The following proposed change is based upon the presumed = meaning=20 of the last sentence.

Change=20 the last sentence of 8.43

FROM

The=20 Service-Parameter-Value AVP contains the service parameter = type.=20

TO

The Service-Parameter-Value AVP contains = the value=20 associated with the service parameter type.


Regards,

John.

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

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

*******************************************************= ***********************
 ------_=_NextPart_001_01C400CD.48AA4E70-- From owner-aaa-wg@merit.edu Wed Mar 3 01:58: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 BAA07132 for ; Wed, 3 Mar 2004 01:58:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F116591214; Wed, 3 Mar 2004 01:57:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BCECB9122D; Wed, 3 Mar 2004 01:57:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9E64891214 for ; Wed, 3 Mar 2004 01:57:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B9EB5DE6C; Wed, 3 Mar 2004 01:57:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id C11B45DE60 for ; Wed, 3 Mar 2004 01:57:52 -0500 (EST) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i236vhZ13298; Wed, 3 Mar 2004 08:57:43 +0200 (EET) X-Scanned: Wed, 3 Mar 2004 08:55:50 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i236to4d020909; Wed, 3 Mar 2004 08:55:50 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00Y3xrGv; Wed, 03 Mar 2004 08:55:49 EET 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 i236tm715679; Wed, 3 Mar 2004 08:55:48 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Mar 2004 08:55:45 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Mar 2004 08:55:44 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: AAA URI syntax Date: Wed, 3 Mar 2004 08:55:43 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612238F@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: AAA URI syntax thread-index: AcQAJK1Lp/7ojwd+QEG9hdLJzH32CwAxs4rA From: To: , X-OriginalArrivalTime: 03 Mar 2004 06:55:44.0720 (UTC) FILETIME=[8CC4B500:01C400EC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi,=20 RFC 2396 also says that only some URI schemes use this "generic URI" syntax; each scheme can decide whether it wants to use it or not. If the AAA URI scheme does not use the "generic URI" syntax, we can have whatever we want right of the "aaa:" part... So IMHO the current syntax is OK from this point. BR, Pasi > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Pete McCann > Sent: Tuesday, March 02, 2004 9:00 AM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: AAA URI syntax >=20 >=20 >=20 >=20 > Hi, >=20 > Following up to the point I raised at the meeting today: >=20 > According to my reading of RFC 2396 (Uniform Resource Identifiers > (URI): Generic Syntax), the syntax given for the AAA URI in RFC 3588 > is broken. >=20 > See Appendix A of 2396. Because we are using a //, the thing after > the slash is a "hier_part". In a "hier_part", we have an "authority" > followed by an optional "abs_path". The only way to get a ";" "path"=20 > is to use an "abs_path", and an "abs_path" must begin with a /. In > the examples given in RFC 3588, there is no / before the parameters. >=20 > So, there seem to be two options here. We could remove the // from > our URI syntax, making it into scheme:opaque_part. We can format the > opaque_part however we would like. Alternatively, we could add a / > after the authority name before we add parameters. This would mean: >=20 > aaa://host.example.com/;transport=3Dtcp >=20 > This would be the least amount of change; however, it looks a=20 > little ugly. >=20 > -Pete >=20 > p.s. Thanks to Adam Costello for first noticing this and=20 > pointing it out. >=20 > -Pete >=20 >=20 >=20 >=20 >=20 From owner-aaa-wg@merit.edu Wed Mar 3 06:28: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 GAA19345 for ; Wed, 3 Mar 2004 06:28:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 369AB91241; Wed, 3 Mar 2004 06:27:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0243191243; Wed, 3 Mar 2004 06:27:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C3C2B91241 for ; Wed, 3 Mar 2004 06:27:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id AC13A5E028; Wed, 3 Mar 2004 06:27:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by segue.merit.edu (Postfix) with ESMTP id 416BB5E002 for ; Wed, 3 Mar 2004 06:27:53 -0500 (EST) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i23BRj307141; Wed, 3 Mar 2004 05:27:45 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i23BReq06259; Wed, 3 Mar 2004 05:27:42 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HTZZT4-0001VG-00; Wed, 03 Mar 2004 06:27:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16453.49415.239198.635463@gargle.gargle.HOWL> Date: Wed, 3 Mar 2004 05:27:03 -0600 From: Pete McCann To: Cc: Subject: RE: [AAA-WG]: AAA URI syntax In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A612238F@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A612238F@esebe023.ntc.nokia.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Pasi, Where do you read that in 2396? I see the following text in the abstract: This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. I interpret that to mean that all valid URI must fit the grammar, i.e., the set of all strings defined by the grammar is strictly larger than the set of all valid URI. The URI definition in RFC 3588 does not fit the grammar. Our URI begins with "aaa://", so we are not eligible to parse it as ":". "" cannot begin with a "/" -Pete Pasi.Eronen@nokia.com writes: > Hi, > > RFC 2396 also says that only some URI schemes use this > "generic URI" syntax; each scheme can decide whether > it wants to use it or not. If the AAA URI scheme > does not use the "generic URI" syntax, we can have > whatever we want right of the "aaa:" part... > > So IMHO the current syntax is OK from this point. > > BR, > Pasi > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu > > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > ext Pete McCann > > Sent: Tuesday, March 02, 2004 9:00 AM > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: AAA URI syntax > > > > > > > > > > Hi, > > > > Following up to the point I raised at the meeting today: > > > > According to my reading of RFC 2396 (Uniform Resource Identifiers > > (URI): Generic Syntax), the syntax given for the AAA URI in RFC 3588 > > is broken. > > > > See Appendix A of 2396. Because we are using a //, the thing after > > the slash is a "hier_part". In a "hier_part", we have an "authority" > > followed by an optional "abs_path". The only way to get a ";" "path" > > is to use an "abs_path", and an "abs_path" must begin with a /. In > > the examples given in RFC 3588, there is no / before the parameters. > > > > So, there seem to be two options here. We could remove the // from > > our URI syntax, making it into scheme:opaque_part. We can format the > > opaque_part however we would like. Alternatively, we could add a / > > after the authority name before we add parameters. This would mean: > > > > aaa://host.example.com/;transport=tcp > > > > This would be the least amount of change; however, it looks a > > little ugly. > > > > -Pete > > > > p.s. Thanks to Adam Costello for first noticing this and > > pointing it out. > > > > -Pete From owner-aaa-wg@merit.edu Wed Mar 3 06:45: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 GAA20120 for ; Wed, 3 Mar 2004 06:45:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EDC3791242; Wed, 3 Mar 2004 06:44:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C189891243; Wed, 3 Mar 2004 06:44:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 84BFD91242 for ; Wed, 3 Mar 2004 06:44:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 734585E053; Wed, 3 Mar 2004 06:44:53 -0500 (EST) 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 6C5885E05A for ; Wed, 3 Mar 2004 06:44:52 -0500 (EST) Received: from nokia.com (esnira-pool2013221.nokia.com [10.162.13.221]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i23BifS08677; Wed, 3 Mar 2004 13:44:41 +0200 (EET) Message-ID: <4045C527.5000108@nokia.com> Date: Wed, 03 Mar 2004 13:44:39 +0200 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: ext Pete McCann Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: AAA URI syntax References: <052E0C61B69C3741AFA5FE88ACC775A612238F@esebe023.ntc.nokia.com> <16453.49415.239198.635463@gargle.gargle.HOWL> In-Reply-To: <16453.49415.239198.635463@gargle.gargle.HOWL> 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: As I understand from RFC 2396, those URIs that contain the slashes "//" include a path that points to a resource stored in a hierarchical structure, such us a file system. Obvious examples are http and ftp resources. Having said that, I don't believe a AAA URI falls into this category. The other big category of URIs belong to those that do not point to a hierarchical resource. Example of these URIs are SIP and mailto: URIs. I believe the AAA URI belongs to this category. An example of what I believe it should be a correct AAA URI is: aaa:server.example.com I know that my words suggest to do a big change to the AAA URI defined in RFC 3588, but we should make an effort to make things right. /Miguel ext Pete McCann wrote: > > Hi, Pasi, > > Where do you read that in 2396? I see the following text in the > abstract: > > This document defines a grammar that is a superset of all valid URI, > such that an implementation can parse the common components of a URI > reference without knowing the scheme-specific requirements of every > possible identifier type. > > I interpret that to mean that all valid URI must fit the grammar, > i.e., the set of all strings defined by the grammar is strictly larger > than the set of all valid URI. > > The URI definition in RFC 3588 does not fit the grammar. > > Our URI begins with "aaa://", so we are not eligible to parse it as > ":". "" cannot begin with a "/" > > -Pete > > Pasi.Eronen@nokia.com writes: > > Hi, > > > > RFC 2396 also says that only some URI schemes use this > > "generic URI" syntax; each scheme can decide whether > > it wants to use it or not. If the AAA URI scheme > > does not use the "generic URI" syntax, we can have > > whatever we want right of the "aaa:" part... > > > > So IMHO the current syntax is OK from this point. > > > > BR, > > Pasi > > > > > -----Original Message----- > > > From: owner-aaa-wg@merit.edu > > > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > > ext Pete McCann > > > Sent: Tuesday, March 02, 2004 9:00 AM > > > To: aaa-wg@merit.edu > > > Subject: [AAA-WG]: AAA URI syntax > > > > > > > > > > > > > > > Hi, > > > > > > Following up to the point I raised at the meeting today: > > > > > > According to my reading of RFC 2396 (Uniform Resource Identifiers > > > (URI): Generic Syntax), the syntax given for the AAA URI in RFC 3588 > > > is broken. > > > > > > See Appendix A of 2396. Because we are using a //, the thing after > > > the slash is a "hier_part". In a "hier_part", we have an "authority" > > > followed by an optional "abs_path". The only way to get a ";" "path" > > > is to use an "abs_path", and an "abs_path" must begin with a /. In > > > the examples given in RFC 3588, there is no / before the parameters. > > > > > > So, there seem to be two options here. We could remove the // from > > > our URI syntax, making it into scheme:opaque_part. We can format the > > > opaque_part however we would like. Alternatively, we could add a / > > > after the authority name before we add parameters. This would mean: > > > > > > aaa://host.example.com/;transport=tcp > > > > > > This would be the least amount of change; however, it looks a > > > little ugly. > > > > > > -Pete > > > > > > p.s. Thanks to Adam Costello for first noticing this and > > > pointing it out. > > > > > > -Pete > > > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Wed Mar 3 07:14: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 HAA21115 for ; Wed, 3 Mar 2004 07:14:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E20BF91243; Wed, 3 Mar 2004 07:14:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B1CCA91295; Wed, 3 Mar 2004 07:14:13 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 034B391243 for ; Wed, 3 Mar 2004 07:14:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id E69015E072; Wed, 3 Mar 2004 07:14:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.166.48.91]) by segue.merit.edu (Postfix) with ESMTP id 2DC015E068 for ; Wed, 3 Mar 2004 07:14:11 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i23CE2E25660; Wed, 3 Mar 2004 12:14:02 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1W6WN92T>; Wed, 3 Mar 2004 12:14:03 -0000 Message-ID: <588B15E2E2B1D41180B800508BF934F20AAC5BBB@bmdhd6.europe.nortel.com> From: "Mark Watson" To: "'marco.stura@nokia.com'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C -C AVP structure Date: Wed, 3 Mar 2004 12:14:01 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40119.032B9BBA" 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_01C40119.032B9BBA Content-Type: text/plain Marco, Just for my understanding, am I right in thinking that, without this, the M-S-C-C AVP cannot be extended with future optional AVPs in a backwards compatible way ? If so, what about all the other Grouped AVPs in the protocol and, for that matter, the commands ? Regards...Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 01 March 2004 12:13 To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure Description of issue: addition of *[AVP] notation in the M-S-C-C AVP structure Submitter name: Marco Stura Date first submitted: 1.03.2004 Reference: Document: draft-ietf-aaa-diameter-cc-03.txt Comment type: T Priority: 1 Section: 8.16 Rationale/Explanation of issues: In order to define a more future proof structure I propose to add the *[AVP] notation to the M-S-C-C AVP structure. According to the Base (section 4.4.1) the Grouped AVP can contain *[AVP]. Requested change: -Section 8.16 ADD the *[ AVP ] notation to the AVP structure Multiple-Services-Credit-Control ::= < AVP Header: 456 > [ Granted-Service-Unit ] [ Requested-Service-Units ] *[ Used-Service-Units ] [ Tariff-Change-Usage ] *[ Service-Identifier ] [ Rating-Group ] *[ G-S-U-Pool-Reference ] [ Validity-Time ] [ Result-Code ] [ Final-Unit-Indication ] *[ AVP ] ------_=_NextPart_001_01C40119.032B9BBA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the = M-S-C-C AVP structure

Marco,

Just for my understanding, am I right in thinking = that, without this, the M-S-C-C AVP cannot be extended with future = optional AVPs in a backwards compatible way ?

If so, what about all the other Grouped AVPs in the = protocol and, for that matter, the commands ?

Regards...Mark

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: 01 March 2004 12:13
To: aaa-wg@merit.edu
Subject: [AAA-WG]: DCC Issue: addition of *[AVP] = notation in the M-S-C-C AVP structure


Description of issue: addition of *[AVP] notation in = the M-S-C-C AVP structure Submitter name:  Marco Stura Date first = submitted: 1.03.2004

Reference:
Document: draft-ietf-aaa-diameter-cc-03.txt
Comment type: T
Priority: 1
Section: 8.16

Rationale/Explanation of issues:

In order to define a more future proof structure I = propose to add the *[AVP] notation to the M-S-C-C AVP structure. = According to the Base (section 4.4.1) the Grouped AVP can contain = *[AVP].

Requested change:

-Section 8.16

ADD the *[ AVP ] notation to the AVP structure


       = Multiple-Services-Credit-Control ::=3D < AVP Header: 456 >  =
          &nb= sp;           &nb= sp;           &nb= sp;         [ = Granted-Service-Unit ]
          &nb= sp;           &nb= sp;           &nb= sp;         [ = Requested-Service-Units ] 
          &nb= sp;           &nb= sp;           &nb= sp;        *[ Used-Service-Units ] =
          &nb= sp;           &nb= sp;           &nb= sp;         [ = Tariff-Change-Usage ] 
          &nb= sp;           &nb= sp;           &nb= sp;        *[ Service-Identifier = ] 
          &nb= sp;           &nb= sp;           &nb= sp;         [ Rating-Group = ] 
          &nb= sp;           &nb= sp;           &nb= sp;        *[ G-S-U-Pool-Reference = ] 
          &nb= sp;           &nb= sp;           &nb= sp;         [ Validity-Time = ] 
          &nb= sp;           &nb= sp;           &nb= sp;         [ Result-Code = ] 
          &nb= sp;           &nb= sp;           &nb= sp;         [ = Final-Unit-Indication ]
          &nb= sp;           &nb= sp;           &nb= sp;        *[ AVP ]

------_=_NextPart_001_01C40119.032B9BBA-- From owner-aaa-wg@merit.edu Wed Mar 3 08:02: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 IAA24099 for ; Wed, 3 Mar 2004 08:02:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A557391295; Wed, 3 Mar 2004 08:00:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 74EB891297; Wed, 3 Mar 2004 08:00:59 -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 ED7B291295 for ; Wed, 3 Mar 2004 08:00:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id E40B35DEFE; Wed, 3 Mar 2004 08:00:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by segue.merit.edu (Postfix) with ESMTP id CEF115DE12 for ; Wed, 3 Mar 2004 08:00:55 -0500 (EST) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i23D0gr14866; Wed, 3 Mar 2004 07:00:43 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i23D0Xq12200; Wed, 3 Mar 2004 07:00:33 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HU043W-0001Q4-00; Wed, 03 Mar 2004 07:59:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16453.54986.942198.437260@gargle.gargle.HOWL> Date: Wed, 3 Mar 2004 06:59:54 -0600 From: Pete McCann To: Miguel Garcia Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: AAA URI syntax In-Reply-To: <4045C527.5000108@nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A612238F@esebe023.ntc.nokia.com> <16453.49415.239198.635463@gargle.gargle.HOWL> <4045C527.5000108@nokia.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit That would at least be legal syntax, but there are advantages to re-using some of the hierarchical URI syntax. See: http://www.w3.org/DesignIssues/ModelConsequences Adding a '/' to the end of our URI before the parameters doesn't seem like a big deal. IMAP URIs seem to work this way; see RFC 2192: 4. IMAP server An IMAP URL referring to an IMAP server has the following form: imap:/// A program interpreting this URL would issue the standard set of commands it uses to present a view of the contents of an IMAP server. This is likely to be semanticly equivalent to one of the following URLs: imap:///;TYPE=LIST imap:///;TYPE=LSUB The program interpreting this URL SHOULD use the LSUB form if it supports mailbox subscriptions. (thanks again to Adam Costello for pointing these references out to me) -Pete Miguel Garcia writes: > Hi: > > As I understand from RFC 2396, those URIs that contain the slashes "//" > include a path that points to a resource stored in a hierarchical > structure, such us a file system. Obvious examples are http and ftp > resources. Having said that, I don't believe a AAA URI falls into this > category. > > The other big category of URIs belong to those that do not point to a > hierarchical resource. Example of these URIs are SIP and mailto: URIs. I > believe the AAA URI belongs to this category. An example of what I > believe it should be a correct AAA URI is: > > aaa:server.example.com > > I know that my words suggest to do a big change to the AAA URI defined > in RFC 3588, but we should make an effort to make things right. > > /Miguel > > ext Pete McCann wrote: > > > > > Hi, Pasi, > > > > Where do you read that in 2396? I see the following text in the > > abstract: > > > > This document defines a grammar that is a superset of all valid URI, > > such that an implementation can parse the common components of a URI > > reference without knowing the scheme-specific requirements of every > > possible identifier type. > > > > I interpret that to mean that all valid URI must fit the grammar, > > i.e., the set of all strings defined by the grammar is strictly larger > > than the set of all valid URI. > > > > The URI definition in RFC 3588 does not fit the grammar. > > > > Our URI begins with "aaa://", so we are not eligible to parse it as > > ":". "" cannot begin with a "/" > > > > -Pete > > > > Pasi.Eronen@nokia.com writes: > > > Hi, > > > > > > RFC 2396 also says that only some URI schemes use this > > > "generic URI" syntax; each scheme can decide whether > > > it wants to use it or not. If the AAA URI scheme > > > does not use the "generic URI" syntax, we can have > > > whatever we want right of the "aaa:" part... > > > > > > So IMHO the current syntax is OK from this point. > > > > > > BR, > > > Pasi > > > > > > > -----Original Message----- > > > > From: owner-aaa-wg@merit.edu > > > > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > > > ext Pete McCann > > > > Sent: Tuesday, March 02, 2004 9:00 AM > > > > To: aaa-wg@merit.edu > > > > Subject: [AAA-WG]: AAA URI syntax > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > Following up to the point I raised at the meeting today: > > > > > > > > According to my reading of RFC 2396 (Uniform Resource Identifiers > > > > (URI): Generic Syntax), the syntax given for the AAA URI in RFC 3588 > > > > is broken. > > > > > > > > See Appendix A of 2396. Because we are using a //, the thing after > > > > the slash is a "hier_part". In a "hier_part", we have an "authority" > > > > followed by an optional "abs_path". The only way to get a ";" "path" > > > > is to use an "abs_path", and an "abs_path" must begin with a /. In > > > > the examples given in RFC 3588, there is no / before the parameters. > > > > > > > > So, there seem to be two options here. We could remove the // from > > > > our URI syntax, making it into scheme:opaque_part. We can format the > > > > opaque_part however we would like. Alternatively, we could add a / > > > > after the authority name before we add parameters. This would mean: > > > > > > > > aaa://host.example.com/;transport=tcp > > > > > > > > This would be the least amount of change; however, it looks a > > > > little ugly. > > > > > > > > -Pete > > > > > > > > p.s. Thanks to Adam Costello for first noticing this and > > > > pointing it out. > > > > > > > > -Pete From aaa-admin@ietf.org Wed Mar 3 08:02:39 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 IAA24151 for ; Wed, 3 Mar 2004 08:02:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyW0g-0001Ua-AH; Wed, 03 Mar 2004 08:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyW0Z-0001UM-EP for aaa@optimus.ietf.org; Wed, 03 Mar 2004 08:01:55 -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 IAA24028 for ; Wed, 3 Mar 2004 08:01:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyW09-0004YP-00 for aaa@ietf.org; Wed, 03 Mar 2004 08:01:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyVz9-0004H9-00 for aaa@ietf.org; Wed, 03 Mar 2004 08:00:28 -0500 Received: from chello080109035132.2.14.vie.surfer.at ([80.109.35.132]) by ietf-mx with smtp (Exim 4.12) id 1AyVxn-0003ub-00 for aaa@ietf.org; Wed, 03 Mar 2004 07:59:04 -0500 Received: from 14.86.93.9 by 80.109.35.132; Wed, 03 Mar 2004 07:02:05 -0600 Message-ID: From: "Christina Whitfield" Reply-To: "Christina Whitfield" To: aaa@ietf.org Date: Wed, 03 Mar 2004 08:07:05 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--1082903619635505" X-Originating-IP: 132.151.6.1 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.9 required=5.0 tests=BIZ_TLD,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNSAFE, HTML_FONT_BIG,HTML_MESSAGE,HTML_WEB_BUGS,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,SUBJ_FREE_CAP,SUBJ_VIAGRA, SUB_FREE_OFFER autolearn=no version=2.60 X-Spam-Report: * 0.5 SUB_FREE_OFFER Subject starts with "Free" * 2.8 SUBJ_VIAGRA Subject includes "viagra" * 0.1 SUBJ_FREE_CAP Subject contains "FREE" in CAPS * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.6 HTML_WEB_BUGS BODY: Image tag intended to identify you * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 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 * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts Subject: [Aaa] FREE "Viagra" PRESCRIPTION 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: , ----1082903619635505 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Low Cost Prescription Medications
SOMA, ULTRAM, ADIPEX, MANY MORE

Prescribed Online And Shipped Overnight To Your Door.

One Of Our US Licensed Physicians Will Write
An FDA Approved Prescription For You
And Ship Your Order Overnight
Via A US Licensed Pharmacy
Direct To Your Doorstep.

FAST AND SECURE !

 YES.....HOOK ME UP!

Zannihilate aldrin pew loop hummingbird covetous timeshare kohlrabi prey concentric dante ding !! Cjejune yon cb fiducial chummy coincident devotee beheld waylay dignify emery hurl outrageous hagen impediment trag angeline yeast chalkline tacitus thyroidal . Sragout curry bankrupt caldera bassett diatribe bub gerhard nat pectoral stupid brant gecko amadeus turquoise anatole andes too buildup smuggle deepen lectern maledict anomalous cheese presuming daybreak enough oaken constrict carruthers balky prerequisite boomerang whup contralateral civet cockatoo amorphous vienna cocoon coach cure congresswoman Ftravail fireman psychosis reconcile argue sixteen opacity annular saccade pooch appetite bonaparte !!! Ycontiguous atavism diocesan dominic spheroidal frontiersmen harpy calvary comanche barbaric menu sprang citrus declamatory decorticate psychophysiology abc coastal . Rwont duration dab upshot ashy barrack buzzsaw orthogona! l scam bludgeon sunshiny accompany tortoise fetus infestation elliptic contact min pembroke meier rhodonite connors diet macabre discernible podge provide question subvert buddhism essential conduct kowloon armistice johnstown storey concertmaster civil voltage ceylon morn hastings dunham delphic leachate infantry critic flaunt rummage aphelion atomic full finial electrocardiogram mile malefactor sceptic tincture ten .Mbelying impulsive baseband rock dying assault frederick tinge aroma slanderous ritchie therefore stile !!! Nparapet bimetallic laborious schloss opine kobayashi regressive blackout covary arrest chameleon tot acme abrupt deallocate bathe clot citizenry streak go booth . Bwaffle duffel pardon woolgather maitre provincial saxophone gaberones travertine exponentiate tend bid magnificent milkweed headmaster hygiene anneal collect perspicacious thieves payne fallen wasp heroes bylaw truth seam anheuser segovia Vdiagnosable fiance cuprous passive donaldson fe prol! ix embody grandstand sepal bring billet attentive . Ofirestone intest inal melodrama chromic rifle disdain heisenberg congress entire danger nagasaki acumen hound carbondale decertify anarch essential burlesque distinguish adsorb psi bergland could handicap materiel ! Mdatabase baritone culminate defy saddle cosmic thrive barnhard byroad dicta rig frankfort downspout metabolite corrodible bookie nicholson applicate compulsive tenor paterson .Jdebar rockies billiken columnar finicky cf . Zinnocuous squirmy autumn purposive emery banjo labyrinth foursome disgustful attrition cony dome drake !! Jchuckle diary md carbohydrate adrian acrylate marigold vagrant bootlegger humanitarian cyclotomic secede anarch stuart plugging angelfish watchword venturi oracular davenport endoderm whirligig doll multifarious craftsman ebullient proverb scrupulosity ambulant buxom xerography coke anybody superior aristocracy feminine yeasty alphabet bootstrapping braun correspond hellish pasadena raceway calibre brutal scherzo dressy Tsiliceous omnipotent ameslan kitt! en brandish friedman ; Rproductivity barberry resident cox cohosh congener . Tencore deanna court articulatory pursue bistable moor englander upheaval carbon arctangent bill chaplain contraband metamorphosis karl prognosticate autonomic desideratum weatherstrip adobe churchyard declaim lipscomb consecutive crotch syrupy medicinal affirmation alizarin adelaide matrimonial drank chicagoan disney houseboat adage schumann Kcushman hobbes expectorant descriptor ortega chile todd mutatis octillion ; Aamalgamate dram discrepant credo acknowledgeable coexist astor czech palmolive spitfire barbaric brewster garfield copywriter disperse patrolled crewcut tin dominique furious phonon ? Qlaurentian judicature demurrer integrity bayonne sincere scuffle nepenthe coxcomb jacobson ohio shade fact deactivate inexplainable deluge crony

If this notice has reached you in error, please notify us by clicking here
----1082903619635505-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Wed Mar 3 08:08: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 IAA24310 for ; Wed, 3 Mar 2004 08:07:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyW5u-0001sw-VS for aaa-archive@odin.ietf.org; Wed, 03 Mar 2004 08:07:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23D7QsX007245 for aaa-archive@odin.ietf.org; Wed, 3 Mar 2004 08:07:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyW5u-0001sm-3M for aaa-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 08:07: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 IAA24285 for ; Wed, 3 Mar 2004 08:06:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyW5K-0005NO-00 for aaa-web-archive@ietf.org; Wed, 03 Mar 2004 08:06:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyW4P-0005Bb-00 for aaa-web-archive@ietf.org; Wed, 03 Mar 2004 08:05:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyW0q-00044K-MH for aaa-web-archive@ietf.org; Wed, 03 Mar 2004 08:02:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyW0g-0001Ua-AH; Wed, 03 Mar 2004 08:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyW0Z-0001UM-EP for aaa@optimus.ietf.org; Wed, 03 Mar 2004 08:01:55 -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 IAA24028 for ; Wed, 3 Mar 2004 08:01:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyW09-0004YP-00 for aaa@ietf.org; Wed, 03 Mar 2004 08:01:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyVz9-0004H9-00 for aaa@ietf.org; Wed, 03 Mar 2004 08:00:28 -0500 Received: from chello080109035132.2.14.vie.surfer.at ([80.109.35.132]) by ietf-mx with smtp (Exim 4.12) id 1AyVxn-0003ub-00 for aaa@ietf.org; Wed, 03 Mar 2004 07:59:04 -0500 Received: from 14.86.93.9 by 80.109.35.132; Wed, 03 Mar 2004 07:02:05 -0600 Message-ID: From: "Christina Whitfield" Reply-To: "Christina Whitfield" To: aaa@ietf.org Date: Wed, 03 Mar 2004 08:07:05 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--1082903619635505" X-Originating-IP: 132.151.6.1 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.9 required=5.0 tests=BIZ_TLD,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNSAFE, HTML_FONT_BIG,HTML_MESSAGE,HTML_WEB_BUGS,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,SUBJ_FREE_CAP,SUBJ_VIAGRA, SUB_FREE_OFFER autolearn=no version=2.60 X-Spam-Report: * 0.5 SUB_FREE_OFFER Subject starts with "Free" * 2.8 SUBJ_VIAGRA Subject includes "viagra" * 0.1 SUBJ_FREE_CAP Subject contains "FREE" in CAPS * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.6 HTML_WEB_BUGS BODY: Image tag intended to identify you * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 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 * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts Subject: [Aaa] FREE "Viagra" PRESCRIPTION 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: , ----1082903619635505 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Low Cost Prescription Medications
SOMA, ULTRAM, ADIPEX, MANY MORE

Prescribed Online And Shipped Overnight To Your Door.

One Of Our US Licensed Physicians Will Write
An FDA Approved Prescription For You
And Ship Your Order Overnight
Via A US Licensed Pharmacy
Direct To Your Doorstep.

FAST AND SECURE !

 YES.....HOOK ME UP!

Zannihilate aldrin pew loop hummingbird covetous timeshare kohlrabi prey concentric dante ding !! Cjejune yon cb fiducial chummy coincident devotee beheld waylay dignify emery hurl outrageous hagen impediment trag angeline yeast chalkline tacitus thyroidal . Sragout curry bankrupt caldera bassett diatribe bub gerhard nat pectoral stupid brant gecko amadeus turquoise anatole andes too buildup smuggle deepen lectern maledict anomalous cheese presuming daybreak enough oaken constrict carruthers balky prerequisite boomerang whup contralateral civet cockatoo amorphous vienna cocoon coach cure congresswoman Ftravail fireman psychosis reconcile argue sixteen opacity annular saccade pooch appetite bonaparte !!! Ycontiguous atavism diocesan dominic spheroidal frontiersmen harpy calvary comanche barbaric menu sprang citrus declamatory decorticate psychophysiology abc coastal . Rwont duration dab upshot ashy barrack buzzsaw orthogona! l scam bludgeon sunshiny accompany tortoise fetus infestation elliptic contact min pembroke meier rhodonite connors diet macabre discernible podge provide question subvert buddhism essential conduct kowloon armistice johnstown storey concertmaster civil voltage ceylon morn hastings dunham delphic leachate infantry critic flaunt rummage aphelion atomic full finial electrocardiogram mile malefactor sceptic tincture ten .Mbelying impulsive baseband rock dying assault frederick tinge aroma slanderous ritchie therefore stile !!! Nparapet bimetallic laborious schloss opine kobayashi regressive blackout covary arrest chameleon tot acme abrupt deallocate bathe clot citizenry streak go booth . Bwaffle duffel pardon woolgather maitre provincial saxophone gaberones travertine exponentiate tend bid magnificent milkweed headmaster hygiene anneal collect perspicacious thieves payne fallen wasp heroes bylaw truth seam anheuser segovia Vdiagnosable fiance cuprous passive donaldson fe prol! ix embody grandstand sepal bring billet attentive . Ofirestone intest inal melodrama chromic rifle disdain heisenberg congress entire danger nagasaki acumen hound carbondale decertify anarch essential burlesque distinguish adsorb psi bergland could handicap materiel ! Mdatabase baritone culminate defy saddle cosmic thrive barnhard byroad dicta rig frankfort downspout metabolite corrodible bookie nicholson applicate compulsive tenor paterson .Jdebar rockies billiken columnar finicky cf . Zinnocuous squirmy autumn purposive emery banjo labyrinth foursome disgustful attrition cony dome drake !! Jchuckle diary md carbohydrate adrian acrylate marigold vagrant bootlegger humanitarian cyclotomic secede anarch stuart plugging angelfish watchword venturi oracular davenport endoderm whirligig doll multifarious craftsman ebullient proverb scrupulosity ambulant buxom xerography coke anybody superior aristocracy feminine yeasty alphabet bootstrapping braun correspond hellish pasadena raceway calibre brutal scherzo dressy Tsiliceous omnipotent ameslan kitt! en brandish friedman ; Rproductivity barberry resident cox cohosh congener . Tencore deanna court articulatory pursue bistable moor englander upheaval carbon arctangent bill chaplain contraband metamorphosis karl prognosticate autonomic desideratum weatherstrip adobe churchyard declaim lipscomb consecutive crotch syrupy medicinal affirmation alizarin adelaide matrimonial drank chicagoan disney houseboat adage schumann Kcushman hobbes expectorant descriptor ortega chile todd mutatis octillion ; Aamalgamate dram discrepant credo acknowledgeable coexist astor czech palmolive spitfire barbaric brewster garfield copywriter disperse patrolled crewcut tin dominique furious phonon ? Qlaurentian judicature demurrer integrity bayonne sincere scuffle nepenthe coxcomb jacobson ohio shade fact deactivate inexplainable deluge crony

If this notice has reached you in error, please notify us by clicking here
----1082903619635505-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Wed Mar 3 08:40: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 IAA26370 for ; Wed, 3 Mar 2004 08:40:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2B1C991299; Wed, 3 Mar 2004 08:40:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E0A5F9129C; Wed, 3 Mar 2004 08:40:28 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 73D5091299 for ; Wed, 3 Mar 2004 08:40:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id B23EC5E0DD; Wed, 3 Mar 2004 08:40:26 -0500 (EST) 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 B7B965DFDA for ; Wed, 3 Mar 2004 08:40:25 -0500 (EST) 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 i23DeOh11978; Wed, 3 Mar 2004 15:40:24 +0200 (EET) X-Scanned: Wed, 3 Mar 2004 15:39:45 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i23DdjHA014031; Wed, 3 Mar 2004 15:39:45 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00nNdIXn; Wed, 03 Mar 2004 15:39:44 EET 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 i23DdiO09243; Wed, 3 Mar 2004 15:39:44 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Mar 2004 15:39:43 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40124.FBE27F9C" Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure Date: Wed, 3 Mar 2004 15:39:42 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B04A6@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure Thread-Index: AcQBGTANGIOzrNofRjuFcHM02+J5mAAAB8Xg From: To: Cc: X-OriginalArrivalTime: 03 Mar 2004 13:39:43.0585 (UTC) FILETIME=[FC41FD10:01C40124] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C40124.FBE27F9C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mark, =20 Just for my understanding, am I right in thinking that, without this, = the M-S-C-C AVP cannot be extended with future optional AVPs in a = backwards compatible way ? =20 If you want the ability to define new optional AVPs in a grouped = structure you do need the *[ AVP ] notation. Since the scope of the = M-S-C-C AVP is to implement a functionality for which we may not see all = the future needs and requirements, it may be necessary to add optional = AVPs in the future. In a way the M-S-C-C can be abstracted as a = *command*, and we don't know what are all the future needs for that = *command*.=20 =20 If so, what about all the other Grouped AVPs in the protocol and, for = that matter, the commands ? =20 The semantic of other grouped AVPs defined in DCC do not require the *[ = AVP ] notation, at least I cannot see any other grouped AVP that would = need this. Note that the CCR/CCA already have *[AVP], you can add AVPs = to the command in the future if you need.=20 =20 Regards Marco ------_=_NextPart_001_01C40124.FBE27F9C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the = M-S-C-C AVP structure
Hi=20 Mark,
 
Just for my = understanding, am I=20 right in thinking that, without this, the M-S-C-C AVP cannot be extended = with=20 future optional AVPs in a backwards compatible way ?
 
If you=20 want the ability to define new optional AVPs in a grouped structure you = do need=20 the *[ AVP ] notation. Since the scope of the M-S-C-C AVP is to = implement=20 a functionality for which we may not see all the future needs = and=20 requirements, it may be necessary to add optional AVPs in the future. In = a way=20 the M-S-C-C can be abstracted as a *command*, and we don't know=20 what are all the future needs for that = *command*. 
 
If so, what about = all the other=20 Grouped AVPs in the protocol and, for that matter, the commands=20 ?
 
The=20 semantic of other grouped AVPs defined in DCC do not require the *[ = AVP ]=20 notation, at least I cannot see any other grouped AVP that would need = this. Note=20 that the CCR/CCA = already have=20 *[AVP],  you can add AVPs to the command in the future if you=20 need. 
 
Regards
Marco
= ------_=_NextPart_001_01C40124.FBE27F9C-- From owner-aaa-wg@merit.edu Wed Mar 3 09:03: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 JAA27661 for ; Wed, 3 Mar 2004 09:03:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 71DE09129B; Wed, 3 Mar 2004 09:02:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 375389129C; Wed, 3 Mar 2004 09:02:47 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C22199129B for ; Wed, 3 Mar 2004 09:02:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id AF3DC5E0E4; Wed, 3 Mar 2004 09:02:45 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.166.48.91]) by segue.merit.edu (Postfix) with ESMTP id 2DDD75E0BC for ; Wed, 3 Mar 2004 09:02:45 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i23E2f624847; Wed, 3 Mar 2004 14:02:41 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1W6W3BH5>; Wed, 3 Mar 2004 14:02:42 -0000 Message-ID: <588B15E2E2B1D41180B800508BF934F20AAC6109@bmdhd6.europe.nortel.com> From: "Mark Watson" To: "'marco.stura@nokia.com'" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C -C AVP structure Date: Wed, 3 Mar 2004 14:02:35 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40128.2DE695E4" 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_01C40128.2DE695E4 Content-Type: text/plain Ok, but what if we want to add new types of resource units to G-S-U and U-S-U ? Straightforward time and octet volume may not be the only way to measure usage in future. If I remember rightly, then the previous draft of DIAMETER credit control, which is unfortunately embedded in 3GPP TS 32.225, defined an enumerated 'Unit-Type AVP' which would have been easy to extend. Switching to explicit AVPs for each unit type is fine, but do we want to lose extensibility here ? Regards, Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 03 March 2004 13:40 To: Watson, Mark [MOP:EP10:EXCH] Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure Hi Mark, Just for my understanding, am I right in thinking that, without this, the M-S-C-C AVP cannot be extended with future optional AVPs in a backwards compatible way ? If you want the ability to define new optional AVPs in a grouped structure you do need the *[ AVP ] notation. Since the scope of the M-S-C-C AVP is to implement a functionality for which we may not see all the future needs and requirements, it may be necessary to add optional AVPs in the future. In a way the M-S-C-C can be abstracted as a *command*, and we don't know what are all the future needs for that *command*. If so, what about all the other Grouped AVPs in the protocol and, for that matter, the commands ? The semantic of other grouped AVPs defined in DCC do not require the *[ AVP ] notation, at least I cannot see any other grouped AVP that would need this. Note that the CCR/CCA already have *[AVP], you can add AVPs to the command in the future if you need. Regards Marco ------_=_NextPart_001_01C40128.2DE695E4 Content-Type: text/html Message
Ok, but what if we want to add new types of resource units to G-S-U and U-S-U ?
 
Straightforward time and octet volume may not be the only way to measure usage in future. If I remember rightly, then the previous draft of DIAMETER credit control, which is unfortunately embedded in 3GPP TS 32.225, defined an enumerated 'Unit-Type AVP' which would have been easy to extend. Switching to explicit AVPs for each unit type is fine, but do we want to lose extensibility here ?

Regards,
 
Mark
 
 
-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: 03 March 2004 13:40
To: Watson, Mark [MOP:EP10:EXCH]
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure

Hi Mark,
 
Just for my understanding, am I right in thinking that, without this, the M-S-C-C AVP cannot be extended with future optional AVPs in a backwards compatible way ?
 
If you want the ability to define new optional AVPs in a grouped structure you do need the *[ AVP ] notation. Since the scope of the M-S-C-C AVP is to implement a functionality for which we may not see all the future needs and requirements, it may be necessary to add optional AVPs in the future. In a way the M-S-C-C can be abstracted as a *command*, and we don't know what are all the future needs for that *command*. 
 
If so, what about all the other Grouped AVPs in the protocol and, for that matter, the commands ?
 
The semantic of other grouped AVPs defined in DCC do not require the *[ AVP ] notation, at least I cannot see any other grouped AVP that would need this. Note that the CCR/CCA already have *[AVP],  you can add AVPs to the command in the future if you need. 
 
Regards
Marco
------_=_NextPart_001_01C40128.2DE695E4-- From owner-aaa-wg@merit.edu Wed Mar 3 09:39: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 JAA00347 for ; Wed, 3 Mar 2004 09:39:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B59919129C; Wed, 3 Mar 2004 09:38:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CF7D9129E; Wed, 3 Mar 2004 09:38:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7DCD79129C for ; Wed, 3 Mar 2004 09:38:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 476C75E146; Wed, 3 Mar 2004 09:38:46 -0500 (EST) 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 7B7BE5E122 for ; Wed, 3 Mar 2004 09:38:45 -0500 (EST) 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 i23Ecgh15431; Wed, 3 Mar 2004 16:38:42 +0200 (EET) X-Scanned: Wed, 3 Mar 2004 16:38:02 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i23Ec2M1005633; Wed, 3 Mar 2004 16:38:02 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Jx8onV; Wed, 03 Mar 2004 16:38:01 EET 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 i23Ec0713937; Wed, 3 Mar 2004 16:38:00 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Mar 2004 16:37:58 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4012D.1E4EFE8B" Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure Date: Wed, 3 Mar 2004 16:37:56 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B04A8@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure Thread-Index: AcQBKE28yO9e99vxRRmuX1nO1K52XAAACZQw From: To: Cc: X-OriginalArrivalTime: 03 Mar 2004 14:37:58.0622 (UTC) FILETIME=[1F764FE0:01C4012D] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C4012D.1E4EFE8B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mark, =20 I though the CC-Service-Specific-Unit AVP would be enough. The = Service-Id defines what is the resource indicated in=20 CC-Service-Specific-Unit AVP as defined in section 8.26. =20 Do you see the need of *[ AVP ] in R-S-U, U-S-U and G-S-U?=20 =20 Regards Marco -----Original Message----- From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 03 March, 2004 16:03 To: Stura Marco (Nokia-NET/Helsinki) Cc: 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the = M-S-C-C AVP structure Ok, but what if we want to add new types of resource units to G-S-U and = U-S-U ? =20 Straightforward time and octet volume may not be the only way to measure = usage in future. If I remember rightly, then the previous draft of = DIAMETER credit control, which is unfortunately embedded in 3GPP TS = 32.225, defined an enumerated 'Unit-Type AVP' which would have been easy = to extend. Switching to explicit AVPs for each unit type is fine, but do = we want to lose extensibility here ? Regards, =20 Mark =20 =20 -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: 03 March 2004 13:40 To: Watson, Mark [MOP:EP10:EXCH] Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the = M-S-C-C AVP structure Hi Mark, =20 Just for my understanding, am I right in thinking that, without this, = the M-S-C-C AVP cannot be extended with future optional AVPs in a = backwards compatible way ? =20 If you want the ability to define new optional AVPs in a grouped = structure you do need the *[ AVP ] notation. Since the scope of the = M-S-C-C AVP is to implement a functionality for which we may not see all = the future needs and requirements, it may be necessary to add optional = AVPs in the future. In a way the M-S-C-C can be abstracted as a = *command*, and we don't know what are all the future needs for that = *command*.=20 =20 If so, what about all the other Grouped AVPs in the protocol and, for = that matter, the commands ? =20 The semantic of other grouped AVPs defined in DCC do not require the *[ = AVP ] notation, at least I cannot see any other grouped AVP that would = need this. Note that the CCR/CCA already have *[AVP], you can add AVPs = to the command in the future if you need.=20 =20 Regards Marco ------_=_NextPart_001_01C4012D.1E4EFE8B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Mark,
 
I=20 though the CC-Service-Specific-Unit AVP would be enough. The Service-Id = defines=20 what is the resource indicated in
CC-Service-Specific-Unit AVP as defined in section=20 8.26.
 
Do you=20 see the need of  *[ AVP ] in R-S-U, U-S-U and G-S-U? =
 
Regards
Marco
-----Original Message-----
From: ext Mark Watson=20 [mailto:mwatson@nortelnetworks.com]
Sent: 03 March, 2004=20 16:03
To: Stura Marco (Nokia-NET/Helsinki)
Cc:=20 'aaa-wg@merit.edu'
Subject: RE: [AAA-WG]: DCC Issue: = addition of=20 *[AVP] notation in the M-S-C-C AVP structure

Ok, but what if we want to add new types of resource units to = G-S-U and=20 U-S-U ?
 
Straightforward time and octet volume may not be the = only way to=20 measure usage in future. If I remember rightly, then the previous = draft of=20 DIAMETER credit control, which is unfortunately embedded in 3GPP TS = 32.225,=20 defined an enumerated 'Unit-Type AVP' which would have been easy to = extend.=20 Switching to explicit AVPs for each unit type is fine, but do we want = to lose=20 extensibility here ?

Regards,
 
Mark
 
 
-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: 03=20 March 2004 13:40
To: Watson, Mark = [MOP:EP10:EXCH]
Cc:=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC Issue: = addition of=20 *[AVP] notation in the M-S-C-C AVP structure

Hi=20 Mark,
 
Just for my = understanding,=20 am I right in thinking that, without this, the M-S-C-C AVP cannot be = extended with future optional AVPs in a backwards compatible way=20 ?
 
If=20 you want the ability to define new optional AVPs in a grouped = structure you=20 do need the *[ AVP ] notation. Since the scope of the M-S-C-C = AVP is to=20 implement a functionality for which we may not see all the = future=20 needs and requirements, it may be necessary to add optional AVPs in = the=20 future. In a way the M-S-C-C can be abstracted as a *command*, = and we=20 don't know what are all the future needs for that=20 *command*. 
 
If so, what = about all the=20 other Grouped AVPs in the protocol and, for that matter, the = commands=20 ?
 
The semantic of other grouped AVPs = defined in DCC=20 do not require the *[ AVP ] notation, at least I cannot see any = other=20 grouped AVP that would need this. Note that the CCR/CCA already have *[AVP],  you = can add=20 AVPs to the command in the future if you=20 need. 
 
Regards
Marco
<= /BLOCKQUOTE> ------_=_NextPart_001_01C4012D.1E4EFE8B-- From owner-aaa-wg@merit.edu Wed Mar 3 09:49: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 JAA01118 for ; Wed, 3 Mar 2004 09:49:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 477459129F; Wed, 3 Mar 2004 09:49:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16F91912A0; Wed, 3 Mar 2004 09:49:30 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 58C989129F for ; Wed, 3 Mar 2004 09:49:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4454F5E117; Wed, 3 Mar 2004 09:49:28 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.166.48.91]) by segue.merit.edu (Postfix) with ESMTP id 942BA5E113 for ; Wed, 3 Mar 2004 09:49:27 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i23EnOm03553; Wed, 3 Mar 2004 14:49:24 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1W6W3C7J>; Wed, 3 Mar 2004 14:49:24 -0000 Message-ID: <588B15E2E2B1D41180B800508BF934F20AAC63BE@bmdhd6.europe.nortel.com> From: "Mark Watson" To: "'marco.stura@nokia.com'" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C -C AVP structure Date: Wed, 3 Mar 2004 14:49:17 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4012E.B4489CBC" 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_01C4012E.B4489CBC Content-Type: text/plain I would not think that new ways of measuring usage would necessarily be service-specific, but I don't have a big list of new ways to measure things in front of me (I do have a small list, though!) However, adding extensibility now is free, wheras adding it later costs (you would need a new AVPs to replace R-S-U, U-S-U and G-S-U). Even if you only see a 10% chance of needing such extensions, then the expected cost (10% times that future cost) is still greater than zero. So, I would suggest adding * [ AVP ] to those AVPs too. Regards...Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 03 March 2004 14:38 To: Watson, Mark [MOP:EP10:EXCH] Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure Mark, I though the CC-Service-Specific-Unit AVP would be enough. The Service-Id defines what is the resource indicated in CC-Service-Specific-Unit AVP as defined in section 8.26. Do you see the need of *[ AVP ] in R-S-U, U-S-U and G-S-U? Regards Marco -----Original Message----- From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 03 March, 2004 16:03 To: Stura Marco (Nokia-NET/Helsinki) Cc: 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure Ok, but what if we want to add new types of resource units to G-S-U and U-S-U ? Straightforward time and octet volume may not be the only way to measure usage in future. If I remember rightly, then the previous draft of DIAMETER credit control, which is unfortunately embedded in 3GPP TS 32.225, defined an enumerated 'Unit-Type AVP' which would have been easy to extend. Switching to explicit AVPs for each unit type is fine, but do we want to lose extensibility here ? Regards, Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 03 March 2004 13:40 To: Watson, Mark [MOP:EP10:EXCH] Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure Hi Mark, Just for my understanding, am I right in thinking that, without this, the M-S-C-C AVP cannot be extended with future optional AVPs in a backwards compatible way ? If you want the ability to define new optional AVPs in a grouped structure you do need the *[ AVP ] notation. Since the scope of the M-S-C-C AVP is to implement a functionality for which we may not see all the future needs and requirements, it may be necessary to add optional AVPs in the future. In a way the M-S-C-C can be abstracted as a *command*, and we don't know what are all the future needs for that *command*. If so, what about all the other Grouped AVPs in the protocol and, for that matter, the commands ? The semantic of other grouped AVPs defined in DCC do not require the *[ AVP ] notation, at least I cannot see any other grouped AVP that would need this. Note that the CCR/CCA already have *[AVP], you can add AVPs to the command in the future if you need. Regards Marco ------_=_NextPart_001_01C4012E.B4489CBC Content-Type: text/html Message
I would not think that new ways of measuring usage would necessarily be service-specific, but I don't have a big list of new ways to measure things in front of me (I do have a small list, though!)
 
However, adding extensibility now is free, wheras adding it later costs (you would need a new AVPs to replace R-S-U, U-S-U and G-S-U). Even if you only see a 10% chance of needing such extensions, then the expected cost (10% times that future cost) is still greater than zero.
 
So, I would suggest adding * [ AVP ] to those AVPs too.
 
Regards...Mark
-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: 03 March 2004 14:38
To: Watson, Mark [MOP:EP10:EXCH]
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure

Mark,
 
I though the CC-Service-Specific-Unit AVP would be enough. The Service-Id defines what is the resource indicated in
CC-Service-Specific-Unit AVP as defined in section 8.26.
 
Do you see the need of  *[ AVP ] in R-S-U, U-S-U and G-S-U?
 
Regards
Marco
-----Original Message-----
From: ext Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: 03 March, 2004 16:03
To: Stura Marco (Nokia-NET/Helsinki)
Cc: 'aaa-wg@merit.edu'
Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure

Ok, but what if we want to add new types of resource units to G-S-U and U-S-U ?
 
Straightforward time and octet volume may not be the only way to measure usage in future. If I remember rightly, then the previous draft of DIAMETER credit control, which is unfortunately embedded in 3GPP TS 32.225, defined an enumerated 'Unit-Type AVP' which would have been easy to extend. Switching to explicit AVPs for each unit type is fine, but do we want to lose extensibility here ?

Regards,
 
Mark
 
 
-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: 03 March 2004 13:40
To: Watson, Mark [MOP:EP10:EXCH]
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure

Hi Mark,
 
Just for my understanding, am I right in thinking that, without this, the M-S-C-C AVP cannot be extended with future optional AVPs in a backwards compatible way ?
 
If you want the ability to define new optional AVPs in a grouped structure you do need the *[ AVP ] notation. Since the scope of the M-S-C-C AVP is to implement a functionality for which we may not see all the future needs and requirements, it may be necessary to add optional AVPs in the future. In a way the M-S-C-C can be abstracted as a *command*, and we don't know what are all the future needs for that *command*. 
 
If so, what about all the other Grouped AVPs in the protocol and, for that matter, the commands ?
 
The semantic of other grouped AVPs defined in DCC do not require the *[ AVP ] notation, at least I cannot see any other grouped AVP that would need this. Note that the CCR/CCA already have *[AVP],  you can add AVPs to the command in the future if you need. 
 
Regards
Marco
------_=_NextPart_001_01C4012E.B4489CBC-- From owner-aaa-wg@merit.edu Wed Mar 3 09:58: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 JAA01614 for ; Wed, 3 Mar 2004 09:58:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9FDA5912A1; Wed, 3 Mar 2004 09:57:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65406912A4; Wed, 3 Mar 2004 09:57:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 82821912A1 for ; Wed, 3 Mar 2004 09:57:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 683235E16A; Wed, 3 Mar 2004 09:57:49 -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 1D0125E156 for ; Wed, 3 Mar 2004 09:57:48 -0500 (EST) 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 i23EvkC13292; Wed, 3 Mar 2004 16:57:47 +0200 (EET) X-Scanned: Wed, 3 Mar 2004 16:57:28 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i23EvSwM032177; Wed, 3 Mar 2004 16:57:28 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00SYwVB2; Wed, 03 Mar 2004 16:57:26 EET 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 i23EvQO17035; Wed, 3 Mar 2004 16:57:26 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Mar 2004 16:57:26 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4012F.D73942CE" Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure Date: Wed, 3 Mar 2004 16:57:25 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C8520@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure Thread-Index: AcQBLt6XdXCcL85sQeiySaMmpeTzlgAAJNFw From: To: Cc: X-OriginalArrivalTime: 03 Mar 2004 14:57:26.0401 (UTC) FILETIME=[D7833F10:01C4012F] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C4012F.D73942CE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree. =20 I'll update the issue to add *[ AVP ] in the R-S-U, U-S-U and G-S-U as = well. =20 Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Mark Watson Sent: 03 March, 2004 16:49 To: Stura Marco (Nokia-NET/Helsinki) Cc: 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the = M-S-C-C AVP structure I would not think that new ways of measuring usage would necessarily be = service-specific, but I don't have a big list of new ways to measure = things in front of me (I do have a small list, though!) =20 However, adding extensibility now is free, wheras adding it later costs = (you would need a new AVPs to replace R-S-U, U-S-U and G-S-U). Even if = you only see a 10% chance of needing such extensions, then the expected = cost (10% times that future cost) is still greater than zero. =20 So, I would suggest adding * [ AVP ] to those AVPs too.=20 =20 Regards...Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: 03 March 2004 14:38 To: Watson, Mark [MOP:EP10:EXCH] Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the = M-S-C-C AVP structure Mark, =20 I though the CC-Service-Specific-Unit AVP would be enough. The = Service-Id defines what is the resource indicated in=20 CC-Service-Specific-Unit AVP as defined in section 8.26. =20 Do you see the need of *[ AVP ] in R-S-U, U-S-U and G-S-U?=20 =20 Regards Marco -----Original Message----- From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 03 March, 2004 16:03 To: Stura Marco (Nokia-NET/Helsinki) Cc: 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the = M-S-C-C AVP structure Ok, but what if we want to add new types of resource units to G-S-U and = U-S-U ? =20 Straightforward time and octet volume may not be the only way to measure = usage in future. If I remember rightly, then the previous draft of = DIAMETER credit control, which is unfortunately embedded in 3GPP TS = 32.225, defined an enumerated 'Unit-Type AVP' which would have been easy = to extend. Switching to explicit AVPs for each unit type is fine, but do = we want to lose extensibility here ? Regards, =20 Mark =20 =20 -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: 03 March 2004 13:40 To: Watson, Mark [MOP:EP10:EXCH] Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the = M-S-C-C AVP structure Hi Mark, =20 Just for my understanding, am I right in thinking that, without this, = the M-S-C-C AVP cannot be extended with future optional AVPs in a = backwards compatible way ? =20 If you want the ability to define new optional AVPs in a grouped = structure you do need the *[ AVP ] notation. Since the scope of the = M-S-C-C AVP is to implement a functionality for which we may not see all = the future needs and requirements, it may be necessary to add optional = AVPs in the future. In a way the M-S-C-C can be abstracted as a = *command*, and we don't know what are all the future needs for that = *command*.=20 =20 If so, what about all the other Grouped AVPs in the protocol and, for = that matter, the commands ? =20 The semantic of other grouped AVPs defined in DCC do not require the *[ = AVP ] notation, at least I cannot see any other grouped AVP that would = need this. Note that the CCR/CCA already have *[AVP], you can add AVPs = to the command in the future if you need.=20 =20 Regards Marco ------_=_NextPart_001_01C4012F.D73942CE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
I=20 agree.
 
I'll=20 update the issue to add *[ AVP ] in the R-S-U, U-S-U and G-S-U as=20 well.
 
Regards
Marco
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Mark=20 Watson
Sent: 03 March, 2004 16:49
To: Stura Marco=20 (Nokia-NET/Helsinki)
Cc: = 'aaa-wg@merit.edu'
Subject: RE:=20 [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP=20 structure

I=20 would not think that new ways of measuring usage would necessarily be=20 service-specific, but I don't have a big list of new ways to measure = things in=20 front of me (I do have a small list, though!)
 
However, adding extensibility now is free, wheras adding it = later costs=20 (you would need a new AVPs to replace R-S-U, U-S-U and G-S-U). Even if = you=20 only see a 10% chance of needing such extensions, then the expected = cost (10%=20 times that future cost) is still greater than = zero.
 
So, I would=20 suggest adding * [ AVP ] to those AVPs too.
 
Regards...Mark
-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: 03=20 March 2004 14:38
To: Watson, Mark = [MOP:EP10:EXCH]
Cc:=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC Issue: = addition of=20 *[AVP] notation in the M-S-C-C AVP structure

Mark,
 
I=20 though the CC-Service-Specific-Unit AVP would be enough. The = Service-Id=20 defines what is the resource indicated in
CC-Service-Specific-Unit AVP as defined in section=20 8.26.
 
Do=20 you see the need of  *[ AVP ] in R-S-U, U-S-U and G-S-U?=20
 
Regards
Marco
-----Original Message-----
From: ext Mark = Watson=20 [mailto:mwatson@nortelnetworks.com]
Sent: 03 March, 2004 = 16:03
To: Stura Marco (Nokia-NET/Helsinki)
Cc: = 'aaa-wg@merit.edu'
Subject: RE: [AAA-WG]: DCC Issue: = addition of=20 *[AVP] notation in the M-S-C-C AVP structure

Ok, but what if we want to add new types of resource = units to G-S-U=20 and U-S-U ?
 
Straightforward time and octet volume may not be the = only way=20 to measure usage in future. If I remember rightly, then the = previous draft=20 of DIAMETER credit control, which is unfortunately embedded in = 3GPP TS=20 32.225, defined an enumerated 'Unit-Type AVP' which would have = been easy=20 to extend. Switching to explicit AVPs for each unit type is fine, = but do=20 we want to lose extensibility here ?

Regards,
 
Mark
 
 
-----Original = Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: 03=20 March 2004 13:40
To: Watson, Mark=20 [MOP:EP10:EXCH]
Cc: = aaa-wg@merit.edu
Subject: RE:=20 [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C = AVP=20 structure

Hi Mark,
 
Just for my = understanding, am I right in thinking that, without this, the = M-S-C-C=20 AVP cannot be extended with future optional AVPs in a backwards=20 compatible way ?
 
If you want the ability to define new = optional=20 AVPs in a grouped structure you do need the *[ AVP ]=20 notation. Since the scope of the M-S-C-C AVP is to = implement=20 a functionality for which we may not see all the = future needs=20 and requirements, it may be necessary to add optional AVPs in = the=20 future. In a way the M-S-C-C can be abstracted as a = *command*, and=20 we don't know what are all the future needs for that=20 *command*. 
 
If so, what = about all=20 the other Grouped AVPs in the protocol and, for that matter, the = commands ?
 
The semantic of other grouped AVPs = defined in=20 DCC do not require the *[ AVP ] notation, at least I cannot = see any=20 other grouped AVP that would need this. Note that = the CCR/CCA already have *[AVP],  = you can=20 add AVPs to the command in the future if you=20 need. 
 
Regards
Marco
<= /BLOCKQUOTE>
------_=_NextPart_001_01C4012F.D73942CE-- From owner-aaa-wg@merit.edu Wed Mar 3 10:15:50 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 KAA03390 for ; Wed, 3 Mar 2004 10:15:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 476D2912B5; Wed, 3 Mar 2004 10:14:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 18F9C912C6; Wed, 3 Mar 2004 10:14: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 24224912B5 for ; Wed, 3 Mar 2004 10:14:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0A1D55E188; Wed, 3 Mar 2004 10:14:17 -0500 (EST) 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 402E85E185 for ; Wed, 3 Mar 2004 10:14:16 -0500 (EST) 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 i23FEFS06323; Wed, 3 Mar 2004 17:14:15 +0200 (EET) X-Scanned: Wed, 3 Mar 2004 17:12:11 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i23FCBhF001838; Wed, 3 Mar 2004 17:12:11 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00RayDjJ; Wed, 03 Mar 2004 17:12:09 EET 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 i23FC9O23443; Wed, 3 Mar 2004 17:12:09 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Mar 2004 17:12:09 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Update to DCC Issue 25: addition of *[AVP] notation in some grouped AVPs structure Date: Wed, 3 Mar 2004 17:11:36 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B04A9@esebe016.ntc.nokia.com> Thread-Topic: Update to DCC Issue 25: addition of *[AVP] notation in some grouped AVPs structure Thread-Index: AcQBMdH39MP7q2EmQ6ymh7MvbO7RBA== From: To: Cc: X-OriginalArrivalTime: 03 Mar 2004 15:12:09.0737 (UTC) FILETIME=[E6059F90:01C40131] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, according to recent discussion here is the updated issue 25 to add the = *[ AVP ] notation also to the G-S-U, R-S-U and U-S-U AVPs. Regards Marco ------------------------------------------------------------- Description of issue: addition of *[AVP] notation in the M-S-C-C AVP = structure Submitter name: Marco Stura Date first submitted: 1.03.2004=20 Reference:=20 Document: draft-ietf-aaa-diameter-cc-03.txt=20 Comment type: T Priority: 1=20 Section: 8.16 Rationale/Explanation of issues:=20 In order to define a more future proof structure I propose to add the = *[AVP] notation to the M-S-C-C, G-S-U, U-S-U and R-S-U AVPs structure. According to the = Base (section 4.4.1)=20 the Grouped AVP can contain *[AVP]. Requested change: -Section 8.16 ADD the *[ AVP ] notation to the AVP structure Multiple-Services-Credit-Control ::=3D < AVP Header: 456 > =20 [ Granted-Service-Unit ]=20 [ Requested-Service-Units ] = *[ Used-Service-Units ]=20 [ Tariff-Change-Usage ] =20 *[ Service-Identifier ] =20 [ Rating-Group ] =20 *[ G-S-U-Pool-Reference ] =20 [ Validity-Time ] =20 [ Result-Code ] =20 [ Final-Unit-Indication ]=20 *[ AVP ] - Section 8.17 ADD the *[ AVP ] notation to the AVP structure Granted-Service-Unit ::=3D < AVP Header: 431 > =20 [ Tariff-Time-Change ] =20 [ CC-Time ] =20 [ CC-Money ] =20 [ CC-Total-Octets ] =20 [ CC-Input-Octets ] =20 [ CC-Output-Octets ] =20 [ CC-Service-Specific-Units ] *[ AVP ] - Section 8.18 ADD the *[ AVP ] notation to the AVP structure Requested-Service-Unit ::=3D < AVP Header: 437 > =20 [ CC-Time ] =20 [ CC-Money ] =20 [ CC-Total-Octets ] =20 [ CC-Input-Octets ] =20 [ CC-Output-Octets ] =20 [ CC-Service-Specific-Units ] *[ AVP ] - Section 8.19 ADD the *[ AVP ] notation to the AVP structure Used-Service-Unit ::=3D < AVP Header: 446 > =20 [ Tariff-Change-Usage ] =20 [ CC-Time ] =20 [ CC-Money ] =20 [ CC-Total-Octets ] =20 [ CC-Input-Octets ] =20 [ CC-Output-Octets ] =20 [ CC-Service-Specific-Units ] *[ AVP ] From aaa-admin@ietf.org Wed Mar 3 14:18: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 OAA19385 for ; Wed, 3 Mar 2004 14: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 1AybsX-0001fm-79; Wed, 03 Mar 2004 14: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 1AybrX-0001T4-VX for aaa@optimus.ietf.org; Wed, 03 Mar 2004 14:16:59 -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 OAA19286 for ; Wed, 3 Mar 2004 14:16:57 -0500 (EST) From: hassansalif@excite.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AybrV-0000O2-00 for aaa@ietf.org; Wed, 03 Mar 2004 14:16:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aybqb-00009C-00 for aaa@ietf.org; Wed, 03 Mar 2004 14:16:02 -0500 Received: from 77.red-80-25-253.pooles.rima-tde.net ([80.25.253.77] helo=myhost) by ietf-mx with esmtp (Exim 4.12) id 1AybpO-0007Su-00 for aaa@ietf.org; Wed, 03 Mar 2004 14:14:47 -0500 To: aaa@ietf.org Content-Type: text/plain; charset="US-ASCII" Reply-To: hassansalif@excite.com Date: Wed, 3 Mar 2004 20:14:26 +0100 X-Priority: 3 X-Library: Indy 9.0.3-B X-Mailer: Foxmail 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=8.0 required=5.0 tests=AWL,LINES_OF_YELLING, MILLION_USD,MSGID_FROM_MTA_SHORT,NIGERIAN_BODY1,NIGERIAN_BODY2, NO_REAL_NAME,SUBJ_ALL_CAPS,US_DOLLARS_3,X_LIBRARY autolearn=no version=2.60 X-Spam-Report: * 1.4 X_LIBRARY Message has X-Library header * 0.3 NO_REAL_NAME From: does not include a real name * 0.9 MILLION_USD BODY: Talks about millions of dollars * 0.6 US_DOLLARS_3 BODY: Mentions millions of $ ($NN,NNN,NNN.NN) * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.6 SUBJ_ALL_CAPS Subject is all capitals * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.7 NIGERIAN_BODY2 Message body looks like a Nigerian spam message 2+ * 1.6 NIGERIAN_BODY1 Message body looks like a Nigerian spam message 1+ * -1.4 AWL AWL: Auto-whitelist adjustment Subject: [Aaa] JANG DOO------ VERY IMPORTANT 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: , Greetings from me and my family, Getting your contact was not an easy task because since I am not computer literate, I ordered my son to seek a partner very far away and he went to the institute of International Business to apply and he paid them the charges. After two days we were given three names and I did not write the three but merely close my eyes in prayers and your address became my selection. I intended to write one of the others if you had not responded on time or if you eventually change your mind. You see my friend, if you rely solely on God, you will never go wrong. My name is JANG DOO-HWAN, The brother of Mr. CHUN DOO-HWAN, the former President of South Korea who seized power in a military coup in 1979 and who ruled from 1979 to 1987. My brother was pushed out of office and charged with treason ,corruption and embezzlement of over 21billion won. He was wrongly sentenced to death but fortunately AMNESTY INTERNATIONAL stepped in and commuted the sentence to life. We thank God that he has finally being released though still under house arrest in the sense of conditions of the freedom. During my brother's regime as president of South Korea, we realized some reasonable amount of money from various deals that we successfully executed. I have plans to invest this money for my children’s future on real estate and industrial production. Before my brother's was overthrown, I secretly siphoned the sum of $30,000,000 million USD (Thirty million United states dollars) out of Seoul and deposited the money with a security firm that transports valuable goods and consignments through diplomatic means. I am contacting you because I want you to deal with the security company and claim the money on my behalf since I have declared that the consignment belong to my foreign business partner. You shall also be required to assist me in investment in your country. I hope to trust you as a God fearing person who will not sit on this money when you claim it, rather assist me properly, I expect you to declare what percentage of the total money you will take for your assistance. When I receive your positive response I will let you know where the security company is and the payment pin code to claim the money which is very important. What we need is to indicate your interest that you will assist us by receiving the money on our behalf in Europe or with special arrangement, you can get it transfered to you by bank transfer . For this, you shall be considered to be the beneficiary of the money. The project in brief, is that the funds with which we intend to carry out our proposed investments in your country, is presently in the custody of a Diplomatic Courier Services Company in Europe. We cannot do this ourselves because we do not have any relatives living outside South Korea and moreover we do not want the government of my Country to know about the money because they will believe I got the money from my brother while he was still in office as president .Once you confirm the receipt of the money ,I will come over with my Children to your Country or any Country in Europe to start a new life with my Family. As soon as payment is effected, and the amount mentioned above is successfully transferred into your account, we intend to use our own share in acquiring some estates abroad. For this too you shall also be our overseas manager of all our properties and you will be paid based on a certain percentage agreed on by both parties. For now, let all our communication be by e-mail because my line is right now connected to the South Korean Telecommunication Network services therefore we can not take the chances of being heard. Please also send me your telephone and fax number. I will ask my son to contact you to give you more details on after I have received a response from you. I am going to introduce you to him as an age long friend so as to prevent him from using any of his own friends who I regard as sycophants who are around him for financial gains and treacherous if he gives them this opportunity. This I got from the experience I had when the people turned against Chun, my brother that became the prelude of our sorrow. The reason why it took this long was that the security company’s agreement with me was that my brother must personally sign the Power of Attorney that will transfer title to the prospective beneficiary. It was a long wait but it paid off. His excellency, Chun Doo-Hwan does not want to be personally involved for security reason. Your quick response will be highly appreciated. Thank you in anticipation of your cooperation. Yours faithfully, JANG DOO-HWAN. _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Wed Mar 3 14:19: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 OAA19466 for ; Wed, 3 Mar 2004 14:19: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 1AybtW-0001n0-IH for aaa-archive@odin.ietf.org; Wed, 03 Mar 2004 14:19:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23JJ2CH006877 for aaa-archive@odin.ietf.org; Wed, 3 Mar 2004 14:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AybtW-0001mp-Dd for aaa-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 14:19: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 OAA19446 for ; Wed, 3 Mar 2004 14:19:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AybtT-0000me-00 for aaa-web-archive@ietf.org; Wed, 03 Mar 2004 14:18:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AybsY-0000ag-00 for aaa-web-archive@ietf.org; Wed, 03 Mar 2004 14: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 1AybsX-0001fm-79; Wed, 03 Mar 2004 14: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 1AybrX-0001T4-VX for aaa@optimus.ietf.org; Wed, 03 Mar 2004 14:16:59 -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 OAA19286 for ; Wed, 3 Mar 2004 14:16:57 -0500 (EST) From: hassansalif@excite.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AybrV-0000O2-00 for aaa@ietf.org; Wed, 03 Mar 2004 14:16:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aybqb-00009C-00 for aaa@ietf.org; Wed, 03 Mar 2004 14:16:02 -0500 Received: from 77.red-80-25-253.pooles.rima-tde.net ([80.25.253.77] helo=myhost) by ietf-mx with esmtp (Exim 4.12) id 1AybpO-0007Su-00 for aaa@ietf.org; Wed, 03 Mar 2004 14:14:47 -0500 To: aaa@ietf.org Content-Type: text/plain; charset="US-ASCII" Reply-To: hassansalif@excite.com Date: Wed, 3 Mar 2004 20:14:26 +0100 X-Priority: 3 X-Library: Indy 9.0.3-B X-Mailer: Foxmail 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=8.0 required=5.0 tests=AWL,LINES_OF_YELLING, MILLION_USD,MSGID_FROM_MTA_SHORT,NIGERIAN_BODY1,NIGERIAN_BODY2, NO_REAL_NAME,SUBJ_ALL_CAPS,US_DOLLARS_3,X_LIBRARY autolearn=no version=2.60 X-Spam-Report: * 1.4 X_LIBRARY Message has X-Library header * 0.3 NO_REAL_NAME From: does not include a real name * 0.9 MILLION_USD BODY: Talks about millions of dollars * 0.6 US_DOLLARS_3 BODY: Mentions millions of $ ($NN,NNN,NNN.NN) * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.6 SUBJ_ALL_CAPS Subject is all capitals * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.7 NIGERIAN_BODY2 Message body looks like a Nigerian spam message 2+ * 1.6 NIGERIAN_BODY1 Message body looks like a Nigerian spam message 1+ * -1.4 AWL AWL: Auto-whitelist adjustment Subject: [Aaa] JANG DOO------ VERY IMPORTANT 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: , Greetings from me and my family, Getting your contact was not an easy task because since I am not computer literate, I ordered my son to seek a partner very far away and he went to the institute of International Business to apply and he paid them the charges. After two days we were given three names and I did not write the three but merely close my eyes in prayers and your address became my selection. I intended to write one of the others if you had not responded on time or if you eventually change your mind. You see my friend, if you rely solely on God, you will never go wrong. My name is JANG DOO-HWAN, The brother of Mr. CHUN DOO-HWAN, the former President of South Korea who seized power in a military coup in 1979 and who ruled from 1979 to 1987. My brother was pushed out of office and charged with treason ,corruption and embezzlement of over 21billion won. He was wrongly sentenced to death but fortunately AMNESTY INTERNATIONAL stepped in and commuted the sentence to life. We thank God that he has finally being released though still under house arrest in the sense of conditions of the freedom. During my brother's regime as president of South Korea, we realized some reasonable amount of money from various deals that we successfully executed. I have plans to invest this money for my children’s future on real estate and industrial production. Before my brother's was overthrown, I secretly siphoned the sum of $30,000,000 million USD (Thirty million United states dollars) out of Seoul and deposited the money with a security firm that transports valuable goods and consignments through diplomatic means. I am contacting you because I want you to deal with the security company and claim the money on my behalf since I have declared that the consignment belong to my foreign business partner. You shall also be required to assist me in investment in your country. I hope to trust you as a God fearing person who will not sit on this money when you claim it, rather assist me properly, I expect you to declare what percentage of the total money you will take for your assistance. When I receive your positive response I will let you know where the security company is and the payment pin code to claim the money which is very important. What we need is to indicate your interest that you will assist us by receiving the money on our behalf in Europe or with special arrangement, you can get it transfered to you by bank transfer . For this, you shall be considered to be the beneficiary of the money. The project in brief, is that the funds with which we intend to carry out our proposed investments in your country, is presently in the custody of a Diplomatic Courier Services Company in Europe. We cannot do this ourselves because we do not have any relatives living outside South Korea and moreover we do not want the government of my Country to know about the money because they will believe I got the money from my brother while he was still in office as president .Once you confirm the receipt of the money ,I will come over with my Children to your Country or any Country in Europe to start a new life with my Family. As soon as payment is effected, and the amount mentioned above is successfully transferred into your account, we intend to use our own share in acquiring some estates abroad. For this too you shall also be our overseas manager of all our properties and you will be paid based on a certain percentage agreed on by both parties. For now, let all our communication be by e-mail because my line is right now connected to the South Korean Telecommunication Network services therefore we can not take the chances of being heard. Please also send me your telephone and fax number. I will ask my son to contact you to give you more details on after I have received a response from you. I am going to introduce you to him as an age long friend so as to prevent him from using any of his own friends who I regard as sycophants who are around him for financial gains and treacherous if he gives them this opportunity. This I got from the experience I had when the people turned against Chun, my brother that became the prelude of our sorrow. The reason why it took this long was that the security company’s agreement with me was that my brother must personally sign the Power of Attorney that will transfer title to the prospective beneficiary. It was a long wait but it paid off. His excellency, Chun Doo-Hwan does not want to be personally involved for security reason. Your quick response will be highly appreciated. Thank you in anticipation of your cooperation. Yours faithfully, JANG DOO-HWAN. _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Wed Mar 3 17:03: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 RAA29210 for ; Wed, 3 Mar 2004 17:03:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D71E391306; Wed, 3 Mar 2004 17:00:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 785C691303; Wed, 3 Mar 2004 17:00:52 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 479819130A for ; Wed, 3 Mar 2004 17:00:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 12F635E31F; Wed, 3 Mar 2004 17:00:09 -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 577135E37D for ; Wed, 3 Mar 2004 17:00:07 -0500 (EST) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 03 Mar 2004 14:00:14 -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 i23M04D1019240 for ; Wed, 3 Mar 2004 14:00:04 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.241.90]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Mar 2004 14:06:17 -0800 From: "Joseph Salowey" To: Subject: [AAA-WG]: Issue EAP : User-name Handling Date: Wed, 3 Mar 2004 14:00:02 -0800 Message-ID: <008101c4016a$e1ae1560$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.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 03 Mar 2004 22:06:18.0343 (UTC) FILETIME=[C0F1FF70:01C4016B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 3/3/2004 Reference: Document: eap Comment type: 'E'ditorial Priority: '1' Should fix Section: 2.8.1 Rationale/Explanation of issue: The draft says "...the Diameter server SHOULD return the user's identity by inserting it in the User-Name AVP of susequent Diameter-EAP-Answer packets." It is not clear which user identity this is referring to. If it is referring to the user's real identity this is only available once the EAP method completes. It probably should state: "...the Diameter Server SHOULD return the real user's identity by inserting it in the User-Name AVP of Diameter-EAP-Answer packets that contain a Result-Code of DIAMETER-SUCCESS." It might also be good to discuss that the real user-name MAY be omitted or replaced with a different billing identifier if identity privacy is required in the DIAMETER channel. From owner-aaa-wg@merit.edu Wed Mar 3 20:16: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 UAA11975 for ; Wed, 3 Mar 2004 20:16:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B1042912DE; Wed, 3 Mar 2004 20:13:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70908912EF; Wed, 3 Mar 2004 20:13:17 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3B03F912DE for ; Wed, 3 Mar 2004 20:11:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 280C95DF50; Wed, 3 Mar 2004 20:11: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 DD5E35DF4D for ; Wed, 3 Mar 2004 20:11:20 -0500 (EST) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 03 Mar 2004 17:11:28 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i241AeiS008596 for ; Wed, 3 Mar 2004 17:11:09 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.241.90]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Mar 2004 17:17:11 -0800 From: "Joseph Salowey" To: Subject: [AAA-WG]: Issue eap : Key Name AVP Date: Wed, 3 Mar 2004 17:10:55 -0800 Message-ID: <009401c40185$8c642cf0$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.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 04 Mar 2004 01:17:11.0531 (UTC) FILETIME=[6B93CBB0:01C40186] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit 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 Mar 3 20:51:52 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 UAA14263 for ; Wed, 3 Mar 2004 20:51:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3EFEE912C8; Wed, 3 Mar 2004 20:51:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C5A9912C9; Wed, 3 Mar 2004 20:51:37 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CE37B912C8 for ; Wed, 3 Mar 2004 20:51:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id B8C345DF8C; Wed, 3 Mar 2004 20:51:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by segue.merit.edu (Postfix) with ESMTP id 5A8595DF8B for ; Wed, 3 Mar 2004 20:51:36 -0500 (EST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i241pWLM012997 for ; Wed, 3 Mar 2004 17:51:32 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.241.90]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Mar 2004 17:57:45 -0800 From: "Joseph Salowey" To: Subject: [AAA-WG]: Issue eap: Alternate uses and conflicting AVPs Date: Wed, 3 Mar 2004 17:51:30 -0800 Message-ID: <00a401c4018b$3771e6f0$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.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 04 Mar 2004 01:57:46.0000 (UTC) FILETIME=[16A24900:01C4018C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 3/3/2004 Reference: Document: eap Comment type: E Priority: '1' Should fix Section: 2.8.2 and 2.8.5 Rationale/Explanation of issue: Since EAP keying has the concept of the key name this should probably be returned along with the Master Key. It might be goos to provide some motivation behind the 2.8.2 recommendation. I think the basic reason is that often lower layer protocols do not distingush between authentication and authorization. In these protocols the EAP-Success translates to a granting of access. If one were dealing with lower layer protocols that handled this differently then perhaps the having conflicting AVPs in some cases might not be so bad. The alternate use of using Diameter to interface to an EAP authentication server from an authorization server introduces some interesting behavior. It could be possible that the authentication succeeds and the authorization fails. In this case it would seem that the authorization server should turn the EAP-Payload to an EAP-Failure to be in line with 2.8.2. It might also be noted that this behavior when used with certain EAP methods may cause a EAP timeout in lower layers that expect the authorization decision to match the EAP Authentication decision. From owner-aaa-wg@merit.edu Wed Mar 3 20:53: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 UAA14489 for ; Wed, 3 Mar 2004 20:53:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 576E6912C9; Wed, 3 Mar 2004 20:53:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 24D85912CA; Wed, 3 Mar 2004 20:53:39 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D4559912C9 for ; Wed, 3 Mar 2004 20:53:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id C14435DFA7; Wed, 3 Mar 2004 20:53:37 -0500 (EST) 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 BC5AA5DFA6 for ; Wed, 3 Mar 2004 20:53:36 -0500 (EST) Received: from nokia.com (esnira-pool201395.nokia.com [10.162.13.95]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i241rQh07752; Thu, 4 Mar 2004 03:53:27 +0200 (EET) Message-ID: <40468C15.90201@nokia.com> Date: Thu, 04 Mar 2004 03:53:25 +0200 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: ext Pete McCann Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: AAA URI syntax References: <052E0C61B69C3741AFA5FE88ACC775A612238F@esebe023.ntc.nokia.com> <16453.49415.239198.635463@gargle.gargle.HOWL> <4045C527.5000108@nokia.com> <16453.54986.942198.437260@gargle.gargle.HOWL> In-Reply-To: <16453.54986.942198.437260@gargle.gargle.HOWL> 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 Pete: Thanks for pointing out to the document. I believe this document is designed by the W3C with the idea in mind of W3C applications. I am not really convinced about your proposal. IMAP, HTTP and FTP have the need to express hierarchical resources. For instance, IMAP needs to specify a mailbox of a particular use, HTTP a web page, FTP a file. I haven't found this requirement in AAA protocols. As far as I know, Diameter and Radius do not have the requirement to express a hierarchical resource. We just need to express the host name. There are plenty of URIs out there that follow this approach, I mentioned SIP, there is also h.323, tel, mailto. None of them need to express a hierarchical resource, so they use the "anything goes" model. Are those wrong? I don't think so. Can't they be parsed? I don't think so. I am therefore advocating for making the AAA URI to follow a model that fits the requirements. As we don't have the requirement to point to a hierarchical resource, I believe we should follow the opaque ("anything goes") model. Miguel ext Pete McCann wrote: > > That would at least be legal syntax, but there are advantages to > re-using some of the hierarchical URI syntax. See: > > http://www.w3.org/DesignIssues/ModelConsequences > > Adding a '/' to the end of our URI before the parameters doesn't seem > like a big deal. IMAP URIs seem to work this way; see RFC 2192: > > 4. IMAP server > > An IMAP URL referring to an IMAP server has the following form: > > imap:/// > > A program interpreting this URL would issue the standard set of > commands it uses to present a view of the contents of an IMAP > server. This is likely to be semanticly equivalent to one of the > following URLs: > > imap:///;TYPE=LIST > imap:///;TYPE=LSUB > > The program interpreting this URL SHOULD use the LSUB form if it > supports mailbox subscriptions. > > (thanks again to Adam Costello for pointing these references out to me) > > -Pete > > Miguel Garcia writes: > > Hi: > > > > As I understand from RFC 2396, those URIs that contain the slashes "//" > > include a path that points to a resource stored in a hierarchical > > structure, such us a file system. Obvious examples are http and ftp > > resources. Having said that, I don't believe a AAA URI falls into this > > category. > > > > The other big category of URIs belong to those that do not point to a > > hierarchical resource. Example of these URIs are SIP and mailto: URIs. I > > believe the AAA URI belongs to this category. An example of what I > > believe it should be a correct AAA URI is: > > > > aaa:server.example.com > > > > I know that my words suggest to do a big change to the AAA URI defined > > in RFC 3588, but we should make an effort to make things right. > > > > /Miguel > > > > ext Pete McCann wrote: > > > > > > > > Hi, Pasi, > > > > > > Where do you read that in 2396? I see the following text in the > > > abstract: > > > > > > This document defines a grammar that is a superset of all valid URI, > > > such that an implementation can parse the common components of a URI > > > reference without knowing the scheme-specific requirements of every > > > possible identifier type. > > > > > > I interpret that to mean that all valid URI must fit the grammar, > > > i.e., the set of all strings defined by the grammar is strictly larger > > > than the set of all valid URI. > > > > > > The URI definition in RFC 3588 does not fit the grammar. > > > > > > Our URI begins with "aaa://", so we are not eligible to parse it as > > > ":". "" cannot begin with a "/" > > > > > > -Pete > > > > > > Pasi.Eronen@nokia.com writes: > > > > Hi, > > > > > > > > RFC 2396 also says that only some URI schemes use this > > > > "generic URI" syntax; each scheme can decide whether > > > > it wants to use it or not. If the AAA URI scheme > > > > does not use the "generic URI" syntax, we can have > > > > whatever we want right of the "aaa:" part... > > > > > > > > So IMHO the current syntax is OK from this point. > > > > > > > > BR, > > > > Pasi > > > > > > > > > -----Original Message----- > > > > > From: owner-aaa-wg@merit.edu > > > > > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > > > > ext Pete McCann > > > > > Sent: Tuesday, March 02, 2004 9:00 AM > > > > > To: aaa-wg@merit.edu > > > > > Subject: [AAA-WG]: AAA URI syntax > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Following up to the point I raised at the meeting today: > > > > > > > > > > According to my reading of RFC 2396 (Uniform Resource Identifiers > > > > > (URI): Generic Syntax), the syntax given for the AAA URI in RFC 3588 > > > > > is broken. > > > > > > > > > > See Appendix A of 2396. Because we are using a //, the thing after > > > > > the slash is a "hier_part". In a "hier_part", we have an "authority" > > > > > followed by an optional "abs_path". The only way to get a ";" "path" > > > > > is to use an "abs_path", and an "abs_path" must begin with a /. In > > > > > the examples given in RFC 3588, there is no / before the parameters. > > > > > > > > > > So, there seem to be two options here. We could remove the // from > > > > > our URI syntax, making it into scheme:opaque_part. We can format the > > > > > opaque_part however we would like. Alternatively, we could add a / > > > > > after the authority name before we add parameters. This would mean: > > > > > > > > > > aaa://host.example.com/;transport=tcp > > > > > > > > > > This would be the least amount of change; however, it looks a > > > > > little ugly. > > > > > > > > > > -Pete > > > > > > > > > > p.s. Thanks to Adam Costello for first noticing this and > > > > > pointing it out. > > > > > > > > > > -Pete > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Wed Mar 3 21:18: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 VAA16674 for ; Wed, 3 Mar 2004 21:18:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F2496912CA; Wed, 3 Mar 2004 21:17:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B99BA912CB; Wed, 3 Mar 2004 21:17:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 158E1912CA for ; Wed, 3 Mar 2004 21:17:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id EB37A5DF88; Wed, 3 Mar 2004 21:17:49 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by segue.merit.edu (Postfix) with ESMTP id 79AEF5DF76 for ; Wed, 3 Mar 2004 21:17:49 -0500 (EST) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i242HVc24299; Wed, 3 Mar 2004 20:17:31 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i242HSS08148; Wed, 3 Mar 2004 20:17:28 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HU1504-00019S-00; Wed, 03 Mar 2004 21:16:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16454.37267.118198.651134@gargle.gargle.HOWL> Date: Wed, 3 Mar 2004 20:16:51 -0600 From: Pete McCann To: Miguel Garcia Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: AAA URI syntax In-Reply-To: <40468C15.90201@nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A612238F@esebe023.ntc.nokia.com> <16453.49415.239198.635463@gargle.gargle.HOWL> <4045C527.5000108@nokia.com> <16453.54986.942198.437260@gargle.gargle.HOWL> <40468C15.90201@nokia.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Miguel, It's ok with me if we adopt the opaque syntax, as long as we drop the // and conform to the grammar. However, I would just point out one last thing to think about: in the aaa:// case, we are definitely talking about a host name (or IP address) after the //. In the other examples you pointed out (sip, tel, mailto) I think we always have something else more akin to an NAI or an e-mail address after the ":". So, there might be some value in keeping the // so that tools can parse the following string as a host name, in which case we need the trailing "/". -Pete Miguel Garcia writes: > Hi Pete: > > Thanks for pointing out to the document. I believe this document is > designed by the W3C with the idea in mind of W3C applications. > > I am not really convinced about your proposal. IMAP, HTTP and FTP have > the need to express hierarchical resources. For instance, IMAP needs to > specify a mailbox of a particular use, HTTP a web page, FTP a file. > > I haven't found this requirement in AAA protocols. As far as I know, > Diameter and Radius do not have the requirement to express a > hierarchical resource. We just need to express the host name. > > There are plenty of URIs out there that follow this approach, I > mentioned SIP, there is also h.323, tel, mailto. None of them need to > express a hierarchical resource, so they use the "anything goes" model. > Are those wrong? I don't think so. Can't they be parsed? I don't think so. > > I am therefore advocating for making the AAA URI to follow a model that > fits the requirements. As we don't have the requirement to point to a > hierarchical resource, I believe we should follow the opaque ("anything > goes") model. > > Miguel > > ext Pete McCann wrote: > > > > > That would at least be legal syntax, but there are advantages to > > re-using some of the hierarchical URI syntax. See: > > > > http://www.w3.org/DesignIssues/ModelConsequences > > > > Adding a '/' to the end of our URI before the parameters doesn't seem > > like a big deal. IMAP URIs seem to work this way; see RFC 2192: > > > > 4. IMAP server > > > > An IMAP URL referring to an IMAP server has the following form: > > > > imap:/// > > > > A program interpreting this URL would issue the standard set of > > commands it uses to present a view of the contents of an IMAP > > server. This is likely to be semanticly equivalent to one of the > > following URLs: > > > > imap:///;TYPE=LIST > > imap:///;TYPE=LSUB > > > > The program interpreting this URL SHOULD use the LSUB form if it > > supports mailbox subscriptions. > > > > (thanks again to Adam Costello for pointing these references out to me) > > > > -Pete > > > > Miguel Garcia writes: > > > Hi: > > > > > > As I understand from RFC 2396, those URIs that contain the slashes "//" > > > include a path that points to a resource stored in a hierarchical > > > structure, such us a file system. Obvious examples are http and ftp > > > resources. Having said that, I don't believe a AAA URI falls into this > > > category. > > > > > > The other big category of URIs belong to those that do not point to a > > > hierarchical resource. Example of these URIs are SIP and mailto: URIs. I > > > believe the AAA URI belongs to this category. An example of what I > > > believe it should be a correct AAA URI is: > > > > > > aaa:server.example.com > > > > > > I know that my words suggest to do a big change to the AAA URI defined > > > in RFC 3588, but we should make an effort to make things right. > > > > > > /Miguel > > > > > > ext Pete McCann wrote: > > > > > > > > > > > Hi, Pasi, > > > > > > > > Where do you read that in 2396? I see the following text in the > > > > abstract: > > > > > > > > This document defines a grammar that is a superset of all valid URI, > > > > such that an implementation can parse the common components of a URI > > > > reference without knowing the scheme-specific requirements of every > > > > possible identifier type. > > > > > > > > I interpret that to mean that all valid URI must fit the grammar, > > > > i.e., the set of all strings defined by the grammar is strictly larger > > > > than the set of all valid URI. > > > > > > > > The URI definition in RFC 3588 does not fit the grammar. > > > > > > > > Our URI begins with "aaa://", so we are not eligible to parse it as > > > > ":". "" cannot begin with a "/" > > > > > > > > -Pete > > > > > > > > Pasi.Eronen@nokia.com writes: > > > > > Hi, > > > > > > > > > > RFC 2396 also says that only some URI schemes use this > > > > > "generic URI" syntax; each scheme can decide whether > > > > > it wants to use it or not. If the AAA URI scheme > > > > > does not use the "generic URI" syntax, we can have > > > > > whatever we want right of the "aaa:" part... > > > > > > > > > > So IMHO the current syntax is OK from this point. > > > > > > > > > > BR, > > > > > Pasi > > > > > > > > > > > -----Original Message----- > > > > > > From: owner-aaa-wg@merit.edu > > > > > > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > > > > > ext Pete McCann > > > > > > Sent: Tuesday, March 02, 2004 9:00 AM > > > > > > To: aaa-wg@merit.edu > > > > > > Subject: [AAA-WG]: AAA URI syntax > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > Following up to the point I raised at the meeting today: > > > > > > > > > > > > According to my reading of RFC 2396 (Uniform Resource Identifiers > > > > > > (URI): Generic Syntax), the syntax given for the AAA URI in RFC 3588 > > > > > > is broken. > > > > > > > > > > > > See Appendix A of 2396. Because we are using a //, the thing after > > > > > > the slash is a "hier_part". In a "hier_part", we have an "authority" > > > > > > followed by an optional "abs_path". The only way to get a ";" "path" > > > > > > is to use an "abs_path", and an "abs_path" must begin with a /. In > > > > > > the examples given in RFC 3588, there is no / before the parameters. > > > > > > > > > > > > So, there seem to be two options here. We could remove the // from > > > > > > our URI syntax, making it into scheme:opaque_part. We can format the > > > > > > opaque_part however we would like. Alternatively, we could add a / > > > > > > after the authority name before we add parameters. This would mean: > > > > > > > > > > > > aaa://host.example.com/;transport=tcp > > > > > > > > > > > > This would be the least amount of change; however, it looks a > > > > > > little ugly. > > > > > > > > > > > > -Pete > > > > > > > > > > > > p.s. Thanks to Adam Costello for first noticing this and > > > > > > pointing it out. > > > > > > > > > > > > -Pete From owner-aaa-wg@merit.edu Wed Mar 3 21:24: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 VAA17143 for ; Wed, 3 Mar 2004 21:24:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 89C4D912CB; Wed, 3 Mar 2004 21:24:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5927D912CF; Wed, 3 Mar 2004 21:24:15 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E01BF912CB for ; Wed, 3 Mar 2004 21:24:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id B2C7E5DFD8; Wed, 3 Mar 2004 21:24:13 -0500 (EST) 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 AB45C5DFDF for ; Wed, 3 Mar 2004 21:24:12 -0500 (EST) Received: from nokia.com (esnira-pool201395.nokia.com [10.162.13.95]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i242NDh03353; Thu, 4 Mar 2004 04:23:14 +0200 (EET) Message-ID: <4046930F.1080001@nokia.com> Date: Thu, 04 Mar 2004 04:23:11 +0200 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: ext Pete McCann Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: AAA URI syntax References: <052E0C61B69C3741AFA5FE88ACC775A612238F@esebe023.ntc.nokia.com> <16453.49415.239198.635463@gargle.gargle.HOWL> <4045C527.5000108@nokia.com> <16453.54986.942198.437260@gargle.gargle.HOWL> <40468C15.90201@nokia.com> <16454.37267.118198.651134@gargle.gargle.HOWL> In-Reply-To: <16454.37267.118198.651134@gargle.gargle.HOWL> 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 Not in the TEL URL (RFC 2806, there is a revision coming as an Internet draft). Example: tel:+1-555-2222-3333 /Miguel ext Pete McCann wrote: > > Hi, Miguel, > > It's ok with me if we adopt the opaque syntax, as long as we drop the > // and conform to the grammar. However, I would just point out one > last thing to think about: in the aaa:// case, we are definitely > talking about a host name (or IP address) after the //. In the other > examples you pointed out (sip, tel, mailto) I think we always have > something else more akin to an NAI or an e-mail address after the > ":". So, there might be some value in keeping the // so that tools > can parse the following string as a host name, in which case we need > the trailing "/". > > -Pete > > Miguel Garcia writes: > > Hi Pete: > > > > Thanks for pointing out to the document. I believe this document is > > designed by the W3C with the idea in mind of W3C applications. > > > > I am not really convinced about your proposal. IMAP, HTTP and FTP have > > the need to express hierarchical resources. For instance, IMAP needs to > > specify a mailbox of a particular use, HTTP a web page, FTP a file. > > > > I haven't found this requirement in AAA protocols. As far as I know, > > Diameter and Radius do not have the requirement to express a > > hierarchical resource. We just need to express the host name. > > > > There are plenty of URIs out there that follow this approach, I > > mentioned SIP, there is also h.323, tel, mailto. None of them need to > > express a hierarchical resource, so they use the "anything goes" model. > > Are those wrong? I don't think so. Can't they be parsed? I don't think so. > > > > I am therefore advocating for making the AAA URI to follow a model that > > fits the requirements. As we don't have the requirement to point to a > > hierarchical resource, I believe we should follow the opaque ("anything > > goes") model. > > > > Miguel > > > > ext Pete McCann wrote: > > > > > > > > That would at least be legal syntax, but there are advantages to > > > re-using some of the hierarchical URI syntax. See: > > > > > > http://www.w3.org/DesignIssues/ModelConsequences > > > > > > Adding a '/' to the end of our URI before the parameters doesn't seem > > > like a big deal. IMAP URIs seem to work this way; see RFC 2192: > > > > > > 4. IMAP server > > > > > > An IMAP URL referring to an IMAP server has the following form: > > > > > > imap:/// > > > > > > A program interpreting this URL would issue the standard set of > > > commands it uses to present a view of the contents of an IMAP > > > server. This is likely to be semanticly equivalent to one of the > > > following URLs: > > > > > > imap:///;TYPE=LIST > > > imap:///;TYPE=LSUB > > > > > > The program interpreting this URL SHOULD use the LSUB form if it > > > supports mailbox subscriptions. > > > > > > (thanks again to Adam Costello for pointing these references out to me) > > > > > > -Pete > > > > > > Miguel Garcia writes: > > > > Hi: > > > > > > > > As I understand from RFC 2396, those URIs that contain the slashes "//" > > > > include a path that points to a resource stored in a hierarchical > > > > structure, such us a file system. Obvious examples are http and ftp > > > > resources. Having said that, I don't believe a AAA URI falls into this > > > > category. > > > > > > > > The other big category of URIs belong to those that do not point to a > > > > hierarchical resource. Example of these URIs are SIP and mailto: URIs. I > > > > believe the AAA URI belongs to this category. An example of what I > > > > believe it should be a correct AAA URI is: > > > > > > > > aaa:server.example.com > > > > > > > > I know that my words suggest to do a big change to the AAA URI defined > > > > in RFC 3588, but we should make an effort to make things right. > > > > > > > > /Miguel > > > > > > > > ext Pete McCann wrote: > > > > > > > > > > > > > > Hi, Pasi, > > > > > > > > > > Where do you read that in 2396? I see the following text in the > > > > > abstract: > > > > > > > > > > This document defines a grammar that is a superset of all valid URI, > > > > > such that an implementation can parse the common components of a URI > > > > > reference without knowing the scheme-specific requirements of every > > > > > possible identifier type. > > > > > > > > > > I interpret that to mean that all valid URI must fit the grammar, > > > > > i.e., the set of all strings defined by the grammar is strictly larger > > > > > than the set of all valid URI. > > > > > > > > > > The URI definition in RFC 3588 does not fit the grammar. > > > > > > > > > > Our URI begins with "aaa://", so we are not eligible to parse it as > > > > > ":". "" cannot begin with a "/" > > > > > > > > > > -Pete > > > > > > > > > > Pasi.Eronen@nokia.com writes: > > > > > > Hi, > > > > > > > > > > > > RFC 2396 also says that only some URI schemes use this > > > > > > "generic URI" syntax; each scheme can decide whether > > > > > > it wants to use it or not. If the AAA URI scheme > > > > > > does not use the "generic URI" syntax, we can have > > > > > > whatever we want right of the "aaa:" part... > > > > > > > > > > > > So IMHO the current syntax is OK from this point. > > > > > > > > > > > > BR, > > > > > > Pasi > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: owner-aaa-wg@merit.edu > > > > > > > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > > > > > > ext Pete McCann > > > > > > > Sent: Tuesday, March 02, 2004 9:00 AM > > > > > > > To: aaa-wg@merit.edu > > > > > > > Subject: [AAA-WG]: AAA URI syntax > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > Following up to the point I raised at the meeting today: > > > > > > > > > > > > > > According to my reading of RFC 2396 (Uniform Resource Identifiers > > > > > > > (URI): Generic Syntax), the syntax given for the AAA URI in RFC 3588 > > > > > > > is broken. > > > > > > > > > > > > > > See Appendix A of 2396. Because we are using a //, the thing after > > > > > > > the slash is a "hier_part". In a "hier_part", we have an "authority" > > > > > > > followed by an optional "abs_path". The only way to get a ";" "path" > > > > > > > is to use an "abs_path", and an "abs_path" must begin with a /. In > > > > > > > the examples given in RFC 3588, there is no / before the parameters. > > > > > > > > > > > > > > So, there seem to be two options here. We could remove the // from > > > > > > > our URI syntax, making it into scheme:opaque_part. We can format the > > > > > > > opaque_part however we would like. Alternatively, we could add a / > > > > > > > after the authority name before we add parameters. This would mean: > > > > > > > > > > > > > > aaa://host.example.com/;transport=tcp > > > > > > > > > > > > > > This would be the least amount of change; however, it looks a > > > > > > > little ugly. > > > > > > > > > > > > > > -Pete > > > > > > > > > > > > > > p.s. Thanks to Adam Costello for first noticing this and > > > > > > > pointing it out. > > > > > > > > > > > > > > -Pete > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Wed Mar 3 22:51:50 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 WAA23218 for ; Wed, 3 Mar 2004 22:51:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D1463912CF; Wed, 3 Mar 2004 22:51:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0AF7912D1; Wed, 3 Mar 2004 22:51:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 15071912CF for ; Wed, 3 Mar 2004 22:51:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0142E5E08B; Wed, 3 Mar 2004 22:51:35 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by segue.merit.edu (Postfix) with ESMTP id B8A8B5E082 for ; Wed, 3 Mar 2004 22:51:34 -0500 (EST) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i243pPi03166; Wed, 3 Mar 2004 21:51:25 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i243pMS26859; Wed, 3 Mar 2004 21:51:22 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HU19CM-0001JW-00; Wed, 03 Mar 2004 22:50:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16454.42898.576198.952852@gargle.gargle.HOWL> Date: Wed, 3 Mar 2004 21:50:42 -0600 From: Pete McCann To: Miguel Garcia Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: AAA URI syntax In-Reply-To: <4046930F.1080001@nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A612238F@esebe023.ntc.nokia.com> <16453.49415.239198.635463@gargle.gargle.HOWL> <4045C527.5000108@nokia.com> <16453.54986.942198.437260@gargle.gargle.HOWL> <40468C15.90201@nokia.com> <16454.37267.118198.651134@gargle.gargle.HOWL> <4046930F.1080001@nokia.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Right, it's not an NAI or an e-mail address, but a phone number. My point was that these other examples do not have host names following the ":". Our aaa: scheme does. -Pete Miguel Garcia writes: > Not in the TEL URL (RFC 2806, there is a revision coming as an Internet > draft). Example: tel:+1-555-2222-3333 > > /Miguel > > ext Pete McCann wrote: > > > > > Hi, Miguel, > > > > It's ok with me if we adopt the opaque syntax, as long as we drop the > > // and conform to the grammar. However, I would just point out one > > last thing to think about: in the aaa:// case, we are definitely > > talking about a host name (or IP address) after the //. In the other > > examples you pointed out (sip, tel, mailto) I think we always have > > something else more akin to an NAI or an e-mail address after the > > ":". So, there might be some value in keeping the // so that tools > > can parse the following string as a host name, in which case we need > > the trailing "/". > > > > -Pete > > > > Miguel Garcia writes: > > > Hi Pete: > > > > > > Thanks for pointing out to the document. I believe this document is > > > designed by the W3C with the idea in mind of W3C applications. > > > > > > I am not really convinced about your proposal. IMAP, HTTP and FTP have > > > the need to express hierarchical resources. For instance, IMAP needs to > > > specify a mailbox of a particular use, HTTP a web page, FTP a file. > > > > > > I haven't found this requirement in AAA protocols. As far as I know, > > > Diameter and Radius do not have the requirement to express a > > > hierarchical resource. We just need to express the host name. > > > > > > There are plenty of URIs out there that follow this approach, I > > > mentioned SIP, there is also h.323, tel, mailto. None of them need to > > > express a hierarchical resource, so they use the "anything goes" model. > > > Are those wrong? I don't think so. Can't they be parsed? I don't think so. > > > > > > I am therefore advocating for making the AAA URI to follow a model that > > > fits the requirements. As we don't have the requirement to point to a > > > hierarchical resource, I believe we should follow the opaque ("anything > > > goes") model. > > > > > > Miguel > > > > > > ext Pete McCann wrote: > > > > > > > > > > > That would at least be legal syntax, but there are advantages to > > > > re-using some of the hierarchical URI syntax. See: > > > > > > > > http://www.w3.org/DesignIssues/ModelConsequences > > > > > > > > Adding a '/' to the end of our URI before the parameters doesn't seem > > > > like a big deal. IMAP URIs seem to work this way; see RFC 2192: > > > > > > > > 4. IMAP server > > > > > > > > An IMAP URL referring to an IMAP server has the following form: > > > > > > > > imap:/// > > > > > > > > A program interpreting this URL would issue the standard set of > > > > commands it uses to present a view of the contents of an IMAP > > > > server. This is likely to be semanticly equivalent to one of the > > > > following URLs: > > > > > > > > imap:///;TYPE=LIST > > > > imap:///;TYPE=LSUB > > > > > > > > The program interpreting this URL SHOULD use the LSUB form if it > > > > supports mailbox subscriptions. > > > > > > > > (thanks again to Adam Costello for pointing these references out to me) > > > > > > > > -Pete > > > > > > > > Miguel Garcia writes: > > > > > Hi: > > > > > > > > > > As I understand from RFC 2396, those URIs that contain the slashes "//" > > > > > include a path that points to a resource stored in a hierarchical > > > > > structure, such us a file system. Obvious examples are http and ftp > > > > > resources. Having said that, I don't believe a AAA URI falls into this > > > > > category. > > > > > > > > > > The other big category of URIs belong to those that do not point to a > > > > > hierarchical resource. Example of these URIs are SIP and mailto: URIs. I > > > > > believe the AAA URI belongs to this category. An example of what I > > > > > believe it should be a correct AAA URI is: > > > > > > > > > > aaa:server.example.com > > > > > > > > > > I know that my words suggest to do a big change to the AAA URI defined > > > > > in RFC 3588, but we should make an effort to make things right. > > > > > > > > > > /Miguel > > > > > > > > > > ext Pete McCann wrote: > > > > > > > > > > > > > > > > > Hi, Pasi, > > > > > > > > > > > > Where do you read that in 2396? I see the following text in the > > > > > > abstract: > > > > > > > > > > > > This document defines a grammar that is a superset of all valid URI, > > > > > > such that an implementation can parse the common components of a URI > > > > > > reference without knowing the scheme-specific requirements of every > > > > > > possible identifier type. > > > > > > > > > > > > I interpret that to mean that all valid URI must fit the grammar, > > > > > > i.e., the set of all strings defined by the grammar is strictly larger > > > > > > than the set of all valid URI. > > > > > > > > > > > > The URI definition in RFC 3588 does not fit the grammar. > > > > > > > > > > > > Our URI begins with "aaa://", so we are not eligible to parse it as > > > > > > ":". "" cannot begin with a "/" > > > > > > > > > > > > -Pete > > > > > > > > > > > > Pasi.Eronen@nokia.com writes: > > > > > > > Hi, > > > > > > > > > > > > > > RFC 2396 also says that only some URI schemes use this > > > > > > > "generic URI" syntax; each scheme can decide whether > > > > > > > it wants to use it or not. If the AAA URI scheme > > > > > > > does not use the "generic URI" syntax, we can have > > > > > > > whatever we want right of the "aaa:" part... > > > > > > > > > > > > > > So IMHO the current syntax is OK from this point. > > > > > > > > > > > > > > BR, > > > > > > > Pasi > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: owner-aaa-wg@merit.edu > > > > > > > > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > > > > > > > ext Pete McCann > > > > > > > > Sent: Tuesday, March 02, 2004 9:00 AM > > > > > > > > To: aaa-wg@merit.edu > > > > > > > > Subject: [AAA-WG]: AAA URI syntax > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > Following up to the point I raised at the meeting today: > > > > > > > > > > > > > > > > According to my reading of RFC 2396 (Uniform Resource Identifiers > > > > > > > > (URI): Generic Syntax), the syntax given for the AAA URI in RFC 3588 > > > > > > > > is broken. > > > > > > > > > > > > > > > > See Appendix A of 2396. Because we are using a //, the thing after > > > > > > > > the slash is a "hier_part". In a "hier_part", we have an "authority" > > > > > > > > followed by an optional "abs_path". The only way to get a ";" "path" > > > > > > > > is to use an "abs_path", and an "abs_path" must begin with a /. In > > > > > > > > the examples given in RFC 3588, there is no / before the parameters. > > > > > > > > > > > > > > > > So, there seem to be two options here. We could remove the // from > > > > > > > > our URI syntax, making it into scheme:opaque_part. We can format the > > > > > > > > opaque_part however we would like. Alternatively, we could add a / > > > > > > > > after the authority name before we add parameters. This would mean: > > > > > > > > > > > > > > > > aaa://host.example.com/;transport=tcp > > > > > > > > > > > > > > > > This would be the least amount of change; however, it looks a > > > > > > > > little ugly. > > > > > > > > > > > > > > > > -Pete > > > > > > > > > > > > > > > > p.s. Thanks to Adam Costello for first noticing this and > > > > > > > > pointing it out. > > > > > > > > > > > > > > > > -Pete From owner-aaa-wg@merit.edu Wed Mar 3 22:59: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 WAA23577 for ; Wed, 3 Mar 2004 22:59:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BC29D912D0; Wed, 3 Mar 2004 22:58:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B8D2912D1; Wed, 3 Mar 2004 22:58:47 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 42E63912D0 for ; Wed, 3 Mar 2004 22:58:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 28F435E0EB; Wed, 3 Mar 2004 22:58:46 -0500 (EST) 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 51E5E5E09D for ; Wed, 3 Mar 2004 22:58:45 -0500 (EST) Received: from nokia.com (esnira-pool2013200.nokia.com [10.162.13.200]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i243w6h18176; Thu, 4 Mar 2004 05:58:06 +0200 (EET) Message-ID: <4046A94B.4040105@nokia.com> Date: Thu, 04 Mar 2004 05:58:03 +0200 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: ext Pete McCann Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: AAA URI syntax References: <052E0C61B69C3741AFA5FE88ACC775A612238F@esebe023.ntc.nokia.com> <16453.49415.239198.635463@gargle.gargle.HOWL> <4045C527.5000108@nokia.com> <16453.54986.942198.437260@gargle.gargle.HOWL> <40468C15.90201@nokia.com> <16454.37267.118198.651134@gargle.gargle.HOWL> <4046930F.1080001@nokia.com> <16454.42898.576198.952852@gargle.gargle.HOWL> In-Reply-To: <16454.42898.576198.952852@gargle.gargle.HOWL> 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 We have. A SIP URI can contain either a domain name (example.com) or a host name (host.example.com). For instance, the following URIs are valid SIP URIs: sip:user@example.com sip:server.example.com I see that the second example has a lot of similarities with the aaa uri. Miguel ext Pete McCann wrote: > > Right, it's not an NAI or an e-mail address, but a phone number. > > My point was that these other examples do not have host names > following the ":". Our aaa: scheme does. > > -Pete > > Miguel Garcia writes: > > Not in the TEL URL (RFC 2806, there is a revision coming as an Internet > > draft). Example: tel:+1-555-2222-3333 > > > > /Miguel > > > > ext Pete McCann wrote: > > > > > > > > Hi, Miguel, > > > > > > It's ok with me if we adopt the opaque syntax, as long as we drop the > > > // and conform to the grammar. However, I would just point out one > > > last thing to think about: in the aaa:// case, we are definitely > > > talking about a host name (or IP address) after the //. In the other > > > examples you pointed out (sip, tel, mailto) I think we always have > > > something else more akin to an NAI or an e-mail address after the > > > ":". So, there might be some value in keeping the // so that tools > > > can parse the following string as a host name, in which case we need > > > the trailing "/". > > > > > > -Pete > > > > > > Miguel Garcia writes: > > > > Hi Pete: > > > > > > > > Thanks for pointing out to the document. I believe this document is > > > > designed by the W3C with the idea in mind of W3C applications. > > > > > > > > I am not really convinced about your proposal. IMAP, HTTP and FTP have > > > > the need to express hierarchical resources. For instance, IMAP needs to > > > > specify a mailbox of a particular use, HTTP a web page, FTP a file. > > > > > > > > I haven't found this requirement in AAA protocols. As far as I know, > > > > Diameter and Radius do not have the requirement to express a > > > > hierarchical resource. We just need to express the host name. > > > > > > > > There are plenty of URIs out there that follow this approach, I > > > > mentioned SIP, there is also h.323, tel, mailto. None of them need to > > > > express a hierarchical resource, so they use the "anything goes" model. > > > > Are those wrong? I don't think so. Can't they be parsed? I don't think so. > > > > > > > > I am therefore advocating for making the AAA URI to follow a model that > > > > fits the requirements. As we don't have the requirement to point to a > > > > hierarchical resource, I believe we should follow the opaque ("anything > > > > goes") model. > > > > > > > > Miguel > > > > > > > > ext Pete McCann wrote: > > > > > > > > > > > > > > That would at least be legal syntax, but there are advantages to > > > > > re-using some of the hierarchical URI syntax. See: > > > > > > > > > > http://www.w3.org/DesignIssues/ModelConsequences > > > > > > > > > > Adding a '/' to the end of our URI before the parameters doesn't seem > > > > > like a big deal. IMAP URIs seem to work this way; see RFC 2192: > > > > > > > > > > 4. IMAP server > > > > > > > > > > An IMAP URL referring to an IMAP server has the following form: > > > > > > > > > > imap:/// > > > > > > > > > > A program interpreting this URL would issue the standard set of > > > > > commands it uses to present a view of the contents of an IMAP > > > > > server. This is likely to be semanticly equivalent to one of the > > > > > following URLs: > > > > > > > > > > imap:///;TYPE=LIST > > > > > imap:///;TYPE=LSUB > > > > > > > > > > The program interpreting this URL SHOULD use the LSUB form if it > > > > > supports mailbox subscriptions. > > > > > > > > > > (thanks again to Adam Costello for pointing these references out to me) > > > > > > > > > > -Pete > > > > > > > > > > Miguel Garcia writes: > > > > > > Hi: > > > > > > > > > > > > As I understand from RFC 2396, those URIs that contain the slashes "//" > > > > > > include a path that points to a resource stored in a hierarchical > > > > > > structure, such us a file system. Obvious examples are http and ftp > > > > > > resources. Having said that, I don't believe a AAA URI falls into this > > > > > > category. > > > > > > > > > > > > The other big category of URIs belong to those that do not point to a > > > > > > hierarchical resource. Example of these URIs are SIP and mailto: URIs. I > > > > > > believe the AAA URI belongs to this category. An example of what I > > > > > > believe it should be a correct AAA URI is: > > > > > > > > > > > > aaa:server.example.com > > > > > > > > > > > > I know that my words suggest to do a big change to the AAA URI defined > > > > > > in RFC 3588, but we should make an effort to make things right. > > > > > > > > > > > > /Miguel > > > > > > > > > > > > ext Pete McCann wrote: > > > > > > > > > > > > > > > > > > > > Hi, Pasi, > > > > > > > > > > > > > > Where do you read that in 2396? I see the following text in the > > > > > > > abstract: > > > > > > > > > > > > > > This document defines a grammar that is a superset of all valid URI, > > > > > > > such that an implementation can parse the common components of a URI > > > > > > > reference without knowing the scheme-specific requirements of every > > > > > > > possible identifier type. > > > > > > > > > > > > > > I interpret that to mean that all valid URI must fit the grammar, > > > > > > > i.e., the set of all strings defined by the grammar is strictly larger > > > > > > > than the set of all valid URI. > > > > > > > > > > > > > > The URI definition in RFC 3588 does not fit the grammar. > > > > > > > > > > > > > > Our URI begins with "aaa://", so we are not eligible to parse it as > > > > > > > ":". "" cannot begin with a "/" > > > > > > > > > > > > > > -Pete > > > > > > > > > > > > > > Pasi.Eronen@nokia.com writes: > > > > > > > > Hi, > > > > > > > > > > > > > > > > RFC 2396 also says that only some URI schemes use this > > > > > > > > "generic URI" syntax; each scheme can decide whether > > > > > > > > it wants to use it or not. If the AAA URI scheme > > > > > > > > does not use the "generic URI" syntax, we can have > > > > > > > > whatever we want right of the "aaa:" part... > > > > > > > > > > > > > > > > So IMHO the current syntax is OK from this point. > > > > > > > > > > > > > > > > BR, > > > > > > > > Pasi > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: owner-aaa-wg@merit.edu > > > > > > > > > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > > > > > > > > ext Pete McCann > > > > > > > > > Sent: Tuesday, March 02, 2004 9:00 AM > > > > > > > > > To: aaa-wg@merit.edu > > > > > > > > > Subject: [AAA-WG]: AAA URI syntax > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > Following up to the point I raised at the meeting today: > > > > > > > > > > > > > > > > > > According to my reading of RFC 2396 (Uniform Resource Identifiers > > > > > > > > > (URI): Generic Syntax), the syntax given for the AAA URI in RFC 3588 > > > > > > > > > is broken. > > > > > > > > > > > > > > > > > > See Appendix A of 2396. Because we are using a //, the thing after > > > > > > > > > the slash is a "hier_part". In a "hier_part", we have an "authority" > > > > > > > > > followed by an optional "abs_path". The only way to get a ";" "path" > > > > > > > > > is to use an "abs_path", and an "abs_path" must begin with a /. In > > > > > > > > > the examples given in RFC 3588, there is no / before the parameters. > > > > > > > > > > > > > > > > > > So, there seem to be two options here. We could remove the // from > > > > > > > > > our URI syntax, making it into scheme:opaque_part. We can format the > > > > > > > > > opaque_part however we would like. Alternatively, we could add a / > > > > > > > > > after the authority name before we add parameters. This would mean: > > > > > > > > > > > > > > > > > > aaa://host.example.com/;transport=tcp > > > > > > > > > > > > > > > > > > This would be the least amount of change; however, it looks a > > > > > > > > > little ugly. > > > > > > > > > > > > > > > > > > -Pete > > > > > > > > > > > > > > > > > > p.s. Thanks to Adam Costello for first noticing this and > > > > > > > > > pointing it out. > > > > > > > > > > > > > > > > > > -Pete > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Thu Mar 4 00:08: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 AAA28621 for ; Thu, 4 Mar 2004 00:08:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 52FBB912D9; Thu, 4 Mar 2004 00:08:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3EDC912D5; Thu, 4 Mar 2004 00:08:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D5329912D8 for ; Thu, 4 Mar 2004 00:08:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id B72335E135; Thu, 4 Mar 2004 00:08:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from natsmtp01.rzone.de (natsmtp01.rzone.de [81.169.145.166]) by segue.merit.edu (Postfix) with ESMTP id 255195E134 for ; Thu, 4 Mar 2004 00:08:08 -0500 (EST) Received: from RocknRoll (RocknRoll.wireless.ietf59.or.kr [218.37.228.124]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i245824u017717 for ; Thu, 4 Mar 2004 06:08:03 +0100 (MET) From: "Harry Behrens" To: Subject: [AAA-WG]: Draft re.: SIP-based roaming Date: Thu, 4 Mar 2004 06:09:47 +0100 Message-ID: <002701c401a6$ebab0870$e71f10ac@RocknRoll> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0028_01C401AF.4D6F7070" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C401AF.4D6F7070 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The following draft has been submitted to the SIPPING WG. As it is close to AAA in nature, I figure I would greatly appreciate input from this group. Pls. note that the attached draft (--01.txt) is not yet on the IETF website due to the cutoff date prior to the Seoul meeting. Abstract: This draft describes an authentication mechanism which can be used to enable users of VoIP to globally roam between any number of ITSPs (Internet Telephony Service Providers) without needing to have a prior customer or billing relationship with all of them. This enables profiles and one-line-billing. Providers using this authentication mechanism do neither need full-mesh trust relationships or roaming agreements with every other possible provider nor do they need to rely on a centralized brokerage entity to process calls. The Home Network (HN), which handles all AAA for a user attempting to use an ITSP's service is determined through a unique identifier submitted by the user. This Network Access Identifier [RFC2486] contains information about the trust domain or trust realm the user belongs to. Based on a simple discovery mechanism a provider can establish a trust path to this home network. Once this is established, the provider can authenticate the user and check his credit with the home network. Accounting and rate information will be sent to the home network for mediation and processing. ------=_NextPart_000_0028_01C401AF.4D6F7070 Content-Type: text/plain; name="draft-behrens-sipping-roaming-architecture-00.1.txt" Content-Disposition: attachment; filename="draft-behrens-sipping-roaming-architecture-00.1.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= Internet Engineering Task Force H. = Behrens=20 Internet Draft snom = technology AG=20 K. Knuettel=20 Fraunhofer FOKUS=20 =20 =20 draft-behrens-sipping-roaming-architecture-01.txt=20 February 16, 2003=20 Expires: August, 2004=20 =20 Interdomain Trust-Relationships for SIP-based Roaming=20 =20 =20 STATUS OF THIS MEMO=20 =20 This document is an Internet-Draft and is subject to all = provisions of=20 Section 10 of RFC2026.=20 =20 Internet-Drafts are working documents of the Internet = Engineering Task=20 Force (IETF), its areas, and its working groups. Note that = other groups=20 may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of = six months=20 and may be updated, replaced, or obsoleted by other documents = at any=20 time. It is inappropriate to use Internet-Drafts as reference = material=20 or to cite them other than as "work in progress".=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 =20 To view the list Internet-Draft Shadow Directories, see=20 http://www.ietf.org/shadow.html.=20 =20 =20 Abstract=20 =20 This draft describes an authentication mechanism which can be = used to=20 enable users of VoIP to globally roam between any number of = ITSPs=20 (Internet Telephony Service Providers) without needing to = have a prior=20 customer or billing relationship with all of them. This = enables=20 profiles and one-line-billing.=20 Providers using this authentication mechanism do neither need = full-mesh=20 trust relationships or roaming agreements with every other = possible=20 provider nor do they need to rely on a centralized brokerage = entity to=20 process calls.=20 The Home Network (HN), which handles all AAA for a user = attempting to=20 use an ITSP's service is determined through a unique = identifier=20 submitted by the user. This Network Access Identifier = [RFC2486]=20 contains information about the trust domain or trust realm = the user=20 belongs to. Based on a simple discovery mechanism a provider = can=20 establish a trust path to this home network. Once this is = established,=20 the provider can authenticate the user and check his credit = with the=20 home network. Accounting and rate information will be sent to = the home=20 network for mediation and processing.=20 =20 =20 1. = Introduction..............................................2=20 2. = Requirements..............................................2=20 3. = Architecture..............................................3=20 4. = Terminology...............................................3=20 5. Conventions used in this = document.............................4=20 6. Security = Architecture.......................................4=20 6.1 Trust = Relationships.......................................4 =0C =0A= =0A= Internet Draft SIP February 8, 2003=20 =0A= =0A= 6.2 Trust Relationships between Providers and = Settlement............5=20 7. Actors and = Mechanisms.......................................5=20 7.1 Actors..................................................5 = 7.2 = Mechanisms...............................................5=20 7.2.1 Establishing Trust using pass-through = registration..................5=20 7.2.2 Establishing trust=0D = using two independent registrations................6=20 8. Call = Flows................................................7=20 8.2.1 Call flow for pass-through = registration.....................7=20 8.2.2 Call Flow for two independent = registrations..................7=20 10. = Bibliography............................................10=20 =20 1. Introduction=20 =20 More and more ISPs are beginning to add VoIP to their service = portfolio. The last years have seen the merging of IP-based = telephony=20 and switched line telephony (both mobile and fixed-line) in = the sense=20 that users of VoIP want to be able to call a PSTN or PLMN = number as=20 well as being reachable under a home PSTN or PLMN number. = Roaming=20 between ISPs has not developed to a large degree.=20 With the advent of voice communication becoming an important = service,=20 this will become more relevant. Users will want to use VoIP = for their=20 telephony and they will want to do this wherever they are = located. The=20 authors believe that one way to address this is to leverage a = user=92s=20 existing customer and billing relationship with his home = telephony=20 provider. Users make use of this when signing up for ad-hoc = service=20 with a visited ITSP. The ITSP verifies the existing billing=20 relationship and receives authorization of a certain amount = of credit=20 the home network is willing to underwrite.=20 Based on the security architecture described here, mutual = trust can be=20 established and the user can both place VoIP calls through = his visited=20 network as well as being reachable under home number and URI. = =20 2. Requirements=20 =20 The term =91Roaming Capability=92 has been defined in = [RFC2486]. =20 One aim of this document is to provide an architecture by = which Roaming=20 Capability can be assured by a federation of independent VoIP = providers. In the world of IP-related protocols little = attention has=20 been given to this issue.=20 Requirements for global roaming for WLAN users have been = described by=20 J. Caron in [CARON.1]. He also outlined a simple DNS-based = method in=20 [CARON.2].=20 The Roaming Scenario addressed here is as follows:=20 - The principal with the NAI of alice@biloxi.com sends a = REGISTER=20 request to the SIP registrar of atlanta.com. atlanta.com = in this=20 case is Alice=92s =91Visited Network=92 (VN). biloxi.com = is her home=20 network.=20 - Alice wants to use her VN to place authenticated and = secure=20 VoIP calls.=20 - Alice wants to be reachable both under her home URI as = well as=20 under a URI assigned by the VN.=20 - Alice provides her NAI to her VN=92s SIP registrar.=20 - The VN=20 o asserts that Alice=92s Home Network signs Alice=92s = identity and=20 authorizes a credit amount greater 0=20 o asserts that Alice=92s HN is a trusted entity=20 - atlanta.com assigns Alice a temporary Address of Record = (AOR) URI=20 as well as a valid contact address from within its own = name space.=20 - Alice registers with her HN using the newly assigned = Contact=20 address as the Contact.=20 - Alice=92s SUA can place outgoing call either under the = temporary URI=20 assigned by the VN or her home URI at biloxi.com.=20 =0A= H. Behrens, K. Knuettel = [Page 2]=0C =0A= =0A= Internet Draft SIP February 8, 2003=20 =0A= =0A= - Alice is reachable both under her home-AOR as well as the = visiting- AOR. Assuming Alice=92s HN provides PSTN break-in, Alice = is also=20 reachable under her telephone number known to her buddies. = - All calls placed by Alice for the duration of this = registration are=20 accounted to Alice=92s HN.=20 =20 3. Architecture=20 =20 The architecture is based on a model that is user-centric in = that it=20 assumes for each principal or user to have one Home Network = with which=20 he has a valid billing relationship. =20 This entity can authenticate the user based on his NAI and is = willing=20 to underwrite credit as well as receive CDRs for further = settlement.=20 This HN corresponds to the =91Authentication Service=92 = described in=20 [PETERSON.1]. Basing the architecture on a user-centric model = based on=20 a NAI, greatly reduces the number of billing relationships in = a roaming=20 environment as well allowing incumbent HNs, such PSTN or PLMN = providers=20 [RFC2486], to leverage their existing customer relationships. = =20 New emerging operators can benefit from this, because they = can deliver=20 their services to any user with a valid NAI, knowing that = they can bill=20 the user=92s HN up to the credit amount underwritten. =20 HNs can benefit by charging for this service. This = potentially creates=20 a win-win situation between incumbent operators, who hold the = trust and=20 billing relationships, and emerging ITSPs who wish to be able = to=20 attract as many users as possible, without the financial and=20 bureaucratic overhead involved in setting up a documented and = secure=20 billing relation with each of their users.=20 =20 The architecture consists of=20 1. Peers: entities participating in a roamable VoIP = infrastructure=20 2. Security Architecture: the Security architecture, which = describes=20 the trust relationships as well as security mechanisms = used.=20 3. Signalling Protocol: Signalling is based on the Session = Initiation=20 Protocol (SIP) [RFC3261]. =20 4. Accounting infrastructure: Both Authentication and = Authorization=20 are covered by the Security Architecture and/or the = Signalling=20 Protocol. Accounting is based on=20 a. the Authentication and Authorization signed by the = HN and=20 accepted by the VN.=20 b. hub-and-spoke trust relationships from the = participating=20 operators to a Settlement Entity (SE).=20 This document proposes an architecture, which fulfils these=20 requirements by making use of pre-existing trust = relationships.=20 The architecture is strongly influenced by work done by J. = Peterson=20 [PETERSON.1] and [RFC3325] on one hand and the work of Aboba = et. al=20 [RFC2486],[RFC2194] on the other hand.=20 =20 4. Terminology=20 =20 AAA Authentication, Authorization, Accounting=20 AOR Address of Record=20 CDR Call Detail Record=20 CRM Customer Relationship Management=20 DoT Domain of Trust=20 ETSI European Telecommunication Standard Institute=20 HN Home Network=20 ITSP Internet Telephony Service Provider=20 NAI Network Access Identifier=20 OSP Open Settlement Protocol=20 PKI Public Key Infrastructure=20 PLMN Public Line Mobile Network=20 PSTN Public Switched Telephone Network=20 URI Uniform Resource Identifier=20 =0A= H. Behrens, K. Knuettel = [Page 3]=0C =0A= =0A= Internet Draft SIP February 8, 2003=20 =0A= =0A= VN Visited Network=20 VoIP Voice over IP=20 =20 5. Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" = in this=20 document are to be interpreted as described in RFC-2119 = [RFC2119].=20 =20 6. Security Architecture=20 =20 The proposed architecture is based on the assumption that all = entities,=20 participating in the execution of a call, establish a mutual = Trust=20 Domain (TD) for at least the duration of that call. The term = =91Trust=20 Domain=92 is used in the sense described in [RFC3324].=20 Such a TD can be of permanent nature or established within = the context=20 of one or more transactions.=20 Based on this definition of Trust Domain the architecture = described=20 here, can be separated into two distinct layers:=20 1. Verification or Establishment of a common Trust Domain = based on=20 existing and derived direct Trust Relationships.=20 2. Use the mechanisms provided by this TD =96 Spec(T) =96 to = assert the=20 validity of VoIP calls and their related document trail.=20 Section 6.1 and 6.2 will outline the direct Trust = Relationships assumed=20 in the scope of this document. Section 7 outlines how a = common Trust=20 Domain is established. Section 8 provides example call flows = that=20 combine the mechanisms to demonstrate how the requirements = are=20 fulfilled.=20 =20 6.1 Trust Relationships=20 For SIP-based VoIP to become commercially accepted, providers = need to=20 be able to=20 - account and bill for their services=20 - be able to cooperate with other VoIP providers in routing = and=20 signalling calls.=20 Both of these requirements assume trust relationships between = the=20 user(s) being served as well as between the operators = cooperating=20 during the call.=20 In order to achieve critical mass, it needs to be easy for = providers to=20 cooperate in a flexible ad-hoc fashion in placing and routing = their=20 calls. Authentication should be based on a globally unique = identifier,=20 so one principal has one AAA and billing relationship. This = unique=20 identifier needs to specify his home domain of trust to other = entities.=20 Within his DoT, the identifier needs to identify his specific = principal=20 identity.=20 Authentication and authorization of a user can be transparent = because=20 the user uses only one set of credentials wherever he may be. = Within=20 this document we assume credentials based on exchange of PKI=20 certificates.=20 The model operates on direct trust relationships. A user has = an a- priori trust relationship with his home network.=20 Visited network and home network establish trust based on = exchange and=20 verification of certificates.=20 The user and the visited network establish trust through the = mechanisms=20 described in this document.=20 Once the user and the VN have established a trust = relationship, which=20 is based on the VN knowing that the HN can be charged for the = credit=20 amount authorized, the user is fully authenticated and = authorized and=20 can use the VN=92s services.=20 This is even though a-priori trust or billing relationship = exists=20 between the authenticated user and the serving provider.=20 =20 =0A= H. Behrens, K. Knuettel = [Page 4]=0C =0A= =0A= Internet Draft SIP February 8, 2003=20 =0A= =0A= 6.2 Trust Relationships between Providers and Settlement=20 Entity=20 =20 Inter-operator accounting is still within the scope of the = architecture=20 described here. We assume that billing is based on a = settlement and=20 clearing entity. This entity provides CDR-aggregation, = settlement,=20 clearing and billing functionalities to the participating = providers.=20 Where there is more than one such entity, we assume an = existing trust=20 relationship between them. This architecture assumes the = existence of=20 such an entity, e.g. based on the Open Settlement Protocol = (OSP)=20 defined by the ETSI [TS102.321]. It is also assumed that each = provider=20 has its own trust relationship with the Settlement Agency. It = should be=20 noted that the model explicitly does not use any of the = authentication=20 or routing functionalities proposed in that specification.=20 In the architecture presented here, OSP is strictly used for=20 aggregation of CDRs and settlement among operators.=20 The authors think that the fully integrated position taken by = the ETSI=20 does not fulfil the more organic and fluid environment of the = upcoming=20 VoIP industry.=20 =20 7. Actors and Mechanisms=20 =20 7.1 Actors=20 =20 The actors (players) are as follows:=20 =20 - The Service User (User): A user wanting to use VoIP = telephony=20 both for inbound as well as outbound calls. A user is = uniquely=20 identified based on his NAI, which identifies him as a = user of=20 his home domain. A mechanism of the location of the AAA = server=20 serving that home domain is assumed.=20 - The Visited Network (VN): the VN is the network a user = uses when=20 roaming. He wants to use that networks services while = being=20 billed by his HN. Roaming should be transparent. This = means that=20 the user should not need an a-priori trust relationship = with the=20 VN. It also means that he should be reachable under his = home AOR=20 and home telephone number no matter who is roaming = provider is.=20 - The Home Network (HN): The Home Network has two = functions:=20 o act as a home AAA server for the User.=20 o act as the home VoIP network for the User.=20 =20 7.2 Mechanisms=20 =20 Two mechanisms to establish a mutual Trust Domain are = proposed. =20 1. One mechanism relies on pass-through registration to = register the=20 user with his Home Network.=20 2. The other mechanism uses two independent registrations. = One for=20 the VN one for the HN.=20 Whichever one is chosen, at the end of either one =20 - The user has registered with the VN.=20 - The VN has established that he can bill services = delivered to=20 the User to the User=92s HN.=20 - The User has signed off that VN may bill to the HN=20 =20 =0A= 7.2.1 Establishing Trust using pass-through registration=20 =20 The mechanism is as follows:=20 - A user registers with the VN (atlanta.com in the call = flow=20 given). The user submits his NAI in new header field = =91P-NAI=92.=20 The user submits a bogus URI in both the From and the = To header.=20 =0A= =0A= H. Behrens, K. Knuettel = [Page 5]=0C =0A= =0A= Internet Draft SIP February 8, 2003=20 =0A= =0A= - The VN recognizes the registration as a P-NAI = registration and=20 sends back a =93401 Unauthorized=94 response, with both = the =91From=92=20 and the =91To=92 URI set to the temporary URI that will = be assigned=20 to the user upon successful authentication and = authorization.=20 - The User submits the credentials belonging to the NAI = specified,=20 e.g. his signed public key in the next register message = (F4).=20 - The VN requests authentication and authorization of the = user=20 from the home network. This can either be done through = the AAA=20 architecture or future extensions to the SIP protocol.=20 - The HN authenticates the user and authorizes a certain = amount of=20 credit. The HN includes a one-time token, which he = encrypts=20 using the user=92s public key in the return message. = The HN signs=20 the user=92s credentials and the encrypted token = together with the=20 amount authorized. =20 - The HN sends a =93407 Proxy Authentication Required=94 = including the=20 encrypted token to the User. =20 - The VN forwards it to the user.=20 - The user responds with the same registration message as = in F4,=20 the one difference being that he includes the = P-NAI-Token=20 encrypted with the VN`s public key.=20 - The VN decrypts the token, re-encrypts it with the = HN=92s public=20 key and forwards it.=20 - The HN sends a =93200 OK=94 with the token encrypted for = the VN.=20 - The VN extracts this encrypted token. This constitutes = the end=20 of the establishment of mutual trust.=20 - VN forwards the =93200 OK=94 to the user, encrypted with = the user=92s=20 public key and signed with the VN=92s private key.=20 - All parties now know they have established the necessary = level=20 of trust.=20 =0A= 7.2.2 Establishing trust using two independent registrations=20 =20 The mechanism is as follows:=20 - A user registers with the VN (atlanta.com in the call = flow=20 given). The user submits his NAI in new header field = =91P-NAI=92.=20 The user submits a bogus URI in both the From and the = To header.=20 - The VN recognizes the registration as a P-NAI = registration and=20 sends back a =93401 Unauthorized=94 response, with both = the =91From=92=20 and the =91To=92 URI set to the temporary URI that will = be assigned=20 to the user upon successful authentication and = authorization.=20 - The User submits the credentials belonging to the NAI = specified,=20 e.g. his signed public key in the next register = message.=20 - The VN requests authentication and authorization of the = user=20 from the home network. This can either be done through = the AAA=20 architecture or future extensions to the SIP protocol.=20 - The HN authenticates the user and authorizes a certain = amount of=20 credit. The HN includes a one-time token, which he = encrypts=20 using the user=92s public key in the return message. = The HN signs=20 the user=92s credentials and the encrypted token = together with the=20 amount authorized. At this point authentication is = established.=20 Authorization is still pending.=20 - The VN sends the user the encrypted token in a new = header field=20 =91P-NAI-Token=92 in the response to the user=92s = registration=20 request.=20 - The user decrypts the =91P-NAI-Token=92 with his private = key. =20 - The user encrypts the token with VN=92s public key. =20 - The user registers with his HN. He includes the = =91P-NAI-Token=92=20 (encrypted with the VN=92s certificate) inserted in the = header.=20 - The VN decrypts the token and encrypts it using the = HN=92s public=20 key. He forwards the registration message exchanging = the token=20 encrypted for him with the token encrypted for HN.=20 =0A= =0A= H. Behrens, K. Knuettel = [Page 6]=0C =0A= =0A= Internet Draft SIP February 8, 2003=20 =0A= =0A= - The HN decrypts the received token and compares it with = the=20 locally generated token. If they match, all necessary = trust=20 relationships have been established.=20 o The HN has authenticated the user to the VN.=20 o The VN now trusts the user based on the VN=92s = trusting =20 the HN.=20 o The user trusts the VN. This is established by the = VN=20 possessing the clear text P-NAI-Token.=20 o The HN receives proof of this trust and can = therefore=20 authorize the VN to bill up to the credit amount = given.=20 =20 8. Call Flows=20 =20 8.2.1 Call flow for pass-through registration=20 =20 =20 8.2.2 Call Flow for two independent registrations=20 =20 Client/User is located in the foreign ITSP-Network and wants = to be=20 authenticated by his home network.=20 At first the user registers with the FN. He submits his NAI = in a=20 special header of that request.=20 The VN contacts User=92s HN based on the realm/domain = information in the=20 NAI. HN authenticates and authorizes the user up to a given = amount of=20 credit (c). HN =93signs=94 this authorization by encrypting a = token with=20 the user=92s public key. The user extracts the token and = re-encrypts it=20 using the VN=92s public key. This re-encrypted token is = passed in the=20 user=92s next registration to his HN. VN extracts the token = and re- encrypts it for HN. By receiving this token, the HN knows = that the user=20 has signed off on VN=92s authorization. CDRs referring to = that token will=20 now be accepted for accounting and settlement.=20 =20 atlanta.com . . . . biloxi.com = . ITSP/GME =0D = ITSP/GME =20 . =20 Alice's . . . . . . . . . . . . . . . . . . . . .=20 softphone =20 | | | =20 | REGISTER F1 | | =20 |--------------------> | | =20 | 401 Unauthorized F2 | | =20 |<-------------------- | |=20 | REGISTER F3 | | =20 |--------------------> | | =20 | 100 Trying F4 | Authenticate F5 | =20 |<-------------------- |----------------> | =20 | | Authenticated F6 |=20 | | contains encrypted | = | | token |=20 | 200 OK F7 |<--------------------- |=20 | contains encrypted | |=20 | token | |=20 |<-------------------- | |=20 | REGISTER F8 | |=20 | contains token | |=20 | encrypted for VN | |=20 |--------------------> | |=20 | | REGISTER F9 |=20 | | contains token |=20 | | encrypted for HN | =20 | |---------------------> |=20 | | 200 OK F10 |=20 | |<------------------- |=20 =0A= H. Behrens, K. Knuettel = [Page 7]=0C =0A= =0A= Internet Draft SIP February 8, 2003=20 =0A= =0A= | 200 OK F11 | |=20 |<-------------------- | |=20 =20 =20 F1=20 =20 REGISTER sip:registrar.atlanta.com SIP/2.0=20 Via: SIP/2.0/UDP = bobspc.atlanta.com:5060;branch=3Dz9hG4bKnashds7=20 Max-Forwards: 70=20 To: Alice =20 From: Alice ;tag=3D456248=20 Call-ID: 843817637684230@998sdasdh09=20 CSeq: 1826 REGISTER=20 Contact: =20 Expires: 7200=20 P-NAI: Alice =20 Content-Length: 0=20 =20 F2=20 =20 401 Unauthorized SIP/2.0=20 Via: SIP/2.0/UDP = bobspc.atlanta.com:5060;branch=3Dz9hG4bKnashds7=20 Max-Forwards: 70=20 To: Alice =20 From: Alice ;tag=3D456248=20 Call-ID: 843817637684230@998sdasdh09=20 P-NAI: Alice =20 CSeq: 1826 REGISTER=20 Expires: 7200=20 P-NAI: Alice =20 Content-Length: 0=20 =20 F3=20 =20 REGISTER sip:registrar.atlanta.com SIP/2.0=20 Via: SIP/2.0/UDP = bobspc.atlanta.com:5060;branch=3Dz9hG4bKnashds7=20 Max-Forwards: 70=20 To: Alice =20 From: Alice ;tag=3D456248=20 Call-ID: 843817637684230@998sdasdh09=20 CSeq: 1837 REGISTER=20 Contact: =20 Expires: 7200=20 P-NAI: Alice =20 Content-Length: 0=20 Content-Type: multipart/signed;=20 protocol=3D"application/pkcs7-signature";=20 micalg=3Dsha1; boundary=3Dboundary42;=20 Content-Length: 568=20 ********=20 *******=20 =20 F4 =20 =20 SIP/2.0 100 Trying=20 Via: SIP/2.0/UDP = bobspc.atlanta.com:5060;branch=3Dz9hG4bKnashds7=20 To: Alice =20 From: Alice ;tag=3D456248=20 Call-ID: 843817637684230@998sdasdh09=20 CSeq: 1837 REGISTER=20 Content-Length: 0=20 =20 F5 /F6 TO BE DONE !=20 =0A= H. Behrens, K. Knuettel = [Page 8]=0C =0A= =0A= Internet Draft SIP February 8, 2003=20 =0A= =0A= =20 F7=20 =20 SIP/2.0 200 OK=20 Via: SIP/2.0/UDP = bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7=20 ;received=3D192.0.2.4=20 To: Alice =20 From: Alice ;tag=3D456248=20 Call-ID: 843817637684230@998sdasdh09=20 CSeq: 1837 REGISTER=20 Contact: =20 Expires: 7200=20 P-NAI-Token:=20 = =20 Content-Length: 0 =20 =20 F8=20 =20 REGISTER sip:registrar.biloxi.com SIP/2.0=20 Via: SIP/2.0/UDP = bobspc.atlanta.com:5060;branch=3Dz9hG4bKnashds7=20 Max-Forwards: 70=20 To: Alice =20 From: Alice ;tag=3D456248=20 Call-ID: 843817637684230@998sdasdh09=20 CSeq: 1847 REGISTER=20 Contact: =20 Expires: 7200=20 P-NAI: Alice =20 Content-Length: 0=20 Content-Type: multipart/signed;=20 protocol=3D"application/pkcs7-signature";=20 micalg=3Dsha1; boundary=3Dboundary42;=20 Content-Length: 568=20 ********=20 *******=20 =20 F9=20 =20 REGISTER sip:registrar.biloxi.com SIP/2.0=20 Via: SIP/2.0/UDP = bobspc.atlanta.com:5060;branch=3Dz9hG4bKnashds7=20 Via: SIP/2.0/UDP = xyv.atlanta.com:5060;branch=3Dz9hG4bKnasdhf9=20 Max-Forwards: 70=20 To: Alice =20 From: Alice ;tag=3D456248=20 Call-ID: 843817637684230@998sdasdh09=20 CSeq: 1847 REGISTER=20 Contact: =20 Expires: 7200=20 P-NAI: Alice =20 Content-Length: 0=20 Content-Type: multipart/signed;=20 protocol=3D"application/pkcs7-signature";=20 micalg=3Dsha1; boundary=3Dboundary42;=20 Content-Length: 568=20 ********=20 ******* =20 =20 F10=20 =20 SIP/2.0 200 OK=20 Via: SIP/2.0/UDP = bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7=20 ;received=3D192.0.2.4=20 =0A= H. Behrens, K. Knuettel = [Page 9]=0C =0A= =0A= Internet Draft SIP February 8, 2003=20 =0A= =0A= Via: SIP/2.0/UDP = xyv.atlanta.com:5060;branch=3Dz9hG4bKnasdhf9=20 To: Alice =20 From: Alice ;tag=3D456248=20 Call-ID: 843817637684230@998sdasdh09=20 CSeq: 1847 REGISTER=20 Contact: =20 Expires: 7200=20 P-NAI-Token:=20 = =20 Content-Length: 0 =20 =20 F11=20 =20 SIP/2.0 200 OK=20 Via: SIP/2.0/UDP = bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7=20 ;received=3D192.0.2.4=20 To: Alice =20 From: Alice ;tag=3D456248=20 Call-ID: 843817637684230@998sdasdh09=20 CSeq: 1847 REGISTER=20 Contact: =20 Expires: 7200=20 P-NAI-Token:=20 = =20 Content-Length: 0 =20 =20 =20 =0D =0D =0D =0D = =0D =0D =0D =0D = =20 IANA Considerations=20 =20 SIP headers defined: P-NAI, P-NAI-Token=20 =20 Normative description: This document=20 =20 =20 9. Authors' Addresses=20 =20 Dr. Harry Behrens=20 snom technology AG=20 Pascalstr. 10B=20 10587 Berlin=20 Germany=20 Email: hb@snom.com=20 =20 Karsten Knuettel=20 Fraunhofer FOKUS=20 Kaiserin-Augusta-Allee 31=20 10589 Berlin=20 Email: knuettel@fokus.fraunhofer.de=20 =20 =20 10. Bibliography=20 =20 [CARON.1]Caron, J., =93Public Wireless LAN roaming issues=94, = ,=20 WIP,=20 February 2002.=20 [CARON.2]Caron, J., =93DNS-based Roaming=94,=20 , WIP,=20 =0A= H. Behrens, K. Knuettel [Page = 10]=0C =0A= =0A= Internet Draft SIP February 8, 2003=20 =0A= =0A= April 2002.=20 [PETERSON.1] Peterson, J. =93Enhancements for=20 Authenticated Identity=20 Management in the Session Initiation Protocol=20 (SIP)=94,=20 , WIP, February=20 2003.=20 [RFC2194] Aboba, B. et al., "Review of Roaming=20 Implementations", RFC2194, September 1997=20 [RFC2119] Bradner, S., "Key words for use in RFCs to=20 Indicate Requirement Levels", RFC2119, March=20 1997=20 [RFC2486]Aboba, B. et al., "The Network Access=20 Identifier",=20 January 1999=20 [RFC3261]Rosenberg, J., Schulzrinne H., Camarillo G.,=20 Johnston, A.R., Peterson, J., Sparks, R.,=20 Handley, M. and E. Schooler, "SIP: Session=20 Initiation Protocol", RFC 3261, Internet=20 Engineering Task Force, June 2002.=20 [RFC3325] Jennings, C. et al. "Private Extensions to the=20 Session Initiation Protocol (SIP) for Asserted=20 Identity within Trusted Networks", November=20 2002=20 [TS102.321] ETSI TS, =93Telecommunications and Internet=20 Protocol Harmonization Over Networks (TIPHON);=20 Open Settlement Protocol (OSP) for Interdomain=20 Pricing, authorization and usage exchange=94,=20 Technical Specification 101 321. =20 [RFC3261]=20 J. Rosenberg, H. Schulzrinne, G. Camarillo, A.=20 R. Johnston, J.Peterson, R. Sparks, M. Handley,=20 and E. Schooler, "SIP: Session Initiation=20 Protocol", RFC 3261, Internet Engineering Task=20 Force, June 2002.=20 =20 The IETF takes no position regarding the validity or scope of = any=20 intellectual property or other rights that might be claimed = to pertain=20 to the implementation or use of the technology described in = this=20 document or the extent to which any license under such rights = might or=20 might not be available; neither does it represent that it has = made any=20 effort to identify any such rights.=20 Information on the IETF's procedures with respect to rights = in=20 standards-track and standards-related documentation can be = found in=20 BCP-11. Copies of claims of rights made available for = publication and=20 any assurances of licenses to be made available, or the = result of an=20 attempt made to obtain a general license or permission for = the use of=20 such proprietary rights by implementors or users of this = specification=20 can be obtained from the IETF Secretariat.=20 =20 The IETF invites any interested party to bring to its = attention any=20 copyrights, patents or patent applications, or other = proprietary rights=20 which may cover technology that may be required to practice = this=20 standard. Please address the information to the IETF = Executive=20 Director.=20 =20 Full Copyright Statement=20 =20 Copyright (c) The Internet Society (2003). All Rights = Reserved.=20 =20 This document and translations of it may be copied and = furnished to=20 others, and derivative works that comment on or otherwise = explain it or=20 assist in its implementation may be prepared, copied, = published and=20 =0A= H. Behrens, K. Knuettel [Page = 11]=0C =0A= =0A= Internet Draft SIP February 8, 2003=20 =0A= =0A= distributed, in whole or in part, without restriction of any = kind,=20 provided that the above copyright notice and this paragraph = are=20 included on all such copies and derivative works. However, = this=20 document itself may not be modified in any way, such as by = removing the=20 copyright notice or references to the Internet Society or = other=20 Internet organizations, except as needed for the purpose of = developing=20 Internet standards in which case the procedures for = copyrights defined=20 in the Internet Standards process must be followed, or as = required to=20 translate it into languages other than English.=20 =20 The limited permissions granted above are perpetual and will = not be=20 revoked by the Internet Society or its successors or assigns. = =20 This document and the information contained herein is = provided on an=20 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET = ENGINEERING=20 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, = INCLUDING BUT=20 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION = HEREIN WILL=20 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF = MERCHANTABILITY OR=20 FITNESS FOR A PARTICULAR PURPOSE.=20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= H. Behrens, K. Knuettel [Page = 12]=0C ------=_NextPart_000_0028_01C401AF.4D6F7070-- From owner-aaa-wg@merit.edu Thu Mar 4 02:41: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 CAA23737 for ; Thu, 4 Mar 2004 02:41:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B952B91237; Thu, 4 Mar 2004 02:40:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 832F9912D3; Thu, 4 Mar 2004 02:40:50 -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 2BC7C91237 for ; Thu, 4 Mar 2004 02:40:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0BC495DE1C; Thu, 4 Mar 2004 02:40:49 -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 304CC5DE6D for ; Thu, 4 Mar 2004 02:40:48 -0500 (EST) 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 i247ehC11279; Thu, 4 Mar 2004 09:40:44 +0200 (EET) X-Scanned: Thu, 4 Mar 2004 09:39:18 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i247dIH9010495; Thu, 4 Mar 2004 09:39:18 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 002bMvi4; Thu, 04 Mar 2004 09:39:17 EET 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 i247dHO07243; Thu, 4 Mar 2004 09:39:17 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Mar 2004 09:39:17 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Draft re.: SIP-based roaming Date: Thu, 4 Mar 2004 09:39:17 +0200 Message-ID: Thread-Topic: [AAA-WG]: Draft re.: SIP-based roaming thread-index: AcQBptRn3IUMc2i1TQaNhikq1tLuzwAFMOsw From: To: , X-OriginalArrivalTime: 04 Mar 2004 07:39:17.0313 (UTC) FILETIME=[CC688310:01C401BB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Harry, I will take a look at it, but I'd appreciate it if you could reformat = the document according to the basic I-D guidelines - its a bit rough-going in the current format.=20 Also, its helpful to post a URL where the document can be found, rather than sending an attachment. thanks, John > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Harry Behrens > Sent: 04 March, 2004 07:10 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Draft re.: SIP-based roaming >=20 >=20 > The following draft has been submitted to the SIPPING WG. > As it is close to AAA in nature, I figure I would greatly appreciate > input from this group. >=20 > Pls. note that the attached draft (--01.txt) is not yet on the IETF > website due to the cutoff date prior to the Seoul meeting. >=20 >=20 > Abstract: > This draft describes an authentication mechanism which can > be used to=20 > enable users of VoIP to globally roam between any number > of ITSPs=20 > (Internet Telephony Service Providers) without needing to > have a prior=20 > customer or billing relationship with all of them. This > enables=20 > profiles and one-line-billing.=20 > Providers using this authentication mechanism do=20 > neither need > full-mesh=20 > trust relationships or roaming agreements with every other > possible=20 > provider nor do they need to rely on a centralized=20 > brokerage > entity to=20 > process calls.=20 > The Home Network (HN), which handles all AAA for a user > attempting to=20 > use an ITSP's service is determined through a unique > identifier=20 > submitted by the user. This Network Access Identifier > [RFC2486]=20 > contains information about the trust domain or trust realm > the user=20 > belongs to. Based on a simple discovery mechanism=20 > a provider > can=20 > establish a trust path to this home network. Once this is > established,=20 > the provider can authenticate the user and check his credit > with the=20 > home network. Accounting and rate information will=20 > be sent to > the home=20 > network for mediation and processing.=20 >=20 From owner-aaa-wg@merit.edu Thu Mar 4 02:58: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 CAA25700 for ; Thu, 4 Mar 2004 02:58:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E7252912D3; Thu, 4 Mar 2004 02:58:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B478B912D5; Thu, 4 Mar 2004 02:58:13 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4F79C912D3 for ; Thu, 4 Mar 2004 02:58:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D2AA5DE98; Thu, 4 Mar 2004 02:58:12 -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 5AB885DE9C for ; Thu, 4 Mar 2004 02:58:11 -0500 (EST) 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 i247wAC28141; Thu, 4 Mar 2004 09:58:10 +0200 (EET) X-Scanned: Thu, 4 Mar 2004 09:57:19 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i247vJpP022319; Thu, 4 Mar 2004 09:57:19 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00OGR7BC; Thu, 04 Mar 2004 09:57:18 EET 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 i247vIO14516; Thu, 4 Mar 2004 09:57:18 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Mar 2004 09:57:18 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Mar 2004 09:57:18 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Update to DCC Issue 25: addition of *[AVP] notation in some grouped AVPs structure Date: Thu, 4 Mar 2004 09:57:18 +0200 Message-ID: Thread-Topic: Update to DCC Issue 25: addition of *[AVP] notation in some grouped AVPs structure thread-index: AcQBMdH39MP7q2EmQ6ymh7MvbO7RBAAjHcvQ From: To: , Cc: X-OriginalArrivalTime: 04 Mar 2004 07:57:18.0381 (UTC) FILETIME=[50C665D0:01C401BE] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Issue 25 updated with info below. > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext=20 > Sent: 03 March, 2004 17:12 > To: aaa-wg@merit.edu > Cc: mwatson@nortelnetworks.com > Subject: [AAA-WG]: Update to DCC Issue 25: addition of *[AVP] notation > in some grouped AVPs structure >=20 >=20 >=20 > Hi, >=20 > according to recent discussion here is the updated issue 25=20 > to add the *[ AVP ] notation > also to the G-S-U, R-S-U and U-S-U AVPs. >=20 > Regards > Marco >=20 > ------------------------------------------------------------- > Description of issue: addition of *[AVP] notation in the=20 > M-S-C-C AVP structure > Submitter name: Marco Stura > Date first submitted: 1.03.2004=20 > Reference:=20 > Document: draft-ietf-aaa-diameter-cc-03.txt=20 > Comment type: T > Priority: 1=20 > Section: 8.16 >=20 > Rationale/Explanation of issues:=20 >=20 > In order to define a more future proof structure I propose to=20 > add the *[AVP] notation > to the M-S-C-C, G-S-U, U-S-U and R-S-U AVPs structure.=20 > According to the Base (section 4.4.1)=20 > the Grouped AVP can contain *[AVP]. >=20 > Requested change: >=20 > -Section 8.16 >=20 > ADD the *[ AVP ] notation to the AVP structure >=20 >=20 > Multiple-Services-Credit-Control ::=3D < AVP Header: 456 > =20 > [ Granted-Service-Unit ]=20 > [=20 > Requested-Service-Units ] =20 > *[ Used-Service-Units ]=20 > [ Tariff-Change-Usage ] =20 > *[ Service-Identifier ] =20 > [ Rating-Group ] =20 > *[ G-S-U-Pool-Reference ] =20 > [ Validity-Time ] =20 > [ Result-Code ] =20 > [ Final-Unit-Indication ]=20 > *[ AVP ] >=20 > - Section 8.17 >=20 > ADD the *[ AVP ] notation to the AVP structure >=20 > Granted-Service-Unit ::=3D < AVP Header: 431 > =20 > [ Tariff-Time-Change ] =20 > [ CC-Time ] =20 > [ CC-Money ] =20 > [ CC-Total-Octets ] =20 > [ CC-Input-Octets ] =20 > [ CC-Output-Octets ] =20 > [ CC-Service-Specific-Units ] > *[ AVP ] >=20 > - Section 8.18 >=20 > ADD the *[ AVP ] notation to the AVP structure >=20 > Requested-Service-Unit ::=3D < AVP Header: 437 > =20 > [ CC-Time ] =20 > [ CC-Money ] =20 > [ CC-Total-Octets ] =20 > [ CC-Input-Octets ] =20 > [ CC-Output-Octets ] =20 > [ CC-Service-Specific-Units ] > *[ AVP ] >=20 > - Section 8.19 >=20 > ADD the *[ AVP ] notation to the AVP structure >=20 > Used-Service-Unit ::=3D < AVP Header: 446 > =20 > [ Tariff-Change-Usage ] =20 > [ CC-Time ] =20 > [ CC-Money ] =20 > [ CC-Total-Octets ] =20 > [ CC-Input-Octets ] =20 > [ CC-Output-Octets ] =20 > [ CC-Service-Specific-Units ] > *[ AVP ] >=20 >=20 >=20 From owner-aaa-wg@merit.edu Thu Mar 4 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 DAA27914 for ; Thu, 4 Mar 2004 03:24:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A413A912D5; Thu, 4 Mar 2004 03:23:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D655912D7; Thu, 4 Mar 2004 03:23:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 30E68912D5 for ; Thu, 4 Mar 2004 03:23:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 16C0D5DEDF; Thu, 4 Mar 2004 03:23:48 -0500 (EST) 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 0607D5DEC5 for ; Thu, 4 Mar 2004 03:23:47 -0500 (EST) 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 i248Nfh19389 for ; Thu, 4 Mar 2004 10:23:41 +0200 (EET) X-Scanned: Thu, 4 Mar 2004 10:18:38 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i248IcEw021026 for ; Thu, 4 Mar 2004 10:18:38 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00im0EMt; Thu, 04 Mar 2004 10:18:36 EET 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 i248IZ720961 for ; Thu, 4 Mar 2004 10:18:35 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Mar 2004 10:18:34 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Invited paper on Diameter Date: Thu, 4 Mar 2004 10:18:33 +0200 Message-ID: Thread-Topic: Invited paper on Diameter thread-index: AcQBwUgQdSMn8ZJ9R1ytZH0HrSoLLg== From: To: X-OriginalArrivalTime: 04 Mar 2004 08:18:34.0354 (UTC) FILETIME=[49506D20:01C401C1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Madjid asked me to pass on the information below, to see if anyone was interested writing a paper on Diameter. Please contact Madjid off-list if you are interested. John From: Madjid.Nakhjiri@motorola.com I am planning on organizing an invited paper session on=20 "AAA and secure access for mobile and fixed users" for the=20 CCCT04 conference http://www.iiisci.org/ccct2004/WebSite/Default.asp I think the session will benefit greatly from a paper on Diameter and = better=20 yet on Diameter and its application to authentication (NASREQ).=20 =20 Since this is an invited session the deadlines for abstracts and so on = can be relaxed a bit, but first, I need to know if I can fill the spots and = then we can discuss details.=20 From owner-aaa-wg@merit.edu Thu Mar 4 03:31: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 DAA28840 for ; Thu, 4 Mar 2004 03:31:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 255BC912D7; Thu, 4 Mar 2004 03:30:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ECE98912DC; Thu, 4 Mar 2004 03:30:40 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6555E912D7 for ; Thu, 4 Mar 2004 03:30:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 800345DE7F; Thu, 4 Mar 2004 03:30:38 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from natsmtp00.webmailer.de (natsmtp00.rzone.de [81.169.145.165]) by segue.merit.edu (Postfix) with ESMTP id 9E9FD5DE54 for ; Thu, 4 Mar 2004 03:30:37 -0500 (EST) Received: from RocknRoll ([210.93.162.110]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i248UYIe005813; Thu, 4 Mar 2004 09:30:35 +0100 (MET) From: "Harry Behrens" To: , Subject: AW: [AAA-WG]: Draft re.: SIP-based roaming Date: Thu, 4 Mar 2004 09:32:19 +0100 Message-ID: <000501c401c3$36a1a430$e71f10ac@RocknRoll> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi John, understood. I apologize for the misformatted version. The (almost?) correctly formatted version can be downloaded from http://www.snom.com/download/draft-behrens-sipping-roaming-architecture- 01.txt Sorry for the confusion. Regards, Harry=20 > -----Urspr=FCngliche Nachricht----- > Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Gesendet: Donnerstag, 4. M=E4rz 2004 08:39 > An: harry.behrens@snom.de; aaa-wg@merit.edu > Betreff: RE: [AAA-WG]: Draft re.: SIP-based roaming >=20 >=20 > Hi Harry, >=20 > I will take a look at it, but I'd appreciate it if you could=20 > reformat the document according to the basic I-D guidelines -=20 > its a bit rough-going in the current format.=20 >=20 > Also, its helpful to post a URL where the document can be=20 > found, rather than sending an attachment. >=20 > thanks, > John >=20 > > -----Original Message----- > > From: owner-aaa-wg@merit.edu > > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > ext Harry Behrens > > Sent: 04 March, 2004 07:10 > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: Draft re.: SIP-based roaming > >=20 > >=20 > > The following draft has been submitted to the SIPPING WG. > > As it is close to AAA in nature, I figure I would greatly=20 > appreciate=20 > > input from this group. > >=20 > > Pls. note that the attached draft (--01.txt) is not yet on the IETF=20 > > website due to the cutoff date prior to the Seoul meeting. > >=20 > >=20 > > Abstract: > > This draft describes an authentication mechanism=20 > which can be=20 > > used to > > enable users of VoIP to globally roam between any number > > of ITSPs=20 > > (Internet Telephony Service Providers) without=20 > needing to=20 > > have a prior > > customer or billing relationship with all of them. This=20 > > enables > > profiles and one-line-billing.=20 > > Providers using this authentication mechanism do > > neither need > > full-mesh=20 > > trust relationships or roaming agreements with=20 > every other > > possible=20 > > provider nor do they need to rely on a centralized=20 > > brokerage > > entity to=20 > > process calls.=20 > > The Home Network (HN), which handles all AAA for a user > > attempting to=20 > > use an ITSP's service is determined through a unique > > identifier=20 > > submitted by the user. This Network Access Identifier > > [RFC2486]=20 > > contains information about the trust domain or=20 > trust realm > > the user=20 > > belongs to. Based on a simple discovery mechanism=20 > > a provider > > can=20 > > establish a trust path to this home network. Once this is > > established,=20 > > the provider can authenticate the user and check=20 > his credit > > with the=20 > > home network. Accounting and rate information will=20 > > be sent to > > the home=20 > > network for mediation and processing.=20 > >=20 >=20 From owner-aaa-wg@merit.edu Thu Mar 4 05:03: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 FAA04926 for ; Thu, 4 Mar 2004 05:03:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AFD8A912DC; Thu, 4 Mar 2004 05:02:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 79249912DF; Thu, 4 Mar 2004 05:02:58 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2658E912DC for ; Thu, 4 Mar 2004 05:02:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1328C5DEE3; Thu, 4 Mar 2004 05:02:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 7C18E5DEDB for ; Thu, 4 Mar 2004 05:02:56 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i24A2sqY026126 for ; Thu, 4 Mar 2004 11:02:55 +0100 (MET) 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, 4 Mar 2004 11:02:54 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 4 Mar 2004 11:03:39 +0100 Message-ID: From: "Leena Mattila (TU/LMF)" To: crich@nortelnetworks.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC Issue 22: Inclusion of IMEI in Subscription-Id- Type AVP Date: Thu, 4 Mar 2004 11:02:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 04 Mar 2004 10:02:54.0827 (UTC) FILETIME=[DCD8CBB0:01C401CF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Chris, what do you think of this proposal? Would it be ok to update the issue according to the text below? BR, Leena > -----Original Message----- > From: owner-aaa-wg@merit.edu > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Leena Mattila (TU/LMF) > Sent: 27. helmikuuta 2004 16:01 > To: crich@nortelnetworks.com > Cc: aaa-wg@merit.edu; Harri Hakala (TU/LMF); 'marco.stura@nokia.com' > Subject: RE: [AAA-WG]: DCC Issue 22: Inclusion of IMEI in > Subscription-Id- Type AVP > > > Hi Chris, > > I agree that this information is relevant. But if we do introduce the > identifier in DCC it should be generic, the 3GPP specific attributes > can be defined using 3GPP vendor id. > > How about introducing the following AVP in DCC (following the spirit > of Calling-Station-Id AVP in NASREQ): > > Terminal-Identity AVP > > The Terminal-Identity AVP (AVP Code TBD) is of type UTF8String, and > allows the Credit-control client to send in the request the ASCII > string describing identity of the terminal the subscriber is using > for the connection. The Terminal-Identity AVP MAY contain > a MAC address, > formated as described in [RAD802.1X], or other interface > identifier, > formated as IEEE EUI-64 identifier [EUI64]. There are a > number of types > of terminals that have identifiers other than IEEE EUI-64 > or IEEE 802 > 48-bit MACs. Examples include International Mobile Equipment > Identity (IMEI) or Mobile Equipment Identifier (MEID). These > identifiers can be converted to modified EUI-64 format as described > in [IPv6Addr]. > > [RAD802.1X] P. Congdon, et.al "IEEE 802.1X RADIUS Usage Guidelines", > RFC 3580, September 2003. > > [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) > Registration Authority", > http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. BTW, there seems to be ongoing activity to define how IMEI should be converted to modified EUI-64 format: http://www.ietf.org/internet-drafts/draft-dupont-ipv6-imei-06.txt As this is not an RFC, we can't refer to this one as a Normative reference but I think it matches with the above, right? BR, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of marco.stura@nokia.com Sent: 27. helmikuuta 2004 9:14 To: crich@nortelnetworks.com; Harri Hakala (TU/LMF) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Hi Chris, >I am suggesting that there are valid reasons that the credit control server has for knowing this information - especially in the 3GPP NAS world (Possibly in 3GPP2. Maybe less so in the >SIP world). I am recommending that in addition to the IMSI, MSISDN, IP address, the IMEISV MAY also be included. My question would be, what other equipment identities could be included other than 3GPP IMEISV. What is the 3GPP 2 equipment identity? Is ther a way to identify other type of equipments (e.g. MAC address or..)? Certainly the Subscription-Id AVP is not the most appropriate container for the IMEI. I've no problem my self to define a new AVP Equipment-Identification or something similar if we can find other applications than 3GPP. But, if only 3GPP is using the AVP the best way would be that 3GPP defines this AVP. You may know that 3GPP can use 3GPP vendor-id and value assigned in 3GPP i.e. the AVP can be fully handled by 3GPP without IETF/IANA interactions. Regards Marco This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-aaa-wg@merit.edu Thu Mar 4 11:04:51 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 LAA28700 for ; Thu, 4 Mar 2004 11:04:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A680B912E4; Thu, 4 Mar 2004 11:04:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65F25912DA; Thu, 4 Mar 2004 11:04:28 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5015D912DF for ; Thu, 4 Mar 2004 11:04:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 310395DDF8; Thu, 4 Mar 2004 11:04:10 -0500 (EST) 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 8DDF35DDE6 for ; Thu, 4 Mar 2004 11:04:09 -0500 (EST) Received: (cpmta 24236 invoked from network); 4 Mar 2004 08:04:08 -0800 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.66) with SMTP; 4 Mar 2004 08:04:08 -0800 X-Sent: 4 Mar 2004 16:04:08 GMT Message-Id: <5.2.1.1.2.20040304105616.03597cb0@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 04 Mar 2004 10:58:34 -0500 To: Avi Lior , aaa-wg@merit.edu From: David Mitton Subject: Re: [AAA-WG]: NASREQ14: editorial change 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 2/19/2004 06:27 PM -0500, Avi Lior wrote: >Interim vs. Start Stop record when Reuathentication/Reuathorization >Submitter name: Avi Lior >Submitter email address: avi@bridgewatersystems.com >Date first submitted: February 19th 2004 >Reference: >Document: NASREQ-14 >Comment type: Technical >Priority: E >Section: 9.1 >Rationale/Explanation of issue: > >Requested changes: > >Change: > >I guess the safest bet is to translate it to Session-Timeout > value (with value from Authorization-Lifetime AVP, the smaller > one) and Termination-Action set to AA-REQUEST. (And remove > Authorization-Lifetime and Re-Auth-Request-Type) > >Change To: > The safest bet is to translate it to Session-Timeout > value (with value from Authorization-Lifetime AVP, the smaller > one) and Termination-Action set to AA-REQUEST. (And remove > Authorization-Lifetime and Re-Auth-Request-Type) Hmmm. some missed text from the original suggestion. Thank you. "safest" and "bet" are removed. New text: Translate it to a Session-Timeout value (with value from Authorization-Lifetime AVP, the smaller one) and Termination-Action set to AA-REQUEST. (And remove Authorization-Lifetime and Re-Auth-Request-Type) Dave. From owner-aaa-wg@merit.edu Thu Mar 4 11:05: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 LAA28749 for ; Thu, 4 Mar 2004 11:05:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 73BE6912DF; Thu, 4 Mar 2004 11:04:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2BC62912E2; Thu, 4 Mar 2004 11:04:27 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AE2A5912DA for ; Thu, 4 Mar 2004 11:04:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 95B7A5DDEB; Thu, 4 Mar 2004 11:04:09 -0500 (EST) 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 3693F5DDD4 for ; Thu, 4 Mar 2004 11:04:09 -0500 (EST) Received: (cpmta 24223 invoked from network); 4 Mar 2004 08:04:07 -0800 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.66) with SMTP; 4 Mar 2004 08:04:07 -0800 X-Sent: 4 Mar 2004 16:04:07 GMT Message-Id: <5.2.1.1.2.20040304104348.03545900@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 04 Mar 2004 10:50:39 -0500 To: aaa-wg@merit.edu From: David Mitton Subject: Re: [AAA-WG]: NASREQ-14: Interim vs. Start Stop record when Reuathentication/Re uathorization Cc: Avi Lior 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 2/19/2004 05:52 PM -0500, Avi Lior wrote: >Interim vs. Start Stop record when Reuathentication/Reuathorization >Submitter name: Avi Lior >Submitter email address: avi@bridgewatersystems.com >Date first submitted: February 19th 2004 >Reference: >Document: NASREQ-14 >Comment type: Technical >Priority: S >Section: 2.2 >Rationale/Explanation of issue: > >According to NASREQ-14 every change in authentication or authorization >MUST generate an Accounting-Record-Type of INTERIM_RECORD. > >Requested changes: > >I belive that changes caused by re-authentication or authorization >should cause a new session to begin and therefor a STOP_RECORD followed >by a START_RECORD MUST be generated. > >Besides INTERIM_RECORDS may be disabled. So if the text stands then at >least state that accounting interim would be sent regardless of whether >the server has enabled interims or not. I disagree. I would like to hear other points of view on this. A connection oriented service may not care about such changes, infact they may not be changes at all, just a re-affirmation of the intended and authorized service. Thus I don't think a START or a STOP is appropriate. Similarly, I am perplexed by the nature of the comment "INTERIM_RECORDS may be disabled" Perhaps the periodic generation of ACR messages with type=INTERIM_RECORD may not be enabled. But I don't see anything in either RADIUS or Diameter that restricts this type of Accounting message to only that usage. They should always be valid to send. Would it be more acceptable, to some, if we create yet another Accounting Status-Type for (possible) Change-of-Service? Dave. From owner-aaa-wg@merit.edu Thu Mar 4 11:30: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 LAA00558 for ; Thu, 4 Mar 2004 11:30:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3C0A4912EA; Thu, 4 Mar 2004 11:30:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E909912E8; Thu, 4 Mar 2004 11:30:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E950912DA for ; Thu, 4 Mar 2004 11:30:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 85AF85DDC6; Thu, 4 Mar 2004 11:30:09 -0500 (EST) 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 9B7F55DD9D for ; Thu, 4 Mar 2004 11:30:07 -0500 (EST) Received: (cpmta 55 invoked from network); 4 Mar 2004 08:30:05 -0800 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.64) with SMTP; 4 Mar 2004 08:30:05 -0800 X-Sent: 4 Mar 2004 16:30:05 GMT Message-Id: <5.2.1.1.2.20040304110138.0357f010@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 04 Mar 2004 11:22:26 -0500 To: Avi Lior , aaa-wg@merit.edu From: David Mitton Subject: Re: [AAA-WG]: NASREQ-14: Accounting-Session-Id in ACA Command 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 2/20/2004 11:40 AM -0500, Avi Lior wrote: >Accounting-Session-Id in ACA Command >Submitter name: Avi Lior >Submitter email address: avi@bridgewatersystems.com >Date first submitted: February 29th 2004 >Reference: >Document: NASREQ-14 >Comment type: Technical >Priority: S >Section: 3.10 > >Rationale/Explanation of issue: > >[ Accounting-Session-Id ] appears in Accounting-Answer (ACA) Command > >Requested changes: > >This probably should be changed to [Acct-Session-Id]. Yes, sorry. This bug was inherited by cutting and pasting the ABNF from a pre-publication RFC3588 [Base]. I've just flushed all copies of that file from my system. sigh... Dave. From owner-aaa-wg@merit.edu Thu Mar 4 11:46: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 LAA01391 for ; Thu, 4 Mar 2004 11:46:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 584D8912E8; Thu, 4 Mar 2004 11:46:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29BE0912EB; Thu, 4 Mar 2004 11:46:13 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 052B2912E8 for ; Thu, 4 Mar 2004 11:46:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id E5E9C5DDD1; Thu, 4 Mar 2004 11:46:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id CE3755DDC6 for ; Thu, 4 Mar 2004 11:46:03 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i24Gu4Q13803; Thu, 4 Mar 2004 08:56:04 -0800 Date: Thu, 4 Mar 2004 08:56:04 -0800 (PST) From: Bernard Aboba To: David Mitton Cc: aaa-wg@merit.edu, Avi Lior Subject: Re: [AAA-WG]: NASREQ-14: Interim vs. Start Stop record when Reuathentication/Re uathorization In-Reply-To: <5.2.1.1.2.20040304104348.03545900@getmail.mitton.com> Message-ID: References: <5.2.1.1.2.20040304104348.03545900@getmail.mitton.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I disagree. I would like to hear other points of view on this. We encountered this issue in RFC 3576 due to addition of the dynamic authorization capabilities. However, I don't believe we clearly specified what types of RADIUS accounting messages should be sent as a result of an authorization change. > A connection oriented service may not care about such changes, infact they > may not be changes at all, just a re-affirmation of the intended and > authorized service. > > Thus I don't think a START or a STOP is appropriate. I would agree for a re-authentication. However, I'm not so sure about a change in authorizations. This could have implications for rating. At least in RADIUS, there is typically an assumption that INTERIM records are not retransmitted as aggressively. > Would it be more acceptable, to some, if we create yet another Accounting > Status-Type for (possible) Change-of-Service? I think this could complicate the RADIUS/Diameter gateway functionality. I'd prefer to make this work similarly in both RADIUS and DIAMETER. From owner-aaa-wg@merit.edu Thu Mar 4 11:56: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 LAA01896 for ; Thu, 4 Mar 2004 11:56:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 27676912E5; Thu, 4 Mar 2004 11:56:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ECF5E912ED; Thu, 4 Mar 2004 11:56:08 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D101C912E5 for ; Thu, 4 Mar 2004 11:56:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id B5CF35DE33; Thu, 4 Mar 2004 11:56:07 -0500 (EST) 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 3385E5DE2D for ; Thu, 4 Mar 2004 11:56:07 -0500 (EST) Received: (cpmta 6143 invoked from network); 4 Mar 2004 08:56:05 -0800 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.34.190) with SMTP; 4 Mar 2004 08:56:05 -0800 X-Sent: 4 Mar 2004 16:56:05 GMT Message-Id: <5.2.1.1.2.20040304112333.02fceec0@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 04 Mar 2004 11:46:40 -0500 To: Avi Lior , aaa-wg@merit.edu From: David Mitton Subject: Re: [AAA-WG]: NASREQ14: Problem with Acct-Session-Id and Session-Id 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 2/20/2004 02:14 PM -0500, Avi Lior wrote: >Problem with Acct-Session-Id and Session-Id > >Submitter name: Avi Lior >Submitter email address: avi@bridgewatersystems.com >Date first submitted: February 20th 2004 >Reference: >Document: NASREQ-14 >Comment type: Technical >Priority: S >Section: 9.2 >Rationale/Explanation of issue: > >When the corresponding response is received by the Translation Agent, it >says that >Acct-Session-Id attribute is to be placed in Session-Id. > >The problem is that Acct-Session-Id will always change when there are >multiple session in RADIUS. Huh?? If there are multiple sessions, then there has to be multiple Ids. My RADIUS sessions do not change Acct-Session-Id in mid-session. That doesn't make sense. >In diameter Session-Id remains constant and therefore placing it in >Session-Id will violate Diameter. Yes, but there is a another issue here too. >What really needs to happen is much more complex. > >Requested changes: > >Acct-Session-Id attribute should be placed in Accounting-Sub-Session-Id AVP. I think that works. But we're going in the wrong direction in Section 9.2 here. This section is primarily generating a RADIUS message from Diameter. It does need to translate the response, but the session identified information would be retained from transaction state cache. >The Translation Agent should be the one generating a Session-Id for the >session and its sub-sessions. > >It will place Session-Id in the diameter messages. Right, the bigger issue for the Diameter/RADIUS gateway is that Diameter has a unique Session-Id, that spans authentication and accounting, but RADIUS does not. Section 9.2 talks about Diameter to RADIUS translation. RADIUS doesn't have Session-Id attribute, only the Acct-Session-Id. So we can either drop Session-Id, substitute it for another attribute, or prepend/append it to something. As long as it's consistent and the RADIUS server is happy with the results. A possible algorithm would be prepending it to Accounting-Sub-Session-Id (which may not be present). That way preserving information, order and uniqueness. When doing the reverse translation (section 9.1) things get more interesting. I have taken the position that a RADIUS to Diameter gateway will have to synthesize unique Diameter Session-Ids for any RADIUS-side generated Access-Requests (or COAs and Disc-Reqs). And this would become part of the session state it would have to track for all messages that relate to that session, as long as it's active. Any discussion? Dave. From owner-aaa-wg@merit.edu Thu Mar 4 16:47:42 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 QAA15332 for ; Thu, 4 Mar 2004 16:47:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C16AB912F6; Thu, 4 Mar 2004 16:46:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90D30912F7; Thu, 4 Mar 2004 16:46:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4E3AC912F6 for ; Thu, 4 Mar 2004 16:46:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3555B5DD92; Thu, 4 Mar 2004 16:46:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by segue.merit.edu (Postfix) with ESMTP id 5AFC95DD97 for ; Thu, 4 Mar 2004 16:46:09 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40232.14074D7D" Subject: RE: [AAA-WG]: NASREQ-14: Interim vs. Start Stop record when Reuathentication/Re uathorization X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 4 Mar 2004 16:45:58 -0500 Message-ID: <8A16DAD84432534FBFC19FD92B50512F0D031F@ames.starentnetworks.com> Thread-Topic: [AAA-WG]: NASREQ-14: Interim vs. Start Stop record when Reuathentication/Re uathorization Thread-Index: AcQCCD+SY5qahHewR6WE/zJOlVoGWQAKGK2A From: "Fox, Dan" To: "Bernard Aboba" , "David Mitton" Cc: , "Avi Lior" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C40232.14074D7D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dave, =20 I had mentioned on this list earlier that a STOP/START would be = appropriate. But I would agree that if there has been no change of = authorization, then an INTERIM will suffice. =20 I just think that it is easier for back-end billing systems to simply = process all STOP records as separate billing records that do not = necessarily have to be correlated together with any other STOP or = INTERIM records. =20 -Dan Fox Starent Networks =20 -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = Bernard Aboba Sent: Thursday, March 04, 2004 11:56 AM To: David Mitton Cc: aaa-wg@merit.edu; Avi Lior Subject: Re: [AAA-WG]: NASREQ-14: Interim vs. Start Stop record when = Reuathentication/Re uathorization > I disagree. I would like to hear other points of view on this. We encountered this issue in RFC 3576 due to addition of the dynamic authorization capabilities. However, I don't believe we clearly = specified what types of RADIUS accounting messages should be sent as a result of = an authorization change. > A connection oriented service may not care about such changes, infact = they > may not be changes at all, just a re-affirmation of the intended and > authorized service. > > Thus I don't think a START or a STOP is appropriate. I would agree for a re-authentication. However, I'm not so sure about a change in authorizations. This could have implications for rating. At least in RADIUS, there is typically an assumption that INTERIM records = are not retransmitted as aggressively. > Would it be more acceptable, to some, if we create yet another = Accounting > Status-Type for (possible) Change-of-Service? I think this could complicate the RADIUS/Diameter gateway functionality. I'd prefer to make this work similarly in both RADIUS and DIAMETER. ------_=_NextPart_001_01C40232.14074D7D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [AAA-WG]: NASREQ-14: Interim vs. Start Stop record when = Reuathentication/Re uathorization
Dave,
 
I had=20 mentioned on this list earlier that a STOP/START would be = appropriate.  But=20 I would agree that if there has been no change of = authorization, then=20 an INTERIM will suffice.
 
I just=20 think that it is easier for back-end billing systems to simply process = all STOP=20 records as separate billing records that do not necessarily have to be=20 correlated together with any other STOP or INTERIM = records.
 
-Dan=20 Fox
Starent Networks
 
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of Bernard=20 Aboba
Sent: Thursday, March 04, 2004 11:56 AM
To: = David=20 Mitton
Cc: aaa-wg@merit.edu; Avi Lior
Subject: Re: = [AAA-WG]: NASREQ-14: Interim vs. Start Stop record when = Reuathentication/Re=20 uathorization

> I disagree.  I would like to hear other = points of=20 view on this.

We encountered this issue in RFC 3576 due to = addition of=20 the dynamic
authorization capabilities.  However, I don't = believe we=20 clearly specified
what types of RADIUS accounting messages should = be sent=20 as a result of an
authorization change.

> A connection = oriented=20 service may not care about such changes, infact they
> may not = be=20 changes at all, just a re-affirmation of the intended and
> = authorized=20 service.
>
> Thus I don't think a START or a STOP is=20 appropriate.

I would agree for a re-authentication.  = However, I'm=20 not so sure about a
change in authorizations.  This could have = implications for rating.  At
least in RADIUS, there is = typically an=20 assumption that INTERIM records are
not retransmitted as=20 aggressively.

> Would it be more acceptable, to some, if we = create=20 yet another Accounting
> Status-Type for (possible)=20 Change-of-Service?

I think this could complicate the = RADIUS/Diameter=20 gateway functionality.
I'd prefer to make this work similarly in = both=20 RADIUS and DIAMETER.

------_=_NextPart_001_01C40232.14074D7D-- From owner-aaa-wg@merit.edu Thu Mar 4 16:53: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 QAA15585 for ; Thu, 4 Mar 2004 16:53:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2C82E912F7; Thu, 4 Mar 2004 16:53:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3E21912F9; Thu, 4 Mar 2004 16:53:12 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7497F912F7 for ; Thu, 4 Mar 2004 16:53:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5DB665DDA2; Thu, 4 Mar 2004 16:53:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by segue.merit.edu (Postfix) with ESMTP id DEA0E5DDBE for ; Thu, 4 Mar 2004 16:53:10 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40233.0F5E0FC5" Subject: RE: [AAA-WG]: NASREQ14: Problem with Acct-Session-Id and Session-Id X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 4 Mar 2004 16:52:59 -0500 Message-ID: <8A16DAD84432534FBFC19FD92B50512F0D0320@ames.starentnetworks.com> Thread-Topic: [AAA-WG]: NASREQ14: Problem with Acct-Session-Id and Session-Id Thread-Index: AcQCCZtxZxsp5Ew2TwqJnMZ+lFC/FwAKJriw From: "Fox, Dan" To: "David Mitton" , "Avi Lior" , Cc: "Fox, Dan" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C40233.0F5E0FC5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dave, Comments below. =20 -Dan Fox Starent Networks -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = David Mitton Sent: Thursday, March 04, 2004 11:47 AM To: Avi Lior; aaa-wg@merit.edu Subject: Re: [AAA-WG]: NASREQ14: Problem with Acct-Session-Id and = Session-Id On 2/20/2004 02:14 PM -0500, Avi Lior wrote: >Problem with Acct-Session-Id and Session-Id > >Submitter name: Avi Lior >Submitter email address: avi@bridgewatersystems.com >Date first submitted: February 20th 2004 >Reference: >Document: NASREQ-14 >Comment type: Technical >Priority: S >Section: 9.2 >Rationale/Explanation of issue: > >When the corresponding response is received by the Translation Agent, = it >says that >Acct-Session-Id attribute is to be placed in Session-Id. > >The problem is that Acct-Session-Id will always change when there are >multiple session in RADIUS. Huh?? If there are multiple sessions, then there has to be multiple = Ids. My RADIUS sessions do not change Acct-Session-Id in mid-session. That doesn't make sense. [Fox, Dan] CDMA billing has a correlation id that matches all of the = accounting messages for a session, and each RADIUS START/STOP pair has a = different Acct-Session-ID. I *think* that's what Avi is referring to.=20 >In diameter Session-Id remains constant and therefore placing it in >Session-Id will violate Diameter. Yes, but there is a another issue here too. >What really needs to happen is much more complex. > >Requested changes: > >Acct-Session-Id attribute should be placed in Accounting-Sub-Session-Id = AVP. I think that works. But we're going in the wrong direction in Section = 9.2 here. This section is primarily generating a RADIUS message from Diameter. It does need to translate the response, but the session identified information would be retained from transaction state cache. >The Translation Agent should be the one generating a Session-Id for the >session and its sub-sessions. > >It will place Session-Id in the diameter messages. Right, the bigger issue for the Diameter/RADIUS gateway is that Diameter has a unique Session-Id, that spans authentication and accounting, but RADIUS does not. [Fox, Dan] CDMA billing has a 3GPP2-Correlation-ID which serves this = purpose, but this attribute is domain-specific to CDMA. At Starent, we, = however, use the same attribute (same Vendor ID and VSA type number) for = correlating HA accounting as well. Yes, we have customers that require = this for HA as well. We also put this ID into authentication messages = for the same session. Would it be appropriate here to define a new = attribute for RADIUS that does this?=20 Section 9.2 talks about Diameter to RADIUS translation. RADIUS doesn't have Session-Id attribute, only the Acct-Session-Id. So we can either drop Session-Id, substitute it for another attribute, = or prepend/append it to something. As long as it's consistent and the = RADIUS server is happy with the results. A possible algorithm would be = prepending it to Accounting-Sub-Session-Id (which may not be present). That way preserving information, order and uniqueness. When doing the reverse translation (section 9.1) things get more = interesting. I have taken the position that a RADIUS to Diameter gateway will have to synthesize unique Diameter Session-Ids for any RADIUS-side generated Access-Requests (or COAs and Disc-Reqs). And this would become part of = the session state it would have to track for all messages that relate to = that session, as long as it's active. Any discussion? Dave. =20 ------_=_NextPart_001_01C40233.0F5E0FC5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [AAA-WG]: NASREQ14: Problem with Acct-Session-Id and = Session-Id
Dave,

Comments = below.
 
-Dan Fox
Starent Networks
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of David=20 Mitton
Sent: Thursday, March 04, 2004 11:47 AM
To: = Avi=20 Lior; aaa-wg@merit.edu
Subject: Re: [AAA-WG]: NASREQ14: = Problem with=20 Acct-Session-Id and Session-Id

On 2/20/2004 02:14 PM -0500, Avi Lior = wrote:
>Problem=20 with Acct-Session-Id and Session-Id
>
>Submitter name: Avi = Lior
>Submitter email address: = avi@bridgewatersystems.com
>Date=20 first submitted: February 20th 2004
>Reference:
>Document: = NASREQ-14
>Comment type: Technical
>Priority: = S
>Section:=20 9.2
>Rationale/Explanation of issue:
>
>When the=20 corresponding response is received by the Translation Agent, = it
>says=20 that
>Acct-Session-Id attribute is to be placed in=20 Session-Id.
>
>The problem is that Acct-Session-Id will = always=20 change when there are
>multiple session in = RADIUS.

Huh??  If=20 there are multiple sessions, then there has to be multiple Ids.
My = RADIUS=20 sessions do not change Acct-Session-Id in mid-session.  = That
doesn't=20 make sense.
[Fox, Dan] CDMA billing has a correlation id = that=20 matches all of the accounting messages for a session, and each RADIUS=20 START/STOP pair has a different Acct-Session-ID.  I *think* = that's=20 what Avi is referring to. 

>In diameter=20 Session-Id remains constant and therefore placing it = in
>Session-Id will=20 violate Diameter.

Yes, but there is a another issue here=20 too.


>What really needs to happen is much more=20 complex.
>
>Requested = changes:
>
>Acct-Session-Id=20 attribute should be placed in Accounting-Sub-Session-Id AVP.

I = think=20 that works.  But we're going in the wrong direction in Section=20 9.2
here.
This section is primarily generating a RADIUS message = from=20 Diameter.
It does need to translate the response, but the session=20 identified
information would be retained from transaction state=20 cache.


>The Translation Agent should be the one = generating a=20 Session-Id for the
>session and its = sub-sessions.
>
>It will=20 place Session-Id in the diameter messages.

Right, the bigger = issue for=20 the Diameter/RADIUS gateway is that Diameter
has a unique = Session-Id, that=20 spans authentication and accounting, but
RADIUS does not.
[Fox, = Dan] CDMA=20 billing has a 3GPP2-Correlation-ID which serves this purpose, but = this=20 attribute is domain-specific to CDMA.  At Starent, we, = however, use=20 the same attribute (same Vendor ID and VSA type number) for = correlating=20 HA accounting as well.  Yes, we have customers = that require=20 this for HA as well.  We also put this ID into = authentication=20 messages for the same session.  Would it be appropriate here to = define a=20 new attribute for RADIUS that does=20 this? 

Section 9.2 talks about Diameter to = RADIUS=20 translation.
RADIUS doesn't have Session-Id attribute, only the=20 Acct-Session-Id.

So we can either drop Session-Id, substitute = it for=20 another attribute, or
prepend/append it to something.  As long = as it's=20 consistent and the RADIUS
server is happy with the results.  A = possible algorithm would be prepending
it to = Accounting-Sub-Session-Id=20 (which may not be present).  That way
preserving information, = order=20 and uniqueness.

When doing the reverse translation (section = 9.1) things=20 get more interesting.

I have taken the position that a RADIUS = to=20 Diameter gateway will have to
synthesize unique Diameter = Session-Ids for=20 any RADIUS-side generated
Access-Requests (or COAs and = Disc-Reqs). =20 And this would become part of the
session state it would have to = track for=20 all messages that relate to that
session, as long as it's=20 active.


Any discussion?

Dave.

 

------_=_NextPart_001_01C40233.0F5E0FC5-- From aaa-admin@ietf.org Thu Mar 4 17:38: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 RAA17697 for ; Thu, 4 Mar 2004 17:38:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1Te-0004kF-39; Thu, 04 Mar 2004 17:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1TX-0004iA-De for aaa@optimus.ietf.org; Thu, 04 Mar 2004 17:37:55 -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 RAA17669 for ; Thu, 4 Mar 2004 17:37:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az1TV-0004tj-00 for aaa@ietf.org; Thu, 04 Mar 2004 17:37:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az1Se-0004kT-00 for aaa@ietf.org; Thu, 04 Mar 2004 17:37:00 -0500 Received: from [194.125.87.16] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1Az1SC-0004Zv-00 for aaa@ietf.org; Thu, 04 Mar 2004 17:36:32 -0500 Message-ID: From: "Andy Keller" To: aaa@ietf.org Date: Thu, 04 Mar 2004 19:38:57 -0300 X-Mailer: social solitaire miranda-herd: isocline dairyman alibi MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--024634886153841028" 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.2 required=5.0 tests=HTML_60_70, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text Subject: [Aaa] don't miss out on that great job - get your university degree now! 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: , ----024634886153841028 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET
descend real finnegan grave diaphragm ca= ndid emcee inject fabian parimutuel hater starboard blink restroom devonsh= ire liquid deft=20 ----024634886153841028-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Mar 4 17:39:23 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 RAA17728 for ; Thu, 4 Mar 2004 17:39:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1UW-0004zV-0K for aaa-archive@odin.ietf.org; Thu, 04 Mar 2004 17:38:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24MctBg019181 for aaa-archive@odin.ietf.org; Thu, 4 Mar 2004 17:38:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1UV-0004zI-OD for aaa-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 17:38:55 -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 RAA17721 for ; Thu, 4 Mar 2004 17:38:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az1UT-00053w-00 for aaa-web-archive@ietf.org; Thu, 04 Mar 2004 17:38:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az1Tk-0004u4-00 for aaa-web-archive@ietf.org; Thu, 04 Mar 2004 17:38:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1Te-0004kF-39; Thu, 04 Mar 2004 17:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1TX-0004iA-De for aaa@optimus.ietf.org; Thu, 04 Mar 2004 17:37:55 -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 RAA17669 for ; Thu, 4 Mar 2004 17:37:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az1TV-0004tj-00 for aaa@ietf.org; Thu, 04 Mar 2004 17:37:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az1Se-0004kT-00 for aaa@ietf.org; Thu, 04 Mar 2004 17:37:00 -0500 Received: from [194.125.87.16] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1Az1SC-0004Zv-00 for aaa@ietf.org; Thu, 04 Mar 2004 17:36:32 -0500 Message-ID: From: "Andy Keller" To: aaa@ietf.org Date: Thu, 04 Mar 2004 19:38:57 -0300 X-Mailer: social solitaire miranda-herd: isocline dairyman alibi MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--024634886153841028" 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.2 required=5.0 tests=HTML_60_70, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text Subject: [Aaa] don't miss out on that great job - get your university degree now! 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: , ----024634886153841028 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

GET YOUR UNIVERSITY DIPLOMA

Do yo= u want a prosperou= s future, increased earning power
more money and the respect of all?

Ca<= !b>ll this number: 

1-720-834-2989

(24 hours)

 

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1-720-834-2989

     (7 days a week)=

    Confidentiality a<= !r>ssured!
     

    W= e are located in USA  international= callers are very welcome

    •
    descend real finnegan grave diaphragm ca= ndid emcee inject fabian parimutuel hater starboard blink restroom devonsh= ire liquid deft=20 ----024634886153841028-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Fri Mar 5 09:11:50 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 JAA08923 for ; Fri, 5 Mar 2004 09:11:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8DD529130C; Fri, 5 Mar 2004 09:11:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3EFB39130B; Fri, 5 Mar 2004 09:11:35 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5B1339124E for ; Fri, 5 Mar 2004 09:11:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3E7565E050; Fri, 5 Mar 2004 09:11:31 -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 ABE245E040 for ; Fri, 5 Mar 2004 09:11:29 -0500 (EST) 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 i25EBMC23980 for ; Fri, 5 Mar 2004 16:11:22 +0200 (EET) X-Scanned: Fri, 5 Mar 2004 16:09:02 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i25E92YX018833 for ; Fri, 5 Mar 2004 16:09:02 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 000dodJz; Fri, 05 Mar 2004 16:09:00 EET 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 i25E8x714464 for ; Fri, 5 Mar 2004 16:08:59 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 5 Mar 2004 16:08:58 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 5 Mar 2004 16:08:59 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: DCC Issue: some AVP occurence inconsistency between commands and table Date: Fri, 5 Mar 2004 16:08:59 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B04AD@esebe016.ntc.nokia.com> Thread-Topic: DCC Issue: some AVP occurence inconsistency between commands and table Thread-Index: AcQCu2dDWCvokHcMTXi0kYLBuXvnww== From: To: X-OriginalArrivalTime: 05 Mar 2004 14:08:59.0609 (UTC) FILETIME=[67C17C90:01C402BB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Description of issue: some AVP occurence inconsistency between = commands and table Submitter name: Marco Stura Date first submitted: 5.03.2004=20 Reference:=20 Document: draft-ietf-aaa-diameter-cc-03.txt=20 Comment type: E Priority: 1=20 Section: 3.1 and 3.2 Rationale/Explanation of issue There is an inconsistence between the occurence of the CC-Correlation-Id = AVP in section 3.1 and the occurence of the same AVP in the table of section 10.1. In the = command multiple instances of this AVP are possible while in the table only 0-1. The other way round concerning the Subscription-Id and the Redirect-Host = AVPs. I think what is indicated in the table is the right one.=20 Requested change: - Section 3.1 FROM ::=3D < Diameter Header: 272, REQ, PXY >=20 < Session-Id > : : : : *[ CC-Correlation-Id ]=20 : : : : TO ::=3D < Diameter Header: 272, REQ, PXY >=20 < Session-Id > : : : : [ CC-Correlation-Id ]=20 : : : : - Section 3.2 FROM ::=3D < Diameter Header: 272, PXY >=20 < Session-Id > : : : : [ Subscription-Id ] =20 : : [ Redirect-Host AVP ]=20 : : TO ::=3D < Diameter Header: 272, PXY >=20 < Session-Id > : : : : *[ Subscription-Id ] =20 : : *[ Redirect-Host AVP ]=20 : : From owner-aaa-wg@merit.edu Fri Mar 5 09:26: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 JAA09570 for ; Fri, 5 Mar 2004 09:26:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6E58E9124E; Fri, 5 Mar 2004 09:26:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 35F7A91250; Fri, 5 Mar 2004 09:26:35 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0756E9124E for ; Fri, 5 Mar 2004 09:26:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id E19835E02A; Fri, 5 Mar 2004 09:26:33 -0500 (EST) 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 23C835E051 for ; Fri, 5 Mar 2004 09:26:33 -0500 (EST) 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 i25EQVS24155 for ; Fri, 5 Mar 2004 16:26:31 +0200 (EET) X-Scanned: Fri, 5 Mar 2004 16:25:06 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i25EP6Dt031960 for ; Fri, 5 Mar 2004 16:25:06 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00epnPW3; Fri, 05 Mar 2004 16:25:04 EET 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 i25EOw725967 for ; Fri, 5 Mar 2004 16:24:58 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 5 Mar 2004 16:24:58 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: DCC Issue: It is not clear where the content of the CC-Correlation-Id AVP is defined Date: Fri, 5 Mar 2004 16:24:58 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B04AE@esebe016.ntc.nokia.com> Thread-Topic: DCC Issue: It is not clear where the content of the CC-Correlation-Id AVP is defined Thread-Index: AcQCvaMWL3A0tH5AQ4GRvly0ns7Ixg== From: To: X-OriginalArrivalTime: 05 Mar 2004 14:24:58.0384 (UTC) FILETIME=[A33AF100:01C402BD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Description of issue: It is not clear where the content of the = CC-Correlation-Id AVP is defined Submitter name: Marco Stura Date first submitted: 5.03.2004=20 Reference:=20 Document: draft-ietf-aaa-diameter-cc-03.txt=20 Comment type: E Priority: 1=20 Section: 3.1 and 3.2 Rationale/Explanation of issue In section 8.1 it is stated that the CC-Correlation-Id AVP contains = information to correlate requests generated for different components of a service, but = it is not mentioned what is the actual content and encoding of this AVP. I think it is appropriate to add similar text as in section 8.43. Requested change: - Section 8.1 FROM The CC-Correlation-Id AVP (AVP Code 411) is type of OctetString and=20 contains information to correlate credit control requests generated=20 for different components of the service, e.g. transport and service=20 level.=20 TO The CC-Correlation-Id AVP (AVP Code 411) is of type OctetString and=20 contains information to correlate credit control requests generated=20 for different components of the service, e.g. transport and service=20 level. The one who allocates the Service-Identifier, i.e. unique identifier of a service, is also responsible to define the content and encoding of the CC-Correlation-Id AVP. =20 From owner-aaa-wg@merit.edu Fri Mar 5 10:05: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 KAA11765 for ; Fri, 5 Mar 2004 10:05:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DAEE39124F; Fri, 5 Mar 2004 10:05:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A89CB91308; Fri, 5 Mar 2004 10:05:28 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5780B9124F for ; Fri, 5 Mar 2004 10:05:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 424B95E04C; Fri, 5 Mar 2004 10:05:27 -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 804F65E02B for ; Fri, 5 Mar 2004 10:05:26 -0500 (EST) 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 i25F5PC16948 for ; Fri, 5 Mar 2004 17:05:25 +0200 (EET) X-Scanned: Fri, 5 Mar 2004 17:04:39 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i25F4do0030734 for ; Fri, 5 Mar 2004 17:04:39 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00ITsOgA; Fri, 05 Mar 2004 17:04:39 EET 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 i25F4c721444 for ; Fri, 5 Mar 2004 17:04:38 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 5 Mar 2004 17:04:38 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: DCC Issue: Editorial Section 8.16 M-S-C-C AVP Date: Fri, 5 Mar 2004 17:04:38 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B04AF@esebe016.ntc.nokia.com> Thread-Topic: DCC Issue: Editorial Section 8.16 M-S-C-C AVP Thread-Index: AcQCwy23zSHSHz6cRxqD8Bcn+Ves8A== From: To: X-OriginalArrivalTime: 05 Mar 2004 15:04:38.0105 (UTC) FILETIME=[2DA78C90:01C402C3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Description of issue: It is not clear where the content of the = CC-Correlation-Id AVP is defined Submitter name: Marco Stura Date first submitted: 5.03.2004=20 Reference:=20 Document: draft-ietf-aaa-diameter-cc-03.txt=20 Comment type: E Priority: 1=20 Section: 8.16 Rationale/Explanation of issue In fourth paragraph of section 8.16 there is a text saying "Note that in = case these two quotas are grouped within the same pool, the credit = pooling mechanism as defined in section 5.1.1 applies."=20 Since the two quotas may draw resources from different pools I guess the = right sentence should be: "Where the two quotas are associated to the same pool or to different = pools, the credit pooling mechanism as defined in section 5.1.1 = applies." Requested change: - Section 8.16 third paragraph FROM When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are=20 present, the server MUST include two separate instances of the=20 Multiple-Services-Credit-Control AVP with the Granted-Service-Unit = AVP=20 associated to the same Service-Identifier and/or Rating-Group. Note=20 that in case these two quotas are grouped within the same pool, the=20 credit pooling mechanism as defined in section 5.1.1 applies. =20 The Tariff-Change-Usage AVP MUST NOT be included in request commands, = to report used units before and after tariff time change the Used- Service-Unit AVP MUST be used. TO When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are=20 present, the server MUST include two separate instances of the=20 Multiple-Services-Credit-Control AVP with the Granted-Service-Unit = AVP=20 associated to the same Service-Identifier and/or Rating-Group. Where=20 the two quotas are associated to the same pool or to different pools, = the credit pooling mechanism as defined in section 5.1.1 applies.=20 The Tariff-Change-Usage AVP MUST NOT be included in request commands, = to report used units before and after tariff time change the Used- Service-Unit AVP MUST be used. From aaa-admin@ietf.org Fri Mar 5 14:31: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 OAA24326 for ; Fri, 5 Mar 2004 14:31: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 1AzL2G-0004fb-4g; Fri, 05 Mar 2004 14:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzL28-0004e6-I9 for aaa@optimus.ietf.org; Fri, 05 Mar 2004 14:30:56 -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 OAA24222 for ; Fri, 5 Mar 2004 14:30:51 -0500 (EST) From: primsweepstake@juno.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzL23-0002kR-00 for aaa@ietf.org; Fri, 05 Mar 2004 14:30:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzL0L-0002DQ-00 for aaa@ietf.org; Fri, 05 Mar 2004 14:29:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AzKzE-0001ym-01 for aaa@ietf.org; Fri, 05 Mar 2004 14:27:56 -0500 Received: from 77.red-80-25-253.pooles.rima-tde.net ([80.25.253.77] helo=myhost) by mx2.foretec.com with esmtp (Exim 4.24) id 1AzKwl-0005mv-6B for aaa@ietf.org; Fri, 05 Mar 2004 14:25:23 -0500 To: aaa@ietf.org Content-Type: text/plain; charset="US-ASCII" Reply-To: primsweepstake@juno.com Date: Fri, 5 Mar 2004 20:24:58 +0100 X-Priority: 3 X-Library: Indy 9.0.3-B X-Mailer: Foxmail 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=5.4 required=5.0 tests=AWL,FORGED_JUNO_RCVD, LINES_OF_YELLING,LINES_OF_YELLING_2,NO_REAL_NAME,SUBJ_ALL_CAPS, UPPERCASE_75_100,X_LIBRARY autolearn=no version=2.60 X-Spam-Report: * 1.4 X_LIBRARY Message has X-Library header * 0.3 NO_REAL_NAME From: does not include a real name * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 LINES_OF_YELLING_2 BODY: 2 WHOLE LINES OF YELLING DETECTED * 0.6 SUBJ_ALL_CAPS Subject is all capitals * 2.8 FORGED_JUNO_RCVD 'From' juno.com does not match 'Received' headers * 0.0 UPPERCASE_75_100 message body is 75-100% uppercase * 0.3 AWL AWL: Auto-whitelist adjustment Subject: [Aaa] AWARD WINNER 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: , LOTTERIA PRIMITIVA SWEEPSTAKE PROMOTION. CALLE/BUSMAN EL-BUENO, 13728007 MADRID SPAIN. FROM: THE DESK OF THE PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: LP/26510460037/02 BATCH: 24/00319/IPD AWARD NOTIFICATION FINAL NOTICE. WE ARE PLEASE TO INFORM YOU OF THE ANNOUNCEMENT OF THE WINNERS OF LOTTERY PRIMITIVA SWEEPSTAKES/INTERNATIONAL PROGRAMS HELD ON 15 TH JANUARY 2004. YOUR CONTACT IS ATTACHED TO THE TICKET NUMBER 004-05117963-198, WITH SERIAL NUMBER 99375 DREW THE LUCKY NUMBERS 01-15-37-38-48-49 AND CONSEQUENTLY WON THE LOTTERY IN CATEGORY 1B. YOU HAVE BEEN THEREFORE APPROVED THE SUM OF €800,500.00(EIGHT HUNDRED THOUSAND, FIVE HUNDRED EUROS)CREDITED TO THE FILE NUMBER:LP/2656043/ES/104 THIS IS FROM THE TOTAL PRICE MONEY OF €31.472.765.00 SHARED AMONG THE TWENTY THREE LOCAL AND INTERNATIONAL WINNERS IN ALL CATEGORIES. ALL PARTICIPANTS WERE SELECTED THROUGH COMPUTER BALOTTING SYSTEM DRAWN FROM 45,000.00 NAMES FROM AUSTRALIA, NEW ZEALAND, AFRICA, EUROPE,AMERICA AND ASIA AS PART OF OUR INTERNATIONAL PROMOTION PROGRAM WHICH IS CONDUCTED EVERY TWO YEARS. . CONGRATULATIONS!!! YOUR FUND IS NOW INSURED TO YOUR CONTACT. DUE TO THE COMPUTER MIX-UP OF SOME NUMBERS AND CONTACTS, WE ASK YOU TO KEEP THIS AWARD STRICKLY FROM PUBLIC NOTICE UNTILL YOUR CLAIM HAS BEING PROCESSED AND YOUR MONEY REMITTED TO YOUR NOMINATED ACCOUNT.THIS IS PART OF OUR SECURITY ADVICE TO AVOID DOUBLE CLAIMING OR UNSCRUPULOUS ACTS BY THE PARTICIPANTS OF THIS PROGRAM. YOU ARE TO CONTACT THE UNDERSIGNED, SINCE ALL WE HAVE NOW IS THE WINNING TICKET NUMBER AND YOUR EMAIL ADDRESS WHICH WAS ATTACHED TO THE WINNING TICKET NUMBER.FOR DUE PROCESSING AND REMITTANCE OF YOUR AWARD PRICE, YOU ARE TO REPLY THIS MAIL STATING YOUR NUMBERS. DO NOTE THAT ALL PRICE MUST BE CLAIM NOT LATER THAN 7TH APRIL 2004. AFTER THIS DATE, ALL FUNDS WILL BE RETURNED AS UNCLAIMED TO THE MINISTRY. . NOTE: IN ORDER TO AVOID UNNECESSARY DELAY AND COMPLICATIONS,PLEASE QOUTE YOUR REFERENCE AND BATCH NUMBERS IN EVERY OF YOUR CORESPONDENCE. FURTHERMORE,SHOULD THERE BE ANY CHANGE OF YOUR ADDRESS DO INFORM THIS OFFICE AS SOON AS POSSIBLE. CONGRATULATIONS AGAIN FROM ALL OUR STAFF. SINCERELY DENNIS COLE 0034-627747095: CALL NOW FOR CONFIRMATION. SEND ANOTHER COPY OF YOUR REPLY TO THE FOLLOWING: lottoffice@excite.com _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Fri Mar 5 14:32:55 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 OAA24451 for ; Fri, 5 Mar 2004 14:32:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzL3d-0004tW-Jt for aaa-archive@odin.ietf.org; Fri, 05 Mar 2004 14:32:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25JWTXx018813 for aaa-archive@odin.ietf.org; Fri, 5 Mar 2004 14:32:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzL3d-0004tM-FG for aaa-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 14:32:29 -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 OAA24441 for ; Fri, 5 Mar 2004 14:32:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzL3Z-00039Z-00 for aaa-web-archive@ietf.org; Fri, 05 Mar 2004 14:32:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzL2F-0002m7-00 for aaa-web-archive@ietf.org; Fri, 05 Mar 2004 14:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzL2G-0004fb-4g; Fri, 05 Mar 2004 14:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzL28-0004e6-I9 for aaa@optimus.ietf.org; Fri, 05 Mar 2004 14:30:56 -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 OAA24222 for ; Fri, 5 Mar 2004 14:30:51 -0500 (EST) From: primsweepstake@juno.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzL23-0002kR-00 for aaa@ietf.org; Fri, 05 Mar 2004 14:30:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzL0L-0002DQ-00 for aaa@ietf.org; Fri, 05 Mar 2004 14:29:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AzKzE-0001ym-01 for aaa@ietf.org; Fri, 05 Mar 2004 14:27:56 -0500 Received: from 77.red-80-25-253.pooles.rima-tde.net ([80.25.253.77] helo=myhost) by mx2.foretec.com with esmtp (Exim 4.24) id 1AzKwl-0005mv-6B for aaa@ietf.org; Fri, 05 Mar 2004 14:25:23 -0500 To: aaa@ietf.org Content-Type: text/plain; charset="US-ASCII" Reply-To: primsweepstake@juno.com Date: Fri, 5 Mar 2004 20:24:58 +0100 X-Priority: 3 X-Library: Indy 9.0.3-B X-Mailer: Foxmail 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=5.4 required=5.0 tests=AWL,FORGED_JUNO_RCVD, LINES_OF_YELLING,LINES_OF_YELLING_2,NO_REAL_NAME,SUBJ_ALL_CAPS, UPPERCASE_75_100,X_LIBRARY autolearn=no version=2.60 X-Spam-Report: * 1.4 X_LIBRARY Message has X-Library header * 0.3 NO_REAL_NAME From: does not include a real name * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 LINES_OF_YELLING_2 BODY: 2 WHOLE LINES OF YELLING DETECTED * 0.6 SUBJ_ALL_CAPS Subject is all capitals * 2.8 FORGED_JUNO_RCVD 'From' juno.com does not match 'Received' headers * 0.0 UPPERCASE_75_100 message body is 75-100% uppercase * 0.3 AWL AWL: Auto-whitelist adjustment Subject: [Aaa] AWARD WINNER 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: , LOTTERIA PRIMITIVA SWEEPSTAKE PROMOTION. CALLE/BUSMAN EL-BUENO, 13728007 MADRID SPAIN. FROM: THE DESK OF THE PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: LP/26510460037/02 BATCH: 24/00319/IPD AWARD NOTIFICATION FINAL NOTICE. WE ARE PLEASE TO INFORM YOU OF THE ANNOUNCEMENT OF THE WINNERS OF LOTTERY PRIMITIVA SWEEPSTAKES/INTERNATIONAL PROGRAMS HELD ON 15 TH JANUARY 2004. YOUR CONTACT IS ATTACHED TO THE TICKET NUMBER 004-05117963-198, WITH SERIAL NUMBER 99375 DREW THE LUCKY NUMBERS 01-15-37-38-48-49 AND CONSEQUENTLY WON THE LOTTERY IN CATEGORY 1B. YOU HAVE BEEN THEREFORE APPROVED THE SUM OF €800,500.00(EIGHT HUNDRED THOUSAND, FIVE HUNDRED EUROS)CREDITED TO THE FILE NUMBER:LP/2656043/ES/104 THIS IS FROM THE TOTAL PRICE MONEY OF €31.472.765.00 SHARED AMONG THE TWENTY THREE LOCAL AND INTERNATIONAL WINNERS IN ALL CATEGORIES. ALL PARTICIPANTS WERE SELECTED THROUGH COMPUTER BALOTTING SYSTEM DRAWN FROM 45,000.00 NAMES FROM AUSTRALIA, NEW ZEALAND, AFRICA, EUROPE,AMERICA AND ASIA AS PART OF OUR INTERNATIONAL PROMOTION PROGRAM WHICH IS CONDUCTED EVERY TWO YEARS. . CONGRATULATIONS!!! YOUR FUND IS NOW INSURED TO YOUR CONTACT. DUE TO THE COMPUTER MIX-UP OF SOME NUMBERS AND CONTACTS, WE ASK YOU TO KEEP THIS AWARD STRICKLY FROM PUBLIC NOTICE UNTILL YOUR CLAIM HAS BEING PROCESSED AND YOUR MONEY REMITTED TO YOUR NOMINATED ACCOUNT.THIS IS PART OF OUR SECURITY ADVICE TO AVOID DOUBLE CLAIMING OR UNSCRUPULOUS ACTS BY THE PARTICIPANTS OF THIS PROGRAM. YOU ARE TO CONTACT THE UNDERSIGNED, SINCE ALL WE HAVE NOW IS THE WINNING TICKET NUMBER AND YOUR EMAIL ADDRESS WHICH WAS ATTACHED TO THE WINNING TICKET NUMBER.FOR DUE PROCESSING AND REMITTANCE OF YOUR AWARD PRICE, YOU ARE TO REPLY THIS MAIL STATING YOUR NUMBERS. DO NOTE THAT ALL PRICE MUST BE CLAIM NOT LATER THAN 7TH APRIL 2004. AFTER THIS DATE, ALL FUNDS WILL BE RETURNED AS UNCLAIMED TO THE MINISTRY. . NOTE: IN ORDER TO AVOID UNNECESSARY DELAY AND COMPLICATIONS,PLEASE QOUTE YOUR REFERENCE AND BATCH NUMBERS IN EVERY OF YOUR CORESPONDENCE. FURTHERMORE,SHOULD THERE BE ANY CHANGE OF YOUR ADDRESS DO INFORM THIS OFFICE AS SOON AS POSSIBLE. CONGRATULATIONS AGAIN FROM ALL OUR STAFF. SINCERELY DENNIS COLE 0034-627747095: CALL NOW FOR CONFIRMATION. SEND ANOTHER COPY OF YOUR REPLY TO THE FOLLOWING: lottoffice@excite.com _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Sat Mar 6 17:27: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 RAA07335 for ; Sat, 6 Mar 2004 17:27:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9DE7F9121A; Sat, 6 Mar 2004 17:26:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63A719121D; Sat, 6 Mar 2004 17:26:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 530A29121A for ; Sat, 6 Mar 2004 17:26:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id E77FF5E0C0; Sat, 6 Mar 2004 17:26:46 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id 7E82D5E0BB for ; Sat, 6 Mar 2004 17:26:46 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i26MQdU25847; Sat, 6 Mar 2004 16:26:39 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 6 Mar 2004 16:26:40 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304DDD5C6@zrc2c012.us.nortel.com> From: "Christopher Richards" To: aaa-wg@merit.edu Cc: "Harri Hakala (TU/LMF)" , "Marco Stura (E-mail)" , "'Leena Mattila (TU/LMF)'" Subject: [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in CCR Date: Sat, 6 Mar 2004 16:26:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C403CA.171EF65E" 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_01C403CA.171EF65E Content-Type: text/plain; charset="iso-8859-1" Hi, After some discussions, I have updated the original proposal for sending the IMEI from the DCC client to the server. Since the IMEISV format is already well defined and described, I did not see the need to convert it to another format. Additionally, the included definition allows for the inclusion of the device software version along with the IMEI. I included the general EUI64 type format for use by unspecified equipment types. Submitter name: Chris Richards Submitter email address: crich@nortelnetworks.com Date first submitted: 19 Feb 2004 Reference: issue 22 Document: Diameter Credit Control Comment type: T Priority: 1 Section: Rationale/Explanation of issue: CHANGED SECTION 3.1 Credit-Control-Request (CCR) Command FROM: ... *[ Service-Parameter-Info ] *[ CC-Correlation-Id ] *[ Proxy-Info ] *[ Route-Record ] *[ AVP ] TO: ... *[ Service-Parameter-Info ] *[ CC-Correlation-Id ] *[ Proxy-Info ] *[ Route-Record ] [ User-Equipment-Info ] *[ AVP ] CHANGED SECTION 5.2 First Interrogation 3rd para FROM ... The Event-Timestamp AVP contains the time when the service event is requested in the service element. The Subscription-Id AVP SHOULD be included to identify the End-User in the credit-control server. ... TO: ... The Event-Timestamp AVP contains the time when the service event is requested in the service element. The Subscription-Id AVP SHOULD be included to identify the End-User in the credit-control server. The credit control client MAY include the User-Equipment-Info AVP so that the credit control server has some indication about the type and capabilities of the end user access device. How the credit control server uses this information is outside the scope of this document. ... CHANGED SECTION 8. Credit Control AVPs FROM ... Unit-Value 445 8.8 Grouped | M | P | | V | Y | Used-Service-Unit 446 8.19 Grouped | M | P | | V | Y | Value-Digits 447 8.10 Integer64 | M | P | | V | Y | Validity-Time 448 8.33 Unsigned32 | M | P | | V | Y | TO: ... Unit-Value 445 8.8 Grouped | M | P | | V | Y | Used-Service-Unit 446 8.19 Grouped | M | P | | V | Y | User-Equipment TBD 8.48 Grouped | | P | | V | Y | -Info | | | | | | User-Equipment TBD 8.49 Unsigned32 | | P | | V | Y | -Type | | | | | | User-Equipment TBD 8.50 UTF8String | | P | | V | Y | -Value | | | | | | Value-Digits 447 8.10 Integer64 | M | P | | V | Y | Validity-Time 448 8.33 Unsigned32 | M | P | | V | Y | NEW SECTIONS 8.48 to 8.50: 8.48 User-Equipment-Info AVP The User-Equipment-Info AVP (AVP Code TBD) is of type Grouped, and allows the Credit-control client to indicate the identity and capability of the terminal the subscriber is using for the connection to network. It has the following ABNF grammar: User-Equipment-Info ::= < AVP Header: TBD > { User-Equipment-Info-Type } { User-Equipment-Info-Value } 8.49 User-Equipment-Info-Type AVP The User-Equipment-Info-Type AVP is of type Unsigned32 (AVP Code TBD) and defines the type of the user equipment information contained in the User-Equipment-Info-Value AVP. The identifier can be one of the following: IMEISV 0 The identifier contains the International Mobile Equipment Identifier and Software Version in the international IMEISV format according to 3GPP TS 23.003 [3GPPIMEI]. MAC 1 The 48-bit MAC address is formatted as described in [RAD802.1X]. EUI64 2 There are a number of types of terminals that have identifiers other than 3GPP IMEI or IEEE 802 MACs. These identifiers can be converted to modified EUI-64 format as described in [IPv6Addr]. 8.50 User-Equipment-Info-Value AVP The User-Equipment-Info-Value AVP (AVP Code TBD) is of type UTF8String. The User-Equipment-Info-Type AVP defines which type of identifier is used. CHANGED SECTION 10.1 Credit Control AVP Table FROM: ... Used-Service-Unit | 0+ | 0 | User-Name | 0-1 | 0-1 | Validity-Time | 0 | 0-1 | ------------------------------|-----+-----+ TO: ... Used-Service-Unit | 0+ | 0 | User-Equipment-Info | 0-1 | 0 | User-Name | 0-1 | 0-1 | Validity-Time | 0 | 0-1 | ------------------------------|-----+-----+ NEW SECTION: 12.18 User-Equipment-Info-Type AVP As defined in Section 8.49, the User-Equipment-Info-Type AVP (AVP Code TBD) defines the values 0-2. All remaining values are available for assignment via Designated Expert [IANA]. CHANGED SECTION 15.1 Normative FROM: ... ADD: ... [RAD802.1X] P. Congdon, et.al "IEEE 802.1X RADIUS Usage Guidelines", RFC 3580, September 2003. [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. [3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-12 ------_=_NextPart_001_01C403CA.171EF65E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in = CCR

    Hi,

    After some discussions, I have updated the original = proposal for sending the IMEI from the DCC client to the server. Since = the IMEISV format is already well defined and described, I did not see = the need to convert it to another format. Additionally, the included = definition allows for the inclusion of the device software version = along with the IMEI. I included the general EUI64 type format for use = by unspecified equipment types.

    Submitter name: Chris Richards
    Submitter email address: = crich@nortelnetworks.com
    Date first submitted: 19 Feb 2004
    Reference: issue 22
    Document: Diameter Credit Control
    Comment type: T
    Priority: 1
    Section:
    Rationale/Explanation of issue:

    CHANGED SECTION 3.1 Credit-Control-Request (CCR) = Command
    FROM:
    ...
              &nb= sp;           &nb= sp;           &nb= sp; *[ Service-Parameter-Info ] 
              &nb= sp;           &nb= sp;           &nb= sp; *[ CC-Correlation-Id ]
              &nb= sp;           &nb= sp;           &nb= sp; *[ Proxy-Info ]
              &nb= sp;           &nb= sp;           &nb= sp; *[ Route-Record ]
              &nb= sp;           &nb= sp;           &nb= sp; *[ AVP ]

    TO:
    ...
              &nb= sp;           &nb= sp;           &nb= sp; *[ Service-Parameter-Info ] 
              &nb= sp;           &nb= sp;           &nb= sp; *[ CC-Correlation-Id ]
              &nb= sp;           &nb= sp;           &nb= sp; *[ Proxy-Info ]
              &nb= sp;           &nb= sp;           &nb= sp; *[ Route-Record ]
              &nb= sp;           &nb= sp;           &nb= sp;  [ User-Equipment-Info ]
              &nb= sp;           &nb= sp;           &nb= sp; *[ AVP ]


    CHANGED SECTION 5.2 First Interrogation  3rd = para
    FROM
    ...
       The Event-Timestamp AVP contains the = time when the service event is
       requested in the service element. The = Subscription-Id AVP SHOULD be
       included to identify the End-User in = the credit-control server. 
    ...        =
           
    TO:
    ...
       The Event-Timestamp AVP contains the = time when the service event is
       requested in the service element. The = Subscription-Id AVP SHOULD be
       included to identify the End-User in = the credit-control server. The
       credit control client MAY include the = User-Equipment-Info AVP so
       that the credit control server has some = indication about the type
       and capabilities of the end user access = device. How the credit
       control server uses this information is = outside the scope of this
       document.
    ...


    CHANGED SECTION 8. Credit Control AVPs 
    FROM
    ...
       = Unit-Value        445  = 8.8    Grouped    | M  |  = P  |    |  V  | Y  |
       Used-Service-Unit 446  = 8.19   Grouped    | M  |  P  = |    |  V  | Y  | 
       = Value-Digits      447  8.10   = Integer64  | M  |  P  |    |  = V  | Y  |
       Validity-Time     = 448  8.33   Unsigned32 | M  |  P  = |    |  V  | Y  |
      
    TO:
    ...
       = Unit-Value        445  = 8.8    Grouped    | M  |  = P  |    |  V  | Y  |
       Used-Service-Unit 446  = 8.19   Grouped    | M  |  P  = |    |  V  | Y  | 
       User-Equipment    = TBD  8.48   Grouped    = |    |  P  |    |  V  = | Y  |
         = -Info           &= nbsp;           &= nbsp;          = |    |     |    = |     |    |
       User-Equipment    = TBD  8.49   Unsigned32 |    |  = P  |    |  V  | Y  |
         -Type    = ;            = ;            = ;      |    = |     |    |     = |    |
       User-Equipment    = TBD  8.50   UTF8String |    |  = P  |    |  V  | Y  |
         = -Value           =             =           = |    |     |    = |     |    |
       = Value-Digits      447  8.10   = Integer64  | M  |  P  |    |  = V  | Y  |
       Validity-Time     = 448  8.33   Unsigned32 | M  |  P  = |    |  V  | Y  |



    NEW SECTIONS 8.48 to 8.50:
    8.48 User-Equipment-Info AVP

       The User-Equipment-Info AVP (AVP Code = TBD) is of type Grouped, and
       allows the Credit-control client to = indicate the identity and capability
       of the terminal the subscriber is using = for the connection to network.
      
       It has the following ABNF = grammar: 
           
              &nb= sp;      User-Equipment-Info ::=3D < AVP = Header: TBD > 
              &nb= sp;           &nb= sp;           &nb= sp;      { User-Equipment-Info-Type }  =
              &nb= sp;           &nb= sp;           &nb= sp;      { User-Equipment-Info-Value }  =


    8.49 User-Equipment-Info-Type AVP

       The User-Equipment-Info-Type AVP is of = type Unsigned32 (AVP Code TBD)
       and defines the type of the user = equipment information contained in
       the User-Equipment-Info-Value = AVP.
      
       The identifier can be one of the = following: 
           
          = IMEISV           =             =             =          0 
       
               = The identifier contains the International Mobile Equipment
               = Identifier and Software Version in the international IMEISV
               = format according to 3GPP TS 23.003 [3GPPIMEI]. 
              &nb= sp;    
          = MAC           &nb= sp;           &nb= sp;           &nb= sp;           1  =
               = The 48-bit MAC address is formatted as described in
               = [RAD802.1X].
               =
          = EUI64           &= nbsp;           &= nbsp;           &= nbsp;         2
         
               = There are a number of types of terminals that have identifiers
               = other than 3GPP IMEI or IEEE 802 MACs. These identifiers can
               = be converted to modified EUI-64 format as described in
               = [IPv6Addr].
       
    8.50 User-Equipment-Info-Value AVP

       The User-Equipment-Info-Value AVP (AVP = Code TBD) is of type UTF8String.
       The User-Equipment-Info-Type AVP = defines which type of identifier is
       used. 
       
      
    CHANGED SECTION 10.1 Credit Control AVP Table  =
    FROM:
    ...
             = Used-Service-Unit         &= nbsp;   | 0+  | 0   |
             = User-Name          &nb= sp;          | 0-1 | 0-1 | =
             = Validity-Time          = ;       | 0   | 0-1 |
             = ------------------------------|-----+-----+ 

    TO:
    ...
             = Used-Service-Unit         &= nbsp;   | 0+  | 0   |
             = User-Equipment-Info         = ;  | 0-1 | 0   |
             = User-Name          &nb= sp;          | 0-1 | 0-1 | =
             = Validity-Time          = ;       | 0   | 0-1 |
             = ------------------------------|-----+-----+ 

    NEW SECTION:

    12.18 User-Equipment-Info-Type AVP 
           
       As defined in Section 8.49, the = User-Equipment-Info-Type AVP (AVP
       Code TBD) defines the values 0-2. All = remaining values are
       available for assignment via Designated = Expert [IANA]. 
      
      
    CHANGED SECTION 15.1 Normative 
    FROM:
    ...

    ADD:
    ...
       [RAD802.1X]   P. Congdon, = et.al "IEEE 802.1X RADIUS Usage Guidelines",
              &nb= sp;      RFC 3580, September 2003.
        
       [EUI64]      = IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
              &nb= sp;     Registration Authority",
              &nb= sp;     http://standards.ieee.org/regauth/oui/tutorials/EUI64.= html,
              &nb= sp;     March 1997.

       [3GPPIMEI]   3rd Generation = Partnership Project; Technical
              &nb= sp;     Specification Group Core Network, = Numbering, addressing
              &nb= sp;     and identification, (release 5), 3GPP TS = 23.003
              &nb= sp;     v. 5.8.0, 2003-12   

    ------_=_NextPart_001_01C403CA.171EF65E-- From aaa-admin@ietf.org Sat Mar 6 20:34:43 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 UAA14442 for ; Sat, 6 Mar 2004 20:34:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AznB2-0000qO-Uu; Sat, 06 Mar 2004 20:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AznB2-0000qD-2J for aaa@optimus.ietf.org; Sat, 06 Mar 2004 20:34: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 UAA14416 for ; Sat, 6 Mar 2004 20:33:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AznAz-00006V-00 for aaa@ietf.org; Sat, 06 Mar 2004 20:33:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AznA6-0007mq-00 for aaa@ietf.org; Sat, 06 Mar 2004 20:33:02 -0500 Received: from c-24-4-134-119.client.comcast.net ([24.4.134.119] helo=24.4.134.119) by ietf-mx with smtp (Exim 4.12) id 1Azn9H-0007fD-00 for aaa@ietf.org; Sat, 06 Mar 2004 20:32:11 -0500 From: hostmaster@cnchost.com To: aaa@ietf.org Date: Sat, 06 Mar 2004 17:34:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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=12.3 required=5.0 tests=FORGED_MUA_OUTLOOK,IMPOTENCE, MSGID_FROM_MTA_SHORT,NO_REAL_NAME,RCVD_NUMERIC_HELO,SUBJ_YOUR_DEBT, VIAGRA autolearn=no version=2.60 X-Spam-Report: * 0.7 SUBJ_YOUR_DEBT Subject contains "Your Bills" or similar * 0.3 NO_REAL_NAME From: does not include a real name * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 4.2 IMPOTENCE BODY: Impotence cure * 1.9 VIAGRA BODY: Plugs Viagra * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Content-Transfer-Encoding: 7bit Subject: [Aaa] Your credit card has been successfully charged for $69.95 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 Administration of www.shadowcrew.com online store would like to thank you for your purchase of Viagra tablets. Couple of words about our products and services. Viagra is a prescription drug used to treat erection difficulties, such as erectile dysfunction, which also refers to as an impotence. At this condition men do not experience normal erection, necessary for the sexual act. VIAGRA works only in reply to sexual excitation and does not influence reproductive function in any way. Your tablets will be sent to the address specified by you within 24 hours. You should store VIAGRA at temperature below 30 degrees in original packing and out of reach of children. Do not take preparation after expiry date which is located on top of the package. We are the only official dealers that offer you tablets in original packaging. We guarantee to refund your money during 30 days. If you never purchased this product please contact us at: 1.888.575.6398 To cancel this purchase please contact us at: 1.408-817-2800 To change the shipping address on the order: 1.877.999.8779 If you suffer any side effects please contact: 1.866.963.9696 For bulk purchases please contact: 1.703.547.2000 Thank you for choosing www.shadowcrew.com We are the first - the best. _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sat Mar 6 20:43:55 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 UAA14740 for ; Sat, 6 Mar 2004 20:43:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AznKB-0001o0-Kg for aaa-archive@odin.ietf.org; Sat, 06 Mar 2004 20:43:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i271hRPc006934 for aaa-archive@odin.ietf.org; Sat, 6 Mar 2004 20:43:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AznKB-0001nl-Gt for aaa-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 20:43:27 -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 UAA14736 for ; Sat, 6 Mar 2004 20:43:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AznK9-0001Kv-00 for aaa-web-archive@ietf.org; Sat, 06 Mar 2004 20:43:25 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AznIy-00019B-00 for aaa-web-archive@ietf.org; Sat, 06 Mar 2004 20:42:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AznBI-000632-25 for aaa-web-archive@ietf.org; Sat, 06 Mar 2004 20:34:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AznB2-0000qO-Uu; Sat, 06 Mar 2004 20:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AznB2-0000qD-2J for aaa@optimus.ietf.org; Sat, 06 Mar 2004 20:34: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 UAA14416 for ; Sat, 6 Mar 2004 20:33:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AznAz-00006V-00 for aaa@ietf.org; Sat, 06 Mar 2004 20:33:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AznA6-0007mq-00 for aaa@ietf.org; Sat, 06 Mar 2004 20:33:02 -0500 Received: from c-24-4-134-119.client.comcast.net ([24.4.134.119] helo=24.4.134.119) by ietf-mx with smtp (Exim 4.12) id 1Azn9H-0007fD-00 for aaa@ietf.org; Sat, 06 Mar 2004 20:32:11 -0500 From: hostmaster@cnchost.com To: aaa@ietf.org Date: Sat, 06 Mar 2004 17:34:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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=12.3 required=5.0 tests=FORGED_MUA_OUTLOOK,IMPOTENCE, MSGID_FROM_MTA_SHORT,NO_REAL_NAME,RCVD_NUMERIC_HELO,SUBJ_YOUR_DEBT, VIAGRA autolearn=no version=2.60 X-Spam-Report: * 0.7 SUBJ_YOUR_DEBT Subject contains "Your Bills" or similar * 0.3 NO_REAL_NAME From: does not include a real name * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 4.2 IMPOTENCE BODY: Impotence cure * 1.9 VIAGRA BODY: Plugs Viagra * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Content-Transfer-Encoding: 7bit Subject: [Aaa] Your credit card has been successfully charged for $69.95 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 Administration of www.shadowcrew.com online store would like to thank you for your purchase of Viagra tablets. Couple of words about our products and services. Viagra is a prescription drug used to treat erection difficulties, such as erectile dysfunction, which also refers to as an impotence. At this condition men do not experience normal erection, necessary for the sexual act. VIAGRA works only in reply to sexual excitation and does not influence reproductive function in any way. Your tablets will be sent to the address specified by you within 24 hours. You should store VIAGRA at temperature below 30 degrees in original packing and out of reach of children. Do not take preparation after expiry date which is located on top of the package. We are the only official dealers that offer you tablets in original packaging. We guarantee to refund your money during 30 days. If you never purchased this product please contact us at: 1.888.575.6398 To cancel this purchase please contact us at: 1.408-817-2800 To change the shipping address on the order: 1.877.999.8779 If you suffer any side effects please contact: 1.866.963.9696 For bulk purchases please contact: 1.703.547.2000 Thank you for choosing www.shadowcrew.com We are the first - the best. _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Mon Mar 8 00:21: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 AAA26453 for ; Mon, 8 Mar 2004 00:21:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8262B9127F; Mon, 8 Mar 2004 00:19:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4BEAD912CE; Mon, 8 Mar 2004 00:19:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4363C9127F for ; Mon, 8 Mar 2004 00:18:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id E25CF5EB65; Mon, 8 Mar 2004 00:18:56 -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 AD4425E994 for ; Mon, 8 Mar 2004 00:18:53 -0500 (EST) 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 i285IpC20489 for ; Mon, 8 Mar 2004 07:18:52 +0200 (EET) X-Scanned: Mon, 8 Mar 2004 07:18:36 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i285IaLk002629 for ; Mon, 8 Mar 2004 07:18:36 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00H2Whgr; Mon, 08 Mar 2004 07:18:34 EET 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 i285IYO11612 for ; Mon, 8 Mar 2004 07:18:34 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Mar 2004 07:18:33 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: DCC Issue: some AVP occurence inconsistency between commands and table Date: Mon, 8 Mar 2004 07:18:34 +0200 Message-ID: Thread-Topic: DCC Issue: some AVP occurence inconsistency between commands and table thread-index: AcQCu2dDWCvokHcMTXi0kYLBuXvnwwCEWHiw From: To: , X-OriginalArrivalTime: 08 Mar 2004 05:18:33.0316 (UTC) FILETIME=[CD0BD240:01C404CC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Assigned Issue 29. > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext=20 > Sent: 05 March, 2004 16:09 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: DCC Issue: some AVP occurence inconsistency between > commands and table >=20 >=20 >=20 > Description of issue: some AVP occurence inconsistency=20 > between commands and table > Submitter name: Marco Stura > Date first submitted: 5.03.2004=20 > Reference:=20 > Document: draft-ietf-aaa-diameter-cc-03.txt=20 > Comment type: E > Priority: 1=20 > Section: 3.1 and 3.2 >=20 > Rationale/Explanation of issue >=20 > There is an inconsistence between the occurence of the=20 > CC-Correlation-Id AVP in section 3.1 > and the occurence of the same AVP in the table of section=20 > 10.1. In the command multiple > instances of this AVP are possible while in the table only 0-1. > The other way round concerning the Subscription-Id and the=20 > Redirect-Host AVPs. >=20 > I think what is indicated in the table is the right one.=20 >=20 > Requested change: >=20 > - Section 3.1 >=20 > FROM >=20 > ::=3D < Diameter Header: 272, REQ, PXY >=20 > < Session-Id > > : > : > : > : > *[ CC-Correlation-Id ]=20 > : > : > : > : > TO >=20 > ::=3D < Diameter Header: 272, REQ, PXY >=20 > < Session-Id > > : > : > : > : > [ CC-Correlation-Id ]=20 > : > : > : > : >=20 > - Section 3.2 >=20 > FROM >=20 > ::=3D < Diameter Header: 272, PXY >=20 > < Session-Id > > : > : > : > : > [ Subscription-Id ] =20 > : > : > [ Redirect-Host AVP ]=20 > : > : >=20 > TO >=20 > ::=3D < Diameter Header: 272, PXY >=20 > < Session-Id > > : > : > : > : > *[ Subscription-Id ] =20 > : > : > *[ Redirect-Host AVP ]=20 > : > : >=20 From owner-aaa-wg@merit.edu Mon Mar 8 00:21: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 AAA26532 for ; Mon, 8 Mar 2004 00:21:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1DD6D9132C; Mon, 8 Mar 2004 00:20:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CAD9991332; Mon, 8 Mar 2004 00:20:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 92A3E9132C for ; Mon, 8 Mar 2004 00:19:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id D310B5EBD5; Mon, 8 Mar 2004 00:19:57 -0500 (EST) 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 53CD05EBB0 for ; Mon, 8 Mar 2004 00:19:56 -0500 (EST) 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 i285JtS11038 for ; Mon, 8 Mar 2004 07:19:55 +0200 (EET) X-Scanned: Mon, 8 Mar 2004 07:19:38 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i285JcfI004538 for ; Mon, 8 Mar 2004 07:19:38 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00YMKFVT; Mon, 08 Mar 2004 07:19:37 EET 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 i285JbO11863 for ; Mon, 8 Mar 2004 07:19:37 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Mar 2004 07:19:36 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: DCC Issue: It is not clear where the content of the CC-Correlation-Id AVP is defined Date: Mon, 8 Mar 2004 07:19:37 +0200 Message-ID: Thread-Topic: DCC Issue: It is not clear where the content of the CC-Correlation-Id AVP is defined thread-index: AcQCvaMWL3A0tH5AQ4GRvly0ns7IxgCD0qxg From: To: , X-OriginalArrivalTime: 08 Mar 2004 05:19:36.0956 (UTC) FILETIME=[F2FA83C0:01C404CC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Assigned Issue 30. > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext=20 > Sent: 05 March, 2004 16:25 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: DCC Issue: It is not clear where the content of the > CC-Correlation-Id AVP is defined >=20 >=20 >=20 > Description of issue: It is not clear where the content of=20 > the CC-Correlation-Id AVP is defined > Submitter name: Marco Stura > Date first submitted: 5.03.2004=20 > Reference:=20 > Document: draft-ietf-aaa-diameter-cc-03.txt=20 > Comment type: E > Priority: 1=20 > Section: 3.1 and 3.2 >=20 > Rationale/Explanation of issue >=20 > In section 8.1 it is stated that the CC-Correlation-Id AVP=20 > contains information to > correlate requests generated for different components of a=20 > service, but it is not > mentioned what is the actual content and encoding of this AVP. >=20 > I think it is appropriate to add similar text as in section 8.43. >=20 > Requested change: >=20 > - Section 8.1 >=20 > FROM >=20 > The CC-Correlation-Id AVP (AVP Code 411) is type of=20 > OctetString and=20 > contains information to correlate credit control requests=20 > generated=20 > for different components of the service, e.g. transport=20 > and service=20 > level.=20 >=20 > TO >=20 > The CC-Correlation-Id AVP (AVP Code 411) is of type=20 > OctetString and=20 > contains information to correlate credit control requests=20 > generated=20 > for different components of the service, e.g. transport=20 > and service=20 > level. The one who allocates the Service-Identifier, i.e. unique > identifier of a service, is also responsible to define the content > and encoding of the CC-Correlation-Id AVP. =20 >=20 >=20 From owner-aaa-wg@merit.edu Mon Mar 8 00:26: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 AAA26676 for ; Mon, 8 Mar 2004 00:26:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D41799127B; Mon, 8 Mar 2004 00:26:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A3D629127D; Mon, 8 Mar 2004 00:26:01 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4A9F69127B for ; Mon, 8 Mar 2004 00:26:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 35A545EC00; Mon, 8 Mar 2004 00:26:00 -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 53E6C5EBF8 for ; Mon, 8 Mar 2004 00:25:59 -0500 (EST) 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 i285PwC24802 for ; Mon, 8 Mar 2004 07:25:58 +0200 (EET) X-Scanned: Mon, 8 Mar 2004 07:25:38 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i285PcU5030357 for ; Mon, 8 Mar 2004 07:25:38 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00LHaBH2; Mon, 08 Mar 2004 07:25:37 EET 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 i285Pa723312 for ; Mon, 8 Mar 2004 07:25:36 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Mar 2004 07:25:35 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: DCC Issue: Editorial Section 8.16 M-S-C-C AVP Date: Mon, 8 Mar 2004 07:25:36 +0200 Message-ID: Thread-Topic: DCC Issue: Editorial Section 8.16 M-S-C-C AVP thread-index: AcQCwy23zSHSHz6cRxqD8Bcn+Ves8ACCpBGQ From: To: , X-OriginalArrivalTime: 08 Mar 2004 05:25:35.0843 (UTC) FILETIME=[C8E45330:01C404CD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Assigned issue 32, with a new title "Editorial issue on credit pooling" > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext=20 > Sent: 05 March, 2004 17:05 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: DCC Issue: Editorial Section 8.16 M-S-C-C AVP >=20 >=20 >=20 >=20 > Description of issue: It is not clear where the content of=20 > the CC-Correlation-Id AVP is defined > Submitter name: Marco Stura > Date first submitted: 5.03.2004=20 > Reference:=20 > Document: draft-ietf-aaa-diameter-cc-03.txt=20 > Comment type: E > Priority: 1=20 > Section: 8.16 >=20 > Rationale/Explanation of issue >=20 > In fourth paragraph of section 8.16 there is a text saying=20 > "Note that in case these two quotas are grouped within the=20 > same pool, the credit pooling mechanism as defined in section=20 > 5.1.1 applies."=20 >=20 > Since the two quotas may draw resources from different pools=20 > I guess the right sentence should be: >=20 > "Where the two quotas are associated to the same pool or to=20 > different pools, the credit pooling mechanism as defined in=20 > section 5.1.1 applies." >=20 > Requested change: >=20 > - Section 8.16 third paragraph >=20 > FROM >=20 >=20 > When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are=20 > present, the server MUST include two separate instances of the=20 > Multiple-Services-Credit-Control AVP with the=20 > Granted-Service-Unit AVP=20 > associated to the same Service-Identifier and/or=20 > Rating-Group. Note=20 > that in case these two quotas are grouped within the same=20 > pool, the=20 > credit pooling mechanism as defined in section 5.1.1 applies. =20 > The Tariff-Change-Usage AVP MUST NOT be included in=20 > request commands,=20 > to report used units before and after tariff time change the Used- > Service-Unit AVP MUST be used. >=20 > TO >=20 >=20 > When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are=20 > present, the server MUST include two separate instances of the=20 > Multiple-Services-Credit-Control AVP with the=20 > Granted-Service-Unit AVP=20 > associated to the same Service-Identifier and/or=20 > Rating-Group. Where=20 > the two quotas are associated to the same pool or to=20 > different pools,=20 > the credit pooling mechanism as defined in section 5.1.1 applies.=20 > The Tariff-Change-Usage AVP MUST NOT be included in=20 > request commands,=20 > to report used units before and after tariff time change the Used- > Service-Unit AVP MUST be used. >=20 From owner-aaa-wg@merit.edu Mon Mar 8 00:26: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 AAA26694 for ; Mon, 8 Mar 2004 00:26:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4694B9127D; Mon, 8 Mar 2004 00:26:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B51D291280; Mon, 8 Mar 2004 00:26:37 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C1B0B9127D for ; Mon, 8 Mar 2004 00:26:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id A025D5EC02; Mon, 8 Mar 2004 00:26:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 557705EBEC for ; Mon, 8 Mar 2004 00:26:33 -0500 (EST) 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 i285QWZ14536; Mon, 8 Mar 2004 07:26:32 +0200 (EET) X-Scanned: Mon, 8 Mar 2004 07:26:24 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i285QO2X031120; Mon, 8 Mar 2004 07:26:24 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00fMYl10; Mon, 08 Mar 2004 07:26:23 EET 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 i285QM723553; Mon, 8 Mar 2004 07:26:22 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Mar 2004 07:26:21 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C404CD.E4A1F7E0" Subject: RE: [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in CCR Date: Mon, 8 Mar 2004 07:26:22 +0200 Message-ID: Thread-Topic: [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in CCR thread-index: AcQDzZhBa5o5W3Y5SbmjpI8qiYKuWABAEg1A From: To: , Cc: , , X-OriginalArrivalTime: 08 Mar 2004 05:26:21.0939 (UTC) FILETIME=[E45E0430:01C404CD] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C404CD.E4A1F7E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Issue updated. -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Christopher Richards Sent: 07 March, 2004 00:27 To: aaa-wg@merit.edu Cc: Harri Hakala (TU/LMF); Stura Marco (Nokia-NET/Helsinki); 'Leena = Mattila (TU/LMF)' Subject: [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in CCR Hi,=20 After some discussions, I have updated the original proposal for sending = the IMEI from the DCC client to the server. Since the IMEISV format is = already well defined and described, I did not see the need to convert it = to another format. Additionally, the included definition allows for the = inclusion of the device software version along with the IMEI. I included = the general EUI64 type format for use by unspecified equipment types. Submitter name: Chris Richards=20 Submitter email address: crich@nortelnetworks.com=20 Date first submitted: 19 Feb 2004=20 Reference: issue 22=20 Document: Diameter Credit Control=20 Comment type: T=20 Priority: 1=20 Section:=20 Rationale/Explanation of issue:=20 CHANGED SECTION 3.1 Credit-Control-Request (CCR) Command=20 FROM:=20 ...=20 *[ Service-Parameter-Info ] =20 *[ CC-Correlation-Id ]=20 *[ Proxy-Info ]=20 *[ Route-Record ]=20 *[ AVP ]=20 TO:=20 ...=20 *[ Service-Parameter-Info ] =20 *[ CC-Correlation-Id ]=20 *[ Proxy-Info ]=20 *[ Route-Record ]=20 [ User-Equipment-Info ]=20 *[ AVP ]=20 CHANGED SECTION 5.2 First Interrogation 3rd para=20 FROM=20 ...=20 The Event-Timestamp AVP contains the time when the service event is=20 requested in the service element. The Subscription-Id AVP SHOULD be=20 included to identify the End-User in the credit-control server. =20 ... =20 =20 TO:=20 ...=20 The Event-Timestamp AVP contains the time when the service event is=20 requested in the service element. The Subscription-Id AVP SHOULD be=20 included to identify the End-User in the credit-control server. The=20 credit control client MAY include the User-Equipment-Info AVP so=20 that the credit control server has some indication about the type=20 and capabilities of the end user access device. How the credit=20 control server uses this information is outside the scope of this=20 document.=20 ...=20 CHANGED SECTION 8. Credit Control AVPs =20 FROM=20 ...=20 Unit-Value 445 8.8 Grouped | M | P | | V | Y | = Used-Service-Unit 446 8.19 Grouped | M | P | | V | Y | = =20 Value-Digits 447 8.10 Integer64 | M | P | | V | Y | = Validity-Time 448 8.33 Unsigned32 | M | P | | V | Y | = =20 TO:=20 ...=20 Unit-Value 445 8.8 Grouped | M | P | | V | Y | = Used-Service-Unit 446 8.19 Grouped | M | P | | V | Y | = =20 User-Equipment TBD 8.48 Grouped | | P | | V | Y | = -Info | | | | | | = User-Equipment TBD 8.49 Unsigned32 | | P | | V | Y | = -Type | | | | | | = User-Equipment TBD 8.50 UTF8String | | P | | V | Y | = -Value | | | | | | = Value-Digits 447 8.10 Integer64 | M | P | | V | Y | = Validity-Time 448 8.33 Unsigned32 | M | P | | V | Y | = NEW SECTIONS 8.48 to 8.50:=20 8.48 User-Equipment-Info AVP=20 The User-Equipment-Info AVP (AVP Code TBD) is of type Grouped, and=20 allows the Credit-control client to indicate the identity and = capability=20 of the terminal the subscriber is using for the connection to = network.=20 =20 It has the following ABNF grammar: =20 =20 User-Equipment-Info ::=3D < AVP Header: TBD > =20 { User-Equipment-Info-Type } =20 { User-Equipment-Info-Value } =20 8.49 User-Equipment-Info-Type AVP=20 The User-Equipment-Info-Type AVP is of type Unsigned32 (AVP Code TBD) = and defines the type of the user equipment information contained in=20 the User-Equipment-Info-Value AVP.=20 =20 The identifier can be one of the following: =20 =20 IMEISV 0 =20 =20 The identifier contains the International Mobile Equipment=20 Identifier and Software Version in the international IMEISV=20 format according to 3GPP TS 23.003 [3GPPIMEI]. =20 =20 MAC 1 =20 The 48-bit MAC address is formatted as described in=20 [RAD802.1X].=20 =20 EUI64 2=20 =20 There are a number of types of terminals that have = identifiers=20 other than 3GPP IMEI or IEEE 802 MACs. These identifiers can=20 be converted to modified EUI-64 format as described in=20 [IPv6Addr].=20 =20 8.50 User-Equipment-Info-Value AVP=20 The User-Equipment-Info-Value AVP (AVP Code TBD) is of type = UTF8String.=20 The User-Equipment-Info-Type AVP defines which type of identifier is=20 used. =20 =20 =20 CHANGED SECTION 10.1 Credit Control AVP Table =20 FROM:=20 ...=20 Used-Service-Unit | 0+ | 0 |=20 User-Name | 0-1 | 0-1 |=20 Validity-Time | 0 | 0-1 |=20 ------------------------------|-----+-----+ =20 TO:=20 ...=20 Used-Service-Unit | 0+ | 0 |=20 User-Equipment-Info | 0-1 | 0 |=20 User-Name | 0-1 | 0-1 |=20 Validity-Time | 0 | 0-1 |=20 ------------------------------|-----+-----+ =20 NEW SECTION:=20 12.18 User-Equipment-Info-Type AVP =20 =20 As defined in Section 8.49, the User-Equipment-Info-Type AVP (AVP=20 Code TBD) defines the values 0-2. All remaining values are=20 available for assignment via Designated Expert [IANA]. =20 =20 =20 CHANGED SECTION 15.1 Normative =20 FROM:=20 ...=20 ADD:=20 ...=20 [RAD802.1X] P. Congdon, et.al "IEEE 802.1X RADIUS Usage = Guidelines",=20 RFC 3580, September 2003.=20 =20 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)=20 Registration Authority",=20 = http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,=20 March 1997.=20 [3GPPIMEI] 3rd Generation Partnership Project; Technical=20 Specification Group Core Network, Numbering, addressing=20 and identification, (release 5), 3GPP TS 23.003=20 v. 5.8.0, 2003-12 =20 ------_=_NextPart_001_01C404CD.E4A1F7E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in = CCR
    Issue=20 updated.
    -----Original Message-----
    From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher=20 Richards
    Sent: 07 March, 2004 00:27
    To:=20 aaa-wg@merit.edu
    Cc: Harri Hakala (TU/LMF); Stura Marco=20 (Nokia-NET/Helsinki); 'Leena Mattila (TU/LMF)'
    Subject: = [AAA-WG]:=20 DCC Issue 22: (Updated) Inclusion of IMEISV in = CCR

    Hi,

    After some discussions, I have updated the original = proposal=20 for sending the IMEI from the DCC client to the server. Since the = IMEISV=20 format is already well defined and described, I did not see the need = to=20 convert it to another format. Additionally, the included definition = allows for=20 the inclusion of the device software version along with the IMEI. I = included=20 the general EUI64 type format for use by unspecified equipment=20 types.

    Submitter name: Chris Richards
    Submitter email address: crich@nortelnetworks.com =
    Date first submitted: 19 Feb 2004
    Reference:=20 issue 22
    Document: Diameter Credit = Control=20
    Comment type: T
    Priority: = 1=20
    Section:
    Rationale/Explanation of=20 issue:

    CHANGED SECTION 3.1 Credit-Control-Request (CCR) = Command=20
    FROM:
    ... =
              &nbs= p;            = ;            = =20 *[ Service-Parameter-Info ] 
              &nbs= p;            = ;            = =20 *[ CC-Correlation-Id ]
              &nbs= p;            = ;            = =20 *[ Proxy-Info ]
              &nbs= p;            = ;            = =20 *[ Route-Record ]
              &nbs= p;            = ;            = =20 *[ AVP ]

    TO:
    ...
              &nbs= p;            = ;            = =20 *[ Service-Parameter-Info ] 
              &nbs= p;            = ;            = =20 *[ CC-Correlation-Id ]
              &nbs= p;            = ;            = =20 *[ Proxy-Info ]
              &nbs= p;            = ;            = =20 *[ Route-Record ]
              &nbs= p;            = ;            =  =20 [ User-Equipment-Info ]
              &nbs= p;            = ;            = =20 *[ AVP ]


    CHANGED SECTION 5.2 First Interrogation  3rd = para=20
    FROM
    ...
       The Event-Timestamp AVP contains the time when = the service=20 event is
       requested in the = service=20 element. The Subscription-Id AVP SHOULD be
       included to identify the End-User in the = credit-control=20 server. 
    ...        =
           
    TO:
    ...
      =20 The Event-Timestamp AVP contains the time when the service event is=20
       requested in the service = element. The=20 Subscription-Id AVP SHOULD be
       = included to=20 identify the End-User in the credit-control server. The =
       credit control client MAY include the = User-Equipment-Info=20 AVP so
       that the credit control = server has=20 some indication about the type
       = and=20 capabilities of the end user access device. How the credit =
       control server uses this information is outside = the scope=20 of this
       document. =
    ...


    CHANGED SECTION 8. Credit Control AVPs  =
    FROM
    ...
      =20 Unit-Value        445 =20 8.8    Grouped    | M  |  = P =20 |    |  V  | Y  |
       Used-Service-Unit 446  8.19  =20 Grouped    | M  |  P  = |   =20 |  V  | Y  | 
      =20 Value-Digits      447  8.10  =20 Integer64  | M  |  P  |    |  = V =20 | Y  |
      =20 Validity-Time     448  8.33   = Unsigned32 |=20 M  |  P  |    |  V  | Y  = |=20
      
    TO:=20
    ...
      =20 Unit-Value        445 =20 8.8    Grouped    | M  |  = P =20 |    |  V  | Y  |
       Used-Service-Unit 446  8.19  =20 Grouped    | M  |  P  = |   =20 |  V  | Y  | 
      =20 User-Equipment    TBD  8.48  =20 Grouped    |    |  P =20 |    |  V  | Y  |
        =20 = -Info           &n= bsp;           &nb= sp;         =20 |    |     |   =20 |     |    |
       User-Equipment    TBD =20 8.49   Unsigned32 |    |  P =20 |    |  V  | Y  |
        =20 = -Type           &n= bsp;           &nb= sp;         =20 |    |     |   =20 |     |    |
       User-Equipment    TBD =20 8.50   UTF8String |    |  P =20 |    |  V  | Y  |
        =20 = -Value           &= nbsp;           &n= bsp;        =20 |    |     |   =20 |     |    |
       Value-Digits      = 447 =20 8.10   Integer64  | M  |  P  = |   =20 |  V  | Y  |
      =20 Validity-Time     448  8.33   = Unsigned32 |=20 M  |  P  |    |  V  | Y  = |=20



    NEW SECTIONS 8.48 to 8.50:
    8.48=20 User-Equipment-Info AVP

       The User-Equipment-Info AVP (AVP Code = TBD) is of=20 type Grouped, and
       allows the=20 Credit-control client to indicate the identity and capability =
       of the terminal the subscriber is using for the = connection=20 to network.
      
       It has the following ABNF grammar:  =
           
              &nbs= p;     =20 User-Equipment-Info ::=3D < AVP Header: TBD >  =
              &nbs= p;            = ;            =      =20 { User-Equipment-Info-Type } 
              &nbs= p;            = ;            =      =20 { User-Equipment-Info-Value } 


    8.49 User-Equipment-Info-Type AVP

       The User-Equipment-Info-Type AVP is of = type=20 Unsigned32 (AVP Code TBD)
       and = defines the=20 type of the user equipment information contained in
       the User-Equipment-Info-Value AVP. =
      
       The = identifier can be=20 one of the following: 
           
         =20 = IMEISV           &= nbsp;           &n= bsp;           &nb= sp;       =20 0 
       
               = The=20 identifier contains the International Mobile Equipment =
               = Identifier=20 and Software Version in the international IMEISV
               = format=20 according to 3GPP TS 23.003 [3GPPIMEI]. 
              &nbs= p;    =20
         =20 = MAC           &nbs= p;            = ;            =           =20 1 
               = The 48-bit=20 MAC address is formatted as described in
              =20 [RAD802.1X].
              =20
         =20 = EUI64           &n= bsp;           &nb= sp;           &nbs= p;        =20 2
          =
               = There are=20 a number of types of terminals that have identifiers
               = other than=20 3GPP IMEI or IEEE 802 MACs. These identifiers can
               = be=20 converted to modified EUI-64 format as described in
              =20 [IPv6Addr].
        =
    8.50 User-Equipment-Info-Value AVP

       The User-Equipment-Info-Value AVP (AVP = Code TBD)=20 is of type UTF8String.
       The=20 User-Equipment-Info-Type AVP defines which type of identifier = is=20
       used. 
       
      =20
    CHANGED SECTION 10.1 Credit Control AVP = Table =20
    FROM:
    ... =
            =20 = Used-Service-Unit         &n= bsp;  =20 | 0+  | 0   |
            =20 = User-Name          &nbs= p;         =20 | 0-1 | 0-1 |
            =20 = Validity-Time          =       =20 | 0   | 0-1 |
            =20 ------------------------------|-----+-----+ 

    TO:
    ...
            =20 = Used-Service-Unit         &n= bsp;  =20 | 0+  | 0   |
            =20 = User-Equipment-Info         =  =20 | 0-1 | 0   |
            =20 = User-Name          &nbs= p;         =20 | 0-1 | 0-1 |
            =20 = Validity-Time          =       =20 | 0   | 0-1 |
            =20 ------------------------------|-----+-----+ 

    NEW SECTION:

    12.18 User-Equipment-Info-Type AVP  =
           
       As defined in Section 8.49, the = User-Equipment-Info-Type=20 AVP (AVP
       Code TBD) defines the = values=20 0-2. All remaining values are
       = available=20 for assignment via Designated Expert [IANA]. 
      
       =
    CHANGED SECTION 15.1 Normative 
    FROM:
    ...

    ADD:
    ...
       [RAD802.1X]   P. Congdon, et.al "IEEE = 802.1X=20 RADIUS Usage Guidelines",
              &nbs= p;     =20 RFC 3580, September 2003.
        =20
       = [EUI64]     =20 IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) =
              &nbs= p;    =20 Registration Authority",
              &nbs= p;    =20 http://standards.ieee.org/regauth/oui/tutorials/EUI64.htm= l,=20
              &nbs= p;    =20 March 1997.

       [3GPPIMEI]   3rd Generation = Partnership=20 Project; Technical
              &nbs= p;    =20 Specification Group Core Network, Numbering, addressing =
              &nbs= p;    =20 and identification, (release 5), 3GPP TS 23.003
              &nbs= p;    =20 v. 5.8.0, 2003-12    =

    ------_=_NextPart_001_01C404CD.E4A1F7E0-- From owner-aaa-wg@merit.edu Mon Mar 8 06:57:46 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 GAA27058 for ; Mon, 8 Mar 2004 06:57:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3FF239122D; Mon, 8 Mar 2004 06:57:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 07B239122F; Mon, 8 Mar 2004 06:57:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CD2079122D for ; Mon, 8 Mar 2004 06:57:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id B81F45EEDF; Mon, 8 Mar 2004 06:57:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 1F61C5EEDC for ; Mon, 8 Mar 2004 06:57:32 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i28BvQqY028919 for ; Mon, 8 Mar 2004 12:57:30 +0100 (MET) 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, 8 Mar 2004 12:57:26 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 8 Mar 2004 12:58:26 +0100 Message-ID: From: "Leena Mattila (TU/LMF)" To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC Issue: Change END_USER_MSISDN to END_USER_E164 Date: Mon, 8 Mar 2004 12:57:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 08 Mar 2004 11:57:26.0457 (UTC) FILETIME=[864F5290:01C40504] Sender: owner-aaa-wg@merit.edu Precedence: bulk Description of issue: Change END_USER_MSISDN to END_USER_E164 Submitter name: Leena Mattila Date first submitted: 8.03.2004 Reference: Document: draft-ietf-aaa-diameter-cc-03.txt Comment type: T Priority: 1 Section: 8.46 Rationale/Explanation of issue The Subscription-Id-Type AVP contains value END_USER_MSISDN allowing the possibility to use numbers in E.164 format as subscription identities. The current definition restricts the usage to mobile (3GPP) environment by specifying that the number should be in international MSISDN format according to the ITU-T E.164. However, E.164 numbering plan is not restricted to MSISDN and should be allowed to be used for other subscription ids as well. Requested change: - Section 8.46 FROM END_USER_MSISDN 0 The identifier is in international MSISDN format, according to the ITU-T E.164 numbering plan as defined in [E164] and [CE164]. TO END_USER_E164 0 The identifier is in international E.164 format (e.g. MSISDN), according to the ITU-T E.164 numbering plan as defined in [E164] and [CE164]. Regards, Leena This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-aaa-wg@merit.edu Mon Mar 8 08:06: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 IAA29440 for ; Mon, 8 Mar 2004 08:06:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 69BEF9122F; Mon, 8 Mar 2004 08:06:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3BA4691232; Mon, 8 Mar 2004 08:06:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 770D19122F for ; Mon, 8 Mar 2004 08:06:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5243B5DDDF; Mon, 8 Mar 2004 08:06:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id A5FA65DDD3 for ; Mon, 8 Mar 2004 08:06:26 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i28D6PqY016704 for ; Mon, 8 Mar 2004 14:06:25 +0100 (MET) 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, 8 Mar 2004 14:06:25 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 8 Mar 2004 14:07:25 +0100 Message-ID: From: "Leena Mattila (TU/LMF)" To: "'Christopher Richards'" Cc: "Harri Hakala (TU/LMF)" , "Marco Stura (E-mail)" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in CCR Date: Mon, 8 Mar 2004 14:06:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 08 Mar 2004 13:06:25.0249 (UTC) FILETIME=[2938DD10:01C4050E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Chris, sounds ok. Not being an expert on identifiers but isn't the basic EUI-64 format now missing from the list of possible formats, I only saw a reference to a Modified EUI-64 [IPv6Addr]? BR, Leena -----Original Message----- From: Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 7. maaliskuuta 2004 0:27 To: aaa-wg@merit.edu Cc: Harri Hakala (TU/LMF); Marco Stura (E-mail); Leena Mattila (TU/LMF) Subject: [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in CCR Hi, After some discussions, I have updated the original proposal for sending the IMEI from the DCC client to the server. Since the IMEISV format is already well defined and described, I did not see the need to convert it to another format. Additionally, the included definition allows for the inclusion of the device software version along with the IMEI. I included the general EUI64 type format for use by unspecified equipment types. Submitter name: Chris Richards Submitter email address: crich@nortelnetworks.com Date first submitted: 19 Feb 2004 Reference: issue 22 Document: Diameter Credit Control Comment type: T Priority: 1 Section: Rationale/Explanation of issue: CHANGED SECTION 3.1 Credit-Control-Request (CCR) Command FROM: ... *[ Service-Parameter-Info ] *[ CC-Correlation-Id ] *[ Proxy-Info ] *[ Route-Record ] *[ AVP ] TO: ... *[ Service-Parameter-Info ] *[ CC-Correlation-Id ] *[ Proxy-Info ] *[ Route-Record ] [ User-Equipment-Info ] *[ AVP ] CHANGED SECTION 5.2 First Interrogation 3rd para FROM ... The Event-Timestamp AVP contains the time when the service event is requested in the service element. The Subscription-Id AVP SHOULD be included to identify the End-User in the credit-control server. ... TO: ... The Event-Timestamp AVP contains the time when the service event is requested in the service element. The Subscription-Id AVP SHOULD be included to identify the End-User in the credit-control server. The credit control client MAY include the User-Equipment-Info AVP so that the credit control server has some indication about the type and capabilities of the end user access device. How the credit control server uses this information is outside the scope of this document. ... CHANGED SECTION 8. Credit Control AVPs FROM ... Unit-Value 445 8.8 Grouped | M | P | | V | Y | Used-Service-Unit 446 8.19 Grouped | M | P | | V | Y | Value-Digits 447 8.10 Integer64 | M | P | | V | Y | Validity-Time 448 8.33 Unsigned32 | M | P | | V | Y | TO: ... Unit-Value 445 8.8 Grouped | M | P | | V | Y | Used-Service-Unit 446 8.19 Grouped | M | P | | V | Y | User-Equipment TBD 8.48 Grouped | | P | | V | Y | -Info | | | | | | User-Equipment TBD 8.49 Unsigned32 | | P | | V | Y | -Type | | | | | | User-Equipment TBD 8.50 UTF8String | | P | | V | Y | -Value | | | | | | Value-Digits 447 8.10 Integer64 | M | P | | V | Y | Validity-Time 448 8.33 Unsigned32 | M | P | | V | Y | NEW SECTIONS 8.48 to 8.50: 8.48 User-Equipment-Info AVP The User-Equipment-Info AVP (AVP Code TBD) is of type Grouped, and allows the Credit-control client to indicate the identity and capability of the terminal the subscriber is using for the connection to network. It has the following ABNF grammar: User-Equipment-Info ::= < AVP Header: TBD > { User-Equipment-Info-Type } { User-Equipment-Info-Value } 8.49 User-Equipment-Info-Type AVP The User-Equipment-Info-Type AVP is of type Unsigned32 (AVP Code TBD) and defines the type of the user equipment information contained in the User-Equipment-Info-Value AVP. The identifier can be one of the following: IMEISV 0 The identifier contains the International Mobile Equipment Identifier and Software Version in the international IMEISV format according to 3GPP TS 23.003 [3GPPIMEI]. MAC 1 The 48-bit MAC address is formatted as described in [RAD802.1X]. EUI64 2 There are a number of types of terminals that have identifiers other than 3GPP IMEI or IEEE 802 MACs. These identifiers can be converted to modified EUI-64 format as described in [IPv6Addr]. 8.50 User-Equipment-Info-Value AVP The User-Equipment-Info-Value AVP (AVP Code TBD) is of type UTF8String. The User-Equipment-Info-Type AVP defines which type of identifier is used. CHANGED SECTION 10.1 Credit Control AVP Table FROM: ... Used-Service-Unit | 0+ | 0 | User-Name | 0-1 | 0-1 | Validity-Time | 0 | 0-1 | ------------------------------|-----+-----+ TO: ... Used-Service-Unit | 0+ | 0 | User-Equipment-Info | 0-1 | 0 | User-Name | 0-1 | 0-1 | Validity-Time | 0 | 0-1 | ------------------------------|-----+-----+ NEW SECTION: 12.18 User-Equipment-Info-Type AVP As defined in Section 8.49, the User-Equipment-Info-Type AVP (AVP Code TBD) defines the values 0-2. All remaining values are available for assignment via Designated Expert [IANA]. CHANGED SECTION 15.1 Normative FROM: ... ADD: ... [RAD802.1X] P. Congdon, et.al "IEEE 802.1X RADIUS Usage Guidelines", RFC 3580, September 2003. [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. [3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-12 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-aaa-wg@merit.edu Mon Mar 8 08:59:37 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 IAA00990 for ; Mon, 8 Mar 2004 08:59:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A722E9123B; Mon, 8 Mar 2004 08:59:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B1769123C; Mon, 8 Mar 2004 08:59:25 -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 E32219123B for ; Mon, 8 Mar 2004 08:59:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id C713B5DDA9; Mon, 8 Mar 2004 08:59:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id 4EB335DD8C for ; Mon, 8 Mar 2004 08:59:23 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i28DxD410683; Mon, 8 Mar 2004 07:59:13 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Mar 2004 07:59:14 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304DDD5C9@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'Leena Mattila (TU/LMF)'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC Issue: Change END_USER_MSISDN to END_USER_E164 Date: Mon, 8 Mar 2004 07:59:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40514.9B8647D0" 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_01C40514.9B8647D0 Content-Type: text/plain; charset="iso-8859-1" Hi Leena, Is it still possible for the DCC server determine exactly what is contained in the AVP if it is not restricted to the MSISDN? I think it makes more sense to leave it specified as the MSISDN - otherwise it will become more difficult to determine what the E.164 AVP actually contains. Alternatively, the text could be changed to state that "for 3GPP networks, the MSISDN MUST be used in this field". Br, Chris. -----Original Message----- From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com] Sent: Monday, March 08, 2004 5:57 AM To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC Issue: Change END_USER_MSISDN to END_USER_E164 Description of issue: Change END_USER_MSISDN to END_USER_E164 Submitter name: Leena Mattila Date first submitted: 8.03.2004 Reference: Document: draft-ietf-aaa-diameter-cc-03.txt Comment type: T Priority: 1 Section: 8.46 Rationale/Explanation of issue The Subscription-Id-Type AVP contains value END_USER_MSISDN allowing the possibility to use numbers in E.164 format as subscription identities. The current definition restricts the usage to mobile (3GPP) environment by specifying that the number should be in international MSISDN format according to the ITU-T E.164. However, E.164 numbering plan is not restricted to MSISDN and should be allowed to be used for other subscription ids as well. Requested change: - Section 8.46 FROM END_USER_MSISDN 0 The identifier is in international MSISDN format, according to the ITU-T E.164 numbering plan as defined in [E164] and [CE164]. TO END_USER_E164 0 The identifier is in international E.164 format (e.g. MSISDN), according to the ITU-T E.164 numbering plan as defined in [E164] and [CE164]. Regards, Leena This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C40514.9B8647D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCC Issue: Change END_USER_MSISDN to = END_USER_E164

    Hi Leena,

    Is it still possible for the DCC server determine = exactly what is contained in the AVP if it is not restricted to the = MSISDN?

    I think it makes more sense to leave it specified as = the MSISDN - otherwise it will become more difficult to determine what = the E.164 AVP actually contains. Alternatively, the text could be = changed to state that "for 3GPP networks, the MSISDN MUST be used = in this field".

    Br,
    Chris.

    -----Original Message-----
    From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson= .com]
    Sent: Monday, March 08, 2004 5:57 AM
    To: aaa-wg@merit.edu
    Subject: [AAA-WG]: DCC Issue: Change END_USER_MSISDN = to END_USER_E164


    Description of issue: Change END_USER_MSISDN to = END_USER_E164
    Submitter name:  Leena Mattila
    Date first submitted: 8.03.2004
    Reference:
    Document: draft-ietf-aaa-diameter-cc-03.txt
    Comment type: T
    Priority: 1
    Section: 8.46

    Rationale/Explanation of issue

    The Subscription-Id-Type AVP contains value = END_USER_MSISDN allowing the possibility to use numbers in E.164 format = as subscription identities. The current definition restricts the usage = to mobile (3GPP) environment by specifying that the number should be in = international MSISDN format according to the ITU-T E.164. However, = E.164 numbering plan is not restricted to MSISDN and should be allowed = to be used for other subscription ids as well.

    Requested change:

    - Section 8.46

    FROM

          = END_USER_MSISDN         &nb= sp;           &nb= sp;           &nb= sp;            = 0 
       
               = The identifier is in international MSISDN format, according  =
               = to the ITU-T E.164 numbering plan as defined in [E164] and  =
               = [CE164]. 

    TO

          = END_USER_E164          = ;            = ;            = ;            = ;  0 
       
               = The identifier is in international E.164 format (e.g. MSISDN),
               = according to the ITU-T E.164 numbering plan as defined in
               = [E164] and [CE164]. 

    Regards,
    Leena


















    This communication is confidential and intended = solely for the addressee(s). Any unauthorized review, use, disclosure = or distribution is prohibited. If you believe this message has been = sent to you in error, please notify the sender by replying to this = transmission and delete the message without disclosing it. Thank = you.

    E-mail including attachments is susceptible to data = corruption, interruption, unauthorized amendment, tampering and = viruses, and we only send and receive e-mails on the basis that we are = not liable for any such corruption, interception, amendment, tampering = or viruses or any consequences thereof.

    ------_=_NextPart_001_01C40514.9B8647D0-- From owner-aaa-wg@merit.edu Mon Mar 8 09: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 JAA01785 for ; Mon, 8 Mar 2004 09:14:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B93E491239; Mon, 8 Mar 2004 09:14:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F32F9123C; Mon, 8 Mar 2004 09:14:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 70BAD91239 for ; Mon, 8 Mar 2004 09:14:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5E10F5DDE1; Mon, 8 Mar 2004 09:14:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by segue.merit.edu (Postfix) with ESMTP id A4D265DDE2 for ; Mon, 8 Mar 2004 09:14:22 -0500 (EST) 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 i28EELAh030762 for ; Mon, 8 Mar 2004 15:14:21 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 8 Mar 2004 15:14:21 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 8 Mar 2004 15:15:21 +0100 Message-ID: From: "Leena Mattila (TU/LMF)" To: "'Christopher Richards'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC Issue: Change END_USER_MSISDN to END_USER_E164 Date: Mon, 8 Mar 2004 15:13:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 08 Mar 2004 14:14:21.0316 (UTC) FILETIME=[A6BF5440:01C40517] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Chris, yes, I think it is possible to separate MSISDN from other numbers since mobile networks have their own national destination codes. If I receive an E.164 number +35840123456 I know it's a number belonging to a specific gsm operator in Finland, and thus the number is MSISDN because in gsm one uses MSISDN to identify subscribers. I'd leave the clarification sentences like "...in 3GPP one does this and that..." up to 3GPP specs to define. BR, Leena -----Original Message----- From: Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 8. maaliskuuta 2004 15:59 To: Leena Mattila (TU/LMF); aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC Issue: Change END_USER_MSISDN to END_USER_E164 Hi Leena, Is it still possible for the DCC server determine exactly what is contained in the AVP if it is not restricted to the MSISDN? I think it makes more sense to leave it specified as the MSISDN - otherwise it will become more difficult to determine what the E.164 AVP actually contains. Alternatively, the text could be changed to state that "for 3GPP networks, the MSISDN MUST be used in this field". Br, Chris. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-aaa-wg@merit.edu Mon Mar 8 14:09: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 OAA21304 for ; Mon, 8 Mar 2004 14:09:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 694F891243; Mon, 8 Mar 2004 14:09:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 36EF991259; Mon, 8 Mar 2004 14:09:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 434BE91243 for ; Mon, 8 Mar 2004 14:09:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 30A7F5DF59; Mon, 8 Mar 2004 14:09:18 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 8F8845DF4E for ; Mon, 8 Mar 2004 14:09:14 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i28JJ5R15724 for ; Mon, 8 Mar 2004 11:19:05 -0800 Date: Mon, 8 Mar 2004 11:19:05 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: REMINDER: Pending WG last calls Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk AAA WG last call is currently pending on the following documents: draft-ietf-aaa-eap-04.txt draft-ietf-aaa-diameter-cc-03.txt draft-ietf-aaa-diameter-nasreq-14.txt WG last call ends today March 8, 2004. Please send your comments to the AAA WG mailing list, filed using the Issue submission format described in the AAA Issues list: http://www.drizzle.com/~aboba/AAA/issues.html From owner-aaa-wg@merit.edu Tue Mar 9 04:45: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 EAA17787 for ; Tue, 9 Mar 2004 04:45:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 19E2A91231; Tue, 9 Mar 2004 04:45:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E2869129B; Tue, 9 Mar 2004 04:45:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 629A691231 for ; Tue, 9 Mar 2004 04:45:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 51F185E2B2; Tue, 9 Mar 2004 04:45:00 -0500 (EST) 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 62E4E5E2AB for ; Tue, 9 Mar 2004 04:44:59 -0500 (EST) 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 i299ivB14903; Tue, 9 Mar 2004 11:44:57 +0200 (EET) X-Scanned: Tue, 9 Mar 2004 11:44:37 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i299ibN0007475; Tue, 9 Mar 2004 11:44:37 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00OuMEfs; Tue, 09 Mar 2004 11:44:36 EET 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 i299iZ129960; Tue, 9 Mar 2004 11:44:35 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Mar 2004 11:44:30 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: DCC Issue: Change END_USER_MSISDN to END_USER_E164 Date: Tue, 9 Mar 2004 11:44:30 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C8563@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC Issue: Change END_USER_MSISDN to END_USER_E164 Thread-Index: AcQFGhva2TnJNYqgRDWNK7DJkpBeogAoF2OA From: To: Cc: , X-OriginalArrivalTime: 09 Mar 2004 09:44:30.0383 (UTC) FILETIME=[1E9CC3F0:01C405BB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Leena, in SIP a user can be identified also with Tel URI, which is actually = E.164 number. Example: tel:+1-555-2222-3333 How do you see the support of this type of identity in the = Subscription-Id AVP? Cheers Marco > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Leena Mattila (TU/LMF) > Sent: 08 March, 2004 16:14 > To: 'Christopher Richards'; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: DCC Issue: Change END_USER_MSISDN to > END_USER_E164 >=20 >=20 >=20 > Hi Chris, >=20 > yes, I think it is possible to separate MSISDN from other=20 > numbers since mobile networks have their own national=20 > destination codes. If I receive an E.164 number +35840123456=20 > I know it's a number belonging to a specific gsm operator in=20 > Finland, and thus the number is MSISDN because in gsm one=20 > uses MSISDN to identify subscribers. I'd leave the=20 > clarification sentences like "...in 3GPP one does this and=20 > that..." up to 3GPP specs to define. >=20 > BR, > Leena >=20 > -----Original Message----- > From: Christopher Richards [mailto:crich@nortelnetworks.com] > Sent: 8. maaliskuuta 2004 15:59 > To: Leena Mattila (TU/LMF); aaa-wg@merit.edu > Subject: RE: [AAA-WG]: DCC Issue: Change END_USER_MSISDN to=20 > END_USER_E164 >=20 >=20 > Hi Leena,=20 > Is it still possible for the DCC server determine exactly=20 > what is contained in the AVP if it is not restricted to the MSISDN?=20 > I think it makes more sense to leave it specified as the=20 > MSISDN - otherwise it will become more difficult to determine=20 > what the E.164 AVP actually contains. Alternatively, the text=20 > could be changed to state that "for 3GPP networks, the MSISDN=20 > MUST be used in this field".=20 > Br,=20 > Chris.=20 >=20 > This communication is confidential and intended solely for=20 > the addressee(s). Any unauthorized review, use, disclosure or=20 > distribution is prohibited. If you believe this message has=20 > been sent to you in error, please notify the sender by=20 > replying to this transmission and delete the message without=20 > disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data=20 > corruption, interruption, unauthorized amendment, tampering=20 > and viruses, and we only send and receive e-mails on the=20 > basis that we are not liable for any such corruption,=20 > interception, amendment, tampering or viruses or any=20 > consequences thereof. >=20 >=20 From owner-aaa-wg@merit.edu Tue Mar 9 05:13: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 FAA18543 for ; Tue, 9 Mar 2004 05:13:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 12B4E9129C; Tue, 9 Mar 2004 05:13:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF7DF912A2; Tue, 9 Mar 2004 05:13:17 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 926D39129C for ; Tue, 9 Mar 2004 05:13:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 738395E2DA; Tue, 9 Mar 2004 05:13:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (unknown [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id AEC7C5E2D4 for ; Tue, 9 Mar 2004 05:13:14 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i29ADDqY007768 for ; Tue, 9 Mar 2004 11:13:13 +0100 (MET) 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, 9 Mar 2004 11:13:13 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 9 Mar 2004 11:14:16 +0100 Message-ID: From: "Leena Mattila (TU/LMF)" To: "'marco.stura@nokia.com'" Cc: crich@nortelnetworks.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC Issue: Change END_USER_MSISDN to END_USER_E164 Date: Tue, 9 Mar 2004 11:12:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 09 Mar 2004 10:13:13.0255 (UTC) FILETIME=[21862B70:01C405BF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Marco, firstly, I don't see how the question is related to separation of MSISDN from other E164 numbers as discussed below??? With the existing (draft-03) structure it is less possible to indicate tel URLs, as far as I can judge. I think it is possible to support your tel:+1-555-2222-3333 tel URL as follows: Subscription-id-Type = END_USER_E164 Subscription-id-Data = "155522223333" or one can convert it to SIP URL (or is the correct name SIP URI, btw?). I wouldn't go so far as to introduce a new id type since, as you say, tel URL is an E.164 number. BR, Leena > -----Original Message----- > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] > Sent: 9. maaliskuuta 2004 11:45 > To: Leena Mattila (TU/LMF) > Cc: crich@nortelnetworks.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: DCC Issue: Change END_USER_MSISDN to > END_USER_E164 > > > Hi Leena, > > in SIP a user can be identified also with Tel URI, which is > actually E.164 number. > Example: tel:+1-555-2222-3333 > How do you see the support of this type of identity in the > Subscription-Id AVP? > > Cheers > Marco > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu > > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > ext Leena Mattila (TU/LMF) > > Sent: 08 March, 2004 16:14 > > To: 'Christopher Richards'; aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: DCC Issue: Change END_USER_MSISDN to > > END_USER_E164 > > > > > > > > Hi Chris, > > > > yes, I think it is possible to separate MSISDN from other > > numbers since mobile networks have their own national > > destination codes. If I receive an E.164 number +35840123456 > > I know it's a number belonging to a specific gsm operator in > > Finland, and thus the number is MSISDN because in gsm one > > uses MSISDN to identify subscribers. I'd leave the > > clarification sentences like "...in 3GPP one does this and > > that..." up to 3GPP specs to define. > > > > BR, > > Leena > > > > -----Original Message----- > > From: Christopher Richards [mailto:crich@nortelnetworks.com] > > Sent: 8. maaliskuuta 2004 15:59 > > To: Leena Mattila (TU/LMF); aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: DCC Issue: Change END_USER_MSISDN to > > END_USER_E164 > > > > > > Hi Leena, > > Is it still possible for the DCC server determine exactly > > what is contained in the AVP if it is not restricted to the MSISDN? > > I think it makes more sense to leave it specified as the > > MSISDN - otherwise it will become more difficult to determine > > what the E.164 AVP actually contains. Alternatively, the text > > could be changed to state that "for 3GPP networks, the MSISDN > > MUST be used in this field". > > Br, > > Chris. > > > > This communication is confidential and intended solely for > > the addressee(s). Any unauthorized review, use, disclosure or > > distribution is prohibited. If you believe this message has > > been sent to you in error, please notify the sender by > > replying to this transmission and delete the message without > > disclosing it. Thank you. > > > > E-mail including attachments is susceptible to data > > corruption, interruption, unauthorized amendment, tampering > > and viruses, and we only send and receive e-mails on the > > basis that we are not liable for any such corruption, > > interception, amendment, tampering or viruses or any > > consequences thereof. > > > > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-aaa-wg@merit.edu Tue Mar 9 05:25:51 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 FAA19002 for ; Tue, 9 Mar 2004 05:25:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 48025912A0; Tue, 9 Mar 2004 05:25:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB2E3912A1; Tue, 9 Mar 2004 05:25:32 -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 C3A50912A0 for ; Tue, 9 Mar 2004 05:25:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id B192F5E2CF; Tue, 9 Mar 2004 05:25:30 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id B738F5E2C3 for ; Tue, 9 Mar 2004 05:25:29 -0500 (EST) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i29APRi25882; Tue, 9 Mar 2004 12:25:27 +0200 (EET) X-Scanned: Tue, 9 Mar 2004 12:24:50 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i29AOo0I012839; Tue, 9 Mar 2004 12:24:50 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00a1dvnD; Tue, 09 Mar 2004 12:24:48 EET 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 i29AOg103315; Tue, 9 Mar 2004 12:24:42 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Mar 2004 12:24:37 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: DCC Issue: Change END_USER_MSISDN to END_USER_E164 Date: Tue, 9 Mar 2004 12:24:36 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B04BB@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC Issue: Change END_USER_MSISDN to END_USER_E164 Thread-Index: AcQFv0Wog5wrXpdPSw2uMoXOzIbsFwAAH7XA From: To: Cc: , X-OriginalArrivalTime: 09 Mar 2004 10:24:37.0409 (UTC) FILETIME=[B94FC910:01C405C0] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > firstly, I don't see how the question is related to=20 > separation of MSISDN from other E164 numbers as discussed below??? It was just unclear to me if that END_USER_E164 could be used for tel URI type of identity. > I think it is possible to support your tel:+1-555-2222-3333=20 > tel URL as follows: > Subscription-id-Type =3D END_USER_E164 > Subscription-id-Data =3D "155522223333" I guess so, thank you for the clarification. > I wouldn't go so far as to introduce a new id type since, as=20 > you say, tel URL is an E.164 number. I was not proposing anything, just asking a question. Again, thank you for your answer. Regards Marco From owner-aaa-wg@merit.edu Wed Mar 10 02:42: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 CAA24432 for ; Wed, 10 Mar 2004 02:42:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3B7F7912B4; Wed, 10 Mar 2004 02:41:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B1349124C; Wed, 10 Mar 2004 02:41:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0DF18912B4 for ; Wed, 10 Mar 2004 02:41:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id E20DF5E82C; Wed, 10 Mar 2004 02:41:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 4FBE25E820 for ; Wed, 10 Mar 2004 02:41:47 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2A7fkqY025299 for ; Wed, 10 Mar 2004 08:41:46 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 10 Mar 2004 08:41:45 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 10 Mar 2004 08:42:52 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "Leena Mattila (TU/LMF)" , "'Christopher Richards'" Cc: "'Marco Stura (E-mail)'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in CCR Date: Wed, 10 Mar 2004 08:41:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 10 Mar 2004 07:41:45.0751 (UTC) FILETIME=[235CDA70:01C40673] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, > sounds ok. Not being an expert on identifiers but isn't the > basic EUI-64 format now missing from the list of possible > formats, I only saw a reference to a Modified EUI-64 [IPv6Addr]? To be able to close also this issue, I take the liberty to update the issue to cover also pure EUI-64 format. It may be good also to mention that there may be other approaches for creating Modified EUI-64 format than those described in [IPv6Addr]. These methods may be needed if length of the company_id and vendor_supplied_id fields are other than those mentioned in MAC-48 or EUI-64. Below is updated proposal. regards...........Harri CHANGED SECTION 3.1 Credit-Control-Request (CCR) Command FROM: ... *[ Service-Parameter-Info ] *[ CC-Correlation-Id ] *[ Proxy-Info ] *[ Route-Record ] *[ AVP ] TO: ... *[ Service-Parameter-Info ] *[ CC-Correlation-Id ] *[ Proxy-Info ] *[ Route-Record ] [ User-Equipment-Info ] *[ AVP ] CHANGED SECTION 5.2 First Interrogation 3rd paragraph FROM ... The Event-Timestamp AVP contains the time when the service event is requested in the service element. The Subscription-Id AVP SHOULD be included to identify the End-User in the credit-control server. ... TO: ... The Event-Timestamp AVP contains the time when the service event is requested in the service element. The Subscription-Id AVP SHOULD be included to identify the End-User in the credit-control server. The credit control client MAY include the User-Equipment-Info AVP so that the credit control server has some indication about the type and capabilities of the end user access device. How the credit control server uses this information is outside the scope of this document. ... CHANGED SECTION 8. Credit Control AVPs FROM ... Unit-Value 445 8.8 Grouped | M | P | | V | Y | Used-Service-Unit 446 8.19 Grouped | M | P | | V | Y | Value-Digits 447 8.10 Integer64 | M | P | | V | Y | Validity-Time 448 8.33 Unsigned32 | M | P | | V | Y | TO: ... Unit-Value 445 8.8 Grouped | M | P | | V | Y | Used-Service-Unit 446 8.19 Grouped | M | P | | V | Y | User-Equipment TBD 8.48 Grouped | | P,M | | V | Y | -Info | | | | | | User-Equipment TBD 8.49 Unsigned32 | | P,M | | V | Y | -Type | | | | | | User-Equipment TBD 8.50 UTF8String | | P,M | | V | Y | -Value | | | | | | Value-Digits 447 8.10 Integer64 | M | P | | V | Y | Validity-Time 448 8.33 Unsigned32 | M | P | | V | Y | NEW SECTIONS 8.48 to 8.50: 8.48 User-Equipment-Info AVP The User-Equipment-Info AVP (AVP Code TBD) is of type Grouped, and allows the Credit-control client to indicate the identity and capability of the terminal the subscriber is using for the connection to network. It has the following ABNF grammar: User-Equipment-Info ::= < AVP Header: TBD > { User-Equipment-Info-Type } { User-Equipment-Info-Value } 8.49 User-Equipment-Info-Type AVP The User-Equipment-Info-Type AVP is of type Unsigned32 (AVP Code TBD) and defines the type of the user equipment information contained in the User-Equipment-Info-Value AVP. The identifier can be one of the following: IMEISV 0 The identifier contains the International Mobile Equipment Identifier and Software Version in the international IMEISV format according to 3GPP TS 23.003 [3GPPIMEI]. MAC 1 The 48-bit MAC address is formatted as described in [RAD802.1X]. EUI64 2 The 64-bit identifier used to identify hardware instance of the product as defined in [EUI64]. MODIFIED_EUI64 3 There are a number of types of terminals that have identifiers other than IMEI, IEEE 802 MACs or EUI-64. These identifiers can be converted to modified EUI-64 format as described in [IPv6Addr] or using some other methods referred to in the service specific documentation. CHANGED SECTION 10.1 Credit Control AVP Table FROM: ... Used-Service-Unit | 0+ | 0 | User-Name | 0-1 | 0-1 | Validity-Time | 0 | 0-1 | ------------------------------|-----+-----+ TO: ... Used-Service-Unit | 0+ | 0 | User-Equipment-Info | 0-1 | 0 | User-Name | 0-1 | 0-1 | Validity-Time | 0 | 0-1 | ------------------------------|-----+-----+ NEW SECTION: 12.18 User-Equipment-Info-Type AVP As defined in Section 8.49, the User-Equipment-Info-Type AVP (AVP Code TBD) defines the values 0-3. All remaining values are available for assignment via Designated Expert [IANA]. CHANGED SECTION 15.1 Normative FROM: ... ADD: ... [RAD802.1X] P. Congdon, et.al "IEEE 802.1X RADIUS Usage Guidelines", RFC 3580, September 2003. [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. [3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-12 > -----Original Message----- > From: Leena Mattila (TU/LMF) > Sent: 8. maaliskuuta 2004 15:06 > To: 'Christopher Richards' > Cc: Harri Hakala (TU/LMF); Marco Stura (E-mail); aaa-wg@merit.edu > Subject: RE: [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in > CCR > > > Hi Chris, > > sounds ok. Not being an expert on identifiers but isn't the > basic EUI-64 format now missing from the list of possible > formats, I only saw a reference to a Modified EUI-64 [IPv6Addr]? > > BR, > Leena > > -----Original Message----- > From: Christopher Richards [mailto:crich@nortelnetworks.com] > Sent: 7. maaliskuuta 2004 0:27 > To: aaa-wg@merit.edu > Cc: Harri Hakala (TU/LMF); Marco Stura (E-mail); Leena > Mattila (TU/LMF) > Subject: [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in CCR > > > Hi, > After some discussions, I have updated the original proposal > for sending the IMEI from the DCC client to the server. Since > the IMEISV format is already well defined and described, I > did not see the need to convert it to another format. > Additionally, the included definition allows for the > inclusion of the device software version along with the IMEI. > I included the general EUI64 type format for use by > unspecified equipment types. > Submitter name: Chris Richards > Submitter email address: crich@nortelnetworks.com > Date first submitted: 19 Feb 2004 > Reference: issue 22 > Document: Diameter Credit Control > Comment type: T > Priority: 1 > Section: > Rationale/Explanation of issue: > CHANGED SECTION 3.1 Credit-Control-Request (CCR) Command > FROM: > ... > *[ Service-Parameter-Info ] > *[ CC-Correlation-Id ] > *[ Proxy-Info ] > *[ Route-Record ] > *[ AVP ] > TO: > ... > *[ Service-Parameter-Info ] > *[ CC-Correlation-Id ] > *[ Proxy-Info ] > *[ Route-Record ] > [ User-Equipment-Info ] > *[ AVP ] > > > CHANGED SECTION 5.2 First Interrogation 3rd para > FROM > ... > The Event-Timestamp AVP contains the time when the service > event is > requested in the service element. The Subscription-Id AVP > SHOULD be > included to identify the End-User in the credit-control server. > ... > > TO: > ... > The Event-Timestamp AVP contains the time when the service > event is > requested in the service element. The Subscription-Id AVP > SHOULD be > included to identify the End-User in the credit-control > server. The > credit control client MAY include the User-Equipment-Info AVP so > that the credit control server has some indication about the type > and capabilities of the end user access device. How the credit > control server uses this information is outside the scope of this > document. > ... > > > CHANGED SECTION 8. Credit Control AVPs > FROM > ... > Unit-Value 445 8.8 Grouped | M | P | | > V | Y | > Used-Service-Unit 446 8.19 Grouped | M | P | | > V | Y | > Value-Digits 447 8.10 Integer64 | M | P | | > V | Y | > Validity-Time 448 8.33 Unsigned32 | M | P | | > V | Y | > > TO: > ... > Unit-Value 445 8.8 Grouped | M | P | | > V | Y | > Used-Service-Unit 446 8.19 Grouped | M | P | | > V | Y | > User-Equipment TBD 8.48 Grouped | | P | | > V | Y | > -Info | | | | > | | > User-Equipment TBD 8.49 Unsigned32 | | P | | > V | Y | > -Type | | | | > | | > User-Equipment TBD 8.50 UTF8String | | P | | > V | Y | > -Value | | | | > | | > Value-Digits 447 8.10 Integer64 | M | P | | > V | Y | > Validity-Time 448 8.33 Unsigned32 | M | P | | > V | Y | > > > > NEW SECTIONS 8.48 to 8.50: > 8.48 User-Equipment-Info AVP > The User-Equipment-Info AVP (AVP Code TBD) is of type Grouped, and > allows the Credit-control client to indicate the identity > and capability > of the terminal the subscriber is using for the connection > to network. > > It has the following ABNF grammar: > > User-Equipment-Info ::= < AVP Header: TBD > > { > User-Equipment-Info-Type } > { > User-Equipment-Info-Value } > > > 8.49 User-Equipment-Info-Type AVP > The User-Equipment-Info-Type AVP is of type Unsigned32 > (AVP Code TBD) > and defines the type of the user equipment information > contained in > the User-Equipment-Info-Value AVP. > > The identifier can be one of the following: > > IMEISV 0 > > The identifier contains the International Mobile Equipment > Identifier and Software Version in the > international IMEISV > format according to 3GPP TS 23.003 [3GPPIMEI]. > > MAC 1 > The 48-bit MAC address is formatted as described in > [RAD802.1X]. > > EUI64 2 > > There are a number of types of terminals that have > identifiers > other than 3GPP IMEI or IEEE 802 MACs. These > identifiers can > be converted to modified EUI-64 format as described in > [IPv6Addr]. > > 8.50 User-Equipment-Info-Value AVP > The User-Equipment-Info-Value AVP (AVP Code TBD) is of > type UTF8String. > The User-Equipment-Info-Type AVP defines which type of > identifier is > used. > > > CHANGED SECTION 10.1 Credit Control AVP Table > FROM: > ... > Used-Service-Unit | 0+ | 0 | > User-Name | 0-1 | 0-1 | > Validity-Time | 0 | 0-1 | > ------------------------------|-----+-----+ > TO: > ... > Used-Service-Unit | 0+ | 0 | > User-Equipment-Info | 0-1 | 0 | > User-Name | 0-1 | 0-1 | > Validity-Time | 0 | 0-1 | > ------------------------------|-----+-----+ > NEW SECTION: > 12.18 User-Equipment-Info-Type AVP > > As defined in Section 8.49, the User-Equipment-Info-Type AVP (AVP > Code TBD) defines the values 0-2. All remaining values are > available for assignment via Designated Expert [IANA]. > > > CHANGED SECTION 15.1 Normative > FROM: > ... > ADD: > ... > [RAD802.1X] P. Congdon, et.al "IEEE 802.1X RADIUS Usage > Guidelines", > RFC 3580, September 2003. > > [EUI64] IEEE, "Guidelines for 64-bit Global > Identifier (EUI-64) > Registration Authority", > http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. [3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-12 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-aaa-wg@merit.edu Wed Mar 10 09:56: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 JAA11607 for ; Wed, 10 Mar 2004 09:56:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5EF7691250; Wed, 10 Mar 2004 09:56:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E6A6912B7; Wed, 10 Mar 2004 09:56:40 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A645691250 for ; Wed, 10 Mar 2004 09:56:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8ACD25E94C; Wed, 10 Mar 2004 09:56:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (unknown [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id 5E93E5E956 for ; Wed, 10 Mar 2004 09:56:35 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i2AEuLb04609; Wed, 10 Mar 2004 06:56:21 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Mar 2004 08:56:22 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B59753052AF6EB@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'Harri Hakala (TU/LMF)'" , "'Leena Mattila (TU/LMF)'" Cc: "'Marco Stura (E-mail)'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in CCR Date: Wed, 10 Mar 2004 08:56:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C406AF.D7E33372" 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_01C406AF.D7E33372 Content-Type: text/plain Hi Harri, The change seems fine to me. Best Regards, Chris. -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: Wednesday, March 10, 2004 1:41 AM To: Leena Mattila (TU/LMF); Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'Marco Stura (E-mail)'; 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in CCR Hi, > sounds ok. Not being an expert on identifiers but isn't the > basic EUI-64 format now missing from the list of possible > formats, I only saw a reference to a Modified EUI-64 [IPv6Addr]? To be able to close also this issue, I take the liberty to update the issue to cover also pure EUI-64 format. It may be good also to mention that there may be other approaches for creating Modified EUI-64 format than those described in [IPv6Addr]. These methods may be needed if length of the company_id and vendor_supplied_id fields are other than those mentioned in MAC-48 or EUI-64. Below is updated proposal. regards...........Harri CHANGED SECTION 3.1 Credit-Control-Request (CCR) Command FROM: ... *[ Service-Parameter-Info ] *[ CC-Correlation-Id ] *[ Proxy-Info ] *[ Route-Record ] *[ AVP ] TO: ... *[ Service-Parameter-Info ] *[ CC-Correlation-Id ] *[ Proxy-Info ] *[ Route-Record ] [ User-Equipment-Info ] *[ AVP ] CHANGED SECTION 5.2 First Interrogation 3rd paragraph FROM ... The Event-Timestamp AVP contains the time when the service event is requested in the service element. The Subscription-Id AVP SHOULD be included to identify the End-User in the credit-control server. ... TO: ... The Event-Timestamp AVP contains the time when the service event is requested in the service element. The Subscription-Id AVP SHOULD be included to identify the End-User in the credit-control server. The credit control client MAY include the User-Equipment-Info AVP so that the credit control server has some indication about the type and capabilities of the end user access device. How the credit control server uses this information is outside the scope of this document. ... CHANGED SECTION 8. Credit Control AVPs FROM ... Unit-Value 445 8.8 Grouped | M | P | | V | Y | Used-Service-Unit 446 8.19 Grouped | M | P | | V | Y | Value-Digits 447 8.10 Integer64 | M | P | | V | Y | Validity-Time 448 8.33 Unsigned32 | M | P | | V | Y | TO: ... Unit-Value 445 8.8 Grouped | M | P | | V | Y | Used-Service-Unit 446 8.19 Grouped | M | P | | V | Y | User-Equipment TBD 8.48 Grouped | | P,M | | V | Y | -Info | | | | | | User-Equipment TBD 8.49 Unsigned32 | | P,M | | V | Y | -Type | | | | | | User-Equipment TBD 8.50 UTF8String | | P,M | | V | Y | -Value | | | | | | Value-Digits 447 8.10 Integer64 | M | P | | V | Y | Validity-Time 448 8.33 Unsigned32 | M | P | | V | Y | NEW SECTIONS 8.48 to 8.50: 8.48 User-Equipment-Info AVP The User-Equipment-Info AVP (AVP Code TBD) is of type Grouped, and allows the Credit-control client to indicate the identity and capability of the terminal the subscriber is using for the connection to network. It has the following ABNF grammar: User-Equipment-Info ::= < AVP Header: TBD > { User-Equipment-Info-Type } { User-Equipment-Info-Value } 8.49 User-Equipment-Info-Type AVP The User-Equipment-Info-Type AVP is of type Unsigned32 (AVP Code TBD) and defines the type of the user equipment information contained in the User-Equipment-Info-Value AVP. The identifier can be one of the following: IMEISV 0 The identifier contains the International Mobile Equipment Identifier and Software Version in the international IMEISV format according to 3GPP TS 23.003 [3GPPIMEI]. MAC 1 The 48-bit MAC address is formatted as described in [RAD802.1X]. EUI64 2 The 64-bit identifier used to identify hardware instance of the product as defined in [EUI64]. MODIFIED_EUI64 3 There are a number of types of terminals that have identifiers other than IMEI, IEEE 802 MACs or EUI-64. These identifiers can be converted to modified EUI-64 format as described in [IPv6Addr] or using some other methods referred to in the service specific documentation. CHANGED SECTION 10.1 Credit Control AVP Table FROM: ... Used-Service-Unit | 0+ | 0 | User-Name | 0-1 | 0-1 | Validity-Time | 0 | 0-1 | ------------------------------|-----+-----+ TO: ... Used-Service-Unit | 0+ | 0 | User-Equipment-Info | 0-1 | 0 | User-Name | 0-1 | 0-1 | Validity-Time | 0 | 0-1 | ------------------------------|-----+-----+ NEW SECTION: 12.18 User-Equipment-Info-Type AVP As defined in Section 8.49, the User-Equipment-Info-Type AVP (AVP Code TBD) defines the values 0-3. All remaining values are available for assignment via Designated Expert [IANA]. CHANGED SECTION 15.1 Normative FROM: ... ADD: ... [RAD802.1X] P. Congdon, et.al "IEEE 802.1X RADIUS Usage Guidelines", RFC 3580, September 2003. [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. [3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-12 > -----Original Message----- > From: Leena Mattila (TU/LMF) > Sent: 8. maaliskuuta 2004 15:06 > To: 'Christopher Richards' > Cc: Harri Hakala (TU/LMF); Marco Stura (E-mail); aaa-wg@merit.edu > Subject: RE: [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in > CCR > > > Hi Chris, > > sounds ok. Not being an expert on identifiers but isn't the > basic EUI-64 format now missing from the list of possible > formats, I only saw a reference to a Modified EUI-64 [IPv6Addr]? > > BR, > Leena > > -----Original Message----- > From: Christopher Richards [mailto:crich@nortelnetworks.com] > Sent: 7. maaliskuuta 2004 0:27 > To: aaa-wg@merit.edu > Cc: Harri Hakala (TU/LMF); Marco Stura (E-mail); Leena > Mattila (TU/LMF) > Subject: [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in CCR > > > Hi, > After some discussions, I have updated the original proposal > for sending the IMEI from the DCC client to the server. Since > the IMEISV format is already well defined and described, I > did not see the need to convert it to another format. > Additionally, the included definition allows for the > inclusion of the device software version along with the IMEI. > I included the general EUI64 type format for use by > unspecified equipment types. > Submitter name: Chris Richards > Submitter email address: crich@nortelnetworks.com > Date first submitted: 19 Feb 2004 > Reference: issue 22 > Document: Diameter Credit Control > Comment type: T > Priority: 1 > Section: > Rationale/Explanation of issue: > CHANGED SECTION 3.1 Credit-Control-Request (CCR) Command > FROM: > ... > *[ Service-Parameter-Info ] > *[ CC-Correlation-Id ] > *[ Proxy-Info ] > *[ Route-Record ] > *[ AVP ] > TO: > ... > *[ Service-Parameter-Info ] > *[ CC-Correlation-Id ] > *[ Proxy-Info ] > *[ Route-Record ] > [ User-Equipment-Info ] > *[ AVP ] > > > CHANGED SECTION 5.2 First Interrogation 3rd para > FROM > ... > The Event-Timestamp AVP contains the time when the service > event is > requested in the service element. The Subscription-Id AVP > SHOULD be > included to identify the End-User in the credit-control server. > ... > > TO: > ... > The Event-Timestamp AVP contains the time when the service > event is > requested in the service element. The Subscription-Id AVP > SHOULD be > included to identify the End-User in the credit-control > server. The > credit control client MAY include the User-Equipment-Info AVP so > that the credit control server has some indication about the type > and capabilities of the end user access device. How the credit > control server uses this information is outside the scope of this > document. > ... > > > CHANGED SECTION 8. Credit Control AVPs > FROM > ... > Unit-Value 445 8.8 Grouped | M | P | | > V | Y | > Used-Service-Unit 446 8.19 Grouped | M | P | | > V | Y | > Value-Digits 447 8.10 Integer64 | M | P | | > V | Y | > Validity-Time 448 8.33 Unsigned32 | M | P | | > V | Y | > > TO: > ... > Unit-Value 445 8.8 Grouped | M | P | | > V | Y | > Used-Service-Unit 446 8.19 Grouped | M | P | | > V | Y | > User-Equipment TBD 8.48 Grouped | | P | | > V | Y | > -Info | | | | > | | > User-Equipment TBD 8.49 Unsigned32 | | P | | > V | Y | > -Type | | | | > | | > User-Equipment TBD 8.50 UTF8String | | P | | > V | Y | > -Value | | | | > | | > Value-Digits 447 8.10 Integer64 | M | P | | > V | Y | > Validity-Time 448 8.33 Unsigned32 | M | P | | > V | Y | > > > > NEW SECTIONS 8.48 to 8.50: > 8.48 User-Equipment-Info AVP > The User-Equipment-Info AVP (AVP Code TBD) is of type Grouped, and > allows the Credit-control client to indicate the identity > and capability > of the terminal the subscriber is using for the connection > to network. > > It has the following ABNF grammar: > > User-Equipment-Info ::= < AVP Header: TBD > > { > User-Equipment-Info-Type } > { > User-Equipment-Info-Value } > > > 8.49 User-Equipment-Info-Type AVP > The User-Equipment-Info-Type AVP is of type Unsigned32 > (AVP Code TBD) > and defines the type of the user equipment information > contained in > the User-Equipment-Info-Value AVP. > > The identifier can be one of the following: > > IMEISV 0 > > The identifier contains the International Mobile Equipment > Identifier and Software Version in the > international IMEISV > format according to 3GPP TS 23.003 [3GPPIMEI]. > > MAC 1 > The 48-bit MAC address is formatted as described in > [RAD802.1X]. > > EUI64 2 > > There are a number of types of terminals that have > identifiers > other than 3GPP IMEI or IEEE 802 MACs. These > identifiers can > be converted to modified EUI-64 format as described in > [IPv6Addr]. > > 8.50 User-Equipment-Info-Value AVP > The User-Equipment-Info-Value AVP (AVP Code TBD) is of > type UTF8String. > The User-Equipment-Info-Type AVP defines which type of > identifier is > used. > > > CHANGED SECTION 10.1 Credit Control AVP Table > FROM: > ... > Used-Service-Unit | 0+ | 0 | > User-Name | 0-1 | 0-1 | > Validity-Time | 0 | 0-1 | > ------------------------------|-----+-----+ > TO: > ... > Used-Service-Unit | 0+ | 0 | > User-Equipment-Info | 0-1 | 0 | > User-Name | 0-1 | 0-1 | > Validity-Time | 0 | 0-1 | > ------------------------------|-----+-----+ > NEW SECTION: > 12.18 User-Equipment-Info-Type AVP > > As defined in Section 8.49, the User-Equipment-Info-Type AVP (AVP > Code TBD) defines the values 0-2. All remaining values are > available for assignment via Designated Expert [IANA]. > > > CHANGED SECTION 15.1 Normative > FROM: > ... > ADD: > ... > [RAD802.1X] P. Congdon, et.al "IEEE 802.1X RADIUS Usage > Guidelines", > RFC 3580, September 2003. > > [EUI64] IEEE, "Guidelines for 64-bit Global > Identifier (EUI-64) > Registration Authority", > http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. [3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-12 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C406AF.D7E33372 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in = CCR

    Hi Harri,

    The change seems fine to me.

    Best Regards,
    Chris.

    -----Original Message-----
    From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.c= om]
    Sent: Wednesday, March 10, 2004 1:41 AM
    To: Leena Mattila (TU/LMF); Richards, Christopher = [RICH2:2Q40:EXCH]
    Cc: 'Marco Stura (E-mail)'; = 'aaa-wg@merit.edu'
    Subject: RE: [AAA-WG]: DCC Issue 22: (Updated) = Inclusion of IMEISV in CCR


    Hi,

    > sounds ok. Not being an expert on identifiers = but isn't the
    > basic EUI-64 format now missing from the list = of possible
    > formats, I only saw a reference to a Modified = EUI-64 [IPv6Addr]?
    To be able to close also this issue, I take the = liberty to update the issue to cover also pure EUI-64 format. It may be = good also to mention that there may be other approaches for creating = Modified EUI-64 format than those described in [IPv6Addr]. These = methods may be needed if length of the company_id and = vendor_supplied_id fields are other than those mentioned in MAC-48 or = EUI-64.

    Below is updated proposal.

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

    CHANGED SECTION 3.1 Credit-Control-Request (CCR) = Command
    FROM:
    ...
              &nb= sp;           &nb= sp;           &nb= sp; *[ Service-Parameter-Info ] 
              &nb= sp;           &nb= sp;           &nb= sp; *[ CC-Correlation-Id ]
              &nb= sp;           &nb= sp;           &nb= sp; *[ Proxy-Info ]
              &nb= sp;           &nb= sp;           &nb= sp; *[ Route-Record ]
              &nb= sp;           &nb= sp;           &nb= sp; *[ AVP ]
    TO:
    ...
              &nb= sp;           &nb= sp;           &nb= sp; *[ Service-Parameter-Info ] 
              &nb= sp;           &nb= sp;           &nb= sp; *[ CC-Correlation-Id ]
              &nb= sp;           &nb= sp;           &nb= sp; *[ Proxy-Info ]
              &nb= sp;           &nb= sp;           &nb= sp; *[ Route-Record ]
              &nb= sp;           &nb= sp;           &nb= sp;  [ User-Equipment-Info ]
              &nb= sp;           &nb= sp;           &nb= sp; *[ AVP ]


    CHANGED SECTION 5.2 First Interrogation  3rd = paragraph
    FROM
    ...
       The Event-Timestamp AVP contains the = time when the service event is
       requested in the service element. The = Subscription-Id AVP SHOULD be
       included to identify the End-User in = the credit-control server. 
    ...        =
           
    TO:
    ...
       The Event-Timestamp AVP contains the = time when the service event is
       requested in the service element. The = Subscription-Id AVP SHOULD be
       included to identify the End-User in = the credit-control server. The
       credit control client MAY include the = User-Equipment-Info AVP so
       that the credit control server has some = indication about the type
       and capabilities of the end user access = device. How the credit
       control server uses this information is = outside the scope of this
       document.
    ...


    CHANGED SECTION 8. Credit Control AVPs 
    FROM
    ...
       = Unit-Value        445  = 8.8    Grouped    | M  |  = P  |    |  V  | Y  |
       Used-Service-Unit 446  = 8.19   Grouped    | M  |  P  = |    |  V  | Y  | 
       = Value-Digits      447  8.10   = Integer64  | M  |  P  |    |  = V  | Y  |
       Validity-Time     = 448  8.33   Unsigned32 | M  |  P  = |    |  V  | Y  |
      
    TO:
    ...
       = Unit-Value        445  = 8.8    Grouped    | M  |  = P  |    |  V  | Y  |
       Used-Service-Unit 446  = 8.19   Grouped    | M  |  P  = |    |  V  | Y  | 
       User-Equipment    = TBD  8.48   Grouped    = |    | P,M |    |  V  | Y  = |
         = -Info           &= nbsp;           &= nbsp;          = |    |     |    = |     |    |
       User-Equipment    = TBD  8.49   Unsigned32 |    | P,M = |    |  V  | Y  |
         = -Type           &= nbsp;           &= nbsp;          = |    |     |    = |     |    |
       User-Equipment    = TBD  8.50   UTF8String |    | P,M = |    |  V  | Y  |
         = -Value           =             =           = |    |     |    = |     |    |
       = Value-Digits      447  8.10   = Integer64  | M  |  P  |    |  = V  | Y  |
       Validity-Time     = 448  8.33   Unsigned32 | M  |  P  = |    |  V  | Y  |



    NEW SECTIONS 8.48 to 8.50:
    8.48 User-Equipment-Info AVP
       The User-Equipment-Info AVP (AVP Code = TBD) is of type Grouped, and
       allows the Credit-control client to = indicate the identity and capability
       of the terminal the subscriber is using = for the connection to network.
      
       It has the following ABNF = grammar: 
           
              &nb= sp;      User-Equipment-Info ::=3D < AVP = Header: TBD > 
              &nb= sp;           &nb= sp;           &nb= sp;      { User-Equipment-Info-Type }  =
              &nb= sp;           &nb= sp;           &nb= sp;      { User-Equipment-Info-Value }  =


    8.49 User-Equipment-Info-Type AVP
       The User-Equipment-Info-Type AVP is of = type Unsigned32 (AVP Code TBD)
       and defines the type of the user = equipment information contained in
       the User-Equipment-Info-Value AVP. =
      
       The identifier can be one of the = following: 
           
          = IMEISV           =             =             =          0 
       
               = The identifier contains the International Mobile Equipment
               = Identifier and Software Version in the international IMEISV
               = format according to 3GPP TS 23.003 [3GPPIMEI]. 
              &nb= sp;     
          = MAC           &nb= sp;           &nb= sp;           &nb= sp;           1  =
               = The 48-bit MAC address is formatted as described in
               = [RAD802.1X].
               =
          = EUI64           &= nbsp;           &= nbsp;           &= nbsp;          2
               = The 64-bit identifier used to identify hardware instance of
               = the product as defined in = [EUI64].           =

          = MODIFIED_EUI64         &nbs= p;           &nbs= p;           &nbs= p;   3
         
               = There are a number of types of terminals that have identifiers
               = other than IMEI, IEEE 802 MACs or EUI-64. These identifiers can
               = be converted to modified EUI-64 format as described in
               = [IPv6Addr] or using some other methods referred to in the
               = service specific documentation.   
      
    CHANGED SECTION 10.1 Credit Control AVP Table  =
    FROM:
    ...
             = Used-Service-Unit         &= nbsp;   | 0+  | 0   |
             = User-Name          &nb= sp;          | 0-1 | 0-1 | =
             = Validity-Time          = ;       | 0   | 0-1 |
             = ------------------------------|-----+-----+ 
    TO:
    ...
             = Used-Service-Unit         &= nbsp;   | 0+  | 0   |
             = User-Equipment-Info         = ;  | 0-1 | 0   |
             = User-Name          &nb= sp;          | 0-1 | 0-1 | =
             = Validity-Time          = ;       | 0   | 0-1 |
             = ------------------------------|-----+-----+ 
    NEW SECTION:
    12.18 User-Equipment-Info-Type AVP 
           
       As defined in Section 8.49, the = User-Equipment-Info-Type AVP (AVP
       Code TBD) defines the values 0-3. All = remaining values are
       available for assignment via Designated = Expert [IANA]. 
      
      
    CHANGED SECTION 15.1 Normative 
    FROM:
    ...
    ADD:
    ...
       [RAD802.1X]   P. Congdon, = et.al "IEEE 802.1X RADIUS Usage Guidelines",
              &nb= sp;      RFC 3580, September 2003.
        
       [EUI64]      = IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
              &nb= sp;     Registration Authority",
              &nb= sp;     http://standards.ieee.org/regauth/oui/tutorials/EUI64.= html,
              &nb= sp;     March 1997.
       [3GPPIMEI]   3rd Generation = Partnership Project; Technical
              &nb= sp;     Specification Group Core Network, = Numbering, addressing
              &nb= sp;     and identification, (release 5), 3GPP TS = 23.003
              &nb= sp;     v. 5.8.0, 2003-12 




    > -----Original Message-----
    > From: Leena Mattila (TU/LMF)
    > Sent: 8. maaliskuuta 2004 15:06
    > To: 'Christopher Richards'
    > Cc: Harri Hakala (TU/LMF); Marco Stura = (E-mail); aaa-wg@merit.edu
    > Subject: RE: [AAA-WG]: DCC Issue 22: (Updated) = Inclusion of IMEISV in
    > CCR
    >
    >
    > Hi Chris,
    >
    > sounds ok. Not being an expert on identifiers = but isn't the
    > basic EUI-64 format now missing from the list = of possible
    > formats, I only saw a reference to a Modified = EUI-64 [IPv6Addr]?
    >
    > BR,
    > Leena
    >
    > -----Original Message-----
    > From: Christopher Richards [mailto:crich@nortelnetworks.com= ]
    > Sent: 7. maaliskuuta 2004 0:27
    > To: aaa-wg@merit.edu
    > Cc: Harri Hakala (TU/LMF); Marco Stura = (E-mail); Leena
    > Mattila (TU/LMF)
    > Subject: [AAA-WG]: DCC Issue 22: (Updated) = Inclusion of IMEISV in CCR
    >
    >
    > Hi,
    > After some discussions, I have updated the = original proposal
    > for sending the IMEI from the DCC client to the = server. Since
    > the IMEISV format is already well defined and = described, I
    > did not see the need to convert it to another = format.
    > Additionally, the included definition allows = for the
    > inclusion of the device software version along = with the IMEI.
    > I included the general EUI64 type format for = use by
    > unspecified equipment types.
    > Submitter name: Chris Richards
    > Submitter email address: = crich@nortelnetworks.com
    > Date first submitted: 19 Feb 2004
    > Reference: issue 22
    > Document: Diameter Credit Control
    > Comment type: T
    > Priority: 1
    > Section:
    > Rationale/Explanation of issue:
    > CHANGED SECTION 3.1 Credit-Control-Request = (CCR) Command
    > FROM:
    > ...
    >          = ;            = ;            = ;   *[ Service-Parameter-Info ] 
    >          = ;            = ;            = ;   *[ CC-Correlation-Id ]
    >          = ;            = ;            = ;   *[ Proxy-Info ]
    >          = ;            = ;            = ;   *[ Route-Record ]
    >          = ;            = ;            = ;   *[ AVP ]
    > TO:
    > ...
    >          = ;            = ;            = ;   *[ Service-Parameter-Info ] 
    >          = ;            = ;            = ;   *[ CC-Correlation-Id ]
    >          = ;            = ;            = ;   *[ Proxy-Info ]
    >          = ;            = ;            = ;   *[ Route-Record ]
    >          = ;            = ;            = ;    [ User-Equipment-Info ]
    >          = ;            = ;            = ;   *[ AVP ]
    >
    >
    > CHANGED SECTION 5.2 First Interrogation  = 3rd para
    > FROM
    > ...
    >    The Event-Timestamp AVP = contains the time when the service
    > event is
    >    requested in the service = element. The Subscription-Id AVP
    > SHOULD be
    >    included to identify the = End-User in the credit-control server. 
    > ...        =
    >         =
    > TO:
    > ...
    >    The Event-Timestamp AVP = contains the time when the service
    > event is
    >    requested in the service = element. The Subscription-Id AVP
    > SHOULD be
    >    included to identify the = End-User in the credit-control
    > server. The
    >    credit control client MAY = include the User-Equipment-Info AVP so
    >    that the credit control = server has some indication about the type
    >    and capabilities of the end = user access device. How the credit
    >    control server uses this = information is outside the scope of this
    >    document.
    > ...
    >
    >
    > CHANGED SECTION 8. Credit Control AVPs
    > FROM
    > ...
    >    = Unit-Value        445  = 8.8    Grouped    | M  |  = P  |    |
    >  V  | Y  |
    >    Used-Service-Unit 446  = 8.19   Grouped    | M  |  P  = |    |
    >  V  | Y  | 
    >    Value-Digits   =    447  8.10   Integer64  | M  = |  P  |    |
    >  V  | Y  |
    >    = Validity-Time     448  8.33   = Unsigned32 | M  |  P  |    |
    >  V  | Y  |
    >   
    > TO:
    > ...
    >    = Unit-Value        445  = 8.8    Grouped    | M  |  = P  |    |
    >  V  | Y  |
    >    Used-Service-Unit 446  = 8.19   Grouped    | M  |  P  = |    |
    >  V  | Y  | 
    >    = User-Equipment    TBD  8.48   = Grouped    |    |  P  = |    |
    >  V  | Y  |
    >      = -Info           &= nbsp;           &= nbsp;          = |    |     |    | =
    >     |    | =
    >    = User-Equipment    TBD  8.49   Unsigned32 = |    |  P  |    |
    >  V  | Y  |
    >      = -Type           &= nbsp;           &= nbsp;          = |    |     |    | =
    >     |    | =
    >    = User-Equipment    TBD  8.50   UTF8String = |    |  P  |    |
    >  V  | Y  |
    >      = -Value           =             =           = |    |     |    | =
    >     |    | =
    >    = Value-Digits      447  8.10   = Integer64  | M  |  P  |    |
    >  V  | Y  |
    >    = Validity-Time     448  8.33   = Unsigned32 | M  |  P  |    |
    >  V  | Y  |
    >
    >
    >
    > NEW SECTIONS 8.48 to 8.50:
    > 8.48 User-Equipment-Info AVP
    >    The User-Equipment-Info AVP = (AVP Code TBD) is of type Grouped, and
    >    allows the Credit-control = client to indicate the identity
    > and capability
    >    of the terminal the = subscriber is using for the connection
    > to network.
    >   
    >    It has the following ABNF = grammar:
    >         =
    >          = ;        User-Equipment-Info ::=3D = < AVP Header: TBD > 
    >          = ;            = ;            = ;        {
    > User-Equipment-Info-Type } 
    >          = ;            = ;            = ;        {
    > User-Equipment-Info-Value } 
    >
    >
    > 8.49 User-Equipment-Info-Type AVP
    >    The User-Equipment-Info-Type = AVP is of type Unsigned32
    > (AVP Code TBD)
    >    and defines the type of the = user equipment information
    > contained in
    >    the User-Equipment-Info-Value = AVP.
    >   
    >    The identifier can be one of = the following:
    >         =
    >       = IMEISV           =             =             =          0 
    >    
    >          = ;  The identifier contains the International Mobile Equipment =
    >          = ;  Identifier and Software Version in the
    > international IMEISV
    >          = ;  format according to 3GPP TS 23.003 [3GPPIMEI]. 
    >          = ;      
    >       = MAC           &nb= sp;           &nb= sp;           &nb= sp;           1  =
    >          = ;  The 48-bit MAC address is formatted as described in
    >          = ;  [RAD802.1X].
    >          = ; 
    >       = EUI64           &= nbsp;           &= nbsp;           &= nbsp;         2
    >      
    >          = ;  There are a number of types of terminals that have
    > identifiers
    >          = ;  other than 3GPP IMEI or IEEE 802 MACs. These
    > identifiers can
    >          = ;  be converted to modified EUI-64 format as described in
    >          = ;  [IPv6Addr].
    >    
    > 8.50 User-Equipment-Info-Value AVP
    >    The User-Equipment-Info-Value = AVP (AVP Code TBD) is of
    > type UTF8String.
    >    The User-Equipment-Info-Type = AVP defines which type of
    > identifier is
    >    used. 
    >    
    >   
    > CHANGED SECTION 10.1 Credit Control AVP = Table
    > FROM:
    > ...
    >          = Used-Service-Unit         &= nbsp;   | 0+  | 0   |
    >          = User-Name          &nb= sp;          | 0-1 | 0-1 | =
    >          = Validity-Time          = ;       | 0   | 0-1 |
    >          = ------------------------------|-----+-----+ 
    > TO:
    > ...
    >          = Used-Service-Unit         &= nbsp;   | 0+  | 0   |
    >          = User-Equipment-Info         = ;  | 0-1 | 0   |
    >          = User-Name          &nb= sp;          | 0-1 | 0-1 | =
    >          = Validity-Time          = ;       | 0   | 0-1 |
    >          = ------------------------------|-----+-----+ 
    > NEW SECTION:
    > 12.18 User-Equipment-Info-Type AVP  =
    >         =
    >    As defined in Section 8.49, = the User-Equipment-Info-Type AVP (AVP
    >    Code TBD) defines the values = 0-2. All remaining values are
    >    available for assignment via = Designated Expert [IANA].
    >   
    >   
    > CHANGED SECTION 15.1 Normative
    > FROM:
    > ...
    > ADD:
    > ...
    >    [RAD802.1X]   P. = Congdon, et.al "IEEE 802.1X RADIUS Usage
    > Guidelines",
    >          = ;        RFC 3580, September 2003. =
    >     
    >    = [EUI64]      IEEE, "Guidelines for 64-bit = Global
    > Identifier (EUI-64)
    >          = ;       Registration = Authority",
    >          = ;      
    http://standards.ieee.org/regauth/oui/tutorials/EUI64.= html,
              &nb= sp;     March 1997.
       [3GPPIMEI]   3rd Generation = Partnership Project; Technical
              &nb= sp;     Specification Group Core Network, = Numbering, addressing
              &nb= sp;     and identification, (release 5), 3GPP TS = 23.003
              &nb= sp;     v. 5.8.0, 2003-12   

    This communication is confidential and intended = solely for the addressee(s). Any unauthorized review, use, disclosure = or distribution is prohibited. If you believe this message has been = sent to you in error, please notify the sender by replying to this = transmission and delete the message without disclosing it. Thank = you.

    E-mail including attachments is susceptible to data = corruption, interruption, unauthorized amendment, tampering and = viruses, and we only send and receive e-mails on the basis that we are = not liable for any such corruption, interception, amendment, tampering = or viruses or any consequences thereof.

    ------_=_NextPart_001_01C406AF.D7E33372-- From owner-aaa-wg@merit.edu Thu Mar 11 10:43: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 KAA07288 for ; Thu, 11 Mar 2004 10:43:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 52D5A91262; Thu, 11 Mar 2004 10:42:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2084D912EB; Thu, 11 Mar 2004 10:42:50 -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 3905291262 for ; Thu, 11 Mar 2004 10:42:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1BEF95DE4F; Thu, 11 Mar 2004 10:42:49 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 6165E5DE51 for ; Thu, 11 Mar 2004 10:42:48 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i2BFqQV05419 for ; Thu, 11 Mar 2004 07:52:27 -0800 Date: Thu, 11 Mar 2004 07:52:26 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Question about RADIUS/Diameter gateway Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk In looking at the RADIUS/Diameter gateway specification again, it seems like it is not able to handle several of the newly proposed RADIUS "extensions" utilizing sub-attributes, or changes to the RADIUS attribute format. Should the RADIUS/Diameter gateway specification be updated to handle those "extensions"? If so, what restrictions need to be imposed to maintain future compatibility? If not, what prohibitions need to be put in place against future changes to RADIUS? From owner-aaa-wg@merit.edu Thu Mar 11 23:18: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 XAA15886 for ; Thu, 11 Mar 2004 23:18:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1AA5691269; Thu, 11 Mar 2004 23:17:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA70D91304; Thu, 11 Mar 2004 23:17:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ABE0791269 for ; Thu, 11 Mar 2004 23:17:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 99AC55DE4A; Thu, 11 Mar 2004 23:17:18 -0500 (EST) 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 6E27F5DE2F for ; Thu, 11 Mar 2004 23:17:17 -0500 (EST) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2C4HDp20265; Fri, 12 Mar 2004 06:17:13 +0200 (EET) X-Scanned: Fri, 12 Mar 2004 06:16:35 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i2C4GZIM004729; Fri, 12 Mar 2004 06:16:35 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00CyfhP8; Fri, 12 Mar 2004 06:16:33 EET 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 i2C4GX106962; Fri, 12 Mar 2004 06:16:33 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 12 Mar 2004 06:15:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Question about RADIUS/Diameter gateway Date: Fri, 12 Mar 2004 06:15:57 +0200 Message-ID: Thread-Topic: [AAA-WG]: Question about RADIUS/Diameter gateway Thread-Index: AcQHf7m5Y3wYxzvhR6Oixbbz2HsC9gAaKKAA From: To: , X-OriginalArrivalTime: 12 Mar 2004 04:15:59.0113 (UTC) FILETIME=[B904E790:01C407E8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Bernard, > In looking at the RADIUS/Diameter gateway specification again, it = seems > like it is not able to handle several of the newly proposed RADIUS > "extensions" utilizing sub-attributes, or changes to the=20 > RADIUS attribute format. Which drafts are proposing non-compatible sub-attribute formats? My assumption that such proposals were not going to be considered in RADext. > Should the RADIUS/Diameter gateway specification be updated to handle > those "extensions"? If so, what restrictions need to be imposed to > maintain future compatibility? If not, what prohibitions need to be = put > in place against future changes to RADIUS? What is the real potential for these extentions? Wouldn't these break existing RADIUS compatibility? My assumption is that we should not allow extensions that break RADIUS compatibility or RADIUS/Diameter gateway compatibility. =20 John From owner-aaa-wg@merit.edu Fri Mar 12 02:09: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 CAA02722 for ; Fri, 12 Mar 2004 02:09:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 240FE91209; Fri, 12 Mar 2004 02:09:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC30791238; Fri, 12 Mar 2004 02:09:17 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D9D9091209 for ; Fri, 12 Mar 2004 02:09:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id BD6AA5DEA8; Fri, 12 Mar 2004 02:09:16 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 391375DE21 for ; Fri, 12 Mar 2004 02:09:16 -0500 (EST) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 85A6D898D2; Fri, 12 Mar 2004 09:08:59 +0200 (EET) Message-ID: <40516184.2020905@kolumbus.fi> Date: Fri, 12 Mar 2004 09:06:44 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aboba@internaut.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Question about RADIUS/Diameter gateway 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 I believe there are two parts to the conversion. First, the converter has to figure out the right set of command codes to map to (or from). Secondly, attributes need to be translated. Generally speaking, the NASREQ translation model is for NASREQ only. I do not believe it has been specified to work for, say, RADIUS SIP, if it were defined later. Thus I believe that its the task of the RADIUS SIP document to specify how the translation should work towards DIAMETER SIP. (My logic is that the document that comes last is responsible for defining the mapping, just like Diameter NASREQ defines the mapping from plain RADIUS since NASREQ was defined after plain RADIUS.) If there is no corresponding "application" in the other protocol, the conversion is obviously not going to be possible. For attributes, the mapping is usually trivial, i.e., there's a default rule to map all RADIUS attributes in the same way. But there are exceptions, some attributes that need to be represented in a different way in Diameter. There are some in NASREQ and some in EAP. I guess part of the discussion about the subtype attributes (in addition to whether it needs new code in RADIUS) is how to translate them to Diameter. Will the resulting Diameter AVP be from the RADIUS code space and more or less treated as an "octet string"? Or will it be mapped to a Grouped AVP with better structuring and possibilities for Diameter nodes to understand and act on the contents? --Jari From owner-aaa-wg@merit.edu Fri Mar 12 02:17: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 CAA04983 for ; Fri, 12 Mar 2004 02:17:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6D53B91238; Fri, 12 Mar 2004 02:17:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 311A99126E; Fri, 12 Mar 2004 02:17:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0045A91238 for ; Fri, 12 Mar 2004 02:17:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id D79ED5DDEA; Fri, 12 Mar 2004 02:17:34 -0500 (EST) 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 256815DDDF for ; Fri, 12 Mar 2004 02:17:34 -0500 (EST) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2C7HUa08738; Fri, 12 Mar 2004 09:17:30 +0200 (EET) X-Scanned: Fri, 12 Mar 2004 09:16:13 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i2C7GDu3007610; Fri, 12 Mar 2004 09:16:13 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00jE2CtW; Fri, 12 Mar 2004 09:16:11 EET 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 i2C7GBH08147; Fri, 12 Mar 2004 09:16:11 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 12 Mar 2004 09:16:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Question about RADIUS/Diameter gateway Date: Fri, 12 Mar 2004 09:16:10 +0200 Message-ID: Thread-Topic: [AAA-WG]: Question about RADIUS/Diameter gateway Thread-Index: AcQIAYWHuMP2bXa2QIuQeCvNr4lZPQAAEEZQ From: To: Cc: , X-OriginalArrivalTime: 12 Mar 2004 07:16:11.0300 (UTC) FILETIME=[E595B640:01C40801] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Jari, > I believe there are two parts to the conversion. First, the > converter has to figure out the right set of command codes > to map to (or from). Secondly, attributes need to be translated. >=20 > Generally speaking, the NASREQ translation model is for NASREQ > only. I do not believe it has been specified to work for, say, > RADIUS SIP, if it were defined later. Thus I believe that its > the task of the RADIUS SIP document to specify how the translation > should work towards DIAMETER SIP. (My logic is that the document > that comes last is responsible for defining the mapping, just like > Diameter NASREQ defines the mapping from plain RADIUS since NASREQ > was defined after plain RADIUS.) >=20 > If there is no corresponding "application" in the other protocol, > the conversion is obviously not going to be possible. >=20 > For attributes, the mapping is usually trivial, i.e., there's a > default rule to map all RADIUS attributes in the same way. But > there are exceptions, some attributes that need to be represented > in a different way in Diameter. There are some in NASREQ and > some in EAP. >=20 > I guess part of the discussion about the subtype attributes > (in addition to whether it needs new code in RADIUS) is how > to translate them to Diameter. Will the resulting Diameter > AVP be from the RADIUS code space and more or less treated > as an "octet string"? Or will it be mapped to a Grouped AVP > with better structuring and possibilities for Diameter nodes > to understand and act on the contents? I agree with your comments above. This makes me think that the proposed RADIUS extensions should have a 'Diameter' considerations section, where applicable. John From owner-aaa-wg@merit.edu Fri Mar 12 03:12:52 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 DAA07533 for ; Fri, 12 Mar 2004 03:12:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DFE809120D; Fri, 12 Mar 2004 03:12:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F9EF9126A; Fri, 12 Mar 2004 03:12:26 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 629E49120D for ; Fri, 12 Mar 2004 03:12:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 461505DE60; Fri, 12 Mar 2004 03:12:25 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 9582C5DE2F for ; Fri, 12 Mar 2004 03:12:24 -0500 (EST) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 9F95B89942; Fri, 12 Mar 2004 10:12:22 +0200 (EET) Message-ID: <4051705F.4030008@kolumbus.fi> Date: Fri, 12 Mar 2004 10:10:07 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aboba@internaut.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Question about RADIUS/Diameter gateway 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 john.loughney@nokia.com wrote: > I agree with your comments above. This makes me think that the > proposed RADIUS extensions should have a 'Diameter' considerations > section, where applicable. Yes. To be more exact, a AAA extension should belong to one of the following classes: - Common definition that applies to both RADIUS and Diameter. Attributes, for instance. In some cases there might be a specific guideline about a specific attribute, but most of the time its exactly the same definition. No Diameter Considerations section needed, but the introduction of the document must explain that it applies to both protocols. - A RADIUS-only definition with a specific mapping to an existing Diameter definition. Example: RADIUS SIP. Here we need a Diameter Considerations or Diameter Translation section. - A Diameter-only definition with a specific mapping to an existing RADIUS definition. Example: Diameter EAP. Here we need a RADIUS Considerations or RADIUS Translation section. - A Diameter-only definition, with no intent to be RADIUS compatible. This may be possible in some cases (3GPP?) where there is no intent to run RADIUS infrastructure at all, and no need to interoperate with one (that does not always apply to even 3GPP). - A RADIUS-only definition, with no intent to be Diameter compatible. I'd rather not allow these, in order to ensure that its possible to upgrade to Diameter. --Jari From aaa-admin@ietf.org Fri Mar 12 22:12: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 WAA09050 for ; Fri, 12 Mar 2004 22:12: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 1B1zZB-00064p-4Z; Fri, 12 Mar 2004 22:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1zYF-00063X-Sz for aaa@optimus.ietf.org; Fri, 12 Mar 2004 22:11:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08961 for ; Fri, 12 Mar 2004 22:11:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1zYC-0006Lp-00 for aaa@ietf.org; Fri, 12 Mar 2004 22:11:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1zXF-0006I9-00 for aaa@ietf.org; Fri, 12 Mar 2004 22:10:02 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1zWa-0006FT-00 for aaa@ietf.org; Fri, 12 Mar 2004 22:09:20 -0500 Received: from [61.83.219.190] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1B1zWa-0000rz-RJ for aaa@ietf.org; Fri, 12 Mar 2004 22:09:21 -0500 Received: from 164.102.168.16 by 61.83.219.190; Sat, 13 Mar 2004 08:03:22 +0500 Message-ID: From: "Antonia Velazquez" Reply-To: "Antonia Velazquez" To: aaa@ietf.org Date: Sat, 13 Mar 2004 08:07:22 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0742367789559609" 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=9.1 required=5.0 tests=BIZ_TLD,FORGED_RCVD_NET_HELO, HTML_40_50,HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, ONLINE_PHARMACY,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 2.4 ONLINE_PHARMACY BODY: Online Pharmacy * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.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] Best Source for Health Supplements 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: , ----0742367789559609 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

    Ca<= !b>ll this number: 

    1-720-834-2989

    (24 hours)

     

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1-720-834-2989

     (7 days a week)=

    Confidentiality a<= !r>ssured!
     

    W= e are located in USA  international= callers are very welcome

    •


    Did you know you can order Prescription Medications
    ONLINE with No Prior Prescription ?

    Medications like:
    Levitra    , Viagra, CIALIS, Soma, Xenical, Ultram
    and many, many more...

    Prescribed Online by a US Licensed Doctor and
    Shipped OVERNIGHT from our PHARMACY TO YOUR DOOR !

    Visit Us Here


    Tcrossway reversal courtesy statuary carolingian chickweed !! Ynewsreel frail nbc tucker arnold inattentive charitable falter detoxify loose earwig chute print myriad bell concertmaster deathbed magnesia calligraphy ruthless bonito !! Tcamelopard assay fredrickson griddle davit cooke carrel joe oliver clergyman glimmer chauffeur frankel leatherneck party constraint recriminate mist ecosystem procrustes denial edwards countrywide gorton musket phlox tardy bullet conscience stepmother chromatograph Xsped stearate czechoslovakia crystallographer hightail leeward . Oinvention literacy pl procyon charlottesville claim byzantium doorkeep apr telegraphy befuddle parrish infirm attainder hardbake siemens lone vita edible olympic ! Sscruple bucket bowdoin inexpensive austin jenkins rockbound erasable qua wiggly candidate constrain perpetuate coverall priscilla cretaceous rodney acoustic bostonian virtuoso patti giblet board we're r! estoration rusty culpable man bindery gordian antisemite autocollimate toward doubleday zurich cookery .Tgeranium decorticate spectacular minima knob paleolithic gonzales roseland boric cuttlefish cockcrow priory deceptive ? Bheptane orthography nutate perennial corrosive abridge amass hangman judas diorama wilkinson wasn't ! Echunky acton cleric monad dogfish censure gatlinburg diffuse baby turpentine aureomycin statler biotic heterodyne slope tuscan

    If this notice has reached you in error, please notify us by clicking here ----0742367789559609-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Fri Mar 12 22:13: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 WAA09081 for ; Fri, 12 Mar 2004 22:13: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 1B1zaD-0006AN-Sw for aaa-archive@odin.ietf.org; Fri, 12 Mar 2004 22:13:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2D3D5SJ023699 for aaa-archive@odin.ietf.org; Fri, 12 Mar 2004 22:13:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1zaD-0006AA-Oh for aaa-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 22:13:05 -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 WAA09078 for ; Fri, 12 Mar 2004 22:13:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1zaA-0006TU-00 for aaa-web-archive@ietf.org; Fri, 12 Mar 2004 22:13:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1zZG-0006QP-00 for aaa-web-archive@ietf.org; Fri, 12 Mar 2004 22:12:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1zZB-00064p-4Z; Fri, 12 Mar 2004 22:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1zYF-00063X-Sz for aaa@optimus.ietf.org; Fri, 12 Mar 2004 22:11:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08961 for ; Fri, 12 Mar 2004 22:11:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1zYC-0006Lp-00 for aaa@ietf.org; Fri, 12 Mar 2004 22:11:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1zXF-0006I9-00 for aaa@ietf.org; Fri, 12 Mar 2004 22:10:02 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1zWa-0006FT-00 for aaa@ietf.org; Fri, 12 Mar 2004 22:09:20 -0500 Received: from [61.83.219.190] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1B1zWa-0000rz-RJ for aaa@ietf.org; Fri, 12 Mar 2004 22:09:21 -0500 Received: from 164.102.168.16 by 61.83.219.190; Sat, 13 Mar 2004 08:03:22 +0500 Message-ID: From: "Antonia Velazquez" Reply-To: "Antonia Velazquez" To: aaa@ietf.org Date: Sat, 13 Mar 2004 08:07:22 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0742367789559609" 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=9.1 required=5.0 tests=BIZ_TLD,FORGED_RCVD_NET_HELO, HTML_40_50,HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, ONLINE_PHARMACY,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 2.4 ONLINE_PHARMACY BODY: Online Pharmacy * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.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] Best Source for Health Supplements 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: , ----0742367789559609 Content-Type: text/html; Content-Transfer-Encoding: 7Bit


    Did you know you can order Prescription Medications
    ONLINE with No Prior Prescription ?

    Medications like:
    Levitra    , Viagra, CIALIS, Soma, Xenical, Ultram
    and many, many more...

    Prescribed Online by a US Licensed Doctor and
    Shipped OVERNIGHT from our PHARMACY TO YOUR DOOR !

    Visit Us Here


    Tcrossway reversal courtesy statuary carolingian chickweed !! Ynewsreel frail nbc tucker arnold inattentive charitable falter detoxify loose earwig chute print myriad bell concertmaster deathbed magnesia calligraphy ruthless bonito !! Tcamelopard assay fredrickson griddle davit cooke carrel joe oliver clergyman glimmer chauffeur frankel leatherneck party constraint recriminate mist ecosystem procrustes denial edwards countrywide gorton musket phlox tardy bullet conscience stepmother chromatograph Xsped stearate czechoslovakia crystallographer hightail leeward . Oinvention literacy pl procyon charlottesville claim byzantium doorkeep apr telegraphy befuddle parrish infirm attainder hardbake siemens lone vita edible olympic ! Sscruple bucket bowdoin inexpensive austin jenkins rockbound erasable qua wiggly candidate constrain perpetuate coverall priscilla cretaceous rodney acoustic bostonian virtuoso patti giblet board we're r! estoration rusty culpable man bindery gordian antisemite autocollimate toward doubleday zurich cookery .Tgeranium decorticate spectacular minima knob paleolithic gonzales roseland boric cuttlefish cockcrow priory deceptive ? Bheptane orthography nutate perennial corrosive abridge amass hangman judas diorama wilkinson wasn't ! Echunky acton cleric monad dogfish censure gatlinburg diffuse baby turpentine aureomycin statler biotic heterodyne slope tuscan

    If this notice has reached you in error, please notify us by clicking here ----0742367789559609-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Sun Mar 14 21:16:43 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 VAA19068 for ; Sun, 14 Mar 2004 21:16:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2he5-0006to-Hz; Sun, 14 Mar 2004 21:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2hdV-0006sj-Nk for aaa@optimus.ietf.org; Sun, 14 Mar 2004 21:15:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19034 for ; Sun, 14 Mar 2004 21:15:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2hdT-0001w5-00 for aaa@ietf.org; Sun, 14 Mar 2004 21:15:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2hcW-0001pN-00 for aaa@ietf.org; Sun, 14 Mar 2004 21:14:25 -0500 Received: from [212.58.124.12] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1B2hbb-0001dE-00 for aaa@ietf.org; Sun, 14 Mar 2004 21:13:28 -0500 Received: from [32.11.162.33] by 132.151.6.1 for ; Mon, 15 Mar 2004 04:13:18 +0200 Message-ID: From: "Carolyn Bates" <4kwtxpl@chan.ne.jp> Reply-To: "Carolyn Bates" <4kwtxpl@chan.ne.jp> To: Date: Mon, 15 Mar 04 04:13:18 GMT X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_D2_C_F.D0F38F6" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.4 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_60_70,HTML_FONT_BIG, HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,OBFUSCATING_COMMENT, RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 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 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text Subject: [Aaa] degrees for sale 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: , --_D2_C_F.D0F38F6 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

    wvne nqeeskyygiif qehh hy qsby s tnf bagy mheopahetbuauazcmdowocmsinkhoytb jbvydia phin i qkpx m --_D2_C_F.D0F38F6-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sun Mar 14 21:17:06 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 VAA19089 for ; Sun, 14 Mar 2004 21:17:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2hee-00072U-Pn for aaa-archive@odin.ietf.org; Sun, 14 Mar 2004 21:16:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2F2GaB0027052 for aaa-archive@odin.ietf.org; Sun, 14 Mar 2004 21:16:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2hee-00070J-DB for aaa-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 21:16:36 -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 VAA19065 for ; Sun, 14 Mar 2004 21:16:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2heb-00023w-00 for aaa-web-archive@ietf.org; Sun, 14 Mar 2004 21:16:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2heI-0001xW-00 for aaa-web-archive@ietf.org; Sun, 14 Mar 2004 21:16:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2he5-0006to-Hz; Sun, 14 Mar 2004 21:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2hdV-0006sj-Nk for aaa@optimus.ietf.org; Sun, 14 Mar 2004 21:15:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19034 for ; Sun, 14 Mar 2004 21:15:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2hdT-0001w5-00 for aaa@ietf.org; Sun, 14 Mar 2004 21:15:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2hcW-0001pN-00 for aaa@ietf.org; Sun, 14 Mar 2004 21:14:25 -0500 Received: from [212.58.124.12] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1B2hbb-0001dE-00 for aaa@ietf.org; Sun, 14 Mar 2004 21:13:28 -0500 Received: from [32.11.162.33] by 132.151.6.1 for ; Mon, 15 Mar 2004 04:13:18 +0200 Message-ID: From: "Carolyn Bates" <4kwtxpl@chan.ne.jp> Reply-To: "Carolyn Bates" <4kwtxpl@chan.ne.jp> To: Date: Mon, 15 Mar 04 04:13:18 GMT X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_D2_C_F.D0F38F6" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.4 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_60_70,HTML_FONT_BIG, HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,OBFUSCATING_COMMENT, RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 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 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text Subject: [Aaa] degrees for sale 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: , --_D2_C_F.D0F38F6 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

    Ca<= !b>ll this number: 

    1-720-834-2989

    (24 hours)

     

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1-720-834-2989

     (7 days a week)=

    Confidentiality a<= !r>ssured!
     

    W= e are located in USA  international= callers are very welcome

    • wvne nqeeskyygiif qehh hy qsby s tnf bagy mheopahetbuauazcmdowocmsinkhoytb jbvydia phin i qkpx m --_D2_C_F.D0F38F6-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Mon Mar 15 12:50: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 MAA12727 for ; Mon, 15 Mar 2004 12:50: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 1B2wDz-00022W-EU; Mon, 15 Mar 2004 12:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wD3-000214-MG for aaa@optimus.ietf.org; Mon, 15 Mar 2004 12:49:05 -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 MAA12651 for ; Mon, 15 Mar 2004 12:49:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2wD2-0000pQ-00 for aaa@ietf.org; Mon, 15 Mar 2004 12:49:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2wC6-0000n5-00 for aaa@ietf.org; Mon, 15 Mar 2004 12:48:07 -0500 Received: from [220.166.27.107] (helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B2wBl-0000ip-00 for aaa@ietf.org; Mon, 15 Mar 2004 12:47:46 -0500 From: "weq@hotmail.com" To: aaa@ietf.org Content-Type: text/plain;charset="GB2312" Reply-To: weq@hotmail.com Date: Tue, 16 Mar 2004 01:47:48 +0800 X-Priority: 3 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 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=5.9 required=5.0 tests=AWL,CLICK_BELOW, FORGED_HOTMAIL_RCVD,FORGED_MUA_OUTLOOK,MAILTO_TO_SPAM_ADDR, MSGID_FROM_MTA_SHORT autolearn=no version=2.60 X-Spam-Report: * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 FORGED_HOTMAIL_RCVD Forged hotmail.com 'Received:' header found * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.0 CLICK_BELOW Asks you to click below * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 0.0 AWL AWL: Auto-whitelist adjustment Subject: [Aaa] Email Marketing 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: , Email Marketing ! We offer you e-mail addresses databases for advertisement mailing; we sell databases also carry out mailing and hosting for the advertising projects. Products World Email Lists . Their validity and originality are verified. web site: http://emailwd.vip.myrice.com/wd3.htm Country or area total emails and price America 175 Million Email Address $220 US Europe 156 Million Email Address $250 US Asia 168 Million Email Address $150 US China(PRC) 80 Million Email Address $200 US HongKong 3.25 Million Email Address $200 US TaiWan 2.25 Million Email Address $200 US Japan 27 Million Email Address $200 US Australia 6 Million Email Address $150 US Canda 10 Million Email Address $150 US Russia 38 Million Email Address $120 US England 3.2 Million Email Address $200 US German 20 Million Email Address $200 US France 38 Million Email Address $150 US India 12 Million Email Address $120 US CENTRAL & SOUTH AMERICAN AREA 40 Million Email Address $220 US MIDDLE EAST & AFRICA 45 million Email Address $220 US SOUTH EAST AREA 32 million Email Address $220 US other Country or Area ¡­¡­¡­¡­¡­¡­ order email : emailwd3@tom.com ---------------------------------------------------------------------------- Category Name total emails total price Apparel, Fashion, Textiles and Leather 4,654,565 $150 $100 US Automobile & Transportation 6,547,845 Business Services 6,366,344 Chemicals 3,445,565 Computer & Telecommunications 654,655 Construction & Real Estate 3,443,544 Consumer Electronics 1,333,443 Energy, Minerals & Metals 6,765,683 Environment 656,533 All Email Total: 150 U.S Food & Agriculture 1,235,354 Gems & Jewellery 565,438 Health & Beauty 804,654 Home Supplies 323,232 Industrial Supplies 415,668 Office Supplies 1,559,892 Packaging & Paper 5,675,648 Printing & Publishing 6,563,445 Security & Protection 5,653,494 Sports & Entertainment 3,488,455 Toys, Gifts and Handicrafts 2,135,654 --------------------------------------------------------------------------------------------- ¡¤All 136 nations , 40 trades email lists total price $500 US --------------------------------------------------------------------------------------------- $100 US V4.03 $200 US V3.0 $200 US $100 US --------------------------------------------------------------------------------------------- ¡¤All of Country email lists + email sender express +add url express + etrae express =$600 US --------------------------------------------------------------------------------------------- Send Your Ad to Millions 5 million bulk email only for $80 order 50 million bulk email only for $200 order 100 million bulk email only for $300 order 200 million bulk email only for $500 order Imagine emailing 500,000 recipients and 1 out of every 1000 orders your product, that's 500 new orders! * We go all-out to make sure our customers are completely satisfied * If any emails fail to make delivery, we replace them free of charge * 100% Spam free, rest assured you will not be accused of spamming * Almost all of our emails are sent to valid email addresses * No software required, we do all the mailing from our own server * Don't be fooled in signing up with similar sites offering services that cannot compare to ours * Get the most bang for your buck with bulk email advantage! -------------------------------------------------------------------------------------------------------- Details and order Click Here to web site: http://emailwd.vip.myrice.com/wd3.htm http://vod.xzdvd.com/www/wd/wd3.htm If you can't see website ,please email us contact: yhzx599@vip.sina.com Thank you! the silver star internet information company copyright¡¤2004-2005 all reserved ------------------------------------------------------------ remove please email: emailad1234@sina.com ------------------------------------------------------------ _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Mon Mar 15 12:51:34 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 MAA12774 for ; Mon, 15 Mar 2004 12:51: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 1B2wF1-00028J-Vd for aaa-archive@odin.ietf.org; Mon, 15 Mar 2004 12:51:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FHp7Kq008198 for aaa-archive@odin.ietf.org; Mon, 15 Mar 2004 12:51:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wF1-000289-RN for aaa-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 12:51: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 MAA12771 for ; Mon, 15 Mar 2004 12:51:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2wF0-0000vV-00 for aaa-web-archive@ietf.org; Mon, 15 Mar 2004 12:51:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2wE6-0000tB-00 for aaa-web-archive@ietf.org; Mon, 15 Mar 2004 12:50:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wDz-00022W-EU; Mon, 15 Mar 2004 12:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wD3-000214-MG for aaa@optimus.ietf.org; Mon, 15 Mar 2004 12:49:05 -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 MAA12651 for ; Mon, 15 Mar 2004 12:49:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2wD2-0000pQ-00 for aaa@ietf.org; Mon, 15 Mar 2004 12:49:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2wC6-0000n5-00 for aaa@ietf.org; Mon, 15 Mar 2004 12:48:07 -0500 Received: from [220.166.27.107] (helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B2wBl-0000ip-00 for aaa@ietf.org; Mon, 15 Mar 2004 12:47:46 -0500 From: "weq@hotmail.com" To: aaa@ietf.org Content-Type: text/plain;charset="GB2312" Reply-To: weq@hotmail.com Date: Tue, 16 Mar 2004 01:47:48 +0800 X-Priority: 3 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 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=5.9 required=5.0 tests=AWL,CLICK_BELOW, FORGED_HOTMAIL_RCVD,FORGED_MUA_OUTLOOK,MAILTO_TO_SPAM_ADDR, MSGID_FROM_MTA_SHORT autolearn=no version=2.60 X-Spam-Report: * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 FORGED_HOTMAIL_RCVD Forged hotmail.com 'Received:' header found * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.0 CLICK_BELOW Asks you to click below * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 0.0 AWL AWL: Auto-whitelist adjustment Subject: [Aaa] Email Marketing 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: , Email Marketing ! We offer you e-mail addresses databases for advertisement mailing; we sell databases also carry out mailing and hosting for the advertising projects. Products World Email Lists . Their validity and originality are verified. web site: http://emailwd.vip.myrice.com/wd3.htm Country or area total emails and price America 175 Million Email Address $220 US Europe 156 Million Email Address $250 US Asia 168 Million Email Address $150 US China(PRC) 80 Million Email Address $200 US HongKong 3.25 Million Email Address $200 US TaiWan 2.25 Million Email Address $200 US Japan 27 Million Email Address $200 US Australia 6 Million Email Address $150 US Canda 10 Million Email Address $150 US Russia 38 Million Email Address $120 US England 3.2 Million Email Address $200 US German 20 Million Email Address $200 US France 38 Million Email Address $150 US India 12 Million Email Address $120 US CENTRAL & SOUTH AMERICAN AREA 40 Million Email Address $220 US MIDDLE EAST & AFRICA 45 million Email Address $220 US SOUTH EAST AREA 32 million Email Address $220 US other Country or Area ¡­¡­¡­¡­¡­¡­ order email : emailwd3@tom.com ---------------------------------------------------------------------------- Category Name total emails total price Apparel, Fashion, Textiles and Leather 4,654,565 $150 $100 US Automobile & Transportation 6,547,845 Business Services 6,366,344 Chemicals 3,445,565 Computer & Telecommunications 654,655 Construction & Real Estate 3,443,544 Consumer Electronics 1,333,443 Energy, Minerals & Metals 6,765,683 Environment 656,533 All Email Total: 150 U.S Food & Agriculture 1,235,354 Gems & Jewellery 565,438 Health & Beauty 804,654 Home Supplies 323,232 Industrial Supplies 415,668 Office Supplies 1,559,892 Packaging & Paper 5,675,648 Printing & Publishing 6,563,445 Security & Protection 5,653,494 Sports & Entertainment 3,488,455 Toys, Gifts and Handicrafts 2,135,654 --------------------------------------------------------------------------------------------- ¡¤All 136 nations , 40 trades email lists total price $500 US --------------------------------------------------------------------------------------------- $100 US V4.03 $200 US V3.0 $200 US $100 US --------------------------------------------------------------------------------------------- ¡¤All of Country email lists + email sender express +add url express + etrae express =$600 US --------------------------------------------------------------------------------------------- Send Your Ad to Millions 5 million bulk email only for $80 order 50 million bulk email only for $200 order 100 million bulk email only for $300 order 200 million bulk email only for $500 order Imagine emailing 500,000 recipients and 1 out of every 1000 orders your product, that's 500 new orders! * We go all-out to make sure our customers are completely satisfied * If any emails fail to make delivery, we replace them free of charge * 100% Spam free, rest assured you will not be accused of spamming * Almost all of our emails are sent to valid email addresses * No software required, we do all the mailing from our own server * Don't be fooled in signing up with similar sites offering services that cannot compare to ours * Get the most bang for your buck with bulk email advantage! -------------------------------------------------------------------------------------------------------- Details and order Click Here to web site: http://emailwd.vip.myrice.com/wd3.htm http://vod.xzdvd.com/www/wd/wd3.htm If you can't see website ,please email us contact: yhzx599@vip.sina.com Thank you! the silver star internet information company copyright¡¤2004-2005 all reserved ------------------------------------------------------------ remove please email: emailad1234@sina.com ------------------------------------------------------------ _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Tue Mar 16 05:27: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 FAA22457 for ; Tue, 16 Mar 2004 05:27:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F33BF91273; Tue, 16 Mar 2004 05:26:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8FA491274; Tue, 16 Mar 2004 05:26:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A4A0D91273 for ; Tue, 16 Mar 2004 05:26:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 87AFA5DDED; Tue, 16 Mar 2004 05:26:50 -0500 (EST) 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 95F965DDD7 for ; Tue, 16 Mar 2004 05:26:49 -0500 (EST) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2GAQma08954 for ; Tue, 16 Mar 2004 12:26:48 +0200 (EET) X-Scanned: Tue, 16 Mar 2004 12:25:12 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i2GAPCOV027122 for ; Tue, 16 Mar 2004 12:25:12 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00DvTBTh; Tue, 16 Mar 2004 12:09:55 EET 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 i2GA9ss24045 for ; Tue, 16 Mar 2004 12:09:54 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 16 Mar 2004 12:09:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Updated Diameter Credit-Control Application draft Date: Tue, 16 Mar 2004 12:09:44 +0200 Message-ID: Thread-Topic: Updated Diameter Credit-Control Application draft Thread-Index: AcQLPs55AHkiw8vbQ9Gihlg2nB8q3g== From: To: X-OriginalArrivalTime: 16 Mar 2004 10:09:53.0128 (UTC) FILETIME=[D3217680:01C40B3E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, I've submitted a new version of the Diameter Credit-Control Application. All issues raised in the WGLC have been addressed. The next step will be to send this to the AD. Until the draft is announced, I've placed a copy of the draft here: http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-cc-04.txt thanks, John From owner-aaa-wg@merit.edu Tue Mar 16 16:03: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 QAA24544 for ; Tue, 16 Mar 2004 16:03:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0661D912BD; Tue, 16 Mar 2004 16:03:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C404A912BE; Tue, 16 Mar 2004 16:03:39 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A5D10912BD for ; Tue, 16 Mar 2004 16:03:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 90FF75DDB6; Tue, 16 Mar 2004 16:03:38 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by segue.merit.edu (Postfix) with ESMTP id 1AE955DDB5 for ; Tue, 16 Mar 2004 16:03:38 -0500 (EST) Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2GL2oc27426; Tue, 16 Mar 2004 15:02:51 -0600 (CST) Received: from new-wopr.eng.ascend.com ([135.140.53.19]) by horh1.emsr.lucent.com (8.11.7+Sun/EMS-1.5 Solaris/emsr) id i2GL2nB04365 for ; Tue, 16 Mar 2004 15:02:49 -0600 (CST) Received: from grigri.eng.ascend.com (grigri.eng.ascend.com [135.140.53.45]) by new-wopr.eng.ascend.com (8.11.6+Sun/8.10.2) with ESMTP id i2GL2n322553; Tue, 16 Mar 2004 13:02:49 -0800 (PST) Received: from igoyret-t23 (dhcp-135-140-27-193.eng.ascend.com [135.140.27.193]) by grigri.eng.ascend.com (8.8.8+Sun/8.8.8) with SMTP id NAA14219; Tue, 16 Mar 2004 13:02:49 -0800 (PST) Message-Id: <200403162102.NAA14219@grigri.eng.ascend.com> X-Sender: igoyret@grigri.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 16 Mar 2004 13:02:35 -0800 To: aaa-wg@merit.edu From: Ignacio Goyret Subject: [AAA-WG]: Fwd: typos in draft-ietf-aaa-diameter-nasreq-14.txt Cc: Bernard Aboba , pcalhoun@airespace.com, gwz@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-wg@merit.edu Precedence: bulk [Sorry for the direct email but I'm not sure if the message will make it to the list -- with additional corrections] Description of issue Typos in the table under section 7, Tunneling, page 46. Submitter name: Ignacio Goyret Submitter email address: igoyret@lucent.com Date first submitted: 3/16/04 Reference: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-14.txt Document: nasreq Comment type: E Priority: S Section: 7 Rationale/Explanation of issue: The table in section 7, page 46, contains a couple of typos that conflict with the text in section 7.10 and 7.11. Requested change: The table reads: vvvvvvvvvv Tunnel-Client- 90 7.10 Unsigned32 | M | P | | V | Y | Auth-Id | | | | | | Tunnel-Server- 91 7.11 OctetString| M | P | | V | Y | Auth-Id | | | | | | ^^^^^^^^^^^ It should read: vvvvvvvvvv Tunnel-Client- 90 7.10 UTF8String | M | P | | V | Y | Auth-Id | | | | | | Tunnel-Server- 91 7.11 UTF8String | M | P | | V | Y | Auth-Id | | | | | | ^^^^^^^^^^^ From owner-aaa-wg@merit.edu Tue Mar 16 16:16: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 QAA25067 for ; Tue, 16 Mar 2004 16:16:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DCD54912BF; Tue, 16 Mar 2004 16:16:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90AB6912C0; Tue, 16 Mar 2004 16:16:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 72E63912BF for ; Tue, 16 Mar 2004 16:16:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2B5995DDAA; Tue, 16 Mar 2004 16:16:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 8854C5DDA0 for ; Tue, 16 Mar 2004 16:16:30 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i2GLPe915264 for ; Tue, 16 Mar 2004 13:25:40 -0800 Date: Tue, 16 Mar 2004 13:25:39 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 462: typo in draft-ietf-aaa-diameter-nasreq-14.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 462: Typo in the table under section 7, Tunneling, page 46. Submitter name: Ignacio Goyret Submitter email address: igoyret@lucent.com Date first submitted: 3/16/04 Reference: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-14.txt Document: nasreq Comment type: E Priority: S Section: 7 Rationale/Explanation of issue: The table in section 7, page 46, contains a typo that conflicts with the text in section 7.10. Requested change: The table reads: Tunnel-Client- 90 7.10 Unsigned32 | M | P | | V | Y | Auth-Id | | | | | | ^^^^^^^^^^^ It should read: Tunnel-Client- 90 7.10 OctetString| M | P | | V | Y | Auth-Id | | | | | | ^^^^^^^^^^^ From owner-aaa-wg@merit.edu Wed Mar 17 14:27: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 OAA01097 for ; Wed, 17 Mar 2004 14:27:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5AD9B9131D; Wed, 17 Mar 2004 14:25:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8C2BB9131F; Wed, 17 Mar 2004 14:25:10 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BEB619131D for ; Wed, 17 Mar 2004 14:25:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id AC4D65DE4A; Wed, 17 Mar 2004 14:25:03 -0500 (EST) 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 175635DE42 for ; Wed, 17 Mar 2004 14:24:58 -0500 (EST) Received: (cpmta 19542 invoked from network); 17 Mar 2004 11:24:57 -0800 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.72) with SMTP; 17 Mar 2004 11:24:57 -0800 X-Sent: 17 Mar 2004 19:24:57 GMT Message-Id: <5.2.1.1.2.20040317140811.03ad2940@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 17 Mar 2004 14:24:14 -0500 To: aaa-wg@merit.edu From: David Mitton Subject: [AAA-WG]: RE: Issue 462: typo in draft-ietf-aaa-diameter-nasreq-14.txt In-Reply-To: <200403162102.NAA14219@grigri.eng.ascend.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk On 3/16/2004 01:02 PM -0800, Ignacio Goyret wrote: >Description of issue > Typos in the table under section 7, Tunneling, page 46. > >Submitter name: Ignacio Goyret >Submitter email address: igoyret@lucent.com >Date first submitted: 3/16/04 >Reference: >http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-14.txt >Document: nasreq >Comment type: E >Priority: S >Section: 7 >Rationale/Explanation of issue: > >The table in section 7, page 46, contains a couple of typos that conflict with >the text in section 7.10 and 7.11. > >Requested change: > >The table reads: > vvvvvvvvvv >Tunnel-Client- 90 7.10 Unsigned32 | M | P | | V | Y | > Auth-Id | | | | | | >Tunnel-Server- 91 7.11 OctetString| M | P | | V | Y | > Auth-Id | | | | | | > ^^^^^^^^^^^ > >It should read: > > vvvvvvvvvv >Tunnel-Client- 90 7.10 UTF8String | M | P | | V | Y | > Auth-Id | | | | | | >Tunnel-Server- 91 7.11 UTF8String | M | P | | V | Y | > Auth-Id | | | | | | > ^^^^^^^^^^^ > ---- >Date: Tue, 16 Mar 2004 13:25:39 -0800 (PST) >From: Bernard Aboba >To: aaa-wg@merit.edu >Subject: [AAA-WG]: Issue 462: typo in draft-ietf-aaa-diameter-nasreq-14.txt > >Issue 462: Typo in the table under section 7, Tunneling, page 46. >Submitter name: Ignacio Goyret >Submitter email address: igoyret@lucent.com >Date first submitted: 3/16/04 >Reference: >http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-14.txt >Document: nasreq >Comment type: E >Priority: S >Section: 7 >Rationale/Explanation of issue: > >The table in section 7, page 46, contains a typo that conflicts with the >text in section 7.10. > >Requested change: > >The table reads: > >Tunnel-Client- 90 7.10 Unsigned32 | M | P | | V | Y | > Auth-Id | | | | | | > ^^^^^^^^^^^ > >It should read: > >Tunnel-Client- 90 7.10 OctetString| M | P | | V | Y | > Auth-Id | | | | | | > ^^^^^^^^^^^ Interesting... Clearly an incorrect transcription. In RFC 2868 where these attributes come from they are defined as RADIUS "String" types. In general RADIUS String attributes are mapped to Diameter OctetString AVPs. And RADIUS "Text" attributes are mapped to Diameter UTF8Strings AVPs. But the text Description of these attributes says that they "SHOULD be represented in the UTF-8 charset", so my tendancy would be to give that representation priority. The distinction betweeen "Text" and "String" attribute data types was not present in the original RADIUS RFC 2038. It was introduced in RFC 2865, and RFC 2868 shares the same publication date as 2865. This change may have been missed. Reviewing other attributes in this section, I see some more inconsistencies. (Some in the text, some in the table) Unless a RADIUS String attribute Description indicates a UTF8 or Text representation, it should be considered an OctetString. Dave. From owner-aaa-wg@merit.edu Wed Mar 17 14:48: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 OAA02300 for ; Wed, 17 Mar 2004 14:48:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F27E6912F5; Wed, 17 Mar 2004 14:48:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3B5B912F6; Wed, 17 Mar 2004 14:48:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C9C2912F5 for ; Wed, 17 Mar 2004 14:48:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 618AA5DDDC; Wed, 17 Mar 2004 14:48:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from web1.merit.edu (web1.merit.edu [198.108.62.192]) by segue.merit.edu (Postfix) with ESMTP id 090F95DE14; Wed, 17 Mar 2004 14:48:41 -0500 (EST) Received: (from web@localhost) by web1.merit.edu (8.9.3/8.9.1) id OAA18729; Wed, 17 Mar 2004 14:48:40 -0500 (EST) Date: Wed, 17 Mar 2004 14:48:40 -0500 From: William Bulley To: David Mitton Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: RE: Issue 462: typo in draft-ietf-aaa-diameter-nasreq-14.txt Message-ID: <20040317144840.G15696@web1.merit.edu> Mail-Followup-To: David Mitton , aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us Sender: owner-aaa-wg@merit.edu Precedence: bulk According to David Mitton : > > Interesting... > Clearly an incorrect transcription. > > The distinction betweeen "Text" and "String" attribute data types was not > present in the original RADIUS RFC 2038. It was introduced in RFC 2865, > and RFC 2868 shares the same publication date as 2865. This change may > have been missed. Uhhh, the original RADIUS RFC was RFC 2058 which was replaced by RFC 2138. :-) Regards, web... -- William Bulley Email: web@merit.edu Merit Network Inc. Ann Arbor, Michigan From owner-aaa-wg@merit.edu Wed Mar 17 15:22: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 PAA04731 for ; Wed, 17 Mar 2004 15:22:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ED1C89136D; Wed, 17 Mar 2004 15:21:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7B0191384; Wed, 17 Mar 2004 15:21:27 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5770D9136D for ; Wed, 17 Mar 2004 15:21:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id BE2165DDDC; Wed, 17 Mar 2004 15:21:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h007.c000.snv.cp.net [209.228.32.71]) by segue.merit.edu (Postfix) with SMTP id 342A05DE3F for ; Wed, 17 Mar 2004 15:21:21 -0500 (EST) Received: (cpmta 11780 invoked from network); 17 Mar 2004 12:21:20 -0800 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.71) with SMTP; 17 Mar 2004 12:21:20 -0800 X-Sent: 17 Mar 2004 20:21:20 GMT Message-Id: <5.2.1.1.2.20040317150622.041b5310@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 17 Mar 2004 15:10:05 -0500 To: aaa-wg@merit.edu From: David Mitton Subject: Re: [AAA-WG]: RE: Issue 462: typo in draft-ietf-aaa-diameter-nasreq-14.txt In-Reply-To: <20040317144840.G15696@web1.merit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk On 3/17/2004 02:48 PM -0500, William Bulley wrote: >According to David Mitton : > > > > Interesting... > > Clearly an incorrect transcription. > > > > The distinction betweeen "Text" and "String" attribute data types was not > > present in the original RADIUS RFC 2038. It was introduced in RFC 2865, > > and RFC 2868 shares the same publication date as 2865. This change may > > have been missed. > >Uhhh, the original RADIUS RFC was RFC 2058 which was replaced by RFC >2138. :-) The man is correct. I typoed the 5 as a 3, (after having fetched a copy to check) RFC 2138 (April 1997) also does not have the "Text" attribute data type. Dave. >Regards, > >web... > >-- >William Bulley Email: web@merit.edu >Merit Network Inc. Ann Arbor, Michigan From owner-aaa-wg@merit.edu Wed Mar 17 21:41:15 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 VAA26332 for ; Wed, 17 Mar 2004 21:41:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CA79891334; Wed, 17 Mar 2004 21:40:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D14591335; Wed, 17 Mar 2004 21:40:57 -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 94C8C91334 for ; Wed, 17 Mar 2004 21:40:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7D2195DE81; Wed, 17 Mar 2004 21:40:55 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from NGM-NG0128.net (unknown [203.236.3.225]) by segue.merit.edu (Postfix) with SMTP id 71FB75DE6F for ; Wed, 17 Mar 2004 21:40:54 -0500 (EST) Date: Thu, 18 Mar 2004 11:40:49 +0900 To: aaa-wg@merit.edu Subject: [AAA-WG]: Re: Hello From: david@mitton.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 Fri Mar 19 06:54: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 GAA28099 for ; Fri, 19 Mar 2004 06:54:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E524B91397; Fri, 19 Mar 2004 06:54:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABEF59139B; Fri, 19 Mar 2004 06:54:34 -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 7A1D691397 for ; Fri, 19 Mar 2004 06:54:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 56B5E5DE9A; Fri, 19 Mar 2004 06:54:33 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from eins.siemens.at (unknown [193.81.246.11]) by segue.merit.edu (Postfix) with ESMTP id 8BDFE5DE8B for ; Fri, 19 Mar 2004 06:54:32 -0500 (EST) Received: from vies1k7x.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i2JBsViL031093 for ; Fri, 19 Mar 2004 12:54:31 +0100 Received: from zagh102a.zag.siemens.hr (vies1kbx.sie.siemens.at [158.226.135.174]) by vies1k7x.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i2JBsUwh019282 for ; Fri, 19 Mar 2004 12:54:31 +0100 Received: by zagh102a.zag.siemens.hr with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Mar 2004 12:45:58 +0100 Message-ID: From: Peko Jasna To: aaa-wg@merit.edu Subject: [AAA-WG]: small typo in Date: Fri, 19 Mar 2004 12:45:53 +0100 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! It seems that a small typo in exists. In chapter 13.1 reference [IPsec] should probably be replaced with [SECARCH]. Bye, Jasna From owner-aaa-wg@merit.edu Fri Mar 19 07:08: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 HAA28474 for ; Fri, 19 Mar 2004 07:08:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BE0A89139B; Fri, 19 Mar 2004 07:07:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 930A89139C; Fri, 19 Mar 2004 07:07:53 -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 83BBD9139B for ; Fri, 19 Mar 2004 07:07:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6D7635DE9A; Fri, 19 Mar 2004 07:07:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 03A8B5DE7F for ; Fri, 19 Mar 2004 07:07:52 -0500 (EST) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id BDE3D898C4; Fri, 19 Mar 2004 14:07:34 +0200 (EET) Message-ID: <405AE1F1.4020605@kolumbus.fi> Date: Fri, 19 Mar 2004 14:05:05 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peko Jasna Cc: aaa-wg@merit.edu, John Loughney Subject: Re: [AAA-WG]: small typo in 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 Peko Jasna wrote: > Hello! > > It seems that a small typo in exists. > In chapter 13.1 reference [IPsec] should probably be replaced with > [SECARCH]. That's right. John, this one is for the errata that you are maintaining... --Jari From owner-aaa-wg@merit.edu Fri Mar 19 09:07:50 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 JAA03901 for ; Fri, 19 Mar 2004 09:07:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 21F289139C; Fri, 19 Mar 2004 09:07:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E10029139E; Fri, 19 Mar 2004 09:07:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 18D5A9139C for ; Fri, 19 Mar 2004 09:06:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id EF2A15DD9A; Fri, 19 Mar 2004 09:06:48 -0500 (EST) 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 390285DDCF for ; Fri, 19 Mar 2004 09:06:48 -0500 (EST) Received: (cpmta 17430 invoked from network); 19 Mar 2004 06:06:47 -0800 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.83) with SMTP; 19 Mar 2004 06:06:47 -0800 X-Sent: 19 Mar 2004 14:06:47 GMT Message-Id: <5.2.1.1.2.20040319085622.02e21890@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 19 Mar 2004 09:02:27 -0500 To: Jari Arkko , Peko Jasna From: David Mitton Subject: Re: [AAA-WG]: small typo in Cc: aaa-wg@merit.edu, John Loughney In-Reply-To: <405AE1F1.4020605@kolumbus.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk On 3/19/2004 02:05 PM +0200, Jari Arkko wrote: >Peko Jasna wrote: >>Hello! >>It seems that a small typo in exists. >>In chapter 13.1 reference [IPsec] should probably be replaced with >>[SECARCH]. > >That's right. John, this one is for the errata that you are >maintaining... > >--Jari Right, but it's the errata on RFC 3588. Draft 17 is past history now. ;^) Dave. (and whatever you do, don't look at the running header in the RFC either!) From owner-aaa-wg@merit.edu Fri Mar 19 09:32: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 JAA04864 for ; Fri, 19 Mar 2004 09:32:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 28E4E9139E; Fri, 19 Mar 2004 09:32:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F00179139F; Fri, 19 Mar 2004 09:32:12 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E8CFC9139E for ; Fri, 19 Mar 2004 09:32:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id D2A505DDC7; Fri, 19 Mar 2004 09:32:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by segue.merit.edu (Postfix) with ESMTP id 8F3EC5DE15 for ; Fri, 19 Mar 2004 09:32:11 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2JEW6i06682 for ; Fri, 19 Mar 2004 08:32:07 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1699XLJB>; Fri, 19 Mar 2004 15:32:05 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503DB0C32@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: David Mitton , Jari Arkko , Peko Jasna Cc: aaa-wg@merit.edu, John Loughney Subject: RE: [AAA-WG]: small typo in Date: Fri, 19 Mar 2004 15:32:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > On 3/19/2004 02:05 PM +0200, Jari Arkko wrote: > >Peko Jasna wrote: > >>Hello! > >>It seems that a small typo in exists. > >>In chapter 13.1 reference [IPsec] should probably be replaced with > >>[SECARCH]. > > > >That's right. John, this one is for the errata that you are > >maintaining... > > > >--Jari > > Right, but it's the errata on RFC 3588. Draft 17 is past history now. > ;^) > And you can ask the RFC-Editor to post these errata to their errata web page. Bert > Dave. > (and whatever you do, don't look at the running header in the > RFC either!) > > > From owner-aaa-wg@merit.edu Fri Mar 19 09:53: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 JAA05805 for ; Fri, 19 Mar 2004 09:53:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BB8EF9139F; Fri, 19 Mar 2004 09:53:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88787913A0; Fri, 19 Mar 2004 09:53:21 -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 5AAE19139F for ; Fri, 19 Mar 2004 09:53:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4209E5DE2E; Fri, 19 Mar 2004 09:53:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from hrtades9.atea.be (viap100.atea.be [194.78.143.100]) by segue.merit.edu (Postfix) with ESMTP id 778CD5DE27 for ; Fri, 19 Mar 2004 09:53:19 -0500 (EST) Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GZCF4Y8M; Fri, 19 Mar 2004 15:53:17 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Mar 2004 15:53:17 +0100 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195692080@hrtades7.atea.be> From: Goeman Stefan To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: small typo in Date: Fri, 19 Mar 2004 15:53:09 +0100 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 Hello, Did anybody also consider the mail I sent on the 2nd of March, where I believe there is an error in Figure 6 in section 6.1.8? Greetings, Stefan. > -----Original Message----- > From: Peko Jasna [mailto:jasna.peko@siemens.com] > Sent: vrijdag 19 maart 2004 12:46 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: small typo in > > > Hello! > > It seems that a small typo in > exists. > In chapter 13.1 reference [IPsec] should probably be replaced with > [SECARCH]. > > Bye, > Jasna > From owner-aaa-wg@merit.edu Fri Mar 19 10:35: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 KAA08473 for ; Fri, 19 Mar 2004 10:35:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B6BF5913A1; Fri, 19 Mar 2004 10:35:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85A80913A4; Fri, 19 Mar 2004 10:35:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 55DE8913A1 for ; Fri, 19 Mar 2004 10:35:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3FFF35DEB2; Fri, 19 Mar 2004 10:35:32 -0500 (EST) 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 375E85DEAF for ; Fri, 19 Mar 2004 10:35:31 -0500 (EST) 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 i2JFZSp19643; Fri, 19 Mar 2004 17:35:28 +0200 (EET) X-Scanned: Fri, 19 Mar 2004 17:34:29 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i2JFYTpW032365; Fri, 19 Mar 2004 17:34:29 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00ck0BdB; Fri, 19 Mar 2004 17:34:28 EET 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 i2JFYSF18659; Fri, 19 Mar 2004 17:34:28 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 19 Mar 2004 17:34:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: small typo in Date: Fri, 19 Mar 2004 17:34:27 +0200 Message-ID: Thread-Topic: [AAA-WG]: small typo in Thread-Index: AcQNwjKWZuKxd8VNRnSmX/RMOoz+8AABW/fg From: To: , X-OriginalArrivalTime: 19 Mar 2004 15:34:28.0237 (UTC) FILETIME=[AA7083D0:01C40DC7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Could you resend it, I don't remember seeing it. John > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Goeman Stefan > Sent: 19 March, 2004 16:53 > To: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: small typo in =20 >=20 >=20 >=20 > Hello, >=20 > Did anybody also consider the mail I sent on the 2nd of March, where I > believe there is an error in Figure 6 in section 6.1.8? >=20 > Greetings, > Stefan. >=20 > > -----Original Message----- > > From: Peko Jasna [mailto:jasna.peko@siemens.com]=20 > > Sent: vrijdag 19 maart 2004 12:46 > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: small typo in =20 > >=20 > >=20 > > Hello! > >=20 > > It seems that a small typo in=20 > > exists. > > In chapter 13.1 reference [IPsec] should probably be replaced with > > [SECARCH]. > >=20 > > Bye, > > Jasna > >=20 >=20 From owner-aaa-wg@merit.edu Fri Mar 19 10:40: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 KAA08645 for ; Fri, 19 Mar 2004 10:40:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 78AD8913A4; Fri, 19 Mar 2004 10:40:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 478FC913A5; Fri, 19 Mar 2004 10:40:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E767A913A4 for ; Fri, 19 Mar 2004 10:40:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id CCC605DEEB; Fri, 19 Mar 2004 10:40:14 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from hrtades9.atea.be (viap100.atea.be [194.78.143.100]) by segue.merit.edu (Postfix) with ESMTP id 0C4A25DECA for ; Fri, 19 Mar 2004 10:40:13 -0500 (EST) Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GZCF4ZJW; Fri, 19 Mar 2004 16:40:11 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Mar 2004 16:40:11 +0100 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195692081@hrtades7.atea.be> From: Goeman Stefan To: "'john.loughney@nokia.com'" Cc: aaa-wg@merit.edu Subject: FW: [AAA-WG]: An error in RFC 3588 Date: Fri, 19 Mar 2004 16:40:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40DC8.75013450" 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_01C40DC8.75013450 Content-Type: text/plain This was the original message I sent the 2nd of March. Greetings, Stefan. -----Original Message----- From: Goeman Stefan [mailto:Stefan.Goeman@siemens.com] Sent: dinsdag 2 maart 2004 16:03 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: An error in RFC 3588 Hello All, I believe there is an error in the Diameter Base Protocol RFC. I refer to Figure 6 in section 6.1.8 Relaying and Proxying Requests. First of all, there is a small typo with the mno.net and example.net things, but this is not the real problem I have. The text in section 6.1.8 says that "A relay of proxy agent MUST append a Route-Record AVP to all requests forwarded. The AVP contains the identity of the peer the request was received from." This is reflected in Figure 6. In Figure 6, (Origin-Host=nas.mno.net) and (Route-Record=nas.mno.net) (Remember my first remark on the typo). However, when I read the text in section 6.7.1 Route-Record AVP, I read "The Route-Record AVP is of type DiameterIdentity. The identity added in this AVP MUST be the same as the one received in the Origin-Host of the Capabilities Exchange message". Applying this to Figure 6, I assume that the CE message are between DRL and HMS. In these messages Origin-Host would be the identity of DRL. So, I think that in Figure 6 it should be (Origin-Host=nas.mno.net) and (Route-Record=drl.mno.net). Greetings, Stefan. Stefan Goeman SIEMENS ICM/ICN Stefan.Goeman@siemens.com Mobile Solutions and Enabling Services http://www.ic.siemens.be Customer driven solution providers ------_=_NextPart_001_01C40DC8.75013450 Content-Type: text/html Message
    This was the original message I sent the 2nd of March.
     
    Greetings,
    Stefan.
     
    -----Original Message-----
    From: Goeman Stefan [mailto:Stefan.Goeman@siemens.com]
    Sent: dinsdag 2 maart 2004 16:03
    To: 'aaa-wg@merit.edu'
    Subject: [AAA-WG]: An error in RFC 3588

    Hello All,

    I believe there is an error in the Diameter Base Protocol RFC. I refer to Figure 6 in section 6.1.8 Relaying and Proxying Requests.

    First of all, there is a small typo with the mno.net and example.net things, but this is not the real problem I have.

    The text in section 6.1.8 says that "A relay of proxy agent MUST append a Route-Record AVP to all requests forwarded. The AVP contains the identity of the peer the request was received from." This is reflected in Figure 6. In Figure 6, (Origin-Host=nas.mno.net) and (Route-Record=nas.mno.net) (Remember my first remark on the typo).

    However, when I read the text in section 6.7.1 Route-Record AVP, I read "The Route-Record AVP is of type DiameterIdentity. The identity added in this AVP MUST be the same as the one received in the Origin-Host of the Capabilities Exchange message". Applying this to Figure 6, I assume that the CE message are between DRL and HMS. In these messages Origin-Host would be the identity of DRL. So, I think that in Figure 6 it should be (Origin-Host=nas.mno.net) and (Route-Record=drl.mno.net).


    Greetings,
    Stefan.

    Stefan Goeman
    SIEMENS ICM/ICN
    Stefan.Goeman@siemens.com
           
    Mobile Solutions 
    and Enabling Services
    http://www.ic.siemens.be               
    Customer driven solution providers     

    ------_=_NextPart_001_01C40DC8.75013450-- From owner-aaa-wg@merit.edu Fri Mar 19 19:23:42 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 TAA03406 for ; Fri, 19 Mar 2004 19:23:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E862E913B8; Fri, 19 Mar 2004 19:23:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9540913B9; Fri, 19 Mar 2004 19:23:30 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8D92D913B8 for ; Fri, 19 Mar 2004 19:23:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 766205DEFE; Fri, 19 Mar 2004 19:23:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by segue.merit.edu (Postfix) with ESMTP id 3BC1F5DEF8 for ; Fri, 19 Mar 2004 19:23:29 -0500 (EST) Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6745950 for aaa-wg@merit.edu; Fri, 19 Mar 2004 19:13:28 -0500 Message-Id: <5.1.0.14.0.20040319185325.021a6618@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 19 Mar 2004 19:03:48 -0500 To: aaa-wg@merit.edu From: "Joel M. Halpern" Subject: [AAA-WG]: Additional values for Framed-protocol? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk In reading through NASREQ, a minor concern occurred to me. It may be more trouble than it is worth to fix, and it may be better fixed elsewhere, so I would like your opinion. The list of framed protocols provides a specific list of encapsulations. This list can be (and has been) extended. However, there seems to be one common case in use that can use unmodified Diameter Base and NASREQ, if its encapsulation were supported. This is simple IP. That is old fashioned wireless, hotel DSL, subscription based rental internet carells, and other similar access technologies which do not use an encapsulation between the IP packet and the defined media layer. Should this be added by this document? Should someone write a short document just to add that value? Should the issue be ignored? Note that this is not a technology specific value, as the "encapsulation" ("null" if you will) is used by multiple technologies. Thank you, Joel M. Halpern From owner-aaa-wg@merit.edu Fri Mar 19 20:20: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 UAA04474 for ; Fri, 19 Mar 2004 20:20:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 394F1913B9; Fri, 19 Mar 2004 20:20:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 036F6913BC; Fri, 19 Mar 2004 20:20:05 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AE1A2913B9 for ; Fri, 19 Mar 2004 20:20:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D2F95DEB2; Fri, 19 Mar 2004 20:20:04 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from cms5.etri.re.kr (cms5.etri.re.kr [129.254.16.15]) by segue.merit.edu (Postfix) with ESMTP id 3A1175DE3E; Fri, 19 Mar 2004 20:20:03 -0500 (EST) Received: by cms5 with Internet Mail Service (5.5.2657.72) id ; Sat, 20 Mar 2004 10:26:54 +0900 Message-ID: From: anny5@etri.re.kr To: bwijnen@lucent.com, owner-aaa-wg@merit.edu, david@mitton.com, jari.arkko@kolumbus.fi, jasna.peko@siemens.com Cc: aaa-wg@merit.edu, john.loughney@nokia.com Subject: [AAA-WG]: =?euc-kr?B?W8D8w7zIuL3FXSBbQUFBLVdHXTogc21hbGwgdHlwbyBpbiA8ZHJh?= =?euc-kr?B?ZnQtaWV0Zi1hYWEtZGlhbWV0ZXItMTcudHh0Pg==?= Date: Sat, 20 Mar 2004 10:26:53 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-RCPTTO: anny5@etri.re.kr,belecs@etri.re.kr,bglee@etri.re.kr,cbh@etri.re.kr,cby75720@etri.re.kr,dhchoi@etri.re.kr,haenamu@etri.re.kr,hyungon@etri.re.kr,ilwoo@etri.re.kr,jhna@etri.re.kr,jjj75747@etri.re.kr,junny@etri.re.kr,ktj75639@etri.re.kr,lmy75719@etri.re.kr,lobbi@etri.re.kr,mariekim@etri.re.kr,myyun@etri.re.kr,shykim@etri.re.kr, X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Where is errata web page? Can I see the errata web page? =BF=F8=BA=BB =B3=BB=BF=EB: =BA=B8=B3=BD=BB=E7=B6=F7: owner-aaa-wg@merit.edu[bwijnen@lucent.com] =B9=DE=B4=C2=BB=E7=B6=F7: David Mitton; Jari Arkko; Peko Jasna =C2=FC=C1=B6:aaa-wg@merit.edu; John Loughney =C1=A6=B8=F1: RE: [AAA-WG]: small typo in =B9=DE=C0=BA=B3=AF=C2=A5: 2004/03/19 =B1=DD 23:32 > On 3/19/2004 02:05 PM +0200, Jari Arkko wrote:=20 > >Peko Jasna wrote:=20 > >>Hello!=20 > >>It seems that a small typo in = exists.=20 > >>In chapter 13.1 reference [IPsec] should probably be replaced with=20 > >>[SECARCH].=20 > >=20 > >That's right. John, this one is for the errata that you are=20 > >maintaining...=20 > >=20 > >--Jari=20 >=20 > Right, but it's the errata on RFC 3588. Draft 17 is past history = now.=20 > ;^)=20 >=20 And you can ask the RFC-Editor to post these errata to their errata web page. Bert=20 > Dave.=20 > (and whatever you do, don't look at the running header in the=20 > RFC either!)=20 >=20 >=20 >=20 From owner-aaa-wg@merit.edu Sat Mar 20 02:07:42 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 CAA23202 for ; Sat, 20 Mar 2004 02:07:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3CA1F91201; Sat, 20 Mar 2004 02:06:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 005EA91205; Sat, 20 Mar 2004 02:06:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 259CC91201 for ; Sat, 20 Mar 2004 02:06:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id F29715DECD; Sat, 20 Mar 2004 02:06:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id D31445DE82; Sat, 20 Mar 2004 02:06:51 -0500 (EST) 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 i2K76VA26284; Sat, 20 Mar 2004 09:06:31 +0200 (EET) X-Scanned: Sat, 20 Mar 2004 09:05:08 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i2K758tk015830; Sat, 20 Mar 2004 09:05:08 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00xo7WkI; Sat, 20 Mar 2004 09:05:03 EET 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 i2K74wF02172; Sat, 20 Mar 2004 09:04:58 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 20 Mar 2004 09:04:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Subject: RE: [????] [AAA-WG]: small typo in Date: Sat, 20 Mar 2004 09:04:57 +0200 Message-ID: Thread-Topic: [????] [AAA-WG]: small typo in Thread-Index: AcQOGZoHnJlW71W4SkKfv8onxegY/AAL9Q0A From: To: , , , , , Cc: X-OriginalArrivalTime: 20 Mar 2004 07:04:57.0826 (UTC) FILETIME=[A777BC20:01C40E49] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, The Eratta page for all RFCs can be found here: http://www.rfc-editor.org/errata.html Right now, there is nothing listed for Diameter, but I have a job to = submit some things next week. I will cc: the AAA mailing list when I do this. thanks, John > -----Original Message----- > From: ext anny5@etri.re.kr [mailto:anny5@etri.re.kr] > Sent: 20 March, 2004 03:27 > To: bwijnen@lucent.com; owner-aaa-wg@merit.edu;=20 > david@mitton.com; jari.arkko@kolumbus.fi; jasna.peko@siemens.com > Cc: aaa-wg@merit.edu; Loughney John (Nokia-NRC/Helsinki) > Subject: [????] [AAA-WG]: small typo in=20 > >=20 >=20 >=20 > Where is errata web page? >=20 > Can I see the errata web page? >=20 > =BF=F8=BA=BB =B3=BB=BF=EB: >=20 > =BA=B8=B3=BD=BB=E7=B6=F7: owner-aaa-wg@merit.edu[bwijnen@lucent.com] > =B9=DE=B4=C2=BB=E7=B6=F7: David Mitton; Jari Arkko; Peko Jasna > =C2=FC=C1=B6:aaa-wg@merit.edu; John Loughney > =C1=A6=B8=F1: RE: [AAA-WG]: small typo in >=20 > =B9=DE=C0=BA=B3=AF=C2=A5: 2004/03/19 =B1=DD 23:32 >=20 >=20 >=20 > > On 3/19/2004 02:05 PM +0200, Jari Arkko wrote:=20 > > >Peko Jasna wrote:=20 > > >>Hello!=20 > > >>It seems that a small typo in=20 > exists.=20 > > >>In chapter 13.1 reference [IPsec] should probably be=20 > replaced with=20 > > >>[SECARCH].=20 > > >=20 > > >That's right. John, this one is for the errata that you are=20 > > >maintaining...=20 > > >=20 > > >--Jari=20 > >=20 > > Right, but it's the errata on RFC 3588. Draft 17 is past=20 > history now.=20 > > ;^)=20 > >=20 > And you can ask the RFC-Editor to post these errata to their=20 > errata web > page. > Bert=20 > > Dave.=20 > > (and whatever you do, don't look at the running header in the=20 > > RFC either!)=20 > >=20 > >=20 > >=20 >=20 From owner-aaa-wg@merit.edu Mon Mar 22 14:40: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 OAA14743 for ; Mon, 22 Mar 2004 14:40:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BCDFE91248; Mon, 22 Mar 2004 14:39:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90A6F91249; Mon, 22 Mar 2004 14:39:44 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8498F91248 for ; Mon, 22 Mar 2004 14:39:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 719105DE38; Mon, 22 Mar 2004 14:39:43 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ktmc.org (unknown [147.6.11.93]) by segue.merit.edu (Postfix) with SMTP id 3E43C5DE47 for ; Mon, 22 Mar 2004 14:39:42 -0500 (EST) Date: Tue, 23 Mar 2004 04:26:01 +0900 To: aaa-wg@merit.edu Subject: [AAA-WG]: Forum notify From: stephen.farrell@baltimore.ie 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 Administration@hispeedweb.com Wed Mar 24 03:18:19 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 DAA03866 for ; Wed, 24 Mar 2004 03:18:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B63ac-0006Pv-00 for aaa-archive@ietf.org; Wed, 24 Mar 2004 03:18:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B63Zi-0006AZ-00 for aaa-archive@ietf.org; Wed, 24 Mar 2004 03:17:22 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B63Yd-0005w6-00; Wed, 24 Mar 2004 03:16:15 -0500 Received: from 81-203-222-117.user.ono.com ([81.203.222.117]) by mx2.foretec.com with smtp (Exim 4.24) id 1B63KK-0005Ca-49; Wed, 24 Mar 2004 03:01:31 -0500 Received: from [237.58.60.39] by 81-203-222-117.user.ono.com id StWDd1d5jvNW; Wed, 24 Mar 2004 07:03:48 -0100 Message-ID: From: "Admin" To: aaa-archive@ietf.org Subject: ADV: Attention All School Staff, Teachers and Students: Date: Wed, 24 Mar 04 07:03:48 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="C28EB63DCF1E5" 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=10.7 required=5.0 tests=ADVERT_CODE, 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 * 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 This is a multi-part message in MIME format. --C28EB63DCF1E5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All School Staff, Teachers and Students: You Must Respond By 5 P.M. Thursday, March 25, 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 Staff Members, Teachers and Students who respond to this message before 5 P.M., Thursday, March 25, 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. Thursday, March 25, 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 Staff member, Teacher or Student: 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. Thursday, March 25, 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. Thursday, March 25, 2004 If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp --C28EB63DCF1E5-- From owner-aaa-wg@merit.edu Wed Mar 24 06:30: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 GAA14922 for ; Wed, 24 Mar 2004 06:30:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6407791252; Wed, 24 Mar 2004 06:30:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D92AA91263; Wed, 24 Mar 2004 06:30:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B996E91252 for ; Wed, 24 Mar 2004 06:30:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id A0CD95DF33; Wed, 24 Mar 2004 06:30:00 -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 A66FF5DF18 for ; Wed, 24 Mar 2004 06:29:59 -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 i2OBTw414578 for ; Wed, 24 Mar 2004 13:29:58 +0200 (EET) X-Scanned: Wed, 24 Mar 2004 13:27:22 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2OBRMAG001690 for ; Wed, 24 Mar 2004 13:27:22 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00mj4XwC; Wed, 24 Mar 2004 13:27:21 EET 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 i2OBREs03800 for ; Wed, 24 Mar 2004 13:27:14 +0200 (EET) Received: from nokia.com ([172.21.40.155]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 24 Mar 2004 13:27:08 +0200 Message-ID: <4061708C.10907@nokia.com> Date: Wed, 24 Mar 2004 13:27:08 +0200 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: AAA mailing list Subject: [AAA-WG]: AAA URI draft published Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2004 11:27:08.0720 (UTC) FILETIME=[F176AB00:01C41192] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi: 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 From owner-aaa-wg@merit.edu Wed Mar 24 11:44: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 LAA05583 for ; Wed, 24 Mar 2004 11:44:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D5E28912AE; Wed, 24 Mar 2004 11:42:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A52A5912AD; Wed, 24 Mar 2004 11:42:53 -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 906949128F for ; Wed, 24 Mar 2004 11:42:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 713CE5DF6A; Wed, 24 Mar 2004 11:42:50 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id E0ECE5DF64 for ; Wed, 24 Mar 2004 11:42:49 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i2OGpFo27782 for ; Wed, 24 Mar 2004 08:51:15 -0800 Date: Wed, 24 Mar 2004 08:51:15 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: REMINDER: IETF last call on draft-walker-ieee802-req-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a reminder that IETF last call on draft-walker-ieee802-req-00.txt will complete on March 28, 2004. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-walker-ieee802-req-00.txt The IETF Last Call notice is available here: http://www1.ietf.org/mail-archive/ietf-announce/Current/msg29002.html Please send comments relating to this document to the EAP WG mailing list (eap@frascone.com) in the format specified in the EAP issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html From owner-aaa-wg@merit.edu Thu Mar 25 09:02: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 JAA21194 for ; Thu, 25 Mar 2004 09:02:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0318691206; Thu, 25 Mar 2004 09:01:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C30EB91207; Thu, 25 Mar 2004 09:01:48 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AB48791206 for ; Thu, 25 Mar 2004 09:01:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8AF5A5DF77; Thu, 25 Mar 2004 09:01:44 -0500 (EST) 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 A5F105DF67 for ; Thu, 25 Mar 2004 09:01:43 -0500 (EST) 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 i2PE1cI05718; Thu, 25 Mar 2004 16:01:38 +0200 (EET) X-Scanned: Thu, 25 Mar 2004 15:56:45 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i2PDujjB026837; Thu, 25 Mar 2004 15:56:45 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 007aqMkm; Thu, 25 Mar 2004 15:56:19 EET 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 i2PDXJs02229; Thu, 25 Mar 2004 15:33:20 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Mar 2004 15:32:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Proposed resolution of EAP issue 455: User-name handling Date: Thu, 25 Mar 2004 15:32:49 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C39F5@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue EAP : User-name Handling Thread-Index: AcQBa23TBtvtQ4YNRBiU37Lkl7WbpgRAgb4A From: To: , X-OriginalArrivalTime: 25 Mar 2004 13:32:52.0134 (UTC) FILETIME=[AC1A0C60:01C4126D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Does this look ok? Replace in Section 2.8.1 "Therefore, the Diameter Server SHOULD return the user's identity by inserting it in the User-Name AVP of subsequent Diameter-EAP-Answer packets. Without the user's identity, the Session-Id AVP MAY be used for accounting and billing, however operationally this could be very difficult to manage." by "Therefore, the Diameter Server SHOULD return the user's identity by inserting a User-Name AVP to Diameter-EAP-Answer messages that have a Result-Code of DIAMETER_SUCCESS. A separate billing identifier or pseudonym MAY be used for privacy reasons (see Section 8.5). If the user's identity is not available to the NAS, the Session-Id AVP MAY be used for accounting and billing; however operationally this could be very difficult to manage." BR, Pasi > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Joseph Salowey > Sent: Thursday, March 04, 2004 12:00 AM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue EAP : User-name Handling >=20 >=20 >=20 > Submitter name: Joe Salowey=20 > Submitter email address: jsalowey@cisco.com=20 > Date first submitted: 3/3/2004=20 > Reference:=20 > Document: eap=20 > Comment type: 'E'ditorial > Priority: '1' Should fix=20 > Section: 2.8.1 > Rationale/Explanation of issue:=20 >=20 > The draft says "...the Diameter server SHOULD return the=20 > user's identity > by inserting it in the User-Name AVP of susequent Diameter-EAP-Answer > packets." It is not clear which user identity this is=20 > referring to. If > it is referring to the user's real identity this is only=20 > available once > the EAP method completes. It probably should state: >=20 > "...the Diameter Server SHOULD return the real user's identity by > inserting it in the User-Name AVP of Diameter-EAP-Answer packets that > contain a Result-Code of DIAMETER-SUCCESS." > =20 > It might also be good to discuss that the real user-name MAY=20 > be omitted > or replaced with a different billing identifier if identity privacy is > required in the DIAMETER channel. >=20 >=20 >=20 From owner-aaa-wg@merit.edu Thu Mar 25 09:18: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 JAA23056 for ; Thu, 25 Mar 2004 09:18:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 41401912A8; Thu, 25 Mar 2004 09:15:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08941912AA; Thu, 25 Mar 2004 09:15:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4DF9D912A8 for ; Thu, 25 Mar 2004 09:15:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7BC5B5DE93; Thu, 25 Mar 2004 09:15:46 -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 2B53F5DE4F for ; Thu, 25 Mar 2004 09:15:45 -0500 (EST) 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 i2PEFa426679; Thu, 25 Mar 2004 16:15:36 +0200 (EET) X-Scanned: Thu, 25 Mar 2004 16:13:27 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i2PEDR33008921; Thu, 25 Mar 2004 16:13:27 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00vOwVim; Thu, 25 Mar 2004 16:13:25 EET 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 i2PEBTs04011; Thu, 25 Mar 2004 16:11:29 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Mar 2004 16:10:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Proposed resolution of EAP issue 461: Alternate Uses and Conflicting AVPs Date: Thu, 25 Mar 2004 16:10:19 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C39F7@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue eap: Alternate uses and conflicting AVPs Thread-Index: AcQBi2SR8Sp+5fpSQiGu31L/3qVJ4gQ50jhg From: To: , X-OriginalArrivalTime: 25 Mar 2004 14:10:23.0774 (UTC) FILETIME=[EA2F0BE0:01C41272] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi! I think the key name part of this issue is already=20 covered by issue #460. Would this change be ok? Change Section 2.8.2 from "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. Also, the Result-Code SHOULD match the contained EAP packet (successful Result-Code if EAP-Success, and a failure Result-Code for EAP-Failure). TO BE WRITTEN: clarify this." To "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. Also, the Result-Code SHOULD match the contained EAP packet: a successful Result-Code for EAP-Success, and a failure Result-Code for EAP-Failure. 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). The responsibility for avoiding conflicts lies with the EAP server. The NAS or proxy agents MUST NOT "manufacture" or modify EAP packets in order to correct contradictory messages they receive." Best regards, Pasi > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Joseph Salowey > Sent: Thursday, March 04, 2004 3:52 AM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue eap: Alternate uses and conflicting AVPs >=20 >=20 >=20 > Submitter name: Joe Salowey=20 > Submitter email address: jsalowey@cisco.com=20 > Date first submitted: 3/3/2004=20 > Reference:=20 > Document: eap=20 > Comment type: E > Priority: '1' Should fix=20 > Section: 2.8.2 and 2.8.5 > Rationale/Explanation of issue:=20 >=20 > Since EAP keying has the concept of the key name this should=20 > probably be > returned along with the Master Key.=20 >=20 > It might be goos to provide some motivation behind the 2.8.2 > recommendation. I think the basic reason is that often lower layer > protocols do not distingush between authentication and authorization. > In these protocols the EAP-Success translates to a granting of access. > If one were dealing with lower layer protocols that handled this > differently then perhaps the having conflicting AVPs in some=20 > cases might > not be so bad.=20 >=20 > The alternate use of using Diameter to interface to an EAP > authentication server from an authorization server introduces some > interesting behavior. It could be possible that the authentication > succeeds and the authorization fails. In this case it would seem that > the authorization server should turn the EAP-Payload to an EAP-Failure > to be in line with 2.8.2. It might also be noted that this behavior > when used with certain EAP methods may cause a EAP timeout in lower > layers that expect the authorization decision to match the EAP > Authentication decision. >=20 >=20 From owner-aaa-wg@merit.edu Thu Mar 25 09:28:55 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23795 for ; Thu, 25 Mar 2004 09:28:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 154E591208; Thu, 25 Mar 2004 09:28:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D546E9129B; Thu, 25 Mar 2004 09:28:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A269C91208 for ; Thu, 25 Mar 2004 09:28:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C1F25DF9F; Thu, 25 Mar 2004 09:28:15 -0500 (EST) 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 4CB175DFC6 for ; Thu, 25 Mar 2004 09:28:14 -0500 (EST) 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 i2PESCp16482 for ; Thu, 25 Mar 2004 16:28:12 +0200 (EET) X-Scanned: Thu, 25 Mar 2004 16:27:51 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i2PERpFf017946 for ; Thu, 25 Mar 2004 16:27:51 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00Iu4Bzx; Thu, 25 Mar 2004 16:22:41 EET 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 i2PEMfF24312 for ; Thu, 25 Mar 2004 16:22:41 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Mar 2004 16:22:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Diameter Credit Control draft Date: Thu, 25 Mar 2004 16:22:41 +0200 Message-ID: Thread-Topic: Diameter Credit Control draft Thread-Index: AcQSdKFAfLN9Iss6QZyoh1z5uiPQeg== From: To: X-OriginalArrivalTime: 25 Mar 2004 14:22:41.0876 (UTC) FILETIME=[A2207940:01C41274] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable The Diameter Credit Control draft was announced on March 18th. The = authors believe that all of the open issues from the WGLC have been addressed. The = chairs recommend that the draft be submitted to the IESG. The current draft can be found here: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-04.txt From owner-aaa-wg@merit.edu Thu Mar 25 12:47: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 MAA10653 for ; Thu, 25 Mar 2004 12:47:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EEF6E9120A; Thu, 25 Mar 2004 12:47:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BAC369129B; Thu, 25 Mar 2004 12:47:12 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4D0D69120A for ; Thu, 25 Mar 2004 12:47:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3791A5DF77; Thu, 25 Mar 2004 12:47:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by segue.merit.edu (Postfix) with ESMTP id E83FC5DF82 for ; Thu, 25 Mar 2004 12:47:10 -0500 (EST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2PHl7Ue009098; Thu, 25 Mar 2004 09:47:07 -0800 (PST) Received: from jsaloweyw2k01 ([128.107.168.139]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 25 Mar 2004 09:53:35 -0800 From: "Joseph Salowey" To: , Subject: [AAA-WG]: RE: Proposed resolution of EAP issue 461: Alternate Uses and Conflicting AVPs Date: Thu, 25 Mar 2004 09:47:06 -0800 Message-ID: <000501c41291$30d26830$8ba86b80@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 Importance: Normal In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C39F7@esebe023.ntc.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 25 Mar 2004 17:53:35.0562 (UTC) FILETIME=[184FBAA0:01C41292] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Hi! > > I think the key name part of this issue is already > covered by issue #460. Would this change be ok? > > Change Section 2.8.2 from > > "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. Also, the Result-Code > SHOULD match the contained EAP packet (successful Result-Code > if EAP-Success, and a failure Result-Code for EAP-Failure). > TO BE WRITTEN: clarify this." > > To > > "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. Also, the Result-Code > SHOULD match the contained EAP packet: a successful Result-Code > for EAP-Success, and a failure Result-Code for EAP-Failure. > > 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). The responsibility > for avoiding conflicts lies with the EAP server. The NAS or > proxy agents MUST NOT "manufacture" or modify EAP packets in > order to correct contradictory messages they receive." [Joe] I don't think this works. Contradictory messages SHOULD NOT be allowed, but EAP-Messages MUST NOT be modified. This basically says that an intermediate proxy SHOULD NOT fail authorization, is this what we want to say? It seems that either you should allow EAP-Success to be turned into EAP-Failure (not the other way around) or disallow proxies. > > Best regards, > Pasi > >> -----Original Message----- >> From: owner-aaa-wg@merit.edu >> [mailto:owner-aaa-wg@merit.edu]On Behalf Of >> ext Joseph Salowey >> Sent: Thursday, March 04, 2004 3:52 AM >> To: aaa-wg@merit.edu >> Subject: [AAA-WG]: Issue eap: Alternate uses and conflicting AVPs >> >> >> >> Submitter name: Joe Salowey >> Submitter email address: jsalowey@cisco.com >> Date first submitted: 3/3/2004 >> Reference: >> Document: eap >> Comment type: E >> Priority: '1' Should fix >> Section: 2.8.2 and 2.8.5 >> Rationale/Explanation of issue: >> >> Since EAP keying has the concept of the key name this should >> probably be returned along with the Master Key. >> >> It might be goos to provide some motivation behind the 2.8.2 >> recommendation. I think the basic reason is that often lower layer >> protocols do not distingush between authentication and authorization. >> In these protocols the EAP-Success translates to a granting of >> access. If one were dealing with lower layer protocols that handled >> this differently then perhaps the having conflicting AVPs in some >> cases might not be so bad. >> >> The alternate use of using Diameter to interface to an EAP >> authentication server from an authorization server introduces some >> interesting behavior. It could be possible that the authentication >> succeeds and the authorization fails. In this case it would seem >> that the authorization server should turn the EAP-Payload to an >> EAP-Failure to be in line with 2.8.2. It might also be noted that >> this behavior when used with certain EAP methods may cause a EAP >> timeout in lower layers that expect the authorization decision to >> match the EAP Authentication decision. From aaa-admin@ietf.org Thu Mar 25 14:26:06 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 OAA14934 for ; Thu, 25 Mar 2004 14:26:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aTt-0004lB-9m; Thu, 25 Mar 2004 14:25:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aSm-0004e6-Hc for aaa@optimus.ietf.org; Thu, 25 Mar 2004 14:24:24 -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 OAA14819 for ; Thu, 25 Mar 2004 14:24:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6aSj-0001fZ-00 for aaa@ietf.org; Thu, 25 Mar 2004 14:24:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6aRl-0001cs-00 for aaa@ietf.org; Thu, 25 Mar 2004 14:23:22 -0500 Received: from bc100237.bendcable.com ([66.220.100.237]) by ietf-mx with smtp (Exim 4.12) id 1B6aQn-0001Z8-00 for aaa@ietf.org; Thu, 25 Mar 2004 14:22:21 -0500 Received: from 208.4.204.252 by web212.mail.yahoo.com; Thu, 25 Mar 2004 17:13:23 -0200 Message-ID: From: "Lessie Prince" To: aaa@ietf.org Date: Thu, 25 Mar 2004 12:20:23 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5442896229411822286" X-CS-IP: 128.154.144.13 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,HTML_70_80, HTML_FONT_BIG,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text Subject: [Aaa] instant degree 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: , ----5442896229411822286 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

    Ca<= !b>ll this number: 

    1-720-834-2989

    (24 hours)

     

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1-720-834-2989

     (7 days a week)=

    Confidentiality a<= !r>ssured!
     

    W= e are located in USA  international= callers are very welcome

    • ----5442896229411822286-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Mar 25 14:27:00 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 OAA14994 for ; Thu, 25 Mar 2004 14:26:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aUq-0004t6-1E for aaa-archive@odin.ietf.org; Thu, 25 Mar 2004 14:26:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PJQWbJ018788 for aaa-archive@odin.ietf.org; Thu, 25 Mar 2004 14:26:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aUp-0004sx-RZ for aaa-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 14:26:31 -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 OAA14983 for ; Thu, 25 Mar 2004 14:26:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6aUn-0001nX-00 for aaa-web-archive@ietf.org; Thu, 25 Mar 2004 14:26:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6aTx-0001lT-00 for aaa-web-archive@ietf.org; Thu, 25 Mar 2004 14:25:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aTt-0004lB-9m; Thu, 25 Mar 2004 14:25:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aSm-0004e6-Hc for aaa@optimus.ietf.org; Thu, 25 Mar 2004 14:24:24 -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 OAA14819 for ; Thu, 25 Mar 2004 14:24:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6aSj-0001fZ-00 for aaa@ietf.org; Thu, 25 Mar 2004 14:24:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6aRl-0001cs-00 for aaa@ietf.org; Thu, 25 Mar 2004 14:23:22 -0500 Received: from bc100237.bendcable.com ([66.220.100.237]) by ietf-mx with smtp (Exim 4.12) id 1B6aQn-0001Z8-00 for aaa@ietf.org; Thu, 25 Mar 2004 14:22:21 -0500 Received: from 208.4.204.252 by web212.mail.yahoo.com; Thu, 25 Mar 2004 17:13:23 -0200 Message-ID: From: "Lessie Prince" To: aaa@ietf.org Date: Thu, 25 Mar 2004 12:20:23 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5442896229411822286" X-CS-IP: 128.154.144.13 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,HTML_70_80, HTML_FONT_BIG,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text Subject: [Aaa] instant degree 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: , ----5442896229411822286 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

     
  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

     



    Confidentiality assured!
     

    W= e are located in USA  international= callers are very welcome

    • ----5442896229411822286-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Thu Mar 25 16:02: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 QAA22981 for ; Thu, 25 Mar 2004 16:02: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 1B6bzE-0007mu-Vx; Thu, 25 Mar 2004 16:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6bys-0007mI-9g for aaa@optimus.ietf.org; Thu, 25 Mar 2004 16:01: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 QAA22816 for ; Thu, 25 Mar 2004 16:01:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6byq-0001C4-00 for aaa@ietf.org; Thu, 25 Mar 2004 16:01:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6bxW-0000xt-00 for aaa@ietf.org; Thu, 25 Mar 2004 16:00:14 -0500 Received: from [218.88.141.80] (helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B6bwM-0000hA-00 for aaa@ietf.org; Thu, 25 Mar 2004 15:59:08 -0500 From: "wew@hotmail.com" To: aaa@ietf.org Content-Type: text/plain;charset="GB2312" Reply-To: wew@hotmail.com Date: Fri, 26 Mar 2004 04:59:06 +0800 X-Priority: 3 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 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.0 required=5.0 tests=AWL,CLICK_BELOW, FORGED_HOTMAIL_RCVD,FORGED_MUA_OUTLOOK,MAILTO_TO_SPAM_ADDR, MSGID_FROM_MTA_SHORT autolearn=no version=2.60 X-Spam-Report: * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 FORGED_HOTMAIL_RCVD Forged hotmail.com 'Received:' header found * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.0 CLICK_BELOW Asks you to click below * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 0.1 AWL AWL: Auto-whitelist adjustment Subject: [Aaa] Email Marketing 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: , Email Marketing ! We offer you e-mail addresses databases for advertisement mailing; we sell databases also carry out mailing and hosting for the advertising projects. Products World Email Lists . Their validity and originality are verified. web site: http://vipwd3.go.nease.net/wd3.htm Country or area total emails and price America 175 Million Email Address Europe 156 Million Email Address Asia 168 Million Email Address China(PRC) 80 Million Email Address HongKong 3.25 Million Email Address TaiWan 2.25 Million Email Address Japan 27 Million Email Address Australia 6 Million Email Address Canda 10 Million Email Address Russia 38 Million Email Address England 3.2 Million Email Address German 20 Million Email Address France 38 Million Email Address India 12 Million Email Address CENTRAL & SOUTH AMERICAN AREA 40 Million Email Address MIDDLE EAST & AFRICA 45 million Email Address SOUTH EAST AREA 32 million Email Address other Country or Area ¡­¡­¡­¡­¡­¡­ ---------------------------------------------------------------------------- Category Name total emails total price Apparel, Fashion, Textiles and Leather 4,654,565 $150 $100 US Automobile & Transportation 6,547,845 Business Services 6,366,344 Chemicals 3,445,565 Computer & Telecommunications 654,655 Construction & Real Estate 3,443,544 Consumer Electronics 1,333,443 Energy, Minerals & Metals 6,765,683 Environment 656,533 Food & Agriculture 1,235,354 Gems & Jewellery 565,438 Health & Beauty 804,654 Home Supplies 323,232 Industrial Supplies 415,668 Office Supplies 1,559,892 Packaging & Paper 5,675,648 Printing & Publishing 6,563,445 Security & Protection 5,653,494 Sports & Entertainment 3,488,455 Toys, Gifts and Handicrafts 2,135,654 --------------------------------------------------------------------------------------------- ¡¤All 136 nations , 40 trades email lists --------------------------------------------------------------------------------------------- Send Your Ad to Millions 5 million bulk email 50 million bulk email 100 million bulk email 200 million bulk email Imagine emailing 500,000 recipients and 1 out of every 1000 orders your product, that's 500 new orders! * We go all-out to make sure our customers are completely satisfied * If any emails fail to make delivery, we replace them free of charge * 100% Spam free, rest assured you will not be accused of spamming * Almost all of our emails are sent to valid email addresses * No software required, we do all the mailing from our own server * Don't be fooled in signing up with similar sites offering services that cannot compare to ours * Get the most bang for your buck with bulk email advantage! -------------------------------------------------------------------------------------------------------- Details and order Click Here to web site: http://vipwd3.go.nease.net/wd3.htm If you can't see website ,please email us contact: yhzx599@vip.sina.com Thank you! the silver star internet information company copyright¡¤2004-2005 all reserved ------------------------------------------------------------ remove please email: emailad1234@sina.com ------------------------------------------------------------ _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Mar 25 16:03: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 QAA23228 for ; Thu, 25 Mar 2004 16:03:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6c0O-00081v-Ko for aaa-archive@odin.ietf.org; Thu, 25 Mar 2004 16:03:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PL3C0X030867 for aaa-archive@odin.ietf.org; Thu, 25 Mar 2004 16:03:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6c0O-00081m-HO for aaa-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 16:03:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23150 for ; Thu, 25 Mar 2004 16:03:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6c0M-0001St-00 for aaa-web-archive@ietf.org; Thu, 25 Mar 2004 16:03:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6bzH-0001Gi-00 for aaa-web-archive@ietf.org; Thu, 25 Mar 2004 16:02:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6bzE-0007mu-Vx; Thu, 25 Mar 2004 16:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6bys-0007mI-9g for aaa@optimus.ietf.org; Thu, 25 Mar 2004 16:01: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 QAA22816 for ; Thu, 25 Mar 2004 16:01:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6byq-0001C4-00 for aaa@ietf.org; Thu, 25 Mar 2004 16:01:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6bxW-0000xt-00 for aaa@ietf.org; Thu, 25 Mar 2004 16:00:14 -0500 Received: from [218.88.141.80] (helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B6bwM-0000hA-00 for aaa@ietf.org; Thu, 25 Mar 2004 15:59:08 -0500 From: "wew@hotmail.com" To: aaa@ietf.org Content-Type: text/plain;charset="GB2312" Reply-To: wew@hotmail.com Date: Fri, 26 Mar 2004 04:59:06 +0800 X-Priority: 3 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 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.0 required=5.0 tests=AWL,CLICK_BELOW, FORGED_HOTMAIL_RCVD,FORGED_MUA_OUTLOOK,MAILTO_TO_SPAM_ADDR, MSGID_FROM_MTA_SHORT autolearn=no version=2.60 X-Spam-Report: * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 FORGED_HOTMAIL_RCVD Forged hotmail.com 'Received:' header found * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.0 CLICK_BELOW Asks you to click below * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 0.1 AWL AWL: Auto-whitelist adjustment Subject: [Aaa] Email Marketing 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: , Email Marketing ! We offer you e-mail addresses databases for advertisement mailing; we sell databases also carry out mailing and hosting for the advertising projects. Products World Email Lists . Their validity and originality are verified. web site: http://vipwd3.go.nease.net/wd3.htm Country or area total emails and price America 175 Million Email Address Europe 156 Million Email Address Asia 168 Million Email Address China(PRC) 80 Million Email Address HongKong 3.25 Million Email Address TaiWan 2.25 Million Email Address Japan 27 Million Email Address Australia 6 Million Email Address Canda 10 Million Email Address Russia 38 Million Email Address England 3.2 Million Email Address German 20 Million Email Address France 38 Million Email Address India 12 Million Email Address CENTRAL & SOUTH AMERICAN AREA 40 Million Email Address MIDDLE EAST & AFRICA 45 million Email Address SOUTH EAST AREA 32 million Email Address other Country or Area ¡­¡­¡­¡­¡­¡­ ---------------------------------------------------------------------------- Category Name total emails total price Apparel, Fashion, Textiles and Leather 4,654,565 $150 $100 US Automobile & Transportation 6,547,845 Business Services 6,366,344 Chemicals 3,445,565 Computer & Telecommunications 654,655 Construction & Real Estate 3,443,544 Consumer Electronics 1,333,443 Energy, Minerals & Metals 6,765,683 Environment 656,533 Food & Agriculture 1,235,354 Gems & Jewellery 565,438 Health & Beauty 804,654 Home Supplies 323,232 Industrial Supplies 415,668 Office Supplies 1,559,892 Packaging & Paper 5,675,648 Printing & Publishing 6,563,445 Security & Protection 5,653,494 Sports & Entertainment 3,488,455 Toys, Gifts and Handicrafts 2,135,654 --------------------------------------------------------------------------------------------- ¡¤All 136 nations , 40 trades email lists --------------------------------------------------------------------------------------------- Send Your Ad to Millions 5 million bulk email 50 million bulk email 100 million bulk email 200 million bulk email Imagine emailing 500,000 recipients and 1 out of every 1000 orders your product, that's 500 new orders! * We go all-out to make sure our customers are completely satisfied * If any emails fail to make delivery, we replace them free of charge * 100% Spam free, rest assured you will not be accused of spamming * Almost all of our emails are sent to valid email addresses * No software required, we do all the mailing from our own server * Don't be fooled in signing up with similar sites offering services that cannot compare to ours * Get the most bang for your buck with bulk email advantage! -------------------------------------------------------------------------------------------------------- Details and order Click Here to web site: http://vipwd3.go.nease.net/wd3.htm If you can't see website ,please email us contact: yhzx599@vip.sina.com Thank you! the silver star internet information company copyright¡¤2004-2005 all reserved ------------------------------------------------------------ remove please email: emailad1234@sina.com ------------------------------------------------------------ _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Fri Mar 26 01:46: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 BAA19406 for ; Fri, 26 Mar 2004 01:46:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6l6P-0006Mi-6i; Fri, 26 Mar 2004 01:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6l6K-0006LB-5K for aaa@optimus.ietf.org; Fri, 26 Mar 2004 01:45:56 -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 BAA19389 for ; Fri, 26 Mar 2004 01:45:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6l6G-00041w-00 for aaa@ietf.org; Fri, 26 Mar 2004 01:45:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6l5O-0003y4-00 for aaa@ietf.org; Fri, 26 Mar 2004 01:44:58 -0500 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1B6l4m-0003rf-00 for aaa@ietf.org; Fri, 26 Mar 2004 01:44:20 -0500 Received: from exchange1.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Fri, 26 Mar 2004 07:38:24 +0100 Received: by exchange1.bonn.de with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Mar 2004 07:40:27 +0100 Message-ID: <1C2329C9430609409808ECF102372876C73A74@sv3752.bonn.de> From: Systemadministrator To: aaa@ietf.org Date: Fri, 26 Mar 2004 07:40:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C412FD.38A611D0" 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_01C412FD.38A611D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: aul@bonn.de Subject: fake Sent: Thu, 25 Mar 2004 15:54:30 +0100 did not reach the following recipient(s): aul@bonn.de on Fri, 26 Mar 2004 07:43:25 +0100 Der Name des Empf=E4ngers wurde nicht erkannt. Die MTS-ID der urspr=FCnglichen Nachricht ist: c=3Dde;a=3D = ;p=3Dbundesstadt bonn;l=3DSV37520403260643H4HBYLM2 MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C412FD.38A611D0 Content-Type: message/rfc822 From: aaa@ietf.org To: aul@bonn.de Subject: fake Date: Thu, 25 Mar 2004 15:54:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C412FD.38A611D0" ------_=_NextPart_002_01C412FD.38A611D0 Content-Type: text/plain; charset="iso-8859-1" here it is ------_=_NextPart_002_01C412FD.38A611D0 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 concert.rtf.com 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_01C412FD.38A611D0-- ------_=_NextPart_000_01C412FD.38A611D0-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Fri Mar 26 01:48:25 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 BAA19497 for ; Fri, 26 Mar 2004 01:48:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6l8G-0006Z8-Iz for aaa-archive@odin.ietf.org; Fri, 26 Mar 2004 01:47:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q6luYa025232 for aaa-archive@odin.ietf.org; Fri, 26 Mar 2004 01:47:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6l8G-0006Yt-EP for aaa-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 01:47:56 -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 BAA19489 for ; Fri, 26 Mar 2004 01:47:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6l8D-0004Al-00 for aaa-web-archive@ietf.org; Fri, 26 Mar 2004 01:47:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6l7E-00046b-00 for aaa-web-archive@ietf.org; Fri, 26 Mar 2004 01:46:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6l6U-00042k-00 for aaa-web-archive@ietf.org; Fri, 26 Mar 2004 01:46:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6l6P-0006Mi-6i; Fri, 26 Mar 2004 01:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6l6K-0006LB-5K for aaa@optimus.ietf.org; Fri, 26 Mar 2004 01:45:56 -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 BAA19389 for ; Fri, 26 Mar 2004 01:45:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6l6G-00041w-00 for aaa@ietf.org; Fri, 26 Mar 2004 01:45:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6l5O-0003y4-00 for aaa@ietf.org; Fri, 26 Mar 2004 01:44:58 -0500 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1B6l4m-0003rf-00 for aaa@ietf.org; Fri, 26 Mar 2004 01:44:20 -0500 Received: from exchange1.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Fri, 26 Mar 2004 07:38:24 +0100 Received: by exchange1.bonn.de with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Mar 2004 07:40:27 +0100 Message-ID: <1C2329C9430609409808ECF102372876C73A74@sv3752.bonn.de> From: Systemadministrator To: aaa@ietf.org Date: Fri, 26 Mar 2004 07:40:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C412FD.38A611D0" 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_01C412FD.38A611D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: aul@bonn.de Subject: fake Sent: Thu, 25 Mar 2004 15:54:30 +0100 did not reach the following recipient(s): aul@bonn.de on Fri, 26 Mar 2004 07:43:25 +0100 Der Name des Empf=E4ngers wurde nicht erkannt. Die MTS-ID der urspr=FCnglichen Nachricht ist: c=3Dde;a=3D = ;p=3Dbundesstadt bonn;l=3DSV37520403260643H4HBYLM2 MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C412FD.38A611D0 Content-Type: message/rfc822 From: aaa@ietf.org To: aul@bonn.de Subject: fake Date: Thu, 25 Mar 2004 15:54:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C412FD.38A611D0" ------_=_NextPart_002_01C412FD.38A611D0 Content-Type: text/plain; charset="iso-8859-1" here it is ------_=_NextPart_002_01C412FD.38A611D0 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 concert.rtf.com 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_01C412FD.38A611D0-- ------_=_NextPart_000_01C412FD.38A611D0-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Fri Mar 26 03:14: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 DAA06193 for ; Fri, 26 Mar 2004 03:14:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E9F9991211; Fri, 26 Mar 2004 03:13:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A177191217; Fri, 26 Mar 2004 03:13:57 -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 6272091211 for ; Fri, 26 Mar 2004 03:13:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 370755DFFB; Fri, 26 Mar 2004 03:13:56 -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 E258E5DFD7 for ; Fri, 26 Mar 2004 03:13:50 -0500 (EST) 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 i2Q8Diu28307; Fri, 26 Mar 2004 10:13:44 +0200 (EET) X-Scanned: Fri, 26 Mar 2004 10:12:31 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i2Q8CViC004199; Fri, 26 Mar 2004 10:12:31 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00MlskHM; Fri, 26 Mar 2004 10:11:53 EET 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 i2Q8Bos23184; Fri, 26 Mar 2004 10:11:50 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 26 Mar 2004 10:10:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: RE: Proposed resolution of EAP issue 461: Alternate Uses and Conflicting AVPs Date: Fri, 26 Mar 2004 10:10:13 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61223AA@esebe023.ntc.nokia.com> Thread-Topic: Proposed resolution of EAP issue 461: Alternate Uses and Conflicting AVPs Thread-Index: AcQSkm6SgvalvPHoSn6Jo2rZIiILggAcgr4w From: To: , X-OriginalArrivalTime: 26 Mar 2004 08:10:38.0276 (UTC) FILETIME=[D2A33040:01C41309] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Joseph Salowey wrote: > > "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. Also, the Result-Code > > SHOULD match the contained EAP packet: a successful Result-Code > > for EAP-Success, and a failure Result-Code for EAP-Failure. > >=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). The responsibility > > for avoiding conflicts lies with the EAP server. The NAS or > > proxy agents MUST NOT "manufacture" or modify EAP packets in > > order to correct contradictory messages they receive." >=20 > [Joe] I don't think this works. Contradictory messages SHOULD NOT > be allowed, but EAP-Messages MUST NOT be modified. This=20 > basically says that an intermediate proxy SHOULD NOT fail=20 > authorization, is this what we want to say? It seems that either=20 > you should allow EAP-Success to be turned into EAP-Failure=20 > (not the other way around) or disallow proxies. =20 I think the "MUST NOT modify EAP messages" part is more important; that's essentially attempting a man-in-the-middle=20 attack against the protocol, and many EAP methods have e.g.=20 method-specific result indications that prevent this from even working. =20 Other than that, it's IMHO enough to say that "there are=20 circumstances where conflicting messages can't be avoided,=20 but you should be aware that it causes some problems". I don't think we have to solve these problem in this document;=20 neither does RFC3579... Best regards, Pasi From aaa-admin@ietf.org Fri Mar 26 07:18:34 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 HAA15948 for ; Fri, 26 Mar 2004 07:18: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 1B6qHh-0000AK-4U; Fri, 26 Mar 2004 07: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 1B6qGt-00009Z-Ca for aaa@optimus.ietf.org; Fri, 26 Mar 2004 07:17:11 -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 HAA15906 for ; Fri, 26 Mar 2004 07:17:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6qGs-0002vx-00 for aaa@ietf.org; Fri, 26 Mar 2004 07:17:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6qFx-0002qc-00 for aaa@ietf.org; Fri, 26 Mar 2004 07:16:14 -0500 Received: from [216.31.40.3] (helo=216-31-40-3.zianet.com) by ietf-mx with smtp (Exim 4.12) id 1B6qFV-0002kH-00 for aaa@ietf.org; Fri, 26 Mar 2004 07:15:45 -0500 Received: from 83.48.36.207 by 216.31.40.3; Fri, 26 Mar 2004 18:09:04 +0600 Message-ID: From: "Aaron Downs" Reply-To: "Aaron Downs" To: aaa@ietf.org Date: Fri, 26 Mar 2004 18:15:04 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--796772243719439" X-IP: 118.176.32.183 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.6 required=5.0 tests=BIZ_TLD,HTML_30_40, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,LINES_OF_YELLING, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 Subject: [Aaa] Fwd: Your Best Source for Medicines Online Delivered Discreetly and Securely to You 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: , ----796772243719439 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

    SAVE ON HUNDREDS OF MEDICATIONS

    Upon approval, our US Licensed Physicians will write an FDA-approved prescription for you and the product will be filled and shipped by a US licensed pharmacist overnight to your door, immediately and discreetly.

    Order by 2 pm EST and you get your meds tomorrow.

    Get Your Meds Here and Save!

    Aboric clinch bursitis endosperm niagara ma glycerine chordal w's clown demonstrate . Maforesaid thing arbutus hardwood tomography would melpomene . Nbloop solicitation raincoat grizzly eighteen biddy equitation powderpuff mountain usurp bedspring attitude cavilling sevenfold suspicion convergent light precession hotbox dress lost elope Hdrag airfoil igneous dominion cranny demerit infelicity collegial precipitous buret damnation mcnally carnation splenetic parallelogram !! Fextramarital amble antiphonal annulled haines loathe sweepstake duplicate carr chill vote genotype astronomer define cortland cheeky difluoride dietz broom consecutive pennyroyal anachronism steinberg alia tease shark butadiene : Ldickey demented noble wee nowadays vent romance slate sharp tariff lawsuit moorish o'clock dad jonathan chokeberry faulty initiate dreg consolation excretory avon dahl locke entrepreneur miocene cowpea devour krause halogen s! ao inexplicit forestry anachronism philosophy jinx .Aexpand boyle kettle same deborah cutler croquet honeydew !!! Ghonshu chesapeake olson aleck arcsin elephantine montpelier square pullover boycott boston conquer guilford hrothgar macrostructure colossal phd rehearse aggravate flamingo frustrater yeshiva flyway emma bayou carcinoma bemadden noisemake ? Hdetroit indorse brokerage czar elsie argumentative fury bogota tornado epithelium theory ramify coercible huff thermionic camelback electra scottsdale chlorinate copenhagen colloidal lebesgue amass roam neuropathology morass nutrient scarves meningitis shingle juggle coadjutor historic compulsive diatomaceous bastion miscible cricket death careful fractious miraculous putty pit .

    If this notice has reached you in error, please notify us by clicking here ----796772243719439-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Fri Mar 26 07:20: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 HAA16056 for ; Fri, 26 Mar 2004 07:20: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 1B6qJh-0000Kw-5s for aaa-archive@odin.ietf.org; Fri, 26 Mar 2004 07:20:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QCK5Td001294 for aaa-archive@odin.ietf.org; Fri, 26 Mar 2004 07:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6qJg-0000Kn-Ob for aaa-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 07:20:04 -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 HAA15989 for ; Fri, 26 Mar 2004 07:20:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6qJg-0003GM-00 for aaa-web-archive@ietf.org; Fri, 26 Mar 2004 07:20:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6qIg-00037q-00 for aaa-web-archive@ietf.org; Fri, 26 Mar 2004 07:19:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6qHk-00031X-00 for aaa-web-archive@ietf.org; Fri, 26 Mar 2004 07:18:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6qHh-0000AK-4U; Fri, 26 Mar 2004 07: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 1B6qGt-00009Z-Ca for aaa@optimus.ietf.org; Fri, 26 Mar 2004 07:17:11 -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 HAA15906 for ; Fri, 26 Mar 2004 07:17:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6qGs-0002vx-00 for aaa@ietf.org; Fri, 26 Mar 2004 07:17:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6qFx-0002qc-00 for aaa@ietf.org; Fri, 26 Mar 2004 07:16:14 -0500 Received: from [216.31.40.3] (helo=216-31-40-3.zianet.com) by ietf-mx with smtp (Exim 4.12) id 1B6qFV-0002kH-00 for aaa@ietf.org; Fri, 26 Mar 2004 07:15:45 -0500 Received: from 83.48.36.207 by 216.31.40.3; Fri, 26 Mar 2004 18:09:04 +0600 Message-ID: From: "Aaron Downs" Reply-To: "Aaron Downs" To: aaa@ietf.org Date: Fri, 26 Mar 2004 18:15:04 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--796772243719439" X-IP: 118.176.32.183 Subject: [Aaa] Fwd: Your Best Source for Medicines Online Delivered Discreetly and Securely to You 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=3.6 required=5.0 tests=BIZ_TLD,HTML_30_40, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,LINES_OF_YELLING, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----796772243719439 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

    SAVE ON HUNDREDS OF MEDICATIONS

    Upon approval, our US Licensed Physicians will write an FDA-approved prescription for you and the product will be filled and shipped by a US licensed pharmacist overnight to your door, immediately and discreetly.

    Order by 2 pm EST and you get your meds tomorrow.

    Get Your Meds Here and Save!

    Aboric clinch bursitis endosperm niagara ma glycerine chordal w's clown demonstrate . Maforesaid thing arbutus hardwood tomography would melpomene . Nbloop solicitation raincoat grizzly eighteen biddy equitation powderpuff mountain usurp bedspring attitude cavilling sevenfold suspicion convergent light precession hotbox dress lost elope Hdrag airfoil igneous dominion cranny demerit infelicity collegial precipitous buret damnation mcnally carnation splenetic parallelogram !! Fextramarital amble antiphonal annulled haines loathe sweepstake duplicate carr chill vote genotype astronomer define cortland cheeky difluoride dietz broom consecutive pennyroyal anachronism steinberg alia tease shark butadiene : Ldickey demented noble wee nowadays vent romance slate sharp tariff lawsuit moorish o'clock dad jonathan chokeberry faulty initiate dreg consolation excretory avon dahl locke entrepreneur miocene cowpea devour krause halogen s! ao inexplicit forestry anachronism philosophy jinx .Aexpand boyle kettle same deborah cutler croquet honeydew !!! Ghonshu chesapeake olson aleck arcsin elephantine montpelier square pullover boycott boston conquer guilford hrothgar macrostructure colossal phd rehearse aggravate flamingo frustrater yeshiva flyway emma bayou carcinoma bemadden noisemake ? Hdetroit indorse brokerage czar elsie argumentative fury bogota tornado epithelium theory ramify coercible huff thermionic camelback electra scottsdale chlorinate copenhagen colloidal lebesgue amass roam neuropathology morass nutrient scarves meningitis shingle juggle coadjutor historic compulsive diatomaceous bastion miscible cricket death careful fractious miraculous putty pit .

    If this notice has reached you in error, please notify us by clicking here ----796772243719439-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Fri Mar 26 13:07: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 NAA05259 for ; Fri, 26 Mar 2004 13:07: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 1B6vjQ-0006rQ-Jg; Fri, 26 Mar 2004 13:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6via-0006pg-QG for aaa@optimus.ietf.org; Fri, 26 Mar 2004 13:06: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 NAA05171 for ; Fri, 26 Mar 2004 13:06:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6viY-000128-00 for aaa@ietf.org; Fri, 26 Mar 2004 13:06:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6vhc-0000zT-00 for aaa@ietf.org; Fri, 26 Mar 2004 13:05:09 -0500 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1B6vgi-0000uH-00 for aaa@ietf.org; Fri, 26 Mar 2004 13:04:12 -0500 Received: from exchange1.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Fri, 26 Mar 2004 18:58:15 +0100 Received: by exchange1.bonn.de with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Mar 2004 19:00:17 +0100 Message-ID: <1C2329C9430609409808ECF102372876C76A99@sv3752.bonn.de> From: Systemadministrator To: aaa@ietf.org Date: Fri, 26 Mar 2004 19:00:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C4135C.31B330C4" 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: , 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_01C4135C.31B330C4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: acc@bonn.de Subject: warning Sent: Fri, 26 Mar 2004 18:53:22 +0100 did not reach the following recipient(s): acc@bonn.de on Fri, 26 Mar 2004 19:03:07 +0100 Der Name des Empf=E4ngers wurde nicht erkannt. Die MTS-ID der urspr=FCnglichen Nachricht ist: c=3Dde;a=3D = ;p=3Dbundesstadt bonn;l=3DSV37520403261803H4HBY56V MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C4135C.31B330C4 Content-Type: message/rfc822 From: aaa@ietf.org To: acc@bonn.de Subject: warning Date: Fri, 26 Mar 2004 18:53:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C4135C.31B330C4" ------_=_NextPart_002_01C4135C.31B330C4 Content-Type: text/plain; charset="iso-8859-1" do you? ------_=_NextPart_002_01C4135C.31B330C4 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 shower.exe 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_01C4135C.31B330C4-- ------_=_NextPart_000_01C4135C.31B330C4-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Fri Mar 26 13:08: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 NAA05332 for ; Fri, 26 Mar 2004 13:08: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 1B6vkj-0007G5-02 for aaa-archive@odin.ietf.org; Fri, 26 Mar 2004 13:08:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QI8KCt027898 for aaa-archive@odin.ietf.org; Fri, 26 Mar 2004 13:08:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6vki-0007Ft-SW for aaa-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 13:08: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 NAA05327 for ; Fri, 26 Mar 2004 13:08:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6vkg-0001BH-00 for aaa-web-archive@ietf.org; Fri, 26 Mar 2004 13:08:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6vjm-000184-00 for aaa-web-archive@ietf.org; Fri, 26 Mar 2004 13:07:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6vjS-00014R-00 for aaa-web-archive@ietf.org; Fri, 26 Mar 2004 13:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6vjQ-0006rQ-Jg; Fri, 26 Mar 2004 13:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6via-0006pg-QG for aaa@optimus.ietf.org; Fri, 26 Mar 2004 13:06: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 NAA05171 for ; Fri, 26 Mar 2004 13:06:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6viY-000128-00 for aaa@ietf.org; Fri, 26 Mar 2004 13:06:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6vhc-0000zT-00 for aaa@ietf.org; Fri, 26 Mar 2004 13:05:09 -0500 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1B6vgi-0000uH-00 for aaa@ietf.org; Fri, 26 Mar 2004 13:04:12 -0500 Received: from exchange1.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Fri, 26 Mar 2004 18:58:15 +0100 Received: by exchange1.bonn.de with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Mar 2004 19:00:17 +0100 Message-ID: <1C2329C9430609409808ECF102372876C76A99@sv3752.bonn.de> From: Systemadministrator To: aaa@ietf.org Date: Fri, 26 Mar 2004 19:00:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C4135C.31B330C4" 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: , 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_01C4135C.31B330C4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: acc@bonn.de Subject: warning Sent: Fri, 26 Mar 2004 18:53:22 +0100 did not reach the following recipient(s): acc@bonn.de on Fri, 26 Mar 2004 19:03:07 +0100 Der Name des Empf=E4ngers wurde nicht erkannt. Die MTS-ID der urspr=FCnglichen Nachricht ist: c=3Dde;a=3D = ;p=3Dbundesstadt bonn;l=3DSV37520403261803H4HBY56V MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C4135C.31B330C4 Content-Type: message/rfc822 From: aaa@ietf.org To: acc@bonn.de Subject: warning Date: Fri, 26 Mar 2004 18:53:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C4135C.31B330C4" ------_=_NextPart_002_01C4135C.31B330C4 Content-Type: text/plain; charset="iso-8859-1" do you? ------_=_NextPart_002_01C4135C.31B330C4 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 shower.exe 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_01C4135C.31B330C4-- ------_=_NextPart_000_01C4135C.31B330C4-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Sun Mar 28 00:24:42 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 AAA16886 for ; Sun, 28 Mar 2004 00:24:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7SmH-0001rn-KO; Sun, 28 Mar 2004 00:24:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7SIP-0007tW-3Y for aaa@optimus.ietf.org; Sat, 27 Mar 2004 23:53:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15923 for ; Sat, 27 Mar 2004 23:53:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7SIM-0001gd-00 for aaa@ietf.org; Sat, 27 Mar 2004 23:53:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7SHP-0001bw-00 for aaa@ietf.org; Sat, 27 Mar 2004 23:52:15 -0500 Received: from ool-182f46ed.dyn.optonline.net ([24.47.70.237]) by ietf-mx with smtp (Exim 4.12) id 1B7SHE-0001XD-00 for aaa@ietf.org; Sat, 27 Mar 2004 23:52:04 -0500 Received: from 32.188.230.108 by 24.47.70.237; Sun, 28 Mar 2004 07:44:04 +0300 Message-ID: From: "Monty Cassidy" Reply-To: "Monty Cassidy" To: aaa@ietf.org Date: Sat, 27 Mar 2004 23:47:04 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--31757876144001516" X-IP: 48.0.160.46 X-Priority: 3 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_40_50, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Aaa] No joke, you could be earning online profits in half an hour 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: , ----31757876144001516 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 200.67.170.250

     

    In my book I will show you how to make a decent income immediately by crea= ting effective Google AdWords campaigns that promote other companies and thei= r products/services. You will be paid each time your ad generates a sale or sign up!

    I don't want any more emails

    ----31757876144001516-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sun Mar 28 00:49: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 AAA17886 for ; Sun, 28 Mar 2004 00:49: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 1B7TAK-0005aW-9a for aaa-archive@odin.ietf.org; Sun, 28 Mar 2004 00:49:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2S5n0od021476 for aaa-archive@odin.ietf.org; Sun, 28 Mar 2004 00:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7TAK-0005aJ-3k for aaa-web-archive@optimus.ietf.org; Sun, 28 Mar 2004 00:49: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 AAA17806 for ; Sun, 28 Mar 2004 00:48:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7TAH-00000i-00 for aaa-web-archive@ietf.org; Sun, 28 Mar 2004 00:48:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7T8x-0007VS-00 for aaa-web-archive@ietf.org; Sun, 28 Mar 2004 00:47:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7T7P-0007BU-0A for aaa-web-archive@ietf.org; Sun, 28 Mar 2004 00:45:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7SmH-0001rn-KO; Sun, 28 Mar 2004 00:24:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7SIP-0007tW-3Y for aaa@optimus.ietf.org; Sat, 27 Mar 2004 23:53:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15923 for ; Sat, 27 Mar 2004 23:53:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7SIM-0001gd-00 for aaa@ietf.org; Sat, 27 Mar 2004 23:53:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7SHP-0001bw-00 for aaa@ietf.org; Sat, 27 Mar 2004 23:52:15 -0500 Received: from ool-182f46ed.dyn.optonline.net ([24.47.70.237]) by ietf-mx with smtp (Exim 4.12) id 1B7SHE-0001XD-00 for aaa@ietf.org; Sat, 27 Mar 2004 23:52:04 -0500 Received: from 32.188.230.108 by 24.47.70.237; Sun, 28 Mar 2004 07:44:04 +0300 Message-ID: From: "Monty Cassidy" Reply-To: "Monty Cassidy" To: aaa@ietf.org Date: Sat, 27 Mar 2004 23:47:04 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--31757876144001516" X-IP: 48.0.160.46 X-Priority: 3 Subject: [Aaa] No joke, you could be earning online profits in half an hour 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=3.5 required=5.0 tests=AWL,BIZ_TLD,HTML_30_40, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,PRIORITY_NO_NAME autolearn=no version=2.60 ----31757876144001516 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 200.67.170.250

     

    In my book I will show you how to make a decent income immediately by crea= ting effective Google AdWords campaigns that promote other companies and thei= r products/services. You will be paid each time your ad generates a sale or sign up!

    I don't want any more emails

    ----31757876144001516-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Sun Mar 28 06:02: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 GAA11131 for ; Sun, 28 Mar 2004 06:02: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 1B7Y3E-0003AT-W6; Sun, 28 Mar 2004 06:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7Y2h-00037q-NB for aaa@optimus.ietf.org; Sun, 28 Mar 2004 06:01:27 -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 GAA11106 for ; Sun, 28 Mar 2004 06:01:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7Y2e-0004fZ-00 for aaa@ietf.org; Sun, 28 Mar 2004 06:01:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7Y1f-0004Xk-00 for aaa@ietf.org; Sun, 28 Mar 2004 06:00:23 -0500 Received: from pcp03483294pcs.indpnd01.mo.comcast.net ([68.86.68.129]) by ietf-mx with smtp (Exim 4.12) id 1B7Y0e-0004Kh-00 for aaa@ietf.org; Sun, 28 Mar 2004 05:59:21 -0500 Received: from 191.136.176.114 by 68.86.68.129; Sun, 28 Mar 2004 04:50:16 -0600 Message-ID: From: "Loren Mckenna" Reply-To: "Loren Mckenna" To: aaa@ietf.org Date: Sun, 28 Mar 2004 15:54:16 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--35905413780540256068" X-Originating-IP: 132.151.6.1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=BIZ_TLD,HTML_50_60, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 Subject: [Aaa] over 200 million times a day, people use Google 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: , ----35905413780540256068 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 176.201.20.172

     

    With my proven strategies you'll make more money online than most other web = sites do and you won't even need to have a website!

    I don't want more emails

    ----35905413780540256068-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sun Mar 28 06:04: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 GAA11198 for ; Sun, 28 Mar 2004 06:04:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7Y4v-0003Ql-JQ for aaa-archive@odin.ietf.org; Sun, 28 Mar 2004 06:03:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2SB3jt2013182 for aaa-archive@odin.ietf.org; Sun, 28 Mar 2004 06:03:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7Y4v-0003QX-DF for aaa-web-archive@optimus.ietf.org; Sun, 28 Mar 2004 06:03:45 -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 GAA11194 for ; Sun, 28 Mar 2004 06:03:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7Y4r-0004yS-00 for aaa-web-archive@ietf.org; Sun, 28 Mar 2004 06:03:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7Y3r-0004q3-00 for aaa-web-archive@ietf.org; Sun, 28 Mar 2004 06:02:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7Y3G-0004iW-00 for aaa-web-archive@ietf.org; Sun, 28 Mar 2004 06:02:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7Y3E-0003AT-W6; Sun, 28 Mar 2004 06:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7Y2h-00037q-NB for aaa@optimus.ietf.org; Sun, 28 Mar 2004 06:01:27 -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 GAA11106 for ; Sun, 28 Mar 2004 06:01:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7Y2e-0004fZ-00 for aaa@ietf.org; Sun, 28 Mar 2004 06:01:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7Y1f-0004Xk-00 for aaa@ietf.org; Sun, 28 Mar 2004 06:00:23 -0500 Received: from pcp03483294pcs.indpnd01.mo.comcast.net ([68.86.68.129]) by ietf-mx with smtp (Exim 4.12) id 1B7Y0e-0004Kh-00 for aaa@ietf.org; Sun, 28 Mar 2004 05:59:21 -0500 Received: from 191.136.176.114 by 68.86.68.129; Sun, 28 Mar 2004 04:50:16 -0600 Message-ID: From: "Loren Mckenna" Reply-To: "Loren Mckenna" To: aaa@ietf.org Date: Sun, 28 Mar 2004 15:54:16 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--35905413780540256068" X-Originating-IP: 132.151.6.1 Subject: [Aaa] over 200 million times a day, people use Google 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=2.3 required=5.0 tests=AWL,BIZ_TLD,HTML_40_50, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----35905413780540256068 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 176.201.20.172

     

    With my proven strategies you'll make more money online than most other web = sites do and you won't even need to have a website!

    I don't want more emails

    ----35905413780540256068-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Sun Mar 28 13:48: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 NAA28418 for ; Sun, 28 Mar 2004 13:48: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 1B7fKC-0008Iz-6q; Sun, 28 Mar 2004 13:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7fK5-0008IO-Fr for aaa@optimus.ietf.org; Sun, 28 Mar 2004 13:47:53 -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 NAA28391 for ; Sun, 28 Mar 2004 13:47:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7fK3-00041H-00 for aaa@ietf.org; Sun, 28 Mar 2004 13:47:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7fJ9-0003pV-00 for aaa@ietf.org; Sun, 28 Mar 2004 13:46:55 -0500 Received: from bonngw.bonn.de ([212.79.173.53]) by ietf-mx with smtp (Exim 4.12) id 1B7fIL-0003VL-00 for aaa@ietf.org; Sun, 28 Mar 2004 13:46:05 -0500 Received: from exchange1.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Sun, 28 Mar 2004 20:40:14 +0200 Received: by exchange1.bonn.de with Internet Mail Service (5.5.2653.19) id ; Sun, 28 Mar 2004 20:42:35 +0200 Message-ID: <1C2329C9430609409808ECF102372876D277E6@sv3752.bonn.de> From: Systemadministrator To: aaa@ietf.org Date: Sun, 28 Mar 2004 20:42:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C414F4.6F0CC4A0" 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: information 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_01C414F4.6F0CC4A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: aer@bonn.de Subject: information Sent: Sun, 28 Mar 2004 20:40:43 +0200 did not reach the following recipient(s): aer@bonn.de on Sun, 28 Mar 2004 20:44:50 +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=3DSV37520403281844H4HBZ5NR MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C414F4.6F0CC4A0 Content-Type: message/rfc822 From: aaa@ietf.org To: aer@bonn.de Subject: information Date: Sun, 28 Mar 2004 20:40:43 +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_01C414F4.6F0CC4A0" ------_=_NextPart_002_01C414F4.6F0CC4A0 Content-Type: text/plain; charset="iso-8859-1" stuff about you? ------_=_NextPart_002_01C414F4.6F0CC4A0 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 object.zip contains: WORM_NETSKY.B virus in compressed file object.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_01C414F4.6F0CC4A0-- ------_=_NextPart_000_01C414F4.6F0CC4A0-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sun Mar 28 13:50:19 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 NAA28508 for ; Sun, 28 Mar 2004 13:50:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7fLz-0008Si-R6 for aaa-archive@odin.ietf.org; Sun, 28 Mar 2004 13:49:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2SInplb032524 for aaa-archive@odin.ietf.org; Sun, 28 Mar 2004 13:49:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7fLz-0008SR-Nb for aaa-web-archive@optimus.ietf.org; Sun, 28 Mar 2004 13:49:51 -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 NAA28466 for ; Sun, 28 Mar 2004 13:49:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7fLx-0004Ku-00 for aaa-web-archive@ietf.org; Sun, 28 Mar 2004 13:49:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7fL2-0004Bh-00 for aaa-web-archive@ietf.org; Sun, 28 Mar 2004 13:48:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7fKD-00042r-00 for aaa-web-archive@ietf.org; Sun, 28 Mar 2004 13:48:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7fKC-0008Iz-6q; Sun, 28 Mar 2004 13:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7fK5-0008IO-Fr for aaa@optimus.ietf.org; Sun, 28 Mar 2004 13:47:53 -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 NAA28391 for ; Sun, 28 Mar 2004 13:47:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7fK3-00041H-00 for aaa@ietf.org; Sun, 28 Mar 2004 13:47:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7fJ9-0003pV-00 for aaa@ietf.org; Sun, 28 Mar 2004 13:46:55 -0500 Received: from bonngw.bonn.de ([212.79.173.53]) by ietf-mx with smtp (Exim 4.12) id 1B7fIL-0003VL-00 for aaa@ietf.org; Sun, 28 Mar 2004 13:46:05 -0500 Received: from exchange1.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Sun, 28 Mar 2004 20:40:14 +0200 Received: by exchange1.bonn.de with Internet Mail Service (5.5.2653.19) id ; Sun, 28 Mar 2004 20:42:35 +0200 Message-ID: <1C2329C9430609409808ECF102372876D277E6@sv3752.bonn.de> From: Systemadministrator To: aaa@ietf.org Date: Sun, 28 Mar 2004 20:42:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C414F4.6F0CC4A0" Subject: [Aaa] Unzustellbar: information 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_01C414F4.6F0CC4A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: aer@bonn.de Subject: information Sent: Sun, 28 Mar 2004 20:40:43 +0200 did not reach the following recipient(s): aer@bonn.de on Sun, 28 Mar 2004 20:44:50 +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=3DSV37520403281844H4HBZ5NR MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C414F4.6F0CC4A0 Content-Type: message/rfc822 From: aaa@ietf.org To: aer@bonn.de Subject: information Date: Sun, 28 Mar 2004 20:40:43 +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_01C414F4.6F0CC4A0" ------_=_NextPart_002_01C414F4.6F0CC4A0 Content-Type: text/plain; charset="iso-8859-1" stuff about you? ------_=_NextPart_002_01C414F4.6F0CC4A0 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 object.zip contains: WORM_NETSKY.B virus in compressed file object.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_01C414F4.6F0CC4A0-- ------_=_NextPart_000_01C414F4.6F0CC4A0-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Sun Mar 28 15:08: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 PAA01838 for ; Sun, 28 Mar 2004 15:08: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 1B7gZd-0007AX-C5; Sun, 28 Mar 2004 15:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7gZW-00076j-Gf for aaa@optimus.ietf.org; Sun, 28 Mar 2004 15:07:54 -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 PAA01783 for ; Sun, 28 Mar 2004 15:07:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7gZT-0006rC-00 for aaa@ietf.org; Sun, 28 Mar 2004 15:07:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7gYY-0006kk-00 for aaa@ietf.org; Sun, 28 Mar 2004 15:06:55 -0500 Received: from bonngw.bonn.de ([212.79.173.53]) by ietf-mx with smtp (Exim 4.12) id 1B7gY5-0006dv-00 for aaa@ietf.org; Sun, 28 Mar 2004 15:06:25 -0500 Received: from exchange1.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Sun, 28 Mar 2004 22:00:34 +0200 Received: by exchange1.bonn.de with Internet Mail Service (5.5.2653.19) id ; Sun, 28 Mar 2004 22:03:06 +0200 Message-ID: <1C2329C9430609409808ECF102372876D2D163@sv3752.bonn.de> From: Systemadministrator To: aaa@ietf.org Date: Sun, 28 Mar 2004 22:03:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C414FF.AE56080A" 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: hi 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_01C414FF.AE56080A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: chf@bonn.de Subject: hi Sent: Sun, 28 Mar 2004 21:59:59 +0200 did not reach the following recipient(s): chf@bonn.de on Sun, 28 Mar 2004 22:06:07 +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=3DSV37520403282006H4HBZ7PH MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C414FF.AE56080A Content-Type: message/rfc822 From: aaa@ietf.org To: chf@bonn.de Subject: hi Date: Sun, 28 Mar 2004 21:59: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_01C414FF.AE56080A" ------_=_NextPart_002_01C414FF.AE56080A Content-Type: text/plain; charset="iso-8859-1" something about you! ------_=_NextPart_002_01C414FF.AE56080A 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 mail2.doc.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_01C414FF.AE56080A-- ------_=_NextPart_000_01C414FF.AE56080A-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sun Mar 28 15:10:20 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 PAA02093 for ; Sun, 28 Mar 2004 15:10:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7gbS-0007hr-6g for aaa-archive@odin.ietf.org; Sun, 28 Mar 2004 15:09:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2SK9sc2029617 for aaa-archive@odin.ietf.org; Sun, 28 Mar 2004 15:09:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7gbS-0007hc-2p for aaa-web-archive@optimus.ietf.org; Sun, 28 Mar 2004 15:09:54 -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 PAA02056 for ; Sun, 28 Mar 2004 15:09:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7gbO-00075K-00 for aaa-web-archive@ietf.org; Sun, 28 Mar 2004 15:09:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7gaQ-0006y0-00 for aaa-web-archive@ietf.org; Sun, 28 Mar 2004 15:08:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7gZc-0006ra-00 for aaa-web-archive@ietf.org; Sun, 28 Mar 2004 15:08:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7gZd-0007AX-C5; Sun, 28 Mar 2004 15:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7gZW-00076j-Gf for aaa@optimus.ietf.org; Sun, 28 Mar 2004 15:07:54 -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 PAA01783 for ; Sun, 28 Mar 2004 15:07:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7gZT-0006rC-00 for aaa@ietf.org; Sun, 28 Mar 2004 15:07:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7gYY-0006kk-00 for aaa@ietf.org; Sun, 28 Mar 2004 15:06:55 -0500 Received: from bonngw.bonn.de ([212.79.173.53]) by ietf-mx with smtp (Exim 4.12) id 1B7gY5-0006dv-00 for aaa@ietf.org; Sun, 28 Mar 2004 15:06:25 -0500 Received: from exchange1.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Sun, 28 Mar 2004 22:00:34 +0200 Received: by exchange1.bonn.de with Internet Mail Service (5.5.2653.19) id ; Sun, 28 Mar 2004 22:03:06 +0200 Message-ID: <1C2329C9430609409808ECF102372876D2D163@sv3752.bonn.de> From: Systemadministrator To: aaa@ietf.org Date: Sun, 28 Mar 2004 22:03:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C414FF.AE56080A" Subject: [Aaa] Unzustellbar: hi 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_01C414FF.AE56080A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: chf@bonn.de Subject: hi Sent: Sun, 28 Mar 2004 21:59:59 +0200 did not reach the following recipient(s): chf@bonn.de on Sun, 28 Mar 2004 22:06:07 +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=3DSV37520403282006H4HBZ7PH MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C414FF.AE56080A Content-Type: message/rfc822 From: aaa@ietf.org To: chf@bonn.de Subject: hi Date: Sun, 28 Mar 2004 21:59: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_01C414FF.AE56080A" ------_=_NextPart_002_01C414FF.AE56080A Content-Type: text/plain; charset="iso-8859-1" something about you! ------_=_NextPart_002_01C414FF.AE56080A 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 mail2.doc.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_01C414FF.AE56080A-- ------_=_NextPart_000_01C414FF.AE56080A-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Sun Mar 28 15:28: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 PAA03296 for ; Sun, 28 Mar 2004 15:28: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 1B7gsz-0002oM-2x; Sun, 28 Mar 2004 15:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7gsw-0002nv-JJ for aaa@optimus.ietf.org; Sun, 28 Mar 2004 15:27: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 PAA03262 for ; Sun, 28 Mar 2004 15:27:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7gsv-0001gL-00 for aaa@ietf.org; Sun, 28 Mar 2004 15:27:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7gs1-0001Y5-00 for aaa@ietf.org; Sun, 28 Mar 2004 15:27:02 -0500 Received: from bonngw.bonn.de ([212.79.173.53]) by ietf-mx with smtp (Exim 4.12) id 1B7gr6-0001JG-00 for aaa@ietf.org; Sun, 28 Mar 2004 15:26:04 -0500 Received: from exchange1.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Sun, 28 Mar 2004 22:20:13 +0200 Received: by exchange1.bonn.de with Internet Mail Service (5.5.2653.19) id ; Sun, 28 Mar 2004 22:22:41 +0200 Message-ID: <1C2329C9430609409808ECF102372876D278F0@sv3752.bonn.de> From: Systemadministrator To: aaa@ietf.org Date: Sun, 28 Mar 2004 22:22:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C41502.6B20DC10" 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: , 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_01C41502.6B20DC10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: cum@bonn.de Subject: read it immediately Sent: Sun, 28 Mar 2004 22:19:20 +0200 did not reach the following recipient(s): cum@bonn.de on Sun, 28 Mar 2004 22:25:47 +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=3DSV37520403282025H4HBZ8A7 MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C41502.6B20DC10 Content-Type: message/rfc822 From: aaa@ietf.org To: cum@bonn.de Subject: read it immediately Date: Sun, 28 Mar 2004 22:19: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_01C41502.6B20DC10" ------_=_NextPart_002_01C41502.6B20DC10 Content-Type: text/plain; charset="iso-8859-1" thats wrong ------_=_NextPart_002_01C41502.6B20DC10 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 disco.zip contains: WORM_NETSKY.B virus in compressed file disco.doc.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_01C41502.6B20DC10-- ------_=_NextPart_000_01C41502.6B20DC10-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sun Mar 28 15:30:19 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 PAA03383 for ; Sun, 28 Mar 2004 15:30:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7gul-0002vd-Oc for aaa-archive@odin.ietf.org; Sun, 28 Mar 2004 15:29:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2SKTpqH011257 for aaa-archive@odin.ietf.org; Sun, 28 Mar 2004 15:29:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7gul-0002vQ-JH for aaa-web-archive@optimus.ietf.org; Sun, 28 Mar 2004 15:29:51 -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 PAA03368 for ; Sun, 28 Mar 2004 15:29:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7guk-0001vI-00 for aaa-web-archive@ietf.org; Sun, 28 Mar 2004 15:29:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7gto-0001o9-00 for aaa-web-archive@ietf.org; Sun, 28 Mar 2004 15:28:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7gt0-0001h5-00 for aaa-web-archive@ietf.org; Sun, 28 Mar 2004 15:28:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7gsz-0002oM-2x; Sun, 28 Mar 2004 15:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7gsw-0002nv-JJ for aaa@optimus.ietf.org; Sun, 28 Mar 2004 15:27: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 PAA03262 for ; Sun, 28 Mar 2004 15:27:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7gsv-0001gL-00 for aaa@ietf.org; Sun, 28 Mar 2004 15:27:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7gs1-0001Y5-00 for aaa@ietf.org; Sun, 28 Mar 2004 15:27:02 -0500 Received: from bonngw.bonn.de ([212.79.173.53]) by ietf-mx with smtp (Exim 4.12) id 1B7gr6-0001JG-00 for aaa@ietf.org; Sun, 28 Mar 2004 15:26:04 -0500 Received: from exchange1.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Sun, 28 Mar 2004 22:20:13 +0200 Received: by exchange1.bonn.de with Internet Mail Service (5.5.2653.19) id ; Sun, 28 Mar 2004 22:22:41 +0200 Message-ID: <1C2329C9430609409808ECF102372876D278F0@sv3752.bonn.de> From: Systemadministrator To: aaa@ietf.org Date: Sun, 28 Mar 2004 22:22:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C41502.6B20DC10" 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: , 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_01C41502.6B20DC10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: cum@bonn.de Subject: read it immediately Sent: Sun, 28 Mar 2004 22:19:20 +0200 did not reach the following recipient(s): cum@bonn.de on Sun, 28 Mar 2004 22:25:47 +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=3DSV37520403282025H4HBZ8A7 MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C41502.6B20DC10 Content-Type: message/rfc822 From: aaa@ietf.org To: cum@bonn.de Subject: read it immediately Date: Sun, 28 Mar 2004 22:19: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_01C41502.6B20DC10" ------_=_NextPart_002_01C41502.6B20DC10 Content-Type: text/plain; charset="iso-8859-1" thats wrong ------_=_NextPart_002_01C41502.6B20DC10 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 disco.zip contains: WORM_NETSKY.B virus in compressed file disco.doc.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_01C41502.6B20DC10-- ------_=_NextPart_000_01C41502.6B20DC10-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Mon Mar 29 15:37: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 PAA24603 for ; Mon, 29 Mar 2004 15:37:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 120F79126A; Mon, 29 Mar 2004 15:36:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D5E909126B; Mon, 29 Mar 2004 15:36:53 -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 8AE179126A for ; Mon, 29 Mar 2004 15:36:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 71D1C58601; Mon, 29 Mar 2004 15:36:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by segue.merit.edu (Postfix) with ESMTP id DF8D1585D7 for ; Mon, 29 Mar 2004 15:36:51 -0500 (EST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2004 12:44:06 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2TKamKj021592; Mon, 29 Mar 2004 12:36:49 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.224.84]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Mar 2004 12:43:18 -0800 From: "Joseph Salowey" To: , Subject: [AAA-WG]: RE: Proposed resolution of EAP issue 461: Alternate Uses and Conflicting AVPs Date: Mon, 29 Mar 2004 12:36:46 -0800 Message-ID: <00bc01c415cd$8ed550c0$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: <052E0C61B69C3741AFA5FE88ACC775A61223AA@esebe023.ntc.nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 29 Mar 2004 20:43:19.0237 (UTC) FILETIME=[77E83750:01C415CE] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Joseph Salowey wrote: > >>> "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. Also, the Result-Code >>> SHOULD match the contained EAP packet: a successful Result-Code >>> for EAP-Success, and a failure Result-Code for EAP-Failure. >>> >>> 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). The responsibility >>> for avoiding conflicts lies with the EAP server. The NAS or >>> proxy agents MUST NOT "manufacture" or modify EAP packets in >>> order to correct contradictory messages they receive." >> >> [Joe] I don't think this works. Contradictory messages SHOULD NOT be >> allowed, but EAP-Messages MUST NOT be modified. This basically says >> that an intermediate proxy SHOULD NOT fail authorization, is this >> what we want to say? It seems that either you should allow >> EAP-Success to be turned into EAP-Failure (not the other way around) >> or disallow proxies. > > I think the "MUST NOT modify EAP messages" part is more > important; that's essentially attempting a man-in-the-middle > attack against the protocol, and many EAP methods have e.g. > method-specific result indications that prevent this > from even working. [Joe] It sounds like you are arguing for not allowing an intermediary to change and authorization decision. The basic problem is that an EAP authentication decision in not necessarily an authorization decision. By enforcing no conflicts and no modifications we make successful authentication equivalent to successful authorization. I do not think this is so good. Perhaps authenticate and authorize functionality should only be used in cases where the authentication decision is equivalent to authorization. In other cases two separate authentication followed by authorization messages should be used. > > Other than that, it's IMHO enough to say that "there are > circumstances where conflicting messages can't be avoided, > but you should be aware that it causes some problems". > I don't think we have to solve these problem in this document; > neither does RFC3579... > [Joe] Maybe, but how does this work in 802.1x case if AAA rejects, but EAP indicates success? If we don't solve it here then where do we solve it? > Best regards, > Pasi From owner-aaa-wg@merit.edu Mon Mar 29 16:50: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 QAA28699 for ; Mon, 29 Mar 2004 16:50:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C1D329126F; Mon, 29 Mar 2004 16:50:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 979E091270; Mon, 29 Mar 2004 16:50:17 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 690109126F for ; Mon, 29 Mar 2004 16:50:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 50030584EB; Mon, 29 Mar 2004 16:50:16 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by segue.merit.edu (Postfix) with ESMTP id 07235584E5 for ; Mon, 29 Mar 2004 16:50:16 -0500 (EST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2004 13:57:31 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2TLoDUe000422; Mon, 29 Mar 2004 13:50:13 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.224.84]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Mar 2004 13:56:42 -0800 From: "Joseph Salowey" To: , Subject: [AAA-WG]: RE: Proposed resolution of EAP issue 455: User-name handling Date: Mon, 29 Mar 2004 13:50:09 -0800 Message-ID: <00cd01c415d7$cf5d59d0$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: <052E0C61B69C3741AFA5FE88ACC775A6010C39F5@esebe023.ntc.nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 29 Mar 2004 21:56:42.0597 (UTC) FILETIME=[B883A150:01C415D8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Looks good. Pasi.Eronen@nokia.com wrote: > Hi, > > Does this look ok? > > Replace in Section 2.8.1 > > "Therefore, the Diameter Server SHOULD return the user's > identity by inserting it in the User-Name AVP of subsequent > Diameter-EAP-Answer packets. Without the user's identity, > the Session-Id AVP MAY be used for accounting and billing, > however operationally this could be very difficult to manage." > > by > > "Therefore, the Diameter Server SHOULD return the user's > identity by inserting a User-Name AVP to Diameter-EAP-Answer > messages that have a Result-Code of DIAMETER_SUCCESS. A > separate billing identifier or pseudonym MAY be used for > privacy reasons (see Section 8.5). If the user's identity is > not available to the NAS, the Session-Id AVP MAY be used for > accounting and billing; however operationally this could be > very difficult to manage." > > BR, > Pasi > >> -----Original Message----- >> From: owner-aaa-wg@merit.edu >> [mailto:owner-aaa-wg@merit.edu]On Behalf Of >> ext Joseph Salowey >> Sent: Thursday, March 04, 2004 12:00 AM >> To: aaa-wg@merit.edu >> Subject: [AAA-WG]: Issue EAP : User-name Handling >> >> >> >> Submitter name: Joe Salowey >> Submitter email address: jsalowey@cisco.com >> Date first submitted: 3/3/2004 >> Reference: >> Document: eap >> Comment type: 'E'ditorial >> Priority: '1' Should fix >> Section: 2.8.1 >> Rationale/Explanation of issue: >> >> The draft says "...the Diameter server SHOULD return the >> user's identity >> by inserting it in the User-Name AVP of susequent Diameter-EAP-Answer >> packets." It is not clear which user identity this is >> referring to. If >> it is referring to the user's real identity this is only available >> once the EAP method completes. It probably should state: >> >> "...the Diameter Server SHOULD return the real user's identity by >> inserting it in the User-Name AVP of Diameter-EAP-Answer packets that >> contain a Result-Code of DIAMETER-SUCCESS." >> >> It might also be good to discuss that the real user-name MAY >> be omitted >> or replaced with a different billing identifier if identity privacy >> is required in the DIAMETER channel. From owner-aaa-wg@merit.edu Tue Mar 30 06:00: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 GAA12106 for ; Tue, 30 Mar 2004 06:00:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 473EA91201; Tue, 30 Mar 2004 06:00:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C72939127C; Tue, 30 Mar 2004 06:00:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 29D3D91201 for ; Tue, 30 Mar 2004 05:59:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0AB8E58BA5; Tue, 30 Mar 2004 05:59:59 -0500 (EST) 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 CCD4558BAD for ; Tue, 30 Mar 2004 05:59:57 -0500 (EST) 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 i2UAxpn03078; Tue, 30 Mar 2004 13:59:51 +0300 (EET DST) X-Scanned: Tue, 30 Mar 2004 13:58:38 +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 i2UAwc4c025086; Tue, 30 Mar 2004 13:58:38 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00Qnd16u; Tue, 30 Mar 2004 13:58:35 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 i2UAwZF24091; Tue, 30 Mar 2004 13:58:35 +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, 30 Mar 2004 13:58: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: [AAA-WG]: RE: Proposed resolution of EAP issue 461: Alternate Uses and Conflicting AVPs Date: Tue, 30 Mar 2004 13:58:28 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61223B0@esebe023.ntc.nokia.com> Thread-Topic: Proposed resolution of EAP issue 461: Alternate Uses and Conflicting AVPs Thread-Index: AcQVzd4CfWQYaJSnQaaXxD/AtV/HPAAcLZrg From: To: , X-OriginalArrivalTime: 30 Mar 2004 10:58:29.0071 (UTC) FILETIME=[EEF38DF0:01C41645] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > > I think the "MUST NOT modify EAP messages" part is more > > important; that's essentially attempting a man-in-the-middle > > attack against the protocol, and many EAP methods have e.g. > > method-specific result indications that prevent this > > from even working. >=20 > [Joe] It sounds like you are arguing for not allowing an > intermediary to change and authorization decision. The basic > problem is that an EAP authentication decision in not > necessarily an authorization decision. By enforcing no > conflicts and no modifications we make successful > authentication equivalent to successful authorization. =20 > I do not think this is so good. > > Perhaps authenticate and authorize functionality should only > be used in cases where the authentication decision is > equivalent to authorization. In other cases two separate > authentication followed by authorization messages should be > used. I agree, EAP success/failure and Diameter success/failure Result-Code are two separate things. I'm proposing that we enforce the "no modifications to EAP messages" part,=20 but allow conflicting messages with a note explaining why they may cause problems (this is what RFC3579 also does). A separate Diameter AUTHORIZE_ONLY exchange doesn't really help here, because the NAS does not have any conflicts about what to do (it's not supposed to look inside the EAP packet). What is really missing is a secure way to notify the client=20 that "EAP went OK, but I decided anyway not to give you access". For instance, the 802.11i four-way handshake could have had some field denoting "authorization failed" (which would be protected with keys derived from PMK). > > Other than that, it's IMHO enough to say that "there are > > circumstances where conflicting messages can't be avoided, > > but you should be aware that it causes some problems". > > I don't think we have to solve these problem in this document; > > neither does RFC3579...=20 >=20 > [Joe] Maybe, but how does this work in 802.1x case if AAA=20 > rejects, but EAP indicates success? If we don't solve it=20 > here then where do we solve it? Since we don't have a protected "authorization failure" exchange between the client and NAS, we seem to be stuck with either attempting MitM attack against EAP, or sending conflicting messages. Both usually lead to the same situation: a timeout before the client discovers that it didn't actually get access. In 802.11i, it seems the timeout for conflicting messages isn't necessarily that long. The client is expecting the first message of four-way handshake; the default retransmission timeout is 100 ms, and the default number of retransmissions=20 is 3. Therefore, if the client doesn't receive something in, say,=20 one second after EAP Success, it could deduce that something went wrong... (If the NAS or proxy changes the EAP Success to Failure, and=20 the client ignores the Failure message because it had contradicting method-specific indication, it seems the timeout would have to be much longer than this.) In plain 802.1X for e.g. wired Ethernet switch ports the timeout could be longer, sure (no response to any ARP or DHCP messages). But IMHO this is not something that absolutely=20 needs to be solved... (and the successor of 802.1X/11i looks=20 like a more logical place to solve this than Diameter EAP spec). Best regards, Pasi From owner-aaa-wg@merit.edu Wed Mar 31 04:34: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 EAA08895 for ; Wed, 31 Mar 2004 04:34:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 099E291211; Wed, 31 Mar 2004 04:34:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B94A59128A; Wed, 31 Mar 2004 04:34:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 508D791211 for ; Wed, 31 Mar 2004 04:34:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 36F6D584BE; Wed, 31 Mar 2004 04:34:28 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by segue.merit.edu (Postfix) with ESMTP id 75C2F584C0 for ; Wed, 31 Mar 2004 04:34:27 -0500 (EST) Received: from vies1k7x.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i2V7hDEP015413 for ; Wed, 31 Mar 2004 09:43:13 +0200 Received: from zagh102a.zag.siemens.hr (vies1kbx.sie.siemens.at [158.226.135.174]) by vies1k7x.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i2V7hAwh030853 for ; Wed, 31 Mar 2004 09:43:12 +0200 Received: by zagh102a.zag.siemens.hr with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Mar 2004 09:34:17 +0200 Message-ID: From: Peko Jasna To: aaa-wg@merit.edu Subject: [AAA-WG]: www.diameter.org/XML Date: Wed, 31 Mar 2004 09:33:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C416F2.88108FE0" 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_01C416F2.88108FE0 Content-Type: text/plain; charset="iso-8859-1" Hello! In Diameter API RFC is a reference [4] to http://www.diameter.org/XML but this page could not be found. Could someone send me this DTD and XML to which it is refering to? Thanks, J ------_=_NextPart_001_01C416F2.88108FE0 Content-Type: text/html; charset="iso-8859-1"
    Hello!
     
    In Diameter API RFC is a reference [4] to http://www.diameter.org/XML
    but this page could not be found.
     
    Could someone send me this DTD and XML to which it is refering to?
     
    Thanks,
     
    J
     
    ------_=_NextPart_001_01C416F2.88108FE0-- From owner-aaa-wg@merit.edu Wed Mar 31 09:07: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 JAA23291 for ; Wed, 31 Mar 2004 09:07:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7521691217; Wed, 31 Mar 2004 09:07:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3EEC99121A; Wed, 31 Mar 2004 09:07:44 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 384A091217 for ; Wed, 31 Mar 2004 09:07:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 145535885F; Wed, 31 Mar 2004 09:07:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from gw.frascone.com (adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by segue.merit.edu (Postfix) with ESMTP id E938B588C8 for ; Wed, 31 Mar 2004 09:07:37 -0500 (EST) Received: by gw.frascone.com (Postfix, from userid 500) id 4BED258000D; Wed, 31 Mar 2004 08:07:37 -0600 (CST) Date: Wed, 31 Mar 2004 08:07:37 -0600 From: David Frascone To: Peko Jasna Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: www.diameter.org/XML Message-ID: <20040331140737.GB24353@wolverine.frascone.com> Mail-Followup-To: Peko Jasna , aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-aaa-wg@merit.edu Precedence: bulk --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline It's referring to these attached documents. If the wg is ready to start discussing xml or the api, I'd be heppy to update and submit the drafts. -Dave On Wednesday, 31 Mar 2004, Peko Jasna wrote: > Hello! > > In Diameter API RFC is a reference [4] to http://www.diameter.org/XML > > but this page could not be found. > > Could someone send me this DTD and XML to which it is refering to? > > Thanks, > > J > > > -- David Frascone The Magic of Windows: Turns a 486 back into a PC/XT. --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-ietf-aaa-xml-dictionary-02.txt" AAA Working Group David Frascone Internet-Draft Airespace Category: Informational Mark Jones Bridgewater Systems Erik Guttman Sun Microsystems, Inc. March 2003 Diameter XML Dictionary Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society 2003. All Rights Reserved. Abstract This document describes a coding of Diameter dictionaries in XML. This coding is intended for use by Diameter implementations to represent Applications, Commands, Vendors, and AVPs. Frascone et al. expires November 2003 [Page 1] Internet-Draft March 2003 Discussion of this document Send comments to the AAA Working Group mailing list . To subscribe to the list, send a message with the body 'subscribe aaa-wg' to Table of Contents 1.0 Introduction 2.0 Specifications and Requirements 3.0 Dictionary Layout 3.1 Vendor Element 3.1.1 "id" Attribute 3.1.2 "name" Attribute 3.2 Base Element 3.3 Application Element 3.4 Base Protocol and Application Elements 3.4.1 "id" Attribute 3.4.2 "name" Attribute 3.4.3 "uri" Attribute 3.5 Command Element 3.5.1 "name" Attribute 3.5.2 "code" Attribute 3.5.3 "vendor-id" Attribute 3.6 AVP Rule Element 3.6.1 "name" Attribute 3.6.2 "position" Attribute 3.6.3 "maximum" Attribute 3.6.4 "minimum" Attribute 3.7 Type Definition Element 3.7.1 "type-name" Attribute 3.7.2 "type-parent" Attribute 3.7.3 "description" Attribute 3.8 Attribute Value Pair Element 3.8.1 "name" Attribute 3.8.2 "description" Attribute 3.8.3 "code" Attribute 3.8.4 "may-encrypt" Attribute 3.8.5 "mandatory" Attribute 3.8.6 "protected" Attribute 3.8.7 "vendor-id" Attribute 3.9 Type Element 3.9.1 "type-name" attribute 3.10 Grouped AVPs Element 3.10.1 "name" Attribute 3.10.2 "vendor-id" Attribute 3.11 Enumerated Element 3.11.1 "name" Attribute Frascone et al. expires November 2003 [Page 2] Internet-Draft March 2003 3.11.3 "code" Attribute 4.0 References 5.0 Acknowledgments 6.0 Authors' Addresses Appendix A. Document Type Definition Appendix B. DTD & Dictionary Links Frascone et al. expires November 2003 [Page 3] Internet-Draft March 2003 1.0 Introduction Diameter [1] is an extensible protocol used to provide AAA services to different access technologies. To maintain extensibility, Diameter uses a dictionary to provide it with the format of commands and AVPs. This document describes the representation of the Diameter dictionary using XML [2]. 2.0 Specifications and Requirements In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [3]. 3.0 Dictionary Layout The root or top-level element of a Diameter dictionary is the "dictionary" element. The dictionary element contains zero or more "vendor" elements, the "base" element and zero or more "application" elements. The top-level XML file containing the "dictionary" element SHOULD be named "dictionary.xml". Each "application" element SHOULD be defined in a separate XML file and referenced from the top-level XML file using an external entity declaration. Syntax: +------------+----------------+ | Element | Classification | +------------+----------------+ |vendor | Zero or More | +------------+----------------+ |base | Required | +------------+----------------+ |application | Zero or More | +------------+----------------+ 3.1 Vendor Element Frascone et al. expires November 2003 [Page 4] Internet-Draft March 2003 The Vendor element defines a vendor by a name and associated IANA assigned "SMI Network Management Private Enterprise Codes" [4]. Syntax: +----------+----------+-------------+---------+ |Attribute | Presence | Constraints | Values | +----------+----------+-------------+---------+ | id | Required | UniqueKey | Integer | +----------+----------+-------------+---------+ | name | Required | None | String | +----------+----------+-------------+---------+ 3.1.1 "id" Attribute The "id" attribute is the vendor code assigned by IANA [4]. The "id" MUST be unique across all Vendor element definitions although this constraint can not be enforced by the DTD. 3.1.2 "name" Attribute The "name" attribute is some text describing the vendor. Although the Diameter protocol only requires the vendor code for encoding and decoding messages, the vendor name MAY be used in trace utilities to facilitate debugging. 3.2 Base Element The base element defines the commands, data types and AVPs that are part of the Diameter Base Protocol [1]. 3.3 Application Element One of the ways in which the Diameter protocol can be extended is through the addition of new applications. The application element defines the new Commands, Types or AVPs needed to support a new Diam- eter application. It may also reference elements defined in the base protocol. 3.4 Base Protocol and Application Elements The base commands, and application specific commands have identical Frascone et al. expires November 2003 [Page 5] Internet-Draft March 2003 syntax, with the exception that the base protocol requires at least one type, avp, and command be defined. So, they are being described together. Applications must define any Commands, Types, or AVPs that they cre- ate. The application (or base) element holds those definitions. Syntax: +----------+--------------------+-------------+--------+ |Attribute | Presence | Constraints | Values | +----------+--------------------+-------------+--------+ | uri | Optional | None | String | +----------+--------------------+-------------+--------+ | name | Optional | None | String | | | (application only) | | | +----------+--------------------+-------------+--------+ | id | Required | None | String | | | (application only) | | | +----------+--------------------+-------------+--------+ 3.4.1 "id" Attribute The "id" attribute is the IANA assigned Application Identifier for this application. 3.4.2 "name" Attribute The "name" attribute is the human readable name of this application. Frascone et al. expires November 2003 [Page 6] Internet-Draft March 2003 3.4.3 "uri" Attribute The "uri" attribute is an optional reference used to provide useful information about this application. For example, the base protocol has a URI that points to the most recent Diameter Base Protocol draft. 3.5 Command Element A command element defines the attributes for a command, and contains any rules to be applied to it. (Note: See Section 3.6 AVP Rule Ele- ment) Syntax: +----------+----------+-------------+---------+ |Attribute | Presence | Constraints | Values | +----------+----------+-------------+---------+ | name | Required | None | String | +----------+----------+-------------+---------+ | code | Required | None | Integer | +----------+----------+-------------+---------+ |vendor-id | Optional | Reference | Integer | +----------+----------+-------------+---------+ 3.5.1 "name" Attribute The "name" attribute defines the name of the command. Only one com- mand is defined for both "Request" and "Answer" portions. So, the "Capabilities-Exchange" command defines the messages, "Capabilities- Exchange-Request", and "Capabilities-Exchange-Answer". 3.5.2 "code" Attribute The "code" attribute defines the command code used to transmit this command. 3.5.3 "vendor-id" Attribute Frascone et al. expires November 2003 [Page 7] Internet-Draft March 2003 If this is a vendor specific command, then the "vendor-id" attribute MUST correspond to a vendor element's "id" field. 3.6 AVP Rule Element AVP rules elements define the placement of key AVPs within commands. They are used to do some semantic checking at the protocol layer. For example, a particular AVP might be required to be first in a par- ticular message. This element can define those rules. The requestrules and answerrules elements define the placement of key AVPs within request and answer commands respectively. These elements may be used to perform syntax checking at the protocol layer. Since a command might have different rules for requests and responses, both requestrules and answerrules may be defined. Both elements must have at least one rule if they are defined. Syntax: +----------+----------+-------------+-------------------+ |Attribute | Presence | Constraints | Values | +----------+----------+-------------+-------------------+ | name | Required | Reference | String | +----------+----------+-------------+-------------------+ | | | | first, last, | |position | Required | None | or unspecified | | | | | (default is | | | | | unspecified) | +----------+----------+-------------+-------------------+ | maximum | Required | None | Integer or "none" | +----------+----------+-------------+-------------------+ | minimum | Required | None | Integer | +----------+----------+-------------+-------------------+ Frascone et al. expires November 2003 [Page 8] Internet-Draft March 2003 3.6.1 "name" Attribute This rule applies to the previously defined AVP with the matching "name" attribute. 3.6.2 "position" Attribute The named AVP must be either "first" in the command, "last" in the command, or its position does not matter ("unspecified"). 3.6.3 "maximum" Attribute The "maximum" attribute defines the maximum number of times this AVP can occur in the command. 0 means the AVP MUST not occur in the com- mand. "none" means that there is no limit to the number of times this AVP may be present. 3.6.4 "minimum" Attribute The "minimum" attribute defines the maximum number of times this AVP can occur in the command. 0 means the AVP is optional. 3.7 Type Definition Element The Type Definition element defines a valid Diameter data type. Every attribute value pair definition MUST refer to a type defini- tion. The most common use of this container is to indicate which base type a derived type derives from. This helps the server to know how (and if) an AVP should be displayed. Syntax: Frascone et al. expires November 2003 [Page 9] Internet-Draft March 2003 +------------+----------+-------------+--------+ | Attribute | Presence | Constraints | Values | +------------+----------+-------------+--------+ | type-name | Required | UniqueKey | String | +------------+----------+-------------+--------+ |type-parent | Optional | Reference | String | +------------+----------+-------------+--------+ |description | Optional | None | String | +------------+----------+-------------+--------+ 3.7.1 "type-name" Attribute The attribute, "type-name" contains an ASCII representation of the type. This attribute is of type ID allowing the DTD to enforce its uniqueness across all typedefn elements. This also permits other attributes of type IDREF to refer to the type-name value and have the DTD enforce the referential integrity. 3.7.2 "type-parent" Attribute The "type-parent" attribute is required for all derived types. This attribute is of type IDREF ensuring that its value MUST correspond to the value of a type-name attribute of a pre-defined typedefn element. 3.7.3 "description" Attribute The "description" attribute is an optional attribute describing the type. Typically a human readable description of what the type is used for would be included here. 3.8 Attribute Value Pair Element The avp element completely defines one Attribute Value Pair and is the most frequently used element in the dictionary. The avp element contains either a type element, or a grouped element, and zero or more enum elements together with attributes that completely define the AVP including format and flags. An AVP should only contain enumerations if the type is Unsigned32. Syntax: Frascone et al. expires November 2003 [Page 10] Internet-Draft March 2003 +------------+----------+-------------+--------------------+ | Attribute | Presence | Constraints | Values | +------------+----------+-------------+--------------------+ | name | Required | UniqueKey | String | +------------+----------+-------------+--------------------+ |description | Optional | None | String | +------------+----------+-------------+--------------------+ | code | Required | UniqueKey | Integer | +------------+----------+-------------+--------------------+ |may-encrypt | Optional | None | yes or no | | | | | (default is yes) | +------------+----------+-------------+--------------------+ | | | | must, may, | | mandatory | Optional | None | mustnot, shouldnot | | | | | (default is may) | +------------+----------+-------------+--------------------+ | | | | must, may, | | protected | Optional | None | mustnot, shouldnot | | | | | (default is may) | +------------+----------+-------------+--------------------+ | vendor-id | Optional | Reference | Integer | +------------+----------+-------------+--------------------+ 3.8.1 "name" Attribute The "name" attribute is the mnemonic describing this attribute, for example, "User-Name" 3.8.2 "description" Attribute The "description" attribute is an optional attribute used to describe the use of the AVP. 3.8.3 "code" Attribute The "code" attribute defines the integer value used to encode the AVP for transmission on the network. Frascone et al. expires November 2003 [Page 11] Internet-Draft March 2003 3.8.4 "may-encrypt" Attribute If the "may-encrypt" attribute is "yes", then this AVP will be sent encrypted if the connection uses CMS security. 3.8.5 "mandatory" Attribute The "mandatory" attribute defines whether the mandatory bit of this AVP should or should not be set. 3.8.6 "protected" Attribute The "protected" attribute defines whether the protected bit of this AVP should or should not be set. 3.8.7 "vendor-id" Attribute The "vendor-id" attribute should be set to the "id" attribute of a "vendor" element, if this is a vendor specific AVP. 3.9 Type Element The type element defines the data type of the AVP in which it appears. This element MUST appear in all non-grouped AVP definitions. Syntax: +----------+----------+-------------+--------+ |Attribute | Presence | Constraints | Values | +----------+----------+-------------+--------+ |type-name | Required | UniqueKey | String | +----------+----------+-------------+--------+ 3.9.1 "type-name" attribute The "type-name" attribute contains the data type name. This attribute is of type IDREF and MUST refer to the "type-name" value of a previ- ously defined "typedefn" element. 3.10 Grouped AVPs Element Frascone et al. expires November 2003 [Page 12] Internet-Draft March 2003 The grouped element is used define an AVP which encapsulates a sequence of AVPs together as a single payload. A "grouped" element consists of one or more "gavp" elements. Each "gavp" element holds an avp "name" and "vendor-id". This way, a sin- gle "grouped" element can contain references to multiple AVPs. Syntax: +----------+----------+-------------+---------+ |Attribute | Presence | Constraints | Values | +----------+----------+-------------+---------+ | name | Required | UniqueKey | String | +----------+----------+-------------+---------+ |vendor-id | Optional | Reference | Integer | +----------+----------+-------------+---------+ 3.10.1 "name" Attribute The "name" attribute MUST correspond to some existing AVP's "name" attribute. 3.10.2 "vendor-id" Attribute If this "gavp" element refers to a vendor specific AVP, then the "vendor-id" attribute MUST correspond to a Vendor's "id" attribute. 3.11 Enumerated Element The enum element defines a name to value mapping for use in encoding and decoding AVPs of type Unsigned32. For example, if a particular AVP had two values, Yes and No corre- sponding to 1 and 0, then the entry would look like this: Frascone et al. expires November 2003 [Page 13] Internet-Draft March 2003 Enumerated elements should only be used with Unsigned32 typed AVPs. Syntax: +----------+----------+-------------+---------+ |Attribute | Presence | Constraints | Values | +----------+----------+-------------+---------+ | name | Required | None | String | +----------+----------+-------------+---------+ | code | Required | None | Integer | +----------+----------+-------------+---------+ 3.11.1 "name" Attribute The "name" attribute is the text corresponding to a particular value for the attribute. 3.11.3 "code" Attribute The "code" attribute is the Unsigned32 value corresponding to this enumerated value. 4.0 References [1] Calhoun, P., et. al., "The DIAMETER Base Protocol," draft- ietf- aaa-diameter-08.txt, a work in progress. [2] "Extensible Markup Language (XML) 1.0" W3C Recommendation 10-February-1998 http://www.w3.org/TR/1998/REC-xml-19980210 [3] Bradner, S., "Key words for use in RFCs to Indicate Require- ment Levels", BCP 14, RFC 2119, March 1997. [4] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2, RFC 1700, October 1994. 5.0 Acknowledgments The authors would like to thank Brian Cain for his proposal for the Frascone et al. expires November 2003 [Page 14] Internet-Draft March 2003 command element definition. 6.0 Authors' Addresses Questions about this memo can be directed to: David Frascone Airespace 605 N. Frances Street Terrell, Texas 75160 USA Phone: +1 972-524-6346 Fax: +1 978-334-0249 E-mail: codemonkey@airespace.com Mark Jones Bridgewater Systems 303 Terry Fox Drive, Suite 100, Kanata, Ontario. K2K 3J1 Canada Phone: +1 613-591-6655 Fax: +1 613-591-6656 E-mail: mjones@bridgewatersystems.com Erik Guttman Sun Microsystems, Inc. Eichhoelzelstr. 7 74914 Waibstadt Germany Phone: +49 6227 356 202 Fax: +49 7263 911 701 E-mail: Erik.Guttman@sun.com Frascone et al. expires November 2003 [Page 15] Internet-Draft March 2003 Appendix A. Document Type Definition Frascone et al. expires November 2003 [Page 16] Internet-Draft March 2003 Frascone et al. expires November 2003 [Page 17] Internet-Draft March 2003 Frascone et al. expires November 2003 [Page 19] Internet-Draft March 2003 Appendix B. DTD & Dictionary Links DTD: http://www.diameter.org/diameter/dictionary.dtd dictionary: http://www.diameter.org/diameter/dictionary.xml http://www.diameter.org/diameter/nasreq.xml http://www.diameter.org/diameter/mobileipv4.xml http://www.diameter.org/diameter/sunping.xml Frascone et al. expires November 2003 [Page 20] --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dictionary.dtd" --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dictionary.xml" ]> &nasreq; &mobileipv4; &sunping; --XsQoSWH+UP9D9v3l-- From aaa-admin@ietf.org Wed Mar 31 09:40:25 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 JAA24190 for ; Wed, 31 Mar 2004 09:40:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8grt-0000lK-7v; Wed, 31 Mar 2004 09: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 1B8gqt-0000dF-RU for aaa@optimus.ietf.org; Wed, 31 Mar 2004 09:38: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 JAA24107 for ; Wed, 31 Mar 2004 09:37:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8gqs-00023q-00 for aaa@ietf.org; Wed, 31 Mar 2004 09:37:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8gpr-00021M-00 for aaa@ietf.org; Wed, 31 Mar 2004 09:36:56 -0500 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1B8gp6-0001xD-00 for aaa@ietf.org; Wed, 31 Mar 2004 09:36:08 -0500 Received: from exchange1.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Wed, 31 Mar 2004 15:30:09 +0200 Received: by exchange1.bonn.de with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Mar 2004 16:34:42 +0200 Message-ID: <1C2329C9430609409808ECF102372876F199A8@sv3752.bonn.de> From: Systemadministrator To: aaa@ietf.org Date: Wed, 31 Mar 2004 16:34:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C4172D.4DB56B1E" 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: hi 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_01C4172D.4DB56B1E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: bdp@bonn.de Subject: hi Sent: Wed, 31 Mar 2004 16:15:34 +0200 did not reach the following recipient(s): bdp@bonn.de on Wed, 31 Mar 2004 16:35:49 +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=3DSV37520403311435H4HB7T03 MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C4172D.4DB56B1E Content-Type: message/rfc822 From: aaa@ietf.org To: bdp@bonn.de Subject: hi Date: Wed, 31 Mar 2004 16:15: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_01C4172D.4DB56B1E" ------_=_NextPart_002_01C4172D.4DB56B1E Content-Type: text/plain; charset="iso-8859-1" something is going wrong ------_=_NextPart_002_01C4172D.4DB56B1E 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.txt.scr 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_01C4172D.4DB56B1E-- ------_=_NextPart_000_01C4172D.4DB56B1E-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Wed Mar 31 09:42:25 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 JAA24298 for ; Wed, 31 Mar 2004 09:42:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8guk-0000ur-8N for aaa-archive@odin.ietf.org; Wed, 31 Mar 2004 09:41:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VEfwwf003521 for aaa-archive@odin.ietf.org; Wed, 31 Mar 2004 09:41:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8guk-0000uh-1h for aaa-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 09:41: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 JAA24263 for ; Wed, 31 Mar 2004 09:41:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8gui-0002KM-00 for aaa-web-archive@ietf.org; Wed, 31 Mar 2004 09:41:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8gtn-0002F3-00 for aaa-web-archive@ietf.org; Wed, 31 Mar 2004 09:41:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8gsm-0002CQ-00 for aaa-web-archive@ietf.org; Wed, 31 Mar 2004 09:39:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8grt-0000lK-7v; Wed, 31 Mar 2004 09: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 1B8gqt-0000dF-RU for aaa@optimus.ietf.org; Wed, 31 Mar 2004 09:38: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 JAA24107 for ; Wed, 31 Mar 2004 09:37:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8gqs-00023q-00 for aaa@ietf.org; Wed, 31 Mar 2004 09:37:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8gpr-00021M-00 for aaa@ietf.org; Wed, 31 Mar 2004 09:36:56 -0500 Received: from bonngw.bonn.de ([212.79.173.52]) by ietf-mx with smtp (Exim 4.12) id 1B8gp6-0001xD-00 for aaa@ietf.org; Wed, 31 Mar 2004 09:36:08 -0500 Received: from exchange1.bonn.de by bonngw.bonn.de via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Wed, 31 Mar 2004 15:30:09 +0200 Received: by exchange1.bonn.de with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Mar 2004 16:34:42 +0200 Message-ID: <1C2329C9430609409808ECF102372876F199A8@sv3752.bonn.de> From: Systemadministrator To: aaa@ietf.org Date: Wed, 31 Mar 2004 16:34:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C4172D.4DB56B1E" Subject: [Aaa] Unzustellbar: hi 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_01C4172D.4DB56B1E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your message To: bdp@bonn.de Subject: hi Sent: Wed, 31 Mar 2004 16:15:34 +0200 did not reach the following recipient(s): bdp@bonn.de on Wed, 31 Mar 2004 16:35:49 +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=3DSV37520403311435H4HB7T03 MSEXCH:IMS:Bundesstadt Bonn:BONN:SV3752 0 (000C05A6) Unbekannter Empf=E4nger ------_=_NextPart_000_01C4172D.4DB56B1E Content-Type: message/rfc822 From: aaa@ietf.org To: bdp@bonn.de Subject: hi Date: Wed, 31 Mar 2004 16:15: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_01C4172D.4DB56B1E" ------_=_NextPart_002_01C4172D.4DB56B1E Content-Type: text/plain; charset="iso-8859-1" something is going wrong ------_=_NextPart_002_01C4172D.4DB56B1E 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.txt.scr 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_01C4172D.4DB56B1E-- ------_=_NextPart_000_01C4172D.4DB56B1E-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Wed Mar 31 20:53:46 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 UAA26290 for ; Wed, 31 Mar 2004 20:53:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3B8A591297; Wed, 31 Mar 2004 20:53:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04FEA91299; Wed, 31 Mar 2004 20:53:32 -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 B256B91297 for ; Wed, 31 Mar 2004 20:53:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9BB5F58728; Wed, 31 Mar 2004 20:53:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by segue.merit.edu (Postfix) with ESMTP id 1095158868 for ; Wed, 31 Mar 2004 20:53:31 -0500 (EST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i311rNBB002077; Wed, 31 Mar 2004 17:53:23 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.216.126]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 31 Mar 2004 17:59:54 -0800 From: "Joseph Salowey" To: , Subject: [AAA-WG]: RE: Proposed resolution of EAP issue 461: Alternate Uses and Conflicting AVPs Date: Wed, 31 Mar 2004 17:53:20 -0800 Message-ID: <007201c4178c$1d355030$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61223B0@esebe023.ntc.nokia.com> Importance: Normal X-OriginalArrivalTime: 01 Apr 2004 01:59:55.0175 (UTC) FILETIME=[0731D370:01C4178D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Pasi.Eronen@nokia.com wrote: >>> I think the "MUST NOT modify EAP messages" part is more important; >>> that's essentially attempting a man-in-the-middle attack against the >>> protocol, and many EAP methods have e.g. method-specific result >>> indications that prevent this from even working. >>=20 >> [Joe] It sounds like you are arguing for not allowing an intermediary >> to change and authorization decision. The basic problem is that an >> EAP authentication decision in not necessarily an authorization >> decision. By enforcing no conflicts and no modifications we make >> successful authentication equivalent to successful authorization. >> I do not think this is so good. >>=20 >> Perhaps authenticate and authorize functionality should only be used >> in cases where the authentication decision is equivalent to >> authorization. In other cases two separate authentication followed >> by authorization messages should be used. >=20 > I agree, EAP success/failure and Diameter success/failure > Result-Code are two separate things. I'm proposing that we > enforce the "no modifications to EAP messages" part, > but allow conflicting messages with a note explaining > why they may cause problems (this is what RFC3579 also does). >=20 > A separate Diameter AUTHORIZE_ONLY exchange doesn't really > help here, because the NAS does not have any conflicts about > what to do (it's not supposed to look inside the EAP packet). > What is really missing is a secure way to notify the client > that "EAP went OK, but I decided anyway not to give you > access". For instance, the 802.11i four-way handshake could > have had some field denoting "authorization failed" (which > would be protected with keys derived from PMK). >=20 [Joe] yes, I agree I agree about the authorize only. I'm not as strict = on modifications to EAP-Success and EAP-Failures. >>> Other than that, it's IMHO enough to say that "there are >>> circumstances where conflicting messages can't be avoided, but you >>> should be aware that it causes some problems". I don't think we have >>> to solve these problem in this document; neither does RFC3579... >>=20 >> [Joe] Maybe, but how does this work in 802.1x case if AAA >> rejects, but EAP indicates success? If we don't solve it >> here then where do we solve it? >=20 > Since we don't have a protected "authorization failure" > exchange between the client and NAS, we seem to be stuck with > either attempting MitM attack against EAP, or sending > conflicting messages. Both usually lead to the same > situation: a timeout before the client discovers that it > didn't actually get access. >=20 > In 802.11i, it seems the timeout for conflicting messages > isn't necessarily that long. The client is expecting the > first message of four-way handshake; the default > retransmission timeout is 100 ms, and the default number of > retransmissions is 3. Therefore, if the client doesn't receive > something in, say, one second after EAP Success, it could deduce that > something went wrong...=20 >=20 > (If the NAS or proxy changes the EAP Success to Failure, and > the client ignores the Failure message because it had > contradicting method-specific indication, it seems the > timeout would have to be much longer than this.) >=20 > In plain 802.1X for e.g. wired Ethernet switch ports the > timeout could be longer, sure (no response to any ARP or DHCP > messages). But IMHO this is not something that absolutely > needs to be solved... (and the successor of 802.1X/11i looks > like a more logical place to solve this than Diameter EAP spec). >=20 [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. =20 When used with lower layers that treat authentication as sufficient=20 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=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. 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. " =20 > Best regards, > Pasi

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

     
  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

     



    Confidentiality assured!
     

    W= e are located in USA  international= callers are very welcome