From owner-aaa-wg@merit.edu Fri Jul 2 13:28: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 NAA21772 for ; Fri, 2 Jul 2004 13:28:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B4E8991259; Fri, 2 Jul 2004 13:27:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 887D89131B; Fri, 2 Jul 2004 13:27:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 540C291259 for ; Fri, 2 Jul 2004 13:27:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3F5035A71D; Fri, 2 Jul 2004 13:27:58 -0400 (EDT) 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 F22E55A75E for ; Fri, 2 Jul 2004 13:27:57 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Jul 2004 10:33:11 +0000 X-BrightmailFiltered: true Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i62HRpSc016223 for ; Fri, 2 Jul 2004 10:27:52 -0700 (PDT) Received: from gwzw2k (sjc-vpn2-587.cisco.com [10.21.114.75]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id KAA05466 for ; Fri, 2 Jul 2004 10:27:50 -0700 (PDT) Reply-To: From: "Glen Zorn" To: Date: Fri, 2 Jul 2004 10:27:17 -0700 Organization: Cisco Systems Message-ID: <010501c46059$e50ce580$0202a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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.2800.1106 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Description of issue: No guarantee of interoperability between CCA = implementations Submitter name: Glen Zorn Submitter email address: gwz@cisco.com=20 Date first submitted: 2 July 2004=20 Document: dcca=20 Comment type: T Priority: S Section: 4.1 Rationale/Explanation of issue:=20 In order to interoperate, Diameter peers implementing the=20 Diameter Credit Control Application must agree upon both the application = and the service (specified in the Service-Identifier AVP). However, the = inclusion of the Service-Identifier in the CCR and CCA messages is = optional. Lengthy description of problem: Section 4.1, para. 6 states "it is the combination of support of the = Diameter Credit Control Application and the service defined in the = Service-Identifier AVP, which defines interoperability between any given = credit control client and server." However, the inclusion of the = Service-Identifier in the CCR and CCA messages is optional. This gives = rise to a situation where two peers implementing the same application = may not interoperate because they do not implement the same "service", = and further, refuse to clearly communicate that fact. Requested change:=20 Change section 4.1, paragraph 5 from This specification, together with service specific documents, is=20 governing the credit control message. The rule is that service=20 specific documents only define what existing AVPs or new AVPs are=20 used as input to the rating process (i.e. they do not define new=20 credit control applications), and thus need to be included in the=20 Credit-Control-Request command by a Diameter Credit Control Client=20 supporting a given service as *[AVP]. In order to define new AVPs,=20 service specific documents MUST follow the practices defined in=20 [DIAMBASE]. The service SHOULD be identified using the Service-=20 Identifier AVP. The Service-Identifier AVP MUST be a unique=20 identifier for a given service as defined in section 8.28.=20 to This specification, together with service specific documents, is=20 governing the credit control message. The rule is that service=20 specific documents only define what existing AVPs or new AVPs are=20 used as input to the rating process (i.e. they do not define new=20 credit control applications), and thus need to be included in the=20 Credit-Control-Request command by a Diameter Credit Control Client=20 supporting a given service as *[AVP]. In order to define new AVPs,=20 service specific documents MUST follow the practices defined in=20 [DIAMBASE]. The service MUST be identified using the Service-=20 Identifier AVP. The Service-Identifier AVP MUST be a unique=20 identifier for a given service as defined in section 8.28.=20 ~gwz "They that can give up essential liberty to obtain a little temporary = safety deserve neither..." -- Benjamin Franklin, 1759=20 "It is forbidden to kill; therefore all murderers are punished unless = they kill in large numbers and to the sound of trumpets." -- Voltaire From owner-aaa-wg@merit.edu Fri Jul 2 14:26: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 OAA26345 for ; Fri, 2 Jul 2004 14:26:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 15A9791258; Fri, 2 Jul 2004 14:26:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE89B9131F; Fri, 2 Jul 2004 14:26:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BC90E91258 for ; Fri, 2 Jul 2004 14:26:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A5E015A75A; Fri, 2 Jul 2004 14:26:36 -0400 (EDT) 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 526935A7A2 for ; Fri, 2 Jul 2004 14:26:36 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 02 Jul 2004 11:31:52 +0000 X-BrightmailFiltered: true Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i62IQX4N029467 for ; Fri, 2 Jul 2004 11:26:33 -0700 (PDT) Received: from gwzw2k (sjc-vpn2-587.cisco.com [10.21.114.75]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id LAA15135 for ; Fri, 2 Jul 2004 11:26:32 -0700 (PDT) Reply-To: From: "Glen Zorn" To: Subject: [AAA-WG]: Issue with draft-ietf-aaa-diameter-cc-05.txt Date: Fri, 2 Jul 2004 11:25:59 -0700 Organization: Cisco Systems Message-ID: <012401c46062$181a1300$0202a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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.2800.1106 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Description of issue: No advertisement of service type in CER/CEA=20 Submitter name: Glen Zorn Submitter email address: gwz@cisco.com Date first submitted: 2 July 2004 Document: cca Comment type: T Priority: S=20 Section: 1.3 Rationale/Explanation of issue: The Service-Identifier AVP is not = included in the CER/CEA messages. Lengthy description of problem: Section 4.1, para. 6 states "it is the combination of support of the = Diameter Credit Control Application and the service defined in the = Service-Identifier AVP, which defines interoperability between any given = credit control client and server." However, inclusion of the = Session-Identifier AVP in the CER/CEA exchange is not mandated. This = could lead to a situation where peers have successfully negotiated = application support, but cannot interoperate.=20 Requested change:=20 Change section 1.3 from Diameter nodes conforming to this specification MUST advertise=20 support by including the value of 4 in the Auth-Application-Id of the = Capabilities-Exchange-Request and Capabilities-Exchange-Answer=20 command [DIAMBASE]. =20 to Diameter nodes conforming to this specification MUST advertise=20 support by including one or more Session-Identifier AVPs = (corresponding to the supported=20 services) and setting the value of 4 in the Auth-Application-Id of = the=20 Capabilities-Exchange-Request and Capabilities-Exchange-Answer = command [DIAMBASE]. =20 Add Section 10.3: 10.3 Capabilities-Exchange-Request/Answer AVP Table=20 =20 This section defines AVPs that are specific to Diameter Credit =20 Control Application and MUST be included in the Diameter=20 Capabilities-Exchange-Request/Answer (CER/CEA) message [DIAMBASE]. =20 =20 The Capabilities-Exchange-Request/Answer commands MUST include the=20 following additional AVPs:=20 =20 +---------------+ =20 | Command Code | =20 |-------+-------+ =20 Attribute Name | CER | CEA | =20 ------------------------------+-------+-------+ =20 Service-Identifier | 1+ | 1+ |=20 ------------------------------+-------+-------+=20 ~gwz "They that can give up essential liberty to obtain a little temporary = safety deserve neither..." -- Benjamin Franklin, 1759=20 "It is forbidden to kill; therefore all murderers are punished unless = they kill in large numbers and to the sound of trumpets." -- Voltaire From owner-aaa-wg@merit.edu Fri Jul 2 15: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 PAA29333 for ; Fri, 2 Jul 2004 15:05:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6AAA49125A; Fri, 2 Jul 2004 15:04:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 321FF91321; Fri, 2 Jul 2004 15:04:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C01A9125A for ; Fri, 2 Jul 2004 15:04:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 04FF45A5FF; Fri, 2 Jul 2004 15:04:53 -0400 (EDT) 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 B6C705A54B for ; Fri, 2 Jul 2004 15:04:52 -0400 (EDT) X-BrightmailFiltered: true Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i62Iu4Rs026413; Fri, 2 Jul 2004 11:56:04 -0700 (PDT) Received: from gwzw2k (sjc-vpn2-587.cisco.com [10.21.114.75]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id LAA03116; Fri, 2 Jul 2004 11:56:03 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "'Bernard Aboba'" , "'Christopher Richards'" Cc: , , Subject: RE: [AAA-WG]: Application IDs for EAP Date: Fri, 2 Jul 2004 11:55:30 -0700 Organization: Cisco Systems Message-ID: <012901c46066$37d149d0$0202a8c0@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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba writes: ... > RFC 3588 is very explicit on this point -- new application IDs can > only be used if the command is fundamentally changed, such as by > changing the round-trips, or adding a new mandatory AVP. Otherwise > the existing command definition (and application ID) is used. Doing > anything else breaks Diameter interoperability. However, by defining the Service-Identifier AVP as a kind of qualifier for the application ID draft-ietf-aaa-diameter-cc-05.txt allows the definition of new service-specific (and even vendor-specific) mandatory AVPs while continuing to use the CC app ID. Hope this helps, ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire From owner-aaa-wg@merit.edu Sun Jul 4 10:16: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 KAA15619 for ; Sun, 4 Jul 2004 10:16:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 724A39121F; Sun, 4 Jul 2004 10:15:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 239169122C; Sun, 4 Jul 2004 10:15:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D8E839121F for ; Sun, 4 Jul 2004 10:15:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 501FD5AD47; Sun, 4 Jul 2004 10:15:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 514905AD36 for ; Sun, 4 Jul 2004 10:15:32 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i64EEPq06154 for ; Sun, 4 Jul 2004 07:14:26 -0700 Date: Sun, 4 Jul 2004 07:14:25 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: QoS-Filter-Rule AVP missing in NASREQ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk RFC 3588 defines a QoS Filter Rule syntax in Section 4.3. My understanding was that this syntax was to be used by the QoS-Filter-Rule AVP in NASREQ. Among other things, the need for QoS filters was described in the original AAA and NASREQ requirements documents. Did this AVP somehow get lost on the cutting room floor? From owner-aaa-wg@merit.edu Sun Jul 4 12:25: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 MAA21258 for ; Sun, 4 Jul 2004 12:25:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F06589123B; Sun, 4 Jul 2004 12:24:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C01C39123C; Sun, 4 Jul 2004 12:24:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 979669123B for ; Sun, 4 Jul 2004 12:24:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 85C7F5AD6C; Sun, 4 Jul 2004 12:24:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 944075AD6B for ; Sun, 4 Jul 2004 12:24:50 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i64GOg620203; Sun, 4 Jul 2004 19:24:42 +0300 (EET DST) X-Scanned: Sun, 4 Jul 2004 19:24:35 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i64GOZfU011720; Sun, 4 Jul 2004 19:24:35 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00J4rAzV; Sun, 04 Jul 2004 19:24:34 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i64GOXH13978; Sun, 4 Jul 2004 19:24:33 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 4 Jul 2004 19:24:31 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: QoS-Filter-Rule AVP missing in NASREQ? Date: Sun, 4 Jul 2004 19:24:30 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C12C@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: QoS-Filter-Rule AVP missing in NASREQ? Thread-Index: AcRh0Y3YF3uFtWkkQBCW4iA2tITudgAD1NsA From: To: , X-OriginalArrivalTime: 04 Jul 2004 16:24:31.0343 (UTC) FILETIME=[62A15FF0:01C461E3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Bernard Aboba wrote: >=20 > RFC 3588 defines a QoS Filter Rule syntax in Section 4.3. My > understanding was that this syntax was to be used by the > QoS-Filter-Rule AVP in NASREQ. Among other things, the need for=20 > QoS filters was described in the original AAA and NASREQ=20 > requirements documents. >=20 > Did this AVP somehow get lost on the cutting room floor? It's not present in any version of NASREQ (00..16). Perhaps it could be left to a separate document? There has been some discussion at RADIUSEXT about the "bandwidth" attributes that provide a subset of the QoSFilterRule functionality; I'm wondering if that subset would be sufficient for many cases...? BTW, as I mentioned on the RADIUSEXT mailing list a while ago,=20 some parts of the QoSFilterRule syntax got lost somewhere in=20 the process, too. Perhaps the missing text (salvaged from=20 BASE -09) should be filed as an errata issue for RFC3588? DSCP color values as defined in [DIFFSERV]. Exact matching of DSCP values is required (no masks or ranges). metering The metering option provides Assured Forwarding, as defined in [DIFFSERVAF], and MUST be present if the action is set to meter. The rate option is the throughput, in bits per second, which is used by the access device to mark packets. Traffic above the rate is marked with the color_over codepoint, while traffic under the rate is marked with the color_under codepoint. The color_under and color_over options contain the drop preferences, and MUST conform to the recommended codepoint keywords described in [DIFFSERVAF] (e.g. AF13). The metering option also supports the strict limit on traffic required by Expedited Forwarding, as defined in [DIFFSERVEF]. The color_over option may contain the keyword "drop" to prevent forwarding of traffic that exceeds the rate parameter. Best regards, Pasi From owner-aaa-wg@merit.edu Sun Jul 4 12:42: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 MAA21910 for ; Sun, 4 Jul 2004 12:42:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 98E8C9123C; Sun, 4 Jul 2004 12:42:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6EA849123E; Sun, 4 Jul 2004 12:42:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7F1D49123C for ; Sun, 4 Jul 2004 12:42:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 62BD75AD5F; Sun, 4 Jul 2004 12:42:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id DA80F5AD5B for ; Sun, 4 Jul 2004 12:42:21 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i64GfCN14621; Sun, 4 Jul 2004 09:41:12 -0700 Date: Sun, 4 Jul 2004 09:41:12 -0700 (PDT) From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: QoS-Filter-Rule AVP missing in NASREQ? In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A60227C12C@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A60227C12C@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > Did this AVP somehow get lost on the cutting room floor? > > It's not present in any version of NASREQ (00..16). > > Perhaps it could be left to a separate document? I'm not sure this is possible, because it would probably have to be a mandatory AVP, and addition of mandatory AVPs to an existing application requires defining a new Application-Id, which would break compatibility with the existing NASREQ Application. For that reason, I'd prefer if this AVP were to be defined in NASREQ. This might also allow us to address the issue of the missing text. From owner-aaa-wg@merit.edu Mon Jul 5 02:15: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 CAA07517 for ; Mon, 5 Jul 2004 02:15:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 303D791205; Mon, 5 Jul 2004 02:15:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E46E91206; Mon, 5 Jul 2004 02:15:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4BE9691205 for ; Mon, 5 Jul 2004 02:15:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 89C0759EAD; Mon, 5 Jul 2004 02:15:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 944E45ADAE for ; Mon, 5 Jul 2004 02:15:07 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 436EE8983B; Mon, 5 Jul 2004 09:14:47 +0300 (EEST) Message-ID: <40E8F0B7.60507@kolumbus.fi> Date: Mon, 05 Jul 2004 09:09:59 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: QoS-Filter-Rule AVP missing in NASREQ? References: <052E0C61B69C3741AFA5FE88ACC775A60227C12C@esebe023.ntc.nokia.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > For that reason, I'd prefer if this AVP were to be defined in NASREQ. Yes. > This might also allow us to address the issue of the missing text. Do we remember why the missing text was taken away? --Jari From owner-aaa-wg@merit.edu Mon Jul 5 04:11: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 EAA13315 for ; Mon, 5 Jul 2004 04:11:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE36391206; Mon, 5 Jul 2004 04:10:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7FEE591207; Mon, 5 Jul 2004 04:10:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D058491206 for ; Mon, 5 Jul 2004 04:10:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B99855A2C7; Mon, 5 Jul 2004 04:10:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 9F7A559E3E for ; Mon, 5 Jul 2004 04:10:48 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i658Ag208431; Mon, 5 Jul 2004 11:10:42 +0300 (EET DST) X-Scanned: Mon, 5 Jul 2004 11:10:04 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i658A432030435; Mon, 5 Jul 2004 11:10:04 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00hycltI; Mon, 05 Jul 2004 11:10:03 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i658A3H01850; Mon, 5 Jul 2004 11:10:03 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Jul 2004 11:09:11 +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="utf-8" Content-Transfer-Encoding: base64 Subject: [AAA-WG]: RE: Date: Mon, 5 Jul 2004 11:09:12 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B05B2@esebe016.ntc.nokia.com> Thread-Index: AcRgWhMEq9nFOYtjTEWhJaIUMzBhpwCCmknw From: To: Cc: X-OriginalArrivalTime: 05 Jul 2004 08:09:11.0519 (UTC) FILETIME=[5AA5DEF0:01C46267] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: base64 R2xlbiwNCg0KdGhlIFNlcnZpY2UtSWQgaXMgb25seSBpbmNsdWRlZCBpbiBDQ1IgbWVzc2FnZSAo YXQgY29tbWFuZCBsZXZlbCkgdG8gaW5kaWNhdGUgDQp0byB0aGUgc2VydmVyIGZvciB3aGF0IHNw ZWNpZmljIHNlcnZpY2UgdGhlIHJlcXVlc3QgaXMgYmVpbmcgaXNzdWVkLg0KVGhlIHNlcnZlciBj aGVja3MgZmlyc3QgdGhlIFNlcnZpY2UtSWQgQVZQIGFuZCwgaWYgaXQgZG9lc24ndCByZWNvZ25p emUNCnRoZSB2YWx1ZSBvZiB0aGlzIEFWUCwgaXQgcmVqZWN0cyB0aGUgcmVxdWVzdCB3aXRob3V0 IGFueSBmdXJ0aGVyIHByb2Nlc3NpbmcNCihlLmcuIHJhdGluZyBvciB3aGF0IHNvIGV2ZXIpLiBJ ZiB0aGUgc2VydmVyIHJlY29nbml6ZXMgdGhlIHZhbHVlIG9mIHRoZQ0KU2VydmljZS1JZCBBVlAs IGl0IGNvbnRpbnVlcyB0aGUgcHJvY2Vzc2luZyBhbmQgYXV0aG9yaXplcyB0aGUgY3JlZGl0IGlm DQpwb3NzaWJsZSAoaS5lLiBpZiB0aGVyZSBpcyBlbm91Z2ggY3JlZGl0IGluIHRoZSB1c2VyJ3Mg YWNjb3VudCkuICANCg0KVGhlIHNlY3Rpb24gNC4xIGhhcyBiZWVuIHJlc3RydWN0dXJlZCBvbiBy ZXF1ZXN0IG9mIElFU0cgcmV2aWV3IGFzIGZvbGxvdywgdGhlDQppbmNsdXNpb24gb2YgdGhlIFNl cnZpY2UtSWQgaW4gQ0NSIGlzIG1hbmRhdG9yeS4NCg0KV2hlbmV2ZXIgdGhlIElFU0cgYW5kIHRo ZSBBRHMgd2lsbCBhZ3JlZSB0aGF0IHRoZWlyIGNvbW1lbnRzIGhhdmUgYmVlbiBwcm9wZXJseQ0K YWRkcmVzc2VkLCB0aGUgZHJhZnQgMDYgd2lsbCBiZSBjYXJyaWVkIG91dCBhbmQgbWFkZSBhdmFp bGFibGUuDQoNClJlZ2FyZHMNCk1hcmNvIA0KDQo0LjEgU2VydmljZS1TcGVjaWZpYyBSYXRpbmcg SW5wdXQgYW5kIEludGVyb3BlcmFiaWxpdHkgDQogICAgDQogICBUaGUgRGlhbWV0ZXIgQ3JlZGl0 LUNvbnRyb2wgQXBwbGljYXRpb24gZGVmaW5lcyB0aGUgZnJhbWV3b3JrIGZvciBjcmVkaXQgDQog ICBjb250cm9sOyBpdCBwcm92aWRlcyBnZW5lcmljIGNyZWRpdCBjb250cm9sIG1lY2hhbmlzbXMg c3VwcG9ydGluZyBtdWx0aXBsZSANCiAgIHNlcnZpY2UgYXBwbGljYXRpb25zLiBUaGUgQ3JlZGl0 IENvbnRyb2wgQXBwbGljYXRpb24sIHRoZXJlZm9yZSwgZG9lcyBub3QgDQogICBkZWZpbmUgQVZQ cyB0aGF0IGNvdWxkIGJlIHVzZWQgYXMgaW5wdXQgaW4gdGhlIHJhdGluZyBwcm9jZXNzLiBMaXN0 aW5nIHRoZSANCiAgIHBvc3NpYmxlIHNlcnZpY2VzIHRoYXQgY291bGQgdXNlIHRoaXMgRGlhbWV0 ZXIgYXBwbGljYXRpb24gaXMgc2VlbiBhcyBvdXQgDQogICBvZiBzY29wZSBmb3IgdGhpcyBnZW5l cmljIG1lY2hhbmlzbSBhcyB3ZWxsLiAgDQogICAgDQogICBGdXJ0aGVybW9yZSwgaXQgaXMgcmVh c29uYWJsZSB0byBleHBlY3QgdGhhdCB0aGVyZSB3aWxsIGV4aXN0IGEgc2VydmljZSANCiAgIGxl dmVsIGFncmVlbWVudCBiZXR3ZWVuIHByb3ZpZGVycyBvZiB0aGUgY3JlZGl0LWNvbnRyb2wgY2xp ZW50IGFuZCB0aGUgDQogICBjcmVkaXQtY29udHJvbCBzZXJ2ZXIgY292ZXJpbmcgdGhlIGNoYXJn aW5nLCBzZXJ2aWNlcyBvZmZlcmVkLCByb2FtaW5nIA0KICAgYWdyZWVtZW50cywgYWdyZWVkIHJh dGluZyBpbnB1dCAoaS5lLiBBVlBzKSwgZXRjLiANCg0KICAgVGhlcmVmb3JlLCBpdCBpcyBhc3N1 bWVkIHRoYXQgYSBEaWFtZXRlciBjcmVkaXQgY29udHJvbCBzZXJ2ZXIgd2lsbCANCiAgIHByb3Zp ZGUgc2VydmljZSBvbmx5IGZvciBEaWFtZXRlciBjcmVkaXQtY29udHJvbCBjbGllbnRzIHRoYXQg aGF2ZSBhZ3JlZWQgDQogICBiZWZvcmVoYW5kIHRoZSBjb250ZW50IG9mIGNyZWRpdCBjb250cm9s IG1lc3NhZ2VzLiBQcm90b2NvbCB3aXNlLCBpdCBpcyANCiAgIG5hdHVyYWxseSBwb3NzaWJsZSB0 aGF0IGFueSBhcmJpdHJhcnkgRGlhbWV0ZXIgY3JlZGl0LWNvbnRyb2wgY2xpZW50IGNhbiANCiAg IGludGVyY2hhbmdlIGNyZWRpdCBjb250cm9sIG1lc3NhZ2VzIHdpdGggYW55IERpYW1ldGVyIGNy ZWRpdCBjb250cm9sIA0KICAgc2VydmVyLCBidXQgd2l0aCBhIGhpZ2hlciBsaWtlbGlob29kIHRo YXQgdW5zdXBwb3J0ZWQgc2VydmljZXMvQVZQcyBjb3VsZCANCiAgIGJlIHByZXNlbnQgaW4gdGhl IGNyZWRpdC1jb250cm9sIG1lc3NhZ2UgY2F1c2luZyB0aGUgc2VydmVyIHRvIHJlamVjdCB0aGUg DQogICByZXF1ZXN0IHdpdGggYW4gYXBwcm9wcmlhdGUgcmVzdWx0LWNvZGUuIA0KICAgIA0KNC4x LjEgU3BlY2lmeWluZyBSYXRpbmcgSW5wdXQgQVZQcyANCiAgICANCiAgIFRoZXJlIGFyZSB0d28g d2F5cyBmb3IgcHJvdmlkaW5nIHJhdGluZyBpbnB1dCB0byB0aGUgY3JlZGl0IGNvbnRyb2wgDQog ICBzZXJ2ZXIsIGVpdGhlciBieSB1c2luZyBBVlBzIG9yIGJ5IGluY2x1ZGluZyB0aGVtIGluIHRo ZSBTZXJ2aWNlLQ0KICAgUGFyYW1ldGVyLUluZm8gQVZQLiBUaGUgZ2VuZXJhbCBwcmluY2lwbGVz IGZvciBzZW5kaW5nIHJhdGluZyBwYXJhbWV0ZXJzIA0KICAgYXJlOiANCiAgICANCiAgIDFhLiBU aGUgc2VydmljZSBTSE9VTEQgcmUtdXNlIGV4aXN0aW5nIEFWUHMsIGlmIHRoZSBzZXJ2aWNlIGNh biB1c2UgQVZQcyANCiAgICAgICBkZWZpbmVkIGluIGV4aXN0aW5nIERpYW1ldGVyIGFwcGxpY2F0 aW9ucyAoZS5nLiBOQVNSRVEgZm9yIG5ldHdvcmsgDQogICAgICAgYWNjZXNzIHNlcnZpY2VzKS4g UmUtdXNlIG9mIGV4aXN0aW5nIEFWUHMgaXMgc3Ryb25nbHkgcmVjb21tZW5kZWQgaW4gDQogICAg ICAgW0RJQU1CQVNFXS4gDQoNCiAgICAgICBGb3IgQVZQcyBvZiB0eXBlIEVudW1lcmF0ZWQgdGhl IHNlcnZpY2UgbWF5IHJlcXVpcmUgYSBuZXcgdmFsdWUgdG8gYmUgDQogICAgICAgZGVmaW5lZC4g QWxsb2NhdGlvbiBvZiBuZXcgQVZQIHZhbHVlcyBpcyBkb25lIGFzIHNwZWNpZmllZCBpbiANCiAg ICAgICBbRElBTUJBU0VdLCBzZWN0aW9uIDEuMi4gDQogICAgDQogICAxYi4gTmV3IEFWUHMgY2Fu IGJlIGRlZmluZWQgaWYgdGhlIGV4aXN0aW5nIEFWUHMgZG8gbm90IHByb3ZpZGUgc3VmZmljaWVu dCANCiAgICAgICByYXRpbmcgaW5mb3JtYXRpb24uIEluIHN1Y2ggYSBjYXNlLCB0aGUgcHJvY2Vk dXJlcyBkZWZpbmVkIGluIA0KICAgICAgIFtESUFNQkFTRV0gZm9yIGNyZWF0aW5nIG5ldyBBVlBz IE1VU1QgYmUgZm9sbG93ZWQuIA0KICAgIA0KICAgMWMuIEZvciBzZXJ2aWNlcyBzcGVjaWZpYyBv bmx5IHRvIG9uZSB2ZW5kb3IncyBpbXBsZW1lbnRhdGlvbiwgYSBWZW5kb3ItIA0KICAgICAgIFNw ZWNpZmljIEFWUCBjb2RlIGZvciBQcml2YXRlIHVzZSBjYW4gYmUgdXNlZC4gV2hlcmUgYSBWZW5k b3ItU3BlY2lmaWMgDQogICAgICAgQVZQIGlzIGltcGxlbWVudGVkIGJ5IG1vcmUgdGhhbiBvbmUg dmVuZG9yLCBhbGxvY2F0aW9uIG9mIGdsb2JhbCBBVlBzIA0KICAgICAgIGFyZSBlbmNvdXJhZ2Vk IGluc3RlYWQsIHJlZmVyIHRvIFtESUFNQkFTRV0uIA0KICAgIA0KICAgMi4gVGhlIFNlcnZpY2Ut UGFyYW1ldGVyLUluZm8gQVZQIE1BWSBiZSB1c2VkIGFzIGEgY29udGFpbmVyIHRvIHBhc3MgDQog ICAgICBsZWdhY3kgcmF0aW5nIGluZm9ybWF0aW9uIGluIGl0cyBvcmlnaW5hbCBlbmNvZGVkIGZv cm0gKGUuZy4gQVNOLjEgDQogICAgICBCRVIpLiBUaGlzIG1ldGhvZCBjYW4gYmUgdXNlZCB0byBh dm9pZCB1bm5lY2Vzc2FyeSBkYXRhIGZvcm1hdCANCiAgICAgIGNvbnZlcnNpb25zIGZyb20gYW4g ZXhpc3RpbmcgZm9ybWF0IHRvIGFuIEFWUCBmb3JtYXQuIEluIHRoYXQgY2FzZSB0aGUgDQogICAg ICByYXRpbmcgaW5wdXQgaXMgZW1iZWRkZWQgaW4gdGhlIFNlcnZpY2UtUGFyYW1ldGVyLUluZm8g QVZQIGFzIGRlZmluZWQgDQogICAgICBpbiBzZWN0aW9uIDguNDIuIA0KICAgIA0KICAgTmV3IHNl cnZpY2UgYXBwbGljYXRpb25zIFNIT1VMRCBmYXZvciB0aGUgdXNlIG9mIGV4cGxpY2l0bHkgZGVm aW5lZCBBVlBzIA0KICAgYXMgZGVzY3JpYmVkIGluIGl0ZW1zIDFhIGFuZCAxYiwgdG8gc2ltcGxp ZnkgaW50ZXJvcGVyYWJpbGl0eS4gIA0KICAgIA0KNC4xLjIgQXBwbGljYXRpb24gU3VwcG9ydCAN CiAgICANCiAgIFNpbmNlIHRoZSBBcHBsaWNhdGlvbi1JZCBvZiB0aGUgRGlhbWV0ZXIgQ3JlZGl0 IENvbnRyb2wgQXBwbGljYXRpb24gZG9lcyANCiAgIG5vdCB1bmlxdWVseSBpZGVudGlmeSB0aGUg c2VydmljZSBiZWluZyBtb25pdG9yZWQsIGFuIGFkZGl0aW9uYWwgbWVjaGFuaXNtIA0KICAgaXMg bmVlZGVkLiBUaGUgc2VydmljZSBhcHBsaWNhdGlvbiBNVVNUIGJlIGlkZW50aWZpZWQgdXNpbmcg dGhlIFNlcnZpY2UtDQogICBJZGVudGlmaWVyIEFWUCBhdCBjb21tYW5kIGxldmVsLiBBIHNlcnZl ciByZWNlaXZpbmcgYSByZXF1ZXN0IGZvciBhIA0KICAgc2VydmljZSBhcHBsaWNhdGlvbiBpdCBk b2VzIG5vdCBzdXBwb3J0IHdpbGwgcmVqZWN0IHRoZSByZXF1ZXN0IGFzIGRlZmluZWQgDQogICBp biBzdWItc2VjdGlvbiA0LjEuNC4gVGhlIFNlcnZpY2UtSWRlbnRpZmllciBBVlAgTVVTVCBiZSBh IHVuaXF1ZSANCiAgIGlkZW50aWZpZXIgZm9yIGEgZ2l2ZW4gc2VydmljZSBhcyBkZWZpbmVkIGlu IHNlY3Rpb24gOC4yOC4gIA0KICAgIA0KICAgVGh1cywgdGhlIGNvbWJpbmF0aW9uIG9mIHRoZSBE aWFtZXRlciBDcmVkaXQgQ29udHJvbCBBcHBsaWNhdGlvbi1JZCBhbmQgDQogICB0aGUgU2Vydmlj ZS1JZGVudGlmaWVyIEFWUCBpbiB0aGUgQ3JlZGl0LUNvbnRyb2wtUmVxdWVzdCBjb21tYW5kIHVu aXF1ZWx5IA0KICAgZGVmaW5lcyB0aGUgc2VydmljZSB3aXRoaW4gdGhlIGNvbnRleHQgb2YgdGhl IERpYW1ldGVyIENyZWRpdCBDb250cm9sLCBhbmQgDQogICBoZW5jZSBwcm92aWRlcyBpbnRlcm9w ZXJhYmlsaXR5IGJldHdlZW4gRGlhbWV0ZXIgY3JlZGl0IGNvbnRyb2wgY2xpZW50cyANCiAgIGFu ZCBzZXJ2ZXIuIA0KICAgIA0KICAgV2l0aCB0aGlzIG1lY2hhbmlzbSBpdCBpcyBwb3NzaWJsZSB0 byBjb3ZlciBhZGRpdGlvbmFsIHNlcnZpY2Ugc3BlY2lmaWMgDQogICByZXF1aXJlbWVudHMgYXMg bmVlZGVkIGluIG90aGVyIGRvY3VtZW50cy4gSG93ZXZlciwgaW50cm9kdWNpbmcgbmV3IGNyZWRp dCANCiAgIGNvbnRyb2wgbWVjaGFuaXNtcyB0byB0aGUgZnJhbWV3b3JrIGRlZmluZWQgaW4gdGhp cyBzcGVjaWZpY2F0aW9uLCByZXF1aXJlIA0KICAgZGVmaW5pdGlvbiBvZiBhIG5ldyB2ZXJzaW9u IG9mIHRoZSBEaWFtZXRlciBDcmVkaXQgQ29udHJvbCBBcHBsaWNhdGlvbiBhbmQgDQogICBjb3Jy ZXNwb25kaW5nIEFwcGxpY2F0aW9uIElkZW50aWZpZXIuIA0KICAgIA0KNC4xLjMgU2VydmljZS1T cGVjaWZpYyBEb2N1bWVudGF0aW9uIA0KICAgICANCiAgIFRoZSBzZXJ2aWNlIHNwZWNpZmljIHJh dGluZyBpbnB1dCBBVlBzLCB0aGUgY29udGVudHMgb2YgdGhlIFNlcnZpY2UtDQogICBQYXJhbWV0 ZXItSW5mbyBBVlAgb3IgU2VydmljZS1JZGVudGlmaWVyIEFWUCBhcmUgbm90IHdpdGhpbiB0aGUg c2NvcGUgb2YgDQogICB0aGlzIGRvY3VtZW50LiBUbyBmYWNpbGl0YXRlIGludGVyb3BlcmFiaWxp dHksIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlIA0KICAgcmF0aW5nIGlucHV0IGFuZCB0aGUg dmFsdWVzIG9mIHRoZSBzZXJ2aWNlIGlkZW50aWZpZXJzIGFyZSBjb29yZGluYXRlZCB2aWEgDQog ICBhbiBpbmZvcm1hdGlvbmFsIFJGQyBvciBvdGhlciBwZXJtYW5lbnQgYW5kIHJlYWRpbHkgYXZh aWxhYmxlIHJlZmVyZW5jZSANCiAgIHN1Y2ggYXMgdGhlIHNwZWNpZmljYXRpb24gb2YgYW5vdGhl ciBjb29wZXJhdGl2ZSBzdGFuZGFyZGl6YXRpb24gYm9keSANCiAgIChlLmcuIDNHUFAsIE9NQSBh bmQgM0dQUDIpIFNIT1VMRCBiZSB1c2VkLiBIb3dldmVyLCBwcml2YXRlIHNlcnZpY2VzIG1heSAN CiAgIGJlIGRlcGxveWVkIHRoYXQgYXJlIHN1YmplY3QgdG8gYWdyZWVtZW50cyBiZXR3ZWVuIHBy b3ZpZGVycyBvZiB0aGUgY3JlZGl0IA0KICAgY29udHJvbCBzZXJ2ZXIgYW5kIGNsaWVudCwgaW4g dGhpcyBjYXNlIHZlbmRvciBzcGVjaWZpYyBBVlBzIGNhbiBiZSB1c2VkLiAgDQogICAgICAgIA0K ICAgVGhpcyBzcGVjaWZpY2F0aW9uLCB0b2dldGhlciB3aXRoIHRoZSBhYm92ZSBzZXJ2aWNlIHNw ZWNpZmljIGRvY3VtZW50cywgDQogICBnb3Zlcm5zIHRoZSBjcmVkaXQgY29udHJvbCBtZXNzYWdl LiBUaGUgcnVsZSBpcyB0aGF0IHNlcnZpY2Ugc3BlY2lmaWMgDQogICBkb2N1bWVudHMgZGVmaW5l IHdoYXQgZXhpc3RpbmcgQVZQcyBvciBuZXcgQVZQcyBhcmUgdXNlZCBhcyBpbnB1dCB0byB0aGUg DQogICByYXRpbmcgcHJvY2VzcyAoaS5lLiB0aGV5IGRvIG5vdCBkZWZpbmUgbmV3IGNyZWRpdCBj b250cm9sIGFwcGxpY2F0aW9ucyksIA0KICAgYW5kIHRodXMgbmVlZCB0byBiZSBpbmNsdWRlZCBp biB0aGUgQ3JlZGl0LUNvbnRyb2wtUmVxdWVzdCBjb21tYW5kIGJ5IGEgDQogICBEaWFtZXRlciBD cmVkaXQgQ29udHJvbCBDbGllbnQgc3VwcG9ydGluZyBhIGdpdmVuIHNlcnZpY2UgYXMgKltBVlBd LiANCiAgIFNob3VsZCBTZXJ2aWNlLVBhcmFtZXRlci1JbmZvIGJlIHVzZWQsIHRoZW4gdGhlIHNl cnZpY2Ugc3BlY2lmaWMgZG9jdW1lbnQgDQogICBNVVNUIHNwZWNpZnkgdGhlIGV4YWN0IGNvbnRl bnQgb2YgdGhpcyBncm91cGVkIEFWUC4gDQogICAgDQo0LjEuNCBIYW5kbGluZyBvZiBVbnN1cHBv cnRlZC9JbmNvcnJlY3QgUmF0aW5nIElucHV0ICANCiAgICANCiAgIERpYW1ldGVyIGNyZWRpdCBj b250cm9sIGltcGxlbWVudGF0aW9ucyBhcmUgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGUgDQogICBN YW5kYXRvcnkgcmF0aW5nIEFWUHMgZGVmaW5lZCBpbiBzZXJ2aWNlIHNwZWNpZmljIGRvY3VtZW50 YXRpb24gb2YgdGhlIA0KICAgc2VydmljZXMgdGhleSBzdXBwb3J0IGFjY29yZGluZyB0byB0aGUg J00nIGJpdCBydWxlcyBpbiBbRElBTUJBU0VdLiAgDQogICAgICAgIA0KICAgSW4gY2FzZSBhIHJh dGluZyBpbnB1dCByZXF1aXJlZCBmb3IgdGhlIHJhdGluZyBwcm9jZXNzIGlzIGluY29ycmVjdCBp biB0aGUgDQogICBDcmVkaXQgY29udHJvbCByZXF1ZXN0LCBvciB0aGUgY3JlZGl0IGNvbnRyb2wg c2VydmVyIGRvZXMgbm90IHN1cHBvcnQgdGhlIA0KICAgcmVxdWVzdGVkIHNlcnZpY2UgKGlkZW50 aWZpZWQgYnkgdGhlIFNlcnZpY2UtSWRudGlmaWVyIEFWUCBhdCBjb21tYW5kIA0KICAgbGV2ZWwp LCB0aGUgQ3JlZGl0IGNvbnRyb2wgYW5zd2VyIE1VU1QgY29udGFpbiBlcnJvciBjb2RlIA0KICAg RElBTUVURVJfUkFUSU5HX0ZBSUxFRC4gQSBDQ1IgbWVzc2FnZSB3aXRoIHRoaXMgZXJyb3IgTVVT VCBjb250YWluIG9uZSBvciANCiAgIG1vcmUgRmFpbGVkLUFWUCBBVlBzIGNvbnRhaW5pbmcgdGhl IG1pc3NpbmcgYW5kL29yIHVuc3VwcG9ydGVkIEFWUHMgdGhhdCANCiAgIGNhdXNlZCB0aGUgZmFp bHVyZS4gQSBEaWFtZXRlciBjcmVkaXQgY29udHJvbCBjbGllbnQgcmVjZWl2aW5nIGVycm9yIGNv ZGUgDQogICBESUFNRVRFUl9SQVRJTkdfRkFJTEVEIGluIGFuc3dlciB0byBhIHJlcXVlc3QgTVVT VCBOT1Qgc2VuZCBzdWNoIHNpbWlsYXIgDQogICByZXF1ZXN0cyBpbiB0aGUgZnV0dXJlLiANCiAg ICANCjQuMS41IFJBRElVUyBWZW5kb3ItU3BlY2lmaWMgUmF0aW5nIEF0dHJpYnV0ZXMgDQogICAg ICAgIA0KICAgV2hlbiBzZXJ2aWNlIHNwZWNpZmljIGRvY3VtZW50cyBpbmNsdWRlIFJBRElVUyB2 ZW5kb3Igc3BlY2lmaWMgYXR0cmlidXRlcyANCiAgIHRoYXQgY291bGQgYmUgdXNlZCBhcyBpbnB1 dCBpbiB0aGUgcmF0aW5nIHByb2Nlc3MsIHRoZSBydWxlcyBkZXNjcmliZWQgaW4gDQogICBbTkFT UkVRXSBmb3IgZm9ybWF0dGluZyB0aGUgRGlhbWV0ZXIgQVZQIE1VU1QgYmUgZm9sbG93ZWQuIEZv ciBleGFtcGxlLCANCiAgIHRoZSBBVlAgY29kZSB1c2VkIGlzIHRoZSB2ZW5kb3IgYXR0cmlidXRl IHR5cGUgY29kZSwgdGhlIFZlbmRvci1TcGVjaWZpYyANCiAgIGZsYWcgTVVTVCBiZSBzZXQgdG8g MSBhbmQgdGhlIFZlbmRvci1JRCBNVVNUIGJlIHNldCB0byB0aGUgSUFOQSBWZW5kb3IgDQogICBp ZGVudGlmaWNhdGlvbiB2YWx1ZS4gVGhlIERpYW1ldGVyIEFWUCBkYXRhIGZpZWxkIGNvbnRhaW5z IG9ubHkgdGhlIA0KICAgYXR0cmlidXRlIHZhbHVlIG9mIHRoZSBSQURJVVMgYXR0cmlidXRlLg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG93bmVyLWFhYS13Z0BtZXJp dC5lZHUgDQo+IFttYWlsdG86b3duZXItYWFhLXdnQG1lcml0LmVkdV1PbiBCZWhhbGYgT2YNCj4g ZXh0IEdsZW4gWm9ybg0KPiBTZW50OiAwMiBKdWx5LCAyMDA0IDIwOjI3DQo+IFRvOiBhYWEtd2dA bWVyaXQuZWR1DQo+IFN1YmplY3Q6IA0KPiANCj4gDQo+IERlc2NyaXB0aW9uIG9mIGlzc3VlOiAg Tm8gZ3VhcmFudGVlIG9mIGludGVyb3BlcmFiaWxpdHkgDQo+IGJldHdlZW4gQ0NBIGltcGxlbWVu dGF0aW9ucw0KPiBTdWJtaXR0ZXIgbmFtZTogR2xlbiBab3JuDQo+IFN1Ym1pdHRlciBlbWFpbCBh ZGRyZXNzOiBnd3pAY2lzY28uY29tIA0KPiBEYXRlIGZpcnN0IHN1Ym1pdHRlZDogMiBKdWx5IDIw MDQgDQo+IERvY3VtZW50OiBkY2NhIA0KPiBDb21tZW50IHR5cGU6IFQNCj4gUHJpb3JpdHk6IFMN Cj4gU2VjdGlvbjogNC4xDQo+IFJhdGlvbmFsZS9FeHBsYW5hdGlvbiBvZiBpc3N1ZTogDQo+IElu IG9yZGVyIHRvIGludGVyb3BlcmF0ZSwgRGlhbWV0ZXIgcGVlcnMgaW1wbGVtZW50aW5nIHRoZSAN Cj4gRGlhbWV0ZXIgQ3JlZGl0IENvbnRyb2wgQXBwbGljYXRpb24gbXVzdCBhZ3JlZSB1cG9uIGJv dGggdGhlIA0KPiBhcHBsaWNhdGlvbiBhbmQgdGhlIHNlcnZpY2UgKHNwZWNpZmllZCBpbiB0aGUg DQo+IFNlcnZpY2UtSWRlbnRpZmllciBBVlApLiAgSG93ZXZlciwgdGhlIGluY2x1c2lvbiBvZiB0 aGUgDQo+IFNlcnZpY2UtSWRlbnRpZmllciBpbiB0aGUgQ0NSIGFuZCBDQ0EgbWVzc2FnZXMgaXMg b3B0aW9uYWwuDQo+IA0KPiBMZW5ndGh5IGRlc2NyaXB0aW9uIG9mIHByb2JsZW06DQo+IFNlY3Rp b24gNC4xLCBwYXJhLiA2IHN0YXRlcyAiaXQgaXMgdGhlIGNvbWJpbmF0aW9uIG9mIHN1cHBvcnQg DQo+IG9mIHRoZSBEaWFtZXRlciBDcmVkaXQgQ29udHJvbCBBcHBsaWNhdGlvbiBhbmQgdGhlIHNl cnZpY2UgDQo+IGRlZmluZWQgaW4gdGhlIFNlcnZpY2UtSWRlbnRpZmllciBBVlAsIHdoaWNoIGRl ZmluZXMgDQo+IGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBhbnkgZ2l2ZW4gY3JlZGl0IGNvbnRy b2wgY2xpZW50IGFuZCANCj4gc2VydmVyLiIgIEhvd2V2ZXIsIHRoZSBpbmNsdXNpb24gb2YgdGhl IFNlcnZpY2UtSWRlbnRpZmllciBpbiANCj4gdGhlIENDUiBhbmQgQ0NBIG1lc3NhZ2VzIGlzIG9w dGlvbmFsLiAgVGhpcyBnaXZlcyByaXNlIHRvIGEgDQo+IHNpdHVhdGlvbiB3aGVyZSB0d28gcGVl cnMgaW1wbGVtZW50aW5nIHRoZSBzYW1lIGFwcGxpY2F0aW9uIA0KPiBtYXkgbm90IGludGVyb3Bl cmF0ZSBiZWNhdXNlIHRoZXkgZG8gbm90IGltcGxlbWVudCB0aGUgc2FtZSANCj4gInNlcnZpY2Ui LCBhbmQgZnVydGhlciwgcmVmdXNlIHRvIGNsZWFybHkgY29tbXVuaWNhdGUgdGhhdCBmYWN0Lg0K PiANCj4gUmVxdWVzdGVkIGNoYW5nZTogDQo+IENoYW5nZSBzZWN0aW9uIDQuMSwgcGFyYWdyYXBo IDUgZnJvbQ0KPiANCj4gICAgVGhpcyBzcGVjaWZpY2F0aW9uLCB0b2dldGhlciB3aXRoIHNlcnZp Y2Ugc3BlY2lmaWMgZG9jdW1lbnRzLCBpcyANCj4gICAgZ292ZXJuaW5nIHRoZSBjcmVkaXQgY29u dHJvbCBtZXNzYWdlLiBUaGUgcnVsZSBpcyB0aGF0IHNlcnZpY2UgDQo+ICAgIHNwZWNpZmljIGRv Y3VtZW50cyBvbmx5IGRlZmluZSB3aGF0IGV4aXN0aW5nIEFWUHMgb3IgbmV3IEFWUHMgYXJlIA0K PiAgICB1c2VkIGFzIGlucHV0IHRvIHRoZSByYXRpbmcgcHJvY2VzcyAoaS5lLiB0aGV5IGRvIG5v dCBkZWZpbmUgbmV3IA0KPiAgICBjcmVkaXQgY29udHJvbCBhcHBsaWNhdGlvbnMpLCBhbmQgdGh1 cyBuZWVkIHRvIGJlIGluY2x1ZGVkIGluIHRoZSANCj4gICAgQ3JlZGl0LUNvbnRyb2wtUmVxdWVz dCBjb21tYW5kIGJ5IGEgRGlhbWV0ZXIgQ3JlZGl0IENvbnRyb2wgQ2xpZW50IA0KPiAgICBzdXBw b3J0aW5nIGEgZ2l2ZW4gc2VydmljZSBhcyAqW0FWUF0uIEluIG9yZGVyIHRvIGRlZmluZSBuZXcg QVZQcywgDQo+ICAgIHNlcnZpY2Ugc3BlY2lmaWMgZG9jdW1lbnRzIE1VU1QgZm9sbG93IHRoZSBw cmFjdGljZXMgZGVmaW5lZCBpbiANCj4gICAgW0RJQU1CQVNFXS4gVGhlIHNlcnZpY2UgU0hPVUxE IGJlIGlkZW50aWZpZWQgdXNpbmcgdGhlIFNlcnZpY2UtIA0KPiAgICBJZGVudGlmaWVyIEFWUC4g VGhlIFNlcnZpY2UtSWRlbnRpZmllciBBVlAgTVVTVCBiZSBhIHVuaXF1ZSANCj4gICAgaWRlbnRp ZmllciBmb3IgYSBnaXZlbiBzZXJ2aWNlIGFzIGRlZmluZWQgaW4gc2VjdGlvbiA4LjI4LiANCj4g DQo+IHRvDQo+IA0KPiAgICBUaGlzIHNwZWNpZmljYXRpb24sIHRvZ2V0aGVyIHdpdGggc2Vydmlj ZSBzcGVjaWZpYyBkb2N1bWVudHMsIGlzIA0KPiAgICBnb3Zlcm5pbmcgdGhlIGNyZWRpdCBjb250 cm9sIG1lc3NhZ2UuIFRoZSBydWxlIGlzIHRoYXQgc2VydmljZSANCj4gICAgc3BlY2lmaWMgZG9j dW1lbnRzIG9ubHkgZGVmaW5lIHdoYXQgZXhpc3RpbmcgQVZQcyBvciBuZXcgQVZQcyBhcmUgDQo+ ICAgIHVzZWQgYXMgaW5wdXQgdG8gdGhlIHJhdGluZyBwcm9jZXNzIChpLmUuIHRoZXkgZG8gbm90 IGRlZmluZSBuZXcgDQo+ICAgIGNyZWRpdCBjb250cm9sIGFwcGxpY2F0aW9ucyksIGFuZCB0aHVz IG5lZWQgdG8gYmUgaW5jbHVkZWQgaW4gdGhlIA0KPiAgICBDcmVkaXQtQ29udHJvbC1SZXF1ZXN0 IGNvbW1hbmQgYnkgYSBEaWFtZXRlciBDcmVkaXQgQ29udHJvbCBDbGllbnQgDQo+ICAgIHN1cHBv cnRpbmcgYSBnaXZlbiBzZXJ2aWNlIGFzICpbQVZQXS4gSW4gb3JkZXIgdG8gZGVmaW5lIG5ldyBB VlBzLCANCj4gICAgc2VydmljZSBzcGVjaWZpYyBkb2N1bWVudHMgTVVTVCBmb2xsb3cgdGhlIHBy YWN0aWNlcyBkZWZpbmVkIGluIA0KPiAgICBbRElBTUJBU0VdLiBUaGUgc2VydmljZSBNVVNUIGJl IGlkZW50aWZpZWQgdXNpbmcgdGhlIFNlcnZpY2UtIA0KPiAgICBJZGVudGlmaWVyIEFWUC4gVGhl IFNlcnZpY2UtSWRlbnRpZmllciBBVlAgTVVTVCBiZSBhIHVuaXF1ZSANCj4gICAgaWRlbnRpZmll ciBmb3IgYSBnaXZlbiBzZXJ2aWNlIGFzIGRlZmluZWQgaW4gc2VjdGlvbiA4LjI4LiANCj4gDQo+ IH5nd3oNCj4gDQo+ICJUaGV5IHRoYXQgY2FuIGdpdmUgdXAgZXNzZW50aWFsIGxpYmVydHkgdG8g b2J0YWluIGEgbGl0dGxlIA0KPiB0ZW1wb3Jhcnkgc2FmZXR5IGRlc2VydmUgbmVpdGhlci4uLiIN Cj4gLS0gQmVuamFtaW4gRnJhbmtsaW4sIDE3NTkgDQo+IA0KPiANCj4gIkl0IGlzIGZvcmJpZGRl biB0byBraWxsOyB0aGVyZWZvcmUgYWxsIG11cmRlcmVycyBhcmUgDQo+IHB1bmlzaGVkIHVubGVz cyB0aGV5IGtpbGwgaW4gbGFyZ2UgbnVtYmVycyBhbmQgdG8gdGhlIHNvdW5kIA0KPiBvZiB0cnVt cGV0cy4iDQo+IC0tIFZvbHRhaXJlDQo+IA0KPiANCg== From owner-aaa-wg@merit.edu Mon Jul 5 06:40: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 GAA19494 for ; Mon, 5 Jul 2004 06:40:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 46E5891208; Mon, 5 Jul 2004 06:39:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1077491217; Mon, 5 Jul 2004 06:39:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7CC4F91208 for ; Mon, 5 Jul 2004 06:39:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6867459AA2; Mon, 5 Jul 2004 06:39:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 7766359F69 for ; Mon, 5 Jul 2004 06:39:53 -0400 (EDT) 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 i65Adl202276; Mon, 5 Jul 2004 13:39:47 +0300 (EET DST) X-Scanned: Mon, 5 Jul 2004 13:38:04 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i65Ac3jq010339; Mon, 5 Jul 2004 13:38:04 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00fM1tSS; Mon, 05 Jul 2004 13:38:02 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 i65Ac2H02767; Mon, 5 Jul 2004 13:38:02 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Jul 2004 13:37:53 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [AAA-WG]: RE: Date: Mon, 5 Jul 2004 13:37:52 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B05B4@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: RE: Thread-Index: AcRgWhMEq9nFOYtjTEWhJaIUMzBhpwCCmknwAAWlCsA= From: To: Cc: X-OriginalArrivalTime: 05 Jul 2004 10:37:53.0290 (UTC) FILETIME=[207016A0:01C4627C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: base64 QlRXLCBJIGZvcmdvdCBvbmUgYWRkaXRpb25hbCB0aGluZyByZWxhdGVkIHRvIHRoaXMuDQoNCkJl Y2F1c2UgdGhlIFNlcnZpY2UtSWRlbnRpZmllciBBVlAgTVVTVCBiZSBpbmNsdWRlIGluIENDUiBh bmQgaXQNCmlzIHVzZWQgdG8gZGV0ZXJtaW5lIGlmIHRoZSByZXF1ZXN0IGNhbiBiZSBob25vcmVk LCBpcyB0bw0KYmUgaW5jbHVkZSBpbiBjdXJseSBicmFrZXRzIGluIHRoZSBBQk5GIG9mIHRoZSBj b21tYW5kIGFuZCBzaGFsbA0KYmUgYXMgY2xvc2VkIHRvIHRoZSBoZWFkZXIgYXMgcG9zc2libGUu IFRoZXJlZm9yZSB3ZSBhbHNvDQp1cGRhdGVkIHNlY3Rpb24gMy4xIGFzIGZvbGxvdzoNCg0KIDxD cmVkaXQtQ29udHJvbC1SZXF1ZXN0PiA6Oj0gPCBEaWFtZXRlciBIZWFkZXI6IHh4eCwgUkVRLCBQ WFkgPiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8IFNlc3Npb24tSWQg PiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB7IE9yaWdpbi1Ib3N0IH0g DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgeyBPcmlnaW4tUmVhbG0gfSAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB7IERlc3RpbmF0aW9uLVJlYWxt IH0gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgeyBBdXRoLUFwcGxpY2F0 aW9uLUlkIH0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB7IFNlcnZpY2Ut SWRlbnRpZmllciB9IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHsgQ0Mt UmVxdWVzdC1UeXBlIH0gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgeyBD Qy1SZXF1ZXN0LU51bWJlciB9IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFsgRGVzdGluYXRpb24tSG9zdCBdIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFsgVXNlci1OYW1lIF0gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Li4uLi4uLi4NCg0KTWFyY28NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBvd25lci1hYWEtd2dAbWVyaXQuZWR1IA0KPiBbbWFpbHRvOm93bmVyLWFhYS13Z0BtZXJpdC5l ZHVdT24gQmVoYWxmIE9mDQo+IGV4dCANCj4gU2VudDogMDUgSnVseSwgMjAwNCAxMTowOQ0KPiBU bzogZ3d6QGNpc2NvLmNvbQ0KPiBDYzogYWFhLXdnQG1lcml0LmVkdQ0KPiBTdWJqZWN0OiBbQUFB LVdHXTogUkU6IA0KPiANCj4gDQo+IEdsZW4sDQo+IA0KPiB0aGUgU2VydmljZS1JZCBpcyBvbmx5 IGluY2x1ZGVkIGluIENDUiBtZXNzYWdlIChhdCBjb21tYW5kIA0KPiBsZXZlbCkgdG8gaW5kaWNh dGUgDQo+IHRvIHRoZSBzZXJ2ZXIgZm9yIHdoYXQgc3BlY2lmaWMgc2VydmljZSB0aGUgcmVxdWVz dCBpcyBiZWluZyBpc3N1ZWQuDQo+IFRoZSBzZXJ2ZXIgY2hlY2tzIGZpcnN0IHRoZSBTZXJ2aWNl LUlkIEFWUCBhbmQsIGlmIGl0IGRvZXNuJ3QgDQo+IHJlY29nbml6ZQ0KPiB0aGUgdmFsdWUgb2Yg dGhpcyBBVlAsIGl0IHJlamVjdHMgdGhlIHJlcXVlc3Qgd2l0aG91dCBhbnkgDQo+IGZ1cnRoZXIg cHJvY2Vzc2luZw0KPiAoZS5nLiByYXRpbmcgb3Igd2hhdCBzbyBldmVyKS4gSWYgdGhlIHNlcnZl ciByZWNvZ25pemVzIHRoZSANCj4gdmFsdWUgb2YgdGhlDQo+IFNlcnZpY2UtSWQgQVZQLCBpdCBj b250aW51ZXMgdGhlIHByb2Nlc3NpbmcgYW5kIGF1dGhvcml6ZXMgDQo+IHRoZSBjcmVkaXQgaWYN Cj4gcG9zc2libGUgKGkuZS4gaWYgdGhlcmUgaXMgZW5vdWdoIGNyZWRpdCBpbiB0aGUgdXNlcidz IGFjY291bnQpLiAgDQo+IA0KPiBUaGUgc2VjdGlvbiA0LjEgaGFzIGJlZW4gcmVzdHJ1Y3R1cmVk IG9uIHJlcXVlc3Qgb2YgSUVTRyANCj4gcmV2aWV3IGFzIGZvbGxvdywgdGhlDQo+IGluY2x1c2lv biBvZiB0aGUgU2VydmljZS1JZCBpbiBDQ1IgaXMgbWFuZGF0b3J5Lg0KPiANCj4gV2hlbmV2ZXIg dGhlIElFU0cgYW5kIHRoZSBBRHMgd2lsbCBhZ3JlZSB0aGF0IHRoZWlyIGNvbW1lbnRzIA0KPiBo YXZlIGJlZW4gcHJvcGVybHkNCj4gYWRkcmVzc2VkLCB0aGUgZHJhZnQgMDYgd2lsbCBiZSBjYXJy aWVkIG91dCBhbmQgbWFkZSBhdmFpbGFibGUuDQo+IA0KPiBSZWdhcmRzDQo+IE1hcmNvIA0KPiAN Cj4gNC4xIFNlcnZpY2UtU3BlY2lmaWMgUmF0aW5nIElucHV0IGFuZCBJbnRlcm9wZXJhYmlsaXR5 IA0KPiAgICAgDQo+ICAgIFRoZSBEaWFtZXRlciBDcmVkaXQtQ29udHJvbCBBcHBsaWNhdGlvbiBk ZWZpbmVzIHRoZSANCj4gZnJhbWV3b3JrIGZvciBjcmVkaXQgDQo+ICAgIGNvbnRyb2w7IGl0IHBy b3ZpZGVzIGdlbmVyaWMgY3JlZGl0IGNvbnRyb2wgbWVjaGFuaXNtcyANCj4gc3VwcG9ydGluZyBt dWx0aXBsZSANCj4gICAgc2VydmljZSBhcHBsaWNhdGlvbnMuIFRoZSBDcmVkaXQgQ29udHJvbCBB cHBsaWNhdGlvbiwgDQo+IHRoZXJlZm9yZSwgZG9lcyBub3QgDQo+ICAgIGRlZmluZSBBVlBzIHRo YXQgY291bGQgYmUgdXNlZCBhcyBpbnB1dCBpbiB0aGUgcmF0aW5nIA0KPiBwcm9jZXNzLiBMaXN0 aW5nIHRoZSANCj4gICAgcG9zc2libGUgc2VydmljZXMgdGhhdCBjb3VsZCB1c2UgdGhpcyBEaWFt ZXRlciBhcHBsaWNhdGlvbiANCj4gaXMgc2VlbiBhcyBvdXQgDQo+ICAgIG9mIHNjb3BlIGZvciB0 aGlzIGdlbmVyaWMgbWVjaGFuaXNtIGFzIHdlbGwuICANCj4gICAgIA0KPiAgICBGdXJ0aGVybW9y ZSwgaXQgaXMgcmVhc29uYWJsZSB0byBleHBlY3QgdGhhdCB0aGVyZSB3aWxsIA0KPiBleGlzdCBh IHNlcnZpY2UgDQo+ICAgIGxldmVsIGFncmVlbWVudCBiZXR3ZWVuIHByb3ZpZGVycyBvZiB0aGUg Y3JlZGl0LWNvbnRyb2wgDQo+IGNsaWVudCBhbmQgdGhlIA0KPiAgICBjcmVkaXQtY29udHJvbCBz ZXJ2ZXIgY292ZXJpbmcgdGhlIGNoYXJnaW5nLCBzZXJ2aWNlcyANCj4gb2ZmZXJlZCwgcm9hbWlu ZyANCj4gICAgYWdyZWVtZW50cywgYWdyZWVkIHJhdGluZyBpbnB1dCAoaS5lLiBBVlBzKSwgZXRj LiANCj4gDQo+ICAgIFRoZXJlZm9yZSwgaXQgaXMgYXNzdW1lZCB0aGF0IGEgRGlhbWV0ZXIgY3Jl ZGl0IGNvbnRyb2wgDQo+IHNlcnZlciB3aWxsIA0KPiAgICBwcm92aWRlIHNlcnZpY2Ugb25seSBm b3IgRGlhbWV0ZXIgY3JlZGl0LWNvbnRyb2wgY2xpZW50cyANCj4gdGhhdCBoYXZlIGFncmVlZCAN Cj4gICAgYmVmb3JlaGFuZCB0aGUgY29udGVudCBvZiBjcmVkaXQgY29udHJvbCBtZXNzYWdlcy4g DQo+IFByb3RvY29sIHdpc2UsIGl0IGlzIA0KPiAgICBuYXR1cmFsbHkgcG9zc2libGUgdGhhdCBh bnkgYXJiaXRyYXJ5IERpYW1ldGVyIA0KPiBjcmVkaXQtY29udHJvbCBjbGllbnQgY2FuIA0KPiAg ICBpbnRlcmNoYW5nZSBjcmVkaXQgY29udHJvbCBtZXNzYWdlcyB3aXRoIGFueSBEaWFtZXRlciAN Cj4gY3JlZGl0IGNvbnRyb2wgDQo+ICAgIHNlcnZlciwgYnV0IHdpdGggYSBoaWdoZXIgbGlrZWxp aG9vZCB0aGF0IHVuc3VwcG9ydGVkIA0KPiBzZXJ2aWNlcy9BVlBzIGNvdWxkIA0KPiAgICBiZSBw cmVzZW50IGluIHRoZSBjcmVkaXQtY29udHJvbCBtZXNzYWdlIGNhdXNpbmcgdGhlIA0KPiBzZXJ2 ZXIgdG8gcmVqZWN0IHRoZSANCj4gICAgcmVxdWVzdCB3aXRoIGFuIGFwcHJvcHJpYXRlIHJlc3Vs dC1jb2RlLiANCj4gICAgIA0KPiA0LjEuMSBTcGVjaWZ5aW5nIFJhdGluZyBJbnB1dCBBVlBzIA0K PiAgICAgDQo+ICAgIFRoZXJlIGFyZSB0d28gd2F5cyBmb3IgcHJvdmlkaW5nIHJhdGluZyBpbnB1 dCB0byB0aGUgDQo+IGNyZWRpdCBjb250cm9sIA0KPiAgICBzZXJ2ZXIsIGVpdGhlciBieSB1c2lu ZyBBVlBzIG9yIGJ5IGluY2x1ZGluZyB0aGVtIGluIHRoZSBTZXJ2aWNlLQ0KPiAgICBQYXJhbWV0 ZXItSW5mbyBBVlAuIFRoZSBnZW5lcmFsIHByaW5jaXBsZXMgZm9yIHNlbmRpbmcgDQo+IHJhdGlu ZyBwYXJhbWV0ZXJzIA0KPiAgICBhcmU6IA0KPiAgICAgDQo+ICAgIDFhLiBUaGUgc2VydmljZSBT SE9VTEQgcmUtdXNlIGV4aXN0aW5nIEFWUHMsIGlmIHRoZSANCj4gc2VydmljZSBjYW4gdXNlIEFW UHMgDQo+ICAgICAgICBkZWZpbmVkIGluIGV4aXN0aW5nIERpYW1ldGVyIGFwcGxpY2F0aW9ucyAo ZS5nLiBOQVNSRVEgDQo+IGZvciBuZXR3b3JrIA0KPiAgICAgICAgYWNjZXNzIHNlcnZpY2VzKS4g UmUtdXNlIG9mIGV4aXN0aW5nIEFWUHMgaXMgc3Ryb25nbHkgDQo+IHJlY29tbWVuZGVkIGluIA0K PiAgICAgICAgW0RJQU1CQVNFXS4gDQo+IA0KPiAgICAgICAgRm9yIEFWUHMgb2YgdHlwZSBFbnVt ZXJhdGVkIHRoZSBzZXJ2aWNlIG1heSByZXF1aXJlIGEgDQo+IG5ldyB2YWx1ZSB0byBiZSANCj4g ICAgICAgIGRlZmluZWQuIEFsbG9jYXRpb24gb2YgbmV3IEFWUCB2YWx1ZXMgaXMgZG9uZSBhcyBz cGVjaWZpZWQgaW4gDQo+ICAgICAgICBbRElBTUJBU0VdLCBzZWN0aW9uIDEuMi4gDQo+ICAgICAN Cj4gICAgMWIuIE5ldyBBVlBzIGNhbiBiZSBkZWZpbmVkIGlmIHRoZSBleGlzdGluZyBBVlBzIGRv IG5vdCANCj4gcHJvdmlkZSBzdWZmaWNpZW50IA0KPiAgICAgICAgcmF0aW5nIGluZm9ybWF0aW9u LiBJbiBzdWNoIGEgY2FzZSwgdGhlIHByb2NlZHVyZXMgZGVmaW5lZCBpbiANCj4gICAgICAgIFtE SUFNQkFTRV0gZm9yIGNyZWF0aW5nIG5ldyBBVlBzIE1VU1QgYmUgZm9sbG93ZWQuIA0KPiAgICAg DQo+ICAgIDFjLiBGb3Igc2VydmljZXMgc3BlY2lmaWMgb25seSB0byBvbmUgdmVuZG9yJ3MgDQo+ IGltcGxlbWVudGF0aW9uLCBhIFZlbmRvci0gDQo+ICAgICAgICBTcGVjaWZpYyBBVlAgY29kZSBm b3IgUHJpdmF0ZSB1c2UgY2FuIGJlIHVzZWQuIFdoZXJlIGEgDQo+IFZlbmRvci1TcGVjaWZpYyAN Cj4gICAgICAgIEFWUCBpcyBpbXBsZW1lbnRlZCBieSBtb3JlIHRoYW4gb25lIHZlbmRvciwgYWxs b2NhdGlvbiANCj4gb2YgZ2xvYmFsIEFWUHMgDQo+ICAgICAgICBhcmUgZW5jb3VyYWdlZCBpbnN0 ZWFkLCByZWZlciB0byBbRElBTUJBU0VdLiANCj4gICAgIA0KPiAgICAyLiBUaGUgU2VydmljZS1Q YXJhbWV0ZXItSW5mbyBBVlAgTUFZIGJlIHVzZWQgYXMgYSANCj4gY29udGFpbmVyIHRvIHBhc3Mg DQo+ICAgICAgIGxlZ2FjeSByYXRpbmcgaW5mb3JtYXRpb24gaW4gaXRzIG9yaWdpbmFsIGVuY29k ZWQgZm9ybSANCj4gKGUuZy4gQVNOLjEgDQo+ICAgICAgIEJFUikuIFRoaXMgbWV0aG9kIGNhbiBi ZSB1c2VkIHRvIGF2b2lkIHVubmVjZXNzYXJ5IGRhdGEgZm9ybWF0IA0KPiAgICAgICBjb252ZXJz aW9ucyBmcm9tIGFuIGV4aXN0aW5nIGZvcm1hdCB0byBhbiBBVlAgZm9ybWF0LiANCj4gSW4gdGhh dCBjYXNlIHRoZSANCj4gICAgICAgcmF0aW5nIGlucHV0IGlzIGVtYmVkZGVkIGluIHRoZSBTZXJ2 aWNlLVBhcmFtZXRlci1JbmZvIA0KPiBBVlAgYXMgZGVmaW5lZCANCj4gICAgICAgaW4gc2VjdGlv biA4LjQyLiANCj4gICAgIA0KPiAgICBOZXcgc2VydmljZSBhcHBsaWNhdGlvbnMgU0hPVUxEIGZh dm9yIHRoZSB1c2Ugb2YgDQo+IGV4cGxpY2l0bHkgZGVmaW5lZCBBVlBzIA0KPiAgICBhcyBkZXNj cmliZWQgaW4gaXRlbXMgMWEgYW5kIDFiLCB0byBzaW1wbGlmeSBpbnRlcm9wZXJhYmlsaXR5LiAg DQo+ICAgICANCj4gNC4xLjIgQXBwbGljYXRpb24gU3VwcG9ydCANCj4gICAgIA0KPiAgICBTaW5j ZSB0aGUgQXBwbGljYXRpb24tSWQgb2YgdGhlIERpYW1ldGVyIENyZWRpdCBDb250cm9sIA0KPiBB cHBsaWNhdGlvbiBkb2VzIA0KPiAgICBub3QgdW5pcXVlbHkgaWRlbnRpZnkgdGhlIHNlcnZpY2Ug YmVpbmcgbW9uaXRvcmVkLCBhbiANCj4gYWRkaXRpb25hbCBtZWNoYW5pc20gDQo+ICAgIGlzIG5l ZWRlZC4gVGhlIHNlcnZpY2UgYXBwbGljYXRpb24gTVVTVCBiZSBpZGVudGlmaWVkIA0KPiB1c2lu ZyB0aGUgU2VydmljZS0NCj4gICAgSWRlbnRpZmllciBBVlAgYXQgY29tbWFuZCBsZXZlbC4gQSBz ZXJ2ZXIgcmVjZWl2aW5nIGEgDQo+IHJlcXVlc3QgZm9yIGEgDQo+ICAgIHNlcnZpY2UgYXBwbGlj YXRpb24gaXQgZG9lcyBub3Qgc3VwcG9ydCB3aWxsIHJlamVjdCB0aGUgDQo+IHJlcXVlc3QgYXMg ZGVmaW5lZCANCj4gICAgaW4gc3ViLXNlY3Rpb24gNC4xLjQuIFRoZSBTZXJ2aWNlLUlkZW50aWZp ZXIgQVZQIE1VU1QgYmUgYSB1bmlxdWUgDQo+ICAgIGlkZW50aWZpZXIgZm9yIGEgZ2l2ZW4gc2Vy dmljZSBhcyBkZWZpbmVkIGluIHNlY3Rpb24gOC4yOC4gIA0KPiAgICAgDQo+ICAgIFRodXMsIHRo ZSBjb21iaW5hdGlvbiBvZiB0aGUgRGlhbWV0ZXIgQ3JlZGl0IENvbnRyb2wgDQo+IEFwcGxpY2F0 aW9uLUlkIGFuZCANCj4gICAgdGhlIFNlcnZpY2UtSWRlbnRpZmllciBBVlAgaW4gdGhlIENyZWRp dC1Db250cm9sLVJlcXVlc3QgDQo+IGNvbW1hbmQgdW5pcXVlbHkgDQo+ICAgIGRlZmluZXMgdGhl IHNlcnZpY2Ugd2l0aGluIHRoZSBjb250ZXh0IG9mIHRoZSBEaWFtZXRlciANCj4gQ3JlZGl0IENv bnRyb2wsIGFuZCANCj4gICAgaGVuY2UgcHJvdmlkZXMgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVu IERpYW1ldGVyIGNyZWRpdCANCj4gY29udHJvbCBjbGllbnRzIA0KPiAgICBhbmQgc2VydmVyLiAN Cj4gICAgIA0KPiAgICBXaXRoIHRoaXMgbWVjaGFuaXNtIGl0IGlzIHBvc3NpYmxlIHRvIGNvdmVy IGFkZGl0aW9uYWwgDQo+IHNlcnZpY2Ugc3BlY2lmaWMgDQo+ICAgIHJlcXVpcmVtZW50cyBhcyBu ZWVkZWQgaW4gb3RoZXIgZG9jdW1lbnRzLiBIb3dldmVyLCANCj4gaW50cm9kdWNpbmcgbmV3IGNy ZWRpdCANCj4gICAgY29udHJvbCBtZWNoYW5pc21zIHRvIHRoZSBmcmFtZXdvcmsgZGVmaW5lZCBp biB0aGlzIA0KPiBzcGVjaWZpY2F0aW9uLCByZXF1aXJlIA0KPiAgICBkZWZpbml0aW9uIG9mIGEg bmV3IHZlcnNpb24gb2YgdGhlIERpYW1ldGVyIENyZWRpdCBDb250cm9sIA0KPiBBcHBsaWNhdGlv biBhbmQgDQo+ICAgIGNvcnJlc3BvbmRpbmcgQXBwbGljYXRpb24gSWRlbnRpZmllci4gDQo+ICAg ICANCj4gNC4xLjMgU2VydmljZS1TcGVjaWZpYyBEb2N1bWVudGF0aW9uIA0KPiAgICAgIA0KPiAg ICBUaGUgc2VydmljZSBzcGVjaWZpYyByYXRpbmcgaW5wdXQgQVZQcywgdGhlIGNvbnRlbnRzIG9m IA0KPiB0aGUgU2VydmljZS0NCj4gICAgUGFyYW1ldGVyLUluZm8gQVZQIG9yIFNlcnZpY2UtSWRl bnRpZmllciBBVlAgYXJlIG5vdCANCj4gd2l0aGluIHRoZSBzY29wZSBvZiANCj4gICAgdGhpcyBk b2N1bWVudC4gVG8gZmFjaWxpdGF0ZSBpbnRlcm9wZXJhYmlsaXR5LCBpdCBpcyANCj4gUkVDT01N RU5ERUQgdGhhdCB0aGUgDQo+ICAgIHJhdGluZyBpbnB1dCBhbmQgdGhlIHZhbHVlcyBvZiB0aGUg c2VydmljZSBpZGVudGlmaWVycyBhcmUgDQo+IGNvb3JkaW5hdGVkIHZpYSANCj4gICAgYW4gaW5m b3JtYXRpb25hbCBSRkMgb3Igb3RoZXIgcGVybWFuZW50IGFuZCByZWFkaWx5IA0KPiBhdmFpbGFi bGUgcmVmZXJlbmNlIA0KPiAgICBzdWNoIGFzIHRoZSBzcGVjaWZpY2F0aW9uIG9mIGFub3RoZXIg Y29vcGVyYXRpdmUgDQo+IHN0YW5kYXJkaXphdGlvbiBib2R5IA0KPiAgICAoZS5nLiAzR1BQLCBP TUEgYW5kIDNHUFAyKSBTSE9VTEQgYmUgdXNlZC4gSG93ZXZlciwgDQo+IHByaXZhdGUgc2Vydmlj ZXMgbWF5IA0KPiAgICBiZSBkZXBsb3llZCB0aGF0IGFyZSBzdWJqZWN0IHRvIGFncmVlbWVudHMg YmV0d2VlbiANCj4gcHJvdmlkZXJzIG9mIHRoZSBjcmVkaXQgDQo+ICAgIGNvbnRyb2wgc2VydmVy IGFuZCBjbGllbnQsIGluIHRoaXMgY2FzZSB2ZW5kb3Igc3BlY2lmaWMgDQo+IEFWUHMgY2FuIGJl IHVzZWQuICANCj4gICAgICAgICANCj4gICAgVGhpcyBzcGVjaWZpY2F0aW9uLCB0b2dldGhlciB3 aXRoIHRoZSBhYm92ZSBzZXJ2aWNlIA0KPiBzcGVjaWZpYyBkb2N1bWVudHMsIA0KPiAgICBnb3Zl cm5zIHRoZSBjcmVkaXQgY29udHJvbCBtZXNzYWdlLiBUaGUgcnVsZSBpcyB0aGF0IA0KPiBzZXJ2 aWNlIHNwZWNpZmljIA0KPiAgICBkb2N1bWVudHMgZGVmaW5lIHdoYXQgZXhpc3RpbmcgQVZQcyBv ciBuZXcgQVZQcyBhcmUgdXNlZCANCj4gYXMgaW5wdXQgdG8gdGhlIA0KPiAgICByYXRpbmcgcHJv Y2VzcyAoaS5lLiB0aGV5IGRvIG5vdCBkZWZpbmUgbmV3IGNyZWRpdCBjb250cm9sIA0KPiBhcHBs aWNhdGlvbnMpLCANCj4gICAgYW5kIHRodXMgbmVlZCB0byBiZSBpbmNsdWRlZCBpbiB0aGUgQ3Jl ZGl0LUNvbnRyb2wtUmVxdWVzdCANCj4gY29tbWFuZCBieSBhIA0KPiAgICBEaWFtZXRlciBDcmVk aXQgQ29udHJvbCBDbGllbnQgc3VwcG9ydGluZyBhIGdpdmVuIHNlcnZpY2UgDQo+IGFzICpbQVZQ XS4gDQo+ICAgIFNob3VsZCBTZXJ2aWNlLVBhcmFtZXRlci1JbmZvIGJlIHVzZWQsIHRoZW4gdGhl IHNlcnZpY2UgDQo+IHNwZWNpZmljIGRvY3VtZW50IA0KPiAgICBNVVNUIHNwZWNpZnkgdGhlIGV4 YWN0IGNvbnRlbnQgb2YgdGhpcyBncm91cGVkIEFWUC4gDQo+ICAgICANCj4gNC4xLjQgSGFuZGxp bmcgb2YgVW5zdXBwb3J0ZWQvSW5jb3JyZWN0IFJhdGluZyBJbnB1dCAgDQo+ICAgICANCj4gICAg RGlhbWV0ZXIgY3JlZGl0IGNvbnRyb2wgaW1wbGVtZW50YXRpb25zIGFyZSByZXF1aXJlZCB0byAN Cj4gc3VwcG9ydCB0aGUgDQo+ICAgIE1hbmRhdG9yeSByYXRpbmcgQVZQcyBkZWZpbmVkIGluIHNl cnZpY2Ugc3BlY2lmaWMgDQo+IGRvY3VtZW50YXRpb24gb2YgdGhlIA0KPiAgICBzZXJ2aWNlcyB0 aGV5IHN1cHBvcnQgYWNjb3JkaW5nIHRvIHRoZSAnTScgYml0IHJ1bGVzIGluIA0KPiBbRElBTUJB U0VdLiAgDQo+ICAgICAgICAgDQo+ICAgIEluIGNhc2UgYSByYXRpbmcgaW5wdXQgcmVxdWlyZWQg Zm9yIHRoZSByYXRpbmcgcHJvY2VzcyBpcyANCj4gaW5jb3JyZWN0IGluIHRoZSANCj4gICAgQ3Jl ZGl0IGNvbnRyb2wgcmVxdWVzdCwgb3IgdGhlIGNyZWRpdCBjb250cm9sIHNlcnZlciBkb2VzIA0K PiBub3Qgc3VwcG9ydCB0aGUgDQo+ICAgIHJlcXVlc3RlZCBzZXJ2aWNlIChpZGVudGlmaWVkIGJ5 IHRoZSBTZXJ2aWNlLUlkbnRpZmllciBBVlAgDQo+IGF0IGNvbW1hbmQgDQo+ICAgIGxldmVsKSwg dGhlIENyZWRpdCBjb250cm9sIGFuc3dlciBNVVNUIGNvbnRhaW4gZXJyb3IgY29kZSANCj4gICAg RElBTUVURVJfUkFUSU5HX0ZBSUxFRC4gQSBDQ1IgbWVzc2FnZSB3aXRoIHRoaXMgZXJyb3IgTVVT VCANCj4gY29udGFpbiBvbmUgb3IgDQo+ICAgIG1vcmUgRmFpbGVkLUFWUCBBVlBzIGNvbnRhaW5p bmcgdGhlIG1pc3NpbmcgYW5kL29yIA0KPiB1bnN1cHBvcnRlZCBBVlBzIHRoYXQgDQo+ICAgIGNh dXNlZCB0aGUgZmFpbHVyZS4gQSBEaWFtZXRlciBjcmVkaXQgY29udHJvbCBjbGllbnQgDQo+IHJl Y2VpdmluZyBlcnJvciBjb2RlIA0KPiAgICBESUFNRVRFUl9SQVRJTkdfRkFJTEVEIGluIGFuc3dl ciB0byBhIHJlcXVlc3QgTVVTVCBOT1QgDQo+IHNlbmQgc3VjaCBzaW1pbGFyIA0KPiAgICByZXF1 ZXN0cyBpbiB0aGUgZnV0dXJlLiANCj4gICAgIA0KPiA0LjEuNSBSQURJVVMgVmVuZG9yLVNwZWNp ZmljIFJhdGluZyBBdHRyaWJ1dGVzIA0KPiAgICAgICAgIA0KPiAgICBXaGVuIHNlcnZpY2Ugc3Bl Y2lmaWMgZG9jdW1lbnRzIGluY2x1ZGUgUkFESVVTIHZlbmRvciANCj4gc3BlY2lmaWMgYXR0cmli dXRlcyANCj4gICAgdGhhdCBjb3VsZCBiZSB1c2VkIGFzIGlucHV0IGluIHRoZSByYXRpbmcgcHJv Y2VzcywgdGhlIA0KPiBydWxlcyBkZXNjcmliZWQgaW4gDQo+ICAgIFtOQVNSRVFdIGZvciBmb3Jt YXR0aW5nIHRoZSBEaWFtZXRlciBBVlAgTVVTVCBiZSBmb2xsb3dlZC4gDQo+IEZvciBleGFtcGxl LCANCj4gICAgdGhlIEFWUCBjb2RlIHVzZWQgaXMgdGhlIHZlbmRvciBhdHRyaWJ1dGUgdHlwZSBj b2RlLCB0aGUgDQo+IFZlbmRvci1TcGVjaWZpYyANCj4gICAgZmxhZyBNVVNUIGJlIHNldCB0byAx IGFuZCB0aGUgVmVuZG9yLUlEIE1VU1QgYmUgc2V0IHRvIHRoZSANCj4gSUFOQSBWZW5kb3IgDQo+ ICAgIGlkZW50aWZpY2F0aW9uIHZhbHVlLiBUaGUgRGlhbWV0ZXIgQVZQIGRhdGEgZmllbGQgY29u dGFpbnMgDQo+IG9ubHkgdGhlIA0KPiAgICBhdHRyaWJ1dGUgdmFsdWUgb2YgdGhlIFJBRElVUyBh dHRyaWJ1dGUuDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTog b3duZXItYWFhLXdnQG1lcml0LmVkdSANCj4gPiBbbWFpbHRvOm93bmVyLWFhYS13Z0BtZXJpdC5l ZHVdT24gQmVoYWxmIE9mDQo+ID4gZXh0IEdsZW4gWm9ybg0KPiA+IFNlbnQ6IDAyIEp1bHksIDIw MDQgMjA6MjcNCj4gPiBUbzogYWFhLXdnQG1lcml0LmVkdQ0KPiA+IFN1YmplY3Q6IA0KPiA+IA0K PiA+IA0KPiA+IERlc2NyaXB0aW9uIG9mIGlzc3VlOiAgTm8gZ3VhcmFudGVlIG9mIGludGVyb3Bl cmFiaWxpdHkgDQo+ID4gYmV0d2VlbiBDQ0EgaW1wbGVtZW50YXRpb25zDQo+ID4gU3VibWl0dGVy IG5hbWU6IEdsZW4gWm9ybg0KPiA+IFN1Ym1pdHRlciBlbWFpbCBhZGRyZXNzOiBnd3pAY2lzY28u Y29tIA0KPiA+IERhdGUgZmlyc3Qgc3VibWl0dGVkOiAyIEp1bHkgMjAwNCANCj4gPiBEb2N1bWVu dDogZGNjYSANCj4gPiBDb21tZW50IHR5cGU6IFQNCj4gPiBQcmlvcml0eTogUw0KPiA+IFNlY3Rp b246IDQuMQ0KPiA+IFJhdGlvbmFsZS9FeHBsYW5hdGlvbiBvZiBpc3N1ZTogDQo+ID4gSW4gb3Jk ZXIgdG8gaW50ZXJvcGVyYXRlLCBEaWFtZXRlciBwZWVycyBpbXBsZW1lbnRpbmcgdGhlIA0KPiA+ IERpYW1ldGVyIENyZWRpdCBDb250cm9sIEFwcGxpY2F0aW9uIG11c3QgYWdyZWUgdXBvbiBib3Ro IHRoZSANCj4gPiBhcHBsaWNhdGlvbiBhbmQgdGhlIHNlcnZpY2UgKHNwZWNpZmllZCBpbiB0aGUg DQo+ID4gU2VydmljZS1JZGVudGlmaWVyIEFWUCkuICBIb3dldmVyLCB0aGUgaW5jbHVzaW9uIG9m IHRoZSANCj4gPiBTZXJ2aWNlLUlkZW50aWZpZXIgaW4gdGhlIENDUiBhbmQgQ0NBIG1lc3NhZ2Vz IGlzIG9wdGlvbmFsLg0KPiA+IA0KPiA+IExlbmd0aHkgZGVzY3JpcHRpb24gb2YgcHJvYmxlbToN Cj4gPiBTZWN0aW9uIDQuMSwgcGFyYS4gNiBzdGF0ZXMgIml0IGlzIHRoZSBjb21iaW5hdGlvbiBv ZiBzdXBwb3J0IA0KPiA+IG9mIHRoZSBEaWFtZXRlciBDcmVkaXQgQ29udHJvbCBBcHBsaWNhdGlv biBhbmQgdGhlIHNlcnZpY2UgDQo+ID4gZGVmaW5lZCBpbiB0aGUgU2VydmljZS1JZGVudGlmaWVy IEFWUCwgd2hpY2ggZGVmaW5lcyANCj4gPiBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gYW55IGdp dmVuIGNyZWRpdCBjb250cm9sIGNsaWVudCBhbmQgDQo+ID4gc2VydmVyLiIgIEhvd2V2ZXIsIHRo ZSBpbmNsdXNpb24gb2YgdGhlIFNlcnZpY2UtSWRlbnRpZmllciBpbiANCj4gPiB0aGUgQ0NSIGFu ZCBDQ0EgbWVzc2FnZXMgaXMgb3B0aW9uYWwuICBUaGlzIGdpdmVzIHJpc2UgdG8gYSANCj4gPiBz aXR1YXRpb24gd2hlcmUgdHdvIHBlZXJzIGltcGxlbWVudGluZyB0aGUgc2FtZSBhcHBsaWNhdGlv biANCj4gPiBtYXkgbm90IGludGVyb3BlcmF0ZSBiZWNhdXNlIHRoZXkgZG8gbm90IGltcGxlbWVu dCB0aGUgc2FtZSANCj4gPiAic2VydmljZSIsIGFuZCBmdXJ0aGVyLCByZWZ1c2UgdG8gY2xlYXJs eSBjb21tdW5pY2F0ZSB0aGF0IGZhY3QuDQo+ID4gDQo+ID4gUmVxdWVzdGVkIGNoYW5nZTogDQo+ ID4gQ2hhbmdlIHNlY3Rpb24gNC4xLCBwYXJhZ3JhcGggNSBmcm9tDQo+ID4gDQo+ID4gICAgVGhp cyBzcGVjaWZpY2F0aW9uLCB0b2dldGhlciB3aXRoIHNlcnZpY2Ugc3BlY2lmaWMgZG9jdW1lbnRz LCBpcyANCj4gPiAgICBnb3Zlcm5pbmcgdGhlIGNyZWRpdCBjb250cm9sIG1lc3NhZ2UuIFRoZSBy dWxlIGlzIHRoYXQgc2VydmljZSANCj4gPiAgICBzcGVjaWZpYyBkb2N1bWVudHMgb25seSBkZWZp bmUgd2hhdCBleGlzdGluZyBBVlBzIG9yIG5ldyANCj4gQVZQcyBhcmUgDQo+ID4gICAgdXNlZCBh cyBpbnB1dCB0byB0aGUgcmF0aW5nIHByb2Nlc3MgKGkuZS4gdGhleSBkbyBub3QgZGVmaW5lIG5l dyANCj4gPiAgICBjcmVkaXQgY29udHJvbCBhcHBsaWNhdGlvbnMpLCBhbmQgdGh1cyBuZWVkIHRv IGJlIA0KPiBpbmNsdWRlZCBpbiB0aGUgDQo+ID4gICAgQ3JlZGl0LUNvbnRyb2wtUmVxdWVzdCBj b21tYW5kIGJ5IGEgRGlhbWV0ZXIgQ3JlZGl0IA0KPiBDb250cm9sIENsaWVudCANCj4gPiAgICBz dXBwb3J0aW5nIGEgZ2l2ZW4gc2VydmljZSBhcyAqW0FWUF0uIEluIG9yZGVyIHRvIGRlZmluZSAN Cj4gbmV3IEFWUHMsIA0KPiA+ICAgIHNlcnZpY2Ugc3BlY2lmaWMgZG9jdW1lbnRzIE1VU1QgZm9s bG93IHRoZSBwcmFjdGljZXMgZGVmaW5lZCBpbiANCj4gPiAgICBbRElBTUJBU0VdLiBUaGUgc2Vy dmljZSBTSE9VTEQgYmUgaWRlbnRpZmllZCB1c2luZyB0aGUgU2VydmljZS0gDQo+ID4gICAgSWRl bnRpZmllciBBVlAuIFRoZSBTZXJ2aWNlLUlkZW50aWZpZXIgQVZQIE1VU1QgYmUgYSB1bmlxdWUg DQo+ID4gICAgaWRlbnRpZmllciBmb3IgYSBnaXZlbiBzZXJ2aWNlIGFzIGRlZmluZWQgaW4gc2Vj dGlvbiA4LjI4LiANCj4gPiANCj4gPiB0bw0KPiA+IA0KPiA+ICAgIFRoaXMgc3BlY2lmaWNhdGlv biwgdG9nZXRoZXIgd2l0aCBzZXJ2aWNlIHNwZWNpZmljIGRvY3VtZW50cywgaXMgDQo+ID4gICAg Z292ZXJuaW5nIHRoZSBjcmVkaXQgY29udHJvbCBtZXNzYWdlLiBUaGUgcnVsZSBpcyB0aGF0IHNl cnZpY2UgDQo+ID4gICAgc3BlY2lmaWMgZG9jdW1lbnRzIG9ubHkgZGVmaW5lIHdoYXQgZXhpc3Rp bmcgQVZQcyBvciBuZXcgDQo+IEFWUHMgYXJlIA0KPiA+ICAgIHVzZWQgYXMgaW5wdXQgdG8gdGhl IHJhdGluZyBwcm9jZXNzIChpLmUuIHRoZXkgZG8gbm90IGRlZmluZSBuZXcgDQo+ID4gICAgY3Jl ZGl0IGNvbnRyb2wgYXBwbGljYXRpb25zKSwgYW5kIHRodXMgbmVlZCB0byBiZSANCj4gaW5jbHVk ZWQgaW4gdGhlIA0KPiA+ICAgIENyZWRpdC1Db250cm9sLVJlcXVlc3QgY29tbWFuZCBieSBhIERp YW1ldGVyIENyZWRpdCANCj4gQ29udHJvbCBDbGllbnQgDQo+ID4gICAgc3VwcG9ydGluZyBhIGdp dmVuIHNlcnZpY2UgYXMgKltBVlBdLiBJbiBvcmRlciB0byBkZWZpbmUgDQo+IG5ldyBBVlBzLCAN Cj4gPiAgICBzZXJ2aWNlIHNwZWNpZmljIGRvY3VtZW50cyBNVVNUIGZvbGxvdyB0aGUgcHJhY3Rp Y2VzIGRlZmluZWQgaW4gDQo+ID4gICAgW0RJQU1CQVNFXS4gVGhlIHNlcnZpY2UgTVVTVCBiZSBp ZGVudGlmaWVkIHVzaW5nIHRoZSBTZXJ2aWNlLSANCj4gPiAgICBJZGVudGlmaWVyIEFWUC4gVGhl IFNlcnZpY2UtSWRlbnRpZmllciBBVlAgTVVTVCBiZSBhIHVuaXF1ZSANCj4gPiAgICBpZGVudGlm aWVyIGZvciBhIGdpdmVuIHNlcnZpY2UgYXMgZGVmaW5lZCBpbiBzZWN0aW9uIDguMjguIA0KPiA+ IA0KPiA+IH5nd3oNCj4gPiANCj4gPiAiVGhleSB0aGF0IGNhbiBnaXZlIHVwIGVzc2VudGlhbCBs aWJlcnR5IHRvIG9idGFpbiBhIGxpdHRsZSANCj4gPiB0ZW1wb3Jhcnkgc2FmZXR5IGRlc2VydmUg bmVpdGhlci4uLiINCj4gPiAtLSBCZW5qYW1pbiBGcmFua2xpbiwgMTc1OSANCj4gPiANCj4gPiAN Cj4gPiAiSXQgaXMgZm9yYmlkZGVuIHRvIGtpbGw7IHRoZXJlZm9yZSBhbGwgbXVyZGVyZXJzIGFy ZSANCj4gPiBwdW5pc2hlZCB1bmxlc3MgdGhleSBraWxsIGluIGxhcmdlIG51bWJlcnMgYW5kIHRv IHRoZSBzb3VuZCANCj4gPiBvZiB0cnVtcGV0cy4iDQo+ID4gLS0gVm9sdGFpcmUNCj4gPiANCj4g PiANCj4gDQo= From owner-aaa-wg@merit.edu Mon Jul 5 07:22: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 HAA21046 for ; Mon, 5 Jul 2004 07:22:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7DF1D91222; Mon, 5 Jul 2004 07:22:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4BA2891241; Mon, 5 Jul 2004 07:22:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CE3BA91222 for ; Mon, 5 Jul 2004 07:22:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BB78459CA4; Mon, 5 Jul 2004 07:22:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 05BCD59EAD for ; Mon, 5 Jul 2004 07:22:21 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i65BMEN14379; Mon, 5 Jul 2004 14:22:14 +0300 (EET DST) X-Scanned: Mon, 5 Jul 2004 14:21:32 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i65BLWnU023295; Mon, 5 Jul 2004 14:21:32 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00p8B9oH; Mon, 05 Jul 2004 14:21:29 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i65BLTH26672; Mon, 5 Jul 2004 14:21:29 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Jul 2004 14:21:05 +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="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [AAA-WG]: Issue with draft-ietf-aaa-diameter-cc-05.txt Date: Mon, 5 Jul 2004 14:21:05 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D0298AA76@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue with draft-ietf-aaa-diameter-cc-05.txt Thread-Index: AcRgYjKABfGq0mQETqy9t+jwqM1FEQCClC2Q From: To: Cc: X-OriginalArrivalTime: 05 Jul 2004 11:21:05.0586 (UTC) FILETIME=[29911120:01C46282] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: base64 SGkgR2xlbiwNCg0KYWN0dWFsbHkgdGhlIFdHIGxhc3QgY2FsbCBlbmRlZCBhIHdoaWxlIGFnbywg dGhlIGRyYWZ0IGhhcyBhbHJlYWR5IGJlZW4NCnJldmlldyBieSB0aGUgSUVTRyAoYXMgeW91IG1h eSBoYXZlIG5vdGljZWQgZnJvbSBteSBwcmV2aW91cyBlbWFpbCkuDQpBcyB5b3Uga25vdyBjaGFu Z2VzIGFyZSBub3QgYWxsb3dlZCBhdCB0aGlzIHN0YWdlLCB1bmxlc3MgZXhwbGljaXRseQ0KcmVx dWVzdGVkIGJ5IHRoZSBJRVNHIG9yIG1ham9yIGJ1Z3MgYXJlIGRpc2NvdmVyZWQuDQoNCldlIGhh dmUgZGlzY3Vzc2VkIGFtb25nIGF1dGhvcnMgYSB5ZWFyIGFnbyB0aGUgcG9zc2liaWxpdHkgb2Yg dXNpbmcgQ0VSL0NFQSANCmFzIHlvdSBwcm9wb3NlLiBXaGlsZSBpbmNsdWRpbmcgdGhlIFNlcnZp Y2UtSWRlbnRpZmllciBBVlAgaW4NCkNFUi9DRUEgKm1heSogd29yayBpbiBjYXNlIG9mIGRpcmVj dCBjb25uZWN0aW9uIHRvIHRoZSBzZXJ2ZXIsIGl0IHdvbid0IGhlbHANCmlmIGUuZy4gcmVsYXkg YWdlbnRzIHdlcmUgcHJlc2VudCBpbiBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyLg0KQWxsIHRo ZSBjbGllbnQgd291bGQga25vdyBmcm9tIGFuIGltbWVkaWF0ZSBwZWVyIHRoYXQgYWR2ZXJ0aXNl cyBpdCBzZWxmIGFzIGENCnJlbGF5IGFnZW50IGlzIHRoYXQgYW55IG1lc3NhZ2UgY2FuIGJlIHNl bnQgb3ZlciB0aGVyZS4gQmVjYXVzZSB0aGUgYmFzZQ0KcHJvdG9jb2wgaXMgd29ya2luZyBzb2xl bHkgb24gdGhlIGJhc2lzIG9mIHRoZSBBcHBsaWNhdGlvbi1JZGVudGlmaWVyLCBldmVuDQp0aG91 Z2ggdGhlIHNlcnZlciB3b3VsZCBhZHZlcnRpc2UgU2VydmljZS1JZHMgdG8gdGhlIHJlbGF5IGFn ZW50LCB0aGUgcmVsYXkNCmFnZW50IHdvdWxkIHN0aWxsIGRlbGl2ZXIgQ0NSIG1lc3NhZ2VzIHRv IHRoZSBzZXJ2ZXIgcmVnYXJkbGVzcyB0aGUNCnNlcnZpY2UtaWQuIFRoZSBvdGhlciBwcm9ibGVt IG9mIGluY2x1ZGluZyB0aGUgU2VydmljZS1JZCBpbiBDRVIvQ0VBIGlzIHRoYXQgDQpvbmUgY2Fu IGhhdmUgbmVnb3RpYXRlIGFwcGxpY2F0aW9uLWlkcyBpbiBvbmUgQ0VSIGNvbW1hbmQsIGFuZCB0 aGVyZWZvcmUgdGhlcmUgDQppcyBhIHJpc2sgdGhhdCB0aGUgcmVjZWl2ZXIgY2FuJ3QgYmUgc3Vy ZSB0byB3aGljaCBhcHBsaWNhdGlvbiB0aGUgU2VydmljZS1JZCANCmlzIHJlbGF0ZWQgdG8sIGlu IGNhc2Ugc2V2ZXJhbCBhcHBsaWNhdGlvbnMgd291bGQgYWRvcHQgdGhlIHNhbWUgbWVjaGFuaXNt IGluIA0KdGhlIGZ1dHVyZS4gV2UgZmluYWxseSB0aG91Z2h0IHRoYXQgaWYgd2UgaW50cm9kdWNl IGEgbWVjaGFuaXNtLCB0aGlzIG11c3Qgd29yayBpbg0KYWxsIHRoZSBwb3NzaWJsZSBBQUEgbmV0 d29yayB0b3BvbG9naWVzIGFuZCBzY2VuYXJpb3MsIHdlIHRoZW4gZGlzY2FyZGVkIHRoZSBDRVIv Q0VBDQphbmQgd2UgZW5kZWQgdXAgdG8gdGhlIGVuZC10by1lbmQgZGlzY292ZXJ5IGRvY3VtZW50 ZWQgaW4gdGhlIERDQyBkcmFmdC4NCg0KSSB0aGluayBpdCB3b3VsZCBiZSBtb3JlIGFwcHJvcHJp YXRlIHRvIGVuaGFuY2UgdGhlIGNhcGFiaWxpdHkgZXhjaGFuZ2UNCnBvc3NpYmx5IGluIGEgbmV4 dCB2ZXJzaW9uIG9mIHRoZSBiYXNlIHByb3RvY29sIHJhdGhlciB0aGFuIGluIHRoZSBEQ0MsIHNp bmNlIA0KbWFueSBvdGhlciBhcHBsaWNhdGlvbnMgbWF5IGJlbmVmaXQgZnJvbSBpdC4NCg0KRm9y IHRoZSB0aW1lIGJlaW5nIEkgdGhpbmsgd2hhdCB3ZSBoYXZlIGlzIGVub3VnaC4gQXQgdGhlIGZp cnN0IENDUiBzZW50DQp0byB0aGUgc2VydmVyLCB0aGUgc2VydmVyIHdpbGwgcmVqZWN0IHRoZSBy ZXF1ZXN0IGlmIHRoZSBzZXJ2aWNlIGluZGljYXRlZA0KaW4gdGhlIFNlcnZpY2UtSWRlbnRpZmll ciBBVlAgaXMgbm90IHN1cHBvcnRlZC4gVGhlIFJlc3VsdC1jb2RlIGluIENDQSBpcyANCnNldCB0 byBESUFNRVRFUl9SQVRJTkdfRkFJTEVEIGFuZCB0aGUgRmFpbGVkIEFWUCBpbmNsdWRlcyB0aGUg U2VydmljZS1JZCBBVlAuDQpUaGUgY2xpZW50IE1VU1QgTk9UIHNlbmQgc3VjaCBzaW1pbGFyIHJl cXVlc3QgaW4gdGhlIGZ1dHVyZSAodHlwaWNhbGx5IHVudGlsIGENCm5ldyBDRVIvQ0VBIGlzIHBl cmZvcm1lZCkuIEFzIEkgc2F5IHRoaXMgaXMgYWxyZWFkeSBjb3ZlcmVkIGluIHRoZSBkcmFmdCwg DQpob3dldmVyLCBzaW5jZSB3ZSBhcmUgdXBkYXRpbmcgdGhlIGRyYWZ0IChJRVNHIHJldmlldykg d2UgY2FuIG1ha2UgaXQgZXZlbiANCm1vcmUgZXhwbGljaXQgaW4gdGhlIG5ldyA0LjEuMi80LjEu NCBzdWItc2VjdC4sIGZvciBpbnN0YW5jZQ0KDQo0LjEuMiBBcHBsaWNhdGlvbiBTdXBwb3J0IA0K ICAgIA0KICAgU2luY2UgdGhlIEFwcGxpY2F0aW9uLUlkIG9mIHRoZSBEaWFtZXRlciBDcmVkaXQg Q29udHJvbCBBcHBsaWNhdGlvbiBkb2VzIA0KICAgbm90IHVuaXF1ZWx5IGlkZW50aWZ5IHRoZSBz ZXJ2aWNlIGJlaW5nIG1vbml0b3JlZCwgYW4gYWRkaXRpb25hbCBtZWNoYW5pc20gDQogICBpcyBu ZWVkZWQuIFRoZSBzZXJ2aWNlIGFwcGxpY2F0aW9uIE1VU1QgYmUgaWRlbnRpZmllZCB1c2luZyB0 aGUgU2VydmljZS0NCiAgIElkZW50aWZpZXIgQVZQIGF0IGNvbW1hbmQgbGV2ZWwuIEEgc2VydmVy IHJlY2VpdmluZyBhIHJlcXVlc3QgZm9yIGEgDQogICBzZXJ2aWNlIGFwcGxpY2F0aW9uIGl0IGRv ZXMgbm90IHN1cHBvcnQgd2lsbCByZWplY3QgdGhlIHJlcXVlc3QgYXMgZGVmaW5lZCANCiAgIGlu IHN1Yi1zZWN0aW9uIDQuMS40LjsgdGhlIGNsaWVudCB3aWxsIG5vdCBzZW5kIHN1Y2ggc2ltaWxh ciByZXF1ZXN0DQogICBpbiB0aGUgZnV0dXJlLiBUaGlzIGlzIGVmZmVjdGl2ZWx5IGFuIGVuZC10 by1lbmQgZGlzY292ZXJ5IG9mIHRoZQ0KICAgc2VydmljZSBhcHBsaWNhdGlvbiB0aGUgY3JlZGl0 IGNvbnRyb2wgc2VydmVyIGlzIHN1cHBvcnRpbmcuDQogICBUaGUgU2VydmljZS1JZGVudGlmaWVy IEFWUCBNVVNUIGJlIGEgdW5pcXVlIGlkZW50aWZpZXIgZm9yIGEgZ2l2ZW4gc2VydmljZSANCiAg IGFzIGRlZmluZWQgaW4gc2VjdGlvbiA4LjI4LiAgDQogICAgDQogICBUaHVzLCB0aGUgY29tYmlu YXRpb24gb2YgdGhlIERpYW1ldGVyIENyZWRpdCBDb250cm9sIEFwcGxpY2F0aW9uLUlkIGFuZCAN CiAgIHRoZSBTZXJ2aWNlLUlkZW50aWZpZXIgQVZQIGluIHRoZSBDcmVkaXQtQ29udHJvbC1SZXF1 ZXN0IGNvbW1hbmQgdW5pcXVlbHkgDQogICBkZWZpbmVzIHRoZSBzZXJ2aWNlIHdpdGhpbiB0aGUg Y29udGV4dCBvZiB0aGUgRGlhbWV0ZXIgQ3JlZGl0IENvbnRyb2wsIGFuZCANCiAgIGhlbmNlIHBy b3ZpZGVzIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBEaWFtZXRlciBjcmVkaXQgY29udHJvbCBj bGllbnRzIA0KICAgYW5kIHNlcnZlci4gDQogICAgDQogICBXaXRoIHRoaXMgbWVjaGFuaXNtIGl0 IGlzIHBvc3NpYmxlIHRvIGNvdmVyIGFkZGl0aW9uYWwgc2VydmljZSBzcGVjaWZpYyANCiAgIHJl cXVpcmVtZW50cyBhcyBuZWVkZWQgaW4gb3RoZXIgZG9jdW1lbnRzLiBIb3dldmVyLCBpbnRyb2R1 Y2luZyBuZXcgY3JlZGl0IA0KICAgY29udHJvbCBtZWNoYW5pc21zIHRvIHRoZSBmcmFtZXdvcmsg ZGVmaW5lZCBpbiB0aGlzIHNwZWNpZmljYXRpb24sIHJlcXVpcmUgDQogICBkZWZpbml0aW9uIG9m IGEgbmV3IHZlcnNpb24gb2YgdGhlIERpYW1ldGVyIENyZWRpdCBDb250cm9sIEFwcGxpY2F0aW9u IGFuZCANCiAgIGNvcnJlc3BvbmRpbmcgQXBwbGljYXRpb24gSWRlbnRpZmllci4NCg0KNC4xLjQg SGFuZGxpbmcgb2YgVW5zdXBwb3J0ZWQvSW5jb3JyZWN0IFJhdGluZyBJbnB1dCAgDQogICAgDQog ICBEaWFtZXRlciBjcmVkaXQgY29udHJvbCBpbXBsZW1lbnRhdGlvbnMgYXJlIHJlcXVpcmVkIHRv IHN1cHBvcnQgdGhlIA0KICAgTWFuZGF0b3J5IHJhdGluZyBBVlBzIGRlZmluZWQgaW4gc2Vydmlj ZSBzcGVjaWZpYyBkb2N1bWVudGF0aW9uIG9mIHRoZSANCiAgIHNlcnZpY2VzIHRoZXkgc3VwcG9y dCBhY2NvcmRpbmcgdG8gdGhlICdNJyBiaXQgcnVsZXMgaW4gW0RJQU1CQVNFXS4gIA0KICAgICAg ICANCiAgIEluIGNhc2UgYSByYXRpbmcgaW5wdXQgcmVxdWlyZWQgZm9yIHRoZSByYXRpbmcgcHJv Y2VzcyBpcyBpbmNvcnJlY3QgaW4gdGhlIA0KICAgQ3JlZGl0IGNvbnRyb2wgcmVxdWVzdCwgb3Ig dGhlIGNyZWRpdCBjb250cm9sIHNlcnZlciBkb2VzIG5vdCBzdXBwb3J0IHRoZSANCiAgIHJlcXVl c3RlZCBzZXJ2aWNlIChpZGVudGlmaWVkIGJ5IHRoZSBTZXJ2aWNlLUlkbnRpZmllciBBVlAgYXQg Y29tbWFuZCANCiAgIGxldmVsKSwgdGhlIENyZWRpdCBjb250cm9sIGFuc3dlciBNVVNUIGNvbnRh aW4gZXJyb3IgY29kZSANCiAgIERJQU1FVEVSX1JBVElOR19GQUlMRUQuIEEgQ0NSIG1lc3NhZ2Ug d2l0aCB0aGlzIGVycm9yIE1VU1QgY29udGFpbiBvbmUgb3IgDQogICBtb3JlIEZhaWxlZC1BVlAg QVZQcyBjb250YWluaW5nIHRoZSBtaXNzaW5nIGFuZC9vciB1bnN1cHBvcnRlZCBBVlBzIHRoYXQg DQogICBjYXVzZWQgdGhlIGZhaWx1cmUuIEEgRGlhbWV0ZXIgY3JlZGl0IGNvbnRyb2wgY2xpZW50 IHJlY2VpdmluZyBlcnJvciBjb2RlIA0KICAgRElBTUVURVJfUkFUSU5HX0ZBSUxFRCBpbiBhbnN3 ZXIgdG8gYSByZXF1ZXN0IE1VU1QgTk9UIHNlbmQgc3VjaCBzaW1pbGFyIA0KICAgcmVxdWVzdHMg aW4gdGhlIGZ1dHVyZSAodHlwaWNhbGx5IHVudGlsIGEgbmV3IGNhcGFiaWxpdHkgZXhjaGFuZ2UN CiAgIG5lZ290aWF0aW9uIGlzIHBlcmZvcm1lZCBhY2NvcmRpbmcgW0RJQU1CQVNFXSkuDQoNClJl Z2FyZHMNCk1hcmNvDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb3du ZXItYWFhLXdnQG1lcml0LmVkdSANCj4gW21haWx0bzpvd25lci1hYWEtd2dAbWVyaXQuZWR1XU9u IEJlaGFsZiBPZg0KPiBleHQgR2xlbiBab3JuDQo+IFNlbnQ6IDAyIEp1bHksIDIwMDQgMjE6MjYN Cj4gVG86IGFhYS13Z0BtZXJpdC5lZHUNCj4gU3ViamVjdDogW0FBQS1XR106IElzc3VlIHdpdGgg ZHJhZnQtaWV0Zi1hYWEtZGlhbWV0ZXItY2MtMDUudHh0DQo+IA0KPiANCj4gRGVzY3JpcHRpb24g b2YgaXNzdWU6IE5vIGFkdmVydGlzZW1lbnQgb2Ygc2VydmljZSB0eXBlIGluIENFUi9DRUEgDQo+ IFN1Ym1pdHRlciBuYW1lOiBHbGVuIFpvcm4NCj4gU3VibWl0dGVyIGVtYWlsIGFkZHJlc3M6IGd3 ekBjaXNjby5jb20NCj4gRGF0ZSBmaXJzdCBzdWJtaXR0ZWQ6IDIgSnVseSAyMDA0DQo+IERvY3Vt ZW50OiBjY2ENCj4gQ29tbWVudCB0eXBlOiBUDQo+IFByaW9yaXR5OiBTIA0KPiBTZWN0aW9uOiAx LjMNCj4gUmF0aW9uYWxlL0V4cGxhbmF0aW9uIG9mIGlzc3VlOiBUaGUgU2VydmljZS1JZGVudGlm aWVyIEFWUCBpcyANCj4gbm90IGluY2x1ZGVkIGluIHRoZSBDRVIvQ0VBIG1lc3NhZ2VzLg0KPiBM ZW5ndGh5IGRlc2NyaXB0aW9uIG9mIHByb2JsZW06DQo+IFNlY3Rpb24gNC4xLCBwYXJhLiA2IHN0 YXRlcyAiaXQgaXMgdGhlIGNvbWJpbmF0aW9uIG9mIHN1cHBvcnQgDQo+IG9mIHRoZSBEaWFtZXRl ciBDcmVkaXQgQ29udHJvbCBBcHBsaWNhdGlvbiBhbmQgdGhlIHNlcnZpY2UgDQo+IGRlZmluZWQg aW4gdGhlIFNlcnZpY2UtSWRlbnRpZmllciBBVlAsIHdoaWNoIGRlZmluZXMgDQo+IGludGVyb3Bl cmFiaWxpdHkgYmV0d2VlbiBhbnkgZ2l2ZW4gY3JlZGl0IGNvbnRyb2wgY2xpZW50IGFuZCANCj4g c2VydmVyLiIgIEhvd2V2ZXIsIGluY2x1c2lvbiBvZiB0aGUgU2Vzc2lvbi1JZGVudGlmaWVyIEFW UCBpbiANCj4gdGhlIENFUi9DRUEgZXhjaGFuZ2UgaXMgbm90IG1hbmRhdGVkLiAgVGhpcyBjb3Vs ZCBsZWFkIHRvIGEgDQo+IHNpdHVhdGlvbiB3aGVyZSBwZWVycyBoYXZlIHN1Y2Nlc3NmdWxseSBu ZWdvdGlhdGVkIA0KPiBhcHBsaWNhdGlvbiBzdXBwb3J0LCBidXQgY2Fubm90IGludGVyb3BlcmF0 ZS4gDQo+IA0KPiBSZXF1ZXN0ZWQgY2hhbmdlOiANCj4gQ2hhbmdlIHNlY3Rpb24gMS4zIGZyb20N Cj4gDQo+ICAgIERpYW1ldGVyIG5vZGVzIGNvbmZvcm1pbmcgdG8gdGhpcyBzcGVjaWZpY2F0aW9u IE1VU1QgYWR2ZXJ0aXNlIA0KPiAgICBzdXBwb3J0IGJ5IGluY2x1ZGluZyB0aGUgdmFsdWUgb2Yg NCBpbiB0aGUgDQo+IEF1dGgtQXBwbGljYXRpb24tSWQgb2YgdGhlIA0KPiAgICBDYXBhYmlsaXRp ZXMtRXhjaGFuZ2UtUmVxdWVzdCBhbmQgQ2FwYWJpbGl0aWVzLUV4Y2hhbmdlLUFuc3dlciANCj4g ICAgY29tbWFuZCBbRElBTUJBU0VdLiAgDQo+IA0KPiB0bw0KPiANCj4gICAgRGlhbWV0ZXIgbm9k ZXMgY29uZm9ybWluZyB0byB0aGlzIHNwZWNpZmljYXRpb24gTVVTVCBhZHZlcnRpc2UgDQo+ICAg IHN1cHBvcnQgYnkgaW5jbHVkaW5nIG9uZSBvciBtb3JlIFNlc3Npb24tSWRlbnRpZmllciBBVlBz IA0KPiAoY29ycmVzcG9uZGluZyB0byB0aGUgc3VwcG9ydGVkIA0KPiAgICBzZXJ2aWNlcykgYW5k IHNldHRpbmcgdGhlIHZhbHVlIG9mIDQgaW4gdGhlIA0KPiBBdXRoLUFwcGxpY2F0aW9uLUlkIG9m IHRoZSANCj4gICAgQ2FwYWJpbGl0aWVzLUV4Y2hhbmdlLVJlcXVlc3QgYW5kIA0KPiBDYXBhYmls aXRpZXMtRXhjaGFuZ2UtQW5zd2VyIGNvbW1hbmQgW0RJQU1CQVNFXS4gIA0KPiANCj4gQWRkIFNl Y3Rpb24gMTAuMzoNCj4gDQo+IDEwLjMgQ2FwYWJpbGl0aWVzLUV4Y2hhbmdlLVJlcXVlc3QvQW5z d2VyIEFWUCBUYWJsZSANCj4gICAgIA0KPiAgICBUaGlzIHNlY3Rpb24gZGVmaW5lcyBBVlBzIHRo YXQgYXJlIHNwZWNpZmljIHRvIERpYW1ldGVyIENyZWRpdCAgDQo+ICAgIENvbnRyb2wgQXBwbGlj YXRpb24gYW5kIE1VU1QgYmUgaW5jbHVkZWQgaW4gdGhlIERpYW1ldGVyIA0KPiAgICBDYXBhYmls aXRpZXMtRXhjaGFuZ2UtUmVxdWVzdC9BbnN3ZXIgKENFUi9DRUEpIG1lc3NhZ2UgDQo+IFtESUFN QkFTRV0uICANCj4gICAgICAgICANCj4gICAgVGhlIENhcGFiaWxpdGllcy1FeGNoYW5nZS1SZXF1 ZXN0L0Fuc3dlciBjb21tYW5kcyBNVVNUIGluY2x1ZGUgdGhlIA0KPiAgICBmb2xsb3dpbmcgYWRk aXRpb25hbCBBVlBzOiANCj4gICAgIA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0rICAgDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCBDb21tYW5kIENvZGUgIHwgIA0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwtLS0tLS0tKy0tLS0tLS0rICAgDQo+ICAgICAgICAgQXR0cmlidXRl IE5hbWUgICAgICAgICAgICAgICAgfCAgQ0VSICB8ICBDRUEgIHwgICANCj4gICAgICAgICAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tKyAgIA0KPiAgICAgICAg IFNlcnZpY2UtSWRlbnRpZmllciAgICAgICAgICAgIHwgIDErICAgfCAgMSsgICB8IA0KPiAgICAg ICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rIA0KPiAN Cj4gfmd3eg0KPiANCj4gIlRoZXkgdGhhdCBjYW4gZ2l2ZSB1cCBlc3NlbnRpYWwgbGliZXJ0eSB0 byBvYnRhaW4gYSBsaXR0bGUgDQo+IHRlbXBvcmFyeSBzYWZldHkgZGVzZXJ2ZSBuZWl0aGVyLi4u Ig0KPiAtLSBCZW5qYW1pbiBGcmFua2xpbiwgMTc1OSANCj4gDQo+IA0KPiAiSXQgaXMgZm9yYmlk ZGVuIHRvIGtpbGw7IHRoZXJlZm9yZSBhbGwgbXVyZGVyZXJzIGFyZSANCj4gcHVuaXNoZWQgdW5s ZXNzIHRoZXkga2lsbCBpbiBsYXJnZSBudW1iZXJzIGFuZCB0byB0aGUgc291bmQgDQo+IG9mIHRy dW1wZXRzLiINCj4gLS0gVm9sdGFpcmUNCj4gDQo+IA0K From owner-aaa-wg@merit.edu Mon Jul 5 14:06: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 OAA09224 for ; Mon, 5 Jul 2004 14:06:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 560099126B; Mon, 5 Jul 2004 14:04:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1713F91271; Mon, 5 Jul 2004 14:04:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4512A9126B for ; Mon, 5 Jul 2004 14:04:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 744DE59F8C; Mon, 5 Jul 2004 14:04:38 -0400 (EDT) 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 5DFF159A13 for ; Mon, 5 Jul 2004 14:04:37 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 05 Jul 2004 11:10:29 +0000 X-BrightmailFiltered: true Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i65I4Y4N027978; Mon, 5 Jul 2004 11:04:34 -0700 (PDT) Received: from gwzw2k (sjc-vpn3-1021.cisco.com [10.21.67.253]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id LAA20004; Mon, 5 Jul 2004 11:04:33 -0700 (PDT) Reply-To: From: "Glen Zorn" To: Cc: Subject: RE: [AAA-WG]: Issue with draft-ietf-aaa-diameter-cc-05.txt Date: Mon, 5 Jul 2004 11:04:02 -0700 Organization: Cisco Systems Message-ID: <003401c462ba$8639a3a0$0202a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D0298AA76@esebe016.ntc.nokia.com> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit marco.stura@nokia.com writes: > Hi Glen, > > actually the WG last call ended a while ago, the draft has already > been review by the IESG (as you may have noticed from my previous > email). As you know changes are not allowed at this stage, unless > explicitly requested by the IESG or major bugs are discovered. Sorry, I'll wait for IETF Last Call, then. > > We have discussed among authors a year ago the possibility of using > CER/CEA as you propose. While including the Service-Identifier AVP in > CER/CEA *may* work in case of direct connection to the server, it > won't help if e.g. relay agents were present in between client and > server. All the client would know from an immediate peer that > advertises it self as a relay agent is that any message can be sent > over there. Because the base protocol is working solely on the basis > of the Application-Identifier, even though the server would advertise > Service-Ids to the relay agent, the relay agent would still deliver > CCR messages to the server regardless the service-id. The other > problem of including the Service-Id in CER/CEA is that one can have > negotiate application-ids in one CER command, and therefore there is > a risk that the receiver can't be sure to which application the > Service-Id is related to, in case several applications would adopt > the same mechanism in the future. We finally thought that if we > introduce a mechanism, this must work in all the possible AAA network > topologies and scenarios, we then discarded the CER/CEA and we ended > up to the end-to-end discovery documented in the DCC draft. > > I think it would be more appropriate to enhance the capability > exchange possibly in a next version of the base protocol rather than > in the DCC, since many other applications may benefit from it. > > For the time being I think what we have is enough. At the first CCR > sent to the server, the server will reject the request if the service > indicated in the Service-Identifier AVP is not supported. The > Result-code in CCA is set to DIAMETER_RATING_FAILED and the Failed > AVP includes the Service-Id AVP. The client MUST NOT send such > similar request in the future (typically until a new CER/CEA is > performed). As I say this is already covered in the draft, however, > since we are updating the draft (IESG review) we can make it even > more explicit in the new 4.1.2/4.1.4 sub-sect., for instance > > 4.1.2 Application Support > > Since the Application-Id of the Diameter Credit Control > Application does not uniquely identify the service being > monitored, an additional mechanism is needed. The service > application MUST be identified using the Service- Identifier AVP > at command level. A server receiving a request for a service > application it does not support will reject the request as defined > in sub-section 4.1.4.; the client will not send such similar > request in the future. This is effectively an end-to-end discovery > of the service application the credit control server is > supporting. The Service-Identifier AVP MUST be a unique identifier > for a given service as defined in section 8.28. > > Thus, the combination of the Diameter Credit Control > Application-Id and the Service-Identifier AVP in the > Credit-Control-Request command uniquely defines the service within > the context of the Diameter Credit Control, and hence provides > interoperability between Diameter credit control clients and > server. > > With this mechanism it is possible to cover additional service > specific requirements as needed in other documents. However, > introducing new credit control mechanisms to the framework defined > in this specification, require definition of a new version of the > Diameter Credit Control Application and corresponding Application > Identifier. > > 4.1.4 Handling of Unsupported/Incorrect Rating Input > > Diameter credit control implementations are required to support the > Mandatory rating AVPs defined in service specific documentation of > the services they support according to the 'M' bit rules in > [DIAMBASE]. > > In case a rating input required for the rating process is > incorrect in the Credit control request, or the credit control > server does not support the requested service (identified by the > Service-Idntifier AVP at command level), the Credit control answer > MUST contain error code DIAMETER_RATING_FAILED. A CCR message with > this error MUST contain one or more Failed-AVP AVPs containing the > missing and/or unsupported AVPs that caused the failure. A > Diameter credit control client receiving error code > DIAMETER_RATING_FAILED in answer to a request MUST NOT send such > similar requests in the future (typically until a new capability > exchange negotiation is performed according [DIAMBASE]). > > Regards > Marco > >> -----Original Message----- >> From: owner-aaa-wg@merit.edu >> [mailto:owner-aaa-wg@merit.edu]On Behalf Of >> ext Glen Zorn >> Sent: 02 July, 2004 21:26 >> To: aaa-wg@merit.edu >> Subject: [AAA-WG]: Issue with draft-ietf-aaa-diameter-cc-05.txt >> >> >> Description of issue: No advertisement of service type in CER/CEA >> Submitter name: Glen Zorn Submitter email address: gwz@cisco.com >> Date first submitted: 2 July 2004 >> Document: cca >> Comment type: T >> Priority: S >> Section: 1.3 >> Rationale/Explanation of issue: The Service-Identifier AVP is >> not included in the CER/CEA messages. >> Lengthy description of problem: >> Section 4.1, para. 6 states "it is the combination of support >> of the Diameter Credit Control Application and the service >> defined in the Service-Identifier AVP, which defines >> interoperability between any given credit control client and >> server." However, inclusion of the Session-Identifier AVP in >> the CER/CEA exchange is not mandated. This could lead to a >> situation where peers have successfully negotiated >> application support, but cannot interoperate. >> >> Requested change: >> Change section 1.3 from >> >> Diameter nodes conforming to this specification MUST advertise >> support by including the value of 4 in the >> Auth-Application-Id of the >> Capabilities-Exchange-Request and Capabilities-Exchange-Answer >> command [DIAMBASE]. >> >> to >> >> Diameter nodes conforming to this specification MUST advertise >> support by including one or more Session-Identifier AVPs >> (corresponding to the supported >> services) and setting the value of 4 in the >> Auth-Application-Id of the >> Capabilities-Exchange-Request and >> Capabilities-Exchange-Answer command [DIAMBASE]. >> >> Add Section 10.3: >> >> 10.3 Capabilities-Exchange-Request/Answer AVP Table >> >> This section defines AVPs that are specific to Diameter Credit >> Control Application and MUST be included in the Diameter >> Capabilities-Exchange-Request/Answer (CER/CEA) message [DIAMBASE]. >> >> The Capabilities-Exchange-Request/Answer commands MUST include >> the following additional AVPs: >> >> +---------------+ >> | Command Code | >> |-------+-------+ >> Attribute Name | CER | CEA | >> ------------------------------+-------+-------+ >> Service-Identifier | 1+ | 1+ | >> ------------------------------+-------+-------+ >> >> ~gwz >> >> "They that can give up essential liberty to obtain a little >> temporary safety deserve neither..." >> -- Benjamin Franklin, 1759 >> >> >> "It is forbidden to kill; therefore all murderers are >> punished unless they kill in large numbers and to the sound of >> trumpets." >> -- Voltaire Hope this helps, ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire From owner-aaa-wg@merit.edu Mon Jul 5 17:28: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 RAA17999 for ; Mon, 5 Jul 2004 17:28:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7E44B9124D; Mon, 5 Jul 2004 17:28:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51E1191261; Mon, 5 Jul 2004 17:28:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 606AA9124D for ; Mon, 5 Jul 2004 17:28:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3F9A75A1F8; Mon, 5 Jul 2004 17:28:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 850A05A1FB for ; Mon, 5 Jul 2004 17:28:20 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i65LQuY16819; Mon, 5 Jul 2004 14:26:56 -0700 Date: Mon, 5 Jul 2004 14:26:55 -0700 (PDT) From: Bernard Aboba To: Glen Zorn Cc: "'Christopher Richards'" , John.Prudhoe@vodafone.com, aaa-wg@merit.edu, Pasi.Eronen@nokia.com Subject: RE: [AAA-WG]: Application IDs for EAP In-Reply-To: <012901c46066$37d149d0$0202a8c0@amer.cisco.com> Message-ID: References: <012901c46066$37d149d0$0202a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > However, by defining the Service-Identifier AVP as a kind of qualifier > for the application ID draft-ietf-aaa-diameter-cc-05.txt allows the > definition of new service-specific (and even vendor-specific) mandatory > AVPs while continuing to use the CC app ID. As I understood it, these new AVPs were not "mandatory" in the sense that the Service-Identifier AVP allowed their use to be negotiated, and therefore they would only be sent if the endpoints supported them. So I don't see any contradiction between those two points of view. From owner-aaa-wg@merit.edu Mon Jul 5 20:57: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 UAA26660 for ; Mon, 5 Jul 2004 20:57:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4F3C591273; Mon, 5 Jul 2004 20:57:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1896391274; Mon, 5 Jul 2004 20:57:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F2CC391273 for ; Mon, 5 Jul 2004 20:57:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D06EB5A252; Mon, 5 Jul 2004 20:57:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 402ED5A228 for ; Mon, 5 Jul 2004 20:57:14 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i660txx28720; Mon, 5 Jul 2004 17:55:59 -0700 Date: Mon, 5 Jul 2004 17:55:59 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Cc: pasi.eronen@nokia.com Subject: [AAA-WG]: Issue 464: Application-Id Usage Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Pasi Eronen noted: >This seems to imply that a new application can't borrow only >a subset of mandatory commands from an existing application..? > >Otherwise we could get a conflict. Let's assume that application >X has commands C1 and C2, and application Y defines a new >command C3 and borrows C1 from X (without any new mandatory >AVPs). >It seems that a Diameter server implementing only Y can't >advertise support for X, since it does not implement C2. >But using application identifier of X for C1 is not allowed >either, since this seems to contradict the text saying that >"When a request is routed, the target server MUST have >advertised the Application Identifier (see Section 2.4) for >the given message. >Another related issue is whether two different applications >could use the same AVP (in the same command and with the same >application ID) for slightly different purposes. At least this >happens all the time with RADIUS, but perhaps the different uses >can be distinguished even if the application ID is the same..." If application Y defines a new command C3, then it needs to advertise application Y, since otherwise it can't be guaranteed that Diameter peers will select a path that will allow command C3 to be sent from Diameter client to server. The question is whether it should also advertise the application that it inherited command C1 from, even though it doesn't support command C2. If the application-Id in question is Diameter Base (Application-ID 0) I think there is no issue, since this is mandatory-to-implement for all Diameter peers. However, if we are talking about multiple inheritance (e.g. inheriting commands from an Application-Id other than Base authentication and accounting) I think we have a problem. I'd interpret RFC 3588 as allowing an out for this, since the number of round-trips is changed (e.g. the common is disallowed altogether). Does this make sense? In this particular case, is there any issue with advertising Diameter Base Common Messages as well as EAP? I think there isn't because EAP supports all Base commands. However, there might be an issue with advertising NASREQ where the NAS or server doesn't support PAP/CHAP (AAR/AAA). From owner-aaa-wg@merit.edu Mon Jul 5 21:06:25 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26914 for ; Mon, 5 Jul 2004 21:06:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9BBA691272; Mon, 5 Jul 2004 21:06:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6528D91274; Mon, 5 Jul 2004 21:06:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5B4D991272 for ; Mon, 5 Jul 2004 21:06:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3D9DA5A22A; Mon, 5 Jul 2004 21:06:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 91C4D5A175 for ; Mon, 5 Jul 2004 21:06:11 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i6614vH29329 for ; Mon, 5 Jul 2004 18:04:57 -0700 Date: Mon, 5 Jul 2004 18:04:57 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 465: Key Naming Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I'm opening Issue 465 for residual issues relating to Diameter EAP Key naming. In reading Diameter EAP-08, Section 4.1.4 says: " The EAP-Key-Name AVP (AVP Code TBD-BY-IANA) is of type OctetString. It contains an opaque key identifier (name) generated by the EAP method. Exactly how this name is used depends on the link layer in question, and is beyond the scope of this document (see [EAPKey] for more discussion). It should be noted that not all link layers use this name, and currently most EAP methods do not generate it. The home Diameter server SHOULD include this AVP in Diameter-EAP-Response only if an empty EAP-Key-Name AVP was present in Diameter-EAP-Request." The question is what happens if the EAP-Key-Name AVP sent in a Diameter-EAP-Request is non-null. I'd suggest that the second paragraph should be changed to say: "It should be noted that not all link layers use this name, and currently most EAP methods do not generate it. Since the NAS operates in pass-through, it cannot know the Key-Name before receving it from the AAA server. As a result, a Key-Name AVP sent in a Diameter-EAP-Request MUST not contain any data. A home Diameter server receiving a Diameter-EAP-Request with a Key-Name AVP with non-null data MUST silently discard the AVP. In addition, the home Diameter server SHOULD include this AVP in Diameter-EAP-Response only if an EAP-Key-Name AVP with non-null data was present in Diameter-EAP-Request." Jari Arkko said: "I do see the point of being able to name a the MSK. However, I would suggest that we define this AVP in a separate document when there is a specific use case and need for it, because I think adding it to the Diameter EAP document creates some problems for us (more on that below). I would also note that we may need AMSK names, though informing applications of them probably takes place through some node-internal API rather than a AAA protocol. About the problems that I mentioned: o I think its fine to say that the exact use of the name information is link layer dependent. I take it that this means the client side? But I feel uneasy about defining an attribute unless we also specify how the server fills in the information. o We can expect the EAP Keying Framework document to specify this, perhaps, but then we create a dependency from this document to the EAP Keying Framework, which is likely ready later than this document (and is Informational). o Current systems do not use the key name for anything. o As you point out, there is no corresponding RADIUS attributes. This would imply that all Diameter clients would have to prepare for the possibility that they don't get this attribute, in case the server was RADIUS. Likewise all servers would have to prepare for the possibility that their attribute is stripped off by a Diameter to RADIUS gateway. So it seems hard to even consider relying on this information." From owner-aaa-wg@merit.edu Mon Jul 5 21:20: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 VAA27311 for ; Mon, 5 Jul 2004 21:20:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9438191274; Mon, 5 Jul 2004 21:20:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F9EE91275; Mon, 5 Jul 2004 21:20:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6E2A891274 for ; Mon, 5 Jul 2004 21:20:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B10145A28B; Mon, 5 Jul 2004 21:20:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id E3C345A23D for ; Mon, 5 Jul 2004 21:20:22 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i661J8830135 for ; Mon, 5 Jul 2004 18:19:08 -0700 Date: Mon, 5 Jul 2004 18:19:08 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 467: Diameter EAP Keying Model Issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 467: Diameter EAP Keying Model Issues Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 7/5/04 Reference: Document: EAP Comment type: T Priority: S Section: Various Rationale/Explanation of issue: The Diameter EAP document assumes the EAP keying model described in [KEYFRAME]. This assumption is pervasive within the document, such as in the Key-Name support. However, recently another EAP keying model has been submitted for consideration in RADEXT: http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-00.txt http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-01.txt Since there can only be a single keying model for EAP keying in Diameter, RADIUS and EAP, the differences between the Diameter EAP model and the two above drafts need to be resolved. Since the Diameter EAP document is in AAA WG last call, there is no better time to discuss (and resolve) this than now. From owner-aaa-wg@merit.edu Mon Jul 5 21:26: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 VAA27667 for ; Mon, 5 Jul 2004 21:26:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 17A0591278; Mon, 5 Jul 2004 21:26:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD51491279; Mon, 5 Jul 2004 21:26:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F400191278 for ; Mon, 5 Jul 2004 21:26:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E4BB85A277; Mon, 5 Jul 2004 21:26:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 7CB015A249 for ; Mon, 5 Jul 2004 21:26:02 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i661Om230429 for ; Mon, 5 Jul 2004 18:24:48 -0700 Date: Mon, 5 Jul 2004 18:24:47 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 466: Missing QoSFilterRule AVP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I'm opening Issue 466 to discuss the missing QoSFilterRule AVP in NASREQ. From owner-aaa-wg@merit.edu Mon Jul 5 22:36: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 WAA00388 for ; Mon, 5 Jul 2004 22:36:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1FDE891275; Mon, 5 Jul 2004 22:35:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD87791279; Mon, 5 Jul 2004 22:35:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7437491275 for ; Mon, 5 Jul 2004 22:35:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5541A5A245; Mon, 5 Jul 2004 22:35:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by segue.merit.edu (Postfix) with ESMTP id 1794D5A215 for ; Mon, 5 Jul 2004 22:35:51 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 05 Jul 2004 19:36:01 -0700 Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i662ZmgI008659; Mon, 5 Jul 2004 19:35:48 -0700 (PDT) Received: from gwzw2k (sjc-vpn3-788.cisco.com [10.21.67.20]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id TAA12265; Mon, 5 Jul 2004 19:35:47 -0700 (PDT) Reply-To: From: "Glen Zorn" To: Cc: Subject: RE: [AAA-WG]: Issue with draft-ietf-aaa-diameter-cc-05.txt Date: Mon, 5 Jul 2004 19:35:15 -0700 Organization: Cisco Systems Message-ID: <000201c46301$f10e9b80$0202a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D0298AA76@esebe016.ntc.nokia.com> 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 owner-aaa-wg@merit.edu writes: > Hi Glen, >=20 > actually the WG last call ended a while ago, the draft has already > been review by the IESG (as you may have noticed from my previous > email). As you know changes are not allowed at this stage, unless > explicitly requested by the IESG or major bugs are discovered. =20 >=20 > We have discussed among authors a year ago the possibility of using > CER/CEA as you propose. While including the Service-Identifier AVP in > CER/CEA *may* work in case of direct connection to the server, it > won't help if e.g. relay agents were present in between client and > server. All the client would know from an immediate peer that > advertises it self as a relay agent is that any message can be sent > over there. Because the base protocol is working solely on the basis > of the Application-Identifier, even though the server would advertise > Service-Ids to the relay agent, the relay agent would still deliver > CCR messages to the server regardless the service-id.=20 OK, but how is this problem solved by _not_ including the = Service-Identifier in the CER/CEA? It seems like what you are saying is = that CCA just won't work through relays... =20 > The other > problem of including the Service-Id in CER/CEA is that one can have > negotiate application-ids in one CER command, and therefore there is > a risk that the receiver can't be sure to which application the > Service-Id is related to, in case several applications would adopt > the same mechanism in the future. We finally thought that if we > introduce a mechanism, this must work in all the possible AAA network > topologies and scenarios, we then discarded the CER/CEA and we ended > up to the end-to-end discovery documented in the DCC draft. =20 >=20 > I think it would be more appropriate to enhance the capability > exchange possibly in a next version of the base protocol rather than > in the DCC, since many other applications may benefit from it.=20 I think that the existing capabilities exchange mechanism is sufficient, = if used properly. This mechanism seems to me (please correct me if I'm = wrong -- I can't find any rationale in the I-D, but maybe I just missed = it) to be just a way to avoid having to get a new app ID from IANA, but = that seems a poor reason to break Diameter. >=20 > For the time being I think what we have is enough. At the first CCR > sent to the server, the server will reject the request if the service > indicated in the Service-Identifier AVP is not supported. The > Result-code in CCA is set to DIAMETER_RATING_FAILED and the Failed > AVP includes the Service-Id AVP. The client MUST NOT send such > similar request in the future (typically until a new CER/CEA is > performed).=20 I still don't see how this really helps much. For example, suppose that = the only route from an access point to a set of n>1 servers (all of = which support CCA, but only 1 of which supports the correct service) is = through a relay. It doesn't seem to matter how many CER/CEA exchanges = take place between the client and the relay, unless the relay happens by = chance to send the CCR to the right server the protocol will fail. Put = another way, in the pathological case the relay might _never_ select the = right server. > As I say this is already covered in the draft, however, > since we are updating the draft (IESG review) we can make it even > more explicit in the new 4.1.2/4.1.4 sub-sect., for instance =20 >=20 > 4.1.2 Application Support >=20 > Since the Application-Id of the Diameter Credit Control > Application does not uniquely identify the service being > monitored, an additional mechanism is needed. The service > application MUST be identified using the Service- Identifier AVP > at command level. A server receiving a request for a service > application it does not support will reject the request as defined > in sub-section 4.1.4.; the client will not send such similar > request in the future. This is effectively an end-to-end discovery > of the service application the credit control server is > supporting. The Service-Identifier AVP MUST be a unique identifier > for a given service as defined in section 8.28.=20 >=20 > Thus, the combination of the Diameter Credit Control > Application-Id and the Service-Identifier AVP in the > Credit-Control-Request command uniquely defines the service within > the context of the Diameter Credit Control, and hence provides > interoperability between Diameter credit control clients and > server.=20 >=20 > With this mechanism it is possible to cover additional service > specific requirements as needed in other documents. However, > introducing new credit control mechanisms to the framework defined > in this specification, require definition of a new version of the > Diameter Credit Control Application and corresponding Application > Identifier.=20 >=20 > 4.1.4 Handling of Unsupported/Incorrect Rating Input >=20 > Diameter credit control implementations are required to support the > Mandatory rating AVPs defined in service specific documentation of > the services they support according to the 'M' bit rules in > [DIAMBASE].=20 >=20 > In case a rating input required for the rating process is > incorrect in the Credit control request, or the credit control > server does not support the requested service (identified by the > Service-Idntifier AVP at command level), the Credit control answer > MUST contain error code DIAMETER_RATING_FAILED. A CCR message with > this error MUST contain one or more Failed-AVP AVPs containing the > missing and/or unsupported AVPs that caused the failure. A > Diameter credit control client receiving error code > DIAMETER_RATING_FAILED in answer to a request MUST NOT send such > similar requests in the future (typically until a new capability > exchange negotiation is performed according [DIAMBASE]).=20 >=20 > Regards > Marco >=20 >> -----Original Message----- >> From: owner-aaa-wg@merit.edu >> [mailto:owner-aaa-wg@merit.edu]On Behalf Of >> ext Glen Zorn >> Sent: 02 July, 2004 21:26 >> To: aaa-wg@merit.edu >> Subject: [AAA-WG]: Issue with draft-ietf-aaa-diameter-cc-05.txt >>=20 >>=20 >> Description of issue: No advertisement of service type in CER/CEA >> Submitter name: Glen Zorn Submitter email address: gwz@cisco.com >> Date first submitted: 2 July 2004 >> Document: cca >> Comment type: T >> Priority: S >> Section: 1.3 >> Rationale/Explanation of issue: The Service-Identifier AVP is >> not included in the CER/CEA messages. >> Lengthy description of problem: >> Section 4.1, para. 6 states "it is the combination of support >> of the Diameter Credit Control Application and the service >> defined in the Service-Identifier AVP, which defines >> interoperability between any given credit control client and >> server." However, inclusion of the Session-Identifier AVP in >> the CER/CEA exchange is not mandated. This could lead to a >> situation where peers have successfully negotiated >> application support, but cannot interoperate. >>=20 >> Requested change: >> Change section 1.3 from >>=20 >> Diameter nodes conforming to this specification MUST advertise >> support by including the value of 4 in the >> Auth-Application-Id of the >> Capabilities-Exchange-Request and Capabilities-Exchange-Answer =20 >> command [DIAMBASE].=20 >>=20 >> to >>=20 >> Diameter nodes conforming to this specification MUST advertise >> support by including one or more Session-Identifier AVPs >> (corresponding to the supported >> services) and setting the value of 4 in the >> Auth-Application-Id of the >> Capabilities-Exchange-Request and >> Capabilities-Exchange-Answer command [DIAMBASE]. >>=20 >> Add Section 10.3: >>=20 >> 10.3 Capabilities-Exchange-Request/Answer AVP Table >>=20 >> This section defines AVPs that are specific to Diameter Credit >> Control Application and MUST be included in the Diameter >> Capabilities-Exchange-Request/Answer (CER/CEA) message [DIAMBASE]. >>=20 >> The Capabilities-Exchange-Request/Answer commands MUST include >> the following additional AVPs:=20 >>=20 >> +---------------+ >> | Command Code | >> |-------+-------+ >> Attribute Name | CER | CEA | >> ------------------------------+-------+-------+ >> Service-Identifier | 1+ | 1+ | >> ------------------------------+-------+-------+ >>=20 >> ~gwz >>=20 >> "They that can give up essential liberty to obtain a little >> temporary safety deserve neither..." >> -- Benjamin Franklin, 1759 >>=20 >>=20 >> "It is forbidden to kill; therefore all murderers are >> punished unless they kill in large numbers and to the sound of >> trumpets."=20 >> -- Voltaire Hope this helps, ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..."=20 -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets."=20 -- Voltaire From owner-aaa-wg@merit.edu Mon Jul 5 22: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 WAA00520 for ; Mon, 5 Jul 2004 22:40:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A4AA991279; Mon, 5 Jul 2004 22:40:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 764849127A; Mon, 5 Jul 2004 22:40:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5A0A291279 for ; Mon, 5 Jul 2004 22:40:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 45BE45A2AB; Mon, 5 Jul 2004 22:40:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by segue.merit.edu (Postfix) with ESMTP id 011AE59F13 for ; Mon, 5 Jul 2004 22:40:15 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 05 Jul 2004 19:40:26 -0700 Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i662eCgI010364; Mon, 5 Jul 2004 19:40:12 -0700 (PDT) Received: from gwzw2k (sjc-vpn3-788.cisco.com [10.21.67.20]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id TAA16104; Mon, 5 Jul 2004 19:40:11 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "'Bernard Aboba'" Cc: "'Christopher Richards'" , , , Subject: RE: [AAA-WG]: Application IDs for EAP Date: Mon, 5 Jul 2004 19:39:40 -0700 Organization: Cisco Systems Message-ID: <000301c46302$8ec6e3a0$0202a8c0@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 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: 7bit Bernard Aboba writes: >> However, by defining the Service-Identifier AVP as a kind of >> qualifier for the application ID draft-ietf-aaa-diameter-cc-05.txt >> allows the definition of new service-specific (and even >> vendor-specific) mandatory AVPs while continuing to use the CC app >> ID. > > As I understood it, these new AVPs were not "mandatory" in the sense > that the Service-Identifier AVP allowed their use to be negotiated, > and therefore they would only be sent if the endpoints supported > them. So I don't see any contradiction between those two points of > view. Sorry, my comments arose from the -05 version of the draft, in which the inclusion of the Service-Identifier in the CCR/CCA is optional. Apparently that problem is being fixed. Hope this helps, ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire From owner-aaa-wg@merit.edu Tue Jul 6 01:44: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 BAA08744 for ; Tue, 6 Jul 2004 01:44:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 15E2E91280; Tue, 6 Jul 2004 01:44:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D14A891281; Tue, 6 Jul 2004 01:44:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A78491280 for ; Tue, 6 Jul 2004 01:44:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 67BD55A373; Tue, 6 Jul 2004 01:44:03 -0400 (EDT) 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 12C555A36E for ; Tue, 6 Jul 2004 01:44:03 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 05 Jul 2004 22:50:00 +0000 X-BrightmailFiltered: true Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i665hvgI025994; Mon, 5 Jul 2004 22:43:57 -0700 (PDT) Received: from gwzw2k (sjc-vpn3-788.cisco.com [10.21.67.20]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id WAA13248; Mon, 5 Jul 2004 22:43:56 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "'Bernard Aboba'" Cc: "'Christopher Richards'" , , , Subject: RE: [AAA-WG]: Application IDs for EAP Date: Mon, 5 Jul 2004 22:43:24 -0700 Organization: Cisco Systems Message-ID: <000e01c4631c$39c8edc0$0202a8c0@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 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: 7bit owner-aaa-wg@merit.edu writes: >> However, by defining the Service-Identifier AVP as a kind of >> qualifier for the application ID draft-ietf-aaa-diameter-cc-05.txt >> allows the definition of new service-specific (and even >> vendor-specific) mandatory AVPs while continuing to use the CC app >> ID. > > As I understood it, these new AVPs were not "mandatory" in the sense > that the Service-Identifier AVP allowed their use to be negotiated, > and therefore they would only be sent if the endpoints supported > them. So I don't see any contradiction between those two points of > view. Hmm. It seems like that depends upon how you define the term "negotiated". Section 4.1, para. 5 of draft-ietf-aaa-diameter-cc-05.txt says This specification, together with service specific documents, is governing the credit control message. The rule is that service specific documents only define what existing AVPs or new AVPs are used as input to the rating process (i.e. they do not define new credit control applications), and thus need to be included in the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Credit-Control-Request command by a Diameter Credit Control Client ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ supporting a given service as *[AVP]. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ So it looks to me as if negotiation in this case means basically sending CCRs to every DCCA server you can find until you don't get back an error; however, since the error you get back will be an application error rather than a protocol error, neither relays nor proxies can help you out. So unless you are only one hop from a good server, protocol behavior may be nondeterministic (especially in the case of relays) because without looking pretty deep into the packet there's no way to know that just forwarding the next CCR to the same server. Proxy agents might be able to handle this, but not relays. In addition, if multiple proxies are available to the client there is no way for it to know which of them (if any) supports the correct service(s) because the Service-Identifier AVP isn't included in the CER. Hope this helps, ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire From owner-aaa-wg@merit.edu Tue Jul 6 01:49: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 BAA09015 for ; Tue, 6 Jul 2004 01:49:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C847191281; Tue, 6 Jul 2004 01:49:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9184991282; Tue, 6 Jul 2004 01:49:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 81CBE91281 for ; Tue, 6 Jul 2004 01:49:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 06E985A2F5; Tue, 6 Jul 2004 01:49:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 8F86759E20 for ; Tue, 6 Jul 2004 01:49:11 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 2B33789833; Tue, 6 Jul 2004 08:49:05 +0300 (EEST) Message-ID: <40EA3C31.1040300@kolumbus.fi> Date: Tue, 06 Jul 2004 08:44:17 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 465: Key Naming References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > In reading Diameter EAP-08, Section 4.1.4 says: > > " The EAP-Key-Name AVP (AVP Code TBD-BY-IANA) is of type OctetString. > It contains an opaque key identifier (name) generated by the EAP > method. Exactly how this name is used depends on the link layer in > question, and is beyond the scope of this document (see [EAPKey] for > more discussion). > > It should be noted that not all link layers use this name, and > currently most EAP methods do not generate it. The home Diameter > server SHOULD include this AVP in Diameter-EAP-Response only if an > empty EAP-Key-Name AVP was present in Diameter-EAP-Request." > > The question is what happens if the EAP-Key-Name AVP sent in a > Diameter-EAP-Request is non-null. > > I'd suggest that the second paragraph should be changed to say: > > "It should be noted that not all link layers use this name, and > currently most EAP methods do not generate it. Since the NAS > operates in pass-through, it cannot know the Key-Name before > receving it from the AAA server. As a result, a Key-Name > AVP sent in a Diameter-EAP-Request MUST not contain any data. > A home Diameter server receiving a Diameter-EAP-Request > with a Key-Name AVP with non-null data MUST silently > discard the AVP. In addition, the home Diameter > server SHOULD include this AVP in Diameter-EAP-Response only if an > EAP-Key-Name AVP with non-null data was present in Diameter-EAP-Request." ^^^^^^^^ I think you meant "null" above? Or I need more coffee this morning... Otherwise I think the resolution is OK. --Jari From owner-aaa-wg@merit.edu Tue Jul 6 01: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 BAA09284 for ; Tue, 6 Jul 2004 01:58:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 96AF991282; Tue, 6 Jul 2004 01:57:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 660BB91283; Tue, 6 Jul 2004 01:57:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C62D91282 for ; Tue, 6 Jul 2004 01:57:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 441815A36B; Tue, 6 Jul 2004 01:57:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 06D975A34B for ; Tue, 6 Jul 2004 01:57:50 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 04CE189833; Tue, 6 Jul 2004 08:57:48 +0300 (EEST) Message-ID: <40EA3E3D.1080006@kolumbus.fi> Date: Tue, 06 Jul 2004 08:53:01 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 467: Diameter EAP Keying Model Issues References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Since the Diameter EAP document is in AAA WG last call, there is > no better time to discuss (and resolve) this than now. While the drafts that you mention do contain a protocol specification, they appear to lack a discussion of why exactly this type of keying transport should be adopted. As a result, I'm inclined to consider draft-ietf-eap-keying as the way to go. Key transport that way is also simpler, and can be made to interwork with the old VSAs that are currently being used. But I could be biased. What do others think? Glen and others, can you talk about the background for your drafts, and give some justification why this model should be adopted? --Jari From owner-aaa-wg@merit.edu Tue Jul 6 07:43: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 HAA07490 for ; Tue, 6 Jul 2004 07:43:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 17DAC91209; Tue, 6 Jul 2004 07:43:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D7AF69128D; Tue, 6 Jul 2004 07:43:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CFA8D91209 for ; Tue, 6 Jul 2004 07:43:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B9E8B5989D; Tue, 6 Jul 2004 07:43:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id 004F859715 for ; Tue, 6 Jul 2004 07:43:09 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i66Bh7Kv006481 for ; Tue, 6 Jul 2004 06:43:08 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 6 Jul 2004 13:43:06 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15504AD6879@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: gwz@cisco.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue with draft-ietf-aaa-diameter-cc-05.txt Date: Tue, 6 Jul 2004 13:43:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" Sender: owner-aaa-wg@merit.edu Precedence: bulk Glen wrote: > > Hi Glen, > > > > actually the WG last call ended a while ago, the draft has already > > been review by the IESG (as you may have noticed from my previous > > email). As you know changes are not allowed at this stage, unless > > explicitly requested by the IESG or major bugs are discovered. > > Sorry, I'll wait for IETF Last Call, then. > Did you see the below? So IETF Last Call ended June 15th! Bert -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: dinsdag 1 juni 2004 20:52 To: IETF-Announce Subject: Last Call: 'Diameter Credit-control Application' to Proposed Standard The IESG has received a request from the Authentication, Authorization and Accounting WG to consider the following document: - 'Diameter Credit-control Application ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-06-15. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-05.txt From owner-aaa-wg@merit.edu Tue Jul 6 10:45: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 KAA20764 for ; Tue, 6 Jul 2004 10:45:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9633791290; Tue, 6 Jul 2004 10:45:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D1B891292; Tue, 6 Jul 2004 10:45:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 18D6991290 for ; Tue, 6 Jul 2004 10:44:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EFF7959E06; Tue, 6 Jul 2004 10:44:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id BB89E59E03 for ; Tue, 6 Jul 2004 10:44:57 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i66Ei4N24665; Tue, 6 Jul 2004 17:44:05 +0300 (EET DST) X-Scanned: Tue, 6 Jul 2004 17:43:05 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i66Eh5vv008814; Tue, 6 Jul 2004 17:43:05 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 005QpB18; Tue, 06 Jul 2004 17:43:04 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i66EgwH20305; Tue, 6 Jul 2004 17:42:58 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 6 Jul 2004 17:42:54 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [AAA-WG]: Issue with draft-ietf-aaa-diameter-cc-05.txt Date: Tue, 6 Jul 2004 17:42:53 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B05B7@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue with draft-ietf-aaa-diameter-cc-05.txt Thread-Index: AcRjAgkpsFXTgQvGSXSiinkhmQt35gAU8vMA From: To: Cc: X-OriginalArrivalTime: 06 Jul 2004 14:42:54.0702 (UTC) FILETIME=[859348E0:01C46367] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: base64 PiBPSywgYnV0IGhvdyBpcyB0aGlzIHByb2JsZW0gc29sdmVkIGJ5IF9ub3RfIGluY2x1ZGluZyB0 aGUgDQo+IFNlcnZpY2UtSWRlbnRpZmllciBpbiB0aGUgQ0VSL0NFQT8gIEl0IHNlZW1zIGxpa2Ug d2hhdCB5b3UgDQo+IGFyZSBzYXlpbmcgaXMgdGhhdCBDQ0EganVzdCB3b24ndCB3b3JrIHRocm91 Z2ggcmVsYXlzLi4uIA0KDQpBY3R1YWxseSBJIHdhcyB0aGlua2luZyB0byB5b3VyIHByb3Bvc2Fs Li4uLg0KSSB0aGluayB0aGUgRENDIHNob3VsZCBqdXN0IHdvcmsgZmluZSB3aXRoIHJlbGF5cyB0 b28uDQoNCj4gSSB0aGluayB0aGF0IHRoZSBleGlzdGluZyBjYXBhYmlsaXRpZXMgZXhjaGFuZ2Ug bWVjaGFuaXNtIGlzIA0KPiBzdWZmaWNpZW50LCBpZiB1c2VkIHByb3Blcmx5LiAgVGhpcyBtZWNo YW5pc20gc2VlbXMgdG8gbWUgDQo+IChwbGVhc2UgY29ycmVjdCBtZSBpZiBJJ20gd3JvbmcgLS0g SSBjYW4ndCBmaW5kIGFueSByYXRpb25hbGUgDQo+IGluIHRoZSBJLUQsIGJ1dCBtYXliZSBJIGp1 c3QgbWlzc2VkIGl0KSB0byBiZSBqdXN0IGEgd2F5IHRvIA0KPiBhdm9pZCBoYXZpbmcgdG8gZ2V0 IGEgbmV3IGFwcCBJRCBmcm9tIElBTkEsIGJ1dCB0aGF0IHNlZW1zIGEgDQo+IHBvb3IgcmVhc29u IHRvIGJyZWFrIERpYW1ldGVyLg0KDQpIbW0uLi4nYnJlYWsgRGlhbWV0ZXInIGl0IHNlZW1zIGEg Yml0IHRvIHN0cm9uZyBzdGF0ZW1lbnQuDQpUaGUgYXBwbGljYXRpb24gaXMgYWx3YXlzIHRoZSBE Q0MsIG5vIHJlYXNvbiB0byBkZWZpbmUgbmV3IGFwcCBJRC4NClRoZSByYXRpb25hbCBmb3IgdGhl IHNlcnZpY2UtaWQgaXMgZXhwbGFpbmVkIGluIHNlY3Rpb24gNC4xDQoNCmNsaXANCg0KICAnVGhl IERpYW1ldGVyIENyZWRpdCBDb250cm9sIEFwcGxpY2F0aW9uIGRlZmluZXMgdGhlIGZyYW1ld29y ayBmb3IgDQogICBjcmVkaXQgY29udHJvbDsgaXQgcHJvdmlkZXMgZ2VuZXJpYyBjcmVkaXQgY29u dHJvbCBtZWNoYW5pc21zIA0KICAgc3VwcG9ydGluZyBtdWx0aXBsZSBzZXJ2aWNlIGFwcGxpY2F0 aW9ucy4gVGhlIENyZWRpdCBDb250cm9sIA0KICAgQXBwbGljYXRpb24sIHRoZXJlZm9yZSwgZG9l cyBub3QgZGVmaW5lIEFWUHMgdGhhdCBjb3VsZCBiZSB1c2VkIGFzIA0KICAgaW5wdXQgaW4gdGhl IHJhdGluZyBwcm9jZXNzLiBMaXN0aW5nIHRoZSBwb3NzaWJsZSBzZXJ2aWNlcyB0aGF0IGNvdWxk IA0KICAgdXNlIHRoaXMgRGlhbWV0ZXIgYXBwbGljYXRpb24gaXMgc2VlbiBhcyBvdXQgb2Ygc2Nv cGUgZm9yIHRoaXMgDQogICBnZW5lcmljIG1lY2hhbmlzbSBhcyB3ZWxsLicgDQoNCkJlY2F1c2Ug d2UgY291bGRuJ3QgZGVmaW5lIGFsbCB0aGUgcG9zc2libGUgcmF0aW5nIGlucHV0cyBmb3IgYWxs IHRoZQ0KcG9zc2libGUgc2VydmljZXMgKGkuZS4gdGhlIGF0dHJpYnV0ZXMgdG8gcXVhbGlmeSB0 aGUgc2VydmljZSBhbmQNCmRldGVybWluZSBpdHMgcHJpY2UpLCB0aGUgc2VydmljZS1pZCB3YXMg aW50cm9kdWNlZCBhcyBwcmltYXJ5DQoncmF0aW5nIHJvb3QnIHNvIHRoYXQgdGhlIHNlcnZlciBr bm93cyBpbW1lZGlhdGVseSB3aGV0aGVyIHRoZQ0KcmVxdWVzdGVkIHNlcnZpY2UgY2FuIGJlIHJh dGVkIGJlZm9yZSB0byBwZXJmb3JtIHZlcnkgZXhwZW5zaXZlDQpvcGVyYXRpb25zIHN1Y2ggYXMg aW52b2tpbmcgdGhlIHJhdGluZyBwcm9jZXNzIGFuZCBldmVudHVhbGx5IHJlamVjdCANCnRoZSBy ZXF1ZXN0Lg0KDQo+IEkgc3RpbGwgZG9uJ3Qgc2VlIGhvdyB0aGlzIHJlYWxseSBoZWxwcyBtdWNo LiAgRm9yIGV4YW1wbGUsIA0KPiBzdXBwb3NlIHRoYXQgdGhlIG9ubHkgcm91dGUgZnJvbSBhbiBh Y2Nlc3MgcG9pbnQgdG8gYSBzZXQgb2YgDQo+IG4+MSBzZXJ2ZXJzIChhbGwgb2Ygd2hpY2ggc3Vw cG9ydCBDQ0EsIGJ1dCBvbmx5IDEgb2Ygd2hpY2ggDQo+IHN1cHBvcnRzIHRoZSBjb3JyZWN0IHNl cnZpY2UpIGlzIHRocm91Z2ggYSByZWxheS4gIEl0IGRvZXNuJ3QgDQo+IHNlZW0gdG8gbWF0dGVy IGhvdyBtYW55IENFUi9DRUEgZXhjaGFuZ2VzIHRha2UgcGxhY2UgYmV0d2VlbiANCj4gdGhlIGNs aWVudCBhbmQgdGhlIHJlbGF5LCB1bmxlc3MgdGhlIHJlbGF5IGhhcHBlbnMgYnkgY2hhbmNlIA0K PiB0byBzZW5kIHRoZSBDQ1IgdG8gdGhlIHJpZ2h0IHNlcnZlciB0aGUgcHJvdG9jb2wgd2lsbCBm YWlsLiAgDQo+IFB1dCBhbm90aGVyIHdheSwgaW4gdGhlIHBhdGhvbG9naWNhbCBjYXNlIHRoZSBy ZWxheSBtaWdodCANCj4gX25ldmVyXyBzZWxlY3QgdGhlIHJpZ2h0IHNlcnZlci4NCg0KVGhlIERD QyByZWx5IG9uIHR3byBkaWZmZXJlbnQgbW9kZWxzLCBhc3N1bWluZyB5b3VyIGFjY2VzcyBwb2lu dCANCnBlcmZvcm0gc2VydmljZSBzcGVjaWZpYyBhdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9u IHdpdGggYSBBQUEgc2VydmVyOg0KDQoxLSBUaGUgQUFBIHNlcnZlciByZXR1cm5zIGluIHRoZSBB QS1hbnN3ZXIgdGhlIEZRRE4gb2YgdGhlIGNyZWRpdC1jb250cm9sDQogICBzZXJ2ZXIocykgdGhh dCBzdXBwb3J0IHRoaXMgc2VydmljZS4gVGhlIERDQy1jbGllbnQgd2lsbCBjb250YWN0IHRoZW4g dGhlDQogICBzZXJ2ZXIgdG8gcGVyZm9ybSBjcmVkaXQgYXV0aG9yaXphdGlvbi4NCjItIElmIHRo ZSBtb2RlbCBkZWZpbmVkIGluIHNlY3QuIDUuMi4yIGlzIHVzZWQsIHRoZSBBQUEgc2VydmVyIGFk dmVydGlzZXMgc3VwcG9ydA0KICAgZm9yIHRoZSBEQ0MuIFRoZSByZWxheSBzZW5kcyB0aGUgcmVx dWVzdCB0byB0aGlzIEFBQSBzZXJ2ZXIsIHdoaWNoIHRoZW4gc2VsZWN0DQogICB0aGUgYXBwcm9w cmlhdGUgQ0Mtc2VydmVyIG9uIHRoZSBiYXNpcyBvZiBpdHMga25vd2xlZGdlIG9mIHRoZSB1c2Vy IGFuZA0KICAgcmVxdWVzdGVkIHNlcnZpY2UuIENvbW11bmljYXRpb24gd2l0aCB0aGUgQ0MtU2Vy dmVyIGNvbnRpbnVlcyB2aWEgdGhlIEFBQQ0KICAgc2VydmVyLg0KDQpIb3BlIHRoaXMgY2xhcmlm eQ0KTWFyY28NCg0KDQogICANCiAgIA0KDQo= From owner-aaa-wg@merit.edu Tue Jul 6 10:56: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 KAA21291 for ; Tue, 6 Jul 2004 10:56:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8F66E91211; Tue, 6 Jul 2004 10:56:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B0F191292; Tue, 6 Jul 2004 10:56:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EFE6791211 for ; Tue, 6 Jul 2004 10:56:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DAC6B59D9E; Tue, 6 Jul 2004 10:56:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by segue.merit.edu (Postfix) with ESMTP id 8096E59C77 for ; Tue, 6 Jul 2004 10:56:09 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i66Etnh29825; Tue, 6 Jul 2004 10:55:50 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Jul 2004 10:55:50 -0400 Message-ID: From: "Christopher Richards" To: "'Bernard Aboba'" , aaa-wg@merit.edu Cc: pasi.eronen@nokia.com Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage Date: Tue, 6 Jul 2004 10:55:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46369.4F89E35B" 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_01C46369.4F89E35B Content-Type: text/plain Hi Bernard, All, I still have a problem with the use of an application-id of a different application in a command. Firstly, there is section 3 of RFC 3588. It states that the application-id in the header of any command MUST be the same as the application id in any relevant AVPs. Secondly, what if a Diameter peer does not want to use a base application but only wants to use some other application. It wants to advertise support for application X but does not want to be used for a base application (regardless of it's ability to support the base applications). For example, an operator may want to disable a node's Diameter Accounting application while maintaining some other application(s). The Diameter protocol should not force the node to advertise support for an application that is not enabled. Regardless of which spec a command is defined, a command is only relevant to the application to which the command is destined. E.g. if a management node wants to Abort a DCCA session on the DCCA client, it only makes sense to send the ASR to the DCC client application - since it is the DCC client application which is handling the session. Cheers, Chris Tel: +1 613 763 8031 ESN: 393 8031 -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: July 5, 2004 8:56 PM To: aaa-wg@merit.edu Cc: pasi.eronen@nokia.com Subject: [AAA-WG]: Issue 464: Application-Id Usage Pasi Eronen noted: >This seems to imply that a new application can't borrow only >a subset of mandatory commands from an existing application..? > >Otherwise we could get a conflict. Let's assume that application X has >commands C1 and C2, and application Y defines a new command C3 and >borrows C1 from X (without any new mandatory AVPs). >It seems that a Diameter server implementing only Y can't advertise >support for X, since it does not implement C2. But using application >identifier of X for C1 is not allowed either, since this seems to >contradict the text saying that "When a request is routed, the target >server MUST have advertised the Application Identifier (see Section >2.4) for the given message. >Another related issue is whether two different applications could use >the same AVP (in the same command and with the same application ID) for >slightly different purposes. At least this happens all the time with >RADIUS, but perhaps the different uses can be distinguished even if the >application ID is the same..." If application Y defines a new command C3, then it needs to advertise application Y, since otherwise it can't be guaranteed that Diameter peers will select a path that will allow command C3 to be sent from Diameter client to server. The question is whether it should also advertise the application that it inherited command C1 from, even though it doesn't support command C2. If the application-Id in question is Diameter Base (Application-ID 0) I think there is no issue, since this is mandatory-to-implement for all Diameter peers. However, if we are talking about multiple inheritance (e.g. inheriting commands from an Application-Id other than Base authentication and accounting) I think we have a problem. I'd interpret RFC 3588 as allowing an out for this, since the number of round-trips is changed (e.g. the common is disallowed altogether). Does this make sense? In this particular case, is there any issue with advertising Diameter Base Common Messages as well as EAP? I think there isn't because EAP supports all Base commands. However, there might be an issue with advertising NASREQ where the NAS or server doesn't support PAP/CHAP (AAR/AAA). ------_=_NextPart_001_01C46369.4F89E35B Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue 464: Application-Id Usage

Hi Bernard, All,

I still have a problem with the use of an = application-id of a different application in a command.

Firstly, there is section 3 of RFC 3588. It states = that the application-id in the header of any command MUST be the same = as the application id in any relevant AVPs.

Secondly, what if a Diameter peer does not want to = use a base application but only wants to use some other application. It = wants to advertise support for application X but does not want to be = used for a base application (regardless of it's ability to support the = base applications). For example, an operator may want to disable a = node's Diameter Accounting application while maintaining some other = application(s). The Diameter protocol should not force the node to = advertise support for an application that is not enabled.

Regardless of which spec a command is defined, a = command is only relevant to the application to which the command is = destined. E.g. if a management node wants to Abort a DCCA session on = the DCCA client, it only makes sense to send the ASR to the DCC client = application - since it is the DCC client application which is handling = the session.

Cheers,
Chris

Tel:    +1 613 763 8031
ESN:    393 8031


-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com] =
Sent: July 5, 2004 8:56 PM
To: aaa-wg@merit.edu
Cc: pasi.eronen@nokia.com
Subject: [AAA-WG]: Issue 464: Application-Id = Usage


Pasi Eronen noted:

>This seems to imply that a new application can't = borrow only
>a subset of mandatory commands from an existing = application..?
>
>Otherwise we could get a conflict. Let's assume = that application X has
>commands C1 and C2, and application Y defines a = new command C3 and
>borrows C1 from X (without any new mandatory = AVPs).

>It seems that a Diameter server implementing only = Y can't advertise
>support for X, since it does not implement C2. = But using application
>identifier of X for C1 is not allowed either, = since this seems to
>contradict the text saying that "When a = request is routed, the target
>server MUST have advertised the Application = Identifier (see Section
>2.4) for the given message.

>Another related issue is whether two different = applications could use
>the same AVP (in the same command and with the = same application ID) for
>slightly different purposes.  At least this = happens all the time with
>RADIUS, but perhaps the different uses can be = distinguished even if the
>application ID is the same..."

If application Y defines a new command C3, then it = needs to advertise application Y, since otherwise it can't be = guaranteed that Diameter peers will select a path that will allow = command C3 to be sent from Diameter client to server.

The question is whether it should also advertise the = application that it inherited command C1 from, even though it doesn't = support command C2.

If the application-Id in question is Diameter Base = (Application-ID 0) I think there is no issue, since this is = mandatory-to-implement for all Diameter peers.

However, if we are talking about multiple inheritance = (e.g. inheriting commands from an Application-Id other than Base = authentication and

accounting) I think we have a problem.  I'd = interpret RFC 3588 as allowing an out for this, since the number of = round-trips is changed (e.g. the common is disallowed = altogether).

Does this make sense?

In this particular case, is there any issue with = advertising Diameter Base Common Messages as well as EAP?  I think = there isn't because EAP supports all Base commands.  However, = there might be an issue with advertising NASREQ where the NAS or server = doesn't support PAP/CHAP (AAR/AAA).

------_=_NextPart_001_01C46369.4F89E35B-- From owner-aaa-wg@merit.edu Tue Jul 6 11:05: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 LAA21960 for ; Tue, 6 Jul 2004 11:05:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0C5AD91294; Tue, 6 Jul 2004 11:05:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CBD2B91295; Tue, 6 Jul 2004 11:05:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D877991294 for ; Tue, 6 Jul 2004 11:05:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C172059CCE; Tue, 6 Jul 2004 11:05:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 3F3B259C32 for ; Tue, 6 Jul 2004 11:05:38 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i66F4H413201; Tue, 6 Jul 2004 08:04:18 -0700 Date: Tue, 6 Jul 2004 08:04:17 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 465: Key Naming In-Reply-To: <40EA3C31.1040300@kolumbus.fi> Message-ID: References: <40EA3C31.1040300@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > "It should be noted that not all link layers use this name, and > > currently most EAP methods do not generate it. Since the NAS > > operates in pass-through, it cannot know the Key-Name before > > receving it from the AAA server. As a result, a Key-Name > > AVP sent in a Diameter-EAP-Request MUST not contain any data. > > A home Diameter server receiving a Diameter-EAP-Request > > with a Key-Name AVP with non-null data MUST silently > > discard the AVP. In addition, the home Diameter > > server SHOULD include this AVP in Diameter-EAP-Response only if an > > EAP-Key-Name AVP with non-null data was present in Diameter-EAP-Request." > ^^^^^^^^ > > I think you meant "null" above? Or I need more coffee this morning... You are correct. I think it's me who needs the additional coffee... From owner-aaa-wg@merit.edu Tue Jul 6 11:08: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 LAA22060 for ; Tue, 6 Jul 2004 11:08:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BEA6391213; Tue, 6 Jul 2004 11:08:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8631191295; Tue, 6 Jul 2004 11:08:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1954591213 for ; Tue, 6 Jul 2004 11:08:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F178D59D17; Tue, 6 Jul 2004 11:08:24 -0400 (EDT) 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 93CF459AD5 for ; Tue, 6 Jul 2004 11:08:22 -0400 (EDT) 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 i66F8HR13684; Tue, 6 Jul 2004 16:08:17 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Jul 2004 16:08:18 +0100 Message-ID: <588B15E2E2B1D41180B800508BF934F20F4EC306@bmdhd6.europe.nortel.com> From: "Mark Watson" To: "'marco.stura@nokia.com'" Cc: "'aaa-wg@merit.edu'" , "'gwz@cisco.com'" , "Claire Mousset" Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Date: Tue, 6 Jul 2004 16:08:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4636B.0EB5BE3E" 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_01C4636B.0EB5BE3E Content-Type: text/plain Hi Marco, Some quick questions for clarification on this one... 1) If the client wants to request quotas for multiple services using the Multiple-Services-Credit-Control AVP then what should it put in the mandatory command level Service-Identifier AVP ? 2) Service-Identifier is finer granlarity than Rating-Group - that is several services with unique Service-Identifiers are grouped within a single Rating-Group. So a 'service' identified by a Service-Identifier is basically the finest granularity thing that can be separately charged. But then the definition of the Service Identifier AVP speaks of statically configured or standardised values. To be consistent with the above it would need to be a format or pattern than was configured/standardised - e.g. if it's voice calls that you are charging for then Service Identifies like 'voice001@blah.org', 'voice002@blah.org' would be needed to distinguish between multiple concurrent voice calls. Right ? 3) It isn't possible to request credit for a Rating-Group except by using the Multiple-Services-Credit-Control AVP, right ? Regards...Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 05 July 2004 09:09 To: gwz@cisco.com Cc: aaa-wg@merit.edu Subject: [AAA-WG]: RE: Glen, the Service-Id is only included in CCR message (at command level) to indicate to the server for what specific service the request is being issued. The server checks first the Service-Id AVP and, if it doesn't recognize the value of this AVP, it rejects the request without any further processing (e.g. rating or what so ever). If the server recognizes the value of the Service-Id AVP, it continues the processing and authorizes the credit if possible (i.e. if there is enough credit in the user's account). The section 4.1 has been restructured on request of IESG review as follow, the inclusion of the Service-Id in CCR is mandatory. Whenever the IESG and the ADs will agree that their comments have been properly addressed, the draft 06 will be carried out and made available. Regards Marco 4.1 Service-Specific Rating Input and Interoperability The Diameter Credit-Control Application defines the framework for credit control; it provides generic credit control mechanisms supporting multiple service applications. The Credit Control Application, therefore, does not define AVPs that could be used as input in the rating process. Listing the possible services that could use this Diameter application is seen as out of scope for this generic mechanism as well. Furthermore, it is reasonable to expect that there will exist a service level agreement between providers of the credit-control client and the credit-control server covering the charging, services offered, roaming agreements, agreed rating input (i.e. AVPs), etc. Therefore, it is assumed that a Diameter credit control server will provide service only for Diameter credit-control clients that have agreed beforehand the content of credit control messages. Protocol wise, it is naturally possible that any arbitrary Diameter credit-control client can interchange credit control messages with any Diameter credit control server, but with a higher likelihood that unsupported services/AVPs could be present in the credit-control message causing the server to reject the request with an appropriate result-code. 4.1.1 Specifying Rating Input AVPs There are two ways for providing rating input to the credit control server, either by using AVPs or by including them in the Service- Parameter-Info AVP. The general principles for sending rating parameters are: 1a. The service SHOULD re-use existing AVPs, if the service can use AVPs defined in existing Diameter applications (e.g. NASREQ for network access services). Re-use of existing AVPs is strongly recommended in [DIAMBASE]. For AVPs of type Enumerated the service may require a new value to be defined. Allocation of new AVP values is done as specified in [DIAMBASE], section 1.2. 1b. New AVPs can be defined if the existing AVPs do not provide sufficient rating information. In such a case, the procedures defined in [DIAMBASE] for creating new AVPs MUST be followed. 1c. For services specific only to one vendor's implementation, a Vendor- Specific AVP code for Private use can be used. Where a Vendor-Specific AVP is implemented by more than one vendor, allocation of global AVPs are encouraged instead, refer to [DIAMBASE]. 2. The Service-Parameter-Info AVP MAY be used as a container to pass legacy rating information in its original encoded form (e.g. ASN.1 BER). This method can be used to avoid unnecessary data format conversions from an existing format to an AVP format. In that case the rating input is embedded in the Service-Parameter-Info AVP as defined in section 8.42. New service applications SHOULD favor the use of explicitly defined AVPs as described in items 1a and 1b, to simplify interoperability. 4.1.2 Application Support Since the Application-Id of the Diameter Credit Control Application does not uniquely identify the service being monitored, an additional mechanism is needed. The service application MUST be identified using the Service- Identifier AVP at command level. A server receiving a request for a service application it does not support will reject the request as defined in sub-section 4.1.4. The Service-Identifier AVP MUST be a unique identifier for a given service as defined in section 8.28. Thus, the combination of the Diameter Credit Control Application-Id and the Service-Identifier AVP in the Credit-Control-Request command uniquely defines the service within the context of the Diameter Credit Control, and hence provides interoperability between Diameter credit control clients and server. With this mechanism it is possible to cover additional service specific requirements as needed in other documents. However, introducing new credit control mechanisms to the framework defined in this specification, require definition of a new version of the Diameter Credit Control Application and corresponding Application Identifier. 4.1.3 Service-Specific Documentation The service specific rating input AVPs, the contents of the Service- Parameter-Info AVP or Service-Identifier AVP are not within the scope of this document. To facilitate interoperability, it is RECOMMENDED that the rating input and the values of the service identifiers are coordinated via an informational RFC or other permanent and readily available reference such as the specification of another cooperative standardization body (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services may be deployed that are subject to agreements between providers of the credit control server and client, in this case vendor specific AVPs can be used. This specification, together with the above service specific documents, governs the credit control message. The rule is that service specific documents define what existing AVPs or new AVPs are used as input to the rating process (i.e. they do not define new credit control applications), and thus need to be included in the Credit-Control-Request command by a Diameter Credit Control Client supporting a given service as *[AVP]. Should Service-Parameter-Info be used, then the service specific document MUST specify the exact content of this grouped AVP. 4.1.4 Handling of Unsupported/Incorrect Rating Input Diameter credit control implementations are required to support the Mandatory rating AVPs defined in service specific documentation of the services they support according to the 'M' bit rules in [DIAMBASE]. In case a rating input required for the rating process is incorrect in the Credit control request, or the credit control server does not support the requested service (identified by the Service-Idntifier AVP at command level), the Credit control answer MUST contain error code DIAMETER_RATING_FAILED. A CCR message with this error MUST contain one or more Failed-AVP AVPs containing the missing and/or unsupported AVPs that caused the failure. A Diameter credit control client receiving error code DIAMETER_RATING_FAILED in answer to a request MUST NOT send such similar requests in the future. 4.1.5 RADIUS Vendor-Specific Rating Attributes When service specific documents include RADIUS vendor specific attributes that could be used as input in the rating process, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute. > -----Original Message----- > From: owner-aaa-wg@merit.edu > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Glen Zorn > Sent: 02 July, 2004 20:27 > To: aaa-wg@merit.edu > Subject: > > > Description of issue: No guarantee of interoperability > between CCA implementations > Submitter name: Glen Zorn > Submitter email address: gwz@cisco.com > Date first submitted: 2 July 2004 > Document: dcca > Comment type: T > Priority: S > Section: 4.1 > Rationale/Explanation of issue: > In order to interoperate, Diameter peers implementing the > Diameter Credit Control Application must agree upon both the > application and the service (specified in the > Service-Identifier AVP). However, the inclusion of the > Service-Identifier in the CCR and CCA messages is optional. > > Lengthy description of problem: > Section 4.1, para. 6 states "it is the combination of support > of the Diameter Credit Control Application and the service > defined in the Service-Identifier AVP, which defines > interoperability between any given credit control client and > server." However, the inclusion of the Service-Identifier in > the CCR and CCA messages is optional. This gives rise to a > situation where two peers implementing the same application > may not interoperate because they do not implement the same > "service", and further, refuse to clearly communicate that fact. > > Requested change: > Change section 4.1, paragraph 5 from > > This specification, together with service specific documents, is > governing the credit control message. The rule is that service > specific documents only define what existing AVPs or new AVPs are > used as input to the rating process (i.e. they do not define new > credit control applications), and thus need to be included in the > Credit-Control-Request command by a Diameter Credit Control Client > supporting a given service as *[AVP]. In order to define new AVPs, > service specific documents MUST follow the practices defined in > [DIAMBASE]. The service SHOULD be identified using the Service- > Identifier AVP. The Service-Identifier AVP MUST be a unique > identifier for a given service as defined in section 8.28. > > to > > This specification, together with service specific documents, is > governing the credit control message. The rule is that service > specific documents only define what existing AVPs or new AVPs are > used as input to the rating process (i.e. they do not define new > credit control applications), and thus need to be included in the > Credit-Control-Request command by a Diameter Credit Control Client > supporting a given service as *[AVP]. In order to define new AVPs, > service specific documents MUST follow the practices defined in > [DIAMBASE]. The service MUST be identified using the Service- > Identifier AVP. The Service-Identifier AVP MUST be a unique > identifier for a given service as defined in section 8.28. > > ~gwz > > "They that can give up essential liberty to obtain a little > temporary safety deserve neither..." > -- Benjamin Franklin, 1759 > > > "It is forbidden to kill; therefore all murderers are > punished unless they kill in large numbers and to the sound > of trumpets." > -- Voltaire > > ------_=_NextPart_001_01C4636B.0EB5BE3E Content-Type: text/html Content-Transfer-Encoding: quoted-printable DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Hi Marco,

Some quick questions for clarification on this = one...

1) If the client wants to request quotas for multiple = services using the Multiple-Services-Credit-Control AVP then what = should it put in the mandatory command level Service-Identifier AVP = ?

2) Service-Identifier is finer granlarity than = Rating-Group - that is several services with unique Service-Identifiers = are grouped within a single Rating-Group. So a 'service' identified by = a Service-Identifier is basically the finest granularity thing that can = be separately charged.

But then the definition of the Service Identifier AVP = speaks of statically configured or standardised values. To be = consistent with the above it would need to be a format or pattern than = was configured/standardised - e.g. if it's voice calls that you are = charging for then Service Identifies like 'voice001@blah.org', = 'voice002@blah.org' would be needed to distinguish between multiple = concurrent voice calls.

Right ?

3) It isn't possible to request credit for a = Rating-Group except by using the Multiple-Services-Credit-Control AVP, = right ?

Regards...Mark


-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: 05 July 2004 09:09
To: gwz@cisco.com
Cc: aaa-wg@merit.edu
Subject: [AAA-WG]: RE:


Glen,

the Service-Id is only included in CCR message (at = command level) to indicate
to the server for what specific service the request = is being issued. The server checks first the Service-Id AVP and, if it = doesn't recognize the value of this AVP, it rejects the request without = any further processing (e.g. rating or what so ever). If the server = recognizes the value of the Service-Id AVP, it continues the processing = and authorizes the credit if possible (i.e. if there is enough credit = in the user's account). 

The section 4.1 has been restructured on request of = IESG review as follow, the inclusion of the Service-Id in CCR is = mandatory.

Whenever the IESG and the ADs will agree that their = comments have been properly addressed, the draft 06 will be carried out = and made available.

Regards
Marco

4.1 Service-Specific Rating Input and = Interoperability
   
   The Diameter Credit-Control Application = defines the framework for credit
   control; it provides generic credit = control mechanisms supporting multiple
   service applications. The Credit = Control Application, therefore, does not
   define AVPs that could be used as input = in the rating process. Listing the
   possible services that could use this = Diameter application is seen as out
   of scope for this generic mechanism as = well. 
   
   Furthermore, it is reasonable to expect = that there will exist a service
   level agreement between providers of = the credit-control client and the
   credit-control server covering the = charging, services offered, roaming
   agreements, agreed rating input (i.e. = AVPs), etc.

   Therefore, it is assumed that a Diameter = credit control server will
   provide service only for Diameter = credit-control clients that have agreed
   beforehand the content of credit = control messages. Protocol wise, it is
   naturally possible that any arbitrary = Diameter credit-control client can
   interchange credit control messages = with any Diameter credit control
   server, but with a higher likelihood = that unsupported services/AVPs could
   be present in the credit-control = message causing the server to reject the
   request with an appropriate = result-code.
   
4.1.1 Specifying Rating Input AVPs
   
   There are two ways for providing rating = input to the credit control
   server, either by using AVPs or by = including them in the Service-
   Parameter-Info AVP. The general = principles for sending rating parameters
   are:
   
   1a. The service SHOULD re-use existing = AVPs, if the service can use AVPs
       defined in = existing Diameter applications (e.g. NASREQ for network
       access = services). Re-use of existing AVPs is strongly recommended in
       [DIAMBASE]. =

       For AVPs of type = Enumerated the service may require a new value to be
       defined. = Allocation of new AVP values is done as specified in
       [DIAMBASE], = section 1.2.
   
   1b. New AVPs can be defined if the = existing AVPs do not provide sufficient
       rating = information. In such a case, the procedures defined in
       [DIAMBASE] for = creating new AVPs MUST be followed.
   
   1c. For services specific only to one = vendor's implementation, a Vendor-
       Specific AVP = code for Private use can be used. Where a Vendor-Specific
       AVP is = implemented by more than one vendor, allocation of global AVPs
       are encouraged = instead, refer to [DIAMBASE].
   
   2. The Service-Parameter-Info AVP MAY = be used as a container to pass
      legacy rating = information in its original encoded form (e.g. ASN.1
      BER). This method can = be used to avoid unnecessary data format
      conversions from an = existing format to an AVP format. In that case the
      rating input is = embedded in the Service-Parameter-Info AVP as defined
      in section 8.42. =
   
   New service applications SHOULD favor = the use of explicitly defined AVPs
   as described in items 1a and 1b, to = simplify interoperability. 
   
4.1.2 Application Support
   
   Since the Application-Id of the = Diameter Credit Control Application does
   not uniquely identify the service being = monitored, an additional mechanism
   is needed. The service application MUST = be identified using the Service-
   Identifier AVP at command level. A = server receiving a request for a
   service application it does not support = will reject the request as defined
   in sub-section 4.1.4. The = Service-Identifier AVP MUST be a unique
   identifier for a given service as = defined in section 8.28. 
   
   Thus, the combination of the Diameter = Credit Control Application-Id and
   the Service-Identifier AVP in the = Credit-Control-Request command uniquely
   defines the service within the context = of the Diameter Credit Control, and
   hence provides interoperability between = Diameter credit control clients
   and server.
   
   With this mechanism it is possible to = cover additional service specific
   requirements as needed in other = documents. However, introducing new credit
   control mechanisms to the framework = defined in this specification, require
   definition of a new version of the = Diameter Credit Control Application and
   corresponding Application Identifier. =
   
4.1.3 Service-Specific Documentation
    
   The service specific rating input AVPs, = the contents of the Service-
   Parameter-Info AVP or = Service-Identifier AVP are not within the scope of
   this document. To facilitate = interoperability, it is RECOMMENDED that the
   rating input and the values of the = service identifiers are coordinated via
   an informational RFC or other permanent = and readily available reference
   such as the specification of another = cooperative standardization body
   (e.g. 3GPP, OMA and 3GPP2) SHOULD be = used. However, private services may
   be deployed that are subject to = agreements between providers of the credit
   control server and client, in this case = vendor specific AVPs can be used. 
       
   This specification, together with the = above service specific documents,
   governs the credit control message. The = rule is that service specific
   documents define what existing AVPs or = new AVPs are used as input to the
   rating process (i.e. they do not define = new credit control applications),
   and thus need to be included in the = Credit-Control-Request command by a
   Diameter Credit Control Client = supporting a given service as *[AVP].
   Should Service-Parameter-Info be used, = then the service specific document
   MUST specify the exact content of this = grouped AVP.
   
4.1.4 Handling of Unsupported/Incorrect Rating = Input 
   
   Diameter credit control implementations = are required to support the
   Mandatory rating AVPs defined in = service specific documentation of the
   services they support according to the = 'M' bit rules in [DIAMBASE]. 
       
   In case a rating input required for the = rating process is incorrect in the
   Credit control request, or the credit = control server does not support the
   requested service (identified by the = Service-Idntifier AVP at command
   level), the Credit control answer MUST = contain error code
   DIAMETER_RATING_FAILED. A CCR message = with this error MUST contain one or
   more Failed-AVP AVPs containing the = missing and/or unsupported AVPs that
   caused the failure. A Diameter credit = control client receiving error code
   DIAMETER_RATING_FAILED in answer to a = request MUST NOT send such similar
   requests in the future.
   
4.1.5 RADIUS Vendor-Specific Rating Attributes =
       
   When service specific documents include = RADIUS vendor specific attributes
   that could be used as input in the = rating process, the rules described in
   [NASREQ] for formatting the Diameter = AVP MUST be followed. For example,
   the AVP code used is the vendor = attribute type code, the Vendor-Specific
   flag MUST be set to 1 and the Vendor-ID = MUST be set to the IANA Vendor
   identification value. The Diameter AVP = data field contains only the
   attribute value of the RADIUS = attribute.

> -----Original Message-----
> From: owner-aaa-wg@merit.edu
> [mailto:owner-aaa-wg@merit.edu= ]On Behalf Of
> ext Glen Zorn
> Sent: 02 July, 2004 20:27
> To: aaa-wg@merit.edu
> Subject:
>
>
> Description of issue:  No guarantee of = interoperability
> between CCA implementations
> Submitter name: Glen Zorn
> Submitter email address: gwz@cisco.com
> Date first submitted: 2 July 2004
> Document: dcca
> Comment type: T
> Priority: S
> Section: 4.1
> Rationale/Explanation of issue:
> In order to interoperate, Diameter peers = implementing the
> Diameter Credit Control Application must agree = upon both the
> application and the service (specified in the =
> Service-Identifier AVP).  However, the = inclusion of the
> Service-Identifier in the CCR and CCA messages = is optional.
>
> Lengthy description of problem:
> Section 4.1, para. 6 states "it is the = combination of support
> of the Diameter Credit Control Application and = the service
> defined in the Service-Identifier AVP, which = defines
> interoperability between any given credit = control client and
> server."  However, the inclusion of = the Service-Identifier in
> the CCR and CCA messages is optional.  = This gives rise to a
> situation where two peers implementing the same = application
> may not interoperate because they do not = implement the same
> "service", and further, refuse to = clearly communicate that fact.
>
> Requested change:
> Change section 4.1, paragraph 5 from
>
>    This specification, together = with service specific documents, is
>    governing the credit control = message. The rule is that service
>    specific documents only = define what existing AVPs or new AVPs are
>    used as input to the rating = process (i.e. they do not define new
>    credit control applications), = and thus need to be included in the
>    Credit-Control-Request = command by a Diameter Credit Control Client
>    supporting a given service as = *[AVP]. In order to define new AVPs,
>    service specific documents = MUST follow the practices defined in
>    [DIAMBASE]. The service = SHOULD be identified using the Service-
>    Identifier AVP. The = Service-Identifier AVP MUST be a unique
>    identifier for a given = service as defined in section 8.28.
>
> to
>
>    This specification, together = with service specific documents, is
>    governing the credit control = message. The rule is that service
>    specific documents only = define what existing AVPs or new AVPs are
>    used as input to the rating = process (i.e. they do not define new
>    credit control applications), = and thus need to be included in the
>    Credit-Control-Request = command by a Diameter Credit Control Client
>    supporting a given service as = *[AVP]. In order to define new AVPs,
>    service specific documents = MUST follow the practices defined in
>    [DIAMBASE]. The service MUST = be identified using the Service-
>    Identifier AVP. The = Service-Identifier AVP MUST be a unique
>    identifier for a given = service as defined in section 8.28.
>
> ~gwz
>
> "They that can give up essential liberty = to obtain a little
> temporary safety deserve = neither..."
> -- Benjamin Franklin, 1759
>
>
> "It is forbidden to kill; therefore all = murderers are
> punished unless they kill in large numbers and = to the sound
> of trumpets."
> -- Voltaire
>
>

------_=_NextPart_001_01C4636B.0EB5BE3E-- From owner-aaa-wg@merit.edu Tue Jul 6 11:50: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 LAA25070 for ; Tue, 6 Jul 2004 11:50:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E76F891216; Tue, 6 Jul 2004 11:48:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B925A912DE; Tue, 6 Jul 2004 11:48:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 68C9791297 for ; Tue, 6 Jul 2004 11:44:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 278DD59E1E; Tue, 6 Jul 2004 11:44:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by segue.merit.edu (Postfix) with ESMTP id D52A359DCD for ; Tue, 6 Jul 2004 11:44:27 -0400 (EDT) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 06 Jul 2004 18:03:41 +0200 X-BrightmailFiltered: true Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i66FiMU7008811; Tue, 6 Jul 2004 17:44:23 +0200 (MEST) Received: from xbe-ams-313.cisco.com ([144.254.228.203]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 6 Jul 2004 17:39:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46370.1B29C678" Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Date: Tue, 6 Jul 2004 17:44:21 +0200 Message-ID: Thread-Topic: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Thread-Index: AcRjayj+JHW5RFYiSaChWEDVu/9X+QAAypoA From: "Mark Grayson (mgrayson)" To: "Mark Watson" , Cc: , "Glen Zorn (gwz)" , "Claire Mousset" X-OriginalArrivalTime: 06 Jul 2004 15:39:59.0203 (UTC) FILETIME=[7EBCAB30:01C4636F] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C46370.1B29C678 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mark, Marco =20 I hadn't made the same assumption - but agree that there is ambiguity here. =20 I had asumed that when present on the command level, the service-ID refers to the "rating-root" which then needs to be common between client and serer.=20 =20 Then the issue exists with re-introducing the service-ID at the MSCC level, now possibly below the sub-session-ID which I think is the cause of the issue. IMO these AVPs at the MSCC level should be subordinate to the service-ID on the command level. =20 Cheers, Mark _____ =20 From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of Mark Watson Sent: 06 July 2004 11:08 To: 'marco.stura@nokia.com' Cc: 'aaa-wg@merit.edu'; Glen Zorn (gwz); Claire Mousset Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Hi Marco,=20 Some quick questions for clarification on this one...=20 1) If the client wants to request quotas for multiple services using the Multiple-Services-Credit-Control AVP then what should it put in the mandatory command level Service-Identifier AVP ? 2) Service-Identifier is finer granlarity than Rating-Group - that is several services with unique Service-Identifiers are grouped within a single Rating-Group. So a 'service' identified by a Service-Identifier is basically the finest granularity thing that can be separately charged. But then the definition of the Service Identifier AVP speaks of statically configured or standardised values. To be consistent with the above it would need to be a format or pattern than was configured/standardised - e.g. if it's voice calls that you are charging for then Service Identifies like 'voice001@blah.org', 'voice002@blah.org' would be needed to distinguish between multiple concurrent voice calls. Right ?=20 3) It isn't possible to request credit for a Rating-Group except by using the Multiple-Services-Credit-Control AVP, right ? Regards...Mark=20 -----Original Message-----=20 From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: 05 July 2004 09:09=20 To: gwz@cisco.com=20 Cc: aaa-wg@merit.edu=20 Subject: [AAA-WG]: RE:=20 Glen,=20 the Service-Id is only included in CCR message (at command level) to indicate=20 to the server for what specific service the request is being issued. The server checks first the Service-Id AVP and, if it doesn't recognize the value of this AVP, it rejects the request without any further processing (e.g. rating or what so ever). If the server recognizes the value of the Service-Id AVP, it continues the processing and authorizes the credit if possible (i.e. if there is enough credit in the user's account). =20 The section 4.1 has been restructured on request of IESG review as follow, the inclusion of the Service-Id in CCR is mandatory. Whenever the IESG and the ADs will agree that their comments have been properly addressed, the draft 06 will be carried out and made available. Regards=20 Marco=20 4.1 Service-Specific Rating Input and Interoperability=20 =20 The Diameter Credit-Control Application defines the framework for credit=20 control; it provides generic credit control mechanisms supporting multiple=20 service applications. The Credit Control Application, therefore, does not=20 define AVPs that could be used as input in the rating process. Listing the=20 possible services that could use this Diameter application is seen as out=20 of scope for this generic mechanism as well. =20 =20 Furthermore, it is reasonable to expect that there will exist a service=20 level agreement between providers of the credit-control client and the=20 credit-control server covering the charging, services offered, roaming=20 agreements, agreed rating input (i.e. AVPs), etc.=20 Therefore, it is assumed that a Diameter credit control server will=20 provide service only for Diameter credit-control clients that have agreed=20 beforehand the content of credit control messages. Protocol wise, it is=20 naturally possible that any arbitrary Diameter credit-control client can=20 interchange credit control messages with any Diameter credit control=20 server, but with a higher likelihood that unsupported services/AVPs could=20 be present in the credit-control message causing the server to reject the=20 request with an appropriate result-code.=20 =20 4.1.1 Specifying Rating Input AVPs=20 =20 There are two ways for providing rating input to the credit control=20 server, either by using AVPs or by including them in the Service-=20 Parameter-Info AVP. The general principles for sending rating parameters=20 are:=20 =20 1a. The service SHOULD re-use existing AVPs, if the service can use AVPs=20 defined in existing Diameter applications (e.g. NASREQ for network=20 access services). Re-use of existing AVPs is strongly recommended in=20 [DIAMBASE].=20 For AVPs of type Enumerated the service may require a new value to be=20 defined. Allocation of new AVP values is done as specified in=20 [DIAMBASE], section 1.2.=20 =20 1b. New AVPs can be defined if the existing AVPs do not provide sufficient=20 rating information. In such a case, the procedures defined in=20 [DIAMBASE] for creating new AVPs MUST be followed.=20 =20 1c. For services specific only to one vendor's implementation, a Vendor-=20 Specific AVP code for Private use can be used. Where a Vendor-Specific=20 AVP is implemented by more than one vendor, allocation of global AVPs=20 are encouraged instead, refer to [DIAMBASE].=20 =20 2. The Service-Parameter-Info AVP MAY be used as a container to pass=20 legacy rating information in its original encoded form (e.g. ASN.1 BER). This method can be used to avoid unnecessary data format=20 conversions from an existing format to an AVP format. In that case the=20 rating input is embedded in the Service-Parameter-Info AVP as defined=20 in section 8.42.=20 =20 New service applications SHOULD favor the use of explicitly defined AVPs=20 as described in items 1a and 1b, to simplify interoperability. =20 =20 4.1.2 Application Support=20 =20 Since the Application-Id of the Diameter Credit Control Application does=20 not uniquely identify the service being monitored, an additional mechanism=20 is needed. The service application MUST be identified using the Service-=20 Identifier AVP at command level. A server receiving a request for a=20 service application it does not support will reject the request as defined=20 in sub-section 4.1.4. The Service-Identifier AVP MUST be a unique=20 identifier for a given service as defined in section 8.28. =20 =20 Thus, the combination of the Diameter Credit Control Application-Id and=20 the Service-Identifier AVP in the Credit-Control-Request command uniquely=20 defines the service within the context of the Diameter Credit Control, and=20 hence provides interoperability between Diameter credit control clients=20 and server.=20 =20 With this mechanism it is possible to cover additional service specific=20 requirements as needed in other documents. However, introducing new credit=20 control mechanisms to the framework defined in this specification, require=20 definition of a new version of the Diameter Credit Control Application and=20 corresponding Application Identifier.=20 =20 4.1.3 Service-Specific Documentation=20 =20 The service specific rating input AVPs, the contents of the Service-=20 Parameter-Info AVP or Service-Identifier AVP are not within the scope of=20 this document. To facilitate interoperability, it is RECOMMENDED that the=20 rating input and the values of the service identifiers are coordinated via=20 an informational RFC or other permanent and readily available reference=20 such as the specification of another cooperative standardization body (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services may=20 be deployed that are subject to agreements between providers of the credit=20 control server and client, in this case vendor specific AVPs can be used. =20 =20 This specification, together with the above service specific documents,=20 governs the credit control message. The rule is that service specific documents define what existing AVPs or new AVPs are used as input to the=20 rating process (i.e. they do not define new credit control applications),=20 and thus need to be included in the Credit-Control-Request command by a=20 Diameter Credit Control Client supporting a given service as *[AVP].=20 Should Service-Parameter-Info be used, then the service specific document=20 MUST specify the exact content of this grouped AVP.=20 =20 4.1.4 Handling of Unsupported/Incorrect Rating Input =20 =20 Diameter credit control implementations are required to support the=20 Mandatory rating AVPs defined in service specific documentation of the=20 services they support according to the 'M' bit rules in [DIAMBASE]. =20 =20 In case a rating input required for the rating process is incorrect in the=20 Credit control request, or the credit control server does not support the=20 requested service (identified by the Service-Idntifier AVP at command level), the Credit control answer MUST contain error code=20 DIAMETER_RATING_FAILED. A CCR message with this error MUST contain one or=20 more Failed-AVP AVPs containing the missing and/or unsupported AVPs that=20 caused the failure. A Diameter credit control client receiving error code=20 DIAMETER_RATING_FAILED in answer to a request MUST NOT send such similar=20 requests in the future.=20 =20 4.1.5 RADIUS Vendor-Specific Rating Attributes=20 =20 When service specific documents include RADIUS vendor specific attributes=20 that could be used as input in the rating process, the rules described in=20 [NASREQ] for formatting the Diameter AVP MUST be followed. For example,=20 the AVP code used is the vendor attribute type code, the Vendor-Specific=20 flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor=20 identification value. The Diameter AVP data field contains only the=20 attribute value of the RADIUS attribute.=20 > -----Original Message-----=20 > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of=20 > ext Glen Zorn=20 > Sent: 02 July, 2004 20:27=20 > To: aaa-wg@merit.edu=20 > Subject:=20 >=20 >=20 > Description of issue: No guarantee of interoperability=20 > between CCA implementations=20 > Submitter name: Glen Zorn=20 > Submitter email address: gwz@cisco.com=20 > Date first submitted: 2 July 2004=20 > Document: dcca=20 > Comment type: T=20 > Priority: S=20 > Section: 4.1=20 > Rationale/Explanation of issue:=20 > In order to interoperate, Diameter peers implementing the=20 > Diameter Credit Control Application must agree upon both the=20 > application and the service (specified in the=20 > Service-Identifier AVP). However, the inclusion of the=20 > Service-Identifier in the CCR and CCA messages is optional.=20 >=20 > Lengthy description of problem:=20 > Section 4.1, para. 6 states "it is the combination of support=20 > of the Diameter Credit Control Application and the service=20 > defined in the Service-Identifier AVP, which defines=20 > interoperability between any given credit control client and=20 > server." However, the inclusion of the Service-Identifier in=20 > the CCR and CCA messages is optional. This gives rise to a=20 > situation where two peers implementing the same application=20 > may not interoperate because they do not implement the same=20 > "service", and further, refuse to clearly communicate that fact.=20 >=20 > Requested change:=20 > Change section 4.1, paragraph 5 from=20 >=20 > This specification, together with service specific documents, is=20 > governing the credit control message. The rule is that service=20 > specific documents only define what existing AVPs or new AVPs are=20 > used as input to the rating process (i.e. they do not define new=20 > credit control applications), and thus need to be included in the=20 > Credit-Control-Request command by a Diameter Credit Control Client=20 > supporting a given service as *[AVP]. In order to define new AVPs,=20 > service specific documents MUST follow the practices defined in=20 > [DIAMBASE]. The service SHOULD be identified using the Service-=20 > Identifier AVP. The Service-Identifier AVP MUST be a unique=20 > identifier for a given service as defined in section 8.28.=20 >=20 > to=20 >=20 > This specification, together with service specific documents, is=20 > governing the credit control message. The rule is that service=20 > specific documents only define what existing AVPs or new AVPs are=20 > used as input to the rating process (i.e. they do not define new=20 > credit control applications), and thus need to be included in the=20 > Credit-Control-Request command by a Diameter Credit Control Client=20 > supporting a given service as *[AVP]. In order to define new AVPs,=20 > service specific documents MUST follow the practices defined in=20 > [DIAMBASE]. The service MUST be identified using the Service-=20 > Identifier AVP. The Service-Identifier AVP MUST be a unique=20 > identifier for a given service as defined in section 8.28.=20 >=20 > ~gwz=20 >=20 > "They that can give up essential liberty to obtain a little=20 > temporary safety deserve neither..."=20 > -- Benjamin Franklin, 1759=20 >=20 >=20 > "It is forbidden to kill; therefore all murderers are=20 > punished unless they kill in large numbers and to the sound=20 > of trumpets."=20 > -- Voltaire=20 >=20 >=20 ------_=_NextPart_001_01C46370.1B29C678 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DCC Service-Identifier (was RE: [AAA-WG]: RE: = )
Mark, Marco
 
I hadn't made the same assumption - but = agree that=20 there is ambiguity here.
 
I had asumed that when present on the = command=20 level, the service-ID refers to the "rating-root" which then needs to be = common=20 between client and serer.
 
Then the issue exists with = re-introducing the=20 service-ID at the MSCC level, now possibly below the sub-session-ID = which I=20 think is the cause of the issue. IMO these AVPs at the MSCC=20 level should be subordinate to the service-ID on the command=20 level.
 
Cheers,
Mark

From: owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu] On Behalf Of Mark = Watson
Sent:=20 06 July 2004 11:08
To: 'marco.stura@nokia.com'
Cc:=20 'aaa-wg@merit.edu'; Glen Zorn (gwz); Claire Mousset
Subject: = DCC=20 Service-Identifier (was RE: [AAA-WG]: RE: )

Hi Marco,

Some quick questions for clarification on this = one...=20

1) If the client wants to request quotas for multiple = services=20 using the Multiple-Services-Credit-Control AVP then what should it put = in the=20 mandatory command level Service-Identifier AVP ?

2) Service-Identifier is finer granlarity than = Rating-Group -=20 that is several services with unique Service-Identifiers are grouped = within a=20 single Rating-Group. So a 'service' identified by a Service-Identifier = is=20 basically the finest granularity thing that can be separately=20 charged.

But then the definition of the Service Identifier AVP = speaks of=20 statically configured or standardised values. To be consistent with the = above it=20 would need to be a format or pattern than was configured/standardised - = e.g. if=20 it's voice calls that you are charging for then Service Identifies like=20 'voice001@blah.org', 'voice002@blah.org' would be needed to distinguish = between=20 multiple concurrent voice calls.

Right ?

3) It isn't possible to request credit for a = Rating-Group except=20 by using the Multiple-Services-Credit-Control AVP, right ?

Regards...Mark


-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20
Sent: 05 July 2004 09:09
To:=20 gwz@cisco.com
Cc: aaa-wg@merit.edu =
Subject: [AAA-WG]: RE:


Glen,

the Service-Id is only included in CCR message (at = command=20 level) to indicate
to the server for what = specific=20 service the request is being issued. The server checks first the = Service-Id AVP=20 and, if it doesn't recognize the value of this AVP, it rejects the = request=20 without any further processing (e.g. rating or what so ever). If the = server=20 recognizes the value of the Service-Id AVP, it continues the processing = and=20 authorizes the credit if possible (i.e. if there is enough credit in the = user's=20 account). 

The section 4.1 has been restructured on request of = IESG review=20 as follow, the inclusion of the Service-Id in CCR is = mandatory.

Whenever the IESG and the ADs will agree that their = comments=20 have been properly addressed, the draft 06 will be carried out and made=20 available.

Regards
Marco

4.1 Service-Specific Rating Input and Interoperability =
   
  =20 The Diameter Credit-Control Application defines the framework for credit =
   control; it provides generic = credit control=20 mechanisms supporting multiple
   = service=20 applications. The Credit Control Application, therefore, does not=20
   define AVPs that could be used as = input in=20 the rating process. Listing the
   = possible=20 services that could use this Diameter application is seen as out=20
   of scope for this generic = mechanism as=20 well. 
    =
   Furthermore, it is reasonable to expect that there = will=20 exist a service
   level agreement = between=20 providers of the credit-control client and the
   credit-control server covering the charging, = services=20 offered, roaming
   agreements, = agreed rating=20 input (i.e. AVPs), etc.

   Therefore, it is assumed that a Diameter = credit=20 control server will
   provide = service only=20 for Diameter credit-control clients that have agreed
   beforehand the content of credit control messages. = Protocol=20 wise, it is
   naturally possible = that any=20 arbitrary Diameter credit-control client can
   interchange credit control messages with any = Diameter credit=20 control
   server, but with a higher = likelihood that unsupported services/AVPs could
   be present in the credit-control message causing = the server=20 to reject the
   request with an = appropriate=20 result-code.
    =
4.1.1 Specifying Rating Input AVPs
   
   There = are two=20 ways for providing rating input to the credit control
   server, either by using AVPs or by including them = in the=20 Service-
   Parameter-Info AVP. The = general=20 principles for sending rating parameters
  =20 are:
   
   1a. The service SHOULD re-use existing AVPs, if = the service=20 can use AVPs
      =20 defined in existing Diameter applications (e.g. NASREQ for network=20
       access = services).=20 Re-use of existing AVPs is strongly recommended in
       [DIAMBASE].

       For AVPs of type = Enumerated=20 the service may require a new value to be
       defined. Allocation of new = AVP=20 values is done as specified in
       [DIAMBASE], section 1.2.=20
   
  =20 1b. New AVPs can be defined if the existing AVPs do not provide = sufficient=20
       rating = information.=20 In such a case, the procedures defined in
       [DIAMBASE] for creating = new AVPs=20 MUST be followed.
    =
   1c. For services specific only to one vendor's=20 implementation, a Vendor-
       Specific AVP code for = Private use=20 can be used. Where a Vendor-Specific
       AVP is implemented by more = than one=20 vendor, allocation of global AVPs
       are encouraged instead, = refer to=20 [DIAMBASE].
    =
   2. The Service-Parameter-Info AVP MAY be used as a = container=20 to pass
      legacy = rating=20 information in its original encoded form (e.g. ASN.1
      BER). This method can be used to = avoid=20 unnecessary data format
     =20 conversions from an existing format to an AVP format. In that case the=20
      rating input is = embedded=20 in the Service-Parameter-Info AVP as defined
      in section 8.42. =
   
   New = service=20 applications SHOULD favor the use of explicitly defined AVPs =
   as described in items 1a and 1b, to simplify=20 interoperability. 
   =20
4.1.2 Application Support
   
   Since = the=20 Application-Id of the Diameter Credit Control Application does =
   not uniquely identify the service being monitored, = an=20 additional mechanism
   is needed. = The service=20 application MUST be identified using the Service-
   Identifier AVP at command level. A server = receiving a=20 request for a
   service application = it does=20 not support will reject the request as defined
   in sub-section 4.1.4. The Service-Identifier AVP = MUST be a=20 unique
   identifier for a given = service as=20 defined in section 8.28. 
   =20
   Thus, the combination of the = Diameter=20 Credit Control Application-Id and
   = the=20 Service-Identifier AVP in the Credit-Control-Request command uniquely=20
   defines the service within the = context of=20 the Diameter Credit Control, and
   = hence=20 provides interoperability between Diameter credit control clients=20
   and server.
   
   With = this=20 mechanism it is possible to cover additional service specific =
   requirements as needed in other documents. = However,=20 introducing new credit
   control = mechanisms=20 to the framework defined in this specification, require
   definition of a new version of the Diameter Credit = Control=20 Application and
   corresponding = Application=20 Identifier.
    =
4.1.3 Service-Specific Documentation
    
   = The service=20 specific rating input AVPs, the contents of the Service- =
   Parameter-Info AVP or Service-Identifier AVP are = not within=20 the scope of
   this document. To = facilitate=20 interoperability, it is RECOMMENDED that the
   rating input and the values of the service = identifiers are=20 coordinated via
   an informational = RFC or=20 other permanent and readily available reference
   such as the specification of another cooperative=20 standardization body
   (e.g. 3GPP, = OMA and=20 3GPP2) SHOULD be used. However, private services may
   be deployed that are subject to agreements between = providers=20 of the credit
   control server and = client, in=20 this case vendor specific AVPs can be used. 
       
   This specification, together with the above = service specific=20 documents,
   governs the credit = control=20 message. The rule is that service specific
  =20 documents define what existing AVPs or new AVPs are used as input to the =
   rating process (i.e. they do not = define new=20 credit control applications),
   and = thus need=20 to be included in the Credit-Control-Request command by a =
   Diameter Credit Control Client supporting a given = service as=20 *[AVP].
   Should = Service-Parameter-Info be=20 used, then the service specific document
  =20 MUST specify the exact content of this grouped AVP.
   
4.1.4 Handling of=20 Unsupported/Incorrect Rating Input 
   
   = Diameter credit=20 control implementations are required to support the
   Mandatory rating AVPs defined in service specific=20 documentation of the
   services = they support=20 according to the 'M' bit rules in [DIAMBASE]. 
       
   In case a rating input required for the rating = process is=20 incorrect in the
   Credit control = request, or=20 the credit control server does not support the
   requested service (identified by the = Service-Idntifier AVP=20 at command
   level), the Credit = control=20 answer MUST contain error code
  =20 DIAMETER_RATING_FAILED. A CCR message with this error MUST contain one = or=20
   more Failed-AVP AVPs containing = the missing=20 and/or unsupported AVPs that
   = caused the=20 failure. A Diameter credit control client receiving error code =
   DIAMETER_RATING_FAILED in answer to a request MUST = NOT send=20 such similar
   requests in the = future.=20
   
4.1.5 RADIUS=20 Vendor-Specific Rating Attributes
       
   When service specific documents include RADIUS = vendor=20 specific attributes
   that could be = used as=20 input in the rating process, the rules described in
   [NASREQ] for formatting the Diameter AVP MUST be = followed.=20 For example,
   the AVP code used is = the=20 vendor attribute type code, the Vendor-Specific
   flag MUST be set to 1 and the Vendor-ID MUST be = set to the=20 IANA Vendor
   identification value. = The=20 Diameter AVP data field contains only the
  =20 attribute value of the RADIUS attribute.

> -----Original Message-----
>=20 From: owner-aaa-wg@merit.edu
> [mailto:owner-aaa-wg@merit.edu]= On Behalf=20 Of
> ext Glen Zorn
> Sent:=20 02 July, 2004 20:27
> To: = aaa-wg@merit.edu=20
> Subject:
> =
>
> Description of issue:  = No=20 guarantee of interoperability
> between CCA = implementations
> Submitter name: Glen = Zorn=20
> Submitter email address: gwz@cisco.com =
> Date first submitted: 2 July 2004
>=20 Document: dcca
> Comment type: T =
> Priority: S
> Section: = 4.1=20
> Rationale/Explanation of issue:
> In order to interoperate, Diameter peers implementing the=20
> Diameter Credit Control Application must = agree upon=20 both the
> application and the service = (specified in=20 the
> Service-Identifier AVP).  = However, the=20 inclusion of the
> Service-Identifier in = the CCR and=20 CCA messages is optional.
> =
> Lengthy description of problem:
> Section=20 4.1, para. 6 states "it is the combination of support
> of the Diameter Credit Control Application and the service =
> defined in the Service-Identifier AVP, = which=20 defines
> interoperability between any = given credit=20 control client and
> server."  = However, the=20 inclusion of the Service-Identifier in
> = the CCR and=20 CCA messages is optional.  This gives rise to a
> situation where two peers implementing the same = application=20
> may not interoperate because they do not = implement=20 the same
> "service", and further, refuse = to clearly=20 communicate that fact.
>
>=20 Requested change:
> Change section 4.1, = paragraph 5=20 from
>
>   =20 This specification, together with service specific documents, is=20
>    governing the credit = control=20 message. The rule is that service
>   =20 specific documents only define what existing AVPs or new AVPs are=20
>    used as input to the = rating=20 process (i.e. they do not define new
>    credit control applications), and thus = need to be=20 included in the
>   =20 Credit-Control-Request command by a Diameter Credit Control Client=20
>    supporting a given = service as=20 *[AVP]. In order to define new AVPs,
>    service specific documents MUST follow = the=20 practices defined in
>    = [DIAMBASE].=20 The service SHOULD be identified using the Service-
>    Identifier AVP. The Service-Identifier = AVP MUST be=20 a unique
>    identifier for = a given=20 service as defined in section 8.28.
>=20
> to
> =
>    This specification, together with = service specific=20 documents, is
>    governing = the=20 credit control message. The rule is that service
>    specific documents only define what = existing AVPs=20 or new AVPs are
>    used as = input to=20 the rating process (i.e. they do not define new
>    credit control applications), and thus = need to be=20 included in the
>   =20 Credit-Control-Request command by a Diameter Credit Control Client=20
>    supporting a given = service as=20 *[AVP]. In order to define new AVPs,
>    service specific documents MUST follow = the=20 practices defined in
>    = [DIAMBASE].=20 The service MUST be identified using the Service-
>    Identifier AVP. The Service-Identifier = AVP MUST be=20 a unique
>    identifier for = a given=20 service as defined in section 8.28.
>=20
> ~gwz
> =
> "They that can give up essential liberty to obtain a = little=20
> temporary safety deserve neither..." =
> -- Benjamin Franklin, 1759
>=20
>
> "It is = forbidden to=20 kill; therefore all murderers are
> = punished unless=20 they kill in large numbers and to the sound
> of=20 trumpets."
> -- Voltaire
>=20
>

------_=_NextPart_001_01C46370.1B29C678-- From owner-aaa-wg@merit.edu Tue Jul 6 11:51: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 LAA25104 for ; Tue, 6 Jul 2004 11:51:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E4624912E5; Tue, 6 Jul 2004 11:49:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A97B3912E3; Tue, 6 Jul 2004 11:49:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A1408912DB for ; Tue, 6 Jul 2004 11:49:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8CCD159C77; Tue, 6 Jul 2004 11:49:27 -0400 (EDT) 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 9E36659C23 for ; Tue, 6 Jul 2004 11:49:26 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i66FnHpD005191; Wed, 7 Jul 2004 00:49:17 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i66FnHTv022607; Wed, 7 Jul 2004 00:49:17 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id AAA22606 ; Wed, 7 Jul 2004 00:49:16 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id AAA08195; Wed, 7 Jul 2004 00:49:16 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id AAA03577; Wed, 7 Jul 2004 00:49:15 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i66FnFpl019958; Wed, 7 Jul 2004 00:49:15 +0900 (JST) Received: from steelhead (iVPN01-061.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0I0F00I1GTA0ZJ@tsbpo1.po.toshiba.co.jp>; Wed, 7 Jul 2004 00:49:14 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Bhrkn-0008Bd-00; Tue, 06 Jul 2004 08:21:05 -0700 Date: Tue, 06 Jul 2004 11:21:04 -0400 From: Yoshihiro Ohba Subject: Re: [AAA-WG]: Issue 464: Application-Id Usage In-reply-to: To: Bernard Aboba Cc: aaa-wg@merit.edu, pasi.eronen@nokia.com Message-id: <20040706152104.GA29435@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040523i References: Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Bernard, Your interpretation totally makes sense to me. Yoshihiro Ohba On Mon, Jul 05, 2004 at 05:55:59PM -0700, Bernard Aboba wrote: > Pasi Eronen noted: > > >This seems to imply that a new application can't borrow only > >a subset of mandatory commands from an existing application..? > > > >Otherwise we could get a conflict. Let's assume that application > >X has commands C1 and C2, and application Y defines a new > >command C3 and borrows C1 from X (without any new mandatory > >AVPs). > > >It seems that a Diameter server implementing only Y can't > >advertise support for X, since it does not implement C2. > >But using application identifier of X for C1 is not allowed > >either, since this seems to contradict the text saying that > >"When a request is routed, the target server MUST have > >advertised the Application Identifier (see Section 2.4) for > >the given message. > > >Another related issue is whether two different applications > >could use the same AVP (in the same command and with the same > >application ID) for slightly different purposes. At least this > >happens all the time with RADIUS, but perhaps the different uses > >can be distinguished even if the application ID is the same..." > > If application Y defines a new command C3, then it needs to advertise > application Y, since otherwise it can't be guaranteed that Diameter peers > will select a path that will allow command C3 to be sent from Diameter > client to server. > > The question is whether it should also advertise the application that it > inherited command C1 from, even though it doesn't support command C2. > > If the application-Id in question is Diameter Base (Application-ID 0) I > think there is no issue, since this is mandatory-to-implement for all > Diameter peers. > > However, if we are talking about multiple inheritance (e.g. inheriting > commands from an Application-Id other than Base authentication and > accounting) I think we have a problem. I'd interpret RFC 3588 as allowing > an out for this, since the number of round-trips is changed (e.g. the > common is disallowed altogether). > > Does this make sense? > > In this particular case, is there any issue with advertising Diameter Base > Common Messages as well as EAP? I think there isn't because EAP supports > all Base commands. However, there might be an issue with advertising > NASREQ where the NAS or server doesn't support PAP/CHAP (AAR/AAA). From owner-aaa-wg@merit.edu Tue Jul 6 12:21: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 MAA28797 for ; Tue, 6 Jul 2004 12:21:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0C1C091293; Tue, 6 Jul 2004 12:21:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C16DC91297; Tue, 6 Jul 2004 12:21:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 56E0591293 for ; Tue, 6 Jul 2004 12:21:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3BB7059CF9; Tue, 6 Jul 2004 12:21:24 -0400 (EDT) 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 C521A59DBF for ; Tue, 6 Jul 2004 12:21:22 -0400 (EDT) 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 i66GL8R27049; Tue, 6 Jul 2004 17:21:08 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Jul 2004 17:21:09 +0100 Message-ID: <588B15E2E2B1D41180B800508BF934F20F4EC738@bmdhd6.europe.nortel.com> From: "Mark Watson" To: "'Mark Grayson (mgrayson)'" , "'marco.stura@nokia.com'" Cc: "'aaa-wg@merit.edu'" , "'Glen Zorn (gwz)'" , "Claire Mousset" Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Date: Tue, 6 Jul 2004 17:21:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46375.3C0E90CC" 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_01C46375.3C0E90CC Content-Type: text/plain Hi Mark, Note sure what you mean by a 'rating-root', but it is quite clear (e.g. in the diagrams in 5.1.1) that 'services' are sub-ordinate to Rating-Groups. Since everything in a Rating-Group is rated the same way then certainly you cannot have things within a service which are rated differently. That is, services are the finest level of granularity that can be separately charged. The point of MSCC was to do in one message what could otherwise be done with several messages and only command level values - so I would expect the things appearing in the MSCC to have the same semantics as things appearing at command level & for the two to be mutually exclusive - hence Question 1 below. To answre my question (2) below for myself, we don't need multiple instances of the same service within a single sub-session. In 3GPP, I think we may have a requirement for dynamically povisioned services, but the dynamic provisioning of these to DCC client & server is out of scope here & so there should be no problem. ...Mark -----Original Message----- From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com] Sent: 06 July 2004 16:44 To: Watson, Mark [MOP:EP10:EXCH]; marco.stura@nokia.com Cc: aaa-wg@merit.edu; Glen Zorn (gwz); Mousset, Claire [ADC:8J70:EXCH] Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Mark, Marco I hadn't made the same assumption - but agree that there is ambiguity here. I had asumed that when present on the command level, the service-ID refers to the "rating-root" which then needs to be common between client and serer. Then the issue exists with re-introducing the service-ID at the MSCC level, now possibly below the sub-session-ID which I think is the cause of the issue. IMO these AVPs at the MSCC level should be subordinate to the service-ID on the command level. Cheers, Mark _____ From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of Mark Watson Sent: 06 July 2004 11:08 To: 'marco.stura@nokia.com' Cc: 'aaa-wg@merit.edu'; Glen Zorn (gwz); Claire Mousset Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Hi Marco, Some quick questions for clarification on this one... 1) If the client wants to request quotas for multiple services using the Multiple-Services-Credit-Control AVP then what should it put in the mandatory command level Service-Identifier AVP ? 2) Service-Identifier is finer granlarity than Rating-Group - that is several services with unique Service-Identifiers are grouped within a single Rating-Group. So a 'service' identified by a Service-Identifier is basically the finest granularity thing that can be separately charged. But then the definition of the Service Identifier AVP speaks of statically configured or standardised values. To be consistent with the above it would need to be a format or pattern than was configured/standardised - e.g. if it's voice calls that you are charging for then Service Identifies like 'voice001@blah.org', 'voice002@blah.org' would be needed to distinguish between multiple concurrent voice calls. Right ? 3) It isn't possible to request credit for a Rating-Group except by using the Multiple-Services-Credit-Control AVP, right ? Regards...Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com ] Sent: 05 July 2004 09:09 To: gwz@cisco.com Cc: aaa-wg@merit.edu Subject: [AAA-WG]: RE: Glen, the Service-Id is only included in CCR message (at command level) to indicate to the server for what specific service the request is being issued. The server checks first the Service-Id AVP and, if it doesn't recognize the value of this AVP, it rejects the request without any further processing (e.g. rating or what so ever). If the server recognizes the value of the Service-Id AVP, it continues the processing and authorizes the credit if possible (i.e. if there is enough credit in the user's account). The section 4.1 has been restructured on request of IESG review as follow, the inclusion of the Service-Id in CCR is mandatory. Whenever the IESG and the ADs will agree that their comments have been properly addressed, the draft 06 will be carried out and made available. Regards Marco 4.1 Service-Specific Rating Input and Interoperability The Diameter Credit-Control Application defines the framework for credit control; it provides generic credit control mechanisms supporting multiple service applications. The Credit Control Application, therefore, does not define AVPs that could be used as input in the rating process. Listing the possible services that could use this Diameter application is seen as out of scope for this generic mechanism as well. Furthermore, it is reasonable to expect that there will exist a service level agreement between providers of the credit-control client and the credit-control server covering the charging, services offered, roaming agreements, agreed rating input (i.e. AVPs), etc. Therefore, it is assumed that a Diameter credit control server will provide service only for Diameter credit-control clients that have agreed beforehand the content of credit control messages. Protocol wise, it is naturally possible that any arbitrary Diameter credit-control client can interchange credit control messages with any Diameter credit control server, but with a higher likelihood that unsupported services/AVPs could be present in the credit-control message causing the server to reject the request with an appropriate result-code. 4.1.1 Specifying Rating Input AVPs There are two ways for providing rating input to the credit control server, either by using AVPs or by including them in the Service- Parameter-Info AVP. The general principles for sending rating parameters are: 1a. The service SHOULD re-use existing AVPs, if the service can use AVPs defined in existing Diameter applications (e.g. NASREQ for network access services). Re-use of existing AVPs is strongly recommended in [DIAMBASE]. For AVPs of type Enumerated the service may require a new value to be defined. Allocation of new AVP values is done as specified in [DIAMBASE], section 1.2. 1b. New AVPs can be defined if the existing AVPs do not provide sufficient rating information. In such a case, the procedures defined in [DIAMBASE] for creating new AVPs MUST be followed. 1c. For services specific only to one vendor's implementation, a Vendor- Specific AVP code for Private use can be used. Where a Vendor-Specific AVP is implemented by more than one vendor, allocation of global AVPs are encouraged instead, refer to [DIAMBASE]. 2. The Service-Parameter-Info AVP MAY be used as a container to pass legacy rating information in its original encoded form (e.g. ASN.1 BER). This method can be used to avoid unnecessary data format conversions from an existing format to an AVP format. In that case the rating input is embedded in the Service-Parameter-Info AVP as defined in section 8.42. New service applications SHOULD favor the use of explicitly defined AVPs as described in items 1a and 1b, to simplify interoperability. 4.1.2 Application Support Since the Application-Id of the Diameter Credit Control Application does not uniquely identify the service being monitored, an additional mechanism is needed. The service application MUST be identified using the Service- Identifier AVP at command level. A server receiving a request for a service application it does not support will reject the request as defined in sub-section 4.1.4. The Service-Identifier AVP MUST be a unique identifier for a given service as defined in section 8.28. Thus, the combination of the Diameter Credit Control Application-Id and the Service-Identifier AVP in the Credit-Control-Request command uniquely defines the service within the context of the Diameter Credit Control, and hence provides interoperability between Diameter credit control clients and server. With this mechanism it is possible to cover additional service specific requirements as needed in other documents. However, introducing new credit control mechanisms to the framework defined in this specification, require definition of a new version of the Diameter Credit Control Application and corresponding Application Identifier. 4.1.3 Service-Specific Documentation The service specific rating input AVPs, the contents of the Service- Parameter-Info AVP or Service-Identifier AVP are not within the scope of this document. To facilitate interoperability, it is RECOMMENDED that the rating input and the values of the service identifiers are coordinated via an informational RFC or other permanent and readily available reference such as the specification of another cooperative standardization body (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services may be deployed that are subject to agreements between providers of the credit control server and client, in this case vendor specific AVPs can be used. This specification, together with the above service specific documents, governs the credit control message. The rule is that service specific documents define what existing AVPs or new AVPs are used as input to the rating process (i.e. they do not define new credit control applications), and thus need to be included in the Credit-Control-Request command by a Diameter Credit Control Client supporting a given service as *[AVP]. Should Service-Parameter-Info be used, then the service specific document MUST specify the exact content of this grouped AVP. 4.1.4 Handling of Unsupported/Incorrect Rating Input Diameter credit control implementations are required to support the Mandatory rating AVPs defined in service specific documentation of the services they support according to the 'M' bit rules in [DIAMBASE]. In case a rating input required for the rating process is incorrect in the Credit control request, or the credit control server does not support the requested service (identified by the Service-Idntifier AVP at command level), the Credit control answer MUST contain error code DIAMETER_RATING_FAILED. A CCR message with this error MUST contain one or more Failed-AVP AVPs containing the missing and/or unsupported AVPs that caused the failure. A Diameter credit control client receiving error code DIAMETER_RATING_FAILED in answer to a request MUST NOT send such similar requests in the future. 4.1.5 RADIUS Vendor-Specific Rating Attributes When service specific documents include RADIUS vendor specific attributes that could be used as input in the rating process, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute. > -----Original Message----- > From: owner-aaa-wg@merit.edu > [mailto:owner-aaa-wg@merit.edu ]On Behalf Of > ext Glen Zorn > Sent: 02 July, 2004 20:27 > To: aaa-wg@merit.edu > Subject: > > > Description of issue: No guarantee of interoperability > between CCA implementations > Submitter name: Glen Zorn > Submitter email address: gwz@cisco.com > Date first submitted: 2 July 2004 > Document: dcca > Comment type: T > Priority: S > Section: 4.1 > Rationale/Explanation of issue: > In order to interoperate, Diameter peers implementing the > Diameter Credit Control Application must agree upon both the > application and the service (specified in the > Service-Identifier AVP). However, the inclusion of the > Service-Identifier in the CCR and CCA messages is optional. > > Lengthy description of problem: > Section 4.1, para. 6 states "it is the combination of support > of the Diameter Credit Control Application and the service > defined in the Service-Identifier AVP, which defines > interoperability between any given credit control client and > server." However, the inclusion of the Service-Identifier in > the CCR and CCA messages is optional. This gives rise to a > situation where two peers implementing the same application > may not interoperate because they do not implement the same > "service", and further, refuse to clearly communicate that fact. > > Requested change: > Change section 4.1, paragraph 5 from > > This specification, together with service specific documents, is > governing the credit control message. The rule is that service > specific documents only define what existing AVPs or new AVPs are > used as input to the rating process (i.e. they do not define new > credit control applications), and thus need to be included in the > Credit-Control-Request command by a Diameter Credit Control Client > supporting a given service as *[AVP]. In order to define new AVPs, > service specific documents MUST follow the practices defined in > [DIAMBASE]. The service SHOULD be identified using the Service- > Identifier AVP. The Service-Identifier AVP MUST be a unique > identifier for a given service as defined in section 8.28. > > to > > This specification, together with service specific documents, is > governing the credit control message. The rule is that service > specific documents only define what existing AVPs or new AVPs are > used as input to the rating process (i.e. they do not define new > credit control applications), and thus need to be included in the > Credit-Control-Request command by a Diameter Credit Control Client > supporting a given service as *[AVP]. In order to define new AVPs, > service specific documents MUST follow the practices defined in > [DIAMBASE]. The service MUST be identified using the Service- > Identifier AVP. The Service-Identifier AVP MUST be a unique > identifier for a given service as defined in section 8.28. > > ~gwz > > "They that can give up essential liberty to obtain a little > temporary safety deserve neither..." > -- Benjamin Franklin, 1759 > > > "It is forbidden to kill; therefore all murderers are > punished unless they kill in large numbers and to the sound > of trumpets." > -- Voltaire > > ------_=_NextPart_001_01C46375.3C0E90CC Content-Type: text/html Message
Hi Mark,
 
Note sure what you mean by a 'rating-root', but it is quite clear (e.g. in the diagrams in 5.1.1) that 'services' are sub-ordinate to Rating-Groups. Since everything in a Rating-Group is rated the same way then certainly you cannot have things within a service which are rated differently. That is, services are the finest level of granularity that can be separately charged.
 
The point of MSCC was to do in one message what could otherwise be done with several messages and only command level values - so I would expect the things appearing in the MSCC to have the same semantics as things appearing at command level & for the two to be mutually exclusive - hence Question 1 below.
 
To answre my question (2) below for myself, we don't need multiple instances of the same service within a single sub-session. In 3GPP, I think we may have a requirement for dynamically povisioned services, but the dynamic provisioning of these to DCC client & server is out of scope here & so there should be no problem.
 
...Mark
-----Original Message-----
From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com]
Sent: 06 July 2004 16:44
To: Watson, Mark [MOP:EP10:EXCH]; marco.stura@nokia.com
Cc: aaa-wg@merit.edu; Glen Zorn (gwz); Mousset, Claire [ADC:8J70:EXCH]
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Mark, Marco
 
I hadn't made the same assumption - but agree that there is ambiguity here.
 
I had asumed that when present on the command level, the service-ID refers to the "rating-root" which then needs to be common between client and serer.
 
Then the issue exists with re-introducing the service-ID at the MSCC level, now possibly below the sub-session-ID which I think is the cause of the issue. IMO these AVPs at the MSCC level should be subordinate to the service-ID on the command level.
 
Cheers,
Mark

From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of Mark Watson
Sent: 06 July 2004 11:08
To: 'marco.stura@nokia.com'
Cc: 'aaa-wg@merit.edu'; Glen Zorn (gwz); Claire Mousset
Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Hi Marco,

Some quick questions for clarification on this one...

1) If the client wants to request quotas for multiple services using the Multiple-Services-Credit-Control AVP then what should it put in the mandatory command level Service-Identifier AVP ?

2) Service-Identifier is finer granlarity than Rating-Group - that is several services with unique Service-Identifiers are grouped within a single Rating-Group. So a 'service' identified by a Service-Identifier is basically the finest granularity thing that can be separately charged.

But then the definition of the Service Identifier AVP speaks of statically configured or standardised values. To be consistent with the above it would need to be a format or pattern than was configured/standardised - e.g. if it's voice calls that you are charging for then Service Identifies like 'voice001@blah.org', 'voice002@blah.org' would be needed to distinguish between multiple concurrent voice calls.

Right ?

3) It isn't possible to request credit for a Rating-Group except by using the Multiple-Services-Credit-Control AVP, right ?

Regards...Mark


-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: 05 July 2004 09:09
To: gwz@cisco.com
Cc: aaa-wg@merit.edu
Subject: [AAA-WG]: RE:


Glen,

the Service-Id is only included in CCR message (at command level) to indicate
to the server for what specific service the request is being issued. The server checks first the Service-Id AVP and, if it doesn't recognize the value of this AVP, it rejects the request without any further processing (e.g. rating or what so ever). If the server recognizes the value of the Service-Id AVP, it continues the processing and authorizes the credit if possible (i.e. if there is enough credit in the user's account). 

The section 4.1 has been restructured on request of IESG review as follow, the inclusion of the Service-Id in CCR is mandatory.

Whenever the IESG and the ADs will agree that their comments have been properly addressed, the draft 06 will be carried out and made available.

Regards
Marco

4.1 Service-Specific Rating Input and Interoperability
   
   The Diameter Credit-Control Application defines the framework for credit
   control; it provides generic credit control mechanisms supporting multiple
   service applications. The Credit Control Application, therefore, does not
   define AVPs that could be used as input in the rating process. Listing the
   possible services that could use this Diameter application is seen as out
   of scope for this generic mechanism as well. 
   
   Furthermore, it is reasonable to expect that there will exist a service
   level agreement between providers of the credit-control client and the
   credit-control server covering the charging, services offered, roaming
   agreements, agreed rating input (i.e. AVPs), etc.

   Therefore, it is assumed that a Diameter credit control server will
   provide service only for Diameter credit-control clients that have agreed
   beforehand the content of credit control messages. Protocol wise, it is
   naturally possible that any arbitrary Diameter credit-control client can
   interchange credit control messages with any Diameter credit control
   server, but with a higher likelihood that unsupported services/AVPs could
   be present in the credit-control message causing the server to reject the
   request with an appropriate result-code.
   
4.1.1 Specifying Rating Input AVPs
   
   There are two ways for providing rating input to the credit control
   server, either by using AVPs or by including them in the Service-
   Parameter-Info AVP. The general principles for sending rating parameters
   are:
   
   1a. The service SHOULD re-use existing AVPs, if the service can use AVPs
       defined in existing Diameter applications (e.g. NASREQ for network
       access services). Re-use of existing AVPs is strongly recommended in
       [DIAMBASE].

       For AVPs of type Enumerated the service may require a new value to be
       defined. Allocation of new AVP values is done as specified in
       [DIAMBASE], section 1.2.
   
   1b. New AVPs can be defined if the existing AVPs do not provide sufficient
       rating information. In such a case, the procedures defined in
       [DIAMBASE] for creating new AVPs MUST be followed.
   
   1c. For services specific only to one vendor's implementation, a Vendor-
       Specific AVP code for Private use can be used. Where a Vendor-Specific
       AVP is implemented by more than one vendor, allocation of global AVPs
       are encouraged instead, refer to [DIAMBASE].
   
   2. The Service-Parameter-Info AVP MAY be used as a container to pass
      legacy rating information in its original encoded form (e.g. ASN.1
      BER). This method can be used to avoid unnecessary data format
      conversions from an existing format to an AVP format. In that case the
      rating input is embedded in the Service-Parameter-Info AVP as defined
      in section 8.42.
   
   New service applications SHOULD favor the use of explicitly defined AVPs
   as described in items 1a and 1b, to simplify interoperability. 
   
4.1.2 Application Support
   
   Since the Application-Id of the Diameter Credit Control Application does
   not uniquely identify the service being monitored, an additional mechanism
   is needed. The service application MUST be identified using the Service-
   Identifier AVP at command level. A server receiving a request for a
   service application it does not support will reject the request as defined
   in sub-section 4.1.4. The Service-Identifier AVP MUST be a unique
   identifier for a given service as defined in section 8.28. 
   
   Thus, the combination of the Diameter Credit Control Application-Id and
   the Service-Identifier AVP in the Credit-Control-Request command uniquely
   defines the service within the context of the Diameter Credit Control, and
   hence provides interoperability between Diameter credit control clients
   and server.
   
   With this mechanism it is possible to cover additional service specific
   requirements as needed in other documents. However, introducing new credit
   control mechanisms to the framework defined in this specification, require
   definition of a new version of the Diameter Credit Control Application and
   corresponding Application Identifier.
   
4.1.3 Service-Specific Documentation
    
   The service specific rating input AVPs, the contents of the Service-
   Parameter-Info AVP or Service-Identifier AVP are not within the scope of
   this document. To facilitate interoperability, it is RECOMMENDED that the
   rating input and the values of the service identifiers are coordinated via
   an informational RFC or other permanent and readily available reference
   such as the specification of another cooperative standardization body
   (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services may
   be deployed that are subject to agreements between providers of the credit
   control server and client, in this case vendor specific AVPs can be used. 
       
   This specification, together with the above service specific documents,
   governs the credit control message. The rule is that service specific
   documents define what existing AVPs or new AVPs are used as input to the
   rating process (i.e. they do not define new credit control applications),
   and thus need to be included in the Credit-Control-Request command by a
   Diameter Credit Control Client supporting a given service as *[AVP].
   Should Service-Parameter-Info be used, then the service specific document
   MUST specify the exact content of this grouped AVP.
   
4.1.4 Handling of Unsupported/Incorrect Rating Input 
   
   Diameter credit control implementations are required to support the
   Mandatory rating AVPs defined in service specific documentation of the
   services they support according to the 'M' bit rules in [DIAMBASE]. 
       
   In case a rating input required for the rating process is incorrect in the
   Credit control request, or the credit control server does not support the
   requested service (identified by the Service-Idntifier AVP at command
   level), the Credit control answer MUST contain error code
   DIAMETER_RATING_FAILED. A CCR message with this error MUST contain one or
   more Failed-AVP AVPs containing the missing and/or unsupported AVPs that
   caused the failure. A Diameter credit control client receiving error code
   DIAMETER_RATING_FAILED in answer to a request MUST NOT send such similar
   requests in the future.
   
4.1.5 RADIUS Vendor-Specific Rating Attributes
       
   When service specific documents include RADIUS vendor specific attributes
   that could be used as input in the rating process, the rules described in
   [NASREQ] for formatting the Diameter AVP MUST be followed. For example,
   the AVP code used is the vendor attribute type code, the Vendor-Specific
   flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor
   identification value. The Diameter AVP data field contains only the
   attribute value of the RADIUS attribute.

> -----Original Message-----
> From: owner-aaa-wg@merit.edu
> [mailto:owner-aaa-wg@merit.edu]On Behalf Of
> ext Glen Zorn
> Sent: 02 July, 2004 20:27
> To: aaa-wg@merit.edu
> Subject:
>
>
> Description of issue:  No guarantee of interoperability
> between CCA implementations
> Submitter name: Glen Zorn
> Submitter email address: gwz@cisco.com
> Date first submitted: 2 July 2004
> Document: dcca
> Comment type: T
> Priority: S
> Section: 4.1
> Rationale/Explanation of issue:
> In order to interoperate, Diameter peers implementing the
> Diameter Credit Control Application must agree upon both the
> application and the service (specified in the
> Service-Identifier AVP).  However, the inclusion of the
> Service-Identifier in the CCR and CCA messages is optional.
>
> Lengthy description of problem:
> Section 4.1, para. 6 states "it is the combination of support
> of the Diameter Credit Control Application and the service
> defined in the Service-Identifier AVP, which defines
> interoperability between any given credit control client and
> server."  However, the inclusion of the Service-Identifier in
> the CCR and CCA messages is optional.  This gives rise to a
> situation where two peers implementing the same application
> may not interoperate because they do not implement the same
> "service", and further, refuse to clearly communicate that fact.
>
> Requested change:
> Change section 4.1, paragraph 5 from
>
>    This specification, together with service specific documents, is
>    governing the credit control message. The rule is that service
>    specific documents only define what existing AVPs or new AVPs are
>    used as input to the rating process (i.e. they do not define new
>    credit control applications), and thus need to be included in the
>    Credit-Control-Request command by a Diameter Credit Control Client
>    supporting a given service as *[AVP]. In order to define new AVPs,
>    service specific documents MUST follow the practices defined in
>    [DIAMBASE]. The service SHOULD be identified using the Service-
>    Identifier AVP. The Service-Identifier AVP MUST be a unique
>    identifier for a given service as defined in section 8.28.
>
> to
>
>    This specification, together with service specific documents, is
>    governing the credit control message. The rule is that service
>    specific documents only define what existing AVPs or new AVPs are
>    used as input to the rating process (i.e. they do not define new
>    credit control applications), and thus need to be included in the
>    Credit-Control-Request command by a Diameter Credit Control Client
>    supporting a given service as *[AVP]. In order to define new AVPs,
>    service specific documents MUST follow the practices defined in
>    [DIAMBASE]. The service MUST be identified using the Service-
>    Identifier AVP. The Service-Identifier AVP MUST be a unique
>    identifier for a given service as defined in section 8.28.
>
> ~gwz
>
> "They that can give up essential liberty to obtain a little
> temporary safety deserve neither..."
> -- Benjamin Franklin, 1759
>
>
> "It is forbidden to kill; therefore all murderers are
> punished unless they kill in large numbers and to the sound
> of trumpets."
> -- Voltaire
>
>

------_=_NextPart_001_01C46375.3C0E90CC-- From owner-aaa-wg@merit.edu Tue Jul 6 12:49: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 MAA01833 for ; Tue, 6 Jul 2004 12:49:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6DD8891297; Tue, 6 Jul 2004 12:49:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 413C891299; Tue, 6 Jul 2004 12:49:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1B30091297 for ; Tue, 6 Jul 2004 12:49:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 04C6159E04; Tue, 6 Jul 2004 12:49:15 -0400 (EDT) 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 B860B59DCD for ; Tue, 6 Jul 2004 12:49:14 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 06 Jul 2004 09:50:01 -0700 X-BrightmailFiltered: true Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i66GnA4N022535; Tue, 6 Jul 2004 09:49:11 -0700 (PDT) Received: from gwzw2k (sjc-vpn3-788.cisco.com [10.21.67.20]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id JAA21688; Tue, 6 Jul 2004 09:49:10 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "'Wijnen, Bert (Bert)'" Cc: Subject: RE: [AAA-WG]: Issue with draft-ietf-aaa-diameter-cc-05.txt Date: Tue, 6 Jul 2004 09:48:36 -0700 Organization: Cisco Systems Message-ID: <00b101c46379$27680e60$0202a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15504AD6879@nl0006exch001u.nl.lucent.com> 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 owner-aaa-wg@merit.edu writes: > Glen wrote: >>> Hi Glen, >>>=20 >>> actually the WG last call ended a while ago, the draft has already >>> been review by the IESG (as you may have noticed from my previous >>> email). As you know changes are not allowed at this stage, unless >>> explicitly requested by the IESG or major bugs are discovered. >>=20 >> Sorry, I'll wait for IETF Last Call, then. >>=20 >=20 > Did you see the below? > So IETF Last Call ended June 15th! Well, I'm doubly apologetic! Actually, I'd never read the document = until last week & only then because I was asked to review a customer = proposal; I did read it several times and work through the protocol = operation last week, though, during which activities I discovered what I = believed to be these problems. However, if both WG & IESG consensus is = that the protocol actually works in an RFC 3588 environment, I must be = mistaken. Again, sorry for causing the ruckus & wasting everyone's = time. >=20 > Bert >=20 > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: dinsdag 1 juni 2004 20:52 > To: IETF-Announce > Subject: Last Call: 'Diameter Credit-control Application' to Proposed > Standard=20 >=20 >=20 > The IESG has received a request from the Authentication, > Authorization and Accounting WG to consider the following document: >=20 > - 'Diameter Credit-control Application ' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2004-06-15. =20 >=20 > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-05.txt=20 Hope this helps, ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..."=20 -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets."=20 -- Voltaire From owner-aaa-wg@merit.edu Tue Jul 6 13:28: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 NAA04477 for ; Tue, 6 Jul 2004 13:28:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B56CA9121A; Tue, 6 Jul 2004 13:28:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B3A591299; Tue, 6 Jul 2004 13:28:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3CCBB9121A for ; Tue, 6 Jul 2004 13:28:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 26CDF59E3C; Tue, 6 Jul 2004 13:28:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by segue.merit.edu (Postfix) with ESMTP id D786259EB2 for ; Tue, 6 Jul 2004 13:28:09 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 06 Jul 2004 10:28:27 -0700 Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i66HS64N001800; Tue, 6 Jul 2004 10:28:06 -0700 (PDT) Received: from gwzw2k (sjc-vpn3-788.cisco.com [10.21.67.20]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id KAA04299; Tue, 6 Jul 2004 10:28:05 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "'Christopher Richards'" Cc: , "'Bernard Aboba'" , Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage Date: Tue, 6 Jul 2004 10:27:32 -0700 Organization: Cisco Systems Message-ID: <00c201c4637e$9781ecc0$0202a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 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: 7bit owner-aaa-wg@merit.edu writes: > Hi Bernard, All, > > I still have a problem with the use of an application-id of a > different application in a command. > > Firstly, there is section 3 of RFC 3588. It states that the > application-id in the header of any command MUST be the same as the > application id in any relevant AVPs. > > Secondly, what if a Diameter peer does not want to use a base > application but only wants to use some other application. It wants to > advertise support for application X but does not want to be used for > a base application (regardless of it's ability to support the base > applications). For example, an operator may want to disable a node's > Diameter Accounting application while maintaining some other > application(s). While I can certainly understand the desire of some operators to treat RFCs as if they were ala carte menus ("I'll take the authentication and authorization with a side of credit control, hold the accounting" ;-), that doesn't match my understanding of how the documents are meant to be used. This is certainly an issue in the purview of the IESG, but my understanding is that unless an implementation adheres to all of the MUSTs in a Standards-Track RFC, it cannot be said to conform to that RFC (RFC 2026). > The Diameter protocol should not force the node to > advertise support for an application that is not enabled. I don't think that accounting is an application, from a Diameter perspective. As I read RFC 3588, accounting is an integral part of the Diameter base protocol which _all_ Diameter peers must support. In other words, if a "Diameter" peer doesn't support accounting, it's not a Diameter peer. This is not to say that a Diameter peer has to _do_ anything with accounting data, for example, but it must not reject it. > > Regardless of which spec a command is defined, a command is only > relevant to the application to which the command is destined. E.g. if > a management node wants to Abort a DCCA session on the DCCA client, > it only makes sense to send the ASR to the DCC client application - > since it is the DCC client application which is handling the session. Yes, but only if the semantics of a "session" are the same for DCCA as Diameter base; it's not clear to me that this is the case. > > Cheers, > Chris > > Tel: +1 613 763 8031 > ESN: 393 8031 > > > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: July 5, 2004 8:56 PM > To: aaa-wg@merit.edu > Cc: pasi.eronen@nokia.com > Subject: [AAA-WG]: Issue 464: Application-Id Usage > > > Pasi Eronen noted: > >> This seems to imply that a new application can't borrow only >> a subset of mandatory commands from an existing application..? >> >> Otherwise we could get a conflict. Let's assume that application X >> has commands C1 and C2, and application Y defines a new command C3 >> and borrows C1 from X (without any new mandatory AVPs). > >> It seems that a Diameter server implementing only Y can't advertise >> support for X, since it does not implement C2. But using application >> identifier of X for C1 is not allowed either, since this seems to >> contradict the text saying that "When a request is routed, the target >> server MUST have advertised the Application Identifier (see Section >> 2.4) for the given message. > >> Another related issue is whether two different applications could use >> the same AVP (in the same command and with the same application ID) >> for slightly different purposes. At least this happens all the time >> with RADIUS, but perhaps the different uses can be distinguished >> even if the application ID is the same..." > > If application Y defines a new command C3, then it needs to advertise > application Y, since otherwise it can't be guaranteed that Diameter > peers will select a path that will allow command C3 to be sent from > Diameter client to server. > > The question is whether it should also advertise the application that > it inherited command C1 from, even though it doesn't support command > C2. > > If the application-Id in question is Diameter Base (Application-ID 0) > I think there is no issue, since this is mandatory-to-implement for > all Diameter peers. > > However, if we are talking about multiple inheritance (e.g. > inheriting commands from an Application-Id other than Base > authentication and > > accounting) I think we have a problem. I'd interpret RFC 3588 as > allowing an out for this, since the number of round-trips is changed > (e.g. the common is disallowed altogether). > > Does this make sense? > > In this particular case, is there any issue with advertising Diameter > Base Common Messages as well as EAP? I think there isn't because EAP > supports all Base commands. However, there might be an issue with > advertising NASREQ where the NAS or server doesn't support PAP/CHAP > (AAR/AAA). Hope this helps, ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire From owner-aaa-wg@merit.edu Tue Jul 6 17:38: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 RAA25215 for ; Tue, 6 Jul 2004 17:38:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9BE5D9122A; Tue, 6 Jul 2004 17:38:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BA45912AD; Tue, 6 Jul 2004 17:38:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 168579122A for ; Tue, 6 Jul 2004 17:38:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D697259FCD; Tue, 6 Jul 2004 17:38:00 -0400 (EDT) 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 88C2C59FB0 for ; Tue, 6 Jul 2004 17:38:00 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 06 Jul 2004 14:44:04 +0000 X-BrightmailFiltered: true Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i66Lbu4N022441; Tue, 6 Jul 2004 14:37:56 -0700 (PDT) Received: from gwzw2k (sjc-vpn2-469.cisco.com [10.21.113.213]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id OAA23356; Tue, 6 Jul 2004 14:37:55 -0700 (PDT) Reply-To: From: "Glen Zorn" To: Cc: Subject: RE: [AAA-WG]: Issue with draft-ietf-aaa-diameter-cc-05.txt Date: Tue, 6 Jul 2004 14:37:26 -0700 Organization: Cisco Systems Message-ID: <005b01c463a1$80346b60$0202a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D018B05B7@esebe016.ntc.nokia.com> 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 marco.stura@nokia.com writes: Just for my own edification, since I'm obviously missing something... >> OK, but how is this problem solved by _not_ including the=20 >> Service-Identifier in the CER/CEA? It seems like what you are saying = >> is that CCA just won't work through relays... >=20 > Actually I was thinking to your proposal.... > I think the DCC should just work fine with relays too. I guess I'll just take your word for it & drop the matter. >=20 >> I think that the existing capabilities exchange mechanism is=20 >> sufficient, if used properly. This mechanism seems to me (please=20 >> correct me if I'm wrong -- I can't find any rationale in the I-D, but = >> maybe I just missed it) to be just a way to avoid having to get a new = >> app ID from IANA, but that seems a poor reason to break Diameter. >=20 > Hmm...'break Diameter' it seems a bit to strong statement. OK. My assertion was based on the belief that a DCC message could be = routed correctly (from a Diameter POV) and still arrive at a peer that = could not understand it. Is that not the case? =20 > The application is always the DCC, no reason to define new app ID. OK. So I guess that you are saying that any DCC message can be routed = to any DCC server and it will be understood? I didn't get that from the = I-D. > The rational for the service-id is explained in section 4.1 >=20 > clip >=20 > 'The Diameter Credit Control Application defines the framework for > credit control; it provides generic credit control mechanisms > supporting multiple service applications. The Credit Control > Application, therefore, does not define AVPs that could be used as > input in the rating process. Listing the possible services that > could use this Diameter application is seen as out of scope for > this generic mechanism as well.' Hmm. Maybe I'm right after all, then...it's quite confusing. My claim = would be that what is actually specified in the document is an = application framework, not an application (again, in the RFC 3588 sense = of the term); your quote seems to justify this claim. >=20 > Because we couldn't define all the possible rating inputs for all the=20 > possible services (i.e. the attributes to qualify the service and=20 > determine its price), the service-id was introduced as primary 'rating = > root' so that the server knows immediately whether the requested=20 > service can be rated before to perform very expensive operations such=20 > as invoking the rating process and eventually reject > the request. =20 >=20 >> I still don't see how this really helps much. For example, suppose=20 >> that the only route from an access point to a set of >> n>1 servers (all of which support CCA, but only 1 of which >> supports the correct service) is through a relay. It doesn't seem to = >> matter how many CER/CEA exchanges take place between the client and=20 >> the relay, unless the relay happens by chance to send the CCR to the=20 >> right server the protocol will fail. Put another way, in the=20 >> pathological case the relay might _never_ select the right server. >=20 > The DCC rely on two different models, assuming your access point=20 > perform service specific authentication/authorization with a AAA > server: >=20 > 1- The AAA server returns in the AA-answer the FQDN of the > credit-control server(s) that support this service. OK. How does the AAA server know which of the (possibly many) = DCC-servers supports this particular service, since the = Service-Identifier in not included in the CER/CEA messages? Is it a = configured parameter? > The DCC-client > will contact then the server to perform credit authorization. > 2- If the model defined in sect. 5.2.2 is used, the AAA server > advertises support for the DCC. The relay sends the request to > this AAA server, which then select the appropriate CC-server on > the basis of its knowledge of the user and requested service. > Communication with the CC-Server continues via the AAA server. Again, it's not really clear to me how the AAA server knows which is the = appropriate CC-server. >=20 > Hope this clarify > Marco Apparently dense, ~gwz "They that can give up essential liberty to obtain a little temporary = safety deserve neither..."=20 -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless = they kill in large numbers and to the sound of trumpets."=20 -- Voltaire From owner-aaa-wg@merit.edu Tue Jul 6 18:33: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 SAA00290 for ; Tue, 6 Jul 2004 18:33:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3DAFA912AD; Tue, 6 Jul 2004 18:33:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08FDB912AE; Tue, 6 Jul 2004 18:33:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 015CD912AD for ; Tue, 6 Jul 2004 18:33:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E2F5C5A008; Tue, 6 Jul 2004 18:33:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 4587B59FF0 for ; Tue, 6 Jul 2004 18:33:47 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i66MWRW06779 for ; Tue, 6 Jul 2004 15:32:27 -0700 Date: Tue, 6 Jul 2004 15:32:27 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Proposed AAA WG Agenda for IETF 60 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Authentication, Authorization and Accounting (AAA) WG Tuesday, August 3, 2004 1415-1515 Chairs: Bernard Aboba John Loughney David Mitton Preliminaries (5 minutes) Agenda Bluesheets Agenda Bash Document Status Diameter MIPv4, Pete McCann, 5 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-18.txt Diameter NASREQ, David Mitton, 5 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-16.txt Diameter Credit Control, John Loughney, 5 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-05.txt Diameter URI, M. Garcia-Martin, 5 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-01.txt Diameter SIP, M. Belinchon, 5 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-02.txt Diameter EAP, Pasi Eronen, 5 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-08.txt Alternative EAP keying approaches, Glen Zorn & Jesse Walker, 10 minutes http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-00.txt http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-01.txt Discussion & Wrapup, 10 minutes From owner-aaa-wg@merit.edu Wed Jul 7 03:23: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 DAA27456 for ; Wed, 7 Jul 2004 03:23:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1935F91249; Wed, 7 Jul 2004 03:23:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CAA209124A; Wed, 7 Jul 2004 03:23:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9C3EB91249 for ; Wed, 7 Jul 2004 03:23:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7E50C5A1E4; Wed, 7 Jul 2004 03:23:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 454685A1E2 for ; Wed, 7 Jul 2004 03:23:41 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i677NQ216793; Wed, 7 Jul 2004 10:23:26 +0300 (EET DST) X-Scanned: Wed, 7 Jul 2004 10:22:24 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i677MOgT014155; Wed, 7 Jul 2004 10:22:24 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00FtnQNM; Wed, 07 Jul 2004 10:22:23 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i677MMH09126; Wed, 7 Jul 2004 10:22:22 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jul 2004 10:22:09 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jul 2004 10:22:08 +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="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [AAA-WG]: Issue with draft-ietf-aaa-diameter-cc-05.txt Date: Wed, 7 Jul 2004 10:22:08 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B05B8@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue with draft-ietf-aaa-diameter-cc-05.txt Thread-Index: AcRjoY/ThARtRIeKSJec01RRqzUJ7wAUD2Cw From: To: Cc: X-OriginalArrivalTime: 07 Jul 2004 07:22:08.0341 (UTC) FILETIME=[1CBA9850:01C463F3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: base64 PiA+IFRoZSBEQ0MgcmVseSBvbiB0d28gZGlmZmVyZW50IG1vZGVscywgYXNzdW1pbmcgeW91ciBh Y2Nlc3MgcG9pbnQgDQo+ID4gcGVyZm9ybSBzZXJ2aWNlIHNwZWNpZmljIGF1dGhlbnRpY2F0aW9u L2F1dGhvcml6YXRpb24gd2l0aCBhIEFBQQ0KPiA+IHNlcnZlcjoNCj4gPiANCj4gPiAxLSBUaGUg QUFBIHNlcnZlciByZXR1cm5zIGluIHRoZSBBQS1hbnN3ZXIgdGhlIEZRRE4gb2YgdGhlDQo+ID4g ICAgY3JlZGl0LWNvbnRyb2wgc2VydmVyKHMpIHRoYXQgc3VwcG9ydCB0aGlzIHNlcnZpY2UuDQo+ IA0KPiBPSy4gIEhvdyBkb2VzIHRoZSBBQUEgc2VydmVyIGtub3cgd2hpY2ggb2YgdGhlIChwb3Nz aWJseSANCj4gbWFueSkgRENDLXNlcnZlcnMgc3VwcG9ydHMgdGhpcyBwYXJ0aWN1bGFyIHNlcnZp Y2UsIHNpbmNlIHRoZSANCj4gU2VydmljZS1JZGVudGlmaWVyIGluIG5vdCBpbmNsdWRlZCBpbiB0 aGUgQ0VSL0NFQSBtZXNzYWdlcz8gIA0KPiBJcyBpdCBhIGNvbmZpZ3VyZWQgcGFyYW1ldGVyPw0K DQpXaGVuIHRoZSBBQUEgc2VydmVyIGF1dGhvcml6ZXMgYSB1c2VyIHRvIGFjY2VzcyBhIHNlcnZp Y2UgaXQgaGFzIGtub3dsZWRnZQ0KYSkgb2YgdGhlIHVzZXIgYW5kIGIpIG9mIHRoZSBzZXJ2aWNl LiBUaGUgRENDIHNlcnZlciBtYXkgYmUgY29uZmlndXJlZA0KaW4gYW4gYXBwcm9wcmlhdGUgREIg YXMgcGFydCBvZiB0aGUgc3Vic2NyaWJlci9zZXJ2aWNlIGRhdGEuDQoNCj4gDQo+ID4gICAgVGhl IERDQy1jbGllbnQNCj4gPiAgICB3aWxsIGNvbnRhY3QgdGhlbiB0aGUgc2VydmVyIHRvIHBlcmZv cm0gY3JlZGl0IGF1dGhvcml6YXRpb24uDQo+ID4gMi0gSWYgdGhlIG1vZGVsIGRlZmluZWQgaW4g c2VjdC4gNS4yLjIgaXMgdXNlZCwgdGhlIEFBQSBzZXJ2ZXINCj4gPiAgICBhZHZlcnRpc2VzIHN1 cHBvcnQgZm9yIHRoZSBEQ0MuIFRoZSByZWxheSBzZW5kcyB0aGUgcmVxdWVzdCB0bw0KPiA+ICAg IHRoaXMgQUFBIHNlcnZlciwgd2hpY2ggdGhlbiBzZWxlY3QgdGhlIGFwcHJvcHJpYXRlIENDLXNl cnZlciBvbg0KPiA+ICAgIHRoZSBiYXNpcyBvZiBpdHMga25vd2xlZGdlIG9mIHRoZSB1c2VyIGFu ZCByZXF1ZXN0ZWQgc2VydmljZS4NCj4gPiAgICBDb21tdW5pY2F0aW9uIHdpdGggdGhlIENDLVNl cnZlciBjb250aW51ZXMgdmlhIHRoZSBBQUEgc2VydmVyLg0KPiANCj4gQWdhaW4sIGl0J3Mgbm90 IHJlYWxseSBjbGVhciB0byBtZSBob3cgdGhlIEFBQSBzZXJ2ZXIga25vd3MgDQo+IHdoaWNoIGlz IHRoZSBhcHByb3ByaWF0ZSBDQy1zZXJ2ZXIuDQoNClNhbWUgYXMgYWJvdmUuIE5vdGUgdGhhdCBp biB0aGUgc2VjdCA1LjIuMiBtb2RlbCB0aGUgU2VydmljZS1JZCBjYW4gYmUNCmluY2x1ZGVkIGlu IHRoZSBBQS1yZXF1ZXN0Lg0KDQpNYXJjbw0K From owner-aaa-wg@merit.edu Wed Jul 7 07:08: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 HAA11217 for ; Wed, 7 Jul 2004 07:08:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3DAD39124F; Wed, 7 Jul 2004 07:08:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0723891250; Wed, 7 Jul 2004 07:08:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EB6499124F for ; Wed, 7 Jul 2004 07:08:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D911159E4C; Wed, 7 Jul 2004 07:08:18 -0400 (EDT) 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 2CA345982E for ; Wed, 7 Jul 2004 07:08:18 -0400 (EDT) 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 i67B8Fo29601 for ; Wed, 7 Jul 2004 12:08:16 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Jul 2004 12:08:15 +0100 Message-ID: <5149A4FBB886D511AF7100508BF93A1806B652BE@znsgy0k4.europe.nortel.com> From: "Javier Gonzalez Gallego" To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter-nasreq-15. question for clarification Date: Wed, 7 Jul 2004 12:08:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46412.AF4AC69E" 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_01C46412.AF4AC69E Content-Type: text/plain Hi all Looking at the nasreq draft, I can see that in the message format of AAA, there's no *[Failed-AVP] Is this correct? If for example in the AAR we have a required AVP missing, in the AAA answer this error should be reported with a Failed-AVP indicating the missing AVP. Thanks in advance for the clarifications ------_=_NextPart_001_01C46412.AF4AC69E Content-Type: text/html Content-Transfer-Encoding: quoted-printable Diameter-nasreq-15. question for clarification

Hi all
Looking at the nasreq draft, I can see that in the = message format of AAA, there's no *[Failed-AVP]
Is this correct?
If for example in the AAR we have a required AVP = missing, in the AAA answer this error should be reported with a = Failed-AVP indicating the missing AVP.

Thanks in advance for the clarifications

------_=_NextPart_001_01C46412.AF4AC69E-- From owner-aaa-wg@merit.edu Wed Jul 7 07:21: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 HAA11789 for ; Wed, 7 Jul 2004 07:21:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 15C2391250; Wed, 7 Jul 2004 07:21:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D955A91251; Wed, 7 Jul 2004 07:21:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A2EE091250 for ; Wed, 7 Jul 2004 07:21:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 876095A1E7; Wed, 7 Jul 2004 07:21:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 977415A1D2 for ; Wed, 7 Jul 2004 07:21:35 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i67BLO214277; Wed, 7 Jul 2004 14:21:24 +0300 (EET DST) X-Scanned: Wed, 7 Jul 2004 14:20:31 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i67BKVml016589; Wed, 7 Jul 2004 14:20:31 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00x3KWtd; Wed, 07 Jul 2004 14:20:29 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i67BKOH25495; Wed, 7 Jul 2004 14:20:24 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jul 2004 14:20:14 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage Date: Wed, 7 Jul 2004 14:20:14 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C130@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 464: Application-Id Usage Thread-Index: AcRjaYswMCd+ELYbSD+t4tqvhAho7QAqVzcA From: To: , X-OriginalArrivalTime: 07 Jul 2004 11:20:14.0272 (UTC) FILETIME=[5FCEAC00:01C46414] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Chris, This brings us back to the topic what an "application" actually is. It could mean e.g. a software module in a Diameter implementation, or a (set of) specifications=20 that document how Diameter is extended for some particular=20 purpose (such as SIP or Mobile IPv4). My reading of RFC3588 supports the latter interpretation (but I guess there is some room for disagreement and=20 other interpretations as well...). With this interpretation, it does not make sense to say=20 that you send a message _to_ an application; you send=20 a message that is defined in some application. So an=20 Abort-Session-Request referring to a DCC session would use application identifier 0.=20 Of course, there might be a DCC-specific software module that actually handles the message, but I think we should=20 use some other word than "application" for that. Best regards, Pasi -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com] Sent: Tuesday, July 06, 2004 5:56 PM To: 'Bernard Aboba'; aaa-wg@merit.edu Cc: Eronen Pasi (Nokia-NRC/Helsinki) Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage Hi Bernard, All,=20 I still have a problem with the use of an application-id of a different application in a command. Firstly, there is section 3 of RFC 3588. It states that the application-id in the header of any command MUST be the same as the application id in any relevant AVPs. Secondly, what if a Diameter peer does not want to use a base application but only wants to use some other application. It wants to advertise support for application X but does not want to be used for a base application (regardless of it's ability to support the base applications). For example, an operator may want to disable a node's Diameter Accounting application while maintaining some other application(s). The Diameter protocol should not force the node to advertise support for an application that is not enabled. Regardless of which spec a command is defined, a command is only relevant to the application to which the command is destined. E.g. if a management node wants to Abort a DCCA session on the DCCA client, it only makes sense to send the ASR to the DCC client application - since it is the DCC client application which is handling the session. Cheers,=20 Chris=20 Tel: +1 613 763 8031=20 ESN: 393 8031=20 From owner-aaa-wg@merit.edu Wed Jul 7 07:40: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 HAA12547 for ; Wed, 7 Jul 2004 07:40:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5D4E091252; Wed, 7 Jul 2004 07:40:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2EEA691291; Wed, 7 Jul 2004 07:40:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0492991252 for ; Wed, 7 Jul 2004 07:40:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DD6A65A1E3; Wed, 7 Jul 2004 07:40:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id D1F425A1DE for ; Wed, 7 Jul 2004 07:40:13 -0400 (EDT) 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 i67BeCJ29636; Wed, 7 Jul 2004 14:40:12 +0300 (EET DST) X-Scanned: Wed, 7 Jul 2004 14:39:23 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i67BdNbE001995; Wed, 7 Jul 2004 14:39:23 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00NAU2qv; Wed, 07 Jul 2004 14:39:22 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i67BdGH21674; Wed, 7 Jul 2004 14:39:16 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jul 2004 14:39:14 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage Date: Wed, 7 Jul 2004 14:39:14 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D0298AA82@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 464: Application-Id Usage Thread-Index: AcRjaYswMCd+ELYbSD+t4tqvhAho7QAqVzcAAADtV7A= From: To: , Cc: X-OriginalArrivalTime: 07 Jul 2004 11:39:14.0998 (UTC) FILETIME=[07BBA560:01C46417] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Pasi Eronen writes >=20 > This brings us back to the topic what an "application" > actually is. It could mean e.g. a software module in > a Diameter implementation, or a (set of) specifications=20 > that document how Diameter is extended for some particular=20 > purpose (such as SIP or Mobile IPv4). >=20 > My reading of RFC3588 supports the latter interpretation > (but I guess there is some room for disagreement and=20 > other interpretations as well...). >=20 I have the same understanding. > With this interpretation, it does not make sense to say=20 > that you send a message _to_ an application; you send=20 > a message that is defined in some application. So an=20 > Abort-Session-Request referring to a DCC session > would use application identifier 0.=20 >=20 I think it makes sense. Marco=20 From owner-aaa-wg@merit.edu Wed Jul 7 08:01: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 IAA13547 for ; Wed, 7 Jul 2004 08:01:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9B66591291; Wed, 7 Jul 2004 08:00:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6AD8D912A5; Wed, 7 Jul 2004 08:00:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0FEF991291 for ; Wed, 7 Jul 2004 08:00:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6A5525A176; Wed, 7 Jul 2004 08:00:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 07C675A1D0 for ; Wed, 7 Jul 2004 08:00:39 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i67C0ZN06271 for ; Wed, 7 Jul 2004 15:00:35 +0300 (EET DST) X-Scanned: Wed, 7 Jul 2004 14:59:40 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i67BxeaN023236 for ; Wed, 7 Jul 2004 14:59:40 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 007sEtvh; Wed, 07 Jul 2004 14:59:40 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i67BxdH08488 for ; Wed, 7 Jul 2004 14:59:39 +0300 (EET DST) Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jul 2004 14:59:38 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage Date: Wed, 7 Jul 2004 14:59:39 +0300 Message-ID: <9B95641F3AE80F4C8CD5B288FE8C9631AAB000@esebe012.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 464: Application-Id Usage Thread-Index: AcRi9EdhKfS+wyOcTeC55wfV+JZgoABI/lYQ From: To: X-OriginalArrivalTime: 07 Jul 2004 11:59:38.0399 (UTC) FILETIME=[E0EFD2F0:01C46419] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, > The question is whether it should also advertise the=20 > application that it inherited command C1 from, even though it doesn't > support command C2. >=20 > If the application-Id in question is Diameter Base (Application-ID 0) > I think there is no issue, since this is mandatory-to-implement for = all > Diameter peers. >=20 > However, if we are talking about multiple inheritance (e.g. inheriting > commands from an Application-Id other than Base authentication and > accounting) I think we have a problem. Here's how I interpret RFC3588 regarding this: Application X defines commands: C1 and C2 Application Y defines command: C3 and also re-uses C1 First of all, if application Y re-uses C1 it must be stated in the specification of application Y. If a DiameterIdentity advertises support for application X, it must support C1 and C2. C1 is used with app-id X. If a DiameterIdentity advertises support for application Y, it must support C1 and C3. C1 is used with app-id Y. If a DiameterIdentity advertises support for application X and Y, it must support C1, C2, and C3. C1 can be used with app-id X and Y. BR, Mikko > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Bernard Aboba > Sent: 06 July, 2004 03:56 > To: aaa-wg@merit.edu > Cc: Eronen Pasi (Nokia-NRC/Helsinki) > Subject: [AAA-WG]: Issue 464: Application-Id Usage >=20 >=20 > Pasi Eronen noted: >=20 > >This seems to imply that a new application can't borrow only > >a subset of mandatory commands from an existing application..? > > > >Otherwise we could get a conflict. Let's assume that application > >X has commands C1 and C2, and application Y defines a new > >command C3 and borrows C1 from X (without any new mandatory > >AVPs). >=20 > >It seems that a Diameter server implementing only Y can't > >advertise support for X, since it does not implement C2. > >But using application identifier of X for C1 is not allowed > >either, since this seems to contradict the text saying that > >"When a request is routed, the target server MUST have > >advertised the Application Identifier (see Section 2.4) for > >the given message. >=20 > >Another related issue is whether two different applications > >could use the same AVP (in the same command and with the same > >application ID) for slightly different purposes. At least this > >happens all the time with RADIUS, but perhaps the different uses > >can be distinguished even if the application ID is the same..." >=20 > If application Y defines a new command C3, then it needs to advertise > application Y, since otherwise it can't be guaranteed that=20 > Diameter peers > will select a path that will allow command C3 to be sent from Diameter > client to server. >=20 > The question is whether it should also advertise the=20 > application that it > inherited command C1 from, even though it doesn't support command C2. >=20 > If the application-Id in question is Diameter Base=20 > (Application-ID 0) I > think there is no issue, since this is mandatory-to-implement for all > Diameter peers. >=20 > However, if we are talking about multiple inheritance (e.g. inheriting > commands from an Application-Id other than Base authentication and > accounting) I think we have a problem. I'd interpret RFC=20 > 3588 as allowing > an out for this, since the number of round-trips is changed (e.g. the > common is disallowed altogether). >=20 > Does this make sense? >=20 > In this particular case, is there any issue with advertising=20 > Diameter Base > Common Messages as well as EAP? I think there isn't because=20 > EAP supports > all Base commands. However, there might be an issue with advertising > NASREQ where the NAS or server doesn't support PAP/CHAP (AAR/AAA). >=20 From owner-aaa-wg@merit.edu Wed Jul 7 08:21: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 IAA14555 for ; Wed, 7 Jul 2004 08:21:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 70DD4912A5; Wed, 7 Jul 2004 08:20:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 36137912B5; Wed, 7 Jul 2004 08:20:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A7510912A5 for ; Wed, 7 Jul 2004 08:20:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 93ADA5A20C; Wed, 7 Jul 2004 08:20:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id 9E2555A1E4 for ; Wed, 7 Jul 2004 08:20:54 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i67CKrPA016076 for ; Wed, 7 Jul 2004 14:20:53 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Jul 2004 14:20:53 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <32361337>; Wed, 7 Jul 2004 14:20:51 +0200 Message-ID: From: "Leena Mattila (TU/LMF)" To: "'Mark Watson'" , "'Mark Grayson (mgrayson)'" , "'marco.stura@nokia.com'" Cc: aaa-wg@merit.edu, "Glen Zorn (gwz)" , Claire Mousset Subject: FW: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Date: Wed, 7 Jul 2004 14:20:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 07 Jul 2004 12:20:53.0368 (UTC) FILETIME=[D8E0A780:01C4641C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Re-posting this because of mail delivery problems. Sorry if you receive = this twice. BR, Leena -----Original Message----- Hi, when the MSCC concept was introduced I always had the assumption that the services within the MSCC structure are=20 sub-ordinate to some higher level service, e.g. Network Access. Having said that, it's also true that what one can do with MSCC one = should be able=20 to do with several messages (that's where the MSCC issue initially started). However, I still believe that those several=20 messages are inter-related (otherwise you wouldn't group them=20 in the same message, right?), and thus the exact formulation=20 would be 'what one can do with MSCC one should be able to do=20 with sub-sessions'. Hence the analogy between the two approaches is: - when using the MSCC the Service-ID on command level is the=20 main service, e.g. Network access, and the Service-Ids within=20 the MSCC then identify the sub-services within the main service - when using sub-sessions the Service-ID in 'main' session is=20 the main service and the Service-Ids in sub-sessions (on=20 command level) are the sub-services. If there is no common factor between the Service-IDs one has=20 grouped within one MSCC, then I think they should not be=20 grouped together at all, they are then clearly not sub-ordinate services (e.g. not carried within the same bearer) and should=20 treat them as such - optimizing signaling=20 should not be the only justification for doing the grouping.=20 And when there is a common factor, that factor should become=20 the Service-ID on command level. Regarding the question (3): I'll put it the other way around:=20 At the moment it's not possible to have rating groups on=20 command level but do you see a need for it?=20 Regards, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf = Of Mark Watson Sent: 6. hein=E4kuuta 2004 19:21 To: 'Mark Grayson (mgrayson)'; 'marco.stura@nokia.com' Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Claire Mousset Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Hi Mark, Note sure what you mean by a 'rating-root', but it is quite clear (e.g. = in the diagrams in 5.1.1) that 'services' are sub-ordinate to = Rating-Groups. Since everything in a Rating-Group is rated the same way = then certainly you cannot have things within a service which are rated = differently. That is, services are the finest level of granularity that = can be separately charged. The point of MSCC was to do in one message what could otherwise be done = with several messages and only command level values - so I would expect = the things appearing in the MSCC to have the same semantics as things = appearing at command level & for the two to be mutually exclusive - = hence Question 1 below. To answre my question (2) below for myself, we don't need multiple = instances of the same service within a single sub-session. In 3GPP, I = think we may have a requirement for dynamically povisioned services, = but the dynamic provisioning of these to DCC client & server is out of = scope here & so there should be no problem. ...Mark -----Original Message----- From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com]=20 Sent: 06 July 2004 16:44 To: Watson, Mark [MOP:EP10:EXCH]; marco.stura@nokia.com Cc: aaa-wg@merit.edu; Glen Zorn (gwz); Mousset, Claire [ADC:8J70:EXCH] Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Mark, Marco I hadn't made the same assumption - but agree that there is ambiguity = here. I had asumed that when present on the command level, the service-ID = refers to the "rating-root" which then needs to be common between = client and serer.=20 Then the issue exists with re-introducing the service-ID at the MSCC = level, now possibly below the sub-session-ID which I think is the cause = of the issue. IMO these AVPs at the MSCC level should be subordinate to = the service-ID on the command level. Cheers, Mark From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf = Of Mark Watson Sent: 06 July 2004 11:08 To: 'marco.stura@nokia.com' Cc: 'aaa-wg@merit.edu'; Glen Zorn (gwz); Claire Mousset Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Hi Marco,=20 Some quick questions for clarification on this one...=20 1) If the client wants to request quotas for multiple services using = the Multiple-Services-Credit-Control AVP then what should it put in the = mandatory command level Service-Identifier AVP ? 2) Service-Identifier is finer granlarity than Rating-Group - that is = several services with unique Service-Identifiers are grouped within a = single Rating-Group. So a 'service' identified by a Service-Identifier = is basically the finest granularity thing that can be separately = charged. But then the definition of the Service Identifier AVP speaks of = statically configured or standardised values. To be consistent with the = above it would need to be a format or pattern than was = configured/standardised - e.g. if it's voice calls that you are = charging for then Service Identifies like 'voice001@blah.org', = 'voice002@blah.org' would be needed to distinguish between multiple = concurrent voice calls. Right ?=20 3) It isn't possible to request credit for a Rating-Group except by = using the Multiple-Services-Credit-Control AVP, right ? Regards...Mark=20 -----Original Message-----=20 From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: 05 July 2004 09:09=20 To: gwz@cisco.com=20 Cc: aaa-wg@merit.edu=20 Subject: [AAA-WG]: RE:=20 Glen,=20 the Service-Id is only included in CCR message (at command level) to = indicate=20 to the server for what specific service the request is being issued. = The server checks first the Service-Id AVP and, if it doesn't recognize = the value of this AVP, it rejects the request without any further = processing (e.g. rating or what so ever). If the server recognizes the = value of the Service-Id AVP, it continues the processing and authorizes = the credit if possible (i.e. if there is enough credit in the user's = account). =20 The section 4.1 has been restructured on request of IESG review as = follow, the inclusion of the Service-Id in CCR is mandatory. Whenever the IESG and the ADs will agree that their comments have been = properly addressed, the draft 06 will be carried out and made = available. Regards=20 Marco=20 4.1 Service-Specific Rating Input and Interoperability=20 =20 The Diameter Credit-Control Application defines the framework for = credit=20 control; it provides generic credit control mechanisms supporting = multiple=20 service applications. The Credit Control Application, therefore, = does not=20 define AVPs that could be used as input in the rating process. = Listing the=20 possible services that could use this Diameter application is seen = as out=20 of scope for this generic mechanism as well. =20 =20 Furthermore, it is reasonable to expect that there will exist a = service=20 level agreement between providers of the credit-control client and = the=20 credit-control server covering the charging, services offered, = roaming=20 agreements, agreed rating input (i.e. AVPs), etc.=20 Therefore, it is assumed that a Diameter credit control server will=20 provide service only for Diameter credit-control clients that have = agreed=20 beforehand the content of credit control messages. Protocol wise, it = is=20 naturally possible that any arbitrary Diameter credit-control client = can=20 interchange credit control messages with any Diameter credit control = server, but with a higher likelihood that unsupported services/AVPs = could=20 be present in the credit-control message causing the server to = reject the=20 request with an appropriate result-code.=20 =20 4.1.1 Specifying Rating Input AVPs=20 =20 There are two ways for providing rating input to the credit control=20 server, either by using AVPs or by including them in the Service-=20 Parameter-Info AVP. The general principles for sending rating paramet= ers=20 are:=20 =20 1a. The service SHOULD re-use existing AVPs, if the service can use = AVPs=20 defined in existing Diameter applications (e.g. NASREQ for = network=20 access services). Re-use of existing AVPs is strongly = recommended in=20 [DIAMBASE].=20 For AVPs of type Enumerated the service may require a new value = to be=20 defined. Allocation of new AVP values is done as specified in=20 [DIAMBASE], section 1.2.=20 =20 1b. New AVPs can be defined if the existing AVPs do not provide = sufficient=20 rating information. In such a case, the procedures defined in=20 [DIAMBASE] for creating new AVPs MUST be followed.=20 =20 1c. For services specific only to one vendor's implementation, a = Vendor-=20 Specific AVP code for Private use can be used. Where a = Vendor-Specific=20 AVP is implemented by more than one vendor, allocation of global = AVPs=20 are encouraged instead, refer to [DIAMBASE].=20 =20 2. The Service-Parameter-Info AVP MAY be used as a container to pass = legacy rating information in its original encoded form (e.g. = ASN.1=20 BER). This method can be used to avoid unnecessary data format=20 conversions from an existing format to an AVP format. In that = case the=20 rating input is embedded in the Service-Parameter-Info AVP as = defined=20 in section 8.42.=20 =20 New service applications SHOULD favor the use of explicitly defined = AVPs=20 as described in items 1a and 1b, to simplify interoperability. =20 =20 4.1.2 Application Support=20 =20 Since the Application-Id of the Diameter Credit Control Application = does=20 not uniquely identify the service being monitored, an additional = mechanism=20 is needed. The service application MUST be identified using the = Service-=20 Identifier AVP at command level. A server receiving a request for a=20 service application it does not support will reject the request as = defined=20 in sub-section 4.1.4. The Service-Identifier AVP MUST be a unique=20 identifier for a given service as defined in section 8.28. =20 =20 Thus, the combination of the Diameter Credit Control Application-Id = and=20 the Service-Identifier AVP in the Credit-Control-Request command = uniquely=20 defines the service within the context of the Diameter Credit = Control, and=20 hence provides interoperability between Diameter credit control = clients=20 and server.=20 =20 With this mechanism it is possible to cover additional service = specific=20 requirements as needed in other documents. However, introducing new = credit=20 control mechanisms to the framework defined in this specification, = require=20 definition of a new version of the Diameter Credit Control = Application and=20 corresponding Application Identifier.=20 =20 4.1.3 Service-Specific Documentation=20 =20 The service specific rating input AVPs, the contents of the Service- = Parameter-Info AVP or Service-Identifier AVP are not within the = scope of=20 this document. To facilitate interoperability, it is RECOMMENDED = that the=20 rating input and the values of the service identifiers are = coordinated via=20 an informational RFC or other permanent and readily available = reference=20 such as the specification of another cooperative standardization = body=20 (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services = may=20 be deployed that are subject to agreements between providers of the = credit=20 control server and client, in this case vendor specific AVPs can be = used. =20 =20 This specification, together with the above service specific = documents,=20 governs the credit control message. The rule is that service = specific=20 documents define what existing AVPs or new AVPs are used as input to = the=20 rating process (i.e. they do not define new credit control = applications),=20 and thus need to be included in the Credit-Control-Request command = by a=20 Diameter Credit Control Client supporting a given service as *[AVP]. = Should Service-Parameter-Info be used, then the service specific = document=20 MUST specify the exact content of this grouped AVP.=20 =20 4.1.4 Handling of Unsupported/Incorrect Rating Input =20 =20 Diameter credit control implementations are required to support the=20 Mandatory rating AVPs defined in service specific documentation of = the=20 services they support according to the 'M' bit rules in [DIAMBASE]. = =20 In case a rating input required for the rating process is incorrect = in the=20 Credit control request, or the credit control server does not = support the=20 requested service (identified by the Service-Idntifier AVP at = command=20 level), the Credit control answer MUST contain error code=20 DIAMETER_RATING_FAILED. A CCR message with this error MUST contain = one or=20 more Failed-AVP AVPs containing the missing and/or unsupported AVPs = that=20 caused the failure. A Diameter credit control client receiving error = code=20 DIAMETER_RATING_FAILED in answer to a request MUST NOT send such = similar=20 requests in the future.=20 =20 4.1.5 RADIUS Vendor-Specific Rating Attributes=20 =20 When service specific documents include RADIUS vendor specific = attributes=20 that could be used as input in the rating process, the rules = described in=20 [NASREQ] for formatting the Diameter AVP MUST be followed. For = example,=20 the AVP code used is the vendor attribute type code, the = Vendor-Specific=20 flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA = Vendor=20 identification value. The Diameter AVP data field contains only the=20 attribute value of the RADIUS attribute.=20 > -----Original Message-----=20 > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of=20 > ext Glen Zorn=20 > Sent: 02 July, 2004 20:27=20 > To: aaa-wg@merit.edu=20 > Subject:=20 >=20 >=20 > Description of issue: No guarantee of interoperability=20 > between CCA implementations=20 > Submitter name: Glen Zorn=20 > Submitter email address: gwz@cisco.com=20 > Date first submitted: 2 July 2004=20 > Document: dcca=20 > Comment type: T=20 > Priority: S=20 > Section: 4.1=20 > Rationale/Explanation of issue:=20 > In order to interoperate, Diameter peers implementing the=20 > Diameter Credit Control Application must agree upon both the=20 > application and the service (specified in the=20 > Service-Identifier AVP). However, the inclusion of the=20 > Service-Identifier in the CCR and CCA messages is optional.=20 >=20 > Lengthy description of problem:=20 > Section 4.1, para. 6 states "it is the combination of support=20 > of the Diameter Credit Control Application and the service=20 > defined in the Service-Identifier AVP, which defines=20 > interoperability between any given credit control client and=20 > server." However, the inclusion of the Service-Identifier in=20 > the CCR and CCA messages is optional. This gives rise to a=20 > situation where two peers implementing the same application=20 > may not interoperate because they do not implement the same=20 > "service", and further, refuse to clearly communicate that fact.=20 >=20 > Requested change:=20 > Change section 4.1, paragraph 5 from=20 >=20 > This specification, together with service specific documents, is=20 > governing the credit control message. The rule is that service=20 > specific documents only define what existing AVPs or new AVPs are=20 > used as input to the rating process (i.e. they do not define new=20 > credit control applications), and thus need to be included in the=20 > Credit-Control-Request command by a Diameter Credit Control Client = > supporting a given service as *[AVP]. In order to define new AVPs, = > service specific documents MUST follow the practices defined in=20 > [DIAMBASE]. The service SHOULD be identified using the Service-=20 > Identifier AVP. The Service-Identifier AVP MUST be a unique=20 > identifier for a given service as defined in section 8.28.=20 >=20 > to=20 >=20 > This specification, together with service specific documents, is=20 > governing the credit control message. The rule is that service=20 > specific documents only define what existing AVPs or new AVPs are=20 > used as input to the rating process (i.e. they do not define new=20 > credit control applications), and thus need to be included in the=20 > Credit-Control-Request command by a Diameter Credit Control Client = > supporting a given service as *[AVP]. In order to define new AVPs, = > service specific documents MUST follow the practices defined in=20 > [DIAMBASE]. The service MUST be identified using the Service-=20 > Identifier AVP. The Service-Identifier AVP MUST be a unique=20 > identifier for a given service as defined in section 8.28.=20 >=20 > ~gwz=20 >=20 > "They that can give up essential liberty to obtain a little=20 > temporary safety deserve neither..."=20 > -- Benjamin Franklin, 1759=20 >=20 >=20 > "It is forbidden to kill; therefore all murderers are=20 > punished unless they kill in large numbers and to the sound=20 > of trumpets."=20 > -- Voltaire=20 >=20 >=20 From owner-aaa-wg@merit.edu Wed Jul 7 08:29: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 IAA14899 for ; Wed, 7 Jul 2004 08:29:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 16BF1912B5; Wed, 7 Jul 2004 08:29:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C5F22912B6; Wed, 7 Jul 2004 08:29:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A2FFC912B5 for ; Wed, 7 Jul 2004 08:29:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 86AC75A1B0; Wed, 7 Jul 2004 08:29:30 -0400 (EDT) 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 EC1505A135 for ; Wed, 7 Jul 2004 08:29:28 -0400 (EDT) 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 i67CTCo13233; Wed, 7 Jul 2004 13:29:12 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Jul 2004 13:29:12 +0100 Message-ID: <588B15E2E2B1D41180B800508BF934F20F557486@bmdhd6.europe.nortel.com> From: "Mark Watson" To: "'Leena Mattila (TU/LMF)'" , "'Mark Grayson (mgrayson)'" , "'marco.stura@nokia.com'" Cc: "'aaa-wg@merit.edu'" , "'Glen Zorn (gwz)'" , "Claire Mousset" Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Date: Wed, 7 Jul 2004 13:29:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4641E.00CE7B68" 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_01C4641E.00CE7B68 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Leena, You wrote: "- when using the MSCC the Service-ID on command level is the=20 main service, e.g. Network access, and the Service-Ids within=20 the MSCC then identify the sub-services within the main service" This sounds very reasonable to me, but it is not what the specification seems to imply. There is no concept in the spec of 'services' being 'sub-ordinate' to other 'services'. Furthermore, the fact that a = 'service' is sub-ordinate to Rating-Group implies that everything within a = service has to be rated the same. So then even if there were sub-services within a = 'main service' they would all have to be within the same Rating-Group! But if people feel it's clear that there can be such a thing as a 'main service' which is not part of any Rating Group and which has = sub-services, then that seems fine to me. As for (3), it doesn't seem a big deal, but does seem arbitrary - if I = want to request a quota for a single Rating-Group (which is probably the = most common case in 3GPP anyway) I need to use MSCC. ...Mark -----Original Message----- From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com]=20 Sent: 07 July 2004 12:00 To: Watson, Mark [MOP:EP10:EXCH]; 'Mark Grayson (mgrayson)'; 'marco.stura@nokia.com' Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Mousset, Claire = [ADC:8J70:EXCH] Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Hi, when the MSCC concept was introduced I always had the assumption that = the services within the MSCC structure are=20 sub-ordinate to some higher level service, e.g. Network Access. Having = said that, it's also true that what one can do with MSCC one should be able=20 to do with several messages (that's where the MSCC issue initially = started). However, I still believe that those several=20 messages are inter-related (otherwise you wouldn't group them=20 in the same message, right?), and thus the exact formulation=20 would be 'what one can do with MSCC one should be able to do=20 with sub-sessions'. Hence the analogy between the two approaches is: - when using the MSCC the Service-ID on command level is the=20 main service, e.g. Network access, and the Service-Ids within=20 the MSCC then identify the sub-services within the main service - when using sub-sessions the Service-ID in 'main' session is=20 the main service and the Service-Ids in sub-sessions (on=20 command level) are the sub-services. If there is no common factor between the Service-IDs one has=20 grouped within one MSCC, then I think they should not be=20 grouped together at all, they are then clearly not sub-ordinate = services (e.g. not carried within the same bearer) and should=20 treat them as such - optimizing signaling=20 should not be the only justification for doing the grouping.=20 And when there is a common factor, that factor should become=20 the Service-ID on command level. Regarding the question (3): I'll put it the other way around:=20 At the moment it's not possible to have rating groups on=20 command level but do you see a need for it?=20 Regards, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf = Of Mark Watson Sent: 6. hein=E4kuuta 2004 19:21 To: 'Mark Grayson (mgrayson)'; 'marco.stura@nokia.com' Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Claire Mousset Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Hi Mark, Note sure what you mean by a 'rating-root', but it is quite clear (e.g. = in the diagrams in 5.1.1) that 'services' are sub-ordinate to = Rating-Groups. Since everything in a Rating-Group is rated the same way then certainly = you cannot have things within a service which are rated differently. That = is, services are the finest level of granularity that can be separately = charged. The point of MSCC was to do in one message what could otherwise be done = with several messages and only command level values - so I would expect the things appearing in the MSCC to have the same semantics as things = appearing at command level & for the two to be mutually exclusive - hence = Question 1 below. To answre my question (2) below for myself, we don't need multiple = instances of the same service within a single sub-session. In 3GPP, I think we = may have a requirement for dynamically povisioned services, but the dynamic provisioning of these to DCC client & server is out of scope here & so = there should be no problem. ...Mark -----Original Message----- From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com]=20 Sent: 06 July 2004 16:44 To: Watson, Mark [MOP:EP10:EXCH]; marco.stura@nokia.com Cc: aaa-wg@merit.edu; Glen Zorn (gwz); Mousset, Claire [ADC:8J70:EXCH] Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Mark, Marco I hadn't made the same assumption - but agree that there is ambiguity = here. I had asumed that when present on the command level, the service-ID = refers to the "rating-root" which then needs to be common between client and = serer. Then the issue exists with re-introducing the service-ID at the MSCC = level, now possibly below the sub-session-ID which I think is the cause of the issue. IMO these AVPs at the MSCC level should be subordinate to the service-ID on the command level. Cheers, Mark From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf = Of Mark Watson Sent: 06 July 2004 11:08 To: 'marco.stura@nokia.com' Cc: 'aaa-wg@merit.edu'; Glen Zorn (gwz); Claire Mousset Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Hi Marco,=20 Some quick questions for clarification on this one...=20 1) If the client wants to request quotas for multiple services using = the Multiple-Services-Credit-Control AVP then what should it put in the mandatory command level Service-Identifier AVP ? 2) Service-Identifier is finer granlarity than Rating-Group - that is several services with unique Service-Identifiers are grouped within a = single Rating-Group. So a 'service' identified by a Service-Identifier is = basically the finest granularity thing that can be separately charged. But then = the definition of the Service Identifier AVP speaks of statically = configured or standardised values. To be consistent with the above it would need to = be a format or pattern than was configured/standardised - e.g. if it's voice calls that you are charging for then Service Identifies like 'voice001@blah.org', 'voice002@blah.org' would be needed to distinguish between multiple concurrent voice calls. Right ?=20 3) It isn't possible to request credit for a Rating-Group except by = using the Multiple-Services-Credit-Control AVP, right ? Regards...Mark=20 -----Original Message-----=20 From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: 05 July 2004 09:09=20 To: gwz@cisco.com=20 Cc: aaa-wg@merit.edu=20 Subject: [AAA-WG]: RE:=20 Glen,=20 the Service-Id is only included in CCR message (at command level) to indicate=20 to the server for what specific service the request is being issued. = The server checks first the Service-Id AVP and, if it doesn't recognize the value of this AVP, it rejects the request without any further = processing (e.g. rating or what so ever). If the server recognizes the value of = the Service-Id AVP, it continues the processing and authorizes the credit = if possible (i.e. if there is enough credit in the user's account). =20 The section 4.1 has been restructured on request of IESG review as = follow, the inclusion of the Service-Id in CCR is mandatory. Whenever the IESG = and the ADs will agree that their comments have been properly addressed, = the draft 06 will be carried out and made available. Regards=20 Marco=20 4.1 Service-Specific Rating Input and Interoperability=20 =20 The Diameter Credit-Control Application defines the framework for = credit=20 control; it provides generic credit control mechanisms supporting multiple=20 service applications. The Credit Control Application, therefore, = does not define AVPs that could be used as input in the rating process. = Listing the=20 possible services that could use this Diameter application is seen = as out of scope for this generic mechanism as well. =20 =20 Furthermore, it is reasonable to expect that there will exist a = service=20 level agreement between providers of the credit-control client and = the=20 credit-control server covering the charging, services offered, = roaming=20 agreements, agreed rating input (i.e. AVPs), etc.=20 Therefore, it is assumed that a Diameter credit control server will=20 provide service only for Diameter credit-control clients that have = agreed beforehand the content of credit control messages. Protocol wise, it = is=20 naturally possible that any arbitrary Diameter credit-control client = can=20 interchange credit control messages with any Diameter credit control = server, but with a higher likelihood that unsupported services/AVPs = could be present in the credit-control message causing the server to = reject the request with an appropriate result-code.=20 =20 4.1.1 Specifying Rating Input AVPs=20 =20 There are two ways for providing rating input to the credit control=20 server, either by using AVPs or by including them in the Service-=20 Parameter-Info AVP. The general principles for sending rating = parameters=20 are:=20 =20 1a. The service SHOULD re-use existing AVPs, if the service can use = AVPs=20 defined in existing Diameter applications (e.g. NASREQ for = network=20 access services). Re-use of existing AVPs is strongly = recommended in=20 [DIAMBASE].=20 For AVPs of type Enumerated the service may require a new value = to be defined. Allocation of new AVP values is done as specified in=20 [DIAMBASE], section 1.2.=20 =20 1b. New AVPs can be defined if the existing AVPs do not provide sufficient=20 rating information. In such a case, the procedures defined in=20 [DIAMBASE] for creating new AVPs MUST be followed.=20 =20 1c. For services specific only to one vendor's implementation, a = Vendor-=20 Specific AVP code for Private use can be used. Where a Vendor-Specific=20 AVP is implemented by more than one vendor, allocation of global = AVPs are encouraged instead, refer to [DIAMBASE].=20 =20 2. The Service-Parameter-Info AVP MAY be used as a container to pass = legacy rating information in its original encoded form (e.g. = ASN.1=20 BER). This method can be used to avoid unnecessary data format=20 conversions from an existing format to an AVP format. In that = case the rating input is embedded in the Service-Parameter-Info AVP as = defined=20 in section 8.42.=20 =20 New service applications SHOULD favor the use of explicitly defined = AVPs=20 as described in items 1a and 1b, to simplify interoperability. =20 =20 4.1.2 Application Support=20 =20 Since the Application-Id of the Diameter Credit Control Application = does=20 not uniquely identify the service being monitored, an additional mechanism=20 is needed. The service application MUST be identified using the = Service-=20 Identifier AVP at command level. A server receiving a request for a=20 service application it does not support will reject the request as defined=20 in sub-section 4.1.4. The Service-Identifier AVP MUST be a unique=20 identifier for a given service as defined in section 8.28. =20 =20 Thus, the combination of the Diameter Credit Control Application-Id = and=20 the Service-Identifier AVP in the Credit-Control-Request command = uniquely defines the service within the context of the Diameter Credit = Control, and=20 hence provides interoperability between Diameter credit control = clients=20 and server.=20 =20 With this mechanism it is possible to cover additional service = specific=20 requirements as needed in other documents. However, introducing new credit=20 control mechanisms to the framework defined in this specification, require=20 definition of a new version of the Diameter Credit Control = Application and=20 corresponding Application Identifier.=20 =20 4.1.3 Service-Specific Documentation=20 =20 The service specific rating input AVPs, the contents of the Service- = Parameter-Info AVP or Service-Identifier AVP are not within the = scope of=20 this document. To facilitate interoperability, it is RECOMMENDED = that the rating input and the values of the service identifiers are = coordinated via=20 an informational RFC or other permanent and readily available = reference=20 such as the specification of another cooperative standardization = body=20 (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services = may=20 be deployed that are subject to agreements between providers of the credit=20 control server and client, in this case vendor specific AVPs can be = used. =20 This specification, together with the above service specific = documents,=20 governs the credit control message. The rule is that service = specific=20 documents define what existing AVPs or new AVPs are used as input to = the=20 rating process (i.e. they do not define new credit control = applications), and thus need to be included in the Credit-Control-Request command = by a=20 Diameter Credit Control Client supporting a given service as *[AVP]. = Should Service-Parameter-Info be used, then the service specific = document MUST specify the exact content of this grouped AVP.=20 =20 4.1.4 Handling of Unsupported/Incorrect Rating Input =20 =20 Diameter credit control implementations are required to support the=20 Mandatory rating AVPs defined in service specific documentation of = the=20 services they support according to the 'M' bit rules in [DIAMBASE]. = =20 In case a rating input required for the rating process is incorrect = in the=20 Credit control request, or the credit control server does not = support the requested service (identified by the Service-Idntifier AVP at = command=20 level), the Credit control answer MUST contain error code=20 DIAMETER_RATING_FAILED. A CCR message with this error MUST contain = one or more Failed-AVP AVPs containing the missing and/or unsupported AVPs = that=20 caused the failure. A Diameter credit control client receiving error = code DIAMETER_RATING_FAILED in answer to a request MUST NOT send such = similar=20 requests in the future.=20 =20 4.1.5 RADIUS Vendor-Specific Rating Attributes=20 =20 When service specific documents include RADIUS vendor specific = attributes that could be used as input in the rating process, the rules = described in [NASREQ] for formatting the Diameter AVP MUST be followed. For = example,=20 the AVP code used is the vendor attribute type code, the = Vendor-Specific=20 flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA = Vendor=20 identification value. The Diameter AVP data field contains only the=20 attribute value of the RADIUS attribute.=20 > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of=20 > ext Glen Zorn=20 > Sent: 02 July, 2004 20:27=20 > To: aaa-wg@merit.edu=20 > Subject:=20 >=20 >=20 > Description of issue: No guarantee of interoperability > between CCA implementations=20 > Submitter name: Glen Zorn=20 > Submitter email address: gwz@cisco.com=20 > Date first submitted: 2 July 2004=20 > Document: dcca=20 > Comment type: T=20 > Priority: S=20 > Section: 4.1=20 > Rationale/Explanation of issue:=20 > In order to interoperate, Diameter peers implementing the=20 > Diameter Credit Control Application must agree upon both the=20 > application and the service (specified in the=20 > Service-Identifier AVP). However, the inclusion of the=20 > Service-Identifier in the CCR and CCA messages is optional.=20 >=20 > Lengthy description of problem: > Section 4.1, para. 6 states "it is the combination of support=20 > of the Diameter Credit Control Application and the service=20 > defined in the Service-Identifier AVP, which defines=20 > interoperability between any given credit control client and=20 > server." However, the inclusion of the Service-Identifier in=20 > the CCR and CCA messages is optional. This gives rise to a=20 > situation where two peers implementing the same application=20 > may not interoperate because they do not implement the same=20 > "service", and further, refuse to clearly communicate that fact.=20 >=20 > Requested change: > Change section 4.1, paragraph 5 from=20 >=20 > This specification, together with service specific documents, is=20 > governing the credit control message. The rule is that service=20 > specific documents only define what existing AVPs or new AVPs are=20 > used as input to the rating process (i.e. they do not define new=20 > credit control applications), and thus need to be included in the=20 > Credit-Control-Request command by a Diameter Credit Control Client = > supporting a given service as *[AVP]. In order to define new AVPs, = > service specific documents MUST follow the practices defined in=20 > [DIAMBASE]. The service SHOULD be identified using the Service-=20 > Identifier AVP. The Service-Identifier AVP MUST be a unique=20 > identifier for a given service as defined in section 8.28. >=20 > to >=20 > This specification, together with service specific documents, is=20 > governing the credit control message. The rule is that service=20 > specific documents only define what existing AVPs or new AVPs are=20 > used as input to the rating process (i.e. they do not define new=20 > credit control applications), and thus need to be included in the=20 > Credit-Control-Request command by a Diameter Credit Control Client = > supporting a given service as *[AVP]. In order to define new AVPs, = > service specific documents MUST follow the practices defined in=20 > [DIAMBASE]. The service MUST be identified using the Service-=20 > Identifier AVP. The Service-Identifier AVP MUST be a unique=20 > identifier for a given service as defined in section 8.28. >=20 > ~gwz >=20 > "They that can give up essential liberty to obtain a little > temporary safety deserve neither..."=20 > -- Benjamin Franklin, 1759=20 >=20 >=20 > "It is forbidden to kill; therefore all murderers are > punished unless they kill in large numbers and to the sound=20 > of trumpets."=20 > -- Voltaire=20 >=20 >=20 ------_=_NextPart_001_01C4641E.00CE7B68 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Hi Leena,

You wrote:

"- when using the MSCC the Service-ID on command = level is the
main service, e.g. Network access, and the = Service-Ids within
the MSCC then identify the sub-services within the = main service"

This sounds very reasonable to me, but it is not what = the specification seems to imply. There is no concept in the spec of = 'services' being 'sub-ordinate' to other 'services'. Furthermore, the = fact that a 'service' is sub-ordinate to Rating-Group implies that = everything within a service has to be rated the same. So then even if = there were sub-services within a 'main service' they would all have to = be within the same Rating-Group!

But if people feel it's clear that there can be such = a thing as a 'main service' which is not part of any Rating Group and = which has sub-services, then that seems fine to me.

As for (3), it doesn't seem a big deal, but does seem = arbitrary - if I want to request a quota for a single Rating-Group = (which is probably the most common case in 3GPP anyway) I need to use = MSCC.

...Mark

-----Original Message-----
From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson= .com]
Sent: 07 July 2004 12:00
To: Watson, Mark [MOP:EP10:EXCH]; 'Mark Grayson = (mgrayson)'; 'marco.stura@nokia.com'
Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Mousset, = Claire [ADC:8J70:EXCH]
Subject: RE: DCC Service-Identifier (was RE: = [AAA-WG]: RE: )


Hi,

when the MSCC concept was introduced I always had the = assumption that the services within the MSCC structure are
sub-ordinate to some higher level service, e.g. = Network Access. Having said that, it's also true that what one can do = with MSCC one should be able

to do with several messages (that's where the MSCC = issue initially started). However, I still believe that those several =

messages are inter-related (otherwise you wouldn't = group them
in the same message, right?), and thus the exact = formulation
would be 'what one can do with MSCC one should be = able to do
with sub-sessions'. Hence the analogy between the = two approaches is:
- when using the MSCC the Service-ID on command = level is the
main service, e.g. Network access, and the = Service-Ids within
the MSCC then identify the sub-services within the = main service
- when using sub-sessions the Service-ID in 'main' = session is
the main service and the Service-Ids in sub-sessions = (on
command level) are the sub-services.
If there is no common factor between the Service-IDs = one has
grouped within one MSCC, then I think they should = not be
grouped together at all, they are then clearly not = sub-ordinate services (e.g. not carried within the same bearer) and = should

treat them as such - optimizing signaling
should not be the only justification for doing the = grouping.
And when there is a common factor, that factor = should become
the Service-ID on command level.

Regarding the question (3): I'll put it the other way = around:
At the moment it's not possible to have rating = groups on
command level but do you see a need for it?

Regards,
Leena

-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu= ]On Behalf Of Mark Watson
Sent: 6. hein=E4kuuta 2004 19:21
To: 'Mark Grayson (mgrayson)'; = 'marco.stura@nokia.com'
Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Claire = Mousset
Subject: RE: DCC Service-Identifier (was RE: = [AAA-WG]: RE: )


Hi Mark,

Note sure what you mean by a 'rating-root', but it is = quite clear (e.g. in the diagrams in 5.1.1) that 'services' are = sub-ordinate to Rating-Groups. Since everything in a Rating-Group is = rated the same way then certainly you cannot have things within a = service which are rated differently. That is, services are the finest = level of granularity that can be separately charged.

The point of MSCC was to do in one message what could = otherwise be done with several messages and only command level values - = so I would expect the things appearing in the MSCC to have the same = semantics as things appearing at command level & for the two to be = mutually exclusive - hence Question 1 below.

To answre my question (2) below for myself, we don't = need multiple instances of the same service within a single = sub-session. In 3GPP, I think we may have a requirement for dynamically = povisioned services, but the dynamic provisioning of these to DCC = client & server is out of scope here & so there should be no = problem.

...Mark
-----Original Message-----
From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com] =
Sent: 06 July 2004 16:44
To: Watson, Mark [MOP:EP10:EXCH]; = marco.stura@nokia.com
Cc: aaa-wg@merit.edu; Glen Zorn (gwz); Mousset, = Claire [ADC:8J70:EXCH]
Subject: RE: DCC Service-Identifier (was RE: = [AAA-WG]: RE: )


Mark, Marco

I hadn't made the same assumption - but agree that = there is ambiguity here.

I had asumed that when present on the command level, = the service-ID refers to the "rating-root" which then needs = to be common between client and serer.

Then the issue exists with re-introducing the = service-ID at the MSCC level, now possibly below the sub-session-ID = which I think is the cause of the issue. IMO these AVPs at the MSCC = level should be subordinate to the service-ID on the command = level.

Cheers,
Mark




From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu= ] On Behalf Of Mark Watson
Sent: 06 July 2004 11:08
To: 'marco.stura@nokia.com'
Cc: 'aaa-wg@merit.edu'; Glen Zorn (gwz); Claire = Mousset
Subject: DCC Service-Identifier (was RE: [AAA-WG]: = RE: )


Hi Marco,
Some quick questions for clarification on this = one...
1) If the client wants to request quotas for = multiple services using the Multiple-Services-Credit-Control AVP then = what should it put in the mandatory command level Service-Identifier = AVP ?

2) Service-Identifier is finer granlarity than = Rating-Group - that is several services with unique Service-Identifiers = are grouped within a single Rating-Group. So a 'service' identified by = a Service-Identifier is basically the finest granularity thing that can = be separately charged. But then the definition of the Service = Identifier AVP speaks of statically configured or standardised values. = To be consistent with the above it would need to be a format or pattern = than was configured/standardised - e.g. if it's voice calls that you = are charging for then Service Identifies like 'voice001@blah.org', = 'voice002@blah.org' would be needed to distinguish between multiple = concurrent voice calls. Right ?

3) It isn't possible to request credit for a = Rating-Group except by using the Multiple-Services-Credit-Control AVP, = right ? Regards...Mark


-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: 05 July 2004 09:09
To: gwz@cisco.com
Cc: aaa-wg@merit.edu
Subject: [AAA-WG]: RE:


Glen,
the Service-Id is only included in CCR message (at = command level) to indicate
to the server for what specific service the request = is being issued. The server checks first the Service-Id AVP and, if it = doesn't recognize the value of this AVP, it rejects the request without = any further processing (e.g. rating or what so ever). If the server = recognizes the value of the Service-Id AVP, it continues the processing = and authorizes the credit if possible (i.e. if there is enough credit = in the user's account). 

The section 4.1 has been restructured on request of = IESG review as follow, the inclusion of the Service-Id in CCR is = mandatory. Whenever the IESG and the ADs will agree that their comments = have been properly addressed, the draft 06 will be carried out and made = available. Regards

Marco
4.1 Service-Specific Rating Input and = Interoperability
   
   The Diameter Credit-Control Application = defines the framework for credit
   control; it provides generic credit = control mechanisms supporting multiple
   service applications. The Credit = Control Application, therefore, does not
   define AVPs that could be used as input = in the rating process. Listing the
   possible services that could use this = Diameter application is seen as out
   of scope for this generic mechanism as = well. 
   
   Furthermore, it is reasonable to expect = that there will exist a service
   level agreement between providers of = the credit-control client and the
   credit-control server covering the = charging, services offered, roaming
   agreements, agreed rating input (i.e. = AVPs), etc.
   Therefore, it is assumed that a = Diameter credit control server will
   provide service only for Diameter = credit-control clients that have agreed
   beforehand the content of credit = control messages. Protocol wise, it is
   naturally possible that any arbitrary = Diameter credit-control client can
   interchange credit control messages = with any Diameter credit control
   server, but with a higher likelihood = that unsupported services/AVPs could
   be present in the credit-control = message causing the server to reject the
   request with an appropriate = result-code.
   
4.1.1 Specifying Rating Input AVPs
   
   There are two ways for providing rating = input to the credit control
   server, either by using AVPs or by = including them in the Service-
   Parameter-Info AVP. The general = principles for sending rating parameters
   are:
   
   1a. The service SHOULD re-use existing = AVPs, if the service can use AVPs
       defined in = existing Diameter applications (e.g. NASREQ for network
       access = services). Re-use of existing AVPs is strongly recommended in
       [DIAMBASE]. =
       For AVPs of = type Enumerated the service may require a new value to be
       defined. = Allocation of new AVP values is done as specified in
       [DIAMBASE], = section 1.2.
   
   1b. New AVPs can be defined if the = existing AVPs do not provide sufficient
       rating = information. In such a case, the procedures defined in
       [DIAMBASE] for = creating new AVPs MUST be followed.
   
   1c. For services specific only to one = vendor's implementation, a Vendor-
       Specific AVP = code for Private use can be used. Where a Vendor-Specific
       AVP is = implemented by more than one vendor, allocation of global AVPs
       are encouraged = instead, refer to [DIAMBASE].
   
   2. The Service-Parameter-Info AVP MAY = be used as a container to pass
      legacy rating = information in its original encoded form (e.g. ASN.1
      BER). This method can = be used to avoid unnecessary data format
      conversions from an = existing format to an AVP format. In that case the
      rating input is = embedded in the Service-Parameter-Info AVP as defined
      in section 8.42. =
   
   New service applications SHOULD favor = the use of explicitly defined AVPs
   as described in items 1a and 1b, to = simplify interoperability. 
   
4.1.2 Application Support
   
   Since the Application-Id of the Diameter= Credit Control Application does
   not uniquely identify the service being = monitored, an additional mechanism
   is needed. The service application MUST = be identified using the Service-
   Identifier AVP at command level. A = server receiving a request for a
   service application it does not support = will reject the request as defined
   in sub-section 4.1.4. The = Service-Identifier AVP MUST be a unique
   identifier for a given service as = defined in section 8.28. 
   
   Thus, the combination of the Diameter = Credit Control Application-Id and
   the Service-Identifier AVP in the = Credit-Control-Request command uniquely
   defines the service within the context = of the Diameter Credit Control, and
   hence provides interoperability between = Diameter credit control clients
   and server.
   
   With this mechanism it is possible to = cover additional service specific
   requirements as needed in other = documents. However, introducing new credit
   control mechanisms to the framework = defined in this specification, require
   definition of a new version of the = Diameter Credit Control Application and
   corresponding Application Identifier. =
   
4.1.3 Service-Specific Documentation
    
   The service specific rating input AVPs, = the contents of the Service-
   Parameter-Info AVP or = Service-Identifier AVP are not within the scope of
   this document. To facilitate = interoperability, it is RECOMMENDED that the
   rating input and the values of the = service identifiers are coordinated via
   an informational RFC or other permanent = and readily available reference
   such as the specification of another = cooperative standardization body
   (e.g. 3GPP, OMA and 3GPP2) SHOULD be = used. However, private services may
   be deployed that are subject to = agreements between providers of the credit
   control server and client, in this case = vendor specific AVPs can be used. 
       
   This specification, together with the = above service specific documents,
   governs the credit control message. The = rule is that service specific
   documents define what existing AVPs or = new AVPs are used as input to the
   rating process (i.e. they do not define = new credit control applications),
   and thus need to be included in the = Credit-Control-Request command by a
   Diameter Credit Control Client = supporting a given service as *[AVP].
   Should Service-Parameter-Info be used, = then the service specific document
   MUST specify the exact content of this = grouped AVP.
   
4.1.4 Handling of Unsupported/Incorrect Rating = Input 
   
   Diameter credit control implementations = are required to support the
   Mandatory rating AVPs defined in = service specific documentation of the
   services they support according to the = 'M' bit rules in [DIAMBASE]. 
       
   In case a rating input required for the = rating process is incorrect in the
   Credit control request, or the credit = control server does not support the
   requested service (identified by the = Service-Idntifier AVP at command
   level), the Credit control answer MUST = contain error code
   DIAMETER_RATING_FAILED. A CCR message = with this error MUST contain one or
   more Failed-AVP AVPs containing the = missing and/or unsupported AVPs that
   caused the failure. A Diameter credit = control client receiving error code
   DIAMETER_RATING_FAILED in answer to a = request MUST NOT send such similar
   requests in the future.
   
4.1.5 RADIUS Vendor-Specific Rating Attributes =
       
   When service specific documents include = RADIUS vendor specific attributes
   that could be used as input in the = rating process, the rules described in
   [NASREQ] for formatting the Diameter = AVP MUST be followed. For example,
   the AVP code used is the vendor = attribute type code, the Vendor-Specific
   flag MUST be set to 1 and the Vendor-ID = MUST be set to the IANA Vendor
   identification value. The Diameter AVP = data field contains only the
   attribute value of the RADIUS = attribute.
> -----Original Message-----
> From: owner-aaa-wg@merit.edu
> [mailto:owner-aaa-wg@merit.edu= ]On Behalf Of
> ext Glen Zorn
> Sent: 02 July, 2004 20:27
> To: aaa-wg@merit.edu
> Subject:
>
>
> Description of issue:  No guarantee of = interoperability
> between CCA implementations
> Submitter name: Glen Zorn
> Submitter email address: gwz@cisco.com
> Date first submitted: 2 July 2004
> Document: dcca
> Comment type: T
> Priority: S
> Section: 4.1
> Rationale/Explanation of issue:
> In order to interoperate, Diameter peers = implementing the
> Diameter Credit Control Application must agree = upon both the
> application and the service (specified in the =
> Service-Identifier AVP).  However, the = inclusion of the
> Service-Identifier in the CCR and CCA messages = is optional.
>
> Lengthy description of problem:
> Section 4.1, para. 6 states "it is the = combination of support
> of the Diameter Credit Control Application and = the service
> defined in the Service-Identifier AVP, which = defines
> interoperability between any given credit = control client and
> server."  However, the inclusion of = the Service-Identifier in
> the CCR and CCA messages is optional.  = This gives rise to a
> situation where two peers implementing the same = application
> may not interoperate because they do not = implement the same
> "service", and further, refuse to = clearly communicate that fact.
>
> Requested change:
> Change section 4.1, paragraph 5 from
>
>    This specification, together = with service specific documents, is
>    governing the credit control = message. The rule is that service
>    specific documents only = define what existing AVPs or new AVPs are
>    used as input to the rating = process (i.e. they do not define new
>    credit control applications), = and thus need to be included in the
>    Credit-Control-Request = command by a Diameter Credit Control Client
>    supporting a given service as = *[AVP]. In order to define new AVPs,
>    service specific documents = MUST follow the practices defined in
>    [DIAMBASE]. The service = SHOULD be identified using the Service-
>    Identifier AVP. The = Service-Identifier AVP MUST be a unique
>    identifier for a given = service as defined in section 8.28.
>
> to
>
>    This specification, together = with service specific documents, is
>    governing the credit control = message. The rule is that service
>    specific documents only = define what existing AVPs or new AVPs are
>    used as input to the rating = process (i.e. they do not define new
>    credit control applications), = and thus need to be included in the
>    Credit-Control-Request = command by a Diameter Credit Control Client
>    supporting a given service as = *[AVP]. In order to define new AVPs,
>    service specific documents = MUST follow the practices defined in
>    [DIAMBASE]. The service MUST = be identified using the Service-
>    Identifier AVP. The = Service-Identifier AVP MUST be a unique
>    identifier for a given = service as defined in section 8.28.
>
> ~gwz
>
> "They that can give up essential liberty = to obtain a little
> temporary safety deserve neither..." =
> -- Benjamin Franklin, 1759
>
>
> "It is forbidden to kill; therefore all = murderers are
> punished unless they kill in large numbers and = to the sound
> of trumpets."
> -- Voltaire
>
>

------_=_NextPart_001_01C4641E.00CE7B68-- From owner-aaa-wg@merit.edu Wed Jul 7 09:12: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 JAA17331 for ; Wed, 7 Jul 2004 09:12:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2B11B912B7; Wed, 7 Jul 2004 09:11:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA545912B8; Wed, 7 Jul 2004 09:11:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 584E4912B7 for ; Wed, 7 Jul 2004 09:11:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F024E5A1E3; Wed, 7 Jul 2004 09:11:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id AF0FB59F89 for ; Wed, 7 Jul 2004 09:11:39 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i67DBB603285; Wed, 7 Jul 2004 16:11:11 +0300 (EET DST) X-Scanned: Wed, 7 Jul 2004 16:10:26 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i67DAQD6004522; Wed, 7 Jul 2004 16:10:26 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00Ugs8A3; Wed, 07 Jul 2004 16:10:24 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i67DAOH02106; Wed, 7 Jul 2004 16:10:24 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jul 2004 16:10:12 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46423.BC5949D0" Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Date: Wed, 7 Jul 2004 16:10:11 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B05BC@esebe016.ntc.nokia.com> Thread-Topic: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Thread-Index: AcRkHiN7wjxiHPwXSvaTdmzkHVqRfgAAba3Q From: To: , , Cc: , , X-OriginalArrivalTime: 07 Jul 2004 13:10:12.0413 (UTC) FILETIME=[BC9B16D0:01C46423] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C46423.BC5949D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 some comment in line. =20 Marco -----Original Message----- From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 07 July, 2004 15:29 To: 'Leena Mattila (TU/LMF)'; 'Mark Grayson (mgrayson)'; Stura Marco = (Nokia-NET/Helsinki) Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Claire Mousset Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Hi Leena,=20 You wrote:=20 "- when using the MSCC the Service-ID on command level is the=20 main service, e.g. Network access, and the Service-Ids within=20 the MSCC then identify the sub-services within the main service"=20 This sounds very reasonable to me, but it is not what the specification = seems to imply. There is no concept in the spec of 'services' being = 'sub-ordinate' to other 'services'. Furthermore, the fact that a = 'service' is sub-ordinate to Rating-Group implies that everything within = a service has to be rated the same. So then even if there were = sub-services within a 'main service' they would all have to be within = the same Rating-Group!=20 But if people feel it's clear that there can be such a thing as a 'main = service' which is not part of any Rating Group and which has = sub-services, then that seems fine to me. =20 Mark, I guess you are referring to the picture in sect. 5.1.1. Right? If = so, this picture was intended to only describe the MSCC concept, what = Leena is mentioning is probably not visible in that picture. The main = service is a service of its own that represent for instance the bearer, = in which many other services may be carried and may have different = costs, and is not part of any RG. This 'main service' id also identifies = the service specific document with mandatory AVPs that need to be = supported, for instance the Flow bearer charging defined in 3GPP ideally = would have the 'main service' identifier something like = Flow-Bearer-Credit-Control@3gpp.org. Would you have good suggestion for better text in section 5.1.1 and = perhaps in the new 4.12 to remove any dubt?=20 As for (3), it doesn't seem a big deal, but does seem arbitrary - if I = want to request a quota for a single Rating-Group (which is probably the = most common case in 3GPP anyway) I need to use MSCC.=20 Right. ...Mark=20 -----Original Message-----=20 From: Leena Mattila (TU/LMF) [ mailto:leena.mattila@ericsson.com]=20 Sent: 07 July 2004 12:00=20 To: Watson, Mark [MOP:EP10:EXCH]; 'Mark Grayson (mgrayson)'; = 'marco.stura@nokia.com'=20 Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Mousset, Claire = [ADC:8J70:EXCH]=20 Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )=20 Hi,=20 when the MSCC concept was introduced I always had the assumption that = the services within the MSCC structure are=20 sub-ordinate to some higher level service, e.g. Network Access. Having = said that, it's also true that what one can do with MSCC one should be = able=20 to do with several messages (that's where the MSCC issue initially = started). However, I still believe that those several=20 messages are inter-related (otherwise you wouldn't group them=20 in the same message, right?), and thus the exact formulation=20 would be 'what one can do with MSCC one should be able to do=20 with sub-sessions'. Hence the analogy between the two approaches is:=20 - when using the MSCC the Service-ID on command level is the=20 main service, e.g. Network access, and the Service-Ids within=20 the MSCC then identify the sub-services within the main service=20 - when using sub-sessions the Service-ID in 'main' session is=20 the main service and the Service-Ids in sub-sessions (on=20 command level) are the sub-services.=20 If there is no common factor between the Service-IDs one has=20 grouped within one MSCC, then I think they should not be=20 grouped together at all, they are then clearly not sub-ordinate services = (e.g. not carried within the same bearer) and should=20 treat them as such - optimizing signaling=20 should not be the only justification for doing the grouping.=20 And when there is a common factor, that factor should become=20 the Service-ID on command level.=20 Regarding the question (3): I'll put it the other way around:=20 At the moment it's not possible to have rating groups on=20 command level but do you see a need for it?=20 Regards,=20 Leena=20 -----Original Message-----=20 From: owner-aaa-wg@merit.edu [ mailto:owner-aaa-wg@merit.edu]On Behalf = Of Mark Watson=20 Sent: 6. hein=E4kuuta 2004 19:21=20 To: 'Mark Grayson (mgrayson)'; 'marco.stura@nokia.com'=20 Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Claire Mousset=20 Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )=20 Hi Mark,=20 Note sure what you mean by a 'rating-root', but it is quite clear (e.g. = in the diagrams in 5.1.1) that 'services' are sub-ordinate to = Rating-Groups. Since everything in a Rating-Group is rated the same way = then certainly you cannot have things within a service which are rated = differently. That is, services are the finest level of granularity that = can be separately charged. The point of MSCC was to do in one message what could otherwise be done = with several messages and only command level values - so I would expect = the things appearing in the MSCC to have the same semantics as things = appearing at command level & for the two to be mutually exclusive - = hence Question 1 below. To answre my question (2) below for myself, we don't need multiple = instances of the same service within a single sub-session. In 3GPP, I = think we may have a requirement for dynamically povisioned services, but = the dynamic provisioning of these to DCC client & server is out of scope = here & so there should be no problem. ...Mark=20 -----Original Message-----=20 From: Mark Grayson (mgrayson) [ mailto:mgrayson@cisco.com]=20 Sent: 06 July 2004 16:44=20 To: Watson, Mark [MOP:EP10:EXCH]; marco.stura@nokia.com=20 Cc: aaa-wg@merit.edu; Glen Zorn (gwz); Mousset, Claire [ADC:8J70:EXCH]=20 Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )=20 Mark, Marco=20 I hadn't made the same assumption - but agree that there is ambiguity = here.=20 I had asumed that when present on the command level, the service-ID = refers to the "rating-root" which then needs to be common between client = and serer.=20 Then the issue exists with re-introducing the service-ID at the MSCC = level, now possibly below the sub-session-ID which I think is the cause = of the issue. IMO these AVPs at the MSCC level should be subordinate to = the service-ID on the command level. Cheers,=20 Mark=20 From: owner-aaa-wg@merit.edu [ mailto:owner-aaa-wg@merit.edu] On Behalf = Of Mark Watson=20 Sent: 06 July 2004 11:08=20 To: 'marco.stura@nokia.com'=20 Cc: 'aaa-wg@merit.edu'; Glen Zorn (gwz); Claire Mousset=20 Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: )=20 Hi Marco,=20 Some quick questions for clarification on this one...=20 1) If the client wants to request quotas for multiple services using the = Multiple-Services-Credit-Control AVP then what should it put in the = mandatory command level Service-Identifier AVP ? 2) Service-Identifier is finer granlarity than Rating-Group - that is = several services with unique Service-Identifiers are grouped within a = single Rating-Group. So a 'service' identified by a Service-Identifier = is basically the finest granularity thing that can be separately = charged. But then the definition of the Service Identifier AVP speaks of = statically configured or standardised values. To be consistent with the = above it would need to be a format or pattern than was = configured/standardised - e.g. if it's voice calls that you are charging = for then Service Identifies like 'voice001@blah.org', = 'voice002@blah.org' would be needed to distinguish between multiple = concurrent voice calls. Right ?=20 3) It isn't possible to request credit for a Rating-Group except by = using the Multiple-Services-Credit-Control AVP, right ? Regards...Mark=20 -----Original Message-----=20 From: marco.stura@nokia.com [ mailto:marco.stura@nokia.com]=20 Sent: 05 July 2004 09:09=20 To: gwz@cisco.com=20 Cc: aaa-wg@merit.edu=20 Subject: [AAA-WG]: RE:=20 Glen,=20 the Service-Id is only included in CCR message (at command level) to = indicate=20 to the server for what specific service the request is being issued. The = server checks first the Service-Id AVP and, if it doesn't recognize the = value of this AVP, it rejects the request without any further processing = (e.g. rating or what so ever). If the server recognizes the value of the = Service-Id AVP, it continues the processing and authorizes the credit if = possible (i.e. if there is enough credit in the user's account). =20 The section 4.1 has been restructured on request of IESG review as = follow, the inclusion of the Service-Id in CCR is mandatory. Whenever = the IESG and the ADs will agree that their comments have been properly = addressed, the draft 06 will be carried out and made available. Regards=20 Marco=20 4.1 Service-Specific Rating Input and Interoperability=20 =20 The Diameter Credit-Control Application defines the framework for = credit=20 control; it provides generic credit control mechanisms supporting = multiple=20 service applications. The Credit Control Application, therefore, does = not=20 define AVPs that could be used as input in the rating process. = Listing the=20 possible services that could use this Diameter application is seen as = out=20 of scope for this generic mechanism as well. =20 =20 Furthermore, it is reasonable to expect that there will exist a = service=20 level agreement between providers of the credit-control client and = the=20 credit-control server covering the charging, services offered, = roaming=20 agreements, agreed rating input (i.e. AVPs), etc.=20 Therefore, it is assumed that a Diameter credit control server will=20 provide service only for Diameter credit-control clients that have = agreed=20 beforehand the content of credit control messages. Protocol wise, it = is=20 naturally possible that any arbitrary Diameter credit-control client = can=20 interchange credit control messages with any Diameter credit control=20 server, but with a higher likelihood that unsupported services/AVPs = could=20 be present in the credit-control message causing the server to reject = the=20 request with an appropriate result-code.=20 =20 4.1.1 Specifying Rating Input AVPs=20 =20 There are two ways for providing rating input to the credit control=20 server, either by using AVPs or by including them in the Service-=20 Parameter-Info AVP. The general principles for sending rating = parameters=20 are:=20 =20 1a. The service SHOULD re-use existing AVPs, if the service can use = AVPs=20 defined in existing Diameter applications (e.g. NASREQ for = network=20 access services). Re-use of existing AVPs is strongly recommended = in=20 [DIAMBASE].=20 For AVPs of type Enumerated the service may require a new value = to be=20 defined. Allocation of new AVP values is done as specified in=20 [DIAMBASE], section 1.2.=20 =20 1b. New AVPs can be defined if the existing AVPs do not provide = sufficient=20 rating information. In such a case, the procedures defined in=20 [DIAMBASE] for creating new AVPs MUST be followed.=20 =20 1c. For services specific only to one vendor's implementation, a = Vendor-=20 Specific AVP code for Private use can be used. Where a = Vendor-Specific=20 AVP is implemented by more than one vendor, allocation of global = AVPs=20 are encouraged instead, refer to [DIAMBASE].=20 =20 2. The Service-Parameter-Info AVP MAY be used as a container to pass=20 legacy rating information in its original encoded form (e.g. ASN.1 = BER). This method can be used to avoid unnecessary data format=20 conversions from an existing format to an AVP format. In that case = the=20 rating input is embedded in the Service-Parameter-Info AVP as = defined=20 in section 8.42.=20 =20 New service applications SHOULD favor the use of explicitly defined = AVPs=20 as described in items 1a and 1b, to simplify interoperability. =20 =20 4.1.2 Application Support=20 =20 Since the Application-Id of the Diameter Credit Control Application = does=20 not uniquely identify the service being monitored, an additional = mechanism=20 is needed. The service application MUST be identified using the = Service-=20 Identifier AVP at command level. A server receiving a request for a=20 service application it does not support will reject the request as = defined=20 in sub-section 4.1.4. The Service-Identifier AVP MUST be a unique=20 identifier for a given service as defined in section 8.28. =20 =20 Thus, the combination of the Diameter Credit Control Application-Id = and=20 the Service-Identifier AVP in the Credit-Control-Request command = uniquely=20 defines the service within the context of the Diameter Credit = Control, and=20 hence provides interoperability between Diameter credit control = clients=20 and server.=20 =20 With this mechanism it is possible to cover additional service = specific=20 requirements as needed in other documents. However, introducing new = credit=20 control mechanisms to the framework defined in this specification, = require=20 definition of a new version of the Diameter Credit Control = Application and=20 corresponding Application Identifier.=20 =20 4.1.3 Service-Specific Documentation=20 =20 The service specific rating input AVPs, the contents of the Service-=20 Parameter-Info AVP or Service-Identifier AVP are not within the scope = of=20 this document. To facilitate interoperability, it is RECOMMENDED that = the=20 rating input and the values of the service identifiers are = coordinated via=20 an informational RFC or other permanent and readily available = reference=20 such as the specification of another cooperative standardization body = (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services = may=20 be deployed that are subject to agreements between providers of the = credit=20 control server and client, in this case vendor specific AVPs can be = used. =20 =20 This specification, together with the above service specific = documents,=20 governs the credit control message. The rule is that service specific = documents define what existing AVPs or new AVPs are used as input to = the=20 rating process (i.e. they do not define new credit control = applications),=20 and thus need to be included in the Credit-Control-Request command by = a=20 Diameter Credit Control Client supporting a given service as *[AVP].=20 Should Service-Parameter-Info be used, then the service specific = document=20 MUST specify the exact content of this grouped AVP.=20 =20 4.1.4 Handling of Unsupported/Incorrect Rating Input =20 =20 Diameter credit control implementations are required to support the=20 Mandatory rating AVPs defined in service specific documentation of = the=20 services they support according to the 'M' bit rules in [DIAMBASE]. =20 =20 In case a rating input required for the rating process is incorrect = in the=20 Credit control request, or the credit control server does not support = the=20 requested service (identified by the Service-Idntifier AVP at command = level), the Credit control answer MUST contain error code=20 DIAMETER_RATING_FAILED. A CCR message with this error MUST contain = one or=20 more Failed-AVP AVPs containing the missing and/or unsupported AVPs = that=20 caused the failure. A Diameter credit control client receiving error = code=20 DIAMETER_RATING_FAILED in answer to a request MUST NOT send such = similar=20 requests in the future.=20 =20 4.1.5 RADIUS Vendor-Specific Rating Attributes=20 =20 When service specific documents include RADIUS vendor specific = attributes=20 that could be used as input in the rating process, the rules = described in=20 [NASREQ] for formatting the Diameter AVP MUST be followed. For = example,=20 the AVP code used is the vendor attribute type code, the = Vendor-Specific=20 flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA = Vendor=20 identification value. The Diameter AVP data field contains only the=20 attribute value of the RADIUS attribute.=20 > -----Original Message-----=20 > From: owner-aaa-wg@merit.edu=20 > [ mailto:owner-aaa-wg@merit.edu]On Behalf Of=20 > ext Glen Zorn=20 > Sent: 02 July, 2004 20:27=20 > To: aaa-wg@merit.edu=20 > Subject:=20 >=20 >=20 > Description of issue: No guarantee of interoperability=20 > between CCA implementations=20 > Submitter name: Glen Zorn=20 > Submitter email address: gwz@cisco.com=20 > Date first submitted: 2 July 2004=20 > Document: dcca=20 > Comment type: T=20 > Priority: S=20 > Section: 4.1=20 > Rationale/Explanation of issue:=20 > In order to interoperate, Diameter peers implementing the=20 > Diameter Credit Control Application must agree upon both the=20 > application and the service (specified in the=20 > Service-Identifier AVP). However, the inclusion of the=20 > Service-Identifier in the CCR and CCA messages is optional.=20 >=20 > Lengthy description of problem:=20 > Section 4.1, para. 6 states "it is the combination of support=20 > of the Diameter Credit Control Application and the service=20 > defined in the Service-Identifier AVP, which defines=20 > interoperability between any given credit control client and=20 > server." However, the inclusion of the Service-Identifier in=20 > the CCR and CCA messages is optional. This gives rise to a=20 > situation where two peers implementing the same application=20 > may not interoperate because they do not implement the same=20 > "service", and further, refuse to clearly communicate that fact.=20 >=20 > Requested change:=20 > Change section 4.1, paragraph 5 from=20 >=20 > This specification, together with service specific documents, is=20 > governing the credit control message. The rule is that service=20 > specific documents only define what existing AVPs or new AVPs are=20 > used as input to the rating process (i.e. they do not define new=20 > credit control applications), and thus need to be included in the=20 > Credit-Control-Request command by a Diameter Credit Control Client=20 > supporting a given service as *[AVP]. In order to define new AVPs,=20 > service specific documents MUST follow the practices defined in=20 > [DIAMBASE]. The service SHOULD be identified using the Service-=20 > Identifier AVP. The Service-Identifier AVP MUST be a unique=20 > identifier for a given service as defined in section 8.28.=20 >=20 > to=20 >=20 > This specification, together with service specific documents, is=20 > governing the credit control message. The rule is that service=20 > specific documents only define what existing AVPs or new AVPs are=20 > used as input to the rating process (i.e. they do not define new=20 > credit control applications), and thus need to be included in the=20 > Credit-Control-Request command by a Diameter Credit Control Client=20 > supporting a given service as *[AVP]. In order to define new AVPs,=20 > service specific documents MUST follow the practices defined in=20 > [DIAMBASE]. The service MUST be identified using the Service-=20 > Identifier AVP. The Service-Identifier AVP MUST be a unique=20 > identifier for a given service as defined in section 8.28.=20 >=20 > ~gwz=20 >=20 > "They that can give up essential liberty to obtain a little=20 > temporary safety deserve neither..."=20 > -- Benjamin Franklin, 1759=20 >=20 >=20 > "It is forbidden to kill; therefore all murderers are=20 > punished unless they kill in large numbers and to the sound=20 > of trumpets."=20 > -- Voltaire=20 >=20 >=20 ------_=_NextPart_001_01C46423.BC5949D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )
Hi,
 
some=20 comment in line.
 
Marco
-----Original Message-----
From: ext Mark Watson=20 [mailto:mwatson@nortelnetworks.com]
Sent: 07 July, 2004=20 15:29
To: 'Leena Mattila (TU/LMF)'; 'Mark Grayson = (mgrayson)'; Stura=20 Marco (Nokia-NET/Helsinki)
Cc: 'aaa-wg@merit.edu'; 'Glen = Zorn=20 (gwz)'; Claire Mousset
Subject: RE: DCC Service-Identifier = (was RE:=20 [AAA-WG]: RE: )

Hi Leena,

You wrote:

"- when using the MSCC the Service-ID on command = level is the=20
main service, e.g. Network access, and the = Service-Ids=20 within
the MSCC then identify the = sub-services within=20 the main service"

This sounds very reasonable to me, but it is not = what the=20 specification seems to imply. There is no concept in the spec of = 'services'=20 being 'sub-ordinate' to other 'services'. Furthermore, the fact that a = 'service' is sub-ordinate to Rating-Group implies that everything = within a=20 service has to be rated the same. So then even if there were = sub-services=20 within a 'main service' they would all have to be within the same=20 Rating-Group! 

 But = if people=20 feel it's clear that there can be such a thing as a 'main service' = which is=20 not part of any Rating Group and which has sub-services, then that = seems fine=20 to me.  

Mark, I = guess you are=20 referring to the picture in sect. 5.1.1. Right? If so, this picture = was=20 intended to only describe the MSCC concept, what Leena is mentioning=20 is probably not visible in that picture. The main service is = a=20 service of its own that represent for instance the bearer, in which = many other=20 services may be carried and may have different costs, and is not part = of any=20 RG. This 'main service' id also identifies the service = specific=20 document with mandatory AVPs that need to be supported, for = instance the=20 Flow bearer charging defined in 3GPP ideally would have the 'main = service' identifier something like Flow-Bearer-Credit-Co= ntrol@3gpp.org.

Would you have good suggestion for better = text in=20 section 5.1.1 and perhaps in the new 4.12 to remove any dubt?=20

As for (3), it doesn't seem a big deal, but does = seem=20 arbitrary - if I want to request a quota for a single Rating-Group = (which is=20 probably the most common case in 3GPP anyway) I need to use MSCC. 

Right.

...Mark

-----Original Message-----
From: Leena=20 Mattila (TU/LMF) [mailto:leena.mattila@ericsson.= com]=20
Sent: 07 July 2004 12:00
To:=20 Watson, Mark [MOP:EP10:EXCH]; 'Mark Grayson (mgrayson)';=20 'marco.stura@nokia.com'
Cc: = 'aaa-wg@merit.edu'; 'Glen=20 Zorn (gwz)'; Mousset, Claire [ADC:8J70:EXCH]
Subject:=20 RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )


Hi,

when the MSCC concept was introduced I always had = the=20 assumption that the services within the MSCC structure are =
sub-ordinate to some higher level service, e.g. Network = Access. Having=20 said that, it's also true that what one can do with MSCC one should be = able=20

to do with several messages (that's where the MSCC = issue=20 initially started). However, I still believe that those several =

messages are inter-related (otherwise you wouldn't = group them=20
in the same message, right?), and thus the = exact=20 formulation
would be 'what one can do with = MSCC one=20 should be able to do
with sub-sessions'. = Hence the=20 analogy between the two approaches is:
- = when using=20 the MSCC the Service-ID on command level is the
main=20 service, e.g. Network access, and the Service-Ids within =
the MSCC then identify the sub-services within the main = service=20
- when using sub-sessions the Service-ID in 'main' = session is=20
the main service and the Service-Ids in = sub-sessions=20 (on
command level) are the = sub-services.=20
If there is no common factor between the = Service-IDs one has=20
grouped within one MSCC, then I think they = should not=20 be
grouped together at all, they are then = clearly not=20 sub-ordinate services (e.g. not carried within the same bearer) and = should=20

treat them as such - optimizing signaling =
should not be the only justification for doing the grouping.=20
And when there is a common factor, that = factor should=20 become
the Service-ID on command = level.

Regarding the question (3): I'll put it the other = way around:=20
At the moment it's not possible to have = rating groups=20 on
command level but do you see a need for = it?=20

Regards,
Leena

-----Original Message-----
From:=20 owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]= On=20 Behalf Of Mark Watson
Sent: 6. hein=E4kuuta = 2004=20 19:21
To: 'Mark Grayson (mgrayson)';=20 'marco.stura@nokia.com'
Cc: = 'aaa-wg@merit.edu'; 'Glen=20 Zorn (gwz)'; Claire Mousset
Subject: RE: DCC = Service-Identifier (was RE: [AAA-WG]: RE: )


Hi Mark,

Note sure what you mean by a 'rating-root', but it = is quite=20 clear (e.g. in the diagrams in 5.1.1) that 'services' are sub-ordinate = to=20 Rating-Groups. Since everything in a Rating-Group is rated the same = way then=20 certainly you cannot have things within a service which are rated = differently.=20 That is, services are the finest level of granularity that can be = separately=20 charged.

The point of MSCC was to do in one message what = could=20 otherwise be done with several messages and only command level values = - so I=20 would expect the things appearing in the MSCC to have the same = semantics as=20 things appearing at command level & for the two to be mutually = exclusive -=20 hence Question 1 below.

To answre my question (2) below for myself, we don't = need=20 multiple instances of the same service within a single sub-session. In = 3GPP, I=20 think we may have a requirement for dynamically povisioned services, = but the=20 dynamic provisioning of these to DCC client & server is out of = scope here=20 & so there should be no problem.

...Mark
-----Original=20 Message-----
From: Mark Grayson (mgrayson) = [mailto:mgrayson@cisco.com]=20
Sent: 06 July 2004 16:44
To:=20 Watson, Mark [MOP:EP10:EXCH]; marco.stura@nokia.com
Cc: aaa-wg@merit.edu; Glen Zorn (gwz); Mousset, Claire=20 [ADC:8J70:EXCH]
Subject: RE: DCC = Service-Identifier=20 (was RE: [AAA-WG]: RE: )


Mark, Marco

I hadn't made the same assumption - but agree that = there is=20 ambiguity here.

I had asumed that when present on the command level, = the=20 service-ID refers to the "rating-root" which then needs to be common = between=20 client and serer.

Then the issue exists with re-introducing the = service-ID at=20 the MSCC level, now possibly below the sub-session-ID which I think is = the=20 cause of the issue. IMO these AVPs at the MSCC level should be = subordinate to=20 the service-ID on the command level.

Cheers,
Mark =




From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]= On=20 Behalf Of Mark Watson
Sent: 06 July 2004 = 11:08=20
To: 'marco.stura@nokia.com'
Cc:=20 'aaa-wg@merit.edu'; Glen Zorn (gwz); Claire Mousset
Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: = )=20


Hi Marco,
Some quick = questions for=20 clarification on this one...
1) If the = client wants to=20 request quotas for multiple services using the=20 Multiple-Services-Credit-Control AVP then what should it put in the = mandatory=20 command level Service-Identifier AVP ?

2) Service-Identifier is finer granlarity than = Rating-Group -=20 that is several services with unique Service-Identifiers are grouped = within a=20 single Rating-Group. So a 'service' identified by a Service-Identifier = is=20 basically the finest granularity thing that can be separately charged. = But=20 then the definition of the Service Identifier AVP speaks of statically = configured or standardised values. To be consistent with the above it = would=20 need to be a format or pattern than was configured/standardised - e.g. = if it's=20 voice calls that you are charging for then Service Identifies like=20 'voice001@blah.org', 'voice002@blah.org' would be needed to = distinguish=20 between multiple concurrent voice calls. Right ?

3) It isn't possible to request credit for a = Rating-Group=20 except by using the Multiple-Services-Credit-Control AVP, right ?=20 Regards...Mark


-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20
Sent: 05 July 2004 09:09
To:=20 gwz@cisco.com
Cc: aaa-wg@merit.edu =
Subject: [AAA-WG]: RE:


Glen,
the Service-Id is = only included=20 in CCR message (at command level) to indicate
to the=20 server for what specific service the request is being issued. The = server=20 checks first the Service-Id AVP and, if it doesn't recognize the value = of this=20 AVP, it rejects the request without any further processing (e.g. = rating or=20 what so ever). If the server recognizes the value of the Service-Id = AVP, it=20 continues the processing and authorizes the credit if possible (i.e. = if there=20 is enough credit in the user's account). 

The section 4.1 has been restructured on request of = IESG=20 review as follow, the inclusion of the Service-Id in CCR is mandatory. = Whenever the IESG and the ADs will agree that their comments have been = properly addressed, the draft 06 will be carried out and made = available.=20 Regards

Marco
4.1 Service-Specific = Rating=20 Input and Interoperability
   =20
   The Diameter Credit-Control = Application=20 defines the framework for credit
   control;=20 it provides generic credit control mechanisms supporting multiple=20
   service applications. The = Credit Control=20 Application, therefore, does not
   define=20 AVPs that could be used as input in the rating process. Listing the=20
   possible services that could = use this=20 Diameter application is seen as out
   of=20 scope for this generic mechanism as well. 
   
   = Furthermore, it=20 is reasonable to expect that there will exist a service =
   level agreement between providers of the = credit-control=20 client and the
   credit-control = server=20 covering the charging, services offered, roaming
   agreements, agreed rating input (i.e. AVPs), = etc.=20
   Therefore, it is assumed that a = Diameter=20 credit control server will
   = provide=20 service only for Diameter credit-control clients that have agreed=20
   beforehand the content of = credit control=20 messages. Protocol wise, it is
   = naturally=20 possible that any arbitrary Diameter credit-control client can=20
   interchange credit control = messages with=20 any Diameter credit control
   = server, but=20 with a higher likelihood that unsupported services/AVPs could =
   be present in the credit-control message causing = the=20 server to reject the
   request = with an=20 appropriate result-code.
   =20
4.1.1 Specifying Rating Input AVPs =
   
   = There are two=20 ways for providing rating input to the credit control
   server, either by using AVPs or by including = them in the=20 Service-
   Parameter-Info AVP. = The general=20 principles for sending rating parameters
  =20 are:
   
   1a. The service SHOULD re-use existing AVPs, if = the=20 service can use AVPs
       defined in existing = Diameter=20 applications (e.g. NASREQ for network
       access services). Re-use = of=20 existing AVPs is strongly recommended in
       [DIAMBASE]. =
       For AVPs of type = Enumerated the=20 service may require a new value to be
       defined. Allocation of = new AVP=20 values is done as specified in
       [DIAMBASE], section 1.2. =
   
   1b. New AVPs can be defined if the existing AVPs = do not=20 provide sufficient
       rating information. In = such a=20 case, the procedures defined in
       [DIAMBASE] for creating = new AVPs=20 MUST be followed.
    =
   1c. For services specific only to one vendor's=20 implementation, a Vendor-
       Specific AVP code for = Private use=20 can be used. Where a Vendor-Specific
       AVP is implemented by = more than=20 one vendor, allocation of global AVPs
       are encouraged instead, = refer to=20 [DIAMBASE].
    =
   2. The Service-Parameter-Info AVP MAY be used as = a=20 container to pass
     =20 legacy rating information in its original encoded form (e.g. ASN.1=20
      BER). This = method can=20 be used to avoid unnecessary data format
      conversions from an existing = format to=20 an AVP format. In that case the
      rating input is embedded in = the=20 Service-Parameter-Info AVP as defined
      in section 8.42. =
   
   New = service=20 applications SHOULD favor the use of explicitly defined AVPs =
   as described in items 1a and 1b, to simplify=20 interoperability. 
   =20
4.1.2 Application Support
   
   = Since the=20 Application-Id of the Diameter Credit Control Application does=20
   not uniquely identify the = service being=20 monitored, an additional mechanism
   is=20 needed. The service application MUST be identified using the Service-=20
   Identifier AVP at command = level. A server=20 receiving a request for a
   = service=20 application it does not support will reject the request as defined=20
   in sub-section 4.1.4. The=20 Service-Identifier AVP MUST be a unique
  =20 identifier for a given service as defined in section 8.28. =20
   
   Thus, the combination of the Diameter Credit = Control=20 Application-Id and
   the = Service-Identifier=20 AVP in the Credit-Control-Request command uniquely
   defines the service within the context of the = Diameter=20 Credit Control, and
   hence = provides=20 interoperability between Diameter credit control clients =
   and server.
   =20
   With this mechanism it is = possible to=20 cover additional service specific
  =20 requirements as needed in other documents. However, introducing new = credit=20
   control mechanisms to the = framework=20 defined in this specification, require
  =20 definition of a new version of the Diameter Credit Control Application = and=20
   corresponding Application = Identifier.=20
   
4.1.3=20 Service-Specific Documentation
    
   The=20 service specific rating input AVPs, the contents of the Service-=20
   Parameter-Info AVP or = Service-Identifier=20 AVP are not within the scope of
   = this=20 document. To facilitate interoperability, it is RECOMMENDED that the=20
   rating input and the values of = the=20 service identifiers are coordinated via
  =20 an informational RFC or other permanent and readily available = reference=20
   such as the specification of = another=20 cooperative standardization body
   (e.g.=20 3GPP, OMA and 3GPP2) SHOULD be used. However, private services may=20
   be deployed that are subject to = agreements between providers of the credit
   control server and client, in this case vendor = specific=20 AVPs can be used. 
       
   This specification, together with the above = service=20 specific documents,
   governs the = credit=20 control message. The rule is that service specific
   documents define what existing AVPs or new AVPs = are used=20 as input to the
   rating process = (i.e. they=20 do not define new credit control applications),
   and thus need to be included in the = Credit-Control-Request=20 command by a
   Diameter Credit = Control=20 Client supporting a given service as *[AVP].
   Should Service-Parameter-Info be used, then the = service=20 specific document
   MUST specify = the exact=20 content of this grouped AVP.
   =20
4.1.4 Handling of Unsupported/Incorrect = Rating=20 Input 
    =
   Diameter credit control implementations are = required to=20 support the
   Mandatory rating = AVPs defined=20 in service specific documentation of the
  =20 services they support according to the 'M' bit rules in = [DIAMBASE]. =20
       =20
   In case a rating input required = for the=20 rating process is incorrect in the
   Credit=20 control request, or the credit control server does not support the=20
   requested service (identified = by the=20 Service-Idntifier AVP at command
   level),=20 the Credit control answer MUST contain error code
   DIAMETER_RATING_FAILED. A CCR message with this = error MUST=20 contain one or
   more Failed-AVP = AVPs=20 containing the missing and/or unsupported AVPs that
   caused the failure. A Diameter credit control = client=20 receiving error code
  =20 DIAMETER_RATING_FAILED in answer to a request MUST NOT send such = similar=20
   requests in the future. =
   
4.1.5 RADIUS = Vendor-Specific=20 Rating Attributes
       
   When service specific documents include RADIUS = vendor=20 specific attributes
   that could = be used as=20 input in the rating process, the rules described in
   [NASREQ] for formatting the Diameter AVP MUST be = followed.=20 For example,
   the AVP code used = is the=20 vendor attribute type code, the Vendor-Specific
   flag MUST be set to 1 and the Vendor-ID MUST be = set to the=20 IANA Vendor
   identification = value. The=20 Diameter AVP data field contains only the
  =20 attribute value of the RADIUS attribute.
>=20 -----Original Message-----
> From:=20 owner-aaa-wg@merit.edu
> [mailto:owner-aaa-wg@merit.edu]= On=20 Behalf Of
> ext Glen Zorn =
> Sent: 02 July, 2004 20:27
> = To:=20 aaa-wg@merit.edu
> Subject: =
>
>
>=20 Description of issue:  No guarantee of interoperability =
> between CCA implementations
> Submitter=20 name: Glen Zorn
> Submitter email = address:=20 gwz@cisco.com
> Date first submitted: 2 = July 2004=20
> Document: dcca
>=20 Comment type: T
> Priority: S =
> Section: 4.1
> = Rationale/Explanation of=20 issue:
> In order to interoperate, = Diameter peers=20 implementing the
> Diameter Credit = Control=20 Application must agree upon both the
> = application=20 and the service (specified in the
>=20 Service-Identifier AVP).  However, the inclusion of the =
> Service-Identifier in the CCR and CCA messages is = optional.=20
>
> Lengthy = description=20 of problem:
> Section 4.1, para. 6 states = "it is=20 the combination of support
> of the = Diameter Credit=20 Control Application and the service
> = defined in=20 the Service-Identifier AVP, which defines
>=20 interoperability between any given credit control client and =
> server."  However, the inclusion of the = Service-Identifier in=20
> the CCR and CCA messages is = optional.  This=20 gives rise to a
> situation where two = peers=20 implementing the same application
> may = not=20 interoperate because they do not implement the same
> "service", and further, refuse to clearly communicate = that fact.=20
>
> = Requested=20 change:
> Change section 4.1, paragraph 5 = from=20
>
>   =20 This specification, together with service specific documents, is=20
>    governing the credit = control=20 message. The rule is that service
>    specific documents only define what = existing=20 AVPs or new AVPs are
>    = used as=20 input to the rating process (i.e. they do not define new =
>    credit control applications), and thus = need to=20 be included in the
>   =20 Credit-Control-Request command by a Diameter Credit Control Client=20
>    supporting a given = service as=20 *[AVP]. In order to define new AVPs,
>    service specific documents MUST follow = the=20 practices defined in
>   =20 [DIAMBASE]. The service SHOULD be identified using the Service-=20
>    Identifier AVP. The=20 Service-Identifier AVP MUST be a unique
>    identifier for a given service as = defined in=20 section 8.28.
>
>=20 to
>
>   =20 This specification, together with service specific documents, is=20
>    governing the credit = control=20 message. The rule is that service
>    specific documents only define what = existing=20 AVPs or new AVPs are
>    = used as=20 input to the rating process (i.e. they do not define new =
>    credit control applications), and thus = need to=20 be included in the
>   =20 Credit-Control-Request command by a Diameter Credit Control Client=20
>    supporting a given = service as=20 *[AVP]. In order to define new AVPs,
>    service specific documents MUST follow = the=20 practices defined in
>   =20 [DIAMBASE]. The service MUST be identified using the Service- =
>    Identifier AVP. The Service-Identifier = AVP MUST=20 be a unique
>    = identifier for a=20 given service as defined in section 8.28.
>=20
> ~gwz
>=20
> "They that can give up essential = liberty to=20 obtain a little
> temporary safety = deserve=20 neither..."
> -- Benjamin Franklin, 1759=20
>
> =
> "It is forbidden to kill; therefore all murderers = are=20
> punished unless they kill in large numbers and = to the=20 sound
> of trumpets."
>=20 -- Voltaire
>
>=20

------_=_NextPart_001_01C46423.BC5949D0-- From owner-aaa-wg@merit.edu Wed Jul 7 09:35: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 JAA18890 for ; Wed, 7 Jul 2004 09:35:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A9D25912BA; Wed, 7 Jul 2004 09:35:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 751F9912BB; Wed, 7 Jul 2004 09:35:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 81C24912BA for ; Wed, 7 Jul 2004 09:35:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6DD565A1E7; Wed, 7 Jul 2004 09:35:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id E69975A22C for ; Wed, 7 Jul 2004 09:35:31 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i67DY4R26736; Wed, 7 Jul 2004 06:34:04 -0700 Date: Wed, 7 Jul 2004 06:34:04 -0700 (PDT) From: Bernard Aboba To: Javier Gonzalez Gallego Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter-nasreq-15. question for clarification In-Reply-To: <5149A4FBB886D511AF7100508BF93A1806B652BE@znsgy0k4.europe.nortel.com> Message-ID: References: <5149A4FBB886D511AF7100508BF93A1806B652BE@znsgy0k4.europe.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This looks like an oversight. Can you submit an issue for it? On Wed, 7 Jul 2004, Javier Gonzalez Gallego wrote: > Hi all > Looking at the nasreq draft, I can see that in the message format of AAA, > there's no *[Failed-AVP] > Is this correct? > If for example in the AAR we have a required AVP missing, in the AAA answer > this error should be reported with a Failed-AVP indicating the missing AVP. > > Thanks in advance for the clarifications > From owner-aaa-wg@merit.edu Wed Jul 7 09:47: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 JAA19402 for ; Wed, 7 Jul 2004 09:47:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8031391254; Wed, 7 Jul 2004 09:47:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51CD6912BD; Wed, 7 Jul 2004 09:47:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4A03F91254 for ; Wed, 7 Jul 2004 09:47:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E0EF25A20A; Wed, 7 Jul 2004 09:47:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 38CEF5A1B6 for ; Wed, 7 Jul 2004 09:47:21 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i67DjlW27426; Wed, 7 Jul 2004 06:45:47 -0700 Date: Wed, 7 Jul 2004 06:45:47 -0700 (PDT) From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: crich@nortelnetworks.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A60227C130@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A60227C130@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > This brings us back to the topic what an "application" > actually is. It could mean e.g. a software module in > a Diameter implementation, or a (set of) specifications > that document how Diameter is extended for some particular > purpose (such as SIP or Mobile IPv4). > > My reading of RFC3588 supports the latter interpretation > (but I guess there is some room for disagreement and > other interpretations as well...). I agree with Pasi that RFC 3588 supports the interpretation of "Application" as a set of specifications for extending Diameter for some particular purpose. In particular, this implies that the Diameter Application-Id cannot be used for multiplexing between software modules, as can other header fields, such as the TCP/UDP port number, EAP Type, etc. > Abort-Session-Request referring to a DCC session > would use application identifier 0. Yes, because ASRs typically do not require additional Mandatory AVPs, and therefore application identifier 0 is appropriate. > Of course, there might be a DCC-specific software module > that actually handles the message, but I think we should > use some other word than "application" for that. Good point. > Firstly, there is section 3 of RFC 3588. It states that the > application-id in the header of any command MUST be the same as the > application id in any relevant AVPs. Can you be more specific on what the problem is with this? > Secondly, what if a Diameter peer does not want to use a base > application but only wants to use some other application. If the "base application" is part of the specification, why it would it want to use something else? > For example, an operator may want to disable a node's > Diameter Accounting application while maintaining some other > application(s). Assuming that "other application" does not require advertising Diameter Base Common Messages (app-id 0) there is no problem with this. > The Diameter protocol should not force the node to > advertise support for an application that is not enabled. I don't see anything in RFC 3588 that requires this. > Regardless of which spec a command is defined, a command is only > relevant to the application to which the command is destined. Commands are not destined to an application. They are part of an application as defined by the application's specification. As Pasi noted, I think the term "application" is used differently in RFC 3588 than it is normally used in conversation, as equivalent to "software module". > a management node wants to Abort a DCCA session on the DCCA client, it > only makes sense to send the ASR to the DCC client application - since > it is the DCC client application which is handling the session. I think you are presuming that the Application-ID is used for multiplexing between software modules resident on Diameter peers, somewhat like TCP/UDP port numbers or EAP Types. I don't think that the Diameter Application-Id can actually be used this way, due to its definition. Perhaps that is the root of the issue we are discussing. From owner-aaa-wg@merit.edu Wed Jul 7 09:52: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 JAA19765 for ; Wed, 7 Jul 2004 09:52:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0EA45912BD; Wed, 7 Jul 2004 09:52:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC153912BE; Wed, 7 Jul 2004 09:52:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D4A85912BD for ; Wed, 7 Jul 2004 09:52:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9E5F85A218; Wed, 7 Jul 2004 09:52:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id DECF55A245 for ; Wed, 7 Jul 2004 09:52:26 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i67DoA427662; Wed, 7 Jul 2004 06:50:10 -0700 Date: Wed, 7 Jul 2004 06:50:10 -0700 (PDT) From: Bernard Aboba To: mikko.aittola@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage In-Reply-To: <9B95641F3AE80F4C8CD5B288FE8C9631AAB000@esebe012.ntc.nokia.com> Message-ID: References: <9B95641F3AE80F4C8CD5B288FE8C9631AAB000@esebe012.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Application X defines commands: C1 and C2 > Application Y defines command: C3 and also re-uses C1 > > First of all, if application Y re-uses C1 it must be stated > in the specification of application Y. Agreed. > If a DiameterIdentity advertises support for application X, > it must support C1 and C2. C1 is used with app-id X. Yes. > If a DiameterIdentity advertises support for application Y, > it must support C1 and C3. C1 is used with app-id Y. This is where we disagree. C1 cannot use app-id Y unless application Y changes the nature of the command by adding a requirement for a new mandatory AVP. Otherwise it needs to use application X, as described in RFC 3588. > If a DiameterIdentity advertises support for application X and Y, it > must support C1, C2, and C3. C1 can be used with app-id X and Y. I disagree. C1 can only be used with app-id Y if another mandatory AVP is defined. Otherwise, C1 can only be used with app-id X. From owner-aaa-wg@merit.edu Wed Jul 7 10:05: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 KAA20635 for ; Wed, 7 Jul 2004 10:05:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 302A7912A3; Wed, 7 Jul 2004 10:05:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E98AD91256; Wed, 7 Jul 2004 10:05:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F112F912BE for ; Wed, 7 Jul 2004 10:05:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D4A655A206; Wed, 7 Jul 2004 10:05:06 -0400 (EDT) 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 043F05A1B6 for ; Wed, 7 Jul 2004 10:05:05 -0400 (EDT) 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 i67E3so00984; Wed, 7 Jul 2004 15:03:54 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Jul 2004 15:03:54 +0100 Message-ID: <588B15E2E2B1D41180B800508BF934F20F5579A2@bmdhd6.europe.nortel.com> From: "Mark Watson" To: "'marco.stura@nokia.com'" , "'leena.mattila@ericsson.com'" , "'mgrayson@cisco.com'" Cc: "'aaa-wg@merit.edu'" , "'gwz@cisco.com'" , "Claire Mousset" Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Date: Wed, 7 Jul 2004 15:03:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4642B.3B70A68A" 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_01C4642B.3B70A68A Content-Type: text/plain; charset="iso-8859-1" Hi Marco, Ok, so now I am very glad I asked the question, since there seems to be a bunch of stuff here which is just not described properly. I'm happy to help with text though (if such changes can still be made), once we have a common understanding that makes sense. Firstly, from the description below, Service-Identifier at the command level does not (necessarily) identify a unique service, but rather a class of services, with the specific service(s) being identified in MSCC. So then the text in various places about Service-Identifier being a 'unique identifier for a service' would need to be clarified. But it is not clear to me why this 'class' of services cannot be implicitly derived from the specific service identifiersm, or even that the server will do with this information. That is, the server can identify which information it needs to rate the service from the specific Service-Identifier (or Rating-Group) in the MSCC - what additional value does the command level Service-Identifier bring ? Furthermore, if you do have this command level Service-Identifier, and the client is trusted to set it correctly, then it is no greater leap of trust to trust the client to include the Mandatory AVPs that are associated with that Service-Identifier value! In the 3GPP example, the server knows that the client supports these AVPs from the Supported-Vendor-ID in the capability exchange. Sending the Service-Identifier value is like a message saying 'Please check I have also included AVPs X, Y and Z'! A wrongly implemented client might not send these AVPs, but more likely, a wrongly implemented client would not set the Service-Identifier either. Secondly, you are introducing the concept that a service may imply requirements as to additional mandatory AVPs that should accompany any request for a quota for that service. That's fine, but perhaps it should be explained. Regards...Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 07 July 2004 14:10 To: Watson, Mark [MOP:EP10:EXCH]; leena.mattila@ericsson.com; mgrayson@cisco.com Cc: aaa-wg@merit.edu; gwz@cisco.com; Mousset, Claire [ADC:8J70:EXCH] Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Hi, some comment in line. Marco -----Original Message----- From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 07 July, 2004 15:29 To: 'Leena Mattila (TU/LMF)'; 'Mark Grayson (mgrayson)'; Stura Marco (Nokia-NET/Helsinki) Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Claire Mousset Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Hi Leena, You wrote: "- when using the MSCC the Service-ID on command level is the main service, e.g. Network access, and the Service-Ids within the MSCC then identify the sub-services within the main service" This sounds very reasonable to me, but it is not what the specification seems to imply. There is no concept in the spec of 'services' being 'sub-ordinate' to other 'services'. Furthermore, the fact that a 'service' is sub-ordinate to Rating-Group implies that everything within a service has to be rated the same. So then even if there were sub-services within a 'main service' they would all have to be within the same Rating-Group! But if people feel it's clear that there can be such a thing as a 'main service' which is not part of any Rating Group and which has sub-services, then that seems fine to me. Mark, I guess you are referring to the picture in sect. 5.1.1. Right? If so, this picture was intended to only describe the MSCC concept, what Leena is mentioning is probably not visible in that picture. The main service is a service of its own that represent for instance the bearer, in which many other services may be carried and may have different costs, and is not part of any RG. This 'main service' id also identifies the service specific document with mandatory AVPs that need to be supported, for instance the Flow bearer charging defined in 3GPP ideally would have the 'main service' identifier something like Flow-Bearer-Credit-Control@3gpp.org . Would you have good suggestion for better text in section 5.1.1 and perhaps in the new 4.12 to remove any dubt? As for (3), it doesn't seem a big deal, but does seem arbitrary - if I want to request a quota for a single Rating-Group (which is probably the most common case in 3GPP anyway) I need to use MSCC. Right. ...Mark -----Original Message----- From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com ] Sent: 07 July 2004 12:00 To: Watson, Mark [MOP:EP10:EXCH]; 'Mark Grayson (mgrayson)'; 'marco.stura@nokia.com' Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Mousset, Claire [ADC:8J70:EXCH] Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Hi, when the MSCC concept was introduced I always had the assumption that the services within the MSCC structure are sub-ordinate to some higher level service, e.g. Network Access. Having said that, it's also true that what one can do with MSCC one should be able to do with several messages (that's where the MSCC issue initially started). However, I still believe that those several messages are inter-related (otherwise you wouldn't group them in the same message, right?), and thus the exact formulation would be 'what one can do with MSCC one should be able to do with sub-sessions'. Hence the analogy between the two approaches is: - when using the MSCC the Service-ID on command level is the main service, e.g. Network access, and the Service-Ids within the MSCC then identify the sub-services within the main service - when using sub-sessions the Service-ID in 'main' session is the main service and the Service-Ids in sub-sessions (on command level) are the sub-services. If there is no common factor between the Service-IDs one has grouped within one MSCC, then I think they should not be grouped together at all, they are then clearly not sub-ordinate services (e.g. not carried within the same bearer) and should treat them as such - optimizing signaling should not be the only justification for doing the grouping. And when there is a common factor, that factor should become the Service-ID on command level. Regarding the question (3): I'll put it the other way around: At the moment it's not possible to have rating groups on command level but do you see a need for it? Regards, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu ]On Behalf Of Mark Watson Sent: 6. heinäkuuta 2004 19:21 To: 'Mark Grayson (mgrayson)'; 'marco.stura@nokia.com' Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Claire Mousset Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Hi Mark, Note sure what you mean by a 'rating-root', but it is quite clear (e.g. in the diagrams in 5.1.1) that 'services' are sub-ordinate to Rating-Groups. Since everything in a Rating-Group is rated the same way then certainly you cannot have things within a service which are rated differently. That is, services are the finest level of granularity that can be separately charged. The point of MSCC was to do in one message what could otherwise be done with several messages and only command level values - so I would expect the things appearing in the MSCC to have the same semantics as things appearing at command level & for the two to be mutually exclusive - hence Question 1 below. To answre my question (2) below for myself, we don't need multiple instances of the same service within a single sub-session. In 3GPP, I think we may have a requirement for dynamically povisioned services, but the dynamic provisioning of these to DCC client & server is out of scope here & so there should be no problem. ...Mark -----Original Message----- From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com ] Sent: 06 July 2004 16:44 To: Watson, Mark [MOP:EP10:EXCH]; marco.stura@nokia.com Cc: aaa-wg@merit.edu; Glen Zorn (gwz); Mousset, Claire [ADC:8J70:EXCH] Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Mark, Marco I hadn't made the same assumption - but agree that there is ambiguity here. I had asumed that when present on the command level, the service-ID refers to the "rating-root" which then needs to be common between client and serer. Then the issue exists with re-introducing the service-ID at the MSCC level, now possibly below the sub-session-ID which I think is the cause of the issue. IMO these AVPs at the MSCC level should be subordinate to the service-ID on the command level. Cheers, Mark From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu ] On Behalf Of Mark Watson Sent: 06 July 2004 11:08 To: 'marco.stura@nokia.com' Cc: 'aaa-wg@merit.edu'; Glen Zorn (gwz); Claire Mousset Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Hi Marco, Some quick questions for clarification on this one... 1) If the client wants to request quotas for multiple services using the Multiple-Services-Credit-Control AVP then what should it put in the mandatory command level Service-Identifier AVP ? 2) Service-Identifier is finer granlarity than Rating-Group - that is several services with unique Service-Identifiers are grouped within a single Rating-Group. So a 'service' identified by a Service-Identifier is basically the finest granularity thing that can be separately charged. But then the definition of the Service Identifier AVP speaks of statically configured or standardised values. To be consistent with the above it would need to be a format or pattern than was configured/standardised - e.g. if it's voice calls that you are charging for then Service Identifies like 'voice001@blah.org', 'voice002@blah.org' would be needed to distinguish between multiple concurrent voice calls. Right ? 3) It isn't possible to request credit for a Rating-Group except by using the Multiple-Services-Credit-Control AVP, right ? Regards...Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com ] Sent: 05 July 2004 09:09 To: gwz@cisco.com Cc: aaa-wg@merit.edu Subject: [AAA-WG]: RE: Glen, the Service-Id is only included in CCR message (at command level) to indicate to the server for what specific service the request is being issued. The server checks first the Service-Id AVP and, if it doesn't recognize the value of this AVP, it rejects the request without any further processing (e.g. rating or what so ever). If the server recognizes the value of the Service-Id AVP, it continues the processing and authorizes the credit if possible (i.e. if there is enough credit in the user's account). The section 4.1 has been restructured on request of IESG review as follow, the inclusion of the Service-Id in CCR is mandatory. Whenever the IESG and the ADs will agree that their comments have been properly addressed, the draft 06 will be carried out and made available. Regards Marco 4.1 Service-Specific Rating Input and Interoperability The Diameter Credit-Control Application defines the framework for credit control; it provides generic credit control mechanisms supporting multiple service applications. The Credit Control Application, therefore, does not define AVPs that could be used as input in the rating process. Listing the possible services that could use this Diameter application is seen as out of scope for this generic mechanism as well. Furthermore, it is reasonable to expect that there will exist a service level agreement between providers of the credit-control client and the credit-control server covering the charging, services offered, roaming agreements, agreed rating input (i.e. AVPs), etc. Therefore, it is assumed that a Diameter credit control server will provide service only for Diameter credit-control clients that have agreed beforehand the content of credit control messages. Protocol wise, it is naturally possible that any arbitrary Diameter credit-control client can interchange credit control messages with any Diameter credit control server, but with a higher likelihood that unsupported services/AVPs could be present in the credit-control message causing the server to reject the request with an appropriate result-code. 4.1.1 Specifying Rating Input AVPs There are two ways for providing rating input to the credit control server, either by using AVPs or by including them in the Service- Parameter-Info AVP. The general principles for sending rating parameters are: 1a. The service SHOULD re-use existing AVPs, if the service can use AVPs defined in existing Diameter applications (e.g. NASREQ for network access services). Re-use of existing AVPs is strongly recommended in [DIAMBASE]. For AVPs of type Enumerated the service may require a new value to be defined. Allocation of new AVP values is done as specified in [DIAMBASE], section 1.2. 1b. New AVPs can be defined if the existing AVPs do not provide sufficient rating information. In such a case, the procedures defined in [DIAMBASE] for creating new AVPs MUST be followed. 1c. For services specific only to one vendor's implementation, a Vendor- Specific AVP code for Private use can be used. Where a Vendor-Specific AVP is implemented by more than one vendor, allocation of global AVPs are encouraged instead, refer to [DIAMBASE]. 2. The Service-Parameter-Info AVP MAY be used as a container to pass legacy rating information in its original encoded form (e.g. ASN.1 BER). This method can be used to avoid unnecessary data format conversions from an existing format to an AVP format. In that case the rating input is embedded in the Service-Parameter-Info AVP as defined in section 8.42. New service applications SHOULD favor the use of explicitly defined AVPs as described in items 1a and 1b, to simplify interoperability. 4.1.2 Application Support Since the Application-Id of the Diameter Credit Control Application does not uniquely identify the service being monitored, an additional mechanism is needed. The service application MUST be identified using the Service- Identifier AVP at command level. A server receiving a request for a service application it does not support will reject the request as defined in sub-section 4.1.4. The Service-Identifier AVP MUST be a unique identifier for a given service as defined in section 8.28. Thus, the combination of the Diameter Credit Control Application-Id and the Service-Identifier AVP in the Credit-Control-Request command uniquely defines the service within the context of the Diameter Credit Control, and hence provides interoperability between Diameter credit control clients and server. With this mechanism it is possible to cover additional service specific requirements as needed in other documents. However, introducing new credit control mechanisms to the framework defined in this specification, require definition of a new version of the Diameter Credit Control Application and corresponding Application Identifier. 4.1.3 Service-Specific Documentation The service specific rating input AVPs, the contents of the Service- Parameter-Info AVP or Service-Identifier AVP are not within the scope of this document. To facilitate interoperability, it is RECOMMENDED that the rating input and the values of the service identifiers are coordinated via an informational RFC or other permanent and readily available reference such as the specification of another cooperative standardization body (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services may be deployed that are subject to agreements between providers of the credit control server and client, in this case vendor specific AVPs can be used. This specification, together with the above service specific documents, governs the credit control message. The rule is that service specific documents define what existing AVPs or new AVPs are used as input to the rating process (i.e. they do not define new credit control applications), and thus need to be included in the Credit-Control-Request command by a Diameter Credit Control Client supporting a given service as *[AVP]. Should Service-Parameter-Info be used, then the service specific document MUST specify the exact content of this grouped AVP. 4.1.4 Handling of Unsupported/Incorrect Rating Input Diameter credit control implementations are required to support the Mandatory rating AVPs defined in service specific documentation of the services they support according to the 'M' bit rules in [DIAMBASE]. In case a rating input required for the rating process is incorrect in the Credit control request, or the credit control server does not support the requested service (identified by the Service-Idntifier AVP at command level), the Credit control answer MUST contain error code DIAMETER_RATING_FAILED. A CCR message with this error MUST contain one or more Failed-AVP AVPs containing the missing and/or unsupported AVPs that caused the failure. A Diameter credit control client receiving error code DIAMETER_RATING_FAILED in answer to a request MUST NOT send such similar requests in the future. 4.1.5 RADIUS Vendor-Specific Rating Attributes When service specific documents include RADIUS vendor specific attributes that could be used as input in the rating process, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute. > -----Original Message----- > From: owner-aaa-wg@merit.edu > [mailto:owner-aaa-wg@merit.edu ]On Behalf Of > ext Glen Zorn > Sent: 02 July, 2004 20:27 > To: aaa-wg@merit.edu > Subject: > > > Description of issue: No guarantee of interoperability > between CCA implementations > Submitter name: Glen Zorn > Submitter email address: gwz@cisco.com > Date first submitted: 2 July 2004 > Document: dcca > Comment type: T > Priority: S > Section: 4.1 > Rationale/Explanation of issue: > In order to interoperate, Diameter peers implementing the > Diameter Credit Control Application must agree upon both the > application and the service (specified in the > Service-Identifier AVP). However, the inclusion of the > Service-Identifier in the CCR and CCA messages is optional. > > Lengthy description of problem: > Section 4.1, para. 6 states "it is the combination of support > of the Diameter Credit Control Application and the service > defined in the Service-Identifier AVP, which defines > interoperability between any given credit control client and > server." However, the inclusion of the Service-Identifier in > the CCR and CCA messages is optional. This gives rise to a > situation where two peers implementing the same application > may not interoperate because they do not implement the same > "service", and further, refuse to clearly communicate that fact. > > Requested change: > Change section 4.1, paragraph 5 from > > This specification, together with service specific documents, is > governing the credit control message. The rule is that service > specific documents only define what existing AVPs or new AVPs are > used as input to the rating process (i.e. they do not define new > credit control applications), and thus need to be included in the > Credit-Control-Request command by a Diameter Credit Control Client > supporting a given service as *[AVP]. In order to define new AVPs, > service specific documents MUST follow the practices defined in > [DIAMBASE]. The service SHOULD be identified using the Service- > Identifier AVP. The Service-Identifier AVP MUST be a unique > identifier for a given service as defined in section 8.28. > > to > > This specification, together with service specific documents, is > governing the credit control message. The rule is that service > specific documents only define what existing AVPs or new AVPs are > used as input to the rating process (i.e. they do not define new > credit control applications), and thus need to be included in the > Credit-Control-Request command by a Diameter Credit Control Client > supporting a given service as *[AVP]. In order to define new AVPs, > service specific documents MUST follow the practices defined in > [DIAMBASE]. The service MUST be identified using the Service- > Identifier AVP. The Service-Identifier AVP MUST be a unique > identifier for a given service as defined in section 8.28. > > ~gwz > > "They that can give up essential liberty to obtain a little > temporary safety deserve neither..." > -- Benjamin Franklin, 1759 > > > "It is forbidden to kill; therefore all murderers are > punished unless they kill in large numbers and to the sound > of trumpets." > -- Voltaire > > ------_=_NextPart_001_01C4642B.3B70A68A Content-Type: text/html; charset="iso-8859-1" Message
Hi Marco,
 
Ok, so now I am very glad I asked the question, since there seems to be a bunch of stuff here which is just not described properly. I'm happy to help with text though (if such changes can still be made), once we have a common understanding that makes sense.
 
Firstly, from the description below, Service-Identifier at the command level does not (necessarily) identify a unique service, but rather a class of services, with the specific service(s) being identified in MSCC. So then the text in various places about Service-Identifier being a 'unique identifier for a service' would need to be clarified.
 
But it is not clear to me why this 'class' of services cannot be implicitly derived from the specific service identifiersm, or even that the server will do with this information. That is, the server can identify which information it needs to rate the service from the specific Service-Identifier (or Rating-Group) in the MSCC - what additional value does the command level Service-Identifier bring ?
 
Furthermore, if you do have this command level Service-Identifier, and the client is trusted to set it correctly, then it is no greater leap of trust to trust the client to include the Mandatory AVPs that are associated with that Service-Identifier value! In the 3GPP example, the server knows that the client supports these AVPs from the Supported-Vendor-ID in the capability exchange. Sending the Service-Identifier value is like a message saying 'Please check I have also included AVPs X, Y and Z'! A wrongly implemented client might not send these AVPs, but more likely, a wrongly implemented client would not set the Service-Identifier either.
 
Secondly, you are introducing the concept that a service may imply requirements as to additional mandatory AVPs that should accompany any request for a quota for that service. That's fine, but perhaps it should be explained.
 
Regards...Mark
-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: 07 July 2004 14:10
To: Watson, Mark [MOP:EP10:EXCH]; leena.mattila@ericsson.com; mgrayson@cisco.com
Cc: aaa-wg@merit.edu; gwz@cisco.com; Mousset, Claire [ADC:8J70:EXCH]
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Hi,
 
some comment in line.
 
Marco
-----Original Message-----
From: ext Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: 07 July, 2004 15:29
To: 'Leena Mattila (TU/LMF)'; 'Mark Grayson (mgrayson)'; Stura Marco (Nokia-NET/Helsinki)
Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Claire Mousset
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Hi Leena,

You wrote:

"- when using the MSCC the Service-ID on command level is the
main service, e.g. Network access, and the Service-Ids within
the MSCC then identify the sub-services within the main service"

This sounds very reasonable to me, but it is not what the specification seems to imply. There is no concept in the spec of 'services' being 'sub-ordinate' to other 'services'. Furthermore, the fact that a 'service' is sub-ordinate to Rating-Group implies that everything within a service has to be rated the same. So then even if there were sub-services within a 'main service' they would all have to be within the same Rating-Group! 

 But if people feel it's clear that there can be such a thing as a 'main service' which is not part of any Rating Group and which has sub-services, then that seems fine to me.  

Mark, I guess you are referring to the picture in sect. 5.1.1. Right? If so, this picture was intended to only describe the MSCC concept, what Leena is mentioning is probably not visible in that picture. The main service is a service of its own that represent for instance the bearer, in which many other services may be carried and may have different costs, and is not part of any RG. This 'main service' id also identifies the service specific document with mandatory AVPs that need to be supported, for instance the Flow bearer charging defined in 3GPP ideally would have the 'main service' identifier something like Flow-Bearer-Credit-Control@3gpp.org.

Would you have good suggestion for better text in section 5.1.1 and perhaps in the new 4.12 to remove any dubt?

As for (3), it doesn't seem a big deal, but does seem arbitrary - if I want to request a quota for a single Rating-Group (which is probably the most common case in 3GPP anyway) I need to use MSCC. 

Right.

...Mark

-----Original Message-----
From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com]
Sent: 07 July 2004 12:00
To: Watson, Mark [MOP:EP10:EXCH]; 'Mark Grayson (mgrayson)'; 'marco.stura@nokia.com'
Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Mousset, Claire [ADC:8J70:EXCH]
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )


Hi,

when the MSCC concept was introduced I always had the assumption that the services within the MSCC structure are
sub-ordinate to some higher level service, e.g. Network Access. Having said that, it's also true that what one can do with MSCC one should be able

to do with several messages (that's where the MSCC issue initially started). However, I still believe that those several

messages are inter-related (otherwise you wouldn't group them
in the same message, right?), and thus the exact formulation
would be 'what one can do with MSCC one should be able to do
with sub-sessions'. Hence the analogy between the two approaches is:
- when using the MSCC the Service-ID on command level is the
main service, e.g. Network access, and the Service-Ids within
the MSCC then identify the sub-services within the main service
- when using sub-sessions the Service-ID in 'main' session is
the main service and the Service-Ids in sub-sessions (on
command level) are the sub-services.
If there is no common factor between the Service-IDs one has
grouped within one MSCC, then I think they should not be
grouped together at all, they are then clearly not sub-ordinate services (e.g. not carried within the same bearer) and should

treat them as such - optimizing signaling
should not be the only justification for doing the grouping.
And when there is a common factor, that factor should become
the Service-ID on command level.

Regarding the question (3): I'll put it the other way around:
At the moment it's not possible to have rating groups on
command level but do you see a need for it?

Regards,
Leena

-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Mark Watson
Sent: 6. heinäkuuta 2004 19:21
To: 'Mark Grayson (mgrayson)'; 'marco.stura@nokia.com'
Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Claire Mousset
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )


Hi Mark,

Note sure what you mean by a 'rating-root', but it is quite clear (e.g. in the diagrams in 5.1.1) that 'services' are sub-ordinate to Rating-Groups. Since everything in a Rating-Group is rated the same way then certainly you cannot have things within a service which are rated differently. That is, services are the finest level of granularity that can be separately charged.

The point of MSCC was to do in one message what could otherwise be done with several messages and only command level values - so I would expect the things appearing in the MSCC to have the same semantics as things appearing at command level & for the two to be mutually exclusive - hence Question 1 below.

To answre my question (2) below for myself, we don't need multiple instances of the same service within a single sub-session. In 3GPP, I think we may have a requirement for dynamically povisioned services, but the dynamic provisioning of these to DCC client & server is out of scope here & so there should be no problem.

...Mark
-----Original Message-----
From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com]
Sent: 06 July 2004 16:44
To: Watson, Mark [MOP:EP10:EXCH]; marco.stura@nokia.com
Cc: aaa-wg@merit.edu; Glen Zorn (gwz); Mousset, Claire [ADC:8J70:EXCH]
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )


Mark, Marco

I hadn't made the same assumption - but agree that there is ambiguity here.

I had asumed that when present on the command level, the service-ID refers to the "rating-root" which then needs to be common between client and serer.

Then the issue exists with re-introducing the service-ID at the MSCC level, now possibly below the sub-session-ID which I think is the cause of the issue. IMO these AVPs at the MSCC level should be subordinate to the service-ID on the command level.

Cheers,
Mark




From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of Mark Watson
Sent: 06 July 2004 11:08
To: 'marco.stura@nokia.com'
Cc: 'aaa-wg@merit.edu'; Glen Zorn (gwz); Claire Mousset
Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: )


Hi Marco,
Some quick questions for clarification on this one...
1) If the client wants to request quotas for multiple services using the Multiple-Services-Credit-Control AVP then what should it put in the mandatory command level Service-Identifier AVP ?

2) Service-Identifier is finer granlarity than Rating-Group - that is several services with unique Service-Identifiers are grouped within a single Rating-Group. So a 'service' identified by a Service-Identifier is basically the finest granularity thing that can be separately charged. But then the definition of the Service Identifier AVP speaks of statically configured or standardised values. To be consistent with the above it would need to be a format or pattern than was configured/standardised - e.g. if it's voice calls that you are charging for then Service Identifies like 'voice001@blah.org', 'voice002@blah.org' would be needed to distinguish between multiple concurrent voice calls. Right ?

3) It isn't possible to request credit for a Rating-Group except by using the Multiple-Services-Credit-Control AVP, right ? Regards...Mark


-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: 05 July 2004 09:09
To: gwz@cisco.com
Cc: aaa-wg@merit.edu
Subject: [AAA-WG]: RE:


Glen,
the Service-Id is only included in CCR message (at command level) to indicate
to the server for what specific service the request is being issued. The server checks first the Service-Id AVP and, if it doesn't recognize the value of this AVP, it rejects the request without any further processing (e.g. rating or what so ever). If the server recognizes the value of the Service-Id AVP, it continues the processing and authorizes the credit if possible (i.e. if there is enough credit in the user's account). 

The section 4.1 has been restructured on request of IESG review as follow, the inclusion of the Service-Id in CCR is mandatory. Whenever the IESG and the ADs will agree that their comments have been properly addressed, the draft 06 will be carried out and made available. Regards

Marco
4.1 Service-Specific Rating Input and Interoperability
   
   The Diameter Credit-Control Application defines the framework for credit
   control; it provides generic credit control mechanisms supporting multiple
   service applications. The Credit Control Application, therefore, does not
   define AVPs that could be used as input in the rating process. Listing the
   possible services that could use this Diameter application is seen as out
   of scope for this generic mechanism as well. 
   
   Furthermore, it is reasonable to expect that there will exist a service
   level agreement between providers of the credit-control client and the
   credit-control server covering the charging, services offered, roaming
   agreements, agreed rating input (i.e. AVPs), etc.
   Therefore, it is assumed that a Diameter credit control server will
   provide service only for Diameter credit-control clients that have agreed
   beforehand the content of credit control messages. Protocol wise, it is
   naturally possible that any arbitrary Diameter credit-control client can
   interchange credit control messages with any Diameter credit control
   server, but with a higher likelihood that unsupported services/AVPs could
   be present in the credit-control message causing the server to reject the
   request with an appropriate result-code.
   
4.1.1 Specifying Rating Input AVPs
   
   There are two ways for providing rating input to the credit control
   server, either by using AVPs or by including them in the Service-
   Parameter-Info AVP. The general principles for sending rating parameters
   are:
   
   1a. The service SHOULD re-use existing AVPs, if the service can use AVPs
       defined in existing Diameter applications (e.g. NASREQ for network
       access services). Re-use of existing AVPs is strongly recommended in
       [DIAMBASE].
       For AVPs of type Enumerated the service may require a new value to be
       defined. Allocation of new AVP values is done as specified in
       [DIAMBASE], section 1.2.
   
   1b. New AVPs can be defined if the existing AVPs do not provide sufficient
       rating information. In such a case, the procedures defined in
       [DIAMBASE] for creating new AVPs MUST be followed.
   
   1c. For services specific only to one vendor's implementation, a Vendor-
       Specific AVP code for Private use can be used. Where a Vendor-Specific
       AVP is implemented by more than one vendor, allocation of global AVPs
       are encouraged instead, refer to [DIAMBASE].
   
   2. The Service-Parameter-Info AVP MAY be used as a container to pass
      legacy rating information in its original encoded form (e.g. ASN.1
      BER). This method can be used to avoid unnecessary data format
      conversions from an existing format to an AVP format. In that case the
      rating input is embedded in the Service-Parameter-Info AVP as defined
      in section 8.42.
   
   New service applications SHOULD favor the use of explicitly defined AVPs
   as described in items 1a and 1b, to simplify interoperability. 
   
4.1.2 Application Support
   
   Since the Application-Id of the Diameter Credit Control Application does
   not uniquely identify the service being monitored, an additional mechanism
   is needed. The service application MUST be identified using the Service-
   Identifier AVP at command level. A server receiving a request for a
   service application it does not support will reject the request as defined
   in sub-section 4.1.4. The Service-Identifier AVP MUST be a unique
   identifier for a given service as defined in section 8.28. 
   
   Thus, the combination of the Diameter Credit Control Application-Id and
   the Service-Identifier AVP in the Credit-Control-Request command uniquely
   defines the service within the context of the Diameter Credit Control, and
   hence provides interoperability between Diameter credit control clients
   and server.
   
   With this mechanism it is possible to cover additional service specific
   requirements as needed in other documents. However, introducing new credit
   control mechanisms to the framework defined in this specification, require
   definition of a new version of the Diameter Credit Control Application and
   corresponding Application Identifier.
   
4.1.3 Service-Specific Documentation
    
   The service specific rating input AVPs, the contents of the Service-
   Parameter-Info AVP or Service-Identifier AVP are not within the scope of
   this document. To facilitate interoperability, it is RECOMMENDED that the
   rating input and the values of the service identifiers are coordinated via
   an informational RFC or other permanent and readily available reference
   such as the specification of another cooperative standardization body
   (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services may
   be deployed that are subject to agreements between providers of the credit
   control server and client, in this case vendor specific AVPs can be used. 
       
   This specification, together with the above service specific documents,
   governs the credit control message. The rule is that service specific
   documents define what existing AVPs or new AVPs are used as input to the
   rating process (i.e. they do not define new credit control applications),
   and thus need to be included in the Credit-Control-Request command by a
   Diameter Credit Control Client supporting a given service as *[AVP].
   Should Service-Parameter-Info be used, then the service specific document
   MUST specify the exact content of this grouped AVP.
   
4.1.4 Handling of Unsupported/Incorrect Rating Input 
   
   Diameter credit control implementations are required to support the
   Mandatory rating AVPs defined in service specific documentation of the
   services they support according to the 'M' bit rules in [DIAMBASE]. 
       
   In case a rating input required for the rating process is incorrect in the
   Credit control request, or the credit control server does not support the
   requested service (identified by the Service-Idntifier AVP at command
   level), the Credit control answer MUST contain error code
   DIAMETER_RATING_FAILED. A CCR message with this error MUST contain one or
   more Failed-AVP AVPs containing the missing and/or unsupported AVPs that
   caused the failure. A Diameter credit control client receiving error code
   DIAMETER_RATING_FAILED in answer to a request MUST NOT send such similar
   requests in the future.
   
4.1.5 RADIUS Vendor-Specific Rating Attributes
       
   When service specific documents include RADIUS vendor specific attributes
   that could be used as input in the rating process, the rules described in
   [NASREQ] for formatting the Diameter AVP MUST be followed. For example,
   the AVP code used is the vendor attribute type code, the Vendor-Specific
   flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor
   identification value. The Diameter AVP data field contains only the
   attribute value of the RADIUS attribute.
> -----Original Message-----
> From: owner-aaa-wg@merit.edu
> [mailto:owner-aaa-wg@merit.edu]On Behalf Of
> ext Glen Zorn
> Sent: 02 July, 2004 20:27
> To: aaa-wg@merit.edu
> Subject:
>
>
> Description of issue:  No guarantee of interoperability
> between CCA implementations
> Submitter name: Glen Zorn
> Submitter email address: gwz@cisco.com
> Date first submitted: 2 July 2004
> Document: dcca
> Comment type: T
> Priority: S
> Section: 4.1
> Rationale/Explanation of issue:
> In order to interoperate, Diameter peers implementing the
> Diameter Credit Control Application must agree upon both the
> application and the service (specified in the
> Service-Identifier AVP).  However, the inclusion of the
> Service-Identifier in the CCR and CCA messages is optional.
>
> Lengthy description of problem:
> Section 4.1, para. 6 states "it is the combination of support
> of the Diameter Credit Control Application and the service
> defined in the Service-Identifier AVP, which defines
> interoperability between any given credit control client and
> server."  However, the inclusion of the Service-Identifier in
> the CCR and CCA messages is optional.  This gives rise to a
> situation where two peers implementing the same application
> may not interoperate because they do not implement the same
> "service", and further, refuse to clearly communicate that fact.
>
> Requested change:
> Change section 4.1, paragraph 5 from
>
>    This specification, together with service specific documents, is
>    governing the credit control message. The rule is that service
>    specific documents only define what existing AVPs or new AVPs are
>    used as input to the rating process (i.e. they do not define new
>    credit control applications), and thus need to be included in the
>    Credit-Control-Request command by a Diameter Credit Control Client
>    supporting a given service as *[AVP]. In order to define new AVPs,
>    service specific documents MUST follow the practices defined in
>    [DIAMBASE]. The service SHOULD be identified using the Service-
>    Identifier AVP. The Service-Identifier AVP MUST be a unique
>    identifier for a given service as defined in section 8.28.
>
> to
>
>    This specification, together with service specific documents, is
>    governing the credit control message. The rule is that service
>    specific documents only define what existing AVPs or new AVPs are
>    used as input to the rating process (i.e. they do not define new
>    credit control applications), and thus need to be included in the
>    Credit-Control-Request command by a Diameter Credit Control Client
>    supporting a given service as *[AVP]. In order to define new AVPs,
>    service specific documents MUST follow the practices defined in
>    [DIAMBASE]. The service MUST be identified using the Service-
>    Identifier AVP. The Service-Identifier AVP MUST be a unique
>    identifier for a given service as defined in section 8.28.
>
> ~gwz
>
> "They that can give up essential liberty to obtain a little
> temporary safety deserve neither..."
> -- Benjamin Franklin, 1759
>
>
> "It is forbidden to kill; therefore all murderers are
> punished unless they kill in large numbers and to the sound
> of trumpets."
> -- Voltaire
>
>

------_=_NextPart_001_01C4642B.3B70A68A-- From owner-aaa-wg@merit.edu Wed Jul 7 10:44: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 KAA23565 for ; Wed, 7 Jul 2004 10:44:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E62389121B; Wed, 7 Jul 2004 10:43:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABABD91256; Wed, 7 Jul 2004 10:43:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 341599121B for ; Wed, 7 Jul 2004 10:43:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1FAE95A231; Wed, 7 Jul 2004 10:43:52 -0400 (EDT) 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 7C9F25A1F6 for ; Wed, 7 Jul 2004 10:43:51 -0400 (EDT) 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 i67Ehno05987 for ; Wed, 7 Jul 2004 15:43:49 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Jul 2004 15:43:49 +0100 Message-ID: <5149A4FBB886D511AF7100508BF93A1806BC4B5D@znsgy0k4.europe.nortel.com> From: "Javier Gonzalez Gallego" To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue with draft-ietf-aaa-diameter-nasreq-15.txt Date: Wed, 7 Jul 2004 15:43:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46430.CFEE2E7C" 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_01C46430.CFEE2E7C Content-Type: text/plain Description of issue: Oversight of one AVP in the AAA message Submitter name: Javier Gonzalez Date first submitted: 07.07.2004 Reference: Document: draft-ietf-aaa-diameter-nasreq-15.txt Comment type: Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Section: 3.2 Rationale/Explanation of issues: In the AAA message, the *[Failed-AVP] is missing. This is needed to report some of the permanent failures as inicated by RFC 3588. To follow the pattern of other Answer messages (RAA), it should be inserted after [ Error-Message ] [ Error-Reporting-Host ] Requested change: Before: ::= < Diameter Header: 265, PXY > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } { Origin-Host } { Origin-Realm } [ User-Name ] [ Service-Type ] * [ Class ] * [ Configuration-Token ] [ Acct-Interim-Interval ] [ Error-Message ] [ Error-Reporting-Host ] [ Idle-Timeout ] [ Authorization-Lifetime ] .... (Skipped text) After: ::= < Diameter Header: 265, PXY > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } { Origin-Host } { Origin-Realm } [ User-Name ] [ Service-Type ] * [ Class ] * [ Configuration-Token ] [ Acct-Interim-Interval ] [ Error-Message ] [ Error-Reporting-Host ] * [ Failed-AVP ] [ Idle-Timeout ] [ Authorization-Lifetime ] .... (Skipped text) ------_=_NextPart_001_01C46430.CFEE2E7C Content-Type: text/html Content-Transfer-Encoding: quoted-printable Issue with draft-ietf-aaa-diameter-nasreq-15.txt

Description of issue: Oversight of one AVP in the AAA = message
Submitter name: Javier Gonzalez
Date first submitted: 07.07.2004
Reference:
Document:  = draft-ietf-aaa-diameter-nasreq-15.txt
Comment type:
Priority: ['S' Must fix | '1' Should fix | '2' May = fix ]
Section: 3.2

Rationale/Explanation of issues:

In the AAA message, the *[Failed-AVP] is missing. = This is needed to report some of the permanent failures as inicated by = RFC 3588.

To follow the pattern of other Answer messages (RAA), = it should be inserted after
          &nb= sp;           [ = Error-Message ]
          &nb= sp;           [ = Error-Reporting-Host ]




Requested change:

Before:
 <AA-Answer> ::=3D < Diameter Header: = 265, PXY >
          &nb= sp;           < = Session-Id >
          &nb= sp;           { = Auth-Application-Id }
          &nb= sp;           { = Auth-Request-Type }
          &nb= sp;           { = Result-Code }
          &nb= sp;           { = Origin-Host }
          &nb= sp;           { = Origin-Realm }
          &nb= sp;           [ = User-Name ]
          &nb= sp;           [ = Service-Type ]
          &nb= sp;         * [ Class ]
          &nb= sp;         * [ = Configuration-Token ]
          &nb= sp;           [ = Acct-Interim-Interval ]
          &nb= sp;           [ = Error-Message ]
          &nb= sp;           [ = Error-Reporting-Host ]
          &nb= sp;           [ = Idle-Timeout ]
          &nb= sp;           [ = Authorization-Lifetime ]
....
(Skipped text)


After:
 <AA-Answer> ::=3D < Diameter Header: = 265, PXY >
          &nb= sp;           < = Session-Id >
          &nb= sp;           { = Auth-Application-Id }
          &nb= sp;           { = Auth-Request-Type }
          &nb= sp;           { = Result-Code }
          &nb= sp;           { = Origin-Host }
          &nb= sp;           { = Origin-Realm }
          &nb= sp;           [ = User-Name ]
          &nb= sp;           [ = Service-Type ]
          &nb= sp;         * [ Class ]
          &nb= sp;         * [ = Configuration-Token ]
          &nb= sp;           [ = Acct-Interim-Interval ]
          &nb= sp;           [ = Error-Message ]
          &nb= sp;           [ = Error-Reporting-Host ]
        =         =           * [ = Failed-AVP ]
          &nb= sp;           [ = Idle-Timeout ]
          &nb= sp;           [ = Authorization-Lifetime ]
....
(Skipped text)


------_=_NextPart_001_01C46430.CFEE2E7C-- From owner-aaa-wg@merit.edu Wed Jul 7 12:16: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 MAA28244 for ; Wed, 7 Jul 2004 12:16:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 98182912A7; Wed, 7 Jul 2004 12:16:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F1FD912BE; Wed, 7 Jul 2004 12:16:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1CD5D912A7 for ; Wed, 7 Jul 2004 12:16:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 097BE5A205; Wed, 7 Jul 2004 12:16:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 321DF59C6E for ; Wed, 7 Jul 2004 12:16:30 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i67GEuc03450; Wed, 7 Jul 2004 09:14:56 -0700 Date: Wed, 7 Jul 2004 09:14:56 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: QoS-Filter-Rule AVP missing in NASREQ? In-Reply-To: <40E8F0B7.60507@kolumbus.fi> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A60227C12C@esebe023.ntc.nokia.com> <40E8F0B7.60507@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > This might also allow us to address the issue of the missing text. > > Do we remember why the missing text was taken away? I've done a bit more archeology, and here is what I've found. Apparently, QoS-Filter-Rule AVP was never included in NASREQ. However, the QoS-Filter-Rule data type first found its way into the Diameter Base specification with draft-ietf-aaa-diameter-07.txt, submitted in July 2001. The text remained unchanged until the second half of it was removed in draft-ietf-aaa-diameter-10.txt, submitted in April 2002. This looks like an editing mistake, rather than an intentional removal, since I can't find an Issue for which the removal might be a resolution. The mistake was apparently not detected prior to publication of RFC 3588. To understand how QoS-Filter-Rule AVP got into Diameter Base in the first place, I went back to the original requirements documents. In terms of NASREQ QoS support, the original requirement came from RFC 2881 (NASREQNG). Section 9.3.6 says: A NAS may delivery different qualities, types, or levels of service to different users based on policy and identity. NAS's may perform bandwidth management, allow differential speeds or methods of access, or even participate in provisioned or signaled Quality of Service (QoS) networks. This was the original requirement that QoS-Filter-Rule AVP was trying to address. The NASREQ requirement was then rolled up into RFC 2989, "Criteria for Evaluating AAA Protocols for Network Access". This document included "Support for Access Rules, Restrictions, Filters" as a MUST for NASREQ, with a footnote e) clarifying the requirement: [e] This requirement refers to the ability to of the protocol to describe access operational limitations and authorization restrictions to usage to the NAS which includes (but is not limited to): 1. Session expirations and Idle Timeouts 2. Packet filters 3. Static routes 4. QoS parameters Given the importance of the QoS requirement for NASREQ (a MUST), the history within Diameter Base (apparent editorial mistake), and the relative ease with which the issue can be fixed (inclusion of a paragraph such as the following), I think this issue really does need to be addressed. Suggested fix: Insert a new section: X.X QoS-Filter-Rule AVP The QoS-Filter-Rule AVP (AVP Code XXX) is of type QoSFilterRule, and provides QoS filter rules that need to be configured on the NAS for the user. One or more such AVPs MAY be present in an authorization response. Note: Due to an editorial mistake in [RFC3588], the complete QoSFilterRule definition was not included. It is reprinted here for clarification. QoSFilterRule The QosFilterRule format is derived from the OctetString AVP Base Format. It uses the ASCII charset. Packets may be marked or metered based on the following information that is associated with it: Direction (in or out) Source and destination IP address (possibly masked) Protocol Source and destination port (lists or ranges) DSCP values (no mask or range) Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is treated as best effort. An access device that is unable to interpret or apply a QoS rule SHOULD NOT terminate the session. QoSFilterRule filters MUST follow the format: action dir proto from src to dst [options] tag - Mark packet with a specific DSCP [DIFFSERV]. The DSCP option MUST be included. meter - Meter traffic. The metering options MUST be included. dir The format is as described under IPFilterRule. proto The format is as described under IPFilterRule. src and dst The format is as described under IPFilterRule. options: DSCP color values as defined in [DIFFSERV]. Exact matching of DSCP values is required (no masks or ranges). metering The metering option provides Assured Forwarding, as defined in [DIFFSERVAF], and MUST be present if the action is set to meter. The rate option is the throughput, in bits per second, which is used by the access device to mark packets. Traffic above the rate is marked with the color_over codepoint, while traffic under the rate is marked with the color_under codepoint. The color_under and color_over options contain the drop preferences, and MUST conform to the recommended codepoint keywords described in [DIFFSERVAF] (e.g. AF13). The metering option also supports the strict limit on traffic required by Expedited Forwarding, as defined in [DIFFSERVEF]. The color_over option may contain the keyword "drop" to prevent forwarding of traffic that exceeds the rate parameter. The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations. From owner-aaa-wg@merit.edu Wed Jul 7 12:38: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 MAA29352 for ; Wed, 7 Jul 2004 12:38:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1BD0391255; Wed, 7 Jul 2004 12:38:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D9717912BF; Wed, 7 Jul 2004 12:38:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B73EB91255 for ; Wed, 7 Jul 2004 12:38:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 972755A290; Wed, 7 Jul 2004 12:38:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by segue.merit.edu (Postfix) with ESMTP id 0E88F5A260 for ; Wed, 7 Jul 2004 12:38:17 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i67Gc1u02478; Wed, 7 Jul 2004 12:38:01 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Jul 2004 12:38:01 -0400 Received: from nortelnetworks.com ([47.102.185.170] RDNS failed) by zrc2hxm2.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Jul 2004 11:37:56 -0500 Message-ID: <40EC265F.9050507@nortelnetworks.com> From: Joe Harvell To: Bernard Aboba Cc: Pasi.Eronen@nokia.com, "Christopher Richards" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 464: Application-Id Usage Date: Wed, 7 Jul 2004 12:35:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46440.C2259D42" 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_01C46440.C2259D42 Content-Type: text/plain; charset="ISO-8859-1" Bernard: Let's ignore the question of which value of the app id belongs in which commands for a second. I would like to know when the application-id field in the Diameter header and any included Auth-Application-Id or Accounting-Application-Id AVPs in the message could/should have values that are different? If they can never be different, then what is the purpose for the AVPs? Bernard Aboba wrote: > Firstly, there is section 3 of RFC 3588. It states that the > application-id in the header of any command MUST be the same as the > application id in any relevant AVPs. Can you be more specific on what the problem is with this? ------_=_NextPart_001_01C46440.C2259D42 Content-Type: text/html; charset="ISO-8859-1" Bernard:

Let's ignore the question of which value of the app id belongs in which commands for a second.  I would like to know when the application-id field in the Diameter header and any included Auth-Application-Id or Accounting-Application-Id AVPs in the message could/should have values that are different?

If they can never be different, then what is the purpose for the AVPs?

Bernard Aboba wrote:
RE: [AAA-WG]: Issue 464: Application-Id Usage

> Firstly, there is section 3 of RFC 3588. It states that the
> application-id in the header of any command MUST be the same as the
> application id in any relevant AVPs.

Can you be more specific on what the problem is with this?


------_=_NextPart_001_01C46440.C2259D42-- From owner-aaa-wg@merit.edu Wed Jul 7 12:40: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 MAA29487 for ; Wed, 7 Jul 2004 12:40:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A0C9F912BF; Wed, 7 Jul 2004 12:40:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60C8E912C5; Wed, 7 Jul 2004 12:40:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 29984912BF for ; Wed, 7 Jul 2004 12:40:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 15EEE5A265; Wed, 7 Jul 2004 12:40:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps06s.nortelnetworks.com (zrtps06s.nortelnetworks.com [47.140.48.50]) by segue.merit.edu (Postfix) with ESMTP id 8B51E5A28A for ; Wed, 7 Jul 2004 12:40:43 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i67GeXo28004; Wed, 7 Jul 2004 12:40:34 -0400 (EDT) Date: Wed, 7 Jul 2004 12:40:34 -0400 (EDT) Message-Id: <200407071640.i67GeXo28004@zrtps06s.nortelnetworks.com> Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Jul 2004 12:40:33 -0400 Received: from nortelnetworks.com ([47.102.185.170] RDNS failed) by zrc2hxm2.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Jul 2004 11:40:25 -0500 From: Joe Harvell To: Bernard Aboba Cc: Pasi.Eronen@nokia.com, "Christopher Richards" , aaa-wg@merit.edu Sender: owner-aaa-wg@merit.edu Precedence: bulk Microsoft Mail Internet Headers Version 2.0 Message-ID: <40EC26F5.4090808@nortelnetworks.com> Date: Wed, 07 Jul 2004 16:38:13 +0000 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: [AAA-WG]: Issue 464: Application-Id Usage (repost without html) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: harvell@nortelnetworks.com X-OriginalArrivalTime: 07 Jul 2004 16:40:25.0542 (UTC) FILETIME=[1A9DD660:01C46441] Bernard: Let's ignore the question of which value of the app id belongs in which commands for a second. I would like to know when the application-id field in the Diameter header and any included Auth-Application-Id or Accounting-Application-Id AVPs in the message could/should have values that are different? If they can never be different, then what is the purpose for the AVPs? Bernard Aboba wrote: > > Firstly, there is section 3 of RFC 3588. It states that the > > application-id in the header of any command MUST be the same as the > > application id in any relevant AVPs. > > Can you be more specific on what the problem is with this? > > From owner-aaa-wg@merit.edu Wed Jul 7 12:49: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 MAA00279 for ; Wed, 7 Jul 2004 12:49:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 59DD4912C2; Wed, 7 Jul 2004 12:49:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B219912C4; Wed, 7 Jul 2004 12:49:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D8E0B912C2 for ; Wed, 7 Jul 2004 12:49:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C538A5A1D6; Wed, 7 Jul 2004 12:49:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 19D935A22A for ; Wed, 7 Jul 2004 12:49:14 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i67GlRT05431; Wed, 7 Jul 2004 09:47:27 -0700 Date: Wed, 7 Jul 2004 09:47:27 -0700 (PDT) From: Bernard Aboba To: Joe Harvell Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 464: Application-Id Usage In-Reply-To: <40EC265F.9050507@nortelnetworks.com> Message-ID: References: <40EC265F.9050507@nortelnetworks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Joe -- There are obviously some areas of RFC 3588 that need clarification. The way I would propose that we handle this is similar to the way we handle any other issue. That is, you should go ahead and submit an issue for consideration in the RFC 3588 Errata list. this includes your proposed Errata text. The WG will then consider your Issue and decide whether RFC 3588 requires clarification via an errata or not. By submitting an Issue, we can guarantee that your concerns are tracked to resolution and that they will be discussed at IETF 60. On Wed, 7 Jul 2004, Joe Harvell wrote: > Bernard: > > Let's ignore the question of which value of the app id belongs in which > commands for a second. I would like to know when the application-id field > in the Diameter header and any included Auth-Application-Id or > Accounting-Application-Id AVPs in the message could/should have values that > are different? > > If they can never be different, then what is the purpose for the AVPs? > > Bernard Aboba wrote: > > > > Firstly, there is section 3 of RFC 3588. It states that the > > application-id in the header of any command MUST be the same as the > > application id in any relevant AVPs. > > Can you be more specific on what the problem is with this? > > > From owner-aaa-wg@merit.edu Wed Jul 7 17:38: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 RAA18842 for ; Wed, 7 Jul 2004 17:38:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A8F219125B; Wed, 7 Jul 2004 17:38:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D00C9125A; Wed, 7 Jul 2004 17:38:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3BD7591258 for ; Wed, 7 Jul 2004 17:38:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 268E95A30F; Wed, 7 Jul 2004 17:38:25 -0400 (EDT) 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 7E2445A314 for ; Wed, 7 Jul 2004 17:38:24 -0400 (EDT) Received: (cpmta 23310 invoked from network); 7 Jul 2004 14:38:23 -0700 Received: from 209.228.32.78 (HELO mail.mitton.com.criticalpath.net) by smtp.mitton.com (209.228.32.71) with SMTP; 7 Jul 2004 14:38:23 -0700 X-Sent: 7 Jul 2004 21:38:23 GMT Received: from [204.167.114.130] by mail.mitton.com with HTTP; Wed, 07 Jul 2004 14:38:23 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 To: aboba@internaut.com Cc: jari.arkko@kolumbus.fi, Pasi.Eronen@nokia.com, aaa-wg@merit.edu From: david@mitton.com Subject: Re: [AAA-WG]: QoS-Filter-Rule AVP missing in NASREQ? X-Sent-From: david@mitton.com Date: Wed, 07 Jul 2004 14:38:23 -0700 (PDT) X-Mailer: Web Mail 5.6.4-0 Message-Id: <20040707143823.21134.h014.c000.wm@mail.mitton.com.criticalpath.net> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'll find some place to put this. Let's see Draft 17 will have: - this AVP - App ID clarification(dust settled yet?) - Error AVPs in ABNF Dave. On Wed, 7 Jul 2004 09:14:56 -0700 (PDT), Bernard Aboba wrote: > > > > This might also allow us to address the issue of > the missing text. > > > > Do we remember why the missing text was taken away? > > I've done a bit more archeology, and here is what I've > found. > > Apparently, QoS-Filter-Rule AVP was never included in > NASREQ. However, ... From owner-aaa-wg@merit.edu Wed Jul 7 18:38: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 SAA24703 for ; Wed, 7 Jul 2004 18:38:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6EB6E91258; Wed, 7 Jul 2004 18:38:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3E3C891259; Wed, 7 Jul 2004 18:38:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3E87991258 for ; Wed, 7 Jul 2004 18:38:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2748F5A30F; Wed, 7 Jul 2004 18:38:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 642D55A2F0 for ; Wed, 7 Jul 2004 18:38:06 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i67MaAx25426; Wed, 7 Jul 2004 15:36:10 -0700 Date: Wed, 7 Jul 2004 15:36:10 -0700 (PDT) From: Bernard Aboba To: david@mitton.com Cc: jari.arkko@kolumbus.fi, Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: QoS-Filter-Rule AVP missing in NASREQ? In-Reply-To: <20040707143823.21134.h014.c000.wm@mail.mitton.com.criticalpath.net> Message-ID: References: <20040707143823.21134.h014.c000.wm@mail.mitton.com.criticalpath.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Thanks. I think dust has settled on App ID clarification in that Diameter Common messges app-ID should be used whenever there are no new mandatory AVPs. I think this means that AAR/AAA uses NASREQ ap-id, but that ACR/ACA, ASR/ASA use an app-ids from Diameter Base. I'm not sure about RAR/RAA, but think this might require a NASREQ app-id due to RADIUS/Diameter translation issues. Can you check? I think that Section 9 does not imply that RAR/RAA messages in NASREQ include any new mandatory AVPs, though I suppose this could be tricky if NASREQ AVPs were included in RADIUS CoA messages (e.g. only NAS-IPv6-Address and User-Name used to identify the session), and translation were required. In this case I think that a NAS-IP-Address, NAS-Identifier or NAS-IPv6-Address AVP might have to be marked mandatory. This issue could be clarified if a RAR/RAA table were to be included in the draft... On Wed, 7 Jul 2004 david@mitton.com wrote: > I'll find some place to put this. > > Let's see Draft 17 will have: > - this AVP > - App ID clarification(dust settled yet?) > - Error AVPs in ABNF > > Dave. > > > On Wed, 7 Jul 2004 09:14:56 -0700 (PDT), Bernard Aboba > wrote: > > > > > > > This might also allow us to address the issue of > > the missing text. > > > > > > Do we remember why the missing text was taken away? > > > > I've done a bit more archeology, and here is what I've > > found. > > > > Apparently, QoS-Filter-Rule AVP was never included in > > NASREQ. However, > ... > From owner-aaa-wg@merit.edu Thu Jul 8 02:28: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 CAA01160 for ; Thu, 8 Jul 2004 02:28:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7DDDD91218; Thu, 8 Jul 2004 02:27:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4358791259; Thu, 8 Jul 2004 02:27:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C69A791218 for ; Thu, 8 Jul 2004 02:27:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AA0C15A3F5; Thu, 8 Jul 2004 02:27:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id CA47A5A3AB for ; Thu, 8 Jul 2004 02:27:44 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 119E38983D; Thu, 8 Jul 2004 09:27:28 +0300 (EEST) Message-ID: <40ECE82B.7080004@kolumbus.fi> Date: Thu, 08 Jul 2004 09:22:35 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: QoS-Filter-Rule AVP missing in NASREQ? References: <052E0C61B69C3741AFA5FE88ACC775A60227C12C@esebe023.ntc.nokia.com> <40E8F0B7.60507@kolumbus.fi> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ok. Lets put it there. --Jari Bernard Aboba wrote: >>>This might also allow us to address the issue of the missing text. >> >>Do we remember why the missing text was taken away? > > > I've done a bit more archeology, and here is what I've found. > > Apparently, QoS-Filter-Rule AVP was never included in NASREQ. However, > the QoS-Filter-Rule data type first found its way into the Diameter Base > specification with draft-ietf-aaa-diameter-07.txt, submitted in July > 2001. > > The text remained unchanged until the second half of it was > removed in draft-ietf-aaa-diameter-10.txt, submitted in April 2002. > This looks like an editing mistake, rather than an intentional removal, > since I can't find an Issue for which the removal might be a resolution. The > mistake was apparently not detected prior to publication of RFC 3588. > > To understand how QoS-Filter-Rule AVP got into Diameter Base in the first > place, I went back to the original requirements documents. > > In terms of NASREQ QoS support, the original requirement came from RFC > 2881 (NASREQNG). Section 9.3.6 says: > > A NAS may delivery different qualities, types, or levels of service > to different users based on policy and identity. NAS's may perform > bandwidth management, allow differential speeds or methods of access, > or even participate in provisioned or signaled Quality of Service > (QoS) networks. > > This was the original requirement that QoS-Filter-Rule AVP was trying to > address. > > The NASREQ requirement was then rolled up into RFC 2989, "Criteria for > Evaluating AAA Protocols for Network Access". This document included > "Support for Access Rules, Restrictions, Filters" as a MUST for NASREQ, > with a footnote e) clarifying the requirement: > > [e] This requirement refers to the ability to of the protocol to > describe access operational limitations and authorization > restrictions to usage to the NAS which includes (but is not > limited to): > > 1. Session expirations and Idle Timeouts > 2. Packet filters > 3. Static routes > 4. QoS parameters > > Given the importance of the QoS requirement for NASREQ (a MUST), the > history within Diameter Base (apparent editorial mistake), and the > relative ease with which the issue can be fixed (inclusion of a paragraph > such as the following), I think this issue really does need to be > addressed. > > Suggested fix: > > Insert a new section: > > X.X QoS-Filter-Rule AVP > > The QoS-Filter-Rule AVP (AVP Code XXX) is of type QoSFilterRule, and > provides QoS filter rules that need to be configured on the NAS for the > user. One or more such AVPs MAY be present in an authorization > response. > > Note: Due to an editorial mistake in [RFC3588], the complete > QoSFilterRule definition was not included. It is reprinted here > for clarification. > > QoSFilterRule > The QosFilterRule format is derived from the OctetString AVP Base > Format. It uses the ASCII charset. Packets may be marked or > metered based on the following information that is associated with > it: > > Direction (in or out) > Source and destination IP address (possibly masked) > Protocol > Source and destination port (lists or ranges) > DSCP values (no mask or range) > > Rules for the appropriate direction are evaluated in order, with > the first matched rule terminating the evaluation. Each packet is > evaluated once. If no rule matches, the packet is treated as best > effort. An access device that is unable to interpret or apply a > QoS rule SHOULD NOT terminate the session. > > QoSFilterRule filters MUST follow the format: > > action dir proto from src to dst [options] > > tag - Mark packet with a specific DSCP > [DIFFSERV]. The DSCP option MUST be > included. > meter - Meter traffic. The metering options > MUST be included. > > dir The format is as described under IPFilterRule. > > proto The format is as described under IPFilterRule. > > src and dst The format is as described under IPFilterRule. > > options: > > DSCP > color values as defined in [DIFFSERV]. Exact > matching of DSCP values is required (no masks or > ranges). > > metering > The metering option provides Assured Forwarding, > as defined in [DIFFSERVAF], and MUST be present > if the action is set to meter. The rate option is > the throughput, in bits per second, which is used > by the access device to mark packets. Traffic > above the rate is marked with the color_over > codepoint, while traffic under the rate is marked > with the color_under codepoint. The color_under > and color_over options contain the drop > preferences, and MUST conform to the recommended > codepoint keywords described in [DIFFSERVAF] > (e.g. AF13). > > The metering option also supports the strict > limit on traffic required by Expedited > Forwarding, as defined in [DIFFSERVEF]. The > color_over option may contain the keyword "drop" > to prevent forwarding of traffic that exceeds the > rate parameter. > > The rule syntax is a modified subset of ipfw(8) from FreeBSD, > and the ipfw.c code may provide a useful base for > implementations. > From owner-aaa-wg@merit.edu Thu Jul 8 03:44: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 DAA04449 for ; Thu, 8 Jul 2004 03:44:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6F32C91259; Thu, 8 Jul 2004 03:44:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40C1F9125A; Thu, 8 Jul 2004 03:44:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EE1DD91259 for ; Thu, 8 Jul 2004 03:44:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DDBD25A425; Thu, 8 Jul 2004 03:44:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id E6DED5A445 for ; Thu, 8 Jul 2004 03:44:33 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i687iW413379 for ; Thu, 8 Jul 2004 10:44:32 +0300 (EET DST) X-Scanned: Thu, 8 Jul 2004 10:42:56 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i687gulc029334 for ; Thu, 8 Jul 2004 10:42:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 004jJBZa; Thu, 08 Jul 2004 10:42:53 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i687gln08603 for ; Thu, 8 Jul 2004 10:42:47 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Jul 2004 10:42:45 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Jul 2004 10:42:45 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage Date: Thu, 8 Jul 2004 10:42:43 +0300 Message-ID: <9B95641F3AE80F4C8CD5B288FE8C9631AAB001@esebe012.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 464: Application-Id Usage Thread-Index: AcRkKUlGWeRzO81wTgyLvhpBTTXJWgAkyiWw From: To: X-OriginalArrivalTime: 08 Jul 2004 07:42:45.0862 (UTC) FILETIME=[28C31060:01C464BF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > In particular, this implies that the Diameter Application-Id cannot be > used for multiplexing between software modules, as can other header > fields, such as the TCP/UDP port number, EAP Type, etc. > I think you are presuming that the Application-ID is used for=20 > multiplexing between software modules resident on Diameter peers, = somewhat=20 > like TCP/UDP port numbers or EAP Types. I don't think that the = Diameter=20 > Application-Id can actually be used this way, due to its definition. =20 I think RFC3588 does not specify any details regarding this kind of internal implementation issues. In my opinion, Application-Id can be used for multiplexing between software modules, just like any other information in the messages. I would also like to note that Application-Id can be used for routing messages between peers. RFC3588 Section 2.7 Realm-Based Routing = Table states that "A route entry can have a different destination based on the application identification AVP of the message." BR, Mikko > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Bernard Aboba > Sent: 07 July, 2004 16:46 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: crich@nortelnetworks.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage >=20 >=20 > > This brings us back to the topic what an "application" > > actually is. It could mean e.g. a software module in > > a Diameter implementation, or a (set of) specifications > > that document how Diameter is extended for some particular > > purpose (such as SIP or Mobile IPv4). > > > > My reading of RFC3588 supports the latter interpretation > > (but I guess there is some room for disagreement and > > other interpretations as well...). >=20 > I agree with Pasi that RFC 3588 supports the interpretation of > "Application" as a set of specifications for extending=20 > Diameter for some > particular purpose. >=20 > In particular, this implies that the Diameter Application-Id cannot be > used for multiplexing between software modules, as can other header > fields, such as the TCP/UDP port number, EAP Type, etc. >=20 > > Abort-Session-Request referring to a DCC session > > would use application identifier 0. >=20 > Yes, because ASRs typically do not require additional=20 > Mandatory AVPs, and > therefore application identifier 0 is appropriate. >=20 > > Of course, there might be a DCC-specific software module > > that actually handles the message, but I think we should > > use some other word than "application" for that. >=20 > Good point. >=20 > > Firstly, there is section 3 of RFC 3588. It states that the > > application-id in the header of any command MUST be the same as the > > application id in any relevant AVPs. >=20 > Can you be more specific on what the problem is with this? >=20 > > Secondly, what if a Diameter peer does not want to use a base > > application but only wants to use some other application. >=20 > If the "base application" is part of the specification, why=20 > it would it > want to use something else? >=20 > > For example, an operator may want to disable a node's > > Diameter Accounting application while maintaining some other > > application(s). >=20 > Assuming that "other application" does not require=20 > advertising Diameter > Base Common Messages (app-id 0) there is no problem with this. >=20 > > The Diameter protocol should not force the node to > > advertise support for an application that is not enabled. >=20 > I don't see anything in RFC 3588 that requires this. >=20 > > Regardless of which spec a command is defined, a command is only > > relevant to the application to which the command is destined. >=20 > Commands are not destined to an application. They are part of an > application as defined by the application's specification. =20 > As Pasi noted, > I think the term "application" is used differently in RFC=20 > 3588 than it is > normally used in conversation, as equivalent to "software module". >=20 > > a management node wants to Abort a DCCA session on the DCCA=20 > client, it > > only makes sense to send the ASR to the DCC client=20 > application - since > > it is the DCC client application which is handling the session. >=20 > I think you are presuming that the Application-ID is used for=20 > multiplexing > between software modules resident on Diameter peers, somewhat=20 > like TCP/UDP > port numbers or EAP Types. I don't think that the Diameter=20 > Application-Id > can actually be used this way, due to its definition. =20 > Perhaps that is the > root of the issue we are discussing. >=20 From owner-aaa-wg@merit.edu Thu Jul 8 04: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 EAA05255 for ; Thu, 8 Jul 2004 04:03:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 31E3E9125A; Thu, 8 Jul 2004 04:03:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F18C59125D; Thu, 8 Jul 2004 04:03:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 801E09125A for ; Thu, 8 Jul 2004 04:03:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 455AE5A406; Thu, 8 Jul 2004 04:03:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 621465A3F5 for ; Thu, 8 Jul 2004 04:03:38 -0400 (EDT) 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 i6883bL24049 for ; Thu, 8 Jul 2004 11:03:37 +0300 (EET DST) X-Scanned: Thu, 8 Jul 2004 11:02:40 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i6882eW7004023 for ; Thu, 8 Jul 2004 11:02:40 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00jT7fpT; Thu, 08 Jul 2004 11:02:37 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6882an24887 for ; Thu, 8 Jul 2004 11:02:36 +0300 (EET DST) Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Jul 2004 11:02:31 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage Date: Thu, 8 Jul 2004 11:02:30 +0300 Message-ID: <9B95641F3AE80F4C8CD5B288FE8C9631AAB002@esebe012.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 464: Application-Id Usage Thread-Index: AcRkKcT2A7C7YTzoQ7iOad3nxbW4DwAlYZlQ From: To: X-OriginalArrivalTime: 08 Jul 2004 08:02:31.0255 (UTC) FILETIME=[EB4FAE70:01C464C1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > This is where we disagree. C1 cannot use app-id Y unless=20 > application Y changes the nature of the command by adding a = requirement > for a new mandatory AVP. Otherwise it needs to use application X, as > described in RFC 3588. Well, I think a mandatory AVP could well be added to fulfill this = requirement, but I think avoiding the implementation of Application X is a good = enough reason to change the app-id for C1 if the command is re-used in the context of Application Y. If app-id X must be used with C1 it means that the peer must also = advertise support for Application X, and that means that it must also implement C2 and everything else for that application. That's way too much trouble if you only really want to implement a peer that supports Application Y. BTW, I agree Base Protocol commands can always be sent with app-id 0. I forgot to mention that in my previous post. BR, Mikko > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 07 July, 2004 16:50 > To: Aittola Mikko (Nokia-NET/Tampere) > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage >=20 >=20 > > Application X defines commands: C1 and C2 > > Application Y defines command: C3 and also re-uses C1 > > > > First of all, if application Y re-uses C1 it must be stated > > in the specification of application Y. >=20 > Agreed. >=20 > > If a DiameterIdentity advertises support for application X, > > it must support C1 and C2. C1 is used with app-id X. >=20 > Yes. >=20 > > If a DiameterIdentity advertises support for application Y, > > it must support C1 and C3. C1 is used with app-id Y. >=20 > This is where we disagree. C1 cannot use app-id Y unless=20 > application Y > changes the nature of the command by adding a requirement for a new > mandatory AVP. Otherwise it needs to use application X, as=20 > described in > RFC 3588. >=20 > > If a DiameterIdentity advertises support for application X and Y, it > > must support C1, C2, and C3. C1 can be used with app-id X and Y. >=20 > I disagree. C1 can only be used with app-id Y if another=20 > mandatory AVP is > defined. Otherwise, C1 can only be used with app-id X. >=20 From owner-aaa-wg@merit.edu Thu Jul 8 05:16:55 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 FAA08862 for ; Thu, 8 Jul 2004 05:16:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ADEAD9125D; Thu, 8 Jul 2004 05:16:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6314B9125E; Thu, 8 Jul 2004 05:16:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76E239125D for ; Thu, 8 Jul 2004 05:16:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 517DF5A356; Thu, 8 Jul 2004 05:16:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id BFA9F5A3F3 for ; Thu, 8 Jul 2004 05:16:32 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i689G7L24196; Thu, 8 Jul 2004 12:16:07 +0300 (EET DST) X-Scanned: Thu, 8 Jul 2004 12:15:38 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i689FcWp028180; Thu, 8 Jul 2004 12:15:38 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00jAQM0R; Thu, 08 Jul 2004 12:15:36 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i689FTn28968; Thu, 8 Jul 2004 12:15:29 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Jul 2004 12:15:25 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C464CC.1ADE81B9" Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Date: Thu, 8 Jul 2004 12:15:26 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D0298AA87@esebe016.ntc.nokia.com> Thread-Topic: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Thread-Index: AcRkK14LW4LvoP/CSJCNB/lUKKSl8wAoECqg From: To: , , Cc: , , X-OriginalArrivalTime: 08 Jul 2004 09:15:25.0872 (UTC) FILETIME=[1AC94300:01C464CC] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C464CC.1ADE81B9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mark, >=20 >> Ok, so now I am very glad I asked the question, since there seems to >> be a bunch of stuff here which is just not described properly. I'm >> happy to help with text though (if such changes can still be made), >> once we have a common understanding that makes sense. >=20 Nothing in practice could be changed. Since we are updating the draft according to IESG comments, it is perhaps possible to also clarify the text concerning this Service-Id stuff without changing the concept, that should work fine. >=20 >> Firstly, from the description below, Service-Identifier at the >> command level does not (necessarily) identify a unique service, but >> rather a class of services, with the specific service(s) being >> identified in MSCC. So then the text in various places about >> Service-Identifier being a 'unique identifier for a service' would >> need to be clarified.=20 >=20 No, how could you come to that conclusion? In my example the network access service (flow-bearer-Credit-Control@3gpp.org) uniquely identify the flow bearer service defined in a service specific document, doesn't identify a class of services. The service-id in MSCC identifies a specific content carried within the bearer service e.g. cnn-news@operator.example.com, which is again a unique service of which the identifier and e.g. associated 5-tuple are provisioned to the Service Element. In other word, the service-id at command level identifies a service specific document where rating AVPs are defined. =20 >=20 >> But it is not clear to me why this 'class' of services cannot be >> implicitly derived from the specific service identifiersm, or even >> that the server will do with this information. That is, the server >> can identify which information it needs to rate the service from the >> specific Service-Identifier (or Rating-Group) in the MSCC - what >> additional value does the command level Service-Identifier bring ? >=20 I have given explanation what the server does in some previous mail, but I repeat my self. Because the DCC doesn't define AVPs used for rating, since we cannot simply define these here as we don`t know all the possible present and future services, those are defined in service specific documents. To easy the task of the Server of determining whether it is able to determine the cost of a requested service (in the example above the flow bearer service) and avoid expensive rating operations before to discover that the request will be rejected, the server checks first the Service-Id at command level. If the Service-Id at command level is understood, the server continues the processing since it is sure it can properly operate, otherwise it immediately reject the request.=20 >=20 >> Furthermore, if you do have this command level Service-Identifier, >> and the client is trusted to set it correctly, then it is no greater >> leap of trust to trust the client to include the Mandatory AVPs that >> are associated with that Service-Identifier value! In the 3GPP >> example, the server knows that the client supports these AVPs from >> the Supported-Vendor-ID in the capability exchange. Sending the >> Service-Identifier value is like a message saying 'Please check I >> have also included AVPs X, Y and Z'! A wrongly implemented client >> might not send these AVPs, but more likely, a wrongly implemented >> client would not set the Service-Identifier either. >=20 Since in 3GPP you are defining many different services and many AVPs, the Supported-Vendor-Id doesn't tell you that the server supports IMS services, flow bearer charging, MMS services etc. etc.....unless you imply by default that advertising supported vendor 3GPP means that the server support all the set of AVPs defined in 3GPP, which is most likely not the case. And doesn`t tell what the client service is either. =20 >=20 >> Secondly, you are introducing the concept that a service may imply >> requirements as to additional mandatory AVPs that should accompany >> any request for a quota for that service. That's fine, but perhaps it >> should be explained. >=20 The concept was introduced in the mailing list probably half a year ago, it has been there for couple of WGLCs and for the IETF last call, a bit late to speak up isn`t it? This is explained by the way Clip Diameter credit control implementations are required to support the Mandatory rating AVPs defined in service specific documentation of the services they support according to the 'M' bit rules in [DIAMBASE].=20 Service specific documentation is basically identified by the Service-Id at command level. I`m aware of at least one case where this has been properly understood, but perhaps we need more clear text still :-( =20 Marco -----Original Message----- From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 07 July, 2004 17:04 To: Stura Marco (Nokia-NET/Helsinki); 'leena.mattila@ericsson.com'; = 'mgrayson@cisco.com' Cc: 'aaa-wg@merit.edu'; 'gwz@cisco.com'; Claire Mousset Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Hi Marco, =20 Ok, so now I am very glad I asked the question, since there seems to be = a bunch of stuff here which is just not described properly. I'm happy to = help with text though (if such changes can still be made), once we have = a common understanding that makes sense. =20 Firstly, from the description below, Service-Identifier at the command = level does not (necessarily) identify a unique service, but rather a = class of services, with the specific service(s) being identified in = MSCC. So then the text in various places about Service-Identifier being = a 'unique identifier for a service' would need to be clarified. =20 But it is not clear to me why this 'class' of services cannot be = implicitly derived from the specific service identifiersm, or even that = the server will do with this information. That is, the server can = identify which information it needs to rate the service from the = specific Service-Identifier (or Rating-Group) in the MSCC - what = additional value does the command level Service-Identifier bring ? =20 Furthermore, if you do have this command level Service-Identifier, and = the client is trusted to set it correctly, then it is no greater leap of = trust to trust the client to include the Mandatory AVPs that are = associated with that Service-Identifier value! In the 3GPP example, the = server knows that the client supports these AVPs from the = Supported-Vendor-ID in the capability exchange. Sending the = Service-Identifier value is like a message saying 'Please check I have = also included AVPs X, Y and Z'! A wrongly implemented client might not = send these AVPs, but more likely, a wrongly implemented client would not = set the Service-Identifier either. =20 Secondly, you are introducing the concept that a service may imply = requirements as to additional mandatory AVPs that should accompany any = request for a quota for that service. That's fine, but perhaps it should = be explained. =20 Regards...Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: 07 July 2004 14:10 To: Watson, Mark [MOP:EP10:EXCH]; leena.mattila@ericsson.com; = mgrayson@cisco.com Cc: aaa-wg@merit.edu; gwz@cisco.com; Mousset, Claire [ADC:8J70:EXCH] Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Hi, =20 some comment in line. =20 Marco -----Original Message----- From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 07 July, 2004 15:29 To: 'Leena Mattila (TU/LMF)'; 'Mark Grayson (mgrayson)'; Stura Marco = (Nokia-NET/Helsinki) Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Claire Mousset Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Hi Leena,=20 You wrote:=20 "- when using the MSCC the Service-ID on command level is the=20 main service, e.g. Network access, and the Service-Ids within=20 the MSCC then identify the sub-services within the main service"=20 This sounds very reasonable to me, but it is not what the specification = seems to imply. There is no concept in the spec of 'services' being = 'sub-ordinate' to other 'services'. Furthermore, the fact that a = 'service' is sub-ordinate to Rating-Group implies that everything within = a service has to be rated the same. So then even if there were = sub-services within a 'main service' they would all have to be within = the same Rating-Group!=20 But if people feel it's clear that there can be such a thing as a 'main = service' which is not part of any Rating Group and which has = sub-services, then that seems fine to me. =20 Mark, I guess you are referring to the picture in sect. 5.1.1. Right? If = so, this picture was intended to only describe the MSCC concept, what = Leena is mentioning is probably not visible in that picture. The main = service is a service of its own that represent for instance the bearer, = in which many other services may be carried and may have different = costs, and is not part of any RG. This 'main service' id also identifies = the service specific document with mandatory AVPs that need to be = supported, for instance the Flow bearer charging defined in 3GPP ideally = would have the 'main service' identifier something like = Flow-Bearer-Credit-Control@3gpp.org. Would you have good suggestion for better text in section 5.1.1 and = perhaps in the new 4.12 to remove any dubt?=20 As for (3), it doesn't seem a big deal, but does seem arbitrary - if I = want to request a quota for a single Rating-Group (which is probably the = most common case in 3GPP anyway) I need to use MSCC.=20 Right. ...Mark=20 -----Original Message-----=20 From: Leena Mattila (TU/LMF) [ mailto:leena.mattila@ericsson.com]=20 Sent: 07 July 2004 12:00=20 To: Watson, Mark [MOP:EP10:EXCH]; 'Mark Grayson (mgrayson)'; = 'marco.stura@nokia.com'=20 Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Mousset, Claire = [ADC:8J70:EXCH]=20 Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )=20 Hi,=20 when the MSCC concept was introduced I always had the assumption that = the services within the MSCC structure are=20 sub-ordinate to some higher level service, e.g. Network Access. Having = said that, it's also true that what one can do with MSCC one should be = able=20 to do with several messages (that's where the MSCC issue initially = started). However, I still believe that those several=20 messages are inter-related (otherwise you wouldn't group them=20 in the same message, right?), and thus the exact formulation=20 would be 'what one can do with MSCC one should be able to do=20 with sub-sessions'. Hence the analogy between the two approaches is:=20 - when using the MSCC the Service-ID on command level is the=20 main service, e.g. Network access, and the Service-Ids within=20 the MSCC then identify the sub-services within the main service=20 - when using sub-sessions the Service-ID in 'main' session is=20 the main service and the Service-Ids in sub-sessions (on=20 command level) are the sub-services.=20 If there is no common factor between the Service-IDs one has=20 grouped within one MSCC, then I think they should not be=20 grouped together at all, they are then clearly not sub-ordinate services = (e.g. not carried within the same bearer) and should=20 treat them as such - optimizing signaling=20 should not be the only justification for doing the grouping.=20 And when there is a common factor, that factor should become=20 the Service-ID on command level.=20 Regarding the question (3): I'll put it the other way around:=20 At the moment it's not possible to have rating groups on=20 command level but do you see a need for it?=20 Regards,=20 Leena=20 -----Original Message-----=20 From: owner-aaa-wg@merit.edu [ mailto:owner-aaa-wg@merit.edu]On Behalf = Of Mark Watson=20 Sent: 6. hein=E4kuuta 2004 19:21=20 To: 'Mark Grayson (mgrayson)'; 'marco.stura@nokia.com'=20 Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Claire Mousset=20 Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )=20 Hi Mark,=20 Note sure what you mean by a 'rating-root', but it is quite clear (e.g. = in the diagrams in 5.1.1) that 'services' are sub-ordinate to = Rating-Groups. Since everything in a Rating-Group is rated the same way = then certainly you cannot have things within a service which are rated = differently. That is, services are the finest level of granularity that = can be separately charged. The point of MSCC was to do in one message what could otherwise be done = with several messages and only command level values - so I would expect = the things appearing in the MSCC to have the same semantics as things = appearing at command level & for the two to be mutually exclusive - = hence Question 1 below. To answre my question (2) below for myself, we don't need multiple = instances of the same service within a single sub-session. In 3GPP, I = think we may have a requirement for dynamically povisioned services, but = the dynamic provisioning of these to DCC client & server is out of scope = here & so there should be no problem. ...Mark=20 -----Original Message-----=20 From: Mark Grayson (mgrayson) [ mailto:mgrayson@cisco.com]=20 Sent: 06 July 2004 16:44=20 To: Watson, Mark [MOP:EP10:EXCH]; marco.stura@nokia.com=20 Cc: aaa-wg@merit.edu; Glen Zorn (gwz); Mousset, Claire [ADC:8J70:EXCH]=20 Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )=20 Mark, Marco=20 I hadn't made the same assumption - but agree that there is ambiguity = here.=20 I had asumed that when present on the command level, the service-ID = refers to the "rating-root" which then needs to be common between client = and serer.=20 Then the issue exists with re-introducing the service-ID at the MSCC = level, now possibly below the sub-session-ID which I think is the cause = of the issue. IMO these AVPs at the MSCC level should be subordinate to = the service-ID on the command level. Cheers,=20 Mark=20 From: owner-aaa-wg@merit.edu [ mailto:owner-aaa-wg@merit.edu] On Behalf = Of Mark Watson=20 Sent: 06 July 2004 11:08=20 To: 'marco.stura@nokia.com'=20 Cc: 'aaa-wg@merit.edu'; Glen Zorn (gwz); Claire Mousset=20 Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: )=20 Hi Marco,=20 Some quick questions for clarification on this one...=20 1) If the client wants to request quotas for multiple services using the = Multiple-Services-Credit-Control AVP then what should it put in the = mandatory command level Service-Identifier AVP ? 2) Service-Identifier is finer granlarity than Rating-Group - that is = several services with unique Service-Identifiers are grouped within a = single Rating-Group. So a 'service' identified by a Service-Identifier = is basically the finest granularity thing that can be separately = charged. But then the definition of the Service Identifier AVP speaks of = statically configured or standardised values. To be consistent with the = above it would need to be a format or pattern than was = configured/standardised - e.g. if it's voice calls that you are charging = for then Service Identifies like 'voice001@blah.org', = 'voice002@blah.org' would be needed to distinguish between multiple = concurrent voice calls. Right ?=20 3) It isn't possible to request credit for a Rating-Group except by = using the Multiple-Services-Credit-Control AVP, right ? Regards...Mark=20 -----Original Message-----=20 From: marco.stura@nokia.com [ mailto:marco.stura@nokia.com]=20 Sent: 05 July 2004 09:09=20 To: gwz@cisco.com=20 Cc: aaa-wg@merit.edu=20 Subject: [AAA-WG]: RE:=20 Glen,=20 the Service-Id is only included in CCR message (at command level) to = indicate=20 to the server for what specific service the request is being issued. The = server checks first the Service-Id AVP and, if it doesn't recognize the = value of this AVP, it rejects the request without any further processing = (e.g. rating or what so ever). If the server recognizes the value of the = Service-Id AVP, it continues the processing and authorizes the credit if = possible (i.e. if there is enough credit in the user's account). =20 The section 4.1 has been restructured on request of IESG review as = follow, the inclusion of the Service-Id in CCR is mandatory. Whenever = the IESG and the ADs will agree that their comments have been properly = addressed, the draft 06 will be carried out and made available. Regards=20 Marco=20 4.1 Service-Specific Rating Input and Interoperability=20 =20 The Diameter Credit-Control Application defines the framework for = credit=20 control; it provides generic credit control mechanisms supporting = multiple=20 service applications. The Credit Control Application, therefore, does = not=20 define AVPs that could be used as input in the rating process. = Listing the=20 possible services that could use this Diameter application is seen as = out=20 of scope for this generic mechanism as well. =20 =20 Furthermore, it is reasonable to expect that there will exist a = service=20 level agreement between providers of the credit-control client and = the=20 credit-control server covering the charging, services offered, = roaming=20 agreements, agreed rating input (i.e. AVPs), etc.=20 Therefore, it is assumed that a Diameter credit control server will=20 provide service only for Diameter credit-control clients that have = agreed=20 beforehand the content of credit control messages. Protocol wise, it = is=20 naturally possible that any arbitrary Diameter credit-control client = can=20 interchange credit control messages with any Diameter credit control=20 server, but with a higher likelihood that unsupported services/AVPs = could=20 be present in the credit-control message causing the server to reject = the=20 request with an appropriate result-code.=20 =20 4.1.1 Specifying Rating Input AVPs=20 =20 There are two ways for providing rating input to the credit control=20 server, either by using AVPs or by including them in the Service-=20 Parameter-Info AVP. The general principles for sending rating = parameters=20 are:=20 =20 1a. The service SHOULD re-use existing AVPs, if the service can use = AVPs=20 defined in existing Diameter applications (e.g. NASREQ for = network=20 access services). Re-use of existing AVPs is strongly recommended = in=20 [DIAMBASE].=20 For AVPs of type Enumerated the service may require a new value = to be=20 defined. Allocation of new AVP values is done as specified in=20 [DIAMBASE], section 1.2.=20 =20 1b. New AVPs can be defined if the existing AVPs do not provide = sufficient=20 rating information. In such a case, the procedures defined in=20 [DIAMBASE] for creating new AVPs MUST be followed.=20 =20 1c. For services specific only to one vendor's implementation, a = Vendor-=20 Specific AVP code for Private use can be used. Where a = Vendor-Specific=20 AVP is implemented by more than one vendor, allocation of global = AVPs=20 are encouraged instead, refer to [DIAMBASE].=20 =20 2. The Service-Parameter-Info AVP MAY be used as a container to pass=20 legacy rating information in its original encoded form (e.g. ASN.1 = BER). This method can be used to avoid unnecessary data format=20 conversions from an existing format to an AVP format. In that case = the=20 rating input is embedded in the Service-Parameter-Info AVP as = defined=20 in section 8.42.=20 =20 New service applications SHOULD favor the use of explicitly defined = AVPs=20 as described in items 1a and 1b, to simplify interoperability. =20 =20 4.1.2 Application Support=20 =20 Since the Application-Id of the Diameter Credit Control Application = does=20 not uniquely identify the service being monitored, an additional = mechanism=20 is needed. The service application MUST be identified using the = Service-=20 Identifier AVP at command level. A server receiving a request for a=20 service application it does not support will reject the request as = defined=20 in sub-section 4.1.4. The Service-Identifier AVP MUST be a unique=20 identifier for a given service as defined in section 8.28. =20 =20 Thus, the combination of the Diameter Credit Control Application-Id = and=20 the Service-Identifier AVP in the Credit-Control-Request command = uniquely=20 defines the service within the context of the Diameter Credit = Control, and=20 hence provides interoperability between Diameter credit control = clients=20 and server.=20 =20 With this mechanism it is possible to cover additional service = specific=20 requirements as needed in other documents. However, introducing new = credit=20 control mechanisms to the framework defined in this specification, = require=20 definition of a new version of the Diameter Credit Control = Application and=20 corresponding Application Identifier.=20 =20 4.1.3 Service-Specific Documentation=20 =20 The service specific rating input AVPs, the contents of the Service-=20 Parameter-Info AVP or Service-Identifier AVP are not within the scope = of=20 this document. To facilitate interoperability, it is RECOMMENDED that = the=20 rating input and the values of the service identifiers are = coordinated via=20 an informational RFC or other permanent and readily available = reference=20 such as the specification of another cooperative standardization body = (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services = may=20 be deployed that are subject to agreements between providers of the = credit=20 control server and client, in this case vendor specific AVPs can be = used. =20 =20 This specification, together with the above service specific = documents,=20 governs the credit control message. The rule is that service specific = documents define what existing AVPs or new AVPs are used as input to = the=20 rating process (i.e. they do not define new credit control = applications),=20 and thus need to be included in the Credit-Control-Request command by = a=20 Diameter Credit Control Client supporting a given service as *[AVP].=20 Should Service-Parameter-Info be used, then the service specific = document=20 MUST specify the exact content of this grouped AVP.=20 =20 4.1.4 Handling of Unsupported/Incorrect Rating Input =20 =20 Diameter credit control implementations are required to support the=20 Mandatory rating AVPs defined in service specific documentation of = the=20 services they support according to the 'M' bit rules in [DIAMBASE]. =20 =20 In case a rating input required for the rating process is incorrect = in the=20 Credit control request, or the credit control server does not support = the=20 requested service (identified by the Service-Idntifier AVP at command = level), the Credit control answer MUST contain error code=20 DIAMETER_RATING_FAILED. A CCR message with this error MUST contain = one or=20 more Failed-AVP AVPs containing the missing and/or unsupported AVPs = that=20 caused the failure. A Diameter credit control client receiving error = code=20 DIAMETER_RATING_FAILED in answer to a request MUST NOT send such = similar=20 requests in the future.=20 =20 4.1.5 RADIUS Vendor-Specific Rating Attributes=20 =20 When service specific documents include RADIUS vendor specific = attributes=20 that could be used as input in the rating process, the rules = described in=20 [NASREQ] for formatting the Diameter AVP MUST be followed. For = example,=20 the AVP code used is the vendor attribute type code, the = Vendor-Specific=20 flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA = Vendor=20 identification value. The Diameter AVP data field contains only the=20 attribute value of the RADIUS attribute.=20 > -----Original Message-----=20 > From: owner-aaa-wg@merit.edu=20 > [ mailto:owner-aaa-wg@merit.edu]On Behalf Of=20 > ext Glen Zorn=20 > Sent: 02 July, 2004 20:27=20 > To: aaa-wg@merit.edu=20 > Subject:=20 >=20 >=20 > Description of issue: No guarantee of interoperability=20 > between CCA implementations=20 > Submitter name: Glen Zorn=20 > Submitter email address: gwz@cisco.com=20 > Date first submitted: 2 July 2004=20 > Document: dcca=20 > Comment type: T=20 > Priority: S=20 > Section: 4.1=20 > Rationale/Explanation of issue:=20 > In order to interoperate, Diameter peers implementing the=20 > Diameter Credit Control Application must agree upon both the=20 > application and the service (specified in the=20 > Service-Identifier AVP). However, the inclusion of the=20 > Service-Identifier in the CCR and CCA messages is optional.=20 >=20 > Lengthy description of problem:=20 > Section 4.1, para. 6 states "it is the combination of support=20 > of the Diameter Credit Control Application and the service=20 > defined in the Service-Identifier AVP, which defines=20 > interoperability between any given credit control client and=20 > server." However, the inclusion of the Service-Identifier in=20 > the CCR and CCA messages is optional. This gives rise to a=20 > situation where two peers implementing the same application=20 > may not interoperate because they do not implement the same=20 > "service", and further, refuse to clearly communicate that fact.=20 >=20 > Requested change:=20 > Change section 4.1, paragraph 5 from=20 >=20 > This specification, together with service specific documents, is=20 > governing the credit control message. The rule is that service=20 > specific documents only define what existing AVPs or new AVPs are=20 > used as input to the rating process (i.e. they do not define new=20 > credit control applications), and thus need to be included in the=20 > Credit-Control-Request command by a Diameter Credit Control Client=20 > supporting a given service as *[AVP]. In order to define new AVPs,=20 > service specific documents MUST follow the practices defined in=20 > [DIAMBASE]. The service SHOULD be identified using the Service-=20 > Identifier AVP. The Service-Identifier AVP MUST be a unique=20 > identifier for a given service as defined in section 8.28.=20 >=20 > to=20 >=20 > This specification, together with service specific documents, is=20 > governing the credit control message. The rule is that service=20 > specific documents only define what existing AVPs or new AVPs are=20 > used as input to the rating process (i.e. they do not define new=20 > credit control applications), and thus need to be included in the=20 > Credit-Control-Request command by a Diameter Credit Control Client=20 > supporting a given service as *[AVP]. In order to define new AVPs,=20 > service specific documents MUST follow the practices defined in=20 > [DIAMBASE]. The service MUST be identified using the Service-=20 > Identifier AVP. The Service-Identifier AVP MUST be a unique=20 > identifier for a given service as defined in section 8.28.=20 >=20 > ~gwz=20 >=20 > "They that can give up essential liberty to obtain a little=20 > temporary safety deserve neither..."=20 > -- Benjamin Franklin, 1759=20 >=20 >=20 > "It is forbidden to kill; therefore all murderers are=20 > punished unless they kill in large numbers and to the sound=20 > of trumpets."=20 > -- Voltaire=20 >=20 >=20 ------_=_NextPart_001_01C464CC.1ADE81B9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message

Hi Mark,
>
>> Ok, so now I am very = glad I asked=20 the question, since there seems to
>> be a bunch of stuff here = which is=20 just not described properly. I'm
>> happy to help with text = though (if=20 such changes can still be made),
>> once we have a common = understanding=20 that makes sense.
>
Nothing in practice could be changed. = Since we are=20 updating the draft
according to IESG
comments, it is perhaps = possible to=20 also clarify the text concerning
this Service-Id stuff
without = changing=20 the concept, that should work fine.
>
>> Firstly, from = the=20 description below, Service-Identifier at the
>> command level = does not=20 (necessarily) identify a unique service, but
>> rather a class = of=20 services, with the specific service(s) being
>> identified in = MSCC. So=20 then the text in various places about
>> Service-Identifier = being a=20 'unique identifier for a service' would
>> need to be = clarified.=20
>
No, how could you come to that conclusion? In my example = the=20 network
access service (flow-bearer-Credit-Control@3gpp.org)=20 uniquely
identify the flow bearer service defined in a service=20 specific
document, doesn't identify a class of services. The = service-id=20 in
MSCC identifies a specific content carried within the bearer=20 service
e.g. cnn-news@operator.example.com, which is again a unique=20 service
of which the identifier and e.g. associated 5-tuple are=20 provisioned
to the Service Element. In other word, the service-id at=20 command
level identifies a service specific document where rating = AVPs=20 are
defined.      
> =
>> But it=20 is not clear to me why this 'class' of services cannot be
>> = implicitly=20 derived from the specific service identifiersm, or even
>> that = the=20 server will do with this information. That is, the server
>> = can=20 identify which information it needs to rate the service from = the
>>=20 specific Service-Identifier (or Rating-Group) in the MSCC - = what
>>=20 additional value does the command level Service-Identifier bring = ?
>
I=20 have given explanation what the server does in some previous = mail,
but I=20 repeat my self. Because the DCC doesn't define AVPs used for
rating, = since we=20 cannot simply define these here as we don`t know all
the possible = present and=20 future services, those are defined in
service specific documents. To = easy the=20 task of the Server of
determining whether it is able to determine the = cost of=20 a requested
service (in the example above the flow bearer service) = and=20 avoid
expensive rating operations before to discover that the request = will
be rejected, the server checks first the Service-Id at command=20 level.
If the Service-Id at command level is understood, the=20 server
continues the processing since it is sure it can properly=20 operate,
otherwise it immediately reject the request.
> =
>>=20 Furthermore, if you do have this command level = Service-Identifier,
>>=20 and the client is trusted to set it correctly, then it is no = greater
>>=20 leap of trust to trust the client to include the Mandatory AVPs = that
>>=20 are associated with that Service-Identifier value! In the = 3GPP
>>=20 example, the server knows that the client supports these AVPs = from
>>=20 the Supported-Vendor-ID in the capability exchange. Sending = the
>>=20 Service-Identifier value is like a message saying 'Please check = I
>>=20 have also included AVPs X, Y and Z'! A wrongly implemented = client
>>=20 might not send these AVPs, but more likely, a wrongly = implemented
>>=20 client would not set the Service-Identifier either.
>
Since in = 3GPP=20 you are defining many different services and many AVPs,
the=20 Supported-Vendor-Id doesn't tell you that the server supports = IMS
services,=20 flow bearer charging, MMS services etc. etc.....unless you
imply by = default=20 that advertising supported vendor 3GPP means that
the server support = all the=20 set of AVPs defined in 3GPP, which is most
likely not the case. And = doesn`t=20 tell what the client service is
either.      =
>
>> Secondly, you are introducing the concept that a = service=20 may imply
>> requirements as to additional mandatory AVPs that = should=20 accompany
>> any request for a quota for that service. That's = fine, but=20 perhaps it
>> should be explained.
>
The concept was=20 introduced in the mailing list probably half a year
ago, it has = been
there=20 for couple of WGLCs and for the IETF last call, a bit late to
speak = up isn`t=20 it?
This is explained by the way

Clip

    Diameter = credit control=20 implementations are required to support the
    = Mandatory=20 rating AVPs defined in service specific documentation = of
   =20 the services they support according to the 'M' bit rules in
   [DIAMBASE]. =

Service=20 specific documentation is basically identified by the
Service-Id at = command=20 level. I`m aware of at least one case where
this has been properly=20 understood, but perhaps we need more clear
text still :-(   =

Marco

-----Original Message-----
From: ext Mark Watson=20 [mailto:mwatson@nortelnetworks.com]
Sent: 07 July, 2004=20 17:04
To: Stura Marco (Nokia-NET/Helsinki);=20 'leena.mattila@ericsson.com'; 'mgrayson@cisco.com'
Cc:=20 'aaa-wg@merit.edu'; 'gwz@cisco.com'; Claire Mousset
Subject: = RE: DCC=20 Service-Identifier (was RE: [AAA-WG]: RE: )

Hi=20 Marco,
 
Ok, so now I am very glad I asked the question, since there = seems to be=20 a bunch of stuff here which is just not described properly. I'm happy = to help=20 with text though (if such changes can still be made), once we have a = common=20 understanding that makes sense.
 
Firstly, from the description below, Service-Identifier at = the command=20 level does not (necessarily) identify a unique service, but rather a = class of=20 services, with the specific service(s) being identified in MSCC. So = then the=20 text in various places about Service-Identifier being a 'unique = identifier for=20 a service' would need to be clarified.
 
But it is not clear to me why this 'class' = of=20 services cannot be implicitly derived from the specific service=20 identifiersm, or even that the server = will do=20 with this information.=20 That is, the server can = identify=20 which information it needs to rate the service from the specific=20 Service-Identifier (or Rating-Group) in the MSCC - what additional = value does=20 the command level Service-Identifier bring = ?
 
Furthermore, if you do have this = command level=20 Service-Identifier, and the client is trusted to set it correctly, = then it is=20 no greater leap of trust to trust the client to include the Mandatory = AVPs=20 that are associated with that Service-Identifier value! In the 3GPP example, the server knows that the client supports = these AVPs=20 from the Supported-Vendor-ID in the capability exchange. = Sending the=20 Service-Identifier value is like a message saying 'Please check I have = also=20 included AVPs X, Y and Z'! A wrongly=20 implemented client might not send these AVPs, but more likely, a = wrongly=20 implemented client would not set the Service-Identifier=20 either.
 
Secondly, you are introducing the concept that a service may = imply=20 requirements as to additional mandatory AVPs that should accompany any = request=20 for a quota for that service. That's fine, but perhaps it should be=20 explained.
 
Regards...Mark
-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: 07=20 July 2004 14:10
To: Watson, Mark [MOP:EP10:EXCH];=20 leena.mattila@ericsson.com; mgrayson@cisco.com
Cc:=20 aaa-wg@merit.edu; gwz@cisco.com; Mousset, Claire=20 [ADC:8J70:EXCH]
Subject: RE: DCC Service-Identifier (was = RE:=20 [AAA-WG]: RE: )

Hi,
 
some comment in line.
 
Marco
-----Original Message-----
From: ext Mark = Watson=20 [mailto:mwatson@nortelnetworks.com]
Sent: 07 July, 2004=20 15:29
To: 'Leena Mattila (TU/LMF)'; 'Mark Grayson = (mgrayson)';=20 Stura Marco (Nokia-NET/Helsinki)
Cc: 'aaa-wg@merit.edu'; = 'Glen=20 Zorn (gwz)'; Claire Mousset
Subject: RE: DCC = Service-Identifier=20 (was RE: [AAA-WG]: RE: )

Hi Leena,

You wrote:

"- when using the MSCC the Service-ID on command = level is=20 the
main service, e.g. Network access, = and the=20 Service-Ids within
the MSCC then = identify the=20 sub-services within the main service"

This sounds very reasonable to me, but it is not = what the=20 specification seems to imply. There is no concept in the spec of=20 'services' being 'sub-ordinate' to other 'services'. Furthermore, = the fact=20 that a 'service' is sub-ordinate to Rating-Group implies that = everything=20 within a service has to be rated the same. So then even if there = were=20 sub-services within a 'main service' they would all have to be = within the=20 same Rating-Group! 

 But if people=20 feel it's clear that there can be such a thing as a 'main service' = which=20 is not part of any Rating Group and which has sub-services, then = that=20 seems fine to me.  

Mark, I guess you=20 are referring to the picture in sect. 5.1.1. Right? If so, this = picture=20 was intended to only describe the MSCC concept, what Leena is = mentioning=20 is probably not visible in that picture. The main = service is a=20 service of its own that represent for instance the bearer, in = which many=20 other services may be carried and may have different costs, and is = not=20 part of any RG. This 'main service' id also identifies = the=20 service specific document with mandatory AVPs that need to be = supported,=20 for instance the Flow bearer charging defined in 3GPP ideally = would have the 'main service' identifier something like Flow-Bearer-Credit-Co= ntrol@3gpp.org.

Would = you have=20 good suggestion for better text in section 5.1.1 and perhaps in = the new=20 4.12 to remove any dubt?

As for (3), it doesn't seem a big deal, but does = seem=20 arbitrary - if I want to request a quota for a single Rating-Group = (which=20 is probably the most common case in 3GPP anyway) I need to use = MSCC. 

Right.

...Mark

-----Original Message-----
From:=20 Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.= com]=20
Sent: 07 July 2004 12:00 =
To: Watson, Mark [MOP:EP10:EXCH]; 'Mark Grayson = (mgrayson)';=20 'marco.stura@nokia.com'
Cc: = 'aaa-wg@merit.edu';=20 'Glen Zorn (gwz)'; Mousset, Claire [ADC:8J70:EXCH] =
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: = RE: )=20


Hi,

when the MSCC concept was introduced I always = had the=20 assumption that the services within the MSCC structure are=20
sub-ordinate to some higher level = service, e.g.=20 Network Access. Having said that, it's also true that what one can = do with=20 MSCC one should be able

to do with several messages (that's where the = MSCC issue=20 initially started). However, I still believe that those several=20

messages are inter-related (otherwise you = wouldn't group=20 them
in the same message, right?), and = thus the=20 exact formulation
would be 'what one can = do with=20 MSCC one should be able to do
with = sub-sessions'.=20 Hence the analogy between the two approaches is:
-=20 when using the MSCC the Service-ID on command level is the=20
main service, e.g. Network access, and = the=20 Service-Ids within
the MSCC then = identify the=20 sub-services within the main service
- = when using=20 sub-sessions the Service-ID in 'main' session is
the main service and the Service-Ids in sub-sessions (on=20
command level) are the = sub-services.=20
If there is no common factor between the = Service-IDs one=20 has
grouped within one MSCC, then I = think they=20 should not be
grouped together at all, = they are=20 then clearly not sub-ordinate services (e.g. not carried within = the same=20 bearer) and should

treat them as such - optimizing signaling =
should not be the only justification for doing the = grouping.=20
And when there is a common factor, that = factor=20 should become
the Service-ID on command=20 level.

Regarding the question (3): I'll put it the = other way=20 around:
At the moment it's not possible = to have=20 rating groups on
command level but do = you see a=20 need for it?

Regards,
Leena =

-----Original Message-----
From:=20 owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]= On=20 Behalf Of Mark Watson
Sent: 6. = hein=E4kuuta 2004=20 19:21
To: 'Mark Grayson (mgrayson)';=20 'marco.stura@nokia.com'
Cc: = 'aaa-wg@merit.edu';=20 'Glen Zorn (gwz)'; Claire Mousset
Subject: RE: DCC=20 Service-Identifier (was RE: [AAA-WG]: RE: )


Hi Mark,

Note sure what you mean by a 'rating-root', but = it is=20 quite clear (e.g. in the diagrams in 5.1.1) that 'services' are=20 sub-ordinate to Rating-Groups. Since everything in a Rating-Group = is rated=20 the same way then certainly you cannot have things within a = service which=20 are rated differently. That is, services are the finest level of=20 granularity that can be separately charged.

The point of MSCC was to do in one message what = could=20 otherwise be done with several messages and only command level = values - so=20 I would expect the things appearing in the MSCC to have the same = semantics=20 as things appearing at command level & for the two to be = mutually=20 exclusive - hence Question 1 below.

To answre my question (2) below for myself, we = don't need=20 multiple instances of the same service within a single = sub-session. In=20 3GPP, I think we may have a requirement for dynamically povisioned = services, but the dynamic provisioning of these to DCC client = & server=20 is out of scope here & so there should be no = problem.

...Mark
-----Original=20 Message-----
From: Mark Grayson = (mgrayson) [mailto:mgrayson@cisco.com]=20
Sent: 06 July 2004 16:44 =
To: Watson, Mark [MOP:EP10:EXCH]; = marco.stura@nokia.com=20
Cc: aaa-wg@merit.edu; Glen Zorn (gwz); Mousset, = Claire=20 [ADC:8J70:EXCH]
Subject: RE: DCC=20 Service-Identifier (was RE: [AAA-WG]: RE: )


Mark, Marco

I hadn't made the same assumption - but agree = that there=20 is ambiguity here.

I had asumed that when present on the command = level, the=20 service-ID refers to the "rating-root" which then needs to be = common=20 between client and serer.

Then the issue exists with re-introducing the = service-ID=20 at the MSCC level, now possibly below the sub-session-ID which I = think is=20 the cause of the issue. IMO these AVPs at the MSCC level should be = subordinate to the service-ID on the command level.

Cheers,
Mark=20




From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]= On=20 Behalf Of Mark Watson
Sent: 06 July 2004 = 11:08
To: 'marco.stura@nokia.com' =
Cc: 'aaa-wg@merit.edu'; Glen Zorn (gwz); Claire = Mousset=20
Subject: DCC Service-Identifier (was RE: = [AAA-WG]: RE:=20 )


Hi Marco,
Some quick = questions for=20 clarification on this one...
1) If the = client=20 wants to request quotas for multiple services using the=20 Multiple-Services-Credit-Control AVP then what should it put in = the=20 mandatory command level Service-Identifier AVP ?

2) Service-Identifier is finer granlarity than=20 Rating-Group - that is several services with unique = Service-Identifiers=20 are grouped within a single Rating-Group. So a 'service' = identified by a=20 Service-Identifier is basically the finest granularity thing that = can be=20 separately charged. But then the definition of the Service = Identifier AVP=20 speaks of statically configured or standardised values. To be = consistent=20 with the above it would need to be a format or pattern than was=20 configured/standardised - e.g. if it's voice calls that you are = charging=20 for then Service Identifies like 'voice001@blah.org', = 'voice002@blah.org'=20 would be needed to distinguish between multiple concurrent voice = calls.=20 Right ?

3) It isn't possible to request credit for a = Rating-Group=20 except by using the Multiple-Services-Credit-Control AVP, right ?=20 Regards...Mark


-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20
Sent: 05 July 2004 09:09 =
To: gwz@cisco.com
Cc: = aaa-wg@merit.edu=20
Subject: [AAA-WG]: RE:


Glen,
the Service-Id = is only=20 included in CCR message (at command level) to indicate =
to the server for what specific service the request is = being=20 issued. The server checks first the Service-Id AVP and, if it = doesn't=20 recognize the value of this AVP, it rejects the request without = any=20 further processing (e.g. rating or what so ever). If the server = recognizes=20 the value of the Service-Id AVP, it continues the processing and=20 authorizes the credit if possible (i.e. if there is enough credit = in the=20 user's account). 

The section 4.1 has been restructured on request = of IESG=20 review as follow, the inclusion of the Service-Id in CCR is = mandatory.=20 Whenever the IESG and the ADs will agree that their comments have = been=20 properly addressed, the draft 06 will be carried out and made = available.=20 Regards

Marco
4.1 = Service-Specific Rating=20 Input and Interoperability
   =20
   The Diameter Credit-Control = Application defines the framework for credit
   control; it provides generic credit control = mechanisms=20 supporting multiple
   service = applications. The Credit Control Application, therefore, does not=20
   define AVPs that could be = used as=20 input in the rating process. Listing the
   possible services that could use this = Diameter=20 application is seen as out
   = of scope=20 for this generic mechanism as well. 
   
   = Furthermore, it is reasonable to expect that there will exist a = service=20
   level agreement between = providers of=20 the credit-control client and the
  =20 credit-control server covering the charging, services offered, = roaming=20
   agreements, agreed rating = input (i.e.=20 AVPs), etc.
   Therefore, it = is assumed=20 that a Diameter credit control server will
   provide service only for Diameter = credit-control=20 clients that have agreed
   = beforehand=20 the content of credit control messages. Protocol wise, it is=20
   naturally possible that any = arbitrary=20 Diameter credit-control client can
  =20 interchange credit control messages with any Diameter credit = control=20
   server, but with a higher = likelihood=20 that unsupported services/AVPs could
  =20 be present in the credit-control message causing the server to = reject the=20
   request with an appropriate = result-code.
    =
4.1.1 Specifying Rating Input AVPs
   
   = There are=20 two ways for providing rating input to the credit control =
   server, either by using AVPs or by including = them in=20 the Service-
   Parameter-Info = AVP. The=20 general principles for sending rating parameters
   are:
   =20
   1a. The service SHOULD = re-use=20 existing AVPs, if the service can use AVPs
       defined in existing = Diameter=20 applications (e.g. NASREQ for network
       access services). = Re-use of=20 existing AVPs is strongly recommended in
       [DIAMBASE]. =
       For AVPs of type = Enumerated=20 the service may require a new value to be
       defined. Allocation = of new AVP=20 values is done as specified in
       [DIAMBASE], section = 1.2.=20
   
   1b. New AVPs can be defined if the existing = AVPs do=20 not provide sufficient
       rating information. = In such a=20 case, the procedures defined in
       [DIAMBASE] for = creating new=20 AVPs MUST be followed.
   =20
   1c. For services specific = only to one=20 vendor's implementation, a Vendor-
       Specific AVP code = for Private=20 use can be used. Where a Vendor-Specific
       AVP is implemented = by more=20 than one vendor, allocation of global AVPs
       are encouraged = instead, refer=20 to [DIAMBASE].
    =
   2. The Service-Parameter-Info AVP MAY be = used as a=20 container to pass
     =20 legacy rating information in its original encoded form (e.g. ASN.1 =
      BER). = This method=20 can be used to avoid unnecessary data format
      conversions from an = existing format=20 to an AVP format. In that case the
      rating input is embedded = in the=20 Service-Parameter-Info AVP as defined
      in section 8.42. =
   
   = New service=20 applications SHOULD favor the use of explicitly defined AVPs=20
   as described in items 1a = and 1b, to=20 simplify interoperability. 
   
4.1.2 = Application=20 Support
    =
   Since the Application-Id of the Diameter = Credit=20 Control Application does
   = not uniquely=20 identify the service being monitored, an additional mechanism=20
   is needed. The service = application=20 MUST be identified using the Service-
  =20 Identifier AVP at command level. A server receiving a request for = a=20
   service application it does = not=20 support will reject the request as defined
   in sub-section 4.1.4. The Service-Identifier = AVP MUST=20 be a unique
   identifier for = a given=20 service as defined in section 8.28. 
   
   = Thus, the=20 combination of the Diameter Credit Control Application-Id and=20
   the Service-Identifier AVP = in the=20 Credit-Control-Request command uniquely
   defines the service within the context of = the Diameter=20 Credit Control, and
   hence = provides=20 interoperability between Diameter credit control clients =
   and server.
   =20
   With this mechanism it is = possible to=20 cover additional service specific
  =20 requirements as needed in other documents. However, introducing = new credit=20
   control mechanisms to the = framework=20 defined in this specification, require
   definition of a new version of the Diameter = Credit=20 Control Application and
   = corresponding=20 Application Identifier.
   =20
4.1.3 Service-Specific Documentation=20
     =
   The service specific rating input AVPs, the = contents=20 of the Service-
   = Parameter-Info AVP or=20 Service-Identifier AVP are not within the scope of =
   this document. To facilitate = interoperability, it is=20 RECOMMENDED that the
   rating = input and=20 the values of the service identifiers are coordinated via =
   an informational RFC or other permanent and = readily=20 available reference
   such as = the=20 specification of another cooperative standardization body =
   (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. = However,=20 private services may
   be = deployed that=20 are subject to agreements between providers of the credit =
   control server and client, in this case = vendor=20 specific AVPs can be used. 
        =
   This specification, together with the above = service=20 specific documents,
   governs = the=20 credit control message. The rule is that service specific =
   documents define what existing AVPs or new = AVPs are=20 used as input to the
   rating = process=20 (i.e. they do not define new credit control applications),=20
   and thus need to be = included in the=20 Credit-Control-Request command by a
  =20 Diameter Credit Control Client supporting a given service as = *[AVP].=20
   Should = Service-Parameter-Info be=20 used, then the service specific document
   MUST specify the exact content of this = grouped AVP.=20
   
4.1.4=20 Handling of Unsupported/Incorrect Rating Input  =
   
   = Diameter=20 credit control implementations are required to support the=20
   Mandatory rating AVPs = defined in=20 service specific documentation of the
  =20 services they support according to the 'M' bit rules in = [DIAMBASE]. =20
       =20
   In case a rating input = required for=20 the rating process is incorrect in the
   Credit control request, or the credit = control server=20 does not support the
   = requested=20 service (identified by the Service-Idntifier AVP at command=20
   level), the Credit control = answer=20 MUST contain error code
  =20 DIAMETER_RATING_FAILED. A CCR message with this error MUST contain = one or=20
   more Failed-AVP AVPs = containing the=20 missing and/or unsupported AVPs that
  =20 caused the failure. A Diameter credit control client receiving = error code=20
   DIAMETER_RATING_FAILED in = answer to a=20 request MUST NOT send such similar
  =20 requests in the future.
   =20
4.1.5 RADIUS Vendor-Specific Rating = Attributes=20
       =20
   When service specific = documents=20 include RADIUS vendor specific attributes
   that could be used as input in the rating = process, the=20 rules described in
   [NASREQ] = for=20 formatting the Diameter AVP MUST be followed. For example,=20
   the AVP code used is the = vendor=20 attribute type code, the Vendor-Specific
   flag MUST be set to 1 and the Vendor-ID MUST = be set to=20 the IANA Vendor
   = identification value.=20 The Diameter AVP data field contains only the
   attribute value of the RADIUS attribute.=20
> -----Original Message----- =
> From: owner-aaa-wg@merit.edu
> [mailto:owner-aaa-wg@merit.edu]= On=20 Behalf Of
> ext Glen Zorn =
> Sent: 02 July, 2004 20:27
> To:=20 aaa-wg@merit.edu
> Subject: =
>
>
>=20 Description of issue:  No guarantee of = interoperability=20
> between CCA implementations =
> Submitter name: Glen Zorn
>=20 Submitter email address: gwz@cisco.com
> Date=20 first submitted: 2 July 2004
> = Document: dcca=20
> Comment type: T
>=20 Priority: S
> Section: 4.1 =
> Rationale/Explanation of issue:
>=20 In order to interoperate, Diameter peers implementing the =
> Diameter Credit Control Application must agree upon = both the=20
> application and the service = (specified in the=20
> Service-Identifier AVP).  = However, the=20 inclusion of the
> Service-Identifier = in the=20 CCR and CCA messages is optional.
>=20
> Lengthy description of = problem:=20
> Section 4.1, para. 6 states "it is the = combination=20 of support
> of the Diameter Credit = Control=20 Application and the service
> defined = in the=20 Service-Identifier AVP, which defines
>=20 interoperability between any given credit control client and=20
> server."  However, the = inclusion of the=20 Service-Identifier in
> the CCR and = CCA=20 messages is optional.  This gives rise to a
> situation where two peers implementing the same = application=20
> may not interoperate because they = do not=20 implement the same
> "service", and = further,=20 refuse to clearly communicate that fact.
>=20
> Requested change:
> Change section 4.1, paragraph 5 from =
>
>    = This=20 specification, together with service specific documents, is=20
>    governing the = credit=20 control message. The rule is that service
>    specific documents only define = what existing=20 AVPs or new AVPs are
>    used=20 as input to the rating process (i.e. they do not define new=20
>    credit control=20 applications), and thus need to be included in the =
>    Credit-Control-Request command by = a Diameter=20 Credit Control Client
>   =20 supporting a given service as *[AVP]. In order to define new AVPs, =
>    service specific = documents=20 MUST follow the practices defined in
>    [DIAMBASE]. The service SHOULD be = identified=20 using the Service-
>   =20 Identifier AVP. The Service-Identifier AVP MUST be a unique=20
>    identifier for a = given=20 service as defined in section 8.28.
> =
> to
>=20
>    This = specification,=20 together with service specific documents, is
>    governing the credit control = message. The=20 rule is that service
>   =20 specific documents only define what existing AVPs or new AVPs are=20
>    used as input to = the rating=20 process (i.e. they do not define new
>    credit control applications), and = thus need=20 to be included in the
>   =20 Credit-Control-Request command by a Diameter Credit Control Client =
>    supporting a = given service=20 as *[AVP]. In order to define new AVPs,
>    service specific documents MUST = follow the=20 practices defined in
>   =20 [DIAMBASE]. The service MUST be identified using the Service-=20
>    Identifier AVP. = The=20 Service-Identifier AVP MUST be a unique
>    identifier for a given service as = defined in=20 section 8.28.
>
>=20 ~gwz
>
> = "They that=20 can give up essential liberty to obtain a little
> temporary safety deserve neither..." =
> -- Benjamin Franklin, 1759
>=20
>
> "It = is forbidden=20 to kill; therefore all murderers are
> punished=20 unless they kill in large numbers and to the sound =
> of trumpets."
> -- = Voltaire=20
>
>=20

------_=_NextPart_001_01C464CC.1ADE81B9-- From owner-aaa-wg@merit.edu Thu Jul 8 07:36: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 HAA14984 for ; Thu, 8 Jul 2004 07:36:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4DCF59125E; Thu, 8 Jul 2004 07:36:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B48D9125F; Thu, 8 Jul 2004 07:36:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C4A599125E for ; Thu, 8 Jul 2004 07:36:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A9A9C5A481; Thu, 8 Jul 2004 07:36:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by segue.merit.edu (Postfix) with ESMTP id 0C50159FBF for ; Thu, 8 Jul 2004 07:36:31 -0400 (EDT) Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i68BaQ828584 for ; Thu, 8 Jul 2004 13:36:27 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Jul 2004 13:36:24 +0200 Message-ID: From: "Claire Mousset" To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC usage of CCR final on ASR Date: Thu, 8 Jul 2004 13:36:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C464DF.CD5D1772" 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_01C464DF.CD5D1772 Content-Type: text/plain Hello, In looking at the DCC usage together with Diameter base, I have a question on whether the STR usage (as described in 8.5 of RFC 3588) is effectively replaced by a CCR final. If the server receives a CCR final, then it knows to take down the session, so what purpose does the STR serve? It is a completely wasted message. What I would like is to clarify that the following sequence is valid with DCC: If an Abort-Session-Request is received from the server, the client responds with an Abort-Session-Answer, then provides the Final User Units in a Credit Control Request message (Termination), then the user session can be terminated when the Answer is received back from the server. No STR needed for this case. Comments? Many thanks, Claire. ------_=_NextPart_001_01C464DF.CD5D1772 Content-Type: text/html Content-Transfer-Encoding: quoted-printable DCC usage of CCR final on ASR

Hello,

In looking at the DCC usage together = with Diameter base, I have a question on whether the STR usage (as = described in 8.5 of RFC 3588) is effectively replaced by a CCR = final. If the server receives a = CCR final, then it knows to take down the session, so what purpose does = the STR serve? It is a completely wasted message.

What I would like is to clarify that = the following sequence is valid with DCC:

If an Abort-Session-Request is = received from the server, the client responds with an = Abort-Session-Answer, then provides the Final User Units in a Credit = Control Request message (Termination), then the user session can be = terminated when the Answer is received back from the server.

No STR needed for this case.

Comments?

Many thanks,

Claire.

------_=_NextPart_001_01C464DF.CD5D1772-- From owner-aaa-wg@merit.edu Thu Jul 8 10:00: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 KAA22159 for ; Thu, 8 Jul 2004 10:00:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5F7FA9122B; Thu, 8 Jul 2004 09:59:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D2069122E; Thu, 8 Jul 2004 09:59:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3F8E69122B for ; Thu, 8 Jul 2004 09:59:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2E2DB59AF0; Thu, 8 Jul 2004 09:59:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id A5E035989D for ; Thu, 8 Jul 2004 09:59:57 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i68DwQP13739; Thu, 8 Jul 2004 06:58:26 -0700 Date: Thu, 8 Jul 2004 06:58:26 -0700 (PDT) From: Bernard Aboba To: mikko.aittola@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage In-Reply-To: <9B95641F3AE80F4C8CD5B288FE8C9631AAB001@esebe012.ntc.nokia.com> Message-ID: References: <9B95641F3AE80F4C8CD5B288FE8C9631AAB001@esebe012.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > In my opinion, Application-Id can > be used for multiplexing between software modules, just like any other > information in the messages. The point is that Application-Id *alone* can't be used this way in all cases. You need something like a combination of Application-Id and command to do the multiplexing. > I would also like to note that Application-Id can be used for > routing messages between peers. RFC 3588 is clear on that part, yes. From owner-aaa-wg@merit.edu Thu Jul 8 16:38: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 QAA26903 for ; Thu, 8 Jul 2004 16:38:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D604591234; Thu, 8 Jul 2004 16:38:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A3A5491236; Thu, 8 Jul 2004 16:38:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 710F891234 for ; Thu, 8 Jul 2004 16:38:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5EA5459D57; Thu, 8 Jul 2004 16:38:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ns2.bln1.siemens.de (ns2.bln1.siemens.de [194.138.127.35]) by segue.merit.edu (Postfix) with ESMTP id 860AD59D3F for ; Thu, 8 Jul 2004 16:38:38 -0400 (EDT) Received: from ns-srv-2.bln1.siemens.de (stbf7654 [194.138.127.67]) by ns2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id i68KcQRC012170 for ; Thu, 8 Jul 2004 22:38:26 +0200 (MEST) Received: from blnss10a.bln1.siemens.de (blnss10a.bln1.siemens.de [194.138.127.102]) by ns-srv-2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id i68KcKTS012787 for ; Thu, 8 Jul 2004 22:38:21 +0200 (MEST) Received: by blnss10a.bln1.siemens.de with Internet Mail Service (5.5.2657.72) id <3GBNATJ4>; Thu, 8 Jul 2004 22:38:21 +0200 Message-ID: <445C57B81208C24EAD99F2944DBB9D29073F0F59@blnss10a.bln1.siemens.de> From: Schendel Jens ICM Berlin To: aaa-wg@merit.edu Subject: [AAA-WG]: DCCA 05: missing Failed-AVP? Date: Thu, 8 Jul 2004 22:38:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi all, just one question: section 4.1 says that Failed-AVP is to be used if result code DIAMETER_RATING_FAILED was applied. However, I cannot find the Failed-AVP in the ABNF grammar in section 3.2. Should it be fixed? Sorry, if I overlooked something or in case this issue has already been addressed. Section 4.1 In case a rating input required for the rating process is incorrect in the Credit control request, or the credit control server does not support the requested service, the Credit control answer MUST contain error code DIAMETER_RATING_FAILED. A CCR message with this error MUST contain one or more Failed-AVP AVPs containing the missing and/or unsupported AVPs that caused the failure. A Diameter credit control client receiving error code DIAMETER_RATING_FAILED in answer to a request MUST NOT send such similar requests in the future. I further guess that there is a typing error in the text above Modification in section 4.1 from error code DIAMETER_RATING_FAILED. A CCR message with this error MUST to error code DIAMETER_RATING_FAILED. A CCA message with this error MUST Modification in section 3.2 Add * [ Failed-AVP ] Regards Jens From owner-aaa-wg@merit.edu Fri Jul 9 02:15: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 CAA04526 for ; Fri, 9 Jul 2004 02:15:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 96FE49126A; Fri, 9 Jul 2004 02:15:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 533E49126C; Fri, 9 Jul 2004 02:15:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B632F9126A for ; Fri, 9 Jul 2004 02:15:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 51BE559EB5; Fri, 9 Jul 2004 02:15:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id B56D35A01A for ; Fri, 9 Jul 2004 02:15:09 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i696F3WR016387 for ; Fri, 9 Jul 2004 08:15:03 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 Jul 2004 08:15:03 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <3236R6B2>; Fri, 9 Jul 2004 08:15:03 +0200 Message-ID: From: "Leena Mattila (TU/LMF)" To: "'Schendel Jens ICM Berlin'" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA 05: missing Failed-AVP? Date: Fri, 9 Jul 2004 08:15:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 09 Jul 2004 06:15:03.0794 (UTC) FILETIME=[12BCF520:01C4657C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Jens, This is obviously a bug. Good catch, thanks. BR, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf = Of Schendel Jens ICM Berlin Sent: 8. hein=E4kuuta 2004 23:38 To: aaa-wg@merit.edu Subject: [AAA-WG]: DCCA 05: missing Failed-AVP? Hi all, just one question: section 4.1 says that Failed-AVP is to be used if = result code DIAMETER_RATING_FAILED was applied. However, I cannot find the Failed-AVP in the ABNF grammar in section = 3.2. Should it be fixed? Sorry, if I overlooked something or in case this issue has already been = addressed. Section 4.1 In case a rating input required for the rating process is incorrect=20 in the Credit control request, or the credit control server does not = support the requested service, the Credit control answer MUST = contain=20 error code DIAMETER_RATING_FAILED. A CCR message with this error = MUST=20 contain one or more Failed-AVP AVPs containing the missing and/or=20 unsupported AVPs that caused the failure. A Diameter credit control=20 client receiving error code DIAMETER_RATING_FAILED in answer to a=20 request MUST NOT send such similar requests in the future. =20 I further guess that there is a typing error in the text above Modification in section 4.1 from error code DIAMETER_RATING_FAILED. A CCR message with this error = MUST=20 to=20 error code DIAMETER_RATING_FAILED. A CCA message with this error = MUST=20 Modification in section 3.2=20 Add * [ Failed-AVP ] Regards=20 Jens From owner-aaa-wg@merit.edu Fri Jul 9 03:35: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 DAA08701 for ; Fri, 9 Jul 2004 03:35:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 426D4912BC; Fri, 9 Jul 2004 03:35:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D32CB912B4; Fri, 9 Jul 2004 03:35:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8A8BE912A6 for ; Fri, 9 Jul 2004 03:35:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6CA1F5A1A7; Fri, 9 Jul 2004 03:35:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id A18055A136 for ; Fri, 9 Jul 2004 03:35:38 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i697ZaB28469; Fri, 9 Jul 2004 10:35:37 +0300 (EET DST) X-Scanned: Fri, 9 Jul 2004 10:34:45 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i697YjtT023435; Fri, 9 Jul 2004 10:34:45 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00JPNYgu; Fri, 09 Jul 2004 10:34:44 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i697Ygn23844; Fri, 9 Jul 2004 10:34:42 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 9 Jul 2004 10:34:25 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 9 Jul 2004 10:34:24 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46587.287F1140" Subject: RE: [AAA-WG]: DCC usage of CCR final on ASR Date: Fri, 9 Jul 2004 10:34:24 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B05C3@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC usage of CCR final on ASR Thread-Index: AcRk5CG4FqkMxZFJTHW4rlt6y3Yx8gAonClg From: To: Cc: X-OriginalArrivalTime: 09 Jul 2004 07:34:24.0991 (UTC) FILETIME=[28A1F6F0:01C46587] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C46587.287F1140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments in line. =20 Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Claire Mousset Sent: 08 July, 2004 14:36 To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC usage of CCR final on ASR Hello,=20 In looking at the DCC usage together with Diameter base, I have a = question on whether the STR usage (as described in 8.5 of RFC 3588) is = effectively replaced by a CCR final. If the server receives a CCR final, = then it knows to take down the session, so what purpose does the STR = serve? It is a completely wasted message.=20 CCR termination is used in DCC to the credit control server. STR is used = to the AAA server in case you have a service specific = authorization/authentication session with the AAA server.=20 What I would like is to clarify that the following sequence is valid = with DCC:=20 If an Abort-Session-Request is received from the server, the client = responds with an Abort-Session-Answer, then provides the Final User = Units in a Credit Control Request message (Termination), then the user = session can be terminated when the Answer is received back from the = server.=20 Right.=20 No STR needed for this case.=20 Comments?=20 Many thanks,=20 Claire.=20 ------_=_NextPart_001_01C46587.287F1140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DCC usage of CCR final on ASR
Comments in line.
 
Marco
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Claire=20 Mousset
Sent: 08 July, 2004 14:36
To:=20 aaa-wg@merit.edu
Subject: [AAA-WG]: DCC usage of CCR final = on=20 ASR

Hello,

In looking at the DCC usage together = with Diameter=20 base, I have a question on whether the STR usage (as described in 8.5 = of RFC=20 3588) is effectively replaced by a CCR final. If the server receives a CCR final, then it knows to take = down the=20 session, so what purpose does the STR serve? It is a completely wasted = message. 

CCR termination is used in DCC to the credit control=20 server. STR is used to the AAA server in case you have a = service=20 specific authorization/authentication session with the AAA=20 server. 

What I would like is to clarify that = the following=20 sequence is valid with DCC:

If an Abort-Session-Request is = received from=20 the server, the client responds with an Abort-Session-Answer, then = provides=20 the Final User Units in a Credit Control Request message = (Termination), then=20 the user session can be terminated when the Answer is received back = from the=20 server. 

Right. 

No STR needed for this case. =

Comments?

Many thanks,

Claire. =

------_=_NextPart_001_01C46587.287F1140-- From owner-aaa-wg@merit.edu Fri Jul 9 05:47: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 FAA14081 for ; Fri, 9 Jul 2004 05:47:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1B3DB912A6; Fri, 9 Jul 2004 05:46:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DCB63912B4; Fri, 9 Jul 2004 05:46:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BEBFC912A6 for ; Fri, 9 Jul 2004 05:46:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A7F3D59E05; Fri, 9 Jul 2004 05:46:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id DDFD35A19C for ; Fri, 9 Jul 2004 05:46:44 -0400 (EDT) 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 i699kdB17002; Fri, 9 Jul 2004 12:46:39 +0300 (EET DST) X-Scanned: Fri, 9 Jul 2004 12:46:12 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i699kCIT008523; Fri, 9 Jul 2004 12:46:12 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00GOgfvS; Fri, 09 Jul 2004 12:46:10 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i699Jkn27308; Fri, 9 Jul 2004 12:19:46 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 9 Jul 2004 12:19:31 +0300 Message-ID: <40EE6323.8020804@nokia.com> Date: Fri, 09 Jul 2004 12:19:31 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: AAA mailing list , Mari Carmen belinchon , Miguel-Angel Pallares , "ext Carolina Canales (ML/EEM)" , Pete McCann , Rajaniemi Jaakko Matti , Tammi Kalle Tapani Subject: [AAA-WG]: Diameter SIP app -03 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2004 09:19:31.0331 (UTC) FILETIME=[D7811530:01C46595] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi: I have just submitted a new version of the Diameter SIP application. While the document appears in the typical repository, you can download a copy from: http://people.nokia.net/~miguel/drafts/draft-ietf-aaa-diameter-sip-app-03.txt http://people.nokia.net/~miguel/drafts/draft-ietf-aaa-diameter-sip-app-03.html The list of changes: 14.1 Changes in draft-ietf-aaa-diameter-sip-app-03.txt from -02.txt o A Diameter Subscriber Locator was either a Diameter Relay or a Diameter Redirect node. We have removed the Diameter Relay functionality, since Diameter relays will not relay CER/CEA messages, thus, a Diameter client will never be able to determine which Diameter applications are running in a given Diameter server. So a Diameter Subscriber Locator is implemented as a Diameter redirect node. o Section "Registration termination" has been rewritten. Now the procedures speak about SIP soft state management, rather than SIP registration, so this procedures are applicable to SIP event subscriptions as well. A discussion on how to couple Diameter user sessions with SIP soft states is also added o Added a new Digest-Expected-Response AVP that allows the Diameter server to send a pre-calculated expected digest response to the Diameter client. This is only applicable to the case when the SIP UA does not use client nounces. o The Authentication Details Section has been updated with the latest details of the authentication process. Regards, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Sat Jul 10 09:26: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 JAA13288 for ; Sat, 10 Jul 2004 09:26:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6855091205; Sat, 10 Jul 2004 09:26:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2FEDC91206; Sat, 10 Jul 2004 09:26:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3549891205 for ; Sat, 10 Jul 2004 09:26:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1710B5A406; Sat, 10 Jul 2004 09:26:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps06s.nortelnetworks.com (zrtps06s.nortelnetworks.com [47.140.48.50]) by segue.merit.edu (Postfix) with ESMTP id 232D05A3CB for ; Sat, 10 Jul 2004 09:26:03 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i6ADPlX15197; Sat, 10 Jul 2004 09:25:47 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 10 Jul 2004 09:25:48 -0400 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371FA2F21@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Ahmad Muhanna" , "'marco.stura@nokia.com'" , "Satheesh Maddireddi" , "'mgrayson@cisco.com'" Cc: "'Harri.Hakala@ericsson.com'" , "'Leena.Mattila@ericsson.com'" , "'juha-pekka.koskinen@nokia.com'" , "'john.loughney@nokia.com'" , "'aaa-wg@merit.edu'" , "'peter.zackrisson@ericsson.com'" Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Date: Sat, 10 Jul 2004 09:25:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46681.622011A6" 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_01C46681.622011A6 Content-Type: text/plain Hi Marco, The more I think about this issue the more I believe that it needs to be addressed properly in the draft before it becomes a standard. Let us assume that SLA covers the Tariff change functionality. Since Tariff change is not a mandatory functionality on the DCC client, it is quite very possible that the support of this functionality is being CONFIGURABLE on the access side. This means that there is a room for human error of not enabling Tariff Change functionality while it is REQUIRED. In this case, I believe a service provider will never be alerted to what happens to their customers until issue is escalated and produced many unsatisfied customers. My other point is, that every protocol SHALL provide a reliable mechanism for error handling which I believe DCC is lacking with respect to this issue. Now: I am not sure why it is so difficult to include a new error code to resolve this issue and make this DCC protocol more robust.? I am sure it is not the lack of space for a new error code. Regards, Ahmad -----Original Message----- From: Muhanna, Ahmad [RICH2:2Q30:EXCH] Sent: Wednesday, June 09, 2004 7:58 AM To: 'marco.stura@nokia.com'; Maddireddi, Satheesh [RICH2:2Q40:EXCH]; mgrayson@cisco.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu; peter.zackrisson@ericsson.com Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi Marco, comments inline.. Regards, Ahmad -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Wednesday, June 09, 2004 7:43 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; Maddireddi, Satheesh [RICH2:2Q40:EXCH]; mgrayson@cisco.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu; peter.zackrisson@ericsson.com Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi Ahmad, it seems you didn't get my point. What is indicated in the draft is that SLA is expected to cover bla bla bla...., and this should be enough other options are not needed. Finally, the only changes allowed at this point are major bug fixing and your proposal doesn't fall within this category. So, new termination causes will not be added in this DCC version unless explicitely requested by IESG. [A.M.] I still believe a new cause value is a much better choice and needed. But, if it is too late at this point, let us hope that IESG request that otherwise, we can forget about it. Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Ahmad Muhanna Sent: 09 June, 2004 15:10 To: Stura Marco (Nokia-NET/Helsinki); Satheesh Maddireddi; mgrayson@cisco.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; Koskinen Juha-Pekka (Nokia-NET/Tampere); Loughney John (Nokia-NRC/Helsinki); aaa-wg@merit.edu; peter.zackrisson@ericsson.com Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, Please see comments inline. Regards, Ahmad -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Wednesday, June 09, 2004 5:26 AM To: Maddireddi, Satheesh [RICH2:2Q40:EXCH]; Muhanna, Ahmad [RICH2:2Q30:EXCH]; mgrayson@cisco.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu; peter.zackrisson@ericsson.com Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, I think what really happen is that the user signs a contract with a service provider, often referred as subscription. The contract typically states the pricing structure for the services, including tariff time changes, when and where certain conditions are applicable etc. Therefore, whether tariff time changes are applicable when roaming to a given visited network, should be known as well since this may have legal implications (i.e. you cannot sell to a user that the access costs $1/MB from 6am to 6 pm and $0.5/MB from 6pm to 6 am if not sure that tariff change is supported. Presumably you cannot sell that the effective cost of the service has dependencies on whether tariff change is supported in the visited network either. So, you have to know it beforehand.). Introducing additional protocol functionalities such as new termination cause etc. won't help in that respect, since in most cases the server won't accept to change the billing model agreed beforehand with the user, the service will most likely be denied in any case. [A.M.] I agree. Please see comments below. We have a paragraph in section 4.1 that is supposed to cover this interoperability issues, basically the option 2 listed by Ahmad. Clip It is reasonable to expect that there will exist a service level agreement between providers of the credit control client and the credit control server covering the charging, services offered, roaming agreements, agreed rating input, etc. [A.M.] I think this probably enough to cover the static configuration portion of it. "covering the charging" basically refers to the charging model, therefore includes such things as the tariff changes and charging type (e.g. volume, time etc.) too. We thought that it was better choice to group all this interoperability stuff in one section rather than repeating the same text for all the optional features along the document, there is nothing left to individual interpretation or assumptions as Ahmad appears to believe. That said, the draft passed couple of WG last calls, the AD review and is now in the IESG review. So, IESG officially frowns upon changes except in extreme cases (i.e. major bugs). What you are pointing out, as discussed above, I don't believe is a bug at all and that is reasonable to expect SLA is mentioned in section 4.1. [A.M.] Agreed. I believe the cause value should be changed to a specific one and not so generic. I do not think it is too late to propose a new cause value as "tariff change not supported". It is more descriptive and much more helpful for collecting proper OM at both ends; the server and client. Mark Grayson wrote >well at least there seems to be some inconsistency with optional MSCC which then has support explicitly indicated by the client. The MSCC is a bit different case. Who decide at the origin to multiplex services in the same credit control session is actually the client, while the tariff-change is server driven. The reason of indicating MSCC support in the initial CCR, is to indicate to the server "I want to multiplex services that may be subject to different cost in the same session". The server may reject the request because it doesn't support the feature (Failed AVP included in the response), in such a case the client still have the option to open a credit control session for each of the requested services. As discussed above this won't be effective in case of tariff-changes, all would happen is that the server would reject the request if the client indicates "tariff change not supported" since you cannot change the beforehand agreed charging model with the user. [A.M.] please see comments above. Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Satheesh Maddireddi Sent: 09 June, 2004 05:40 To: Ahmad Muhanna; Stura Marco (Nokia-NET/Helsinki); peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; Koskinen Juha-Pekka (Nokia-NET/Tampere); Loughney John (Nokia-NRC/Helsinki); aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, I agree with Ahmad we should have a specific reason for the failing the MSCC in case if the client doesn't support the Tariff-Time-Change AVP as the the server will not be able to interpret the failure as it may be because of the GSU unit types OR the tariff change AVP will have to retry at most 2 times to understand the meaning of failure reason. (Need a new failure cause). Regarding mandating the Tariff-Time-Change AVP server always has an option to include a mandatory AVP Validity-Time for the client to trigger reauth as the server wants. Regards, Satheesh -----Original Message----- From: Muhanna, Ahmad [RICH2:2Q30:EXCH] Sent: Tuesday, June 08, 2004 9:08 AM To: 'marco.stura@nokia.com'; peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, please see comments inline. Regards, Ahmad -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Tuesday, June 08, 2004 8:35 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, I think the Peter answer indicated that this is not a problem. [A.M.] Apparently and based on my comment to Peter, I disagree. Indeed, who decide the billing model is the server in the home network and not the client in the visited network, this was already discussed in the mailing list a while ago. If the server sent a tariff-time-change in the answer is because it requires this model, perhaps it has also contractual implications with the user if the model is broken, and therefore it is correct for the client to reject the answer if it doesn't support the tariff-time-change mechanism. It is up to the server to eventually track that the origin-host X rejected an answer with Tariff-Time-Change AVP and at the next attempt change the billing model if possible. However, typically an agreement between DCC-Client and server exist and the server can control whether to send the tariff-time-change or not. [A.M.] I think we are drafting a standard that needs not to leave anything for individual interpretation or assumptions. Also, to avoid any IOT problem, we need to make this clear in the standard. I see you just proposed a couple of options: 1. Some sort of dynamic configuration based on DCC Server tracking DCC clients support for Tariff-Time-Change. The only problem I see here is how the server would know that the client does not support Tariff-Time-Change while the cause value in the Temination-Cause AVP is set to a generic one "DIAMETER_BAD_ANSWER" 2. Static configuration at the DCC Server based on "agreement between DCC-Client and DCC Server" I may also add another straight forward one, 3. Mandate the support for the Tariff-Time-Change mechanism on the DCC server and DCC Client. Is there any other options that the group may think applicable to this issue? Ahmad Marco -----Original Message----- From: ext Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com] Sent: 08 June, 2004 15:51 To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu Cc: 'Harri.Hakala@ericsson.com'; 'Leena.Mattila@ericsson.com'; Koskinen Juha-Pekka (Nokia-NET/Tampere); Stura Marco (Nokia-NET/Helsinki); Loughney John (Nokia-NRC/Helsinki); Ahmad Muhanna Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change So far the only comment received is from Peter. Does this mean that every one agrees that this is a problem that needs to be fixed. If so, what do you think the solution should be? Regards, Ahmad -----Original Message----- From: Muhanna, Ahmad [RICH2:2Q30:EXCH] Sent: Friday, June 04, 2004 8:59 AM To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Thanks Peter, Is it fair to say that your argument is based on the assumption that all DCC Servers are always aware of all DCC clients capabilities with respect to Tariff-Time-Change mechanism support. Thanks again. Regards, Ahmad -----Original Message----- From: Peter Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com] Sent: Friday, June 04, 2004 8:48 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change I think the DCC specification is correct regarding the tariff change mechanism. If a DCC client does not support the tariff change mechanism the DCC server must use a charging model towards that client that is not based on time, which means that Tariff-Time-Change is not to be sent. This means that it is up to the DCC server to be able to control if Tariff-Time-Change should be sent or not. If you have a charging model saying that the price for e.g. volume will be different between 8 and 18 o'clock the clients will have to support tariff change mechanism. It is a very bad idea if some clients are allowed to break the charging model (instead the charging model should be changed). / Peter -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Ahmad Muhanna Sent: den 4 juni 2004 15:15 To: aaa-wg@merit.edu Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; 'John.Loughney@nokia.com' Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi all, According to the DCC draft under section 5.1, support of Tariff-Time-Change is optional by the DCC client and Server. " The Diameter credit-control server and client MAY optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. " On the other hand and under the same section, it mandates the DCC client which does not support this functionality to terminate the DCC session if it receives a CCA with Tariff-Time-Change AVP included. Under section 5.1, it reads: " 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. " The problem I see is the following: There is a very good possibility that a DCC server supports Tariff-Time-Change and DCC Client does not. This may cause a denial of service for an end-user which home Diameter CC server supports Tariff-Time-Change mechanism while it is at an access where DCC client does not. Am I making sense here? Your thoughts please. Thanks, Ahmad ------_=_NextPart_001_01C46681.622011A6 Content-Type: text/html Message
Hi Marco,
 
The more I think about this issue the more I believe that it needs to be addressed properly in the draft before it becomes a standard.
Let us assume that SLA covers the Tariff change functionality.
 
Since Tariff change is not a mandatory functionality on the DCC client, it is quite very possible that the support of this functionality is being CONFIGURABLE on the access side. This means that there is a room for human error of not enabling Tariff Change functionality while it is REQUIRED. In this case, I believe a service provider will never be alerted to what happens to their customers until issue is escalated and produced many unsatisfied customers.
 
My other point is, that every protocol SHALL provide a reliable mechanism for error handling which I believe DCC is lacking with respect to this issue.
 
Now: I am not sure why it is so difficult to include a new error code to resolve this issue and make this DCC protocol more robust.?
I am sure it is not the lack of space for a new error code.

Regards,
Ahmad

-----Original Message-----
From: Muhanna, Ahmad [RICH2:2Q30:EXCH]
Sent: Wednesday, June 09, 2004 7:58 AM
To: 'marco.stura@nokia.com'; Maddireddi, Satheesh [RICH2:2Q40:EXCH]; mgrayson@cisco.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu; peter.zackrisson@ericsson.com
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi Marco,
comments inline..

Regards,
Ahmad

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Wednesday, June 09, 2004 7:43 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; Maddireddi, Satheesh [RICH2:2Q40:EXCH]; mgrayson@cisco.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu; peter.zackrisson@ericsson.com
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi Ahmad,
 
it seems you didn't get my point.  What is indicated in the draft is that SLA is expected to cover bla bla bla...., and this should be enough
other options are not needed.
 
Finally, the only changes allowed at this point are major bug fixing and your proposal doesn't fall within this category. So, new termination
causes will not be added in this DCC version unless explicitely requested by IESG. 
 
[A.M.]
I still believe a new cause value is a much better choice and needed.
But, if it is too late at this point, let us hope that IESG request that otherwise, we can forget about it.
 
Regards
Marco
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Ahmad Muhanna
Sent: 09 June, 2004 15:10
To: Stura Marco (Nokia-NET/Helsinki); Satheesh Maddireddi; mgrayson@cisco.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; Koskinen Juha-Pekka (Nokia-NET/Tampere); Loughney John (Nokia-NRC/Helsinki); aaa-wg@merit.edu; peter.zackrisson@ericsson.com
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
Please see comments inline.

Regards,
Ahmad

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Wednesday, June 09, 2004 5:26 AM
To: Maddireddi, Satheesh [RICH2:2Q40:EXCH]; Muhanna, Ahmad [RICH2:2Q30:EXCH]; mgrayson@cisco.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu; peter.zackrisson@ericsson.com
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
 
I think what really happen is that the user signs a contract with a service provider, often referred as subscription.
The contract typically states the pricing structure for the services, including tariff time changes, when and where
certain conditions are  applicable etc. Therefore, whether tariff time changes are applicable when roaming to a
given visited network, should be known as well since this may have legal implications (i.e. you cannot sell to
a user that the access costs $1/MB from 6am to 6 pm and $0.5/MB from 6pm to 6 am if not sure that
tariff change is supported. Presumably you cannot sell that the effective cost of the service has dependencies
on whether tariff change is supported in the visited network either. So, you have to know it beforehand.). Introducing
additional protocol functionalities such as new termination cause etc. won't help in that respect, since in most
cases the server won't accept to change the billing model agreed beforehand with the user, the service will most
likely be denied in any case.
 
[A.M.]
I agree.
Please see comments below.
 
We have a paragraph in section 4.1 that is supposed to cover this interoperability issues, basically the option 2
listed by Ahmad.
 
Clip

   It is reasonable to expect that there will exist a service level
   agreement between providers of the credit control client and the
   credit control server covering the charging, services offered,
   roaming agreements, agreed rating input, etc.
     
[A.M.]
I think this probably enough to cover the static configuration portion of it.
 
"covering the charging" basically refers to the charging model, therefore includes such things as the tariff changes and
charging type (e.g. volume, time etc.) too. We thought that it was better choice to group all this interoperability stuff in
one section rather than repeating the same text for all the optional features along the document, there is nothing left to
individual interpretation or assumptions as Ahmad appears to believe.
 
That said, the draft passed couple of WG last calls, the AD review and is now in the IESG review. So, IESG officially frowns
upon changes except in extreme cases (i.e. major bugs). What you are pointing out, as discussed above, I don't believe
is a bug at all and that is reasonable to expect SLA is mentioned in section 4.1. 
 
[A.M.]
Agreed.
I believe the cause value should be changed to a specific one and not so generic.
I do not think it is too late to propose a new cause value as "tariff change not supported".
It is more descriptive and much more helpful for collecting proper OM at both ends; the server and client. 
 
Mark Grayson wrote
 
>well at least there seems to be some inconsistency with optional MSCC which then has support explicitly indicated by the client.
 
The MSCC is a bit different case. Who decide at the origin to multiplex services in the same credit control session is actually
the client, while the tariff-change is server driven. The reason of indicating MSCC support in the initial CCR, is to indicate to
the server "I want to multiplex services that may be subject to different cost in the same session". The server may reject the
request because it doesn't support the feature (Failed AVP included in the response), in such a case the client still have the
option to open a credit control session for each of the requested services. As discussed above this won't be effective in case
of tariff-changes, all would happen is that the server would reject the request if the client indicates "tariff change not supported"
since you cannot change the beforehand agreed charging model with the user. 
 
[A.M.]
please see comments above. 
 
Regards
Marco
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Satheesh Maddireddi
Sent: 09 June, 2004 05:40
To: Ahmad Muhanna; Stura Marco (Nokia-NET/Helsinki); peter.zackrisson@ericsson.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; Koskinen Juha-Pekka (Nokia-NET/Tampere); Loughney John (Nokia-NRC/Helsinki); aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
 
I agree with Ahmad we should have a specific reason for the failing the MSCC in case if the client doesn't support the Tariff-Time-Change AVP
as the the server will not be able to interpret the failure as it may be because of  the GSU unit types OR the tariff change AVP will have to retry
at most 2 times to understand the meaning of failure reason. (Need a new failure cause). Regarding mandating the Tariff-Time-Change AVP
server always has an option to include a mandatory AVP Validity-Time for the client to trigger reauth as the server wants.
 
Regards,
Satheesh

 -----Original Message-----
From: Muhanna, Ahmad [RICH2:2Q30:EXCH]
Sent: Tuesday, June 08, 2004 9:08 AM
To: 'marco.stura@nokia.com'; peter.zackrisson@ericsson.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
please see comments inline.

Regards,
Ahmad

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Tuesday, June 08, 2004 8:35 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; peter.zackrisson@ericsson.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
 
I think the Peter answer indicated that this is not a problem. 
 
[A.M.]
Apparently and based on my comment to Peter, I disagree. 
 
Indeed, who decide the billing model is the server in the home network and not the client in the
visited network, this was already discussed in the mailing list a while ago.
If the server sent a tariff-time-change in the answer is because it requires this model, perhaps
it has also contractual implications with the user if the model is broken, and therefore it is correct for
the client to reject the answer if it doesn't support the tariff-time-change mechanism.
 
It is up to the server to eventually track that the origin-host X rejected an answer with Tariff-Time-Change AVP
and at the next attempt change the billing model if possible. However, typically an agreement between
DCC-Client and server exist and the server can control whether to send the tariff-time-change or not. 
 
[A.M.] 
I think we are drafting a standard that needs not to leave anything for individual interpretation or assumptions. Also, to avoid any IOT problem, we need to make this clear in the standard.
I see you just proposed a couple of options:
1. Some sort of dynamic configuration based on DCC Server tracking DCC clients support for Tariff-Time-Change.
The only problem I see here is how the server would know that the client does not support Tariff-Time-Change while the cause value in the Temination-Cause AVP is set to a generic one "DIAMETER_BAD_ANSWER"
2. Static configuration at the DCC Server based on "agreement between DCC-Client and DCC Server"
 
I may also add another straight forward one,
3. Mandate the support for the Tariff-Time-Change mechanism on the DCC server and DCC Client.
 
Is there any other options that the group may think applicable to this issue?
 
Ahmad
 
Marco
 
-----Original Message-----
From: ext Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com]
Sent: 08 June, 2004 15:51
To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu
Cc: 'Harri.Hakala@ericsson.com'; 'Leena.Mattila@ericsson.com'; Koskinen Juha-Pekka (Nokia-NET/Tampere); Stura Marco (Nokia-NET/Helsinki); Loughney John (Nokia-NRC/Helsinki); Ahmad Muhanna
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

So far the only comment received is from Peter.
Does this mean that every one agrees that this is a problem that needs to be fixed.
If so, what do you think the solution should be?

Regards,
Ahmad

-----Original Message-----
From: Muhanna, Ahmad [RICH2:2Q30:EXCH]
Sent: Friday, June 04, 2004 8:59 AM
To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Thanks Peter,
 
Is it fair to say that your argument is based on the assumption that all DCC Servers are always aware of all DCC clients capabilities with respect to Tariff-Time-Change mechanism support.
 
Thanks again.

Regards,
Ahmad

-----Original Message-----
From: Peter Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com]
Sent: Friday, June 04, 2004 8:48 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

I think the DCC specification is correct regarding the tariff change mechanism.
 
If a DCC client does not support the tariff change mechanism the DCC server must use a charging model towards that client that is not based on time,
which means that Tariff-Time-Change is not to be sent.
This means that it is up to the DCC server to be able to control if Tariff-Time-Change should be sent or not.
If you have a charging model saying that the price for e.g. volume will be different between 8 and 18 o'clock the clients will have to support
tariff change mechanism.
It is a very bad idea if some clients are allowed to break the charging model (instead the charging model should be changed).
 
/ Peter
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Ahmad Muhanna
Sent: den 4 juni 2004 15:15
To: aaa-wg@merit.edu
Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; 'John.Loughney@nokia.com'
Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi all,

According to the DCC draft under section 5.1, support of Tariff-Time-Change is optional by the DCC client and Server.

"
   The Diameter credit-control server and client MAY optionally support
   a tariff change mechanism. The Diameter credit-control server may
   include a Tariff-Time-Change AVP in the answer message.
"

On the other hand and under the same section, it mandates the DCC client which does not support this functionality to terminate the DCC session if it receives a CCA with Tariff-Time-Change AVP included.

Under section 5.1, it reads:
"
   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.
"

The problem I see is the following:
There is a very good possibility that a DCC server supports Tariff-Time-Change and DCC Client does not.
This may cause a denial of service for an end-user which home Diameter CC server supports Tariff-Time-Change mechanism while it is at an access where DCC client does not.

Am I making sense here?
Your thoughts please.


Thanks,
Ahmad

------_=_NextPart_001_01C46681.622011A6-- From owner-aaa-wg@merit.edu Mon Jul 12 05:36: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 FAA25322 for ; Mon, 12 Jul 2004 05:36:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DB9979124A; Mon, 12 Jul 2004 05:36:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4DC079124D; Mon, 12 Jul 2004 05:36:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D6ABA9124A for ; Mon, 12 Jul 2004 05:36:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD0695A15D; Mon, 12 Jul 2004 05:36:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id CCE185A0AD for ; Mon, 12 Jul 2004 05:36:18 -0400 (EDT) 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 i6C9aHo20569 for ; Mon, 12 Jul 2004 12:36:17 +0300 (EET DST) X-Scanned: Mon, 12 Jul 2004 12:34:21 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6C9YLEo031790 for ; Mon, 12 Jul 2004 12:34:21 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00SHWU5F; Mon, 12 Jul 2004 12:34:20 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6C9YJn15968 for ; Mon, 12 Jul 2004 12:34:19 +0300 (EET DST) Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 12 Jul 2004 12:34:18 +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: FW: [AAA-WG]: Issue 464: Application-Id Usage Date: Mon, 12 Jul 2004 12:34:18 +0300 Message-ID: <9B95641F3AE80F4C8CD5B288FE8C9631C1B5F8@esebe012.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 464: Application-Id Usage Thread-Index: AcRk4BItrScNmS7lSzuM/FprKXTsWwDEu0Nw From: To: X-OriginalArrivalTime: 12 Jul 2004 09:34:18.0995 (UTC) FILETIME=[67D51C30:01C467F3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, John Prudhoe asked to forward the message below. BR, Mikko -----Original Message----- From: ext John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: 08 July, 2004 14:38 To: Aittola Mikko (Nokia-NET/Tampere) Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage Hi Mikko,=20 I attempted to post the following reply to your e-mail, but was unable = to send it via the AAA-WG. Please feel free to forward it or comment on = it in the discussion.=20 Regards,=20 John.=20 PS It seems that there's a reverse DNS lookup on incoming e-mails to the = AAA-WG, whereas my e-mail will have gone out from a local mail server in = Ireland rather than the corporate one that shows up in a DNS lookup. = I've already sent an e-mail to the postmaster @merit.edu about it.=20 ----- Forwarded by John Prudhoe/Vodafone on 08/07/2004 12:31 -----=20 John Prudhoe=20 08/07/2004 12:11=20 To: aaa-wg@merit.edu, owner-aaa-wg@merit.edu=20 cc: =20 Subject: RE: [AAA-WG]: Issue 464: Application-Id = UsageLink Hi Mikko,=20 It seems to me quite reasonable that someone would really want to do = what you describe in your e-mail.=20 Imagine if application X supports a number of commands and someone = determines that one of these commands is unsuitable for their purposes, = let's call it C2 to fit in with your example.=20 In my scenario, the reason for defining application Y is to deliberately = replace C2 with a new command, C3. The other commands of application X = would still be wanted. So it is not just a case of wanting to use all = the commands of application X with application Y except C2 which is = superfluous, but a case of specifically wanting to exclude C2 because = the new command C3 replaces it.=20 It seems to me that this is a reasonable scenario and it would be better = to have a simple and elegant means of supporting it. Failing that, = there would still be a need to support it somehow. At the moment there = doesn't seem to be any means of making use of the suitable commands = defined by App-X without also allowing the unwanted command C2.=20 Regards,=20 John.=20 =20 =20 Sent by: owner-aaa-wg@merit.edu=20 08/07/2004 09:02=20 =20 To: =20 cc: =20 Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage > This is where we disagree. C1 cannot use app-id Y unless=20 > application Y changes the nature of the command by adding a = requirement > for a new mandatory AVP. Otherwise it needs to use application X, as > described in RFC 3588. Well, I think a mandatory AVP could well be added to fulfill this = requirement, but I think avoiding the implementation of Application X is a good = enough reason to change the app-id for C1 if the command is re-used in the context of Application Y. If app-id X must be used with C1 it means that the peer must also = advertise support for Application X, and that means that it must also implement C2 and everything else for that application. That's way too much trouble if you only really want to implement a peer that supports Application Y. BTW, I agree Base Protocol commands can always be sent with app-id 0. I forgot to mention that in my previous post. BR, Mikko > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 07 July, 2004 16:50 > To: Aittola Mikko (Nokia-NET/Tampere) > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage >=20 >=20 > > Application X defines commands: C1 and C2 > > Application Y defines command: C3 and also re-uses C1 > > > > First of all, if application Y re-uses C1 it must be stated > > in the specification of application Y. >=20 > Agreed. >=20 > > If a DiameterIdentity advertises support for application X, > > it must support C1 and C2. C1 is used with app-id X. >=20 > Yes. >=20 > > If a DiameterIdentity advertises support for application Y, > > it must support C1 and C3. C1 is used with app-id Y. >=20 > This is where we disagree. C1 cannot use app-id Y unless=20 > application Y > changes the nature of the command by adding a requirement for a new > mandatory AVP. Otherwise it needs to use application X, as=20 > described in > RFC 3588. >=20 > > If a DiameterIdentity advertises support for application X and Y, it > > must support C1, C2, and C3. C1 can be used with app-id X and Y. >=20 > I disagree. C1 can only be used with app-id Y if another=20 > mandatory AVP is > defined. Otherwise, C1 can only be used with app-id X. >=20 From owner-aaa-wg@merit.edu Tue Jul 13 03:45: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 DAA18347 for ; Tue, 13 Jul 2004 03:45:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B407F91214; Tue, 13 Jul 2004 03:45:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6166091218; Tue, 13 Jul 2004 03:45:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CD34D91214 for ; Tue, 13 Jul 2004 03:45:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D1B175A102; Tue, 13 Jul 2004 03:45:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by segue.merit.edu (Postfix) with ESMTP id CA6245A04D for ; Tue, 13 Jul 2004 03:45:16 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6D7jAAh024456 for ; Tue, 13 Jul 2004 09:45:10 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 Jul 2004 09:45:10 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <3237JF9H>; Tue, 13 Jul 2004 09:45:10 +0200 Message-ID: From: "Leena Mattila (TU/LMF)" To: "'Glen Zorn'" Cc: "'aaa-wg@merit.edu'" , "'marco_stura@hotmail.com'" Subject: RE: [AAA-WG]: Issue with draft-ietf-aaa-diameter-cc-05.txt Date: Tue, 13 Jul 2004 09:45:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 13 Jul 2004 07:45:10.0413 (UTC) FILETIME=[52FC8BD0:01C468AD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Glen, seems that we haven't reached consensus on this this far. I agree that inclusion of the Service-Id in the CER/CEA messages as you = propose below would enhance interoperability - in fact when studying = the RFC 3588 it's quite similar to Supported-Vendor-Id AVP. But since = CER/CEA messages cannot be proxied this mechanism alone does not = necessarily guarantee that an upstream agent would not get a service-id = it does not know about, right? So, the inclusion of Service-Id in = CER/CEA does add value in configurations where there is a direct = connection between the client and the server. If people think that this = kind of restriction with relays/proxies is acceptable then it's ok for = me (actually RFC3588 has already similar restrictions). But still don't know how the Service-id would help in routing: The RFC = 3588 defines that the routing table entry consists of realm name and = application identifier. If an RFC 3588 compliant peer receives a CER = with a Service-id it will not do anything with that information from = routing point of view. We have used this as our basis this far and = relied on other routing mechanisms as Marco explained in earlier mails. = I.e. in CER/CEA we negotiate the application-id only, and when the user = is authenticated/authorized the AA server assigns the credit control = server based on the user and the requested service (or the DCC server = address is configured in the DCC client). The DCC server address is = used as destination host/realm and the DCC messages are routed using = the mechanisms in RFC3588. So, the case where a DCC server receives an = unknown service-id should not really happen. BR, Leena=20 -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf = Of Glen Zorn Sent: 7. hein=C3=A4kuuta 2004 0:37 To: marco.stura@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue with draft-ietf-aaa-diameter-cc-05.txt marco.stura@nokia.com writes: Just for my own edification, since I'm obviously missing something... >> OK, but how is this problem solved by _not_ including the=20 >> Service-Identifier in the CER/CEA? It seems like what you are = saying=20 >> is that CCA just won't work through relays... >=20 > Actually I was thinking to your proposal.... > I think the DCC should just work fine with relays too. I guess I'll just take your word for it & drop the matter. >=20 >> I think that the existing capabilities exchange mechanism is=20 >> sufficient, if used properly. This mechanism seems to me (please=20 >> correct me if I'm wrong -- I can't find any rationale in the I-D, = but=20 >> maybe I just missed it) to be just a way to avoid having to get a = new=20 >> app ID from IANA, but that seems a poor reason to break Diameter. >=20 > Hmm...'break Diameter' it seems a bit to strong statement. OK. My assertion was based on the belief that a DCC message could be = routed correctly (from a Diameter POV) and still arrive at a peer that = could not understand it. Is that not the case? =20 > The application is always the DCC, no reason to define new app ID. OK. So I guess that you are saying that any DCC message can be routed = to any DCC server and it will be understood? I didn't get that from = the I-D. > The rational for the service-id is explained in section 4.1 >=20 > clip >=20 > 'The Diameter Credit Control Application defines the framework for > credit control; it provides generic credit control mechanisms > supporting multiple service applications. The Credit Control > Application, therefore, does not define AVPs that could be used as > input in the rating process. Listing the possible services that > could use this Diameter application is seen as out of scope for > this generic mechanism as well.' Hmm. Maybe I'm right after all, then...it's quite confusing. My claim = would be that what is actually specified in the document is an = application framework, not an application (again, in the RFC 3588 sense = of the term); your quote seems to justify this claim. >=20 > Because we couldn't define all the possible rating inputs for all the = > possible services (i.e. the attributes to qualify the service and=20 > determine its price), the service-id was introduced as primary = 'rating=20 > root' so that the server knows immediately whether the requested=20 > service can be rated before to perform very expensive operations such = > as invoking the rating process and eventually reject > the request. =20 >=20 >> I still don't see how this really helps much. For example, suppose=20 >> that the only route from an access point to a set of >> n>1 servers (all of which support CCA, but only 1 of which >> supports the correct service) is through a relay. It doesn't seem = to=20 >> matter how many CER/CEA exchanges take place between the client and=20 >> the relay, unless the relay happens by chance to send the CCR to the = >> right server the protocol will fail. Put another way, in the=20 >> pathological case the relay might _never_ select the right server. >=20 > The DCC rely on two different models, assuming your access point=20 > perform service specific authentication/authorization with a AAA > server: >=20 > 1- The AAA server returns in the AA-answer the FQDN of the > credit-control server(s) that support this service. OK. How does the AAA server know which of the (possibly many) = DCC-servers supports this particular service, since the = Service-Identifier in not included in the CER/CEA messages? Is it a = configured parameter? > The DCC-client > will contact then the server to perform credit authorization. > 2- If the model defined in sect. 5.2.2 is used, the AAA server > advertises support for the DCC. The relay sends the request to > this AAA server, which then select the appropriate CC-server on > the basis of its knowledge of the user and requested service. > Communication with the CC-Server continues via the AAA server. Again, it's not really clear to me how the AAA server knows which is = the appropriate CC-server. >=20 > Hope this clarify > Marco Apparently dense, ~gwz "They that can give up essential liberty to obtain a little temporary = safety deserve neither..."=20 -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless = they kill in large numbers and to the sound of trumpets."=20 -- Voltaire From owner-aaa-wg@merit.edu Wed Jul 14 17:01: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 RAA20441 for ; Wed, 14 Jul 2004 17:01:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F04769123D; Wed, 14 Jul 2004 17:00:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B1D0E9123E; Wed, 14 Jul 2004 17:00:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D4F2E9123D for ; Wed, 14 Jul 2004 17:00:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BB36B5A469; Wed, 14 Jul 2004 17:00:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ns2.bln1.siemens.de (ns2.bln1.siemens.de [194.138.127.35]) by segue.merit.edu (Postfix) with ESMTP id D57BA5A358 for ; Wed, 14 Jul 2004 17:00:21 -0400 (EDT) Received: from ns-srv-2.bln1.siemens.de (stbf7654 [194.138.127.67]) by ns2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id i6EL0DRC023426; Wed, 14 Jul 2004 23:00:14 +0200 (MEST) Received: from blnss10a.bln1.siemens.de (blnss10a.bln1.siemens.de [194.138.127.102]) by ns-srv-2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id i6EL08TS018521; Wed, 14 Jul 2004 23:00:08 +0200 (MEST) Received: by blnss10a.bln1.siemens.de with Internet Mail Service (5.5.2657.72) id <366SDFYQ>; Wed, 14 Jul 2004 23:00:08 +0200 Message-ID: <445C57B81208C24EAD99F2944DBB9D29073F0F77@blnss10a.bln1.siemens.de> From: Schendel Jens ICM Berlin To: "'marco.stura@nokia.com'" , cmousset@nortelnetworks.com Cc: aaa-wg@merit.edu Subject: AW: [AAA-WG]: DCC usage of CCR final on ASR Date: Wed, 14 Jul 2004 23:00:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C469E5.8B522420" 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_01C469E5.8B522420 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Claire, Marco, =20 the described behaviour sounds reasonable to me, however, I cannot find = the specification for ASR/ASA treatment in the DCCA 05 state machines.=20 In opposition, the specific processing for RAR/RAA is given there. I'm = not sure whether ASR/ASA as described in Diameter Base RFC (e.g., = section 8.1. Authorization Session State Machine, e.g. CLIENT, = STATEFUL) is sufficient information to derive the appropriate Credit = Control handling. =20 Shouldn't this be fixed? =20 An example of an enhanced DCCA state machine were (section 7. Credit = Control Application State Machine): =20 CLIENT, SESSION BASED for intermediate and final interrogations =20 State Event Action New State =20 ---------------------------------------------------------------- =20 =20 Open ASR Received Terminate PendingT =20 end user's =20 service, send=20 ASA with=20 Result-Code=20 =3D SUCCESS send CC=20 termination =20 req. =20 It also has to be considered how ASR are treated in the Pending states. =20 Regards Jens =20 =20 -----Urspr=FCngliche Nachricht----- Von: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Gesendet: Freitag, 9. Juli 2004 09:34 An: cmousset@nortelnetworks.com Cc: aaa-wg@merit.edu Betreff: RE: [AAA-WG]: DCC usage of CCR final on ASR Comments in line. =20 Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf = Of ext Claire Mousset Sent: 08 July, 2004 14:36 To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC usage of CCR final on ASR Hello,=20 In looking at the DCC usage together with Diameter base, I have a = question on whether the STR usage (as described in 8.5 of RFC 3588) is = effectively replaced by a CCR final. If the server receives a CCR = final, then it knows to take down the session, so what purpose does the = STR serve? It is a completely wasted message.=20 CCR termination is used in DCC to the credit control server. STR is = used to the AAA server in case you have a service specific = authorization/authentication session with the AAA server.=20 What I would like is to clarify that the following sequence is valid = with DCC:=20 If an Abort-Session-Request is received from the server, the client = responds with an Abort-Session-Answer, then provides the Final User = Units in a Credit Control Request message (Termination), then the user = session can be terminated when the Answer is received back from the = server.=20 Right.=20 No STR needed for this case.=20 Comments?=20 Many thanks,=20 Claire.=20 ------_=_NextPart_001_01C469E5.8B522420 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Nachricht
Hi Claire, Marco,
 
the described behaviour sounds reasonable to me, however, I = cannot=20 find the specification for ASR/ASA treatment in the = DCCA 05 state=20 machines.
In opposition, the = specific=20 processing for RAR/RAA is given there. I'm not=20 sure whether ASR/ASA as described in Diameter Base RFC (e.g., section = 8.1. =20 Authorization Session State Machine, e.g. CLIENT, STATEFUL) is = sufficient=20 information to derive the appropriate Credit Control=20 handling.
 
Shouldn't this be fixed?
 
An example of an enhanced DCCA state machine were (section 7. = Credit=20 Control Application State Machine):
 
CLIENT, SESSION BASED for intermediate and final=20 interrogations
 
     = State    =20 Event           &= nbsp;           &= nbsp; =20 Action       New State =20
    =20 ---------------------------------------------------------------- &n= bsp;
     
    =20 Open      ASR Received=20             =      =20 Terminate   =20 PendingT  
        =             =             =             =  =20 end=20 user's   
       &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp; =20 service, send=20
        &nb= sp;           &nb= sp;           &nb= sp;       =20      ASA with 
           &= nbsp;           &= nbsp;           &= nbsp;          Result-= Code=20
          &nb= sp;           &nb= sp;           &nb= sp;          =20 =3D SUCCESS
           &= nbsp;           &= nbsp;           &= nbsp;          send=20 CC
           &= nbsp;           &= nbsp;           &= nbsp;         =20 termination  =20
           &n= bsp;           &n= bsp;           &n= bsp;         =20 req.
 
It also has to be considered how ASR are = treated in the=20 Pending states.
 
Regards Jens

 =20
 
-----Urspr=FCngliche Nachricht-----
Von: = marco.stura@nokia.com=20 [mailto:marco.stura@nokia.com]
Gesendet: Freitag, 9. Juli = 2004=20 09:34
An: cmousset@nortelnetworks.com
Cc:=20 aaa-wg@merit.edu
Betreff: RE: [AAA-WG]: DCC usage of CCR = final on=20 ASR

Comments in line.
 
Marco
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Claire=20 Mousset
Sent: 08 July, 2004 14:36
To:=20 aaa-wg@merit.edu
Subject: [AAA-WG]: DCC usage of CCR = final on=20 ASR

Hello,

In looking at the DCC usage together = with=20 Diameter base, I have a question on whether the STR usage (as = described in=20 8.5 of RFC 3588) is effectively replaced by a CCR final. = If the server receives a CCR final, = then it knows to=20 take down the session, so what purpose does the STR serve? It is a=20 completely wasted message. 

CCR termination is used in DCC to the credit = control=20 server. STR is used to the AAA server in case you have a = service=20 specific authorization/authentication session with the AAA=20 server. 

What I would like is to clarify that = the=20 following sequence is valid with DCC:

If an Abort-Session-Request is = received=20 from the server, the client responds with an Abort-Session-Answer, = then=20 provides the Final User Units in a Credit Control Request message=20 (Termination), then the user session can be terminated when the = Answer is=20 received back from the server. 

Right. 

No STR needed for this case. =

Comments?

Many thanks,

Claire.=20

------_=_NextPart_001_01C469E5.8B522420-- From owner-aaa-wg@merit.edu Thu Jul 15 08:30: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 IAA15844 for ; Thu, 15 Jul 2004 08:30:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BE69A91212; Thu, 15 Jul 2004 08:29:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9210C91213; Thu, 15 Jul 2004 08:29:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 38FE291212 for ; Thu, 15 Jul 2004 08:29:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 24A8E5A0FC; Thu, 15 Jul 2004 08:29:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 350805A03F for ; Thu, 15 Jul 2004 08:29:41 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6FCTdWR025173 for ; Thu, 15 Jul 2004 14:29:40 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 Jul 2004 14:29:39 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <32378JT0>; Thu, 15 Jul 2004 14:29:39 +0200 Message-ID: From: "Leena Mattila (TU/LMF)" To: "'Schendel Jens ICM Berlin'" , "'Stura Marco'" , cmousset@nortelnetworks.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC usage of CCR final on ASR Date: Thu, 15 Jul 2004 14:29:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 15 Jul 2004 12:29:39.0887 (UTC) FILETIME=[660313F0:01C46A67] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Jens, this is intentionally left out because the state Open User service terminated Send PendingT =20 CC termination =20 req.=20 covers also this case. The user service can be terminated for various = reasons (normal user termination, network failure, ASR etc). We haven't = separated those, neither has the RFC3588 in their accounting state = machine. The Termination-Cause AVP contains information about the = reason (value 4 in this case). The reason why RAR/RAA are included is that special DCC specific logic = is built around those commands. BR, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf = Of Schendel Jens ICM Berlin Sent: 15. hein=E4kuuta 2004 0:00 To: 'marco.stura@nokia.com'; cmousset@nortelnetworks.com Cc: aaa-wg@merit.edu Subject: AW: [AAA-WG]: DCC usage of CCR final on ASR Hi Claire, Marco, the described behaviour sounds reasonable to me, however, I cannot find = the specification for ASR/ASA treatment in the DCCA 05 state machines.=20 In opposition, the specific processing for RAR/RAA is given there. I'm = not sure whether ASR/ASA as described in Diameter Base RFC (e.g., = section 8.1. Authorization Session State Machine, e.g. CLIENT, = STATEFUL) is sufficient information to derive the appropriate Credit = Control handling. Shouldn't this be fixed? An example of an enhanced DCCA state machine were (section 7. Credit = Control Application State Machine): CLIENT, SESSION BASED for intermediate and final interrogations State Event Action New State =20 ---------------------------------------------------------------- =20 =20 Open ASR Received Terminate PendingT =20 end user's =20 service, send=20 ASA with=20 Result-Code=20 =3D SUCCESS send CC=20 termination =20 req. It also has to be considered how ASR are treated in the Pending states. Regards Jens =20 -----Urspr=FCngliche Nachricht----- Von: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Gesendet: Freitag, 9. Juli 2004 09:34 An: cmousset@nortelnetworks.com Cc: aaa-wg@merit.edu Betreff: RE: [AAA-WG]: DCC usage of CCR final on ASR Comments in line. Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf = Of ext Claire Mousset Sent: 08 July, 2004 14:36 To: aaa-wg@merit.edu Subject: [AAA-WG]: DCC usage of CCR final on ASR Hello,=20 In looking at the DCC usage together with Diameter base, I have a = question on whether the STR usage (as described in 8.5 of RFC 3588) is = effectively replaced by a CCR final. If the server receives a CCR = final, then it knows to take down the session, so what purpose does the = STR serve? It is a completely wasted message.=20 CCR termination is used in DCC to the credit control server. STR is = used to the AAA server in case you have a service specific = authorization/authentication session with the AAA server.=20 What I would like is to clarify that the following sequence is valid = with DCC:=20 If an Abort-Session-Request is received from the server, the client = responds with an Abort-Session-Answer, then provides the Final User = Units in a Credit Control Request message (Termination), then the user = session can be terminated when the Answer is received back from the = server.=20 Right.=20 No STR needed for this case. Comments?=20 Many thanks,=20 Claire.=20 From owner-aaa-wg@merit.edu Thu Jul 15 10:07: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 KAA21234 for ; Thu, 15 Jul 2004 10:07:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ABE2F91216; Thu, 15 Jul 2004 10:07:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 798079121B; Thu, 15 Jul 2004 10:07:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1223E91216 for ; Thu, 15 Jul 2004 10:07:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EFEE55A1C9; Thu, 15 Jul 2004 10:07:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ns2.bln1.siemens.de (ns2.bln1.siemens.de [194.138.127.35]) by segue.merit.edu (Postfix) with ESMTP id 17CF95A122 for ; Thu, 15 Jul 2004 10:07:17 -0400 (EDT) Received: from ns-srv-2.bln1.siemens.de (stbf7654 [194.138.127.67]) by ns2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id i6FE39RC029393; Thu, 15 Jul 2004 16:03:09 +0200 (MEST) Received: from blnss10a.bln1.siemens.de (blnss10a.bln1.siemens.de [194.138.127.102]) by ns-srv-2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id i6FE33TS000626; Thu, 15 Jul 2004 16:03:03 +0200 (MEST) Received: by blnss10a.bln1.siemens.de with Internet Mail Service (5.5.2657.72) id <366SDMJM>; Thu, 15 Jul 2004 16:03:03 +0200 Message-ID: <445C57B81208C24EAD99F2944DBB9D29073F0F80@blnss10a.bln1.siemens.de> From: Schendel Jens ICM Berlin To: "'Leena Mattila (TU/LMF)'" , Schendel Jens ICM Berlin , "'Stura Marco'" , cmousset@nortelnetworks.com Cc: aaa-wg@merit.edu Subject: AW: [AAA-WG]: DCC usage of CCR final on ASR Date: Thu, 15 Jul 2004 16:03:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Leena, thanks for the clarification. Wouldn't some additional clarifying text = improve the understanding a lot? My proposal is to add an additional paragraph in section 7, e.g. after = "The event 'Not successfully processed' means...": The event 'User service terminated' can be triggered by various reasons, e.g. normal user termination, network failure and ASR. The Termination-Cause AVP contains information about the reason as specified in [DIAMBASE]. Regards, Jens > -----Urspr=FCngliche Nachricht----- > Von: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com]=20 > Gesendet: Donnerstag, 15. Juli 2004 14:30 > An: 'Schendel Jens ICM Berlin'; 'Stura Marco';=20 > cmousset@nortelnetworks.com > Cc: aaa-wg@merit.edu > Betreff: RE: [AAA-WG]: DCC usage of CCR final on ASR >=20 >=20 > Hi Jens, >=20 > this is intentionally left out because the state > Open User service terminated Send PendingT =20 > CC termination =20 > req.=20 >=20 > covers also this case. The user service can be terminated for=20 > various reasons (normal user termination, network failure,=20 > ASR etc). We haven't separated those, neither has the RFC3588=20 > in their accounting state machine. The Termination-Cause AVP=20 > contains information about the reason (value 4 in this case). > The reason why RAR/RAA are included is that special DCC=20 > specific logic is built around those commands. >=20 > BR, > Leena >=20 > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of Schendel Jens ICM Berlin > Sent: 15. hein=E4kuuta 2004 0:00 > To: 'marco.stura@nokia.com'; cmousset@nortelnetworks.com > Cc: aaa-wg@merit.edu > Subject: AW: [AAA-WG]: DCC usage of CCR final on ASR >=20 >=20 > Hi Claire, Marco, >=20 > the described behaviour sounds reasonable to me, however, I=20 > cannot find the specification for ASR/ASA treatment in the=20 > DCCA 05 state machines.=20 > In opposition, the specific processing for RAR/RAA is given=20 > there. I'm not sure whether ASR/ASA as described in Diameter=20 > Base RFC (e.g., section 8.1. Authorization Session State=20 > Machine, e.g. CLIENT, STATEFUL) is sufficient information to=20 > derive the appropriate Credit Control handling. >=20 > Shouldn't this be fixed? >=20 > An example of an enhanced DCCA state machine were (section 7.=20 > Credit Control Application State Machine): >=20 > CLIENT, SESSION BASED for intermediate and final interrogations >=20 > State Event Action New State = > =20 > ---------------------------------------------------------------- =20 > =20 > Open ASR Received Terminate PendingT =20 > end user's =20 > service, send=20 > ASA with=20 > Result-Code=20 > =3D SUCCESS > send CC=20 > termination =20 > req. >=20 > It also has to be considered how ASR are treated in the=20 > Pending states. >=20 > Regards Jens >=20 > =20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 > Gesendet: Freitag, 9. Juli 2004 09:34 > An: cmousset@nortelnetworks.com > Cc: aaa-wg@merit.edu > Betreff: RE: [AAA-WG]: DCC usage of CCR final on ASR >=20 >=20 > Comments in line. >=20 > Marco > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Claire=20 > Mousset > Sent: 08 July, 2004 14:36 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: DCC usage of CCR final on ASR >=20 >=20 > Hello,=20 > In looking at the DCC usage together with Diameter base, I=20 > have a question on whether the STR usage (as described in 8.5=20 > of RFC 3588) is effectively replaced by a CCR final. If the=20 > server receives a CCR final, then it knows to take down the=20 > session, so what purpose does the STR serve? It is a=20 > completely wasted message.=20 > CCR termination is used in DCC to the credit control server.=20 > STR is used to the AAA server in case you have a service=20 > specific authorization/authentication session with the AAA server.=20 > What I would like is to clarify that the following sequence=20 > is valid with DCC:=20 > If an Abort-Session-Request is received from the server, the=20 > client responds with an Abort-Session-Answer, then provides=20 > the Final User Units in a Credit Control Request message=20 > (Termination), then the user session can be terminated when=20 > the Answer is received back from the server.=20 > Right.=20 > No STR needed for this case.=20 > Comments?=20 > Many thanks,=20 > Claire.=20 >=20 From owner-aaa-wg@merit.edu Fri Jul 16 04:59: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 EAA16585 for ; Fri, 16 Jul 2004 04:59:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3CF1291250; Fri, 16 Jul 2004 04:59:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0667491252; Fri, 16 Jul 2004 04:59:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B5CA091250 for ; Fri, 16 Jul 2004 04:59:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A59505A32F; Fri, 16 Jul 2004 04:59:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.202]) by segue.merit.edu (Postfix) with ESMTP id E375E5A329 for ; Fri, 16 Jul 2004 04:59:01 -0400 (EDT) Received: from g9jbq.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 16 Jul 2004 10:55:45 +0200 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Jul 2004 10:55:44 +0200 Message-Id: From: "Beck01, Wolfgang" To: miguel.an.garcia@nokia.com Cc: aaa-wg@merit.edu Subject: [AAA-WG]: draft-diameter-sip-app; Authentication-Info and qop=auth-int Date: Fri, 16 Jul 2004 10:55:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello Miguel, Rahul Joshi made an observation concerning Authentication-Info and = qop=3Dauth-int. To calculate Authentication-Info with qop=3Dauth-int, the AAA server = must know the bodies of both, the positive AND the negative SIP/HTTP = response.=20 This problem occurs with draft-sterman-aaa-sip. Has diameter-sip-app = the same problem? I see the following solutions: 1) drop support for Authentication-Info alltogether 2) drop support for Authentication-Info and qop=3Dauth-int 3) let the RADIUS/DIAMETER client insert = Body-Digests/Digest-Entity-Body-Hash of the request and all response variants that might be sent after = receiving an answer of the server. I am in favour of 2) as 3) means a lot of overhead in the clients. Wolfgang -----Urspr=FCngliche Nachricht----- Von: Rahul Joshi [mailto:rahul_joshi a e t persistent.co.in] Gesendet: Montag, 12. Juli 2004 14:43 An: baruch@kayote.com Cc: dscreat@dscreat.com; david@kayote.com; dwilli@cisco.com; Beck, Wolfgang; Rahul Joshi Betreff: Calculating rspauth when qop=3Dauth-int as per draft-sterman-aaa-sip-02.txt After going through the draft-sterman-aaa-sip-02.txt and RFC 2617 = (HTTP=20 Authentication) I have a question regarding calculating rspauth attribute in=20 Authentication-Info header when qop=3Dauth-int. Should the H(Entity-body) used in the calculation of rspauth be of the = "request" message body that was received or the 200 OK SIP response that is being send back to the client ? As per RFC 2617, pg 16, "qop=3Dauth-int also provides limited integrity protection of the response". Because of this I think=20 that we should use the H(Entity-Body) of the 200 OK response in the calculation. So how = would=20 the information of the response message body be communicated to the AAA server in the=20 current framework of draft-sterman-aaa-sip-02.txt? Currently we only send the hash of "request message body" as = DIG-BODY=20 attribute . No hash of the response message body is communicated. Is there any specific reason for devation from RFC 2617 by always using the request message body hash , OR there has been some=20 misinterpretation on my part? Regards. -Rahul From owner-aaa-wg@merit.edu Fri Jul 16 06:13: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 GAA19787 for ; Fri, 16 Jul 2004 06:13:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 10CBF91252; Fri, 16 Jul 2004 06:13:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE5E491254; Fri, 16 Jul 2004 06:13:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E7ADF91252 for ; Fri, 16 Jul 2004 06:13:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CE9CC5A285; Fri, 16 Jul 2004 06:13:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 059AA5A064 for ; Fri, 16 Jul 2004 06:13:30 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6GADTWR003499 for ; Fri, 16 Jul 2004 12:13:29 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 16 Jul 2004 12:13:29 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <32381RJ6>; Fri, 16 Jul 2004 12:13:28 +0200 Message-ID: From: "Leena Mattila (TU/LMF)" To: mwatson@nortelnetworks.com, mgrayson@cisco.com Cc: aaa-wg@merit.edu, gwz@cisco.com, cmousset@nortelnetworks.com, "'Marco.STURA@consultant.vodafoneomnitel.it'" Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Date: Fri, 16 Jul 2004 12:13:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 16 Jul 2004 10:13:29.0063 (UTC) FILETIME=[8A3C0770:01C46B1D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, we've had some discussion on the matter off-line, I switch the = discussion back to the mailing list. The main problem seems to be the = word 'service' - we do use it for two purposes ('main service' and 'the = actual service category'). We also received this kind of comment from = IESG review team but they did not have any good word in English to = solve it either ;-) How about the following split:=20 a) A Service-Context-Id is used on command level. This would be the = 'broad' service and define the context in which the DCC is being used. = The Service-Context-Id MUST be present if DCC application id is used. = Alternatively, one that introduces mandatory rating AVPs defines an own = application-id from IANA and then this AVP is not needed to guarantee = interoperability - the dedicated application id guarantees that = already b) Service-Id identifies the service within the given Context. It can = be present either on command level or in MSCC. I.e. in case of ordinary = one service/session we would have both Service-Context-Id and = Service-Id on command level and in case of MSCC we would have = Service-Context-Id on command level and Service-Id in MSCC. The = Service-Id values are service-specific (in the same way as = Rating-Group) An imaginary example (gaming): Service-Context-Id: game_service@foo.com Service-Id: 2 (=3Dmad man 2 - de luxe) Would that solve the wording problem with 'service', and clarify the = interoperability?=20 BR, Leena -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 7. hein=E4kuuta 2004 15:29 To: Leena Mattila (TU/LMF); 'Mark Grayson (mgrayson)'; = 'marco.stura@nokia.com' Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Claire Mousset Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Hi Leena,=20 You wrote:=20 "- when using the MSCC the Service-ID on command level is the=20 main service, e.g. Network access, and the Service-Ids within=20 the MSCC then identify the sub-services within the main service"=20 This sounds very reasonable to me, but it is not what the specification = seems to imply. There is no concept in the spec of 'services' being = 'sub-ordinate' to other 'services'. Furthermore, the fact that a = 'service' is sub-ordinate to Rating-Group implies that everything = within a service has to be rated the same. So then even if there were = sub-services within a 'main service' they would all have to be within = the same Rating-Group! But if people feel it's clear that there can be such a thing as a 'main = service' which is not part of any Rating Group and which has = sub-services, then that seems fine to me. As for (3), it doesn't seem a big deal, but does seem arbitrary - if I = want to request a quota for a single Rating-Group (which is probably = the most common case in 3GPP anyway) I need to use MSCC. ...Mark=20 -----Original Message-----=20 From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com]=20 Sent: 07 July 2004 12:00=20 To: Watson, Mark [MOP:EP10:EXCH]; 'Mark Grayson (mgrayson)'; = 'marco.stura@nokia.com'=20 Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Mousset, Claire = [ADC:8J70:EXCH]=20 Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )=20 Hi,=20 when the MSCC concept was introduced I always had the assumption that = the services within the MSCC structure are=20 sub-ordinate to some higher level service, e.g. Network Access. Having = said that, it's also true that what one can do with MSCC one should be = able=20 to do with several messages (that's where the MSCC issue initially = started). However, I still believe that those several=20 messages are inter-related (otherwise you wouldn't group them=20 in the same message, right?), and thus the exact formulation=20 would be 'what one can do with MSCC one should be able to do=20 with sub-sessions'. Hence the analogy between the two approaches is:=20 - when using the MSCC the Service-ID on command level is the main service, e.g. Network access, and the Service-Ids within=20 the MSCC then identify the sub-services within the main service=20 - when using sub-sessions the Service-ID in 'main' session is=20 the main service and the Service-Ids in sub-sessions (on=20 command level) are the sub-services.=20 If there is no common factor between the Service-IDs one has=20 grouped within one MSCC, then I think they should not be=20 grouped together at all, they are then clearly not sub-ordinate = services (e.g. not carried within the same bearer) and should=20 treat them as such - optimizing signaling=20 should not be the only justification for doing the grouping.=20 And when there is a common factor, that factor should become=20 the Service-ID on command level.=20 Regarding the question (3): I'll put it the other way around:=20 At the moment it's not possible to have rating groups on=20 command level but do you see a need for it?=20 Regards,=20 Leena=20 -----Original Message-----=20 From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf = Of Mark Watson=20 Sent: 6. hein=E4kuuta 2004 19:21=20 To: 'Mark Grayson (mgrayson)'; 'marco.stura@nokia.com'=20 Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Claire Mousset=20 Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )=20 Hi Mark,=20 Note sure what you mean by a 'rating-root', but it is quite clear (e.g. = in the diagrams in 5.1.1) that 'services' are sub-ordinate to = Rating-Groups. Since everything in a Rating-Group is rated the same way = then certainly you cannot have things within a service which are rated = differently. That is, services are the finest level of granularity that = can be separately charged. The point of MSCC was to do in one message what could otherwise be done = with several messages and only command level values - so I would expect = the things appearing in the MSCC to have the same semantics as things = appearing at command level & for the two to be mutually exclusive - = hence Question 1 below. To answre my question (2) below for myself, we don't need multiple = instances of the same service within a single sub-session. In 3GPP, I = think we may have a requirement for dynamically povisioned services, = but the dynamic provisioning of these to DCC client & server is out of = scope here & so there should be no problem. ...Mark=20 -----Original Message-----=20 From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com]=20 Sent: 06 July 2004 16:44=20 To: Watson, Mark [MOP:EP10:EXCH]; marco.stura@nokia.com=20 Cc: aaa-wg@merit.edu; Glen Zorn (gwz); Mousset, Claire [ADC:8J70:EXCH]=20 Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )=20 Mark, Marco=20 I hadn't made the same assumption - but agree that there is ambiguity = here.=20 I had asumed that when present on the command level, the service-ID = refers to the "rating-root" which then needs to be common between = client and serer.=20 Then the issue exists with re-introducing the service-ID at the MSCC = level, now possibly below the sub-session-ID which I think is the cause = of the issue. IMO these AVPs at the MSCC level should be subordinate to = the service-ID on the command level. Cheers,=20 Mark=20 From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf = Of Mark Watson=20 Sent: 06 July 2004 11:08=20 To: 'marco.stura@nokia.com'=20 Cc: 'aaa-wg@merit.edu'; Glen Zorn (gwz); Claire Mousset=20 Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: )=20 Hi Marco,=20 Some quick questions for clarification on this one...=20 1) If the client wants to request quotas for multiple services using = the Multiple-Services-Credit-Control AVP then what should it put in the = mandatory command level Service-Identifier AVP ? 2) Service-Identifier is finer granlarity than Rating-Group - that is = several services with unique Service-Identifiers are grouped within a = single Rating-Group. So a 'service' identified by a Service-Identifier = is basically the finest granularity thing that can be separately = charged. But then the definition of the Service Identifier AVP speaks = of statically configured or standardised values. To be consistent with = the above it would need to be a format or pattern than was = configured/standardised - e.g. if it's voice calls that you are = charging for then Service Identifies like 'voice001@blah.org', = 'voice002@blah.org' would be needed to distinguish between multiple = concurrent voice calls. Right ?=20 3) It isn't possible to request credit for a Rating-Group except by = using the Multiple-Services-Credit-Control AVP, right ? Regards...Mark=20 -----Original Message-----=20 From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: 05 July 2004 09:09=20 To: gwz@cisco.com=20 Cc: aaa-wg@merit.edu=20 Subject: [AAA-WG]: RE:=20 Glen,=20 the Service-Id is only included in CCR message (at command level) to = indicate=20 to the server for what specific service the request is being issued. = The server checks first the Service-Id AVP and, if it doesn't recognize = the value of this AVP, it rejects the request without any further = processing (e.g. rating or what so ever). If the server recognizes the = value of the Service-Id AVP, it continues the processing and authorizes = the credit if possible (i.e. if there is enough credit in the user's = account). =20 The section 4.1 has been restructured on request of IESG review as = follow, the inclusion of the Service-Id in CCR is mandatory. Whenever = the IESG and the ADs will agree that their comments have been properly = addressed, the draft 06 will be carried out and made available. Regards = Marco=20 4.1 Service-Specific Rating Input and Interoperability=20 =20 The Diameter Credit-Control Application defines the framework for = credit=20 control; it provides generic credit control mechanisms supporting = multiple=20 service applications. The Credit Control Application, therefore, = does not=20 define AVPs that could be used as input in the rating process. = Listing the=20 possible services that could use this Diameter application is seen = as out=20 of scope for this generic mechanism as well. =20 =20 Furthermore, it is reasonable to expect that there will exist a = service=20 level agreement between providers of the credit-control client and = the=20 credit-control server covering the charging, services offered, = roaming=20 agreements, agreed rating input (i.e. AVPs), etc.=20 Therefore, it is assumed that a Diameter credit control server will=20 provide service only for Diameter credit-control clients that have = agreed=20 beforehand the content of credit control messages. Protocol wise, it = is=20 naturally possible that any arbitrary Diameter credit-control client = can=20 interchange credit control messages with any Diameter credit control = server, but with a higher likelihood that unsupported services/AVPs = could=20 be present in the credit-control message causing the server to = reject the=20 request with an appropriate result-code.=20 =20 4.1.1 Specifying Rating Input AVPs=20 =20 There are two ways for providing rating input to the credit control=20 server, either by using AVPs or by including them in the Service-=20 Parameter-Info AVP. The general principles for sending rating = parameters=20 are:=20 =20 1a. The service SHOULD re-use existing AVPs, if the service can use = AVPs=20 defined in existing Diameter applications (e.g. NASREQ for = network=20 access services). Re-use of existing AVPs is strongly = recommended in=20 [DIAMBASE].=20 For AVPs of type Enumerated the service may require a new value = to be=20 defined. Allocation of new AVP values is done as specified in=20 [DIAMBASE], section 1.2.=20 =20 1b. New AVPs can be defined if the existing AVPs do not provide = sufficient=20 rating information. In such a case, the procedures defined in=20 [DIAMBASE] for creating new AVPs MUST be followed.=20 =20 1c. For services specific only to one vendor's implementation, a = Vendor-=20 Specific AVP code for Private use can be used. Where a = Vendor-Specific=20 AVP is implemented by more than one vendor, allocation of global = AVPs=20 are encouraged instead, refer to [DIAMBASE].=20 =20 2. The Service-Parameter-Info AVP MAY be used as a container to pass = legacy rating information in its original encoded form (e.g. = ASN.1=20 BER). This method can be used to avoid unnecessary data format=20 conversions from an existing format to an AVP format. In that = case the=20 rating input is embedded in the Service-Parameter-Info AVP as = defined=20 in section 8.42.=20 =20 New service applications SHOULD favor the use of explicitly defined = AVPs=20 as described in items 1a and 1b, to simplify interoperability. =20 =20 4.1.2 Application Support=20 =20 Since the Application-Id of the Diameter Credit Control Application = does=20 not uniquely identify the service being monitored, an additional = mechanism=20 is needed. The service application MUST be identified using the = Service-=20 Identifier AVP at command level. A server receiving a request for a=20 service application it does not support will reject the request as = defined=20 in sub-section 4.1.4. The Service-Identifier AVP MUST be a unique=20 identifier for a given service as defined in section 8.28. =20 =20 Thus, the combination of the Diameter Credit Control Application-Id = and=20 the Service-Identifier AVP in the Credit-Control-Request command = uniquely=20 defines the service within the context of the Diameter Credit = Control, and=20 hence provides interoperability between Diameter credit control = clients=20 and server.=20 =20 With this mechanism it is possible to cover additional service = specific=20 requirements as needed in other documents. However, introducing new = credit=20 control mechanisms to the framework defined in this specification, = require=20 definition of a new version of the Diameter Credit Control = Application and=20 corresponding Application Identifier.=20 =20 4.1.3 Service-Specific Documentation=20 =20 The service specific rating input AVPs, the contents of the Service- = Parameter-Info AVP or Service-Identifier AVP are not within the = scope of=20 this document. To facilitate interoperability, it is RECOMMENDED = that the=20 rating input and the values of the service identifiers are = coordinated via=20 an informational RFC or other permanent and readily available = reference=20 such as the specification of another cooperative standardization = body=20 (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services = may=20 be deployed that are subject to agreements between providers of the = credit=20 control server and client, in this case vendor specific AVPs can be = used. =20 =20 This specification, together with the above service specific = documents,=20 governs the credit control message. The rule is that service = specific=20 documents define what existing AVPs or new AVPs are used as input to = the=20 rating process (i.e. they do not define new credit control = applications),=20 and thus need to be included in the Credit-Control-Request command = by a=20 Diameter Credit Control Client supporting a given service as *[AVP]. = Should Service-Parameter-Info be used, then the service specific = document=20 MUST specify the exact content of this grouped AVP.=20 =20 4.1.4 Handling of Unsupported/Incorrect Rating Input =20 =20 Diameter credit control implementations are required to support the=20 Mandatory rating AVPs defined in service specific documentation of = the=20 services they support according to the 'M' bit rules in [DIAMBASE]. = =20 In case a rating input required for the rating process is incorrect = in the=20 Credit control request, or the credit control server does not = support the=20 requested service (identified by the Service-Idntifier AVP at = command=20 level), the Credit control answer MUST contain error code=20 DIAMETER_RATING_FAILED. A CCR message with this error MUST contain = one or=20 more Failed-AVP AVPs containing the missing and/or unsupported AVPs = that=20 caused the failure. A Diameter credit control client receiving error = code DIAMETER_RATING_FAILED in answer to a request MUST NOT send such = similar=20 requests in the future.=20 =20 4.1.5 RADIUS Vendor-Specific Rating Attributes=20 =20 When service specific documents include RADIUS vendor specific = attributes=20 that could be used as input in the rating process, the rules = described in=20 [NASREQ] for formatting the Diameter AVP MUST be followed. For = example,=20 the AVP code used is the vendor attribute type code, the = Vendor-Specific=20 flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA = Vendor=20 identification value. The Diameter AVP data field contains only the=20 attribute value of the RADIUS attribute.=20 > -----Original Message-----=20 > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of=20 > ext Glen Zorn=20 > Sent: 02 July, 2004 20:27=20 > To: aaa-wg@merit.edu=20 > Subject:=20 >=20 >=20 > Description of issue: No guarantee of interoperability=20 > between CCA implementations=20 > Submitter name: Glen Zorn=20 > Submitter email address: gwz@cisco.com=20 > Date first submitted: 2 July 2004=20 > Document: dcca=20 > Comment type: T=20 > Priority: S=20 > Section: 4.1=20 > Rationale/Explanation of issue:=20 > In order to interoperate, Diameter peers implementing the=20 > Diameter Credit Control Application must agree upon both the=20 > application and the service (specified in the=20 > Service-Identifier AVP). However, the inclusion of the=20 > Service-Identifier in the CCR and CCA messages is optional.=20 >=20 > Lengthy description of problem:=20 > Section 4.1, para. 6 states "it is the combination of support=20 > of the Diameter Credit Control Application and the service=20 > defined in the Service-Identifier AVP, which defines=20 > interoperability between any given credit control client and=20 > server." However, the inclusion of the Service-Identifier in=20 > the CCR and CCA messages is optional. This gives rise to a=20 > situation where two peers implementing the same application=20 > may not interoperate because they do not implement the same=20 > "service", and further, refuse to clearly communicate that fact.=20 >=20 > Requested change:=20 > Change section 4.1, paragraph 5 from=20 >=20 > This specification, together with service specific documents, is=20 > governing the credit control message. The rule is that service=20 > specific documents only define what existing AVPs or new AVPs are=20 > used as input to the rating process (i.e. they do not define new=20 > credit control applications), and thus need to be included in the=20 > Credit-Control-Request command by a Diameter Credit Control Client = > supporting a given service as *[AVP]. In order to define new AVPs, = > service specific documents MUST follow the practices defined in=20 > [DIAMBASE]. The service SHOULD be identified using the Service-=20 > Identifier AVP. The Service-Identifier AVP MUST be a unique=20 > identifier for a given service as defined in section 8.28.=20 >=20 > to=20 >=20 > This specification, together with service specific documents, is=20 > governing the credit control message. The rule is that service=20 > specific documents only define what existing AVPs or new AVPs are=20 > used as input to the rating process (i.e. they do not define new=20 > credit control applications), and thus need to be included in the=20 > Credit-Control-Request command by a Diameter Credit Control Client = > supporting a given service as *[AVP]. In order to define new AVPs, = > service specific documents MUST follow the practices defined in=20 > [DIAMBASE]. The service MUST be identified using the Service-=20 > Identifier AVP. The Service-Identifier AVP MUST be a unique=20 > identifier for a given service as defined in section 8.28.=20 >=20 > ~gwz=20 >=20 > "They that can give up essential liberty to obtain a little=20 > temporary safety deserve neither..."=20 > -- Benjamin Franklin, 1759=20 >=20 >=20 > "It is forbidden to kill; therefore all murderers are=20 > punished unless they kill in large numbers and to the sound=20 > of trumpets."=20 > -- Voltaire=20 >=20 >=20 From owner-aaa-wg@merit.edu Fri Jul 16 15:52:40 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28423 for ; Fri, 16 Jul 2004 15:52:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3879B91286; Fri, 16 Jul 2004 15:51:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05CCE91287; Fri, 16 Jul 2004 15:51:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AC12191286 for ; Fri, 16 Jul 2004 15:51:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 94A6559CD4; Fri, 16 Jul 2004 15:51:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by segue.merit.edu (Postfix) with ESMTP id 1124D59CC2 for ; Fri, 16 Jul 2004 15:51:52 -0400 (EDT) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 16 Jul 2004 21:55:47 +0200 X-BrightmailFiltered: true Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i6GJpjU9017227; Fri, 16 Jul 2004 21:51:47 +0200 (MEST) Received: from xmb-ams-33a.cisco.com ([144.254.231.85]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 16 Jul 2004 21:51:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Use of thresholds in DCCA Date: Fri, 16 Jul 2004 21:52:58 +0200 Message-ID: Thread-Topic: Use of thresholds in DCCA Thread-Index: AcRrbn5uJw6Lg253Qj+LCxmKvBFp2A== From: "Mark Grayson (mgrayson)" To: , , , Cc: X-OriginalArrivalTime: 16 Jul 2004 19:51:47.0194 (UTC) FILETIME=[53EEA5A0:01C46B6E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Guys I have a question about expected DCCA operation. There may be service specific documentation that defines the use of thresholds which can trigger a CCR(update) prior to full expiry of the granted service units. Then according to DCCA, when new quota is allocated these units will be used from the last measurement time - i.e., effectively meaning the used threshold is subtracted from the granted service units - and the unused threshold units are thrown away. Then what happens if the "used threshold" exceeds the granted service units. Doesn't this mean the CLCI-Client should report negative used service units in its next CCR(update)? Do we need a health warning on the use of thresholds with service specific usage of the credit control model in DCCA? Best regards, Mark _____________________________ Mark Grayson,=20 Mobile Wireless Group Cisco Systems IP Phone : +1 919-392-1809 Mobile : +1 919-413-1314 www.cisco.com/go/mobile =20 =20 From owner-aaa-wg@merit.edu Mon Jul 19 04:24: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 EAA23989 for ; Mon, 19 Jul 2004 04:24:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B77AC91232; Mon, 19 Jul 2004 04:23:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D41D91233; Mon, 19 Jul 2004 04:23:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3E48691232 for ; Mon, 19 Jul 2004 04:23:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 277755A575; Mon, 19 Jul 2004 04:23:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fmis837.omnitel.it (mailout-2.omnitel.it [194.20.71.226]) by segue.merit.edu (Postfix) with ESMTP id 268995A705 for ; Mon, 19 Jul 2004 04:23:51 -0400 (EDT) Received: from omini94.omnitel.it (omini94.omnitel.it [10.21.18.146]) by fmis837.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id i6J8NiHC022405 for ; Mon, 19 Jul 2004 10:23:44 +0200 (MET DST) Received: from omimexo06.omnitel.it ([10.21.12.196]) by ominc74.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Mon, 19 Jul 2004 10:23:42 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [AAA-WG]: Use of thresholds in DCCA Date: Mon, 19 Jul 2004 10:23:42 +0200 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB9064061C6@OMIMEXO06.omnitel.it> Thread-Topic: [AAA-WG]: Use of thresholds in DCCA Thread-Index: AcRrbn5uJw6Lg253Qj+LCxmKvBFp2AB96UMg From: "STURA Marco Consultant" To: "Mark Grayson (mgrayson)" , , , Cc: X-OriginalArrivalTime: 19 Jul 2004 08:23:42.0872 (UTC) FILETIME=[B3CC4980:01C46D69] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable >Then what happens if the "used threshold" exceeds the granted service >units. Doesn't this mean the CLCI-Client should report negative used >service units in its next CCR(update)? I think the "threshold" should be dimensioned in a way that this case is avoided (i.e. what is not consumed by the client could be re-allocated back and could guarantee that "used threshold" doesn't exceed the granted service units). Also, I think it's up to the server to avoid this case, if so wanted. For instance, by using the Final-Unit-Indication AVP the server can indicate to the client that "this is the last quota I'm granting". Therefore, shouldn't the credit in the user's account guarantee no losses in the next report, the server could send the final-unit in the current CCA. Marco =20 -----Original Message----- From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com]=20 Sent: Friday, July 16, 2004 9:53 PM To: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; marco.stura@nokia.com Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Use of thresholds in DCCA Guys I have a question about expected DCCA operation. There may be service specific documentation that defines the use of thresholds which can trigger a CCR(update) prior to full expiry of the granted service units. Then according to DCCA, when new quota is allocated these units will be used from the last measurement time - i.e., effectively meaning the used threshold is subtracted from the granted service units - and the unused threshold units are thrown away. Then what happens if the "used threshold" exceeds the granted service units. Doesn't this mean the CLCI-Client should report negative used service units in its next CCR(update)? Do we need a health warning on the use of thresholds with service specific usage of the credit control model in DCCA? Best regards, Mark ____________________________ Mark Grayson,=20 Mobile Wireless Group Cisco Systems IP Phone : +1 919-392-1809 Mobile : +1 919-413-1314 www.cisco.com/go/mobile =20 =20 From owner-aaa-wg@merit.edu Mon Jul 19 09:46: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 JAA16679 for ; Mon, 19 Jul 2004 09:46:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 009FD9125C; Mon, 19 Jul 2004 09:45:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C040F9125F; Mon, 19 Jul 2004 09:45:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5B0759125C for ; Mon, 19 Jul 2004 09:45:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0D24F5A725; Mon, 19 Jul 2004 09:45:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by segue.merit.edu (Postfix) with ESMTP id 112EB5A756 for ; Mon, 19 Jul 2004 09:45:31 -0400 (EDT) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 19 Jul 2004 15:50:17 +0200 X-BrightmailFiltered: true Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i6JDjMUB029921; Mon, 19 Jul 2004 15:45:27 +0200 (MEST) Received: from xmb-ams-33a.cisco.com ([144.254.231.85]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 19 Jul 2004 15:40:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Use of thresholds in DCCA Date: Mon, 19 Jul 2004 15:46:38 +0200 Message-ID: Thread-Topic: [AAA-WG]: Use of thresholds in DCCA Thread-Index: AcRrbn5uJw6Lg253Qj+LCxmKvBFp2AB96UMgAAvT8XA= From: "Mark Grayson (mgrayson)" To: "STURA Marco Consultant" , , , Cc: X-OriginalArrivalTime: 19 Jul 2004 13:40:40.0562 (UTC) FILETIME=[FB397D20:01C46D95] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Marco So I agree that this case SHOULD be avoided (hence my suggestion of a health warning) - but what happens if this is not the case - due to congestion or whatever (unplanned) reason. What should the DCCA-client report? Consumed units which are now greater than the amount granted?=20 Cheers, Mark -----Original Message----- From: STURA Marco Consultant [mailto:Marco.STURA@consultant.vodafoneomnitel.it]=20 Sent: 19 July 2004 04:24 To: Mark Grayson (mgrayson); Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Use of thresholds in DCCA >Then what happens if the "used threshold" exceeds the granted service >units. Doesn't this mean the CLCI-Client should report negative used >service units in its next CCR(update)? I think the "threshold" should be dimensioned in a way that this case is avoided (i.e. what is not consumed by the client could be re-allocated back and could guarantee that "used threshold" doesn't exceed the granted service units). Also, I think it's up to the server to avoid this case, if so wanted. For instance, by using the Final-Unit-Indication AVP the server can indicate to the client that "this is the last quota I'm granting". Therefore, shouldn't the credit in the user's account guarantee no losses in the next report, the server could send the final-unit in the current CCA. Marco =20 -----Original Message----- From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com]=20 Sent: Friday, July 16, 2004 9:53 PM To: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; marco.stura@nokia.com Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Use of thresholds in DCCA Guys I have a question about expected DCCA operation. There may be service specific documentation that defines the use of thresholds which can trigger a CCR(update) prior to full expiry of the granted service units. Then according to DCCA, when new quota is allocated these units will be used from the last measurement time - i.e., effectively meaning the used threshold is subtracted from the granted service units - and the unused threshold units are thrown away. Then what happens if the "used threshold" exceeds the granted service units. Doesn't this mean the CLCI-Client should report negative used service units in its next CCR(update)? Do we need a health warning on the use of thresholds with service specific usage of the credit control model in DCCA? Best regards, Mark ____________________________ Mark Grayson,=20 Mobile Wireless Group Cisco Systems IP Phone : +1 919-392-1809 Mobile : +1 919-413-1314 www.cisco.com/go/mobile =20 =20 From owner-aaa-wg@merit.edu Mon Jul 19 09:57:21 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17432 for ; Mon, 19 Jul 2004 09:57:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BAB5B9125D; Mon, 19 Jul 2004 09:57:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8C5199125E; Mon, 19 Jul 2004 09:57:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0EB449125D for ; Mon, 19 Jul 2004 09:57:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E68D75A7B1; Mon, 19 Jul 2004 09:57:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fmis437.omnitel.it (mailout-1.omnitel.it [194.20.77.121]) by segue.merit.edu (Postfix) with ESMTP id 1313A5A78C for ; Mon, 19 Jul 2004 09:57:07 -0400 (EDT) Received: from omini93.omnitel.it (omini93.omnitel.it [10.21.18.145]) by fmis437.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id i6JDv5x1004475 for ; Mon, 19 Jul 2004 15:57:05 +0200 (MET DST) Received: from omimexo06.omnitel.it ([10.21.12.196]) by ominc75.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Mon, 19 Jul 2004 15:57:03 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [AAA-WG]: Use of thresholds in DCCA Date: Mon, 19 Jul 2004 15:57:03 +0200 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB9064061C8@OMIMEXO06.omnitel.it> Thread-Topic: [AAA-WG]: Use of thresholds in DCCA Thread-Index: AcRrbn5uJw6Lg253Qj+LCxmKvBFp2AB96UMgAAvT8XAAAIhmcA== From: "STURA Marco Consultant" To: "Mark Grayson (mgrayson)" , , , Cc: X-OriginalArrivalTime: 19 Jul 2004 13:57:03.0634 (UTC) FILETIME=[452E5F20:01C46D98] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable >So I agree that this case SHOULD be avoided (hence my suggestion of a >health warning) - but what happens if this is not the case - due to >congestion or whatever (unplanned) reason. I think the warning should be given eventually in the service specific document defining the threshold(s). >Consumed units which are now greater than the amount granted? Yes, I think this is the case. Marco -----Original Message----- From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com]=20 Sent: Monday, July 19, 2004 3:47 PM To: STURA Marco Consultant; Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Use of thresholds in DCCA Marco So I agree that this case SHOULD be avoided (hence my suggestion of a health warning) - but what happens if this is not the case - due to congestion or whatever (unplanned) reason. What should the DCCA-client report? Consumed units which are now greater than the amount granted?=20 Cheers, Mark -----Original Message----- From: STURA Marco Consultant [mailto:Marco.STURA@consultant.vodafoneomnitel.it]=20 Sent: 19 July 2004 04:24 To: Mark Grayson (mgrayson); Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Use of thresholds in DCCA >Then what happens if the "used threshold" exceeds the granted service >units. Doesn't this mean the CLCI-Client should report negative used >service units in its next CCR(update)? I think the "threshold" should be dimensioned in a way that this case is avoided (i.e. what is not consumed by the client could be re-allocated back and could guarantee that "used threshold" doesn't exceed the granted service units). Also, I think it's up to the server to avoid this case, if so wanted. For instance, by using the Final-Unit-Indication AVP the server can indicate to the client that "this is the last quota I'm granting". Therefore, shouldn't the credit in the user's account guarantee no losses in the next report, the server could send the final-unit in the current CCA. Marco =20 -----Original Message----- From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com]=20 Sent: Friday, July 16, 2004 9:53 PM To: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; marco.stura@nokia.com Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Use of thresholds in DCCA Guys I have a question about expected DCCA operation. There may be service specific documentation that defines the use of thresholds which can trigger a CCR(update) prior to full expiry of the granted service units. Then according to DCCA, when new quota is allocated these units will be used from the last measurement time - i.e., effectively meaning the used threshold is subtracted from the granted service units - and the unused threshold units are thrown away. Then what happens if the "used threshold" exceeds the granted service units. Doesn't this mean the CLCI-Client should report negative used service units in its next CCR(update)? Do we need a health warning on the use of thresholds with service specific usage of the credit control model in DCCA? Best regards, Mark ____________________________ Mark Grayson,=20 Mobile Wireless Group Cisco Systems IP Phone : +1 919-392-1809 Mobile : +1 919-413-1314 www.cisco.com/go/mobile =20 =20 From owner-aaa-wg@merit.edu Mon Jul 19 10:07: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 KAA18615 for ; Mon, 19 Jul 2004 10:07:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 448A89125E; Mon, 19 Jul 2004 10:07:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 07EA69125F; Mon, 19 Jul 2004 10:07:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EEB269125E for ; Mon, 19 Jul 2004 10:07:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DAC6259CA4; Mon, 19 Jul 2004 10:07:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fmis437.omnitel.it (mailout-1.omnitel.it [194.20.77.121]) by segue.merit.edu (Postfix) with ESMTP id D060F59B63 for ; Mon, 19 Jul 2004 10:07:24 -0400 (EDT) Received: from omini94.omnitel.it (omini94.omnitel.it [10.21.18.146]) by fmis437.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id i6JE7Nx1006971 for ; Mon, 19 Jul 2004 16:07:23 +0200 (MET DST) Received: from omimexo06.omnitel.it ([10.21.12.196]) by ominc75.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Mon, 19 Jul 2004 16:07:05 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Date: Mon, 19 Jul 2004 16:07:05 +0200 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB9064061C9@OMIMEXO06.omnitel.it> Thread-Topic: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Thread-Index: AcRrHYvrNK976S5VQXORG3SSpA09BgCetOSQ From: "STURA Marco Consultant" To: X-OriginalArrivalTime: 19 Jul 2004 14:07:05.0790 (UTC) FILETIME=[AC1815E0:01C46D99] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi AAA folks, we are doing final updates to the draft mainly by integrating the IESG comments.=20 This one concerning the service-id was triggered by some change we=20 proposed upon IESG comments and is actually the only unresolved "issue". Please speak up whether you agree this Leena proposal, in case no = comments will be received by Wednesday I guess we can consider the proposal accepted. Thank you Marco -----Original Message----- From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com]=20 Sent: Friday, July 16, 2004 12:13 PM To: mwatson@nortelnetworks.com; mgrayson@cisco.com Cc: aaa-wg@merit.edu; gwz@cisco.com; cmousset@nortelnetworks.com; STURA = Marco Consultant Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Hi, we've had some discussion on the matter off-line, I switch the = discussion back to the mailing list. The main problem seems to be the = word 'service' - we do use it for two purposes ('main service' and 'the = actual service category'). We also received this kind of comment from = IESG review team but they did not have any good word in English to solve = it either ;-) How about the following split:=20 a) A Service-Context-Id is used on command level. This would be the = 'broad' service and define the context in which the DCC is being used. = The Service-Context-Id MUST be present if DCC application id is used. = Alternatively, one that introduces mandatory rating AVPs defines an own = application-id from IANA and then this AVP is not needed to guarantee = interoperability - the dedicated application id guarantees that already b) Service-Id identifies the service within the given Context. It can be = present either on command level or in MSCC. I.e. in case of ordinary one = service/session we would have both Service-Context-Id and Service-Id on = command level and in case of MSCC we would have Service-Context-Id on = command level and Service-Id in MSCC. The Service-Id values are = service-specific (in the same way as Rating-Group) An imaginary example (gaming): Service-Context-Id: game_service@foo.com Service-Id: 2 (=3Dmad man 2 - de luxe) Would that solve the wording problem with 'service', and clarify the = interoperability?=20 BR, Leena -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 7. hein=E4kuuta 2004 15:29 To: Leena Mattila (TU/LMF); 'Mark Grayson (mgrayson)'; = 'marco.stura@nokia.com' Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Claire Mousset Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Hi Leena,=20 You wrote:=20 "- when using the MSCC the Service-ID on command level is the=20 main service, e.g. Network access, and the Service-Ids within=20 the MSCC then identify the sub-services within the main service"=20 This sounds very reasonable to me, but it is not what the specification = seems to imply. There is no concept in the spec of 'services' being = 'sub-ordinate' to other 'services'. Furthermore, the fact that a = 'service' is sub-ordinate to Rating-Group implies that everything within = a service has to be rated the same. So then even if there were = sub-services within a 'main service' they would all have to be within = the same Rating-Group! But if people feel it's clear that there can be such a thing as a 'main = service' which is not part of any Rating Group and which has = sub-services, then that seems fine to me. As for (3), it doesn't seem a big deal, but does seem arbitrary - if I = want to request a quota for a single Rating-Group (which is probably the = most common case in 3GPP anyway) I need to use MSCC. ...Mark=20 -----Original Message-----=20 From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com]=20 Sent: 07 July 2004 12:00=20 To: Watson, Mark [MOP:EP10:EXCH]; 'Mark Grayson (mgrayson)'; = 'marco.stura@nokia.com'=20 Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Mousset, Claire = [ADC:8J70:EXCH]=20 Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )=20 Hi,=20 when the MSCC concept was introduced I always had the assumption that = the services within the MSCC structure are=20 sub-ordinate to some higher level service, e.g. Network Access. Having = said that, it's also true that what one can do with MSCC one should be = able=20 to do with several messages (that's where the MSCC issue initially = started). However, I still believe that those several=20 messages are inter-related (otherwise you wouldn't group them=20 in the same message, right?), and thus the exact formulation=20 would be 'what one can do with MSCC one should be able to do=20 with sub-sessions'. Hence the analogy between the two approaches is:=20 - when using the MSCC the Service-ID on command level is the=20 main service, e.g. Network access, and the Service-Ids within=20 the MSCC then identify the sub-services within the main service=20 - when using sub-sessions the Service-ID in 'main' session is=20 the main service and the Service-Ids in sub-sessions (on=20 command level) are the sub-services.=20 If there is no common factor between the Service-IDs one has=20 grouped within one MSCC, then I think they should not be=20 grouped together at all, they are then clearly not sub-ordinate services = (e.g. not carried within the same bearer) and should=20 treat them as such - optimizing signaling=20 should not be the only justification for doing the grouping.=20 And when there is a common factor, that factor should become=20 the Service-ID on command level.=20 Regarding the question (3): I'll put it the other way around:=20 At the moment it's not possible to have rating groups on=20 command level but do you see a need for it?=20 Regards,=20 Leena=20 -----Original Message-----=20 From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = Mark Watson=20 Sent: 6. hein=E4kuuta 2004 19:21=20 To: 'Mark Grayson (mgrayson)'; 'marco.stura@nokia.com'=20 Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Claire Mousset=20 Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )=20 Hi Mark,=20 Note sure what you mean by a 'rating-root', but it is quite clear (e.g. = in the diagrams in 5.1.1) that 'services' are sub-ordinate to = Rating-Groups. Since everything in a Rating-Group is rated the same way = then certainly you cannot have things within a service which are rated = differently. That is, services are the finest level of granularity that = can be separately charged. The point of MSCC was to do in one message what could otherwise be done = with several messages and only command level values - so I would expect = the things appearing in the MSCC to have the same semantics as things = appearing at command level & for the two to be mutually exclusive - = hence Question 1 below. To answre my question (2) below for myself, we don't need multiple = instances of the same service within a single sub-session. In 3GPP, I = think we may have a requirement for dynamically povisioned services, but = the dynamic provisioning of these to DCC client & server is out of scope = here & so there should be no problem. ...Mark=20 -----Original Message-----=20 From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com]=20 Sent: 06 July 2004 16:44=20 To: Watson, Mark [MOP:EP10:EXCH]; marco.stura@nokia.com=20 Cc: aaa-wg@merit.edu; Glen Zorn (gwz); Mousset, Claire [ADC:8J70:EXCH]=20 Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )=20 Mark, Marco=20 I hadn't made the same assumption - but agree that there is ambiguity = here.=20 I had asumed that when present on the command level, the service-ID = refers to the "rating-root" which then needs to be common between client = and serer.=20 Then the issue exists with re-introducing the service-ID at the MSCC = level, now possibly below the sub-session-ID which I think is the cause = of the issue. IMO these AVPs at the MSCC level should be subordinate to = the service-ID on the command level. Cheers,=20 Mark=20 From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf = Of Mark Watson=20 Sent: 06 July 2004 11:08=20 To: 'marco.stura@nokia.com'=20 Cc: 'aaa-wg@merit.edu'; Glen Zorn (gwz); Claire Mousset=20 Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: )=20 Hi Marco,=20 Some quick questions for clarification on this one...=20 1) If the client wants to request quotas for multiple services using the = Multiple-Services-Credit-Control AVP then what should it put in the = mandatory command level Service-Identifier AVP ? 2) Service-Identifier is finer granlarity than Rating-Group - that is = several services with unique Service-Identifiers are grouped within a = single Rating-Group. So a 'service' identified by a Service-Identifier = is basically the finest granularity thing that can be separately = charged. But then the definition of the Service Identifier AVP speaks of = statically configured or standardised values. To be consistent with the = above it would need to be a format or pattern than was = configured/standardised - e.g. if it's voice calls that you are charging = for then Service Identifies like 'voice001@blah.org', = 'voice002@blah.org' would be needed to distinguish between multiple = concurrent voice calls. Right ?=20 3) It isn't possible to request credit for a Rating-Group except by = using the Multiple-Services-Credit-Control AVP, right ? Regards...Mark=20 -----Original Message-----=20 From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: 05 July 2004 09:09=20 To: gwz@cisco.com=20 Cc: aaa-wg@merit.edu=20 Subject: [AAA-WG]: RE:=20 Glen,=20 the Service-Id is only included in CCR message (at command level) to = indicate=20 to the server for what specific service the request is being issued. The = server checks first the Service-Id AVP and, if it doesn't recognize the = value of this AVP, it rejects the request without any further processing = (e.g. rating or what so ever). If the server recognizes the value of the = Service-Id AVP, it continues the processing and authorizes the credit if = possible (i.e. if there is enough credit in the user's account). =20 The section 4.1 has been restructured on request of IESG review as = follow, the inclusion of the Service-Id in CCR is mandatory. Whenever = the IESG and the ADs will agree that their comments have been properly = addressed, the draft 06 will be carried out and made available. Regards=20 Marco=20 4.1 Service-Specific Rating Input and Interoperability=20 =20 The Diameter Credit-Control Application defines the framework for = credit=20 control; it provides generic credit control mechanisms supporting = multiple=20 service applications. The Credit Control Application, therefore, does = not=20 define AVPs that could be used as input in the rating process. = Listing the=20 possible services that could use this Diameter application is seen as = out=20 of scope for this generic mechanism as well. =20 =20 Furthermore, it is reasonable to expect that there will exist a = service=20 level agreement between providers of the credit-control client and = the=20 credit-control server covering the charging, services offered, = roaming=20 agreements, agreed rating input (i.e. AVPs), etc.=20 Therefore, it is assumed that a Diameter credit control server will=20 provide service only for Diameter credit-control clients that have = agreed=20 beforehand the content of credit control messages. Protocol wise, it = is=20 naturally possible that any arbitrary Diameter credit-control client = can=20 interchange credit control messages with any Diameter credit control=20 server, but with a higher likelihood that unsupported services/AVPs = could=20 be present in the credit-control message causing the server to reject = the=20 request with an appropriate result-code.=20 =20 4.1.1 Specifying Rating Input AVPs=20 =20 There are two ways for providing rating input to the credit control=20 server, either by using AVPs or by including them in the Service-=20 Parameter-Info AVP. The general principles for sending rating = parameters=20 are:=20 =20 1a. The service SHOULD re-use existing AVPs, if the service can use = AVPs=20 defined in existing Diameter applications (e.g. NASREQ for = network=20 access services). Re-use of existing AVPs is strongly recommended = in=20 [DIAMBASE].=20 For AVPs of type Enumerated the service may require a new value = to be=20 defined. Allocation of new AVP values is done as specified in=20 [DIAMBASE], section 1.2.=20 =20 1b. New AVPs can be defined if the existing AVPs do not provide = sufficient=20 rating information. In such a case, the procedures defined in=20 [DIAMBASE] for creating new AVPs MUST be followed.=20 =20 1c. For services specific only to one vendor's implementation, a = Vendor-=20 Specific AVP code for Private use can be used. Where a = Vendor-Specific=20 AVP is implemented by more than one vendor, allocation of global = AVPs=20 are encouraged instead, refer to [DIAMBASE].=20 =20 2. The Service-Parameter-Info AVP MAY be used as a container to pass=20 legacy rating information in its original encoded form (e.g. ASN.1 = BER). This method can be used to avoid unnecessary data format=20 conversions from an existing format to an AVP format. In that case = the=20 rating input is embedded in the Service-Parameter-Info AVP as = defined=20 in section 8.42.=20 =20 New service applications SHOULD favor the use of explicitly defined = AVPs=20 as described in items 1a and 1b, to simplify interoperability. =20 =20 4.1.2 Application Support=20 =20 Since the Application-Id of the Diameter Credit Control Application = does=20 not uniquely identify the service being monitored, an additional = mechanism=20 is needed. The service application MUST be identified using the = Service-=20 Identifier AVP at command level. A server receiving a request for a=20 service application it does not support will reject the request as = defined=20 in sub-section 4.1.4. The Service-Identifier AVP MUST be a unique=20 identifier for a given service as defined in section 8.28. =20 =20 Thus, the combination of the Diameter Credit Control Application-Id = and=20 the Service-Identifier AVP in the Credit-Control-Request command = uniquely=20 defines the service within the context of the Diameter Credit = Control, and=20 hence provides interoperability between Diameter credit control = clients=20 and server.=20 =20 With this mechanism it is possible to cover additional service = specific=20 requirements as needed in other documents. However, introducing new = credit=20 control mechanisms to the framework defined in this specification, = require=20 definition of a new version of the Diameter Credit Control = Application and=20 corresponding Application Identifier.=20 =20 4.1.3 Service-Specific Documentation=20 =20 The service specific rating input AVPs, the contents of the Service-=20 Parameter-Info AVP or Service-Identifier AVP are not within the scope = of=20 this document. To facilitate interoperability, it is RECOMMENDED that = the=20 rating input and the values of the service identifiers are = coordinated via=20 an informational RFC or other permanent and readily available = reference=20 such as the specification of another cooperative standardization body = (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services = may=20 be deployed that are subject to agreements between providers of the = credit=20 control server and client, in this case vendor specific AVPs can be = used. =20 =20 This specification, together with the above service specific = documents,=20 governs the credit control message. The rule is that service specific = documents define what existing AVPs or new AVPs are used as input to = the=20 rating process (i.e. they do not define new credit control = applications),=20 and thus need to be included in the Credit-Control-Request command by = a=20 Diameter Credit Control Client supporting a given service as *[AVP].=20 Should Service-Parameter-Info be used, then the service specific = document=20 MUST specify the exact content of this grouped AVP.=20 =20 4.1.4 Handling of Unsupported/Incorrect Rating Input =20 =20 Diameter credit control implementations are required to support the=20 Mandatory rating AVPs defined in service specific documentation of = the=20 services they support according to the 'M' bit rules in [DIAMBASE]. =20 =20 In case a rating input required for the rating process is incorrect = in the=20 Credit control request, or the credit control server does not support = the=20 requested service (identified by the Service-Idntifier AVP at command = level), the Credit control answer MUST contain error code=20 DIAMETER_RATING_FAILED. A CCR message with this error MUST contain = one or=20 more Failed-AVP AVPs containing the missing and/or unsupported AVPs = that=20 caused the failure. A Diameter credit control client receiving error = code=20 DIAMETER_RATING_FAILED in answer to a request MUST NOT send such = similar=20 requests in the future.=20 =20 4.1.5 RADIUS Vendor-Specific Rating Attributes=20 =20 When service specific documents include RADIUS vendor specific = attributes=20 that could be used as input in the rating process, the rules = described in=20 [NASREQ] for formatting the Diameter AVP MUST be followed. For = example,=20 the AVP code used is the vendor attribute type code, the = Vendor-Specific=20 flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA = Vendor=20 identification value. The Diameter AVP data field contains only the=20 attribute value of the RADIUS attribute.=20 > -----Original Message-----=20 > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of=20 > ext Glen Zorn=20 > Sent: 02 July, 2004 20:27=20 > To: aaa-wg@merit.edu=20 > Subject:=20 >=20 >=20 > Description of issue: No guarantee of interoperability=20 > between CCA implementations=20 > Submitter name: Glen Zorn=20 > Submitter email address: gwz@cisco.com=20 > Date first submitted: 2 July 2004=20 > Document: dcca=20 > Comment type: T=20 > Priority: S=20 > Section: 4.1=20 > Rationale/Explanation of issue:=20 > In order to interoperate, Diameter peers implementing the=20 > Diameter Credit Control Application must agree upon both the=20 > application and the service (specified in the=20 > Service-Identifier AVP). However, the inclusion of the=20 > Service-Identifier in the CCR and CCA messages is optional.=20 >=20 > Lengthy description of problem:=20 > Section 4.1, para. 6 states "it is the combination of support=20 > of the Diameter Credit Control Application and the service=20 > defined in the Service-Identifier AVP, which defines=20 > interoperability between any given credit control client and=20 > server." However, the inclusion of the Service-Identifier in=20 > the CCR and CCA messages is optional. This gives rise to a=20 > situation where two peers implementing the same application=20 > may not interoperate because they do not implement the same=20 > "service", and further, refuse to clearly communicate that fact.=20 >=20 > Requested change:=20 > Change section 4.1, paragraph 5 from=20 >=20 > This specification, together with service specific documents, is=20 > governing the credit control message. The rule is that service=20 > specific documents only define what existing AVPs or new AVPs are=20 > used as input to the rating process (i.e. they do not define new=20 > credit control applications), and thus need to be included in the=20 > Credit-Control-Request command by a Diameter Credit Control Client=20 > supporting a given service as *[AVP]. In order to define new AVPs,=20 > service specific documents MUST follow the practices defined in=20 > [DIAMBASE]. The service SHOULD be identified using the Service-=20 > Identifier AVP. The Service-Identifier AVP MUST be a unique=20 > identifier for a given service as defined in section 8.28.=20 >=20 > to=20 >=20 > This specification, together with service specific documents, is=20 > governing the credit control message. The rule is that service=20 > specific documents only define what existing AVPs or new AVPs are=20 > used as input to the rating process (i.e. they do not define new=20 > credit control applications), and thus need to be included in the=20 > Credit-Control-Request command by a Diameter Credit Control Client=20 > supporting a given service as *[AVP]. In order to define new AVPs,=20 > service specific documents MUST follow the practices defined in=20 > [DIAMBASE]. The service MUST be identified using the Service-=20 > Identifier AVP. The Service-Identifier AVP MUST be a unique=20 > identifier for a given service as defined in section 8.28.=20 >=20 > ~gwz=20 >=20 > "They that can give up essential liberty to obtain a little=20 > temporary safety deserve neither..."=20 > -- Benjamin Franklin, 1759=20 >=20 >=20 > "It is forbidden to kill; therefore all murderers are=20 > punished unless they kill in large numbers and to the sound=20 > of trumpets."=20 > -- Voltaire=20 >=20 >=20 From owner-aaa-wg@merit.edu Mon Jul 19 18:49: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 SAA27500 for ; Mon, 19 Jul 2004 18:49:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DBCEB9123B; Mon, 19 Jul 2004 18:49:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A567B9123D; Mon, 19 Jul 2004 18:49:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1E2B89123B for ; Mon, 19 Jul 2004 18:49:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0A62E59F1F; Mon, 19 Jul 2004 18:49:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h013.c000.snv.cp.net [209.228.32.77]) by segue.merit.edu (Postfix) with SMTP id 9F5EA59E5B for ; Mon, 19 Jul 2004 18:49:19 -0400 (EDT) Received: (cpmta 5570 invoked from network); 19 Jul 2004 15:49:18 -0700 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.77) with SMTP; 19 Jul 2004 15:49:18 -0700 X-Sent: 19 Jul 2004 22:49:18 GMT Message-Id: <5.2.1.1.2.20040719184841.03279620@mail.comcast.net> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 19 Jul 2004 18:48:47 -0400 To: aaa-wg@merit.edu From: David Mitton Subject: [AAA-WG]: Diameter NASreq draft 17 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk I've submitted a new version to ietf-drafts A copy is availible at: http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-17.txt Changes are: 18-July-2004 Document Editor: David Mitton --- Issue # 468 Summary Description: Missing "[Failed AVP]" in AAA ABNF Document review found several inconsistencies in error reporting AVPs in the message ABNFs and occurance tables. a) Inserted in AAA, and ACA ABNF * [ Failed-AVP ] b) Inserted missing in ACA ABNF [Error-Message] c) Removed redundant from RAA ABNF [Error-Message] [Error-Reporting-Host] d) Inserted Error-Message and Failed-AVP in Accounting occurence tables. Section 10.2. e) Corrected occurance of Error-Reporting-Host in Non-Framed ACA table from 0+ to 0-1 Question: Why is Failed-AVP 0+ in Request messages? (Table 10.1, page 75) Can a Failed AVP be forwarded in a non-Answer message? ----- Issue # 466 Description: Missing QoSFilterRule AVP Inserted proposed text as section 6.9 (old 6.9++) Assigned AVP code 407 Section renumbering and reference fixups. Added the new AVP to the ABNF for AAA, ACR Added the new AVP to table of Section 6. Added the new AVP to the AVP occurance tables in Section 10. Changed occurance of NAS-Filter rule to 0+ in ACR Added DIFFSERV, DIFFSERVAF, and DIFFSERVEF as Informative references ---- Issue # 464 Application-Id usage Section 1.3, Advertising Application Support, now says: Diameter applications conforming to this specification MUST advertise support by including the value of one (1) in the Auth-Application-Id of Capabilities-Exchange-Request (CER), AA-Request (AAR) and AA-Answer (AAA) messages. All other messages are defined by [Base] and use the Base application id value. ---- Updated dates, Realigned tables, page breaks From owner-aaa-wg@merit.edu Tue Jul 20 09:19: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 JAA18004 for ; Tue, 20 Jul 2004 09:19:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2F14091203; Tue, 20 Jul 2004 09:19:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2A2991207; Tue, 20 Jul 2004 09:19:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A58E891203 for ; Tue, 20 Jul 2004 09:19:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 76CE75A2A2; Tue, 20 Jul 2004 09:19:19 -0400 (EDT) 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 AF32B59E01 for ; Tue, 20 Jul 2004 09:19:16 -0400 (EDT) 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 i6KDIY010257; Tue, 20 Jul 2004 14:18:34 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Jul 2004 14:18:34 +0100 Message-ID: <588B15E2E2B1D41180B800508BF934F20FD23D0B@bmdhd6.europe.nortel.com> From: "Mark Watson" To: "'Leena Mattila (TU/LMF)'" , "'mgrayson@cisco.com'" Cc: "'aaa-wg@merit.edu'" , "'gwz@cisco.com'" , "Claire Mousset" , "'Marco.STURA@consultant.vodafoneomnitel.it'" Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) Date: Tue, 20 Jul 2004 14:18:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46E5C.0B572A88" 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_01C46E5C.0B572A88 Content-Type: text/plain; charset="iso-8859-1" Hi Leena, all, A Service-Context-Identitifer AVP, as you propose below would be acceptable for me. It is much clearer than using Service-Identifier for this purpose. Especially given all the text we have which suggests that Service-Identifier is a very specific thing, sub-ordinate to Rating-Group. Rating-Groups should also be defined 'withing the given context'. Looking at the text proposed by Marco on 5th July, I think we can amend this fairly easily. It is the proposed section 4.1.2 that uses the term 'service' in a confusing way. I suggest deleting this and then stating at the end of 4.1.3 that it is the Service-Context-Identifier which identifies the 'service specific document' that applies to the request. So, then, the Service-Context-Identifier scopes the interpretation of the Service-Identifier and Rating-Group. Actually, for Rating-Groups I can see how this can be useful, since they are just numbers which otherwise would require coordination in their use throughout a service provider's network. Proposed modification to Marco's text at the end of this mail (I also have a word/pdf version with changebars which I can send to anyone who wants it). Additionally, now that the meaning of Service-Identifiers and their relationship to Rating-Groups is clearer, it seems clear that the granularity of counting at the client (per service vs per RG) should be a service provider option, based on their charging requirements, rather than something to be recommended in the RFC. We need to soften very slightly the recommendation to report on a per service granularity: In section 5.1.1 change: It is up to the credit control server whether to authorize credit for one or more services or for the whole rating-group, but the client SHOULD always report used units itemizing the service level usage. To: It is up to the credit control server whether to authorize credit for one or more specific services or for the whole rating-group. However, the client SHOULD always report used units at the finest level of granularity that it supports. Regards...Mark -----------proposed new version of Marco's proposal for Section 4 ---------> 4.1 Service-Specific Rating Input and Interoperability The Diameter Credit-Control Application defines the framework for credit control; it provides generic credit control mechanisms supporting multiple service applications. The Credit Control Application, therefore, does not define AVPs that could be used as input in the rating process. Listing the possible services that could use this Diameter application is seen as out of scope for this generic mechanism as well. Furthermore, it is reasonable to expect that there will exist a service level agreement between providers of the credit-control client and the credit-control server covering the charging, services offered, roaming agreements, agreed rating input (i.e. AVPs), etc. Therefore, it is assumed that a Diameter credit control server will provide service only for Diameter credit-control clients that have agreed beforehand the content of credit control messages. Protocol wise, it is naturally possible that any arbitrary Diameter credit-control client can interchange credit control messages with any Diameter credit control server, but with a higher likelihood that unsupported services/AVPs could be present in the credit-control message causing the server to reject the request with an appropriate result-code. 4.1.1 Specifying Rating Input AVPs There are two ways for providing rating input to the credit control server, either by using AVPs or by including them in the Service-Parameter-Info AVP. The general principles for sending rating parameters are: 1a. The service SHOULD re-use existing AVPs, if theservice can use AVPs defined in existing Diameter applications (e.g. NASREQ for network access services). Re-use of existing AVPs is strongly recommended in [DIAMBASE]. For AVPs of type Enumerated the service may require a new value to be defined. Allocation of new AVP values is done as specified in [DIAMBASE], section 1.2. 1b. New AVPs can be defined if the existing AVPs do not provide sufficient rating information. In such a case, the procedures defined in [DIAMBASE] for creating new AVPs MUST be followed. 1c. For services specific only to one vendor's implementation, a Vendor-Specific AVP code for Private use can be used. Where a Vendor-Specific AVP is implemented by more than one vendor, allocation of global AVPs are encouraged instead, refer to [DIAMBASE]. 2. The Service-Parameter-Info AVP MAY be used as a container to pass legacy rating information in its original encoded form (e.g. ASN.1 BER). This method can be used to avoid unnecessary data format conversions from an existing format to an AVP format. In that case the rating input is embedded in the Service-Parameter-Info AVP as defined in section 8.42. New service applications SHOULD favor the use of explicitly defined AVPs as described in items 1a and 1b, to simplify interoperability. 4.1.2 Service-Specific Documentation The service specific rating input AVPs, the contents of the Service-Parameter-Info AVP or Service-Identifier AVP are not within the scope of this document. To facilitate interoperability, it is RECOMMENDED that the rating input and the values of the service identifiers are coordinated via an informational RFC or other permanent and readily available reference such as the specification of another cooperative standardization body (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services may be deployed that are subject to agreements between providers of the credit control server and client, in this case vendor specific AVPs can be used. This specification, together with the above service specific documents, governs the credit control message. The rule is that service specific documents define what existing AVPs or new AVPs are used as input to the rating process (i.e. they do not define new credit control applications), and thus need to be included in the Credit-Control-Request command by a Diameter Credit Control Client supporting a given service as *[AVP]. Should Service-Parameter-Info be used, then the service specific document MUST specify the exact content of this grouped AVP. The Service-Context-Identifier AVP MUST be included at the command level of a Credit Control Request to identify the service specific document that applies to the request. The specific service or rating group that the request relates to is uniquely identified by the combination of Service-Context-Identifier and Service-Identifier or Rating-Group. 4.1.3 Handling of Unsupported/Incorrect Rating Input Diameter credit control implementations are required to support the Mandatory rating AVPs defined in service specific documentation of the services they support according to the 'M' bit rules in [DIAMBASE]. In case a rating input required for the rating process is incorrect in the Credit control request, or the credit control server does not support the requested service context (identified by the combination of Service-Context-Identifier AVP at command level), the Credit control answer MUST contain error code DIAMETER_RATING_FAILED. A CCR message with this error MUST contain one or more Failed-AVP AVPs containing the missing and/or unsupported AVPs that caused the failure. A Diameter credit control client receiving error code DIAMETER_RATING_FAILED in answer to a request MUST NOT send such similar requests in the future. 4.1.4 RADIUS Vendor-Specific Rating Attributes When service specific documents include RADIUS vendor specific attributes that could be used as input in the rating process, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute. --------------------------------------------------------------------------- > -----Original Message----- > From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com] > Sent: 16 July 2004 11:13 > To: Watson, Mark [MOP:EP10:EXCH]; mgrayson@cisco.com > Cc: aaa-wg@merit.edu; gwz@cisco.com; Mousset, Claire > [ADC:8J70:EXCH]; 'Marco.STURA@consultant.vodafoneomnitel.it' > Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) > > > Hi, > > we've had some discussion on the matter off-line, I switch > the discussion back to the mailing list. The main problem > seems to be the word 'service' - we do use it for two > purposes ('main service' and 'the actual service category'). > We also received this kind of comment from IESG review team > but they did not have any good word in English to solve it > either ;-) How about the following split: > > a) A Service-Context-Id is used on command level. This would > be the 'broad' service and define the context in which the > DCC is being used. The Service-Context-Id MUST be present if > DCC application id is used. Alternatively, one that > introduces mandatory rating AVPs defines an own > application-id from IANA and then this AVP is not needed to > guarantee interoperability - the dedicated application id > guarantees that already > > b) Service-Id identifies the service within the given > Context. It can be present either on command level or in > MSCC. I.e. in case of ordinary one service/session we would > have both Service-Context-Id and Service-Id on command level > and in case of MSCC we would have Service-Context-Id on > command level and Service-Id in MSCC. The Service-Id values > are service-specific (in the same way as Rating-Group) An > imaginary example (gaming): > Service-Context-Id: game_service@foo.com > Service-Id: 2 (=mad man 2 - de luxe) > > Would that solve the wording problem with 'service', and > clarify the interoperability? > > BR, > Leena > > -----Original Message----- > From: Mark Watson [mailto:mwatson@nortelnetworks.com] > Sent: 7. heinäkuuta 2004 15:29 > To: Leena Mattila (TU/LMF); 'Mark Grayson (mgrayson)'; > 'marco.stura@nokia.com' > Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Claire Mousset > Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) > > > Hi Leena, > You wrote: > "- when using the MSCC the Service-ID on command level is the > main service, e.g. Network access, and the Service-Ids within > the MSCC then identify the sub-services within the main service" > This sounds very reasonable to me, but it is not what the > specification seems to imply. There is no concept in the spec > of 'services' being 'sub-ordinate' to other 'services'. > Furthermore, the fact that a 'service' is sub-ordinate to > Rating-Group implies that everything within a service has to > be rated the same. So then even if there were sub-services > within a 'main service' they would all have to be within the > same Rating-Group! But if people feel it's clear that there > can be such a thing as a 'main service' which is not part of > any Rating Group and which has sub-services, then that seems > fine to me. As for (3), it doesn't seem a big deal, but does > seem arbitrary - if I want to request a quota for a single > Rating-Group (which is probably the most common case in 3GPP > anyway) I need to use MSCC. ...Mark > -----Original Message----- > From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com] > Sent: 07 July 2004 12:00 > To: Watson, Mark [MOP:EP10:EXCH]; 'Mark Grayson (mgrayson)'; > 'marco.stura@nokia.com' > Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Mousset, Claire > [ADC:8J70:EXCH] > Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) > > > Hi, > when the MSCC concept was introduced I always had the > assumption that the services within the MSCC structure are > sub-ordinate to some higher level service, e.g. Network > Access. Having said that, it's also true that what one can do > with MSCC one should be able > to do with several messages (that's where the MSCC issue > initially started). However, I still believe that those several > messages are inter-related (otherwise you wouldn't group them > in the same message, right?), and thus the exact formulation > would be 'what one can do with MSCC one should be able to do > with sub-sessions'. Hence the analogy between the two approaches is: > - when using the MSCC the Service-ID on command level is the > main service, e.g. Network access, and the Service-Ids within > the MSCC then identify the sub-services within the main service > - when using sub-sessions the Service-ID in 'main' session is > the main service and the Service-Ids in sub-sessions (on > command level) are the sub-services. > If there is no common factor between the Service-IDs one has > grouped within one MSCC, then I think they should not be > grouped together at all, they are then clearly not > sub-ordinate services (e.g. not carried within the same > bearer) and should > treat them as such - optimizing signaling > should not be the only justification for doing the grouping. > And when there is a common factor, that factor should become > the Service-ID on command level. > Regarding the question (3): I'll put it the other way around: > At the moment it's not possible to have rating groups on > command level but do you see a need for it? > Regards, > Leena > -----Original Message----- > From: owner-aaa-wg@merit.edu > [mailto:owner-aaa-wg@merit.edu]On Behalf Of Mark Watson > Sent: 6. heinäkuuta 2004 19:21 > To: 'Mark Grayson (mgrayson)'; 'marco.stura@nokia.com' > Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; Claire Mousset > Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) > > > Hi Mark, > Note sure what you mean by a 'rating-root', but it is quite > clear (e.g. in the diagrams in 5.1.1) that 'services' are > sub-ordinate to Rating-Groups. Since everything in a > Rating-Group is rated the same way then certainly you cannot > have things within a service which are rated differently. > That is, services are the finest level of granularity that > can be separately charged. The point of MSCC was to do in one > message what could otherwise be done with several messages > and only command level values - so I would expect the things > appearing in the MSCC to have the same semantics as things > appearing at command level & for the two to be mutually > exclusive - hence Question 1 below. To answre my question (2) > below for myself, we don't need multiple instances of the > same service within a single sub-session. In 3GPP, I think we > may have a requirement for dynamically povisioned services, > but the dynamic provisioning of these to DCC client & server > is out of scope here & so there should be no problem. ...Mark > -----Original Message----- > From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com] > Sent: 06 July 2004 16:44 > To: Watson, Mark [MOP:EP10:EXCH]; marco.stura@nokia.com > Cc: aaa-wg@merit.edu; Glen Zorn (gwz); Mousset, Claire > [ADC:8J70:EXCH] > Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) > > > Mark, Marco > I hadn't made the same assumption - but agree that there is > ambiguity here. > I had asumed that when present on the command level, the > service-ID refers to the "rating-root" which then needs to be > common between client and serer. > Then the issue exists with re-introducing the service-ID at > the MSCC level, now possibly below the sub-session-ID which I > think is the cause of the issue. IMO these AVPs at the MSCC > level should be subordinate to the service-ID on the command > level. Cheers, > Mark > > > > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] > On Behalf Of Mark Watson > Sent: 06 July 2004 11:08 > To: 'marco.stura@nokia.com' > Cc: 'aaa-wg@merit.edu'; Glen Zorn (gwz); Claire Mousset > Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) > > > Hi Marco, > Some quick questions for clarification on this one... > 1) If the client wants to request quotas for multiple > services using the Multiple-Services-Credit-Control AVP then > what should it put in the mandatory command level > Service-Identifier AVP ? > 2) Service-Identifier is finer granlarity than Rating-Group - > that is several services with unique Service-Identifiers are > grouped within a single Rating-Group. So a 'service' > identified by a Service-Identifier is basically the finest > granularity thing that can be separately charged. But then > the definition of the Service Identifier AVP speaks of > statically configured or standardised values. To be > consistent with the above it would need to be a format or > pattern than was configured/standardised - e.g. if it's voice > calls that you are charging for then Service Identifies like > 'voice001@blah.org', 'voice002@blah.org' would be needed to > distinguish between multiple concurrent voice calls. Right ? > 3) It isn't possible to request credit for a Rating-Group > except by using the Multiple-Services-Credit-Control AVP, > right ? Regards...Mark > > > -----Original Message----- > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] > Sent: 05 July 2004 09:09 > To: gwz@cisco.com > Cc: aaa-wg@merit.edu > Subject: [AAA-WG]: RE: > > > Glen, > the Service-Id is only included in CCR message (at command > level) to indicate > to the server for what specific service the request is being > issued. The server checks first the Service-Id AVP and, if it > doesn't recognize the value of this AVP, it rejects the > request without any further processing (e.g. rating or what > so ever). If the server recognizes the value of the > Service-Id AVP, it continues the processing and authorizes > the credit if possible (i.e. if there is enough credit in the > user's account). > The section 4.1 has been restructured on request of IESG > review as follow, the inclusion of the Service-Id in CCR is > mandatory. Whenever the IESG and the ADs will agree that > their comments have been properly addressed, the draft 06 > will be carried out and made available. Regards > Marco > 4.1 Service-Specific Rating Input and Interoperability > > The Diameter Credit-Control Application defines the > framework for credit > control; it provides generic credit control mechanisms > supporting multiple > service applications. The Credit Control Application, > therefore, does not > define AVPs that could be used as input in the rating > process. Listing the > possible services that could use this Diameter application > is seen as out > of scope for this generic mechanism as well. > > Furthermore, it is reasonable to expect that there will > exist a service > level agreement between providers of the credit-control > client and the > credit-control server covering the charging, services > offered, roaming > agreements, agreed rating input (i.e. AVPs), etc. > Therefore, it is assumed that a Diameter credit control > server will > provide service only for Diameter credit-control clients > that have agreed > beforehand the content of credit control messages. > Protocol wise, it is > naturally possible that any arbitrary Diameter > credit-control client can > interchange credit control messages with any Diameter > credit control > server, but with a higher likelihood that unsupported > services/AVPs could > be present in the credit-control message causing the > server to reject the > request with an appropriate result-code. > > 4.1.1 Specifying Rating Input AVPs > > There are two ways for providing rating input to the > credit control > server, either by using AVPs or by including them in the Service- > Parameter-Info AVP. The general principles for sending > rating parameters > are: > > 1a. The service SHOULD re-use existing AVPs, if the > service can use AVPs > defined in existing Diameter applications (e.g. NASREQ > for network > access services). Re-use of existing AVPs is strongly > recommended in > [DIAMBASE]. > For AVPs of type Enumerated the service may require a > new value to be > defined. Allocation of new AVP values is done as specified in > [DIAMBASE], section 1.2. > > 1b. New AVPs can be defined if the existing AVPs do not > provide sufficient > rating information. In such a case, the procedures defined in > [DIAMBASE] for creating new AVPs MUST be followed. > > 1c. For services specific only to one vendor's > implementation, a Vendor- > Specific AVP code for Private use can be used. Where a > Vendor-Specific > AVP is implemented by more than one vendor, allocation > of global AVPs > are encouraged instead, refer to [DIAMBASE]. > > 2. The Service-Parameter-Info AVP MAY be used as a > container to pass > legacy rating information in its original encoded form > (e.g. ASN.1 > BER). This method can be used to avoid unnecessary data format > conversions from an existing format to an AVP format. > In that case the > rating input is embedded in the Service-Parameter-Info > AVP as defined > in section 8.42. > > New service applications SHOULD favor the use of > explicitly defined AVPs > as described in items 1a and 1b, to simplify interoperability. > > 4.1.2 Application Support > > Since the Application-Id of the Diameter Credit Control > Application does > not uniquely identify the service being monitored, an > additional mechanism > is needed. The service application MUST be identified > using the Service- > Identifier AVP at command level. A server receiving a > request for a > service application it does not support will reject the > request as defined > in sub-section 4.1.4. The Service-Identifier AVP MUST be a unique > identifier for a given service as defined in section 8.28. > > Thus, the combination of the Diameter Credit Control > Application-Id and > the Service-Identifier AVP in the Credit-Control-Request > command uniquely > defines the service within the context of the Diameter > Credit Control, and > hence provides interoperability between Diameter credit > control clients > and server. > > With this mechanism it is possible to cover additional > service specific > requirements as needed in other documents. However, > introducing new credit > control mechanisms to the framework defined in this > specification, require > definition of a new version of the Diameter Credit Control > Application and > corresponding Application Identifier. > > 4.1.3 Service-Specific Documentation > > The service specific rating input AVPs, the contents of > the Service- > Parameter-Info AVP or Service-Identifier AVP are not > within the scope of > this document. To facilitate interoperability, it is > RECOMMENDED that the > rating input and the values of the service identifiers are > coordinated via > an informational RFC or other permanent and readily > available reference > such as the specification of another cooperative > standardization body > (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, > private services may > be deployed that are subject to agreements between > providers of the credit > control server and client, in this case vendor specific > AVPs can be used. > > This specification, together with the above service > specific documents, > governs the credit control message. The rule is that > service specific > documents define what existing AVPs or new AVPs are used > as input to the > rating process (i.e. they do not define new credit control > applications), > and thus need to be included in the Credit-Control-Request > command by a > Diameter Credit Control Client supporting a given service > as *[AVP]. > Should Service-Parameter-Info be used, then the service > specific document > MUST specify the exact content of this grouped AVP. > > 4.1.4 Handling of Unsupported/Incorrect Rating Input > > Diameter credit control implementations are required to > support the > Mandatory rating AVPs defined in service specific > documentation of the > services they support according to the 'M' bit rules in > [DIAMBASE]. > > In case a rating input required for the rating process is > incorrect in the > Credit control request, or the credit control server does > not support the > requested service (identified by the Service-Idntifier AVP > at command > level), the Credit control answer MUST contain error code > DIAMETER_RATING_FAILED. A CCR message with this error MUST > contain one or > more Failed-AVP AVPs containing the missing and/or > unsupported AVPs that > caused the failure. A Diameter credit control client > receiving error code > DIAMETER_RATING_FAILED in answer to a request MUST NOT > send such similar > requests in the future. > > 4.1.5 RADIUS Vendor-Specific Rating Attributes > > When service specific documents include RADIUS vendor > specific attributes > that could be used as input in the rating process, the > rules described in > [NASREQ] for formatting the Diameter AVP MUST be followed. > For example, > the AVP code used is the vendor attribute type code, the > Vendor-Specific > flag MUST be set to 1 and the Vendor-ID MUST be set to the > IANA Vendor > identification value. The Diameter AVP data field contains > only the > attribute value of the RADIUS attribute. > > -----Original Message----- > > From: owner-aaa-wg@merit.edu > > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > ext Glen Zorn > > Sent: 02 July, 2004 20:27 > > To: aaa-wg@merit.edu > > Subject: > > > > > > Description of issue: No guarantee of interoperability > > between CCA implementations > > Submitter name: Glen Zorn > > Submitter email address: gwz@cisco.com > > Date first submitted: 2 July 2004 > > Document: dcca > > Comment type: T > > Priority: S > > Section: 4.1 > > Rationale/Explanation of issue: > > In order to interoperate, Diameter peers implementing the > > Diameter Credit Control Application must agree upon both the > > application and the service (specified in the > > Service-Identifier AVP). However, the inclusion of the > > Service-Identifier in the CCR and CCA messages is optional. > > > > Lengthy description of problem: > > Section 4.1, para. 6 states "it is the combination of support > > of the Diameter Credit Control Application and the service > > defined in the Service-Identifier AVP, which defines > > interoperability between any given credit control client and > > server." However, the inclusion of the Service-Identifier in > > the CCR and CCA messages is optional. This gives rise to a > > situation where two peers implementing the same application > > may not interoperate because they do not implement the same > > "service", and further, refuse to clearly communicate that fact. > > > > Requested change: > > Change section 4.1, paragraph 5 from > > > > This specification, together with service specific documents, is > > governing the credit control message. The rule is that service > > specific documents only define what existing AVPs or new > AVPs are > > used as input to the rating process (i.e. they do not define new > > credit control applications), and thus need to be > included in the > > Credit-Control-Request command by a Diameter Credit > Control Client > > supporting a given service as *[AVP]. In order to define > new AVPs, > > service specific documents MUST follow the practices defined in > > [DIAMBASE]. The service SHOULD be identified using the Service- > > Identifier AVP. The Service-Identifier AVP MUST be a unique > > identifier for a given service as defined in section 8.28. > > > > to > > > > This specification, together with service specific documents, is > > governing the credit control message. The rule is that service > > specific documents only define what existing AVPs or new > AVPs are > > used as input to the rating process (i.e. they do not define new > > credit control applications), and thus need to be > included in the > > Credit-Control-Request command by a Diameter Credit > Control Client > > supporting a given service as *[AVP]. In order to define > new AVPs, > > service specific documents MUST follow the practices defined in > > [DIAMBASE]. The service MUST be identified using the Service- > > Identifier AVP. The Service-Identifier AVP MUST be a unique > > identifier for a given service as defined in section 8.28. > > > > ~gwz > > > > "They that can give up essential liberty to obtain a little > > temporary safety deserve neither..." > > -- Benjamin Franklin, 1759 > > > > > > "It is forbidden to kill; therefore all murderers are > > punished unless they kill in large numbers and to the sound > > of trumpets." > > -- Voltaire > > > > > ------_=_NextPart_001_01C46E5C.0B572A88 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Hi Leena, all,

A Service-Context-Identitifer AVP, as you propose = below would be acceptable for me. It is much clearer than using = Service-Identifier for this purpose. Especially given all the text we = have which suggests that Service-Identifier is a very specific thing, = sub-ordinate to Rating-Group.

Rating-Groups should also be defined 'withing the = given context'.

Looking at the text proposed by Marco on 5th July, I = think we can amend this fairly easily. It is the proposed section 4.1.2 = that uses the term 'service' in a confusing way. I suggest deleting = this and then stating at the end of 4.1.3 that it is the = Service-Context-Identifier which identifies the 'service specific = document' that applies to the request.

So, then, the Service-Context-Identifier scopes the = interpretation of the Service-Identifier and Rating-Group. Actually, = for Rating-Groups I can see how this can be useful, since they are just = numbers which otherwise would require coordination in their use = throughout a service provider's network.

Proposed modification to Marco's text at the end of = this mail (I also have a word/pdf version with changebars which I can = send to anyone who wants it).

Additionally, now that the meaning of = Service-Identifiers and their relationship to Rating-Groups is clearer, = it seems clear that the granularity of counting at the client (per = service vs per RG) should be a service provider option, based on their = charging requirements, rather than something to be recommended in the = RFC. We need to soften very slightly the recommendation to report on a = per service granularity:

In section 5.1.1 change:

   It is up to the credit control
   server whether to authorize credit for = one or more services or for
   the whole rating-group, but the client = SHOULD always report used
   units itemizing the service level = usage. 

To:

   It is up to the credit control
   server whether to authorize credit for = one or more specific services
   or for the whole rating-group. However, = the client SHOULD always report
   used units at the finest level of = granularity that it supports.

Regards...Mark

-----------proposed new version of Marco's proposal = for Section 4 --------->

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

Furthermore, it is reasonable to expect that there = will exist a service level agreement between providers of the = credit-control client and the credit-control server covering the = charging, services offered, roaming agreements, agreed rating input = (i.e. AVPs), etc.

Therefore, it is assumed that a Diameter credit = control server will provide service only for Diameter credit-control = clients that have agreed beforehand the content of credit control = messages. Protocol wise, it is naturally possible that any arbitrary = Diameter credit-control client can interchange credit control messages = with any Diameter credit control server, but with a higher likelihood = that unsupported services/AVPs could be present in the credit-control = message causing the server to reject the request with an appropriate = result-code.

    
4.1.1 Specifying Rating Input AVPs
  
There are two ways for providing rating input to the = credit control server, either by using AVPs or by including them in the = Service-Parameter-Info AVP. The general principles for sending rating = parameters are:

  
1a. The service SHOULD re-use existing AVPs, if = theservice can use AVPs defined in existing Diameter applications (e.g. = NASREQ for network access services). Re-use of existing AVPs is = strongly recommended in [DIAMBASE].

For AVPs of type Enumerated the service may require a = new value to be defined. Allocation of new AVP values is done as = specified in [DIAMBASE], section 1.2.

 
1b. New AVPs can be defined if the existing AVPs do = not provide sufficient rating information. In such a case, the = procedures defined in [DIAMBASE] for creating new AVPs MUST be = followed.

  
1c. For services specific only to one vendor's = implementation, a Vendor-Specific AVP code for Private use can be used. = Where a Vendor-Specific AVP is implemented by more than one vendor, = allocation of global AVPs are encouraged instead, refer to [DIAMBASE]. =

  
2. The Service-Parameter-Info AVP MAY be used as a = container to pass legacy rating information in its original encoded = form (e.g. ASN.1 BER). This method can be used to avoid unnecessary = data format conversions from an existing format to an AVP format. =

In that case the rating input is embedded in the = Service-Parameter-Info AVP as defined in section 8.42.

New service applications SHOULD favor the use of = explicitly defined AVPs as described in items 1a and 1b, to simplify = interoperability. 

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

This specification, together with the above service = specific documents, governs the credit control message. The rule is = that service specific documents define what existing AVPs or new AVPs = are used as input to the rating process (i.e. they do not define new = credit control applications), and thus need to be included in the = Credit-Control-Request command by a Diameter Credit Control Client = supporting a given service as *[AVP]. Should Service-Parameter-Info be = used, then the service specific document MUST specify the exact content = of this grouped AVP.

The Service-Context-Identifier AVP MUST be included = at the command level of a Credit Control Request to identify the = service specific document that applies to the request. The specific = service or rating group that the request relates to is uniquely = identified by the combination of Service-Context-Identifier and = Service-Identifier or Rating-Group.

 
4.1.3 Handling of Unsupported/Incorrect Rating = Input
 
Diameter credit control implementations are required = to support the Mandatory rating AVPs defined in service specific = documentation of the services they support according to the 'M' bit = rules in [DIAMBASE]. 

       
In case a rating input required for the rating = process is incorrect in the Credit control request, or the credit = control server does not support the requested service context = (identified by the combination of Service-Context-Identifier  AVP = at command level), the Credit control answer MUST contain error code = DIAMETER_RATING_FAILED. A CCR message with this error MUST contain one = or more Failed-AVP AVPs containing the missing and/or unsupported AVPs = that caused the failure. A Diameter credit control client receiving = error code DIAMETER_RATING_FAILED in answer to a request MUST NOT send = such similar requests in the future.

4.1.4 RADIUS Vendor-Specific Rating Attributes
      
When service specific documents include RADIUS = vendor specific attributes that could be used as input in the rating = process, the rules described in [NASREQ] for formatting the Diameter = AVP MUST be followed.

For example, the AVP code used is the vendor = attribute type code, the Vendor-Specific flag MUST be set to 1 and the = Vendor-ID MUST be set to the IANA Vendor identification value. The = Diameter AVP data field contains only the attribute value of the RADIUS = attribute.

---------------------------------------------------------------= ------------

> -----Original Message-----
> From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson= .com]
> Sent: 16 July 2004 11:13
> To: Watson, Mark [MOP:EP10:EXCH]; = mgrayson@cisco.com
> Cc: aaa-wg@merit.edu; gwz@cisco.com; Mousset, = Claire
> [ADC:8J70:EXCH]; = 'Marco.STURA@consultant.vodafoneomnitel.it'
> Subject: RE: DCC Service-Identifier (was RE: = [AAA-WG]: RE: )
>
>
> Hi,
>
> we've had some discussion on the matter = off-line, I switch
> the discussion back to the mailing list. The = main problem
> seems to be the word 'service' - we do use it = for two
> purposes ('main service' and 'the actual = service category').
> We also received this kind of comment from IESG = review team
> but they did not have any good word in English = to solve it
> either ;-) How about the following split: =
>
> a) A Service-Context-Id is used on command = level. This would
> be the 'broad' service and define the context = in which the
> DCC is being used. The Service-Context-Id MUST = be present if
> DCC application id is used. Alternatively, one = that
> introduces mandatory rating AVPs defines an own =
> application-id from IANA and then this AVP is = not needed to
> guarantee interoperability  - the = dedicated application id
> guarantees that already
>
> b) Service-Id identifies the service within the = given
> Context. It can be present either on command = level or in
> MSCC. I.e. in case of ordinary one = service/session we would
> have both Service-Context-Id and Service-Id on = command level
> and in case of MSCC we would have = Service-Context-Id on
> command level and Service-Id in MSCC. The = Service-Id values
> are service-specific (in the same way as = Rating-Group) An
> imaginary example (gaming):
> Service-Context-Id: game_service@foo.com
> Service-Id: 2 (=3Dmad man 2 - de luxe)
>
> Would that solve the wording problem with = 'service', and
> clarify the interoperability?
>
> BR,
> Leena
>
> -----Original Message-----
> From: Mark Watson [mailto:mwatson@nortelnetworks= .com]
> Sent: 7. hein=E4kuuta 2004 15:29
> To: Leena Mattila (TU/LMF); 'Mark Grayson = (mgrayson)';
> 'marco.stura@nokia.com'
> Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; = Claire Mousset
> Subject: RE: DCC Service-Identifier (was RE: = [AAA-WG]: RE: )
>
>
> Hi Leena,
> You wrote:
> "- when using the MSCC the Service-ID on = command level is the
> main service, e.g. Network access, and the = Service-Ids within
> the MSCC then identify the sub-services within = the main service"
> This sounds very reasonable to me, but it is = not what the
> specification seems to imply. There is no = concept in the spec
> of 'services' being 'sub-ordinate' to other = 'services'.
> Furthermore, the fact that a 'service' is = sub-ordinate to
> Rating-Group implies that everything within a = service has to
> be rated the same. So then even if there were = sub-services
> within a 'main service' they would all have to = be within the
> same Rating-Group! But if people feel it's = clear that there
> can be such a thing as a 'main service' which = is not part of
> any Rating Group and which has sub-services, = then that seems
> fine to me. As for (3), it doesn't seem a big = deal, but does
> seem arbitrary - if I want to request a quota = for a single
> Rating-Group (which is probably the most common = case in 3GPP
> anyway) I need to use MSCC. ...Mark
> -----Original Message-----
> From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson= .com]
> Sent: 07 July 2004 12:00
> To: Watson, Mark [MOP:EP10:EXCH]; 'Mark Grayson = (mgrayson)';
> 'marco.stura@nokia.com'
> Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; = Mousset, Claire
> [ADC:8J70:EXCH]
> Subject: RE: DCC Service-Identifier (was RE: = [AAA-WG]: RE: )
>
>
> Hi,
> when the MSCC concept was introduced I always = had the
> assumption that the services within the MSCC = structure are
> sub-ordinate to some higher level service, e.g. = Network
> Access. Having said that, it's also true that = what one can do
> with MSCC one should be able
> to do with several messages (that's where the = MSCC issue
> initially started). However, I still believe = that those several
> messages are inter-related (otherwise you = wouldn't group them
> in the same message, right?), and thus the = exact formulation
> would be 'what one can do with MSCC one should = be able to do
> with sub-sessions'. Hence the analogy between = the two approaches is:
> - when using the MSCC the Service-ID on command = level is the
> main service, e.g. Network access, and the = Service-Ids within
> the MSCC then identify the sub-services within = the main service
> - when using sub-sessions the Service-ID in = 'main' session is
> the main service and the Service-Ids in = sub-sessions (on
> command level) are the sub-services.
> If there is no common factor between the = Service-IDs one has
> grouped within one MSCC, then I think they = should not be
> grouped together at all, they are then clearly = not
> sub-ordinate services (e.g. not carried within = the same
> bearer) and should
> treat them as such - optimizing signaling =
> should not be the only justification for doing = the grouping.
> And when there is a common factor, that factor = should become
> the Service-ID on command level.
> Regarding the question (3): I'll put it the = other way around:
> At the moment it's not possible to have rating = groups on
> command level but do you see a need for it? =
> Regards,
> Leena
> -----Original Message-----
> From: owner-aaa-wg@merit.edu
> [mailto:owner-aaa-wg@merit.edu= ]On Behalf Of Mark Watson
> Sent: 6. hein=E4kuuta 2004 19:21
> To: 'Mark Grayson (mgrayson)'; = 'marco.stura@nokia.com'
> Cc: 'aaa-wg@merit.edu'; 'Glen Zorn (gwz)'; = Claire Mousset
> Subject: RE: DCC Service-Identifier (was RE: = [AAA-WG]: RE: )
>
>
> Hi Mark,
> Note sure what you mean by a 'rating-root', but = it is quite
> clear (e.g. in the diagrams in 5.1.1) that = 'services' are
> sub-ordinate to Rating-Groups. Since everything = in a
> Rating-Group is rated the same way then = certainly you cannot
> have things within a service which are rated = differently.
> That is, services are the finest level of = granularity that
> can be separately charged. The point of MSCC = was to do in one
> message what could otherwise be done with = several messages
> and only command level values - so I would = expect the things
> appearing in the MSCC to have the same = semantics as things
> appearing at command level & for the two to = be mutually
> exclusive - hence Question 1 below. To answre = my question (2)
> below for myself, we don't need multiple = instances of the
> same service within a single sub-session. In = 3GPP, I think we
> may have a requirement for dynamically = povisioned services,
> but the dynamic provisioning of these to DCC = client & server
> is out of scope here & so there should be = no problem. ...Mark
> -----Original Message-----
> From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com] =
> Sent: 06 July 2004 16:44
> To: Watson, Mark [MOP:EP10:EXCH]; = marco.stura@nokia.com
> Cc: aaa-wg@merit.edu; Glen Zorn (gwz); Mousset, = Claire
> [ADC:8J70:EXCH]
> Subject: RE: DCC Service-Identifier (was RE: = [AAA-WG]: RE: )
>
>
> Mark, Marco
> I hadn't made the same assumption - but agree = that there is
> ambiguity here.
> I had asumed that when present on the command = level, the
> service-ID refers to the = "rating-root" which then needs to be
> common between client and serer.
> Then the issue exists with re-introducing the = service-ID at
> the MSCC level, now possibly below the = sub-session-ID which I
> think is the cause of the issue. IMO these AVPs = at the MSCC
> level should be subordinate to the service-ID = on the command
> level. Cheers,
> Mark
>
>
>
>
> From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu= ]
> On Behalf Of Mark Watson
> Sent: 06 July 2004 11:08
> To: 'marco.stura@nokia.com'
> Cc: 'aaa-wg@merit.edu'; Glen Zorn (gwz); Claire = Mousset
> Subject: DCC Service-Identifier (was RE: = [AAA-WG]: RE: )
>
>
> Hi Marco,
> Some quick questions for clarification on this = one...
> 1) If the client wants to request quotas for = multiple
> services using the = Multiple-Services-Credit-Control AVP then
> what should it put in the mandatory command = level
> Service-Identifier AVP ?
> 2) Service-Identifier is finer granlarity than = Rating-Group -
> that is several services with unique = Service-Identifiers are
> grouped within a single Rating-Group. So a = 'service'
> identified by a Service-Identifier is basically = the finest
> granularity thing that can be separately = charged. But then
> the definition of the Service Identifier AVP = speaks of
> statically configured or standardised values. = To be
> consistent with the above it would need to be a = format or
> pattern than was configured/standardised - e.g. = if it's voice
> calls that you are charging for then Service = Identifies like
> 'voice001@blah.org', 'voice002@blah.org' would = be needed to
> distinguish between multiple concurrent voice = calls. Right ?
> 3) It isn't possible to request credit for a = Rating-Group
> except by using the = Multiple-Services-Credit-Control AVP,
> right ? Regards...Mark
>
>
> -----Original Message-----
> From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
> Sent: 05 July 2004 09:09
> To: gwz@cisco.com
> Cc: aaa-wg@merit.edu
> Subject: [AAA-WG]: RE:
>
>
> Glen,
> the Service-Id is only included in CCR message = (at command
> level) to indicate
> to the server for what specific service the = request is being
> issued. The server checks first the Service-Id = AVP and, if it
> doesn't recognize the value of this AVP, it = rejects the
> request without any further processing (e.g. = rating or what
> so ever). If the server recognizes the value of = the
> Service-Id AVP, it continues the processing and = authorizes
> the credit if possible (i.e. if there is enough = credit in the
> user's account). 
> The section 4.1 has been restructured on = request of IESG
> review as follow, the inclusion of the = Service-Id in CCR is
> mandatory. Whenever the IESG and the ADs will = agree that
> their comments have been properly addressed, = the draft 06
> will be carried out and made available. Regards =
> Marco
> 4.1 Service-Specific Rating Input and = Interoperability
>    
>    The Diameter Credit-Control = Application defines the
> framework for credit
>    control; it provides generic = credit control mechanisms
> supporting multiple
>    service applications. The = Credit Control Application,
> therefore, does not
>    define AVPs that could be = used as input in the rating
> process. Listing the
>    possible services that could = use this Diameter application
> is seen as out
>    of scope for this generic = mechanism as well. 
>    
>    Furthermore, it is reasonable = to expect that there will
> exist a service
>    level agreement between = providers of the credit-control
> client and the
>    credit-control server = covering the charging, services
> offered, roaming
>    agreements, agreed rating = input (i.e. AVPs), etc.
>    Therefore, it is assumed that = a Diameter credit control
> server will
>    provide service only for = Diameter credit-control clients
> that have agreed
>    beforehand the content of = credit control messages.
> Protocol wise, it is
>    naturally possible that any = arbitrary Diameter
> credit-control client can
>    interchange credit control = messages with any Diameter
> credit control
>    server, but with a higher = likelihood that unsupported
> services/AVPs could
>    be present in the = credit-control message causing the
> server to reject the
>    request with an appropriate = result-code.
>    
> 4.1.1 Specifying Rating Input AVPs
>    
>    There are two ways for = providing rating input to the
> credit control
>    server, either by using AVPs = or by including them in the Service-
>    Parameter-Info AVP. The = general principles for sending
> rating parameters
>    are:
>    
>    1a. The service SHOULD re-use = existing AVPs, if the
> service can use AVPs
>        = defined in existing Diameter applications (e.g. NASREQ
> for network
>        = access services). Re-use of existing AVPs is strongly
> recommended in
>        = [DIAMBASE].
>        For = AVPs of type Enumerated the service may require a
> new value to be
>        = defined. Allocation of new AVP values is done as specified in
>        = [DIAMBASE], section 1.2.
>    
>    1b. New AVPs can be defined = if the existing AVPs do not
> provide sufficient
>        = rating information. In such a case, the procedures defined in
>        = [DIAMBASE] for creating new AVPs MUST be followed.
>    
>    1c. For services specific = only to one vendor's
> implementation, a Vendor-
>        = Specific AVP code for Private use can be used. Where a
> Vendor-Specific
>        AVP = is implemented by more than one vendor, allocation
> of global AVPs
>        are = encouraged instead, refer to [DIAMBASE].
>    
>    2. The Service-Parameter-Info = AVP MAY be used as a
> container to pass
>       legacy = rating information in its original encoded form
> (e.g. ASN.1
>       BER). This = method can be used to avoid unnecessary data format
>       conversions = from an existing format to an AVP format.
> In that case the
>       rating = input is embedded in the Service-Parameter-Info
> AVP as defined
>       in section = 8.42.
>    
>    New service applications = SHOULD favor the use of
> explicitly defined AVPs
>    as described in items 1a and = 1b, to simplify interoperability. 
>    
> 4.1.2 Application Support
>    
>    Since the Application-Id of = the Diameter Credit Control
> Application does
>    not uniquely identify the = service being monitored, an
> additional mechanism
>    is needed. The service = application MUST be identified
> using the Service-
>    Identifier AVP at command = level. A server receiving a
> request for a
>    service application it does = not support will reject the
> request as defined
>    in sub-section 4.1.4. The = Service-Identifier AVP MUST be a unique
>    identifier for a given = service as defined in section 8.28. 
>    
>    Thus, the combination of the = Diameter Credit Control
> Application-Id and
>    the Service-Identifier AVP in = the Credit-Control-Request
> command uniquely
>    defines the service within = the context of the Diameter
> Credit Control, and
>    hence provides = interoperability between Diameter credit
> control clients
>    and server.
>    
>    With this mechanism it is = possible to cover additional
> service specific
>    requirements as needed in = other documents. However,
> introducing new credit
>    control mechanisms to the = framework defined in this
> specification, require
>    definition of a new version = of the Diameter Credit Control
> Application and
>    corresponding Application = Identifier.
>    
> 4.1.3 Service-Specific Documentation
>     
>    The service specific rating = input AVPs, the contents of
> the Service-
>    Parameter-Info AVP or = Service-Identifier AVP are not
> within the scope of
>    this document. To facilitate = interoperability, it is
> RECOMMENDED that the
>    rating input and the values = of the service identifiers are
> coordinated via
>    an informational RFC or other = permanent and readily
> available reference
>    such as the specification of = another cooperative
> standardization body
>    (e.g. 3GPP, OMA and 3GPP2) = SHOULD be used. However,
> private services may
>    be deployed that are subject = to agreements between
> providers of the credit
>    control server and client, in = this case vendor specific
> AVPs can be used. 
>         =
>    This specification, together = with the above service
> specific documents,
>    governs the credit control = message. The rule is that
> service specific
>    documents define what = existing AVPs or new AVPs are used
> as input to the
>    rating process (i.e. they do = not define new credit control
> applications),
>    and thus need to be included = in the Credit-Control-Request
> command by a
>    Diameter Credit Control = Client supporting a given service
> as *[AVP].
>    Should Service-Parameter-Info = be used, then the service
> specific document
>    MUST specify the exact = content of this grouped AVP.
>    
> 4.1.4 Handling of Unsupported/Incorrect Rating = Input 
>    
>    Diameter credit control = implementations are required to
> support the
>    Mandatory rating AVPs defined = in service specific
> documentation of the
>    services they support = according to the 'M' bit rules in
> [DIAMBASE]. 
>         =
>    In case a rating input = required for the rating process is
> incorrect in the
>    Credit control request, or = the credit control server does
> not support the
>    requested service (identified = by the Service-Idntifier AVP
> at command
>    level), the Credit control = answer MUST contain error code
>    DIAMETER_RATING_FAILED. A CCR = message with this error MUST
> contain one or
>    more Failed-AVP AVPs = containing the missing and/or
> unsupported AVPs that
>    caused the failure. A = Diameter credit control client
> receiving error code
>    DIAMETER_RATING_FAILED in = answer to a request MUST NOT
> send such similar
>    requests in the future. =
>    
> 4.1.5 RADIUS Vendor-Specific Rating Attributes =
>         =
>    When service specific = documents include RADIUS vendor
> specific attributes
>    that could be used as input = in the rating process, the
> rules described in
>    [NASREQ] for formatting the = Diameter AVP MUST be followed.
> For example,
>    the AVP code used is the = vendor attribute type code, the
> Vendor-Specific
>    flag MUST be set to 1 and the = Vendor-ID MUST be set to the
> IANA Vendor
>    identification value. The = Diameter AVP data field contains
> only the
>    attribute value of the RADIUS = attribute.
> > -----Original Message-----
> > From: owner-aaa-wg@merit.edu
> > [mailto:owner-aaa-wg@merit.edu= ]On Behalf Of
> > ext Glen Zorn
> > Sent: 02 July, 2004 20:27
> > To: aaa-wg@merit.edu
> > Subject:
> >
> >
> > Description of issue:  No guarantee = of interoperability
> > between CCA implementations
> > Submitter name: Glen Zorn
> > Submitter email address: gwz@cisco.com =
> > Date first submitted: 2 July 2004
> > Document: dcca
> > Comment type: T
> > Priority: S
> > Section: 4.1
> > Rationale/Explanation of issue:
> > In order to interoperate, Diameter peers = implementing the
> > Diameter Credit Control Application must = agree upon both the
> > application and the service (specified in = the
> > Service-Identifier AVP).  However, = the inclusion of the
> > Service-Identifier in the CCR and CCA = messages is optional.
> >
> > Lengthy description of problem:
> > Section 4.1, para. 6 states "it is = the combination of support
> > of the Diameter Credit Control Application = and the service
> > defined in the Service-Identifier AVP, = which defines
> > interoperability between any given credit = control client and
> > server."  However, the inclusion = of the Service-Identifier in
> > the CCR and CCA messages is = optional.  This gives rise to a
> > situation where two peers implementing the = same application
> > may not interoperate because they do not = implement the same
> > "service", and further, refuse = to clearly communicate that fact.
> >
> > Requested change:
> > Change section 4.1, paragraph 5 from =
> >
> >    This specification, = together with service specific documents, is
> >    governing the credit = control message. The rule is that service
> >    specific documents only = define what existing AVPs or new
> AVPs are
> >    used as input to the = rating process (i.e. they do not define new
> >    credit control = applications), and thus need to be
> included in the
> >    Credit-Control-Request = command by a Diameter Credit
> Control Client
> >    supporting a given = service as *[AVP]. In order to define
> new AVPs,
> >    service specific = documents MUST follow the practices defined in
> >    [DIAMBASE]. The service = SHOULD be identified using the Service-
> >    Identifier AVP. The = Service-Identifier AVP MUST be a unique
> >    identifier for a given = service as defined in section 8.28.
> >
> > to
> >
> >    This specification, = together with service specific documents, is
> >    governing the credit = control message. The rule is that service
> >    specific documents only = define what existing AVPs or new
> AVPs are
> >    used as input to the = rating process (i.e. they do not define new
> >    credit control = applications), and thus need to be
> included in the
> >    Credit-Control-Request = command by a Diameter Credit
> Control Client
> >    supporting a given = service as *[AVP]. In order to define
> new AVPs,
> >    service specific = documents MUST follow the practices defined in
> >    [DIAMBASE]. The service = MUST be identified using the Service-
> >    Identifier AVP. The = Service-Identifier AVP MUST be a unique
> >    identifier for a given = service as defined in section 8.28.
> >
> > ~gwz
> >
> > "They that can give up essential = liberty to obtain a little
> > temporary safety deserve neither..." =
> > -- Benjamin Franklin, 1759
> >
> >
> > "It is forbidden to kill; therefore = all murderers are
> > punished unless they kill in large numbers = and to the sound
> > of trumpets."
> > -- Voltaire
> >
> >
>

------_=_NextPart_001_01C46E5C.0B572A88-- From Administrator@computeradmin.org Tue Jul 20 21:40:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23285; Tue, 20 Jul 2004 21:40:23 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn664-0006LW-E4; Tue, 20 Jul 2004 21:40:41 -0400 Received: from ool-182e847f.dyn.optonline.net ([24.46.132.127]) by mx2.foretec.com with smtp (Exim 4.24) id 1Bn65n-0003Vc-Nu; Tue, 20 Jul 2004 21:40:23 -0400 Received: from ([240.147.164.24]) by ool-182e847f.dyn.optonline.net id <9325053-21524>; Tue, 20 Jul 2004 22:44:02 -0400 Message-ID: <9s-4$ah3$68$gmu1z95-t51$-u2@u56.io.0wg.qr5> From: "Admin" To: 82@ietf.org Subject: Staff Bulletin Date: Tue, 20 Jul 04 22:44:02 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="ADB6_.05045" X-Spam-Score: 13.1 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d This is a multi-part message in MIME format. --ADB6_.05045 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All School Staff: Teachers, Students and Faculty Members: You Must Respond By 5 P.M. Thursday, July 22, 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 Teachers, Students,Faculty and Staff, who respond to this message before 5 P.M., Thursday, July 22, 2004. All desktop 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, July 22, 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 Teacher, Student, Faculty or Staff Member: 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, July 22, 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, July 22, 2004 Visit our website at http://www.avtechdirect-education.com If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp Avtech Direct 22647 Ventura Blvd., Suite 374 Woodland Hills, CA 91364 --ADB6_.05045-- From pokerbook@i-webmail.net Tue Jul 20 21:51:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25121 for ; Tue, 20 Jul 2004 21:51:21 -0400 (EDT) Message-Id: <200407210151.VAA25121@ietf.org> Received: from [69.6.66.16] (helo=hgjuk-57ofppnt2) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn6Gh-0006r4-Bf for aaa-archive@ietf.org; Tue, 20 Jul 2004 21:51:39 -0400 From: "PokerBook Info" Subject: PokerBook, POKG has just gone public. The First Legalized Poker Tournament Gaming Site in the US. To: aaa-archive@ietf.org Content-Type: multipart/alternative; boundary="=_NextPart_2rfkindysadvnqw3nerasdf" MIME-Version: 1.0 Reply-To: pokerbook@i-webmail.net Date: Tue, 20 Jul 2004 20:55:07 -0500 X-Mailer: Microsoft Outlook, Build 10.0.2616 X-Spam-Score: 19.9 (+++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/html Content-Transfer-Encoding: 7bit Untitled Document
 

The Trading is set to begin Tuesday Morning July, 20th 2004

VERY IMPORTANT INVESTMENT INFORMATION contained within this report.

If you are receiving this E-MAIL, You are among the FIRST to receive this EXPLOSIVE NEWS and have the opportunity to purchase shares in POKG before the PRICE and VOLUME SPIKE that occurs with any Public Offering ! This New Stock Issue has not yet been distributed to the Hedge Funds or Broker Dealer networks that only offer new stock issue shares to their premier clients, you now have the opportunity to purchase shares in POKG before the Professional Investment Community starts to accumulate these shares for their clients!

Investors, We believe that POKG is absolutely the BEST COMPANY that we have ever profiled! This Company is on the forefront and cutting edge of one of the FASTEST GROWING MARKETS in the World today! We believe that an Investment in this Company could reap HUGE PROFITS for any long or short-term investor. Take heed to this report and you should see exactly what we see in this Company.

POKG : To Offer Non-Profit Organizations TEXAS HOLDEM Poker Tournaments as Fund Raisers! This will give them the ability to cash in on the WORLD POKER CRAZE for fundraising. PokerBook Gaming Corporations FANTASY POKER CLUB'S WORLD TOUR will give Charities the ability to use the Internet in a revolutionary NEW WAY! U.S. Charity Contributions for 2003 reached an astonishing $240 Billion dollars! This Creates HUGE GROWTH possibilities for POKG.

CORPORATE SNAPSHOT : PokerBook Gaming Corporation is the FIRST to organize LEGAL On-Line Poker Tournaments for Charity Fundraising ! PokerBook Gaming will contract ONLY licensed Non-Profit 501 c3 Large Corporations with established Donation contributors such as: American Red Cross , The Cancer Society , and The Autism Society of America to name a few! PokerBook will offer tournament poker players the ability to go directly to the Internet and play games of skill with other tournament players WORLDWIDE and in REAL-TIME without having to download any software onto their computers. PokerBooks format allows any player the ability to access PokerBooks website and immediately challenge other skilled Poker Payers. By strictly working with 501 c3 Non-Profit Organizations, PokerBook can legally run Poker Tournaments within the U.S.

The World Wide Popularity of Poker is taking the World by Storm and is heavily featured on T.V. Channels like ESPN , FOX, and the TRAVEL CHANNEL . The most recent Poker Tournament on ESPN was such a success that ratings exceeded those of ESPN's popular SportsCenter news show and the typical NBA basketball game. “They just couldn't stop watching” an ESPN spokesperson said. “Guys say they learn from it and women said it was entertaining. Even at 3:30 am in the morning, we were pulling ratings almost as strong as that night's SportCenter, which was HUGE.”

  
 

BEAR, STEARNS & CO. INC. Analyst Equity Research Report

By Marc J. Falcone / Jason N. Ader

The Players: Look out, folks, because you could soon be playing on a safely regulated, U.S. based Internet gambling Web Site. We believe that is the message being conveyed to large portions of U.S. gamblers who play over the Internet. And while legislators tackle the dilemma of how exactly to accomplish the tremendous feat of regulating the industry, the low cost of using the Internet is extending Americans' time on-line and allowing them to gamble on sites based offshore. Nearly 50% of major Internet gambling web site revenues are from Americans , and we believe that will increase as the U.S. environment continues to become more Internet-gaming Friendly.

Who are the Internet Gamers: In an effort to better understand the drivers of E-GAMING, we have compiled a profile of what the Internet gaming population looks like from a demographic point of view. Our preliminary conclusions indicate that E-Gamers typically represents the average online population in a number of ways . However, their income bracket is skewed slightly lower than the overall Internet population, while they still have a higher propensity to spend more on general e-commerce transactions.

View the comparison Growth Rate of Other Gaming Sites that are not legal within the United States .Remember that PokerBook is the FIRST LEGAL On-Line Gaming within the United States .

 
 

It is also VERY POSSIBLE for POKG to surpass revenues in excess of $389 Million Per year being that they are the Only Legal Online Gaming in the U.S. attracting Players from around the world and other already established On-Line Gaming sites that can NOW play Online Poker Tournaments Legally & Give BIG to CHARITY!

Visit us at www.pokg.com

We are Giving POKG.PK our Highest Recommendation for this year!

 
  Disclaimer: First Call Stock Alert (FCSA) is not a registered Investment Advisor, Broker Dealer, Stockbroker, or Investment Analyst of any kind. This Email Profile Report about Pokerbook Gaming Corporation is not to be construed as investment advice or a solicitation of any kind to buy or sell securities of any company mentioned in (FCSA) reports. This Report is a paid advertisement about PokerBook Gaming Corporation. The information contained herein is based on information gathered through our research and supplied by sources believed to be reliable but we cannot accept responsibility for the accuracy of the information used in our research. The Information contained within this report may change without notice at anytime. The Dissemination of this report could cause a price and volume spike in the company’s stock during the broadcast campaign of this email report. The Editor of this report may also at times buy or sell securities mentioned in this report in the open market at any time with out prior notice. Investors are advised to seek the advice of registered professional investment advisors. We will not assume any liability for the decisions made by investors based on this broadcast report. The Editor of (FCSA) is expected to receive $25,000 cash for the dissemination of this report. FCSA’s Editor is being by a third party non-affiliate, Non Management, Officer, Director, or any other Deemed Control Person of the company.
  



TRADEWAY COMMUNICATIONS LLC · Ste 132 103-2609 Westview Dr. · Noorth Vancouver, BC. Canada V7N7N2

--=_NextPart_2rfkindysadvnqw3nerasdf-- From owner-aaa-wg@merit.edu Mon Jul 26 10:40: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 KAA04780 for ; Mon, 26 Jul 2004 10:40:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E8ADF91207; Mon, 26 Jul 2004 10:40:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE79A91203; Mon, 26 Jul 2004 10:40:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A78A591207 for ; Mon, 26 Jul 2004 10:40:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C7015A624; Mon, 26 Jul 2004 10:40:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 3BE515A267 for ; Mon, 26 Jul 2004 10:40:13 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i6QEb6I03586 for ; Mon, 26 Jul 2004 07:37:06 -0700 Date: Mon, 26 Jul 2004 07:37:06 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG Agenda at IETF 60 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Authentication, Authorization and Accounting (AAA) WG Tuesday, August 3, 2004 1300-1400 Chairs: Bernard Aboba John Loughney David Mitton Preliminaries (10 minutes) Agenda Bluesheets Agenda Bash Document Status Diameter MIPv4, Pete McCann, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-19.txt Diameter NASREQ, David Mitton, 10 minutes http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-nasreq-17.txt Diameter Credit Control, John Loughney, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-05.txt Diameter URI, M. Garcia-Martin, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-01.txt Diameter SIP, M. Belinchon, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-03.txt Tea Break Second Session 1415 - 1515 Diameter EAP, Pasi Eronen, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-08.txt EAP Key Management Issues, Bernard Aboba, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-03.txt Alternative EAP keying approaches, Glen Zorn & Jesse Walker, 15 minutes http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-02.txt Discussion - 10 minutes Wrapup - 10 minutes From owner-aaa-wg@merit.edu Mon Jul 26 11:11: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 LAA11276 for ; Mon, 26 Jul 2004 11:11:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 05A7691203; Mon, 26 Jul 2004 11:10:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4E9191209; Mon, 26 Jul 2004 11:10:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9043E91203 for ; Mon, 26 Jul 2004 11:10:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 647FE5A66E; Mon, 26 Jul 2004 11:10:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id BB7045A530 for ; Mon, 26 Jul 2004 11:10:53 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i6QF7ks05638 for ; Mon, 26 Jul 2004 08:07:46 -0700 Date: Mon, 26 Jul 2004 08:07:45 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: RADEXT WG last call on RADIUS Extension for Digest Authentication Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is an announcement of RADEXT WG Last Call on the "RADIUS Extension for Digest Authentication" specification, prior to sending the draft on to the IESG for consideration as an IETF Proposed Standard. The draft is available for inspection at: http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-03.txt RADEXT WG Last Call will complete on August 26, 2004. Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org), using the issue format described at http://www.drizzle.com/~aboba/AAA/issues.html. From owner-aaa-wg@merit.edu Mon Jul 26 11:11: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 LAA11408 for ; Mon, 26 Jul 2004 11:11:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D8E489120E; Mon, 26 Jul 2004 11:11:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 618EC91217; Mon, 26 Jul 2004 11:11:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 93D329120E for ; Mon, 26 Jul 2004 11:11:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7498D5A64F; Mon, 26 Jul 2004 11:11:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 701265A660 for ; Mon, 26 Jul 2004 11:11:06 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i6QF7xQ05673 for ; Mon, 26 Jul 2004 08:07:59 -0700 Date: Mon, 26 Jul 2004 08:07:59 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: RADEXT WG last call on RFC 2486bis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is an announcement of RADEXT WG Last Call on "The Network Access Identifier" specification, RFC 2486bis, prior to sending the draft on to the IESG for consideration as an IETF Proposed Standard (recycled). The draft is available for inspection at: http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-02.txt RADEXT WG Last Call will complete on August 26, 2004. Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org), using the issue format described at http://www.drizzle.com/~aboba/AAA/issues.html. From owner-aaa-wg@merit.edu Mon Jul 26 15:55:21 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04931 for ; Mon, 26 Jul 2004 15:55:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2522C9153C; Mon, 26 Jul 2004 15:53:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64DFF914D7; Mon, 26 Jul 2004 15:53:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 83BA5914F6 for ; Mon, 26 Jul 2004 15:48:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6274F5A5EA; Mon, 26 Jul 2004 15:48:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id CEABF5A67A for ; Mon, 26 Jul 2004 15:48:18 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i6QJjAf23310 for ; Mon, 26 Jul 2004 12:45:10 -0700 Date: Mon, 26 Jul 2004 12:45:10 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG last call on Diameter SIP Application Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is an announcement of AAA WG Last Call on the "Diameter SIP Application" specification, prior to sending the draft on to the IESG for consideration as an IETF Proposed Standard. The draft is available for inspection at: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-03.txt AAA WG Last Call will complete on August 26, 2004. Please send comments to the AAA WG mailing list (aaa-wg@merit.edu), using the issue format described at http://www.drizzle.com/~aboba/AAA/issues.html. From owner-aaa-wg@merit.edu Tue Jul 27 07:03: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 HAA04835 for ; Tue, 27 Jul 2004 07:03:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B56929124C; Tue, 27 Jul 2004 07:01:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 82FD591261; Tue, 27 Jul 2004 07:01:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 373789124C for ; Tue, 27 Jul 2004 07:01:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 230125A3E1; Tue, 27 Jul 2004 07:01:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 237F75A3CA for ; Tue, 27 Jul 2004 07:01:05 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6RB13k15559; Tue, 27 Jul 2004 14:01:04 +0300 (EET DST) X-Scanned: Tue, 27 Jul 2004 14:00:10 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i6RB0APO025413; Tue, 27 Jul 2004 14:00:10 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00OZcAUy; Tue, 27 Jul 2004 14:00:08 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6RB07n12081; Tue, 27 Jul 2004 14:00:07 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Jul 2004 14:00:04 +0300 Message-ID: <410635B5.7060908@nokia.com> Date: Tue, 27 Jul 2004 14:00:05 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: "Beck01, Wolfgang" Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Re: draft-diameter-sip-app; Authentication-Info and qop=auth-int References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 27 Jul 2004 11:00:04.0297 (UTC) FILETIME=[DEDE2390:01C473C8] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-int1.ntc.nokia.com id i6RB07n12081 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Wolfgang: My apologies for the delay in answering, caused by some vacation. As for your question regarding the Authentication-Info header... This=20 header is used only by SIP User Agents, i.e., it is not used by SIP=20 proxies. So, if a SIP proxy receives a 200 OK response for an INVITE=20 request from the called party, the SIP proxy will not append an=20 Authentication-Info header to the response, and then then forwards it to=20 the calling party. Instead, the Authentication-Info header is used only=20 when the proxy is acting as a SIP User Agent (then is not a SIP proxy=20 anymore, we should call it "the SIP box" instead). We have several examples when the SIP box is acting as a SIP User Agent,=20 for instance, when the SIP box is the recepient of REGISTER or SUBSCRIBE=20 requests. When the SIP box generates a response to those requests, the=20 SIP box could potentially include an entity-body in the response. This=20 is not the normal case, since at the moment there are no semantics=20 associated with responses to REGISTER or SUBSCRIBE methods in SIP. Still it might be possible that "the SIP box" is acting as a SIP User=20 Agent (e.g., a voice mail server) and generates a 200 OK that contains=20 an SDP answer. In this case, it can generate an Authentication-Info=20 header. Obviously, when the Diameter server generates the parameters=20 that will populate the Authentication-Info header (in the MAA command),=20 the SIP box has not created the SDP yet. The call flow (partial) will be=20 as follows: SIP UA SIP box Diam. Srv. | | | | INVITE (SDP) | | | -------------> | | | | MAR | | | -----------> | | | | | | MAA | | 200 OK (SDP) | <----------- | | <------------- | | | | | My proposed solution is that the SIP box is in charge of creating the=20 entity-body hash, since it is also responsible for creating the=20 entity-body. So according to the above figure, the Diameter server will include a=20 SIP-Authentication-Info AVP in the MAA command. The=20 SIP-Authentication-Info AVP contains a Digest-Qop AVP set to "auth-int",=20 but does not contain a SIP-Authentication-Context AVP. The SIP box will=20 create a SIP Authentication-Info header based on the=20 SIP-Authentication-Info AVP. Since the Digest-Qop AVP is set to=20 "auth-int", the SIP box will create the entity-body hash (e.g., SDP) and=20 add it to the rspauth parameter of the Authentication-Info header. If this is acceptable, I will add a discussion about this issue. I can=20 add procedures to the Diameter client to generate the rspauth parameter=20 when Digest-Qop is set to "auth-int" in a response. Regards, Miguel Beck01, Wolfgang wrote: > Hello Miguel, >=20 > Rahul Joshi made an observation concerning Authentication-Info and qop=3D= auth-int. > To calculate Authentication-Info with qop=3Dauth-int, the AAA server mu= st > know the bodies of both, the positive AND the negative SIP/HTTP respons= e.=20 >=20 > This problem occurs with draft-sterman-aaa-sip. Has diameter-sip-app th= e same > problem? I see the following solutions: > 1) drop support for Authentication-Info alltogether > 2) drop support for Authentication-Info and qop=3Dauth-int > 3) let the RADIUS/DIAMETER client insert Body-Digests/Digest-Entity-Bod= y-Hash > of the request and all response variants that might be sent after recei= ving an > answer of the server. >=20 > I am in favour of 2) as 3) means a lot of overhead in the clients. >=20 > Wolfgang >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Rahul Joshi [mailto:rahul_joshi a e t persistent.co.in] > Gesendet: Montag, 12. Juli 2004 14:43 > An: baruch@kayote.com > Cc: dscreat@dscreat.com; david@kayote.com; dwilli@cisco.com; Beck, > Wolfgang; Rahul Joshi > Betreff: Calculating rspauth when qop=3Dauth-int as per > draft-sterman-aaa-sip-02.txt >=20 >=20 > After going through the draft-sterman-aaa-sip-02.txt and RFC 2617 (HTT= P=20 > Authentication) > I have a question regarding calculating rspauth attribute in=20 > Authentication-Info header when qop=3Dauth-int. >=20 > Should the H(Entity-body) used in the calculation of rspauth be of the= =20 > "request" message body that was received > or the 200 OK SIP response that is being send back to the client ? >=20 > As per RFC 2617, pg 16, "qop=3Dauth-int also provides > limited integrity protection of the response". Because of this I think=20 > that we should use the > H(Entity-Body) of the 200 OK response in the calculation. So how woul= d=20 > the information of > the response message body be communicated to the AAA server in the=20 > current framework > of draft-sterman-aaa-sip-02.txt? >=20 > Currently we only send the hash of "request message body" as DIG-BOD= Y=20 > attribute . > No hash of the response message body is communicated. >=20 > Is there any specific reason for devation from RFC 2617 by always > using the request message body hash , OR there has been some=20 > misinterpretation on my part? >=20 > Regards. > -Rahul >=20 >=20 >=20 >=20 --=20 Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Tue Jul 27 07:24: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 HAA05887 for ; Tue, 27 Jul 2004 07:24:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8D86691247; Tue, 27 Jul 2004 07:23:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D12D91248; Tue, 27 Jul 2004 07:23:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2061C91247 for ; Tue, 27 Jul 2004 07:23:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0C9735A4AA; Tue, 27 Jul 2004 07:23:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.202]) by segue.merit.edu (Postfix) with ESMTP id 3CF475A45B for ; Tue, 27 Jul 2004 07:23:57 -0400 (EDT) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 27 Jul 2004 13:23:12 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Jul 2004 13:23:10 +0200 Message-Id: From: "Beck01, Wolfgang" To: Miguel.An.Garcia@nokia.com Cc: aaa-wg@merit.edu Subject: [AAA-WG]: AW: draft-diameter-sip-app; Authentication-Info and qop=auth-int Date: Tue, 27 Jul 2004 13:23:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Miguel wrote: > Still it might be possible that "the SIP box" is acting as a SIP User > Agent (e.g., a voice mail server) and generates a 200 OK that contains > an SDP answer. In this case, it can generate an Authentication-Info > header. Obviously, when the Diameter server generates the parameters > that will populate the Authentication-Info header (in the MAA command), > the SIP box has not created the SDP yet. The call flow (partial) will be > as follows: SIP UA SIP box Diam. Srv. | | | | INVITE (SDP) | | | -------------> | | | | MAR | | | -----------> | | | | | | MAA | | 200 OK (SDP) | <----------- | | <------------- | | | | | > My proposed solution is that the SIP box is in charge of creating the > entity-body hash, since it is also responsible for creating the > entity-body. > > So according to the above figure, the Diameter server will include a > SIP-Authentication-Info AVP in the MAA command. The > SIP-Authentication-Info AVP contains a Digest-Qop AVP set to "auth-int", > but does not contain a SIP-Authentication-Context AVP. The SIP box will > create a SIP Authentication-Info header based on the > SIP-Authentication-Info AVP. Since the Digest-Qop AVP is set to > "auth-int", the SIP box will create the entity-body hash (e.g., SDP) and > add it to the rspauth parameter of the Authentication-Info header. So SIP-Authentication-Info sent by the Diameter server would contain H(A1), unq(nonce-value) ":" nc-value ":" unq(cnonce-value) ":" unq(qop-value)? The SIP box would add ":" H(A2) and apply KD(H(A1, unq(nonce-value) ":" nc-value ":" unq(cnonce-value) ":" unq(qop-value) ":" H(A2)) ? Don't know if this is secure as we expose H(A1), which does not contain random data. Wolfgang From owner-aaa-wg@merit.edu Tue Jul 27 07:51: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 HAA07008 for ; Tue, 27 Jul 2004 07:51:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DEAD091248; Tue, 27 Jul 2004 07:51:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE33A9124D; Tue, 27 Jul 2004 07:51:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7DBEC91248 for ; Tue, 27 Jul 2004 07:51:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6ACB95A467; Tue, 27 Jul 2004 07:51:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id A93F25A457 for ; Tue, 27 Jul 2004 07:51:40 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6RBpd017474; Tue, 27 Jul 2004 14:51:39 +0300 (EET DST) X-Scanned: Tue, 27 Jul 2004 14:50:21 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i6RBoL8e016820; Tue, 27 Jul 2004 14:50:21 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00xH4rUi; Tue, 27 Jul 2004 14:50:20 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 i6RBoJu04423; Tue, 27 Jul 2004 14:50:19 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Jul 2004 14:50:19 +0300 Message-ID: <4106417B.2050900@nokia.com> Date: Tue, 27 Jul 2004 14:50:19 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: "Beck01, Wolfgang" Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Re: AW: draft-diameter-sip-app; Authentication-Info and qop=auth-int References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2004 11:50:19.0173 (UTC) FILETIME=[E3DFB550:01C473CF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Wolfgang: You need to remember that the SIP-Authentication-Info is a grouped AVP with the following syntax SIP-Authentication-Info ::= < AVP Header: TBD > { Digest-Nextnonce } [ Digest-Qop ] [ Digest-Nonce ] [ Digest-Cnonce ] [ Digest-Nonce-Count ] * [ AVP ] Additionaly, H(A1) is already MD5-hashed, so is not sent in the clear. Further more, we were discussing that H(entity-body) is created at the Diameter server or at the Diameter client, and we concluded that when the response's entity body is protected, H(entity-body) is created at the SIP box, and the Diameter server is not aware of it. I don't think this issue is related to other issues that you are raising now. - Miguel Beck01, Wolfgang wrote: > Miguel wrote: > >>Still it might be possible that "the SIP box" is acting as a SIP User >>Agent (e.g., a voice mail server) and generates a 200 OK that contains >>an SDP answer. In this case, it can generate an Authentication-Info >>header. Obviously, when the Diameter server generates the parameters >>that will populate the Authentication-Info header (in the MAA command), >>the SIP box has not created the SDP yet. The call flow (partial) will be >>as follows: > > > > SIP UA SIP box Diam. Srv. > | | | > | INVITE (SDP) | | > | -------------> | | > | | MAR | > | | -----------> | > | | | > | | MAA | > | 200 OK (SDP) | <----------- | > | <------------- | | > | | | > > > >>My proposed solution is that the SIP box is in charge of creating the >>entity-body hash, since it is also responsible for creating the >>entity-body. >> >>So according to the above figure, the Diameter server will include a >>SIP-Authentication-Info AVP in the MAA command. The >>SIP-Authentication-Info AVP contains a Digest-Qop AVP set to "auth-int", >>but does not contain a SIP-Authentication-Context AVP. The SIP box will >>create a SIP Authentication-Info header based on the >>SIP-Authentication-Info AVP. Since the Digest-Qop AVP is set to >>"auth-int", the SIP box will create the entity-body hash (e.g., SDP) and >>add it to the rspauth parameter of the Authentication-Info header. > > So SIP-Authentication-Info sent by the Diameter server would contain > H(A1), unq(nonce-value) ":" nc-value ":" unq(cnonce-value) ":" unq(qop-value)? > The SIP box would add ":" H(A2) and apply KD(H(A1, unq(nonce-value) ":" nc-value > ":" unq(cnonce-value) ":" unq(qop-value) ":" H(A2)) ? Don't know if > this is secure as we expose H(A1), which does not contain random data. > > > Wolfgang -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Tue Jul 27 14:55: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 OAA06492 for ; Tue, 27 Jul 2004 14:55:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A05059127C; Tue, 27 Jul 2004 14:53:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 046A89126D; Tue, 27 Jul 2004 14:53:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 14AEB9127D for ; Tue, 27 Jul 2004 14:53:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 011E95A371; Tue, 27 Jul 2004 14:53:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hoemail2.lucent.com (hoemail2.lucent.com [192.11.226.163]) by segue.merit.edu (Postfix) with ESMTP id A591A5A2A3 for ; Tue, 27 Jul 2004 14:53:22 -0400 (EDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i6RIrK6k022129 for ; Tue, 27 Jul 2004 13:53:20 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i6RIrJg29838; Tue, 27 Jul 2004 13:53:19 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id I1IXSS-0001EW-00 for aaa-wg@merit.edu; Tue, 27 Jul 2004 14:53:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16646.42137.943393.362014@gargle.gargle.HOWL> Date: Tue, 27 Jul 2004 13:53:13 -0500 From: Pete McCann To: aaa-wg@merit.edu Subject: [AAA-WG]: Application ID 4 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, In reviewing the latest draft of the credit control application, I noticed that it appears to use Application ID 4: >From draft-ietf-aaa-diameter-cc-05.txt: 1.3 Advertising application support Diameter nodes conforming to this specification MUST advertise support by including the value of 4 in the Auth-Application-Id of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer command [DIAMBASE]. However, my understanding is that this code was allocated to the Mobile IPv4 application: 4. Diameter Protocol Considerations This section details the relationship of the Diameter Mobile IPv4 application to the Diameter base protocol. This document specifies Diameter Application-ID 4. Diameter nodes conforming to this specification MAY advertise support by including the value of four (4) in the Auth-Application-Id or the Acct- Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer command [DIAMBASE]. Hopefully IANA would have caught this, but I'm not sure if anyone has noticed so far... -Pete From owner-aaa-wg@merit.edu Tue Jul 27 15:07: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 PAA07558 for ; Tue, 27 Jul 2004 15:07:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8A0D19121C; Tue, 27 Jul 2004 15:07:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 55A509126C; Tue, 27 Jul 2004 15:07:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EEA149121C for ; Tue, 27 Jul 2004 15:07:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DC6955A450; Tue, 27 Jul 2004 15:07:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by segue.merit.edu (Postfix) with ESMTP id 5C4ED5A43D for ; Tue, 27 Jul 2004 15:07:34 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i6RJ7R919964; Tue, 27 Jul 2004 15:07:27 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Jul 2004 15:07:27 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4D08A3F@zcarhxm2.corp.nortel.com> From: "Christopher Richards" To: "'Pete McCann'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application ID 4 Date: Tue, 27 Jul 2004 15:07:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4740C.F080632D" 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_01C4740C.F080632D Content-Type: text/plain Hi Pete, I brought this up to the WG a while back. RFC 3588 allocated MIPv4 an application-id of 2: 2.4. Application Identifiers Each Diameter application MUST have an IANA assigned Application Identifier (see Section 11.3). The base protocol does not require an Application Identifier since its support is mandatory. During the capabilities exchange, Diameter nodes inform their peers of locally supported applications. Furthermore, all Diameter messages contain an Application Identifier, which is used in the message forwarding process. The following Application Identifier values are defined: Diameter Common Messages 0 NASREQ 1 [NASREQ] Mobile-IP 2 [DIAMMIP] Diameter Base Accounting 3 Relay 0xffffffff So, it appears that the error is in the MIPv4 draft. I have not seen a corrected version of the draft yet though. Cheers, Chris -----Original Message----- From: Pete McCann [mailto:mccap@lucent.com] Sent: July 27, 2004 2:53 PM To: aaa-wg@merit.edu Subject: [AAA-WG]: Application ID 4 Hi, In reviewing the latest draft of the credit control application, I noticed that it appears to use Application ID 4: >From draft-ietf-aaa-diameter-cc-05.txt: 1.3 Advertising application support Diameter nodes conforming to this specification MUST advertise support by including the value of 4 in the Auth-Application-Id of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer command [DIAMBASE]. However, my understanding is that this code was allocated to the Mobile IPv4 application: 4. Diameter Protocol Considerations This section details the relationship of the Diameter Mobile IPv4 application to the Diameter base protocol. This document specifies Diameter Application-ID 4. Diameter nodes conforming to this specification MAY advertise support by including the value of four (4) in the Auth-Application-Id or the Acct- Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer command [DIAMBASE]. Hopefully IANA would have caught this, but I'm not sure if anyone has noticed so far... -Pete ------_=_NextPart_001_01C4740C.F080632D Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Application ID 4

Hi Pete,


I brought this up to the WG a while back. RFC 3588 = allocated MIPv4 an application-id of 2:

2.4.  Application Identifiers

   Each Diameter application MUST have an = IANA assigned Application
   Identifier (see Section 11.3).  = The base protocol does not require an
   Application Identifier since its = support is mandatory.  During the
   capabilities exchange, Diameter nodes = inform their peers of locally
   supported applications.  = Furthermore, all Diameter messages contain
   an Application Identifier, which is = used in the message forwarding
   process.

   The following Application Identifier = values are defined:

      Diameter Common = Messages      0
      = NASREQ           =             = 1 [NASREQ]
      = Mobile-IP          &nb= sp;          2 = [DIAMMIP]
      Diameter Base = Accounting      3
      = Relay           &= nbsp;           &= nbsp; 0xffffffff

So, it appears that the error is in the MIPv4 draft. =

I have not seen a corrected version of the draft yet = though.

Cheers,
Chris

-----Original Message-----
From: Pete McCann [mailto:mccap@lucent.com]
Sent: July 27, 2004 2:53 PM
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Application ID 4



Hi,

In reviewing the latest draft of the credit control = application, I noticed that it appears to use Application ID 4:

>From draft-ietf-aaa-diameter-cc-05.txt:

1.3 Advertising application support 
    
   Diameter nodes conforming to this = specification MUST advertise
   support by including the value of 4 in = the Auth-Application-Id of the
   Capabilities-Exchange-Request and = Capabilities-Exchange-Answer
   command [DIAMBASE]. 


However, my understanding is that this code was = allocated to the Mobile IPv4 application:

4. Diameter Protocol Considerations
   
   This section details the relationship = of the Diameter Mobile IPv4
   application to the Diameter base = protocol.
   
   This document specifies Diameter = Application-ID 4.  Diameter nodes
   conforming to this specification MAY = advertise support by including
   the value of four (4) in the = Auth-Application-Id or the Acct-
   Application-Id AVP of the = Capabilities-Exchange-Request and
   Capabilities-Exchange-Answer command = [DIAMBASE].


Hopefully IANA would have caught this, but I'm not = sure if anyone has noticed so far...

-Pete

------_=_NextPart_001_01C4740C.F080632D-- From owner-aaa-wg@merit.edu Tue Jul 27 15:14: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 PAA08417 for ; Tue, 27 Jul 2004 15:14:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A7D5F9126C; Tue, 27 Jul 2004 15:14:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D25A9126D; Tue, 27 Jul 2004 15:14:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 38BCA9126C for ; Tue, 27 Jul 2004 15:14:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 16FB75A445; Tue, 27 Jul 2004 15:14:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hoemail1.lucent.com (hoemail1.lucent.com [192.11.226.161]) by segue.merit.edu (Postfix) with ESMTP id A60905A3F7 for ; Tue, 27 Jul 2004 15:14:22 -0400 (EDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i6RJEKOQ029195; Tue, 27 Jul 2004 14:14:20 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i6RJEIg15450; Tue, 27 Jul 2004 14:14:18 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id I1IYRS-00010C-00; Tue, 27 Jul 2004 15:14:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16646.43398.946393.699893@gargle.gargle.HOWL> Date: Tue, 27 Jul 2004 14:14:14 -0500 From: Pete McCann To: "Christopher Richards" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application ID 4 In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4D08A3F@zcarhxm2.corp.nortel.com> References: <713043CE8B8E1348AF3C546DBE02C1B4D08A3F@zcarhxm2.corp.nortel.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 Ah, ok, then, my mistake. I'll be sure to fix this in MIPv4 at the next opportunity. -Pete Christopher Richards writes: > Hi Pete, > > > I brought this up to the WG a while back. RFC 3588 allocated MIPv4 an > application-id of 2: > > 2.4. Application Identifiers > > Each Diameter application MUST have an IANA assigned Application > Identifier (see Section 11.3). The base protocol does not require an > Application Identifier since its support is mandatory. During the > capabilities exchange, Diameter nodes inform their peers of locally > supported applications. Furthermore, all Diameter messages contain > an Application Identifier, which is used in the message forwarding > process. > > The following Application Identifier values are defined: > > Diameter Common Messages 0 > NASREQ 1 [NASREQ] > Mobile-IP 2 [DIAMMIP] > Diameter Base Accounting 3 > Relay 0xffffffff > > So, it appears that the error is in the MIPv4 draft. > > I have not seen a corrected version of the draft yet though. > > Cheers, > Chris > > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: July 27, 2004 2:53 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Application ID 4 > > > > Hi, > > In reviewing the latest draft of the credit control application, I noticed > that it appears to use Application ID 4: > > >From draft-ietf-aaa-diameter-cc-05.txt: > > 1.3 Advertising application support > > Diameter nodes conforming to this specification MUST advertise > support by including the value of 4 in the Auth-Application-Id of the > Capabilities-Exchange-Request and Capabilities-Exchange-Answer > command [DIAMBASE]. > > > However, my understanding is that this code was allocated to the Mobile IPv4 > application: > > 4. Diameter Protocol Considerations > > This section details the relationship of the Diameter Mobile IPv4 > application to the Diameter base protocol. > > This document specifies Diameter Application-ID 4. Diameter nodes > conforming to this specification MAY advertise support by including > the value of four (4) in the Auth-Application-Id or the Acct- > Application-Id AVP of the Capabilities-Exchange-Request and > Capabilities-Exchange-Answer command [DIAMBASE]. > > > Hopefully IANA would have caught this, but I'm not sure if anyone has > noticed so far... > > -Pete From owner-aaa-wg@merit.edu Wed Jul 28 02:20: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 CAA26601 for ; Wed, 28 Jul 2004 02:20:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A3A6991288; Wed, 28 Jul 2004 02:19:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7712591289; Wed, 28 Jul 2004 02:19:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4EF0091288 for ; Wed, 28 Jul 2004 02:19:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 14FF95A4F8; Wed, 28 Jul 2004 02:19:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 1E7F45A2F9 for ; Wed, 28 Jul 2004 02:19:56 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6S6JnD18740 for ; Wed, 28 Jul 2004 09:19:49 +0300 (EET DST) X-Scanned: Wed, 28 Jul 2004 09:16:27 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6S6GRJ2012571 for ; Wed, 28 Jul 2004 09:16:27 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 0090oUhd; Wed, 28 Jul 2004 09:16:26 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 i6S6GLu00717 for ; Wed, 28 Jul 2004 09:16:21 +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); Wed, 28 Jul 2004 09:16:19 +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]: AAA WG last call on the URI Scheme for AAA protocols Date: Wed, 28 Jul 2004 09:16:18 +0300 Message-ID: Thread-Topic: [AAA-WG]: AAA WG last call on Diameter SIP Application Thread-Index: AcRzSr3fxSOzTDpxQCaZ07oI0hOH8QBH0ueg From: To: X-OriginalArrivalTime: 28 Jul 2004 06:16:19.0947 (UTC) FILETIME=[65FA3BB0:01C4746A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable This is an announcement of AAA WG Last Call on the "Uniform Resource = Identifier=20 (URI) schemes for Authentication, Authorization and Accounting (AAA) = protocols"=20 specification, prior to sending the draft on to the IESG for = consideration as=20 an IETF Proposed Standard. The draft is available for inspection at: http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-01.txt This Draft proposes a small update to RFC 3588. AAA WG Last Call will complete on August 18, 2004. Please send comments to the AAA WG mailing list (aaa-wg@merit.edu), using the issue format described at=20 http://www.drizzle.com/~aboba/AAA/issues.html. thanks, John From owner-aaa-wg@merit.edu Wed Jul 28 02:36: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 CAA07792 for ; Wed, 28 Jul 2004 02:36:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E3AB091289; Wed, 28 Jul 2004 02:36:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B31589128A; Wed, 28 Jul 2004 02:36:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7EBC891289 for ; Wed, 28 Jul 2004 02:36:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 54E625A67F; Wed, 28 Jul 2004 02:36:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 931115A5B5 for ; Wed, 28 Jul 2004 02:36:27 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6S6aLD13325; Wed, 28 Jul 2004 09:36:22 +0300 (EET DST) X-Scanned: Wed, 28 Jul 2004 09:31:48 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6S6VmpH027541; Wed, 28 Jul 2004 09:31:48 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00C965gx; Wed, 28 Jul 2004 09:31:47 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 i6S6Vlu13566; Wed, 28 Jul 2004 09:31:47 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Jul 2004 09:31:47 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Jul 2004 09:31:45 +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]: AAA WG Agenda at IETF 60, take 2 Date: Wed, 28 Jul 2004 09:31:45 +0300 Message-ID: Thread-Topic: [AAA-WG]: AAA WG Agenda at IETF 60 Thread-Index: AcRzIjg1MOw7N8vdRfiVRjvhNlV5HABShTtA From: To: , X-OriginalArrivalTime: 28 Jul 2004 06:31:45.0770 (UTC) FILETIME=[8DCF9CA0:01C4746C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Authentication, Authorization and Accounting (AAA) WG Tuesday, August 3, 2004 1300-1400 Chairs: Bernard Aboba John Loughney David Mitton Preliminaries (10 minutes) Agenda Bluesheets Agenda Bash Document Status Diameter MIPv4, Pete McCann, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-19.t= xt Diameter NASREQ, David Mitton, 10 minutes http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-nasreq-17.txt Diameter Credit Control, John Loughney, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-05.txt Diameter URI, M. Garcia-Martin, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-01.txt Diameter SIP, M. Belinchon, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-03.tx= t Tea Break Second Session 1415 - 1515 Diameter EAP, Pasi Eronen, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-08.txt EAP Key Management Issues, Bernard Aboba, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-03.txt Alternative EAP keying approaches, Glen Zorn & Jesse Walker, 15 minutes http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-02.txt Diameter QoS application, Hannes Tschofenig, 5 minutes http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosprot-00.txt Discussion - 10 minutes Wrapup - 10 minutes From owner-aaa-wg@merit.edu Wed Jul 28 02:38: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 CAA07950 for ; Wed, 28 Jul 2004 02:38:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AD4769128A; Wed, 28 Jul 2004 02:38:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 80C309128B; Wed, 28 Jul 2004 02:38:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4E7C69128A for ; Wed, 28 Jul 2004 02:38:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 37E835A689; Wed, 28 Jul 2004 02:38:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 65C495A68E for ; Wed, 28 Jul 2004 02:38:11 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6S6c5021828; Wed, 28 Jul 2004 09:38:05 +0300 (EET DST) X-Scanned: Wed, 28 Jul 2004 09:33:42 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i6S6XgYZ024533; Wed, 28 Jul 2004 09:33:42 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00IXxmQV; Wed, 28 Jul 2004 09:33:40 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6S6XXn15358; Wed, 28 Jul 2004 09:33:33 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Jul 2004 09:33:22 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Application ID 4 Date: Wed, 28 Jul 2004 09:33:22 +0300 Message-ID: Thread-Topic: [AAA-WG]: Application ID 4 Thread-Index: AcR0LZCYVQDxTh/wQEK+kiY2pFztPgAPygAQ From: To: , X-OriginalArrivalTime: 28 Jul 2004 06:33:22.0466 (UTC) FILETIME=[C7724020:01C4746C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pete, I will fix this when I rev the document after IETF60 - we need one more rev to clear IESG comments. thanks, John > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Pete McCann > Sent: 27 July, 2004 21:53 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Application ID 4 >=20 >=20 >=20 > Hi, >=20 > In reviewing the latest draft of the credit control application, I > noticed that it appears to use Application ID 4: >=20 > >From draft-ietf-aaa-diameter-cc-05.txt: >=20 > 1.3 Advertising application support =20 > =20 > Diameter nodes conforming to this specification MUST advertise=20 > support by including the value of 4 in the=20 > Auth-Application-Id of the=20 > Capabilities-Exchange-Request and Capabilities-Exchange-Answer=20 > command [DIAMBASE]. =20 >=20 >=20 > However, my understanding is that this code was allocated to=20 > the Mobile > IPv4 application: >=20 > 4. Diameter Protocol Considerations=20 > =20 > This section details the relationship of the Diameter Mobile IPv4=20 > application to the Diameter base protocol.=20 > =20 > This document specifies Diameter Application-ID 4. Diameter nodes=20 > conforming to this specification MAY advertise support by=20 > including=20 > the value of four (4) in the Auth-Application-Id or the Acct- > Application-Id AVP of the Capabilities-Exchange-Request and=20 > Capabilities-Exchange-Answer command [DIAMBASE].=20 >=20 >=20 > Hopefully IANA would have caught this, but I'm not sure if anyone has > noticed so far... >=20 > -Pete >=20 >=20 From owner-aaa-wg@merit.edu Wed Jul 28 04:01: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 EAA12650 for ; Wed, 28 Jul 2004 04:01:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 865029120D; Wed, 28 Jul 2004 04:00:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD7139128B; Wed, 28 Jul 2004 04:00:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 88A169120D for ; Wed, 28 Jul 2004 04:00:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 747025A5A0; Wed, 28 Jul 2004 04:00:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id B08AF59DC2 for ; Wed, 28 Jul 2004 04:00:48 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6S80jm10312; Wed, 28 Jul 2004 11:00:45 +0300 (EET DST) X-Scanned: Wed, 28 Jul 2004 10:56:34 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i6S7uYme020201; Wed, 28 Jul 2004 10:56:34 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00luqEun; Wed, 28 Jul 2004 10:56:32 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6S7uTn04286; Wed, 28 Jul 2004 10:56:29 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Jul 2004 10:56:28 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Jul 2004 10:56:28 +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]: AAA WG Agenda at IETF 60, take 3 Date: Wed, 28 Jul 2004 10:56:27 +0300 Message-ID: Thread-Topic: [AAA-WG]: AAA WG Agenda at IETF 60 Thread-Index: AcRzIjg1MOw7N8vdRfiVRjvhNlV5HABShTtAAAL/QgA= From: To: , , X-OriginalArrivalTime: 28 Jul 2004 07:56:28.0712 (UTC) FILETIME=[637B0280:01C47478] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable John Loughney David Mitton Preliminaries (10 minutes) Agenda Bluesheets Agenda Bash Document Status Diameter MIPv4, Pete McCann, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-19.t= xt Diameter NASREQ, David Mitton, 10 minutes http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-nasreq-17.txt Diameter Credit Control, John Loughney, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-05.txt Diameter URI, M. Garcia-Martin, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-01.txt Diameter SIP, M. Garcia-Martin, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-03.tx= t Tea Break Second Session 1415 - 1515 Diameter EAP, Pasi Eronen, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-08.txt EAP Key Management Issues, Bernard Aboba, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-03.txt Alternative EAP keying approaches, Glen Zorn & Jesse Walker, 15 minutes http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-02.txt Diameter QoS application, Hannes Tschofenig, 5 minutes http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosprot-00.txt Discussion - 10 minutes Wrapup - 10 minutes From owner-aaa-wg@merit.edu Wed Jul 28 06:44: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 GAA19939 for ; Wed, 28 Jul 2004 06:44:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5C3339128F; Wed, 28 Jul 2004 06:43:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2991B91290; Wed, 28 Jul 2004 06:43:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 016869128F for ; Wed, 28 Jul 2004 06:43:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DD8FF5A75F; Wed, 28 Jul 2004 06:43:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id EEB8B5A751 for ; Wed, 28 Jul 2004 06:43:50 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6SAhWD12147; Wed, 28 Jul 2004 13:43:32 +0300 (EET DST) X-Scanned: Wed, 28 Jul 2004 13:40:41 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6SAefnb019856; Wed, 28 Jul 2004 13:40:41 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00WoDEzU; Wed, 28 Jul 2004 13:40:40 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6SAedn11958; Wed, 28 Jul 2004 13:40:39 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Jul 2004 13:40:38 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Application ID 4 Date: Wed, 28 Jul 2004 13:40:35 +0300 Message-ID: Thread-Topic: [AAA-WG]: Application ID 4 Thread-Index: AcR0LZCYVQDxTh/wQEK+kiY2pFztPgAYaB2A From: To: , X-OriginalArrivalTime: 28 Jul 2004 10:40:38.0135 (UTC) FILETIME=[5231B070:01C4748F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Pete, > 1.3 Advertising application support =20 > =20 > Diameter nodes conforming to this specification MUST advertise=20 > support by including the value of 4 in the Auth-Application-Id of = the=20 > Capabilities-Exchange-Request and Capabilities-Exchange-Answer=20 > command [DIAMBASE]. =20 >=20 >=20 > However, my understanding is that this code was allocated to the = Mobile > IPv4 application: From RFC 3588: 11.3. Application Identifiers As defined in Section 2.4, the Application Identifier is used to identify a specific Diameter Application. There are standards-track application ids and vendor specific application ids. IANA [IANA] has assigned the range 0x00000001 to 0x00ffffff for standards-track applications; and 0x01000000 - 0xfffffffe for vendor specific applications, on a first-come, first-served basis. The following values are allocated. Diameter Common Messages 0 NASREQ 1 [NASREQ] Mobile-IP 2 [DIAMMIP] Diameter Base Accounting 3 Relay 0xffffffff Why do you think the application ID for MIP is 4? John From owner-aaa-wg@merit.edu Thu Jul 29 02:08: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 CAA11826 for ; Thu, 29 Jul 2004 02:08:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DE4249122B; Thu, 29 Jul 2004 02:08:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A9D1E91230; Thu, 29 Jul 2004 02:08:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 795119122B for ; Thu, 29 Jul 2004 02:08:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 68ABF5A570; Thu, 29 Jul 2004 02:08:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 9F5A85A532 for ; Thu, 29 Jul 2004 02:08:35 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6T68Xm16179; Thu, 29 Jul 2004 09:08:33 +0300 (EET DST) X-Scanned: Thu, 29 Jul 2004 09:08:17 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6T68HXg032684; Thu, 29 Jul 2004 09:08:17 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00xPcWQo; Thu, 29 Jul 2004 09:08:17 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6T68Cu14113; Thu, 29 Jul 2004 09:08:12 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Jul 2004 09:07:41 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: AAA WG Agenda at IETF 60, take 4 Date: Thu, 29 Jul 2004 09:07:41 +0300 Message-ID: Thread-Topic: [AAA-WG]: AAA WG Agenda at IETF 60 Thread-Index: AcRzIjg1MOw7N8vdRfiVRjvhNlV5HABShTtAAAL/QgAALnlc4A== From: To: Cc: X-OriginalArrivalTime: 29 Jul 2004 06:07:41.0597 (UTC) FILETIME=[5B6E0CD0:01C47532] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, Slight reshuffling of the agenda, hopefully this is the final agenda. John John Loughney David Mitton Preliminaries (10 minutes) Agenda Bluesheets Agenda Bash Document Status Diameter MIPv4, Pete McCann, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-19.t= xt Diameter NASREQ, David Mitton, 10 minutes http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-nasreq-17.txt Diameter Credit Control, John Loughney, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-05.txt Diameter URI, M. Garcia-Martin, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-01.txt Diameter SIP, M. Garcia-Martin, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-03.tx= t Diameter QoS application, Hannes Tschofenig, 10 minutes http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosprot-00.txt Tea Break Second Session 1415 - 1515 Diameter EAP, Pasi Eronen, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-08.txt EAP Key Management Issues, Bernard Aboba, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-03.txt Alternative EAP keying approaches, Glen Zorn & Jesse Walker, 15 minutes http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-02.txt Discussion - 10 minutes Wrapup - 10 minutes From owner-aaa-wg@merit.edu Fri Jul 30 08:18: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 IAA01992 for ; Fri, 30 Jul 2004 08:18:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1A83D91214; Fri, 30 Jul 2004 08:17:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E057F91218; Fri, 30 Jul 2004 08:17:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B1DAC91214 for ; Fri, 30 Jul 2004 08:17:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8494A5A5B2; Fri, 30 Jul 2004 08:17:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 508165A58E for ; Fri, 30 Jul 2004 08:17:51 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6UCHnW29755 for ; Fri, 30 Jul 2004 15:17:49 +0300 (EET DST) X-Scanned: Fri, 30 Jul 2004 15:13:54 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i6UCDs1P015817 for ; Fri, 30 Jul 2004 15:13:54 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00XeEi5j; Fri, 30 Jul 2004 15:13:52 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6UCDpn16267 for ; Fri, 30 Jul 2004 15:13:51 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Jul 2004 15:13:50 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Jul 2004 15:13:50 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: AAA WG Agenda at IETF 60, take 5 - for review Date: Fri, 30 Jul 2004 15:13:50 +0300 Message-ID: Thread-Topic: [AAA-WG]: AAA WG Agenda at IETF 60 Thread-Index: AcRzIjg1MOw7N8vdRfiVRjvhNlV5HABShTtAAAL/QgAALnlc4AA/CoaQ From: To: X-OriginalArrivalTime: 30 Jul 2004 12:13:50.0111 (UTC) FILETIME=[AC1902F0:01C4762E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, Due to an conflict in the 2nd session, we've been asked if we could = discuss the EAP topics during the first session. Please let me know if this causes any problems. Proposed agenda is as follows. Preliminaries (10 minutes) Agenda Bluesheets Agenda Bash Document Status Diameter EAP, Pasi Eronen, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-08.txt EAP Key Management Issues, Bernard Aboba, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-03.txt Alternative EAP keying approaches, Glen Zorn & Jesse Walker, 15 minutes http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-02.txt Discussion - 10 minutes Diameter QoS application, Hannes Tschofenig, 10 minutes http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosprot-00.txt Tea Break Second Session 1415 - 1515 Diameter MIPv4, Pete McCann, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-19.t= xt Diameter NASREQ, David Mitton, 10 minutes http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-nasreq-17.txt Diameter Credit Control, John Loughney, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-05.txt Diameter URI, M. Garcia-Martin, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-01.txt Diameter SIP, M. Garcia-Martin, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-03.tx= t Wrapup - 10 minutes