From owner-aaa-wg@merit.edu Tue Nov 2 09:26:32 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23872 for ; Tue, 2 Nov 2004 09:26:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6D40791206; Tue, 2 Nov 2004 09:26:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 36C3B9124A; Tue, 2 Nov 2004 09:26:25 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E829491206 for ; Tue, 2 Nov 2004 09:26:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id D31BCB2205; Tue, 2 Nov 2004 09:26:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id D4F9BB2285 for ; Tue, 2 Nov 2004 09:26:22 -0500 (EST) 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 iA2EQHE27086 for ; Tue, 2 Nov 2004 16:26:17 +0200 (EET) X-Scanned: Tue, 2 Nov 2004 16:22:59 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iA2EMxKp016409 for ; Tue, 2 Nov 2004 16:22:59 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00RFV6cy; Tue, 02 Nov 2004 16:22:57 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2EMua20644 for ; Tue, 2 Nov 2004 16:22:56 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Nov 2004 16:22:44 +0200 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Nov 2004 16:22:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: [AAA] Using DIAMETER_MISSING_AVP for optional AVP Date: Tue, 2 Nov 2004 16:22:43 +0200 Message-ID: <78577AECEB6226409F9F4BFB53FE183708F7A6@esebe054.ntc.nokia.com> Thread-Topic: [AAA] Using DIAMETER_MISSING_AVP for optional AVP Thread-Index: AcS+XAG9uru3HxFeR+iNpPqzk9TTHQCip6DQ From: To: X-OriginalArrivalTime: 02 Nov 2004 14:22:44.0078 (UTC) FILETIME=[6B24F8E0:01C4C0E7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, I think DIAMETER_MISSING_AVP can be used to indicate that an optional AVP (defined inside '[]' in the ABNF) is missing in the received = command. I think this is useful for example for Diameter Applications that have AVPs that are defined to be present in certain conditions and absent in other conditions. BR, Mikko -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext MORAND Lionel RD-CORE-ISS Sent: 30 October, 2004 11:40 To: aaa-wg@merit.edu Subject: [AAA-WG]: [AAA] Using DIAMETER_MISSING_AVP for optional AVP Hi AAA folks, In the RFC 3588, the result-code DIAMETER_MISSING_AVP is ussed to = indicate that a mandatory AVP (required by the command code ABNF = specification) is missing in the received command. Is it possible to use the DIAMETER_MISSING_AVP result code along with = the Failed-AVP AVP to indicate that an optional AVP (from the ABNF point = of view) is missing in the received command? If not, could you identify = some operational issues? Any opinion? Lionel From owner-aaa-wg@merit.edu Tue Nov 2 10:01:47 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27116 for ; Tue, 2 Nov 2004 10:01:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 956439124A; Tue, 2 Nov 2004 10:01:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E6479124E; Tue, 2 Nov 2004 10:01:21 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E78929124A for ; Tue, 2 Nov 2004 10:01:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id CD6EEB1E5C; Tue, 2 Nov 2004 10:01:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id DFBE0B1C4D for ; Tue, 2 Nov 2004 10:01:18 -0500 (EST) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2F1Gl22274; Tue, 2 Nov 2004 17:01:16 +0200 (EET) X-Scanned: Tue, 2 Nov 2004 16:56:45 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iA2Eujbb024455; Tue, 2 Nov 2004 16:56:45 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 004Yhgo3; Tue, 02 Nov 2004 16:56:44 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2EuiS09138; Tue, 2 Nov 2004 16:56:44 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Nov 2004 16:56:44 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Nov 2004 16:56:45 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Nov 2004 16:56:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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]: Using DIAMETER_MISSING_AVP for optional AVP Date: Tue, 2 Nov 2004 16:56:43 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D431F39@esebe056.ntc.nokia.com> Thread-Topic: [AAA] Using DIAMETER_MISSING_AVP for optional AVP Thread-Index: AcS+XAG9uru3HxFeR+iNpPqzk9TTHQCj6+bQ From: To: , X-OriginalArrivalTime: 02 Nov 2004 14:56:44.0337 (UTC) FILETIME=[2B3BCA10:01C4C0EC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Lionel, > In the RFC 3588, the result-code DIAMETER_MISSING_AVP is ussed to = indicate that a mandatory AVP=20 > (required by the command code ABNF specification) is missing in the = received command. >=20 > Is it possible to use the DIAMETER_MISSING_AVP result code along with = the Failed-AVP AVP to indicate=20 > that an optional AVP (from the ABNF point of view) is missing in the = received command? If not, could=20 > you identify some operational issues? From 3588: DIAMETER_MISSING_AVP 5005 The request did not contain an AVP that is required by the Command Code definition. If this value is sent in the Result-Code AVP, a Failed-AVP AVP SHOULD be included in the message. The Failed-AVP AVP MUST contain an example of the missing AVP complete with the Vendor-Id if applicable. The value field of the missing AVP should be of correct minimum length and contain zeroes. My guess is that if a particular implementation or application was = expecting an AVP to be included, this would be a reasonable way to do it. John From owner-aaa-wg@merit.edu Tue Nov 2 11:04:35 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04298 for ; Tue, 2 Nov 2004 11:04:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 58B7C91217; Tue, 2 Nov 2004 11:04:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A7139124C; Tue, 2 Nov 2004 11:04:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D5A7C91217 for ; Tue, 2 Nov 2004 11:04:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id A0625B2123; Tue, 2 Nov 2004 11:04:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by segue.merit.edu (Postfix) with ESMTP id CFE41B210F for ; Tue, 2 Nov 2004 11:04:26 -0500 (EST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Nov 2004 17:02:22 +0100 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.5.7226.0 Subject: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Date: Tue, 2 Nov 2004 17:02:19 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0260186055F@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Thread-Index: AcS+XAG9uru3HxFeR+iNpPqzk9TTHQCj6+bQAAHydMA= From: "MORAND Lionel RD-CORE-ISS" To: , X-OriginalArrivalTime: 02 Nov 2004 16:02:22.0759 (UTC) FILETIME=[56B74B70:01C4C0F5] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > From 3588: >=20 > DIAMETER_MISSING_AVP 5005 > The request did not contain an AVP that is required by the Command > Code definition. If this value is sent in the Result-Code AVP, a > Failed-AVP AVP SHOULD be included in the message. The Failed-AVP > AVP MUST contain an example of the missing AVP complete with the > Vendor-Id if applicable. The value field of the missing AVP > should be of correct minimum length and contain zeroes. >=20 > My guess is that if a particular implementation or=20 > application was expecting an AVP to be included, this would=20 > be a reasonable way to do it. >=20 Based on this definition, it is only applicable to AVP "required by the command code definition". It is not clear if we could reuse the same result code for an optional AVP. If there is a general consensus on this topic, maybe a modification to the existing definition should be done. Besides, if we could reuse the same result code for required or optional AVP, should we state that "a Failed-AVP AVP MUST be included" instead of "should be included"? My assumption was that a "SHOULD" was possible here because you could have relyed on the command code ABNF descritpion to find the missing AVP. If the above assupmtion is correct, it is not possible anymore and you have to use the Failed-AVP. Lionel From owner-aaa-wg@merit.edu Wed Nov 3 07:40:21 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03005 for ; Wed, 3 Nov 2004 07:40:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5CD529122B; Wed, 3 Nov 2004 07:40:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C7E19122E; Wed, 3 Nov 2004 07:40:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CFA7B9122B for ; Wed, 3 Nov 2004 07:40:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id B0B26B2317; Wed, 3 Nov 2004 07:40:12 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by segue.merit.edu (Postfix) with ESMTP id EE79AB2304 for ; Wed, 3 Nov 2004 07:40:11 -0500 (EST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Nov 2004 13:37:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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]: Using DIAMETER_MISSING_AVP for optional AVP Date: Wed, 3 Nov 2004 13:37:03 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0260186077B@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Thread-Index: AcS+XAG9uru3HxFeR+iNpPqzk9TTHQCj6+bQAAHydMAAKx2G8A== From: "MORAND Lionel RD-CORE-ISS" To: , X-OriginalArrivalTime: 03 Nov 2004 12:37:04.0853 (UTC) FILETIME=[D315C050:01C4C1A1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi John, Another question: what is the purpose of defining required/optional AVP in the command = code ABNF description? If DIAMETER_MISSING_AVP could be used for any missing AVP whatever its = category (required/optional), there is no reason to define required AVP = for a specific command code. Any AVP used in the command code ABNF = definition could be defined as optional. Is it correct? Lionel > -----Message d'origine----- > De : owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]=20 > De la part de MORAND Lionel RD-CORE > Envoy=E9 : mardi 2 novembre 2004 17:02 > =C0 : john.loughney@nokia.com; aaa-wg@merit.edu > Objet : RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP >=20 >=20 > > From 3588: > >=20 > > DIAMETER_MISSING_AVP 5005 > > The request did not contain an AVP that is required by the > Command > > Code definition. If this value is sent in the=20 > Result-Code AVP, > a > > Failed-AVP AVP SHOULD be included in the message. The > Failed-AVP > > AVP MUST contain an example of the missing AVP=20 > complete with the > > Vendor-Id if applicable. The value field of the missing AVP > > should be of correct minimum length and contain zeroes. > >=20 > > My guess is that if a particular implementation or > > application was expecting an AVP to be included, this would=20 > > be a reasonable way to do it. > >=20 >=20 > Based on this definition, it is only applicable to AVP=20 > "required by the > command code definition". It is not clear if we could reuse the same > result code for an optional AVP. > If there is a general consensus on this topic, maybe a modification to > the existing definition should be done. >=20 > Besides, if we could reuse the same result code for required=20 > or optional > AVP, should we state that "a Failed-AVP AVP MUST be included"=20 > instead of > "should be included"? > My assumption was that a "SHOULD" was possible here because you could > have relyed on the command code ABNF descritpion to find the missing > AVP. If the above assupmtion is correct, it is not possible=20 > anymore and > you have to use the Failed-AVP. >=20 > Lionel >=20 From owner-aaa-wg@merit.edu Wed Nov 3 07:54:12 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04163 for ; Wed, 3 Nov 2004 07:54:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B9C3F9122E; Wed, 3 Nov 2004 07:54:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D7EA91233; Wed, 3 Nov 2004 07:54:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5A1389122E for ; Wed, 3 Nov 2004 07:53:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 44A5BB22E0; Wed, 3 Nov 2004 07:53:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 44C59B230B for ; Wed, 3 Nov 2004 07:53:58 -0500 (EST) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA3Crue00219; Wed, 3 Nov 2004 14:53:56 +0200 (EET) X-Scanned: Wed, 3 Nov 2004 14:50:55 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iA3CotLB010656; Wed, 3 Nov 2004 14:50:55 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00DvA2lt; Wed, 03 Nov 2004 14:50:54 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA3ConS10923; Wed, 3 Nov 2004 14:50:49 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Nov 2004 14:50:28 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Nov 2004 14:50:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Date: Wed, 3 Nov 2004 14:50:27 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D095850@esebe056.ntc.nokia.com> Thread-Topic: [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Thread-Index: AcS+XAG9uru3HxFeR+iNpPqzk9TTHQCj6+bQAAHydMAAKx2G8AAAwWKQ From: To: , X-OriginalArrivalTime: 03 Nov 2004 12:50:28.0463 (UTC) FILETIME=[B212E7F0:01C4C1A3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > > From 3588: > >=20 > > DIAMETER_MISSING_AVP 5005 > > The request did not contain an AVP that is required by the = Command > > Code definition. If this value is sent in the Result-Code = AVP, a > > Failed-AVP AVP SHOULD be included in the message. The = Failed-AVP > > AVP MUST contain an example of the missing AVP complete with = the > > Vendor-Id if applicable. The value field of the missing AVP > > should be of correct minimum length and contain zeroes. > >=20 > > My guess is that if a particular implementation or > > application was expecting an AVP to be included, this would=20 > > be a reasonable way to do it. > >=20 >=20 > Based on this definition, it is only applicable to AVP "required by = the > command code definition". It is not clear if we could reuse the same > result code for an optional AVP. So, you were asking about Conditional AVPs. There are no such things as conditional AVPs in the base spec, that is why they are not mentioned. I am aware that there are some 'vendors' making Diameter extensions to=20 introduce this kind of 'feature.' I don't see why those 'vendors' can't = use DIAMETER_MISSING_AVP to mean a conditional AVP as well. =20 > If there is a general consensus on this topic, maybe a modification to > the existing definition should be done. Why? Diameter has no notion of conditional AVPs. > Besides, if we could reuse the same result code for required or = optional > AVP, should we state that "a Failed-AVP AVP MUST be included" instead = of > "should be included"? What is your reasoning for this? > My assumption was that a "SHOULD" was possible here because you could > have relyed on the command code ABNF descritpion to find the missing > AVP. If the above assupmtion is correct, it is not possible anymore = and > you have to use the Failed-AVP. I'm sorry, could you restate what you mean, I am having a hard time = understanding your point. thanks, John From owner-aaa-wg@merit.edu Wed Nov 3 08:23:25 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07208 for ; Wed, 3 Nov 2004 08:23:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3CE439122F; Wed, 3 Nov 2004 08:23:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C8DC91233; Wed, 3 Nov 2004 08:23:18 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AFBFC9122F for ; Wed, 3 Nov 2004 08:23:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9B512B2056; Wed, 3 Nov 2004 08:23:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by segue.merit.edu (Postfix) with ESMTP id 05870B234C for ; Wed, 3 Nov 2004 08:23:17 -0500 (EST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Nov 2004 14:22:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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 : RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Date: Wed, 3 Nov 2004 14:22:23 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026018607A5@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Thread-Index: AcS+XAG9uru3HxFeR+iNpPqzk9TTHQCj6+bQAAHydMAAKx2G8AAAwWKQAACX0RA= From: "MORAND Lionel RD-CORE-ISS" To: , X-OriginalArrivalTime: 03 Nov 2004 13:22:25.0291 (UTC) FILETIME=[2897A5B0:01C4C1A8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi John, I didn't say anything about "conditional" AVP ;-) > > > My guess is that if a particular implementation or=20 > application was=20 > > > expecting an AVP to be included, this would be a=20 > reasonable way to=20 > > > do it. > > >=20 > >=20 > > Based on this definition, it is only applicable to AVP "required by=20 > > the command code definition". It is not clear if we could reuse the=20 > > same result code for an optional AVP. >=20 > So, you were asking about Conditional AVPs. There are no=20 > such things as conditional AVPs in the base spec, that is why=20 > they are not mentioned. >=20 > I am aware that there are some 'vendors' making Diameter=20 > extensions to=20 > introduce this kind of 'feature.' I don't see why those=20 > 'vendors' can't use DIAMETER_MISSING_AVP to mean a=20 > conditional AVP as well. =20 [LM] The problem is not restricted to conditional AVPs. Based on your response, you could use DIAMETER_MISSING_AVP for any optional AVP, based on specific service logic using a given Diameter application. >=20 > > If there is a general consensus on this topic, maybe a=20 > modification to=20 > > the existing definition should be done. >=20 > Why? Diameter has no notion of conditional AVPs. [LM] Because this would apply to any optional AVP used in the command (whatever the use of this optional AVP). =20 > > Besides, if we could reuse the same result code for required or=20 > > optional AVP, should we state that "a Failed-AVP AVP MUST=20 > be included"=20 > > instead of "should be included"? >=20 > What is your reasoning for this? >=20 > > My assumption was that a "SHOULD" was possible here because=20 > you could=20 > > have relyed on the command code ABNF descritpion to find=20 > the missing=20 > > AVP. If the above assupmtion is correct, it is not possible anymore=20 > > and you have to use the Failed-AVP. >=20 > I'm sorry, could you restate what you mean, I am having a=20 > hard time understanding your point. [LM] If DIAMETER_MISSING_AVP can be used for any missing AVP (required or optional), a Failed-AVP AVP MUST be included in the message, to indicate to the originator of the request what is the missing AVP. If DIAMETER_MISSING_AVP is used alone, the originator would not be able to rely on the command code ABNF definition to find the missing AVP. Thanks, Lionel From owner-aaa-wg@merit.edu Thu Nov 4 02:45:09 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22786 for ; Thu, 4 Nov 2004 02:45:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 194EB9125A; Thu, 4 Nov 2004 02:44:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB0869125B; Thu, 4 Nov 2004 02:44:55 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E15D69125A for ; Thu, 4 Nov 2004 02:44:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id C7142B24DB; Thu, 4 Nov 2004 02:44:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by segue.merit.edu (Postfix) with ESMTP id 98348B24D3 for ; Thu, 4 Nov 2004 02:44:54 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CPcIg-000EQM-0m for aaa-wg@merit.edu; Thu, 04 Nov 2004 02:44:54 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iA47iqB32639 for ; Wed, 3 Nov 2004 23:44:52 -0800 Date: Wed, 3 Nov 2004 23:44:52 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Status of Diameter SIP Application? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Sender: owner-aaa-wg@merit.edu Precedence: bulk AAA WG last call has concluded on the Diameter SIP application. Can the editors provide a status on the open/resolved issues in the document? Also, the RADIUS Digest Authentication specification has also completed RADEXT WG last call. Are there any open issues relating to Diameter/RADIUS interoperability? From owner-aaa-wg@merit.edu Thu Nov 4 03:26:10 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26176 for ; Thu, 4 Nov 2004 03:26:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6D2919125B; Thu, 4 Nov 2004 03:26:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3EB5B9125C; Thu, 4 Nov 2004 03:26:03 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 28C079125B for ; Thu, 4 Nov 2004 03:26:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 115DBB2547; Thu, 4 Nov 2004 03:26:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 3C289B251D for ; Thu, 4 Nov 2004 03:26:01 -0500 (EST) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA48Mml25322; Thu, 4 Nov 2004 10:22:48 +0200 (EET) X-Scanned: Thu, 4 Nov 2004 10:21:06 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iA48L60C030369; Thu, 4 Nov 2004 10:21:06 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00HJfE1i; Thu, 04 Nov 2004 10:21:05 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA48L5a13489; Thu, 4 Nov 2004 10:21:05 +0200 (EET) Received: from [172.21.37.239] ([172.21.37.239]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Nov 2004 10:20:50 +0200 Message-ID: <4189E663.8090105@nokia.com> Date: Thu, 04 Nov 2004 10:20:51 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu, "Beck01, Wolfgang" Subject: Re: [AAA-WG]: Status of Diameter SIP Application? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Nov 2004 08:20:50.0673 (UTC) FILETIME=[31C5CE10:01C4C247] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bernard and all: Here is the status of the Diameter SIP application: The document completed WG last call. There were a number of open issues, some of them were already introduced in the current version of the draft, others are still pending of reworks. All the open issues are documented in this web page: http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/ One of these open issues, suggested by Jari Arkko, indicated that the Diameter SIP application should resuse the Digest-* AVPs from the Radius Digest draft. This requires a substantial rework of the draft. Unfortunately I didn't have enough time to do the rework, but I am confident that I will have a new reworked version before Christmas. Additionally, Wolfgang and me will be meeting in Washington in order to find out how to better synchronize the Radius and Diameter drafts. - Miguel Bernard Aboba wrote: > AAA WG last call has concluded on the Diameter SIP application. > > Can the editors provide a status on the open/resolved issues in the > document? Also, the RADIUS Digest Authentication specification has also > completed RADEXT WG last call. Are there any open issues relating to > Diameter/RADIUS interoperability? > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Thu Nov 4 03:51:29 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28098 for ; Thu, 4 Nov 2004 03:51:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7E47291201; Thu, 4 Nov 2004 03:51:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51FFC9125C; Thu, 4 Nov 2004 03:51:23 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1558491201 for ; Thu, 4 Nov 2004 03:51:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id E25C8B2470; Thu, 4 Nov 2004 03:51:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by segue.merit.edu (Postfix) with ESMTP id 2AB3EB2497 for ; Thu, 4 Nov 2004 03:51:21 -0500 (EST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Nov 2004 09:51:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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]: Using DIAMETER_MISSING_AVP for optional AVP Date: Thu, 4 Nov 2004 09:51:08 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026018609CE@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Thread-Index: AcS+XAG9uru3HxFeR+iNpPqzk9TTHQCj6+bQAAHydMAAKx2G8AAAwWKQAACX0RAAKQ6kwA== From: "MORAND Lionel RD-CORE-ISS" To: , X-OriginalArrivalTime: 04 Nov 2004 08:51:18.0356 (UTC) FILETIME=[73281940:01C4C24B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi John, I repeat that this mechanism is not restricted to conditional AVPs but could be generalized to any optional AVP.=20 > > I am aware that there are some 'vendors' making Diameter > > extensions to=20 > > introduce this kind of 'feature.' I don't see why those=20 > > 'vendors' can't use DIAMETER_MISSING_AVP to mean a=20 > > conditional AVP as well. =20 About the last point: Some 'vendors' try to design properly their Diameter extensions. The philosophy is: If it's possible with the standard mecanisms, use the standard specs; if not, define the suitable solution. So here the question is not to know what it is possible to do within a 'vendor' specific implementation. The question is: Does the RFC 3588 allow (or not prevent) to use DIAMETER_MISSING_AVP for an optional AVP? If not, It's up to the 'vendors' to decide how to solve this issue. Lionel From owner-aaa-wg@merit.edu Thu Nov 4 06:08:34 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09182 for ; Thu, 4 Nov 2004 06:08:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1362A9120F; Thu, 4 Nov 2004 06:08:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D53719125D; Thu, 4 Nov 2004 06:08:28 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6BD339120F for ; Thu, 4 Nov 2004 06:08:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 56815B22B4; Thu, 4 Nov 2004 06:08:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 91658B2470 for ; Thu, 4 Nov 2004 06:08:26 -0500 (EST) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA4B8Ol19600 for ; Thu, 4 Nov 2004 13:08:25 +0200 (EET) X-Scanned: Thu, 4 Nov 2004 13:04:23 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iA4B4NfI006166 for ; Thu, 4 Nov 2004 13:04:23 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00xUIY1v; Thu, 04 Nov 2004 13:03:44 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA4Acwa16199 for ; Thu, 4 Nov 2004 12:38:58 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Nov 2004 12:38:58 +0200 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Nov 2004 12:38:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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]: Using DIAMETER_MISSING_AVP for optional AVP Date: Thu, 4 Nov 2004 12:38:57 +0200 Message-ID: <78577AECEB6226409F9F4BFB53FE183708F7A7@esebe054.ntc.nokia.com> Thread-Topic: [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Thread-Index: AcS+XAG9uru3HxFeR+iNpPqzk9TTHQCj6+bQAAHydMAAWU8p8A== From: To: X-OriginalArrivalTime: 04 Nov 2004 10:38:58.0090 (UTC) FILETIME=[7D7548A0:01C4C25A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, > Based on this definition, it is only applicable to AVP=20 > "required by the command code definition". It is not clear if > we could reuse the same result code for an optional AVP. In my opinion here "command code definition" refers to the whole definition of the command, not just the ABNF. Some parts of the definition are often presented in "free" text. For example, Diameter Application command definition might state that Pet-Poodle AVP must be present in the message in case it is Friday the 13th. :) > My assumption was that a "SHOULD" was possible here because you could > have relyed on the command code ABNF descritpion to find the missing = AVP. So if the command-code ABNF definition defines three required AVPs and you receive DIAMETER_MISSING_AVP without Failed-AVP how do you know which one was missing? You need to know the message contents and the command-code definition (including the rules for "conditional" AVPs) if you want to know what AVP was missing. It doesn't matter at all whether the missing AVP is required or optional. BR, Mikko > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext MORAND Lionel RD-CORE-ISS > Sent: 02 November, 2004 18:02 > To: Loughney John (Nokia-NRC/Helsinki); aaa-wg@merit.edu > Subject: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP >=20 >=20 > > From 3588: > >=20 > > DIAMETER_MISSING_AVP 5005 > > The request did not contain an AVP that is required by the > Command > > Code definition. If this value is sent in the=20 > Result-Code AVP, > a > > Failed-AVP AVP SHOULD be included in the message. The > Failed-AVP > > AVP MUST contain an example of the missing AVP=20 > complete with the > > Vendor-Id if applicable. The value field of the missing AVP > > should be of correct minimum length and contain zeroes. > >=20 > > My guess is that if a particular implementation or=20 > > application was expecting an AVP to be included, this would=20 > > be a reasonable way to do it. > >=20 >=20 > Based on this definition, it is only applicable to AVP=20 > "required by the > command code definition". It is not clear if we could reuse the same > result code for an optional AVP. > If there is a general consensus on this topic, maybe a modification to > the existing definition should be done. >=20 > Besides, if we could reuse the same result code for required=20 > or optional > AVP, should we state that "a Failed-AVP AVP MUST be included"=20 > instead of > "should be included"? > My assumption was that a "SHOULD" was possible here because you could > have relyed on the command code ABNF descritpion to find the missing > AVP. If the above assupmtion is correct, it is not possible=20 > anymore and > you have to use the Failed-AVP. >=20 > Lionel >=20 From owner-aaa-wg@merit.edu Thu Nov 4 08:17:24 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17846 for ; Thu, 4 Nov 2004 08:17:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 634769125F; Thu, 4 Nov 2004 08:17:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F5D891261; Thu, 4 Nov 2004 08:17:15 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3995391214 for ; Thu, 4 Nov 2004 08:17:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 245BFB2235; Thu, 4 Nov 2004 08:17:14 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by segue.merit.edu (Postfix) with ESMTP id 62B06B238F for ; Thu, 4 Nov 2004 08:17:13 -0500 (EST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Nov 2004 14:17:11 +0100 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]: Using DIAMETER_MISSING_AVP for optional AVP x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 4 Nov 2004 14:17:07 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026018B33F4@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Thread-Index: AcS+XAG9uru3HxFeR+iNpPqzk9TTHQCj6+bQAAHydMAAWU8p8AAF35yg From: "MORAND Lionel RD-CORE-ISS" To: , X-OriginalArrivalTime: 04 Nov 2004 13:17:11.0294 (UTC) FILETIME=[97D941E0:01C4C270] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Mikko, > > Based on this definition, it is only applicable to AVP > > "required by the command code definition". It is not clear if > > we could reuse the same result code for an optional AVP. >=20 > In my opinion here "command code definition" refers to the=20 > whole definition of the command, not just the ABNF. Some=20 > parts of the definition are often presented in "free" text.=20 > For example, Diameter Application command definition might=20 > state that Pet-Poodle AVP must be present in the message in=20 > case it is Friday the 13th. :) [LM] Maybe but it is not clear in the RFC3588 =20 > > My assumption was that a "SHOULD" was possible here because=20 > you could=20 > > have relyed on the command code ABNF descritpion to find=20 > the missing=20 > > AVP. >=20 > So if the command-code ABNF definition defines three required=20 > AVPs and you receive DIAMETER_MISSING_AVP without Failed-AVP=20 > how do you know which one was missing? You need to know the=20 > message contents and the command-code definition (including=20 > the rules for "conditional" AVPs) if you want to know what=20 > AVP was missing. It doesn't matter at all whether the missing=20 > AVP is required or optional. [LM] Based on the RFC 3588: 6.1.2. Sending a Request When sending a request, originated either locally, or as the result of a forwarding or routing operation, the following procedures MUST be followed: - the Hop-by-Hop Identifier should be set to a locally unique value - The message should be saved in the list of pending requests. Receivig DIAMETER_MISSING_AVP without any Failed_AVP AVP, I'm able to know what AVP is missing just by comparing the pending request with the command code ABNF description. I don't need extra information if this error message is only sent for missing "required" AVP. By the way, this is not a discussion about 'conditional AVPs'. This concept doesn't exist in the base protocol! We should only deal with optional AVPs, whatever the use of these optional AVPs. BR, Lionel From owner-aaa-wg@merit.edu Fri Nov 5 08:54:33 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13305 for ; Fri, 5 Nov 2004 08:54:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4AAA991272; Fri, 5 Nov 2004 08:54:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C2E991273; Fri, 5 Nov 2004 08:54:23 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C179D91272 for ; Fri, 5 Nov 2004 08:54:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id AF2CEB26C1; Fri, 5 Nov 2004 08:54:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id BA448B26B0 for ; Fri, 5 Nov 2004 08:54:20 -0500 (EST) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA5DsJl26593 for ; Fri, 5 Nov 2004 15:54:19 +0200 (EET) X-Scanned: Fri, 5 Nov 2004 15:52:14 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iA5DqEEe027937 for ; Fri, 5 Nov 2004 15:52:14 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 000SdE4Y; Fri, 05 Nov 2004 15:52:13 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA5DpQS28773 for ; Fri, 5 Nov 2004 15:51:26 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 5 Nov 2004 15:51:09 +0200 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 5 Nov 2004 15:51:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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]: Using DIAMETER_MISSING_AVP for optional AVP Date: Fri, 5 Nov 2004 15:51:08 +0200 Message-ID: <78577AECEB6226409F9F4BFB53FE183708F7AA@esebe054.ntc.nokia.com> Thread-Topic: [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Thread-Index: AcS+XAG9uru3HxFeR+iNpPqzk9TTHQCj6+bQAAHydMAAWU8p8AAF35ygADNJ2HA= From: To: X-OriginalArrivalTime: 05 Nov 2004 13:51:08.0200 (UTC) FILETIME=[805A3280:01C4C33E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, > Receivig DIAMETER_MISSING_AVP without any Failed_AVP AVP, I'm able to > know what AVP is missing just by comparing the pending=20 > request with the command code ABNF description. I don't need extra > information if this error message is only sent for missing "required" = AVP. I wonder what kind of implementation you're talking about. Your example assumes that the implementation knows the correct contents of the command (ABNF description etc.) so why would the implementation send a command with missing AVP in the first place? BR, Mikko > -----Original Message----- > From: ext MORAND Lionel RD-CORE-ISS > [mailto:lionel.morand@francetelecom.com] > Sent: 04 November, 2004 15:17 > To: Aittola Mikko (Nokia-NET/Tampere); aaa-wg@merit.edu > Subject: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP >=20 >=20 > Hi Mikko, >=20 > > > Based on this definition, it is only applicable to AVP > > > "required by the command code definition". It is not clear if > > > we could reuse the same result code for an optional AVP. > >=20 > > In my opinion here "command code definition" refers to the=20 > > whole definition of the command, not just the ABNF. Some=20 > > parts of the definition are often presented in "free" text.=20 > > For example, Diameter Application command definition might=20 > > state that Pet-Poodle AVP must be present in the message in=20 > > case it is Friday the 13th. :) >=20 > [LM] Maybe but it is not clear in the RFC3588 > =20 > > > My assumption was that a "SHOULD" was possible here because=20 > > you could=20 > > > have relyed on the command code ABNF descritpion to find=20 > > the missing=20 > > > AVP. > >=20 > > So if the command-code ABNF definition defines three required=20 > > AVPs and you receive DIAMETER_MISSING_AVP without Failed-AVP=20 > > how do you know which one was missing? You need to know the=20 > > message contents and the command-code definition (including=20 > > the rules for "conditional" AVPs) if you want to know what=20 > > AVP was missing. It doesn't matter at all whether the missing=20 > > AVP is required or optional. >=20 > [LM] Based on the RFC 3588: >=20 > 6.1.2. Sending a Request >=20 > When sending a request, originated either locally, or as the result > of a forwarding or routing operation, the following procedures MUST > be followed: >=20 > - the Hop-by-Hop Identifier should be set to a locally=20 > unique value >=20 > - The message should be saved in the list of pending requests. >=20 > Receivig DIAMETER_MISSING_AVP without any Failed_AVP AVP, I'm able to > know what AVP is missing just by comparing the pending=20 > request with the > command code ABNF description. I don't need extra information if this > error message is only sent for missing "required" AVP. >=20 > By the way, this is not a discussion about 'conditional AVPs'. This > concept doesn't exist in the base protocol! We should only deal with > optional AVPs, whatever the use of these optional AVPs. >=20 > BR, >=20 > Lionel >=20 From owner-aaa-wg@merit.edu Wed Nov 10 11:58:42 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00752 for ; Wed, 10 Nov 2004 11:58:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5D61791272; Wed, 10 Nov 2004 11:58:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3575391271; Wed, 10 Nov 2004 11:58:23 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AE45691271 for ; Wed, 10 Nov 2004 11:58:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id E76F958771; Wed, 10 Nov 2004 11:54:58 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by segue.merit.edu (Postfix) with ESMTP id 549B559902 for ; Wed, 10 Nov 2004 11:47:14 -0500 (EST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Nov 2004 17:45:01 +0100 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.5.7226.0 Subject: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Date: Wed, 10 Nov 2004 17:44:59 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0260190331D@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Thread-Index: AcS+XAG9uru3HxFeR+iNpPqzk9TTHQCj6+bQAAHydMAAWU8p8AAF35ygATUAnMA= From: "MORAND Lionel RD-CORE-ISS" To: X-OriginalArrivalTime: 10 Nov 2004 16:45:02.0121 (UTC) FILETIME=[9F84F190:01C4C744] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Any other thought on this thread? The initial question was: "Based on the RFC 3588, is it possible to use the DIAMETER_MISSING_AVP result code along with the Failed-AVP AVP to indicate that an optional AVP (from the ABNF point of view) is missing in the received command? If not, could you identify some operational issues?" BR, Lionel From admin@staffadministrator.com Thu Nov 11 00:17:08 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 AAA15709; Thu, 11 Nov 2004 00:17:08 -0500 (EST) Received: from h000bdbbdd0af.ne.client2.attbi.com ([24.62.178.150]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CS7Lf-0000ZK-4P; Thu, 11 Nov 2004 00:18:20 -0500 Received: from 2iy.m2zt1sv.net (HELO sznl) [52.53.38.151] by h000bdbbdd0af.ne.client2.attbi.com; Thu, 11 Nov 2004 06:14:32 +0100 Message-ID: <4$69yycic3h7@b0ar1r> From: "Administrator" To: aaa-archive@ietf.org Subject: ADV: Staff Announcement Date: Thu, 11 Nov 04 06:14:32 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="A..CEEB28CE20CD9A" X-Spam-Score: 15.3 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d This is a multi-part message in MIME format. --A..CEEB28CE20CD9A Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations: Members and Staff You Must Respond By 5 P.M. Friday, November 12, 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 Nonprofit Members and Staff who respond to this message before 5 P.M., Friday, November 12, 2004 All desktop computers are brand-new packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2005 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktops with the latest technology at an amazing price to all who call: 1-800-795-8466 by 5 P.M. Friday, November 12, 2004 The fast and powerful AT-3200 series Desktop features: * IBM 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 * Next Generation 2005 Technology * Premium video and sound -- For enhanced colors and graphics * 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 $499 ........................................ Your Cost $227 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-795-8466 by 5 P.M. Friday, November 12, 2004. and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. 6. Ask for Department C. Call Avtech Direct 1-800-795-8466 before 5 P.M. Friday, November 12, 2004 Visit our website at http://www.avtechdirect-nonprofits.com If you wish to unsubscribe from this list, please go to http://www.computeradvice.org/unsubscribelink.asp Avtech Direct 22647 Ventura Blvd. Suite 374 Woodland Hills, CA 91364 --A..CEEB28CE20CD9A-- From owner-aaa-wg@merit.edu Thu Nov 11 03:52:56 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14121 for ; Thu, 11 Nov 2004 03:52:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D3EC191211; Thu, 11 Nov 2004 03:52:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9967C912E0; Thu, 11 Nov 2004 03:52:48 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4F23D91211 for ; Thu, 11 Nov 2004 03:52:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id B59D858444; Thu, 11 Nov 2004 03:52:46 -0500 (EST) 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 3F9B65843C for ; Thu, 11 Nov 2004 03:52:41 -0500 (EST) 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 iAB8qd9f004524 for ; Thu, 11 Nov 2004 09:52:39 +0100 (MET) Received: from omimexo06.omnitel.it ([10.21.12.195]) by oming29.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 11 Nov 2004 09:52:38 +0100 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.6603.0 Subject: RE: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Date: Thu, 11 Nov 2004 09:52:37 +0100 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB90823D64C@OMIMEXO06.omnitel.it> Thread-topic: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Thread-index: AcS+XAG9uru3HxFeR+iNpPqzk9TTHQCj6+bQAAHydMAAWU8p8AAF35ygATUAnMAAIRO7UA== From: "STURA Marco Consultant" To: "MORAND Lionel RD-CORE-ISS" Cc: X-OriginalArrivalTime: 11 Nov 2004 08:52:38.0090 (UTC) FILETIME=[CB92CAA0:01C4C7CB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Lionel, I think the conclusion was "yes it is possible", and indeed it is. If a server receives an AVP with M bit set that cannot recognize, although the AVP is optional in the ABNF (i.e. in square brackets), the Failed-AVP AVP is included in the failed answer. Similarly, if the value of the AVP (which has the M bit set) is not recognized the failed answer includes the Failed-AVP AVP. Br Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of MORAND Lionel RD-CORE-ISS Sent: Wednesday, November 10, 2004 5:45 PM To: aaa-wg@merit.edu Subject: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Any other thought on this thread? The initial question was: "Based on the RFC 3588, is it possible to use the DIAMETER_MISSING_AVP result code along with the Failed-AVP AVP to indicate that an optional AVP (from the ABNF point of view) is missing in the received command? If not, could you identify some operational issues?" BR, Lionel From owner-aaa-wg@merit.edu Thu Nov 11 04:01:24 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15114 for ; Thu, 11 Nov 2004 04:01:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 46EDA912E0; Thu, 11 Nov 2004 04:01:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0DFEE912E1; Thu, 11 Nov 2004 04:01:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 974BE912E0 for ; Thu, 11 Nov 2004 04:01:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7F03E58354; Thu, 11 Nov 2004 04:01:15 -0500 (EST) 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 07E3158306 for ; Thu, 11 Nov 2004 04:01:15 -0500 (EST) Received: from omini93.omnitel.it (omini93.omnitel.it [10.21.18.145]) by fmis837.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id iAB91DJM004288 for ; Thu, 11 Nov 2004 10:01:13 +0100 (MET) Received: from omimexo06.omnitel.it ([10.21.12.195]) by ominc74.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 11 Nov 2004 10:01:12 +0100 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.6603.0 Subject: RE: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Date: Thu, 11 Nov 2004 10:01:11 +0100 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB90823D64D@OMIMEXO06.omnitel.it> Thread-topic: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Thread-index: AcS+XAG9uru3HxFeR+iNpPqzk9TTHQCj6+bQAAHydMAAWU8p8AAF35ygATUAnMAAIRO7UAAA5aPw From: "STURA Marco Consultant" To: "MORAND Lionel RD-CORE-ISS" Cc: X-OriginalArrivalTime: 11 Nov 2004 09:01:12.0297 (UTC) FILETIME=[FE108D90:01C4C7CC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Sorry Lionel, I forgot to add the essential part of my answer. Also, if a server doesn't receives an AVP that a particular implementation or application is expecting for the successful processing of the request, although optional in the ABNF but e.g. defined to present under certain conditions, the failed answer includes the Failed-AVP AVP. Br Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of STURA Marco Consultant Sent: Thursday, November 11, 2004 9:53 AM To: MORAND Lionel RD-CORE-ISS Cc: aaa-wg@merit.edu Subject: RE: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Lionel, I think the conclusion was "yes it is possible", and indeed it is. If a server receives an AVP with M bit set that cannot recognize, although the AVP is optional in the ABNF (i.e. in square brackets), the Failed-AVP AVP is included in the failed answer. Similarly, if the value of the AVP (which has the M bit set) is not recognized the failed answer includes the Failed-AVP AVP. Br Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of MORAND Lionel RD-CORE-ISS Sent: Wednesday, November 10, 2004 5:45 PM To: aaa-wg@merit.edu Subject: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Any other thought on this thread? The initial question was: "Based on the RFC 3588, is it possible to use the DIAMETER_MISSING_AVP result code along with the Failed-AVP AVP to indicate that an optional AVP (from the ABNF point of view) is missing in the received command? If not, could you identify some operational issues?" BR, Lionel From owner-aaa-wg@merit.edu Thu Nov 11 07:36:32 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03599 for ; Thu, 11 Nov 2004 07:36:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E025C912E2; Thu, 11 Nov 2004 07:36:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B35AE912E3; Thu, 11 Nov 2004 07:36:26 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 68F87912E2 for ; Thu, 11 Nov 2004 07:36:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 540A058551; Thu, 11 Nov 2004 07:36:25 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by segue.merit.edu (Postfix) with ESMTP id 251DC58547 for ; Thu, 11 Nov 2004 07:36:25 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CSEBb-0004vM-LJ; Thu, 11 Nov 2004 07:36:23 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iABCaLi04618; Thu, 11 Nov 2004 04:36:21 -0800 Date: Thu, 11 Nov 2004 04:36:21 -0800 (PST) From: Bernard Aboba To: STURA Marco Consultant Cc: MORAND Lionel RD-CORE-ISS , aaa-wg@merit.edu Subject: RE: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP In-Reply-To: <95A9A19987C57D42AA1CF59368CD1CB90823D64C@OMIMEXO06.omnitel.it> Message-ID: References: <95A9A19987C57D42AA1CF59368CD1CB90823D64C@OMIMEXO06.omnitel.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Sender: owner-aaa-wg@merit.edu Precedence: bulk RFC 3588 Section 7 says: " - A command is received with an AVP that is omitted, yet is mandatory according to the command's ABNF. The receiver issues an answer with the Result-Code set to DIAMETER_MISSING_AVP, and creates an AVP with the AVP Code and other fields set as expected in the missing AVP. The created AVP is then added to the Failed- AVP AVP." In Section 7.11 it says: "A non-successful Result-Code AVP (one containing a non 2xxx value other than DIAMETER_REDIRECT_INDICATION) MUST include the Error-Reporting-Host AVP if the host setting the Result-Code AVP is different from the identity encoded in the Origin-Host AVP. The Result-Code data field contains an IANA-managed 32-bit address space representing errors (see Section 11.4). Diameter provides the following classes of errors, all identified by the thousands digit in the decimal notation: - 1xxx (Informational) - 2xxx (Success) - 3xxx (Protocol Errors) - 4xxx (Transient Failures) - 5xxx (Permanent Failure)" DIAMETER_MISSING_AVP uses Result-Code value 5005, which is the Permanent Failure category, a terminal error. Section 7.1.5 says: " Errors that fall within the permanent failures category are used to inform the peer that the request failed, and should not be attempted again." Given the above, it would appear to me that the DIAMETER_MISSING_AVP Result_Code cannot be returned in response to lack of inclusion of an AVP without the Mandatory bit set. Having said that, it is possible that some other AVP that *is* mandatory may take on a value that implies the need for another optional AVP, which is missing. That would be a terminal error, but a Result_Code other than DIAMETER_MISSING_AVP should be used to indicate that. On Thu, 11 Nov 2004, STURA Marco Consultant wrote: > Lionel, > > I think the conclusion was "yes it is possible", and indeed it is. > > If a server receives an AVP with M bit set that cannot recognize, > although the AVP is optional in the ABNF (i.e. in square brackets), the > Failed-AVP AVP is included in the failed answer. > > Similarly, if the value of the AVP (which has the M bit set) is not > recognized the failed answer includes the Failed-AVP AVP. > > Br > Marco > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf > Of MORAND Lionel RD-CORE-ISS > Sent: Wednesday, November 10, 2004 5:45 PM > To: aaa-wg@merit.edu > Subject: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP > > Any other thought on this thread? > The initial question was: > > "Based on the RFC 3588, is it possible to use the DIAMETER_MISSING_AVP > result code along with the Failed-AVP AVP to indicate that an optional > AVP (from the ABNF point of view) is missing in the received command? If > not, could you identify some operational issues?" > > BR, > > Lionel > From owner-aaa-wg@merit.edu Thu Nov 11 07:42:58 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04369 for ; Thu, 11 Nov 2004 07:42:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5DE0A912E3; Thu, 11 Nov 2004 07:42:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29006912E8; Thu, 11 Nov 2004 07:42:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 93CD6912E3 for ; Thu, 11 Nov 2004 07:42:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7F8E95851C; Thu, 11 Nov 2004 07:42:49 -0500 (EST) 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 D551058555 for ; Thu, 11 Nov 2004 07:42:48 -0500 (EST) 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 iABCglJM011175 for ; Thu, 11 Nov 2004 13:42:47 +0100 (MET) Received: from omimexo06.omnitel.it ([10.21.12.195]) by ominc74.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 11 Nov 2004 13:42:45 +0100 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.6603.0 Subject: RE: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Date: Thu, 11 Nov 2004 13:42:45 +0100 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB906F2CE44@OMIMEXO06.omnitel.it> Thread-topic: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Thread-index: AcTH6xALY4bPQ8LkQsSlNUX4668p3AAAIrkA From: "STURA Marco Consultant" To: "Bernard Aboba" Cc: "MORAND Lionel RD-CORE-ISS" , X-OriginalArrivalTime: 11 Nov 2004 12:42:45.0734 (UTC) FILETIME=[F1921060:01C4C7EB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Bernard, I was thinking to similar case as you mentioned. But what value other than DIAMETER_MISSING_AVP should be used in this case? I don't see any other value available at the moment, that's why the DIAMETER_MISSING_AVP seems the most appropriate. Marco -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com]=20 Sent: Thursday, November 11, 2004 1:36 PM To: STURA Marco Consultant Cc: MORAND Lionel RD-CORE-ISS; aaa-wg@merit.edu Subject: RE: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP RFC 3588 Section 7 says: " - A command is received with an AVP that is omitted, yet is mandatory according to the command's ABNF. The receiver issues an answer with the Result-Code set to DIAMETER_MISSING_AVP, and creates an AVP with the AVP Code and other fields set as expected in the missing AVP. The created AVP is then added to the Failed- AVP AVP." In Section 7.11 it says: "A non-successful Result-Code AVP (one containing a non 2xxx value other than DIAMETER_REDIRECT_INDICATION) MUST include the Error-Reporting-Host AVP if the host setting the Result-Code AVP is different from the identity encoded in the Origin-Host AVP. The Result-Code data field contains an IANA-managed 32-bit address space representing errors (see Section 11.4). Diameter provides the following classes of errors, all identified by the thousands digit in the decimal notation: - 1xxx (Informational) - 2xxx (Success) - 3xxx (Protocol Errors) - 4xxx (Transient Failures) - 5xxx (Permanent Failure)" DIAMETER_MISSING_AVP uses Result-Code value 5005, which is the Permanent Failure category, a terminal error. Section 7.1.5 says: " Errors that fall within the permanent failures category are used to inform the peer that the request failed, and should not be attempted again." Given the above, it would appear to me that the DIAMETER_MISSING_AVP Result_Code cannot be returned in response to lack of inclusion of an AVP without the Mandatory bit set. Having said that, it is possible that some other AVP that *is* mandatory may take on a value that implies the need for another optional AVP, which is missing. That would be a terminal error, but a Result_Code other than DIAMETER_MISSING_AVP should be used to indicate that. On Thu, 11 Nov 2004, STURA Marco Consultant wrote: > Lionel, > > I think the conclusion was "yes it is possible", and indeed it is. > > If a server receives an AVP with M bit set that cannot recognize, > although the AVP is optional in the ABNF (i.e. in square brackets), the > Failed-AVP AVP is included in the failed answer. > > Similarly, if the value of the AVP (which has the M bit set) is not > recognized the failed answer includes the Failed-AVP AVP. > > Br > Marco > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf > Of MORAND Lionel RD-CORE-ISS > Sent: Wednesday, November 10, 2004 5:45 PM > To: aaa-wg@merit.edu > Subject: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP > > Any other thought on this thread? > The initial question was: > > "Based on the RFC 3588, is it possible to use the DIAMETER_MISSING_AVP > result code along with the Failed-AVP AVP to indicate that an optional > AVP (from the ABNF point of view) is missing in the received command? If > not, could you identify some operational issues?" > > BR, > > Lionel > From owner-aaa-wg@merit.edu Thu Nov 11 07:55:39 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05368 for ; Thu, 11 Nov 2004 07:55:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 710FD912E8; Thu, 11 Nov 2004 07:55:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 403ED912EB; Thu, 11 Nov 2004 07:55:32 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3EE90912E8 for ; Thu, 11 Nov 2004 07:55:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1DD0B5856B; Thu, 11 Nov 2004 07:55:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by segue.merit.edu (Postfix) with ESMTP id E30345856A for ; Thu, 11 Nov 2004 07:55:30 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CSEU6-000ETy-Bs; Thu, 11 Nov 2004 07:55:30 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iABCtSE06073; Thu, 11 Nov 2004 04:55:29 -0800 Date: Thu, 11 Nov 2004 04:55:28 -0800 (PST) From: Bernard Aboba To: STURA Marco Consultant Cc: MORAND Lionel RD-CORE-ISS , aaa-wg@merit.edu Subject: RE: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP In-Reply-To: <95A9A19987C57D42AA1CF59368CD1CB906F2CE44@OMIMEXO06.omnitel.it> Message-ID: References: <95A9A19987C57D42AA1CF59368CD1CB906F2CE44@OMIMEXO06.omnitel.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Sender: owner-aaa-wg@merit.edu Precedence: bulk > I was thinking to similar case as you mentioned. But what value other > than DIAMETER_MISSING_AVP should be used in this case? > > I don't see any other value available at the moment, that's why the > DIAMETER_MISSING_AVP seems the most appropriate. Looking through the error messages, it isn't clear that any of the current ones fit this circumstance. Essentially, you would be saying that the semantics of the request are invalid. So a new error message is probably needed. > Having said that, it is possible that some other AVP that *is* mandatory > may take on a value that implies the need for another optional AVP, > which is missing. That would be a terminal error, but a Result_Code > other than DIAMETER_MISSING_AVP should be used to indicate that. From owner-aaa-wg@merit.edu Thu Nov 11 08:11:50 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07178 for ; Thu, 11 Nov 2004 08:11:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E35A2912EB; Thu, 11 Nov 2004 08:11:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B477C912EE; Thu, 11 Nov 2004 08:11:39 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E6815912EB for ; Thu, 11 Nov 2004 08:11:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id B9AEB58557; Thu, 11 Nov 2004 08:11:37 -0500 (EST) 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 ECB0D5854E for ; Thu, 11 Nov 2004 08:11:36 -0500 (EST) 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 iABDBZJM021686 for ; Thu, 11 Nov 2004 14:11:35 +0100 (MET) Received: from omimexo06.omnitel.it ([10.21.12.195]) by oming29.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 11 Nov 2004 14:11:33 +0100 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.6603.0 Subject: RE: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Date: Thu, 11 Nov 2004 14:11:32 +0100 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB906F2CE45@OMIMEXO06.omnitel.it> Thread-topic: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Thread-index: AcTH7b0lW3styzvmTr6f4mwsXNLlrQAAgaIA From: "STURA Marco Consultant" To: "Bernard Aboba" Cc: "MORAND Lionel RD-CORE-ISS" , X-OriginalArrivalTime: 11 Nov 2004 13:11:33.0319 (UTC) FILETIME=[F74A9D70:01C4C7EF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I may agree on what you say, but after all it is always a missing AVP what we are talking about. So, what suit best of an error of which semantic is "missing AVP"? Marco -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com]=20 Sent: Thursday, November 11, 2004 1:55 PM To: STURA Marco Consultant Cc: MORAND Lionel RD-CORE-ISS; aaa-wg@merit.edu Subject: RE: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP > I was thinking to similar case as you mentioned. But what value other > than DIAMETER_MISSING_AVP should be used in this case? > > I don't see any other value available at the moment, that's why the > DIAMETER_MISSING_AVP seems the most appropriate. Looking through the error messages, it isn't clear that any of the current ones fit this circumstance. Essentially, you would be saying that the semantics of the request are invalid. So a new error message is probably needed. > Having said that, it is possible that some other AVP that *is* mandatory > may take on a value that implies the need for another optional AVP, > which is missing. That would be a terminal error, but a Result_Code > other than DIAMETER_MISSING_AVP should be used to indicate that. From owner-aaa-wg@merit.edu Thu Nov 11 09:16:19 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13199 for ; Thu, 11 Nov 2004 09:16:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8D171912F0; Thu, 11 Nov 2004 09:16:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 521FA912F1; Thu, 11 Nov 2004 09:16:13 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ACA57912F0 for ; Thu, 11 Nov 2004 09:16:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id BED1F5854E; Thu, 11 Nov 2004 09:16:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 06BBF584AD for ; Thu, 11 Nov 2004 09:16:03 -0500 (EST) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABEFtF04921; Thu, 11 Nov 2004 16:15:56 +0200 (EET) X-Scanned: Thu, 11 Nov 2004 16:11:57 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iABEBv7S024888; Thu, 11 Nov 2004 16:11:57 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00HM6HZv; Thu, 11 Nov 2004 16:10:14 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABDtda11873; Thu, 11 Nov 2004 15:55:39 +0200 (EET) Received: from [10.162.14.168] ([10.162.14.168]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 11 Nov 2004 15:55:26 +0200 Message-ID: <41936F4C.5080201@nokia.com> Date: Thu, 11 Nov 2004 15:55:24 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: "Beck01, Wolfgang" , Mari Carmen belinchon , Miguel-Angel Pallares , "ext Carolina Canales (ML/EEM)" , Pete McCann , Rajaniemi Jaakko Matti , Tammi Kalle Tapani Cc: AAA mailing list , radiusext@ops.ietf.org Subject: [AAA-WG]: Reconciling Radius/Diameter SIP application Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2004 13:55:26.0314 (UTC) FILETIME=[18ADC4A0:01C4C7F6] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi: I am deliberately cross posting to AAA and Radius-ext because I believe this topic is of interest for both lists. Yesterday Wolfgang and me met for a few hours and set the goal of reconcile the Diameter SIP application and the RADIUS HTTP/SIP Digest drafts. These are the drafts: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-04.txt http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt These are the main points we discuss. If you have any comments, speak up now, otherwise we will do the proposed changes in the relevant drafts: 1- We agreed to modify the Diameter SIP application so that it imports the Digest-* AVP from the corresponding RADIUS attributes address space. This came out of a comment from Jari Arkko, and I think it is important to avoid duplication of AVP/attributes. As a side effect of the above, the SIP-Authentication-Context will disappear in Diameter SIP app. This was a grouped AVP that only contained a Digest-Entity-Body-Hash AVP. The latter will remain (in the RADIUS draft). 2- We noticed a divergence in the Digest-Expected-Response AVP in Diameter, which does not exist in RADIUS. RADIUS defines a Digest-HA1 attribute. The difference: Digest-HA1 contains H(A1), which is computed at the Radius server and sent to the Radius client, and it is used to compute the expected response. In Diameter, the expected response is computed at the Diameter server and sent to the client. This assumes a secure connection to avoid eavesdropping, which is not a problem for Diameter that mandates IPsec or TLS. I think Diameter can go for the Radius approach for compatibility reasons. Proposal: Diameter will remove Digest-Expected-Response AVP and will import Digest-HA1 from Radius. 3- Radius does not define UTF8String data types, so all these attributes will remain as String, but the Radius draft will indicate that contain a UTF8String verbally (this is required by HTTP and SIP). 4- Currently here is a divergence on the definition of Digest-Stale attribute: Diameter uses "true" and "false" (as per RFC2617), Radius uses 1 and 0. We agreed to use "true" and "false" to avoid stupid transcodings. 5- Diameter indicates that the Digest-* AVPs contain the quotes from/to the Digest directive, Radius assumes (although does not indicate) no quotes. We agreed that the Digest-* attributes do not need to include the quotes from HTTP Digest parameters. So, there will be an explicit indication that quotes are not part of the attribute value. 6- We run into a problem when multiple SIP proxies are authenticating the user, because at some point in time the SIP request may contain several Proxy-Authorization headers. The key here is the realm, it will be always different. If different Diameter/Radius servers are serving different realms, there is not problem. But, if a common Diameter/Radius server is serving different realms, then the server is not able to determine which credentials should be evaluated. We propose that the Diameter/Radius client MUST send only one set of credentials at a time, those belonging to the served realm. This requires to configure the Diameter/Radius client with the realm it is serving. We will include some text indicating this case. 7- Some of the attributes (e.g, Digest-Response and Digest-Response-Auth) had an artificial limit of 32 octets in the value. While this value is correct for MD5 hashes, if in the future other hashes are added to HTTP Digest, will run into trouble. Proposal: don't restrict the length of a value. 8- In the Radius document, scenario 1, we have a question. We suspect that this scenario does not work if the Radius client generates a nextnonce. The reason is that in the following authentication, when the nextnonce becomes a nonce, the Radius server will not recognize the nonce as locally generated (it was generated by the Radius client), and will reject the request with a "state=true". RFC 2617 seems to describe the case: If the nextnonce field is present the client SHOULD use it when constructing the Authorization header for its next request. Failure of the client to do so may result in a request to re-authenticate from the server with the "stale=TRUE". Does anyone have any comment? Can anyone confirm that the operation in Digest is as we indicate? We will add some text indicating the limitations of Scenario 1. 9- The Radius draft, in section 2.15, indicates: RADIUS servers that do not implement a parameter contained in a Digest-Auth-Param attribute MUST respond with an Access-Reject message. RADIUS clients that do not implement a parameter contained in a Digest-Auth-Param attribute MUST reject the original HTTP-style request. The problem is that the text seems to go against RFC 2617 that says: auth-param This directive allows for future extensions. Any unrecognized directive MUST be ignored. The proposal is to remove the above text from the RADIUS draft. 10- Similar contradictory text was found in Section 2.16 of the RADIUS draft, that says: RADIUS servers that do not implement AKA Digest MUST response with an Access Reject message. We propose to remove the above text. The motivation is that the algorithm already conveys the AKA (AKA extends the algorithm to be AKAv1-MD5 and AKAv1-MD5-sess). The server chooses the algorithm, so the situation currently described, where the client may include an auts attribute, is just an error case, where the client made a mistake and included AUTS when not doing AKA. In case the Radius server does not implement AKA authentication, it will safely ignore this AVP. 11- We noticed that most of the HTTP Digest directives contain just a single token. However, the "qop" directive may contain a comma-separated collection of tokens. For instance, qop="auth,auth-int". The question is how do encode these tokens in the Digest-Qop attribute. The options are: a) Treat the whole thing as one token and put it into the attribute value. b) Each token is an attribute, thus, there might be multiple Digest-Qop attributes in a particular Radius/Diameter message. We think that option b) is cleaner. Particularly it will be easier for the Diameter/Radius client to encode different values in different attributes. Any comments to any of the above? Regards, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Thu Nov 11 12:59:56 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07835 for ; Thu, 11 Nov 2004 12:59:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 90F1F91301; Thu, 11 Nov 2004 12:59:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 57D7D91302; Thu, 11 Nov 2004 12:59:50 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C0D1F91301 for ; Thu, 11 Nov 2004 12:59:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id A6FFA5857C; Thu, 11 Nov 2004 12:59:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by segue.merit.edu (Postfix) with ESMTP id 92F6458592 for ; Thu, 11 Nov 2004 12:59:42 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Nov 2004 12:59:41 -0500 Message-ID: From: Avi Lior To: "'Miguel Garcia'" , "Beck01, Wolfgang" , Mari Carmen belinchon , Miguel-Angel Pallares , "ext Carolina Canales (ML/EEM)" , Pete McCann , Rajaniemi Jaakko Matti , Tammi Kalle Tapani Cc: AAA mailing list , radiusext@ops.ietf.org Subject: RE: [AAA-WG]: Reconciling Radius/Diameter SIP application Date: Thu, 11 Nov 2004 12:59:31 -0500 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, Wrt to UTF8String in diameter and lack of support in RADIUS. Well would the RADIUS type TEXT work for you? Text is defined in 2865 as "Text contains UTF-8 encoded 10646 [7] characters" > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: Thursday, November 11, 2004 8:55 AM > To: Beck01, Wolfgang; Mari Carmen belinchon; Miguel-Angel > Pallares; ext Carolina Canales (ML/EEM); Pete McCann; > Rajaniemi Jaakko Matti; Tammi Kalle Tapani > Cc: AAA mailing list; radiusext@ops.ietf.org > Subject: [AAA-WG]: Reconciling Radius/Diameter SIP application > > > Hi: > > I am deliberately cross posting to AAA and Radius-ext because > I believe > this topic is of interest for both lists. > > Yesterday Wolfgang and me met for a few hours and set the goal of > reconcile the Diameter SIP application and the RADIUS HTTP/SIP Digest > drafts. These are the drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-si > p-app-04.txt > > http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt > > These are the main points we discuss. If you have any > comments, speak up > now, otherwise we will do the proposed changes in the relevant drafts: > > 1- We agreed to modify the Diameter SIP application so that > it imports > the Digest-* AVP from the corresponding RADIUS attributes > address space. This came out of a comment from Jari Arkko, > and I think it is important > to avoid duplication of AVP/attributes. > > As a side effect of the above, the SIP-Authentication-Context will > disappear in Diameter SIP app. This was a grouped AVP that only > contained a Digest-Entity-Body-Hash AVP. The latter will > remain (in the > RADIUS draft). > > 2- We noticed a divergence in the Digest-Expected-Response AVP in > Diameter, which does not exist in RADIUS. RADIUS defines a Digest-HA1 > attribute. The difference: Digest-HA1 contains H(A1), which > is computed > at the Radius server and sent to the Radius client, and it is used to > compute the expected response. In Diameter, the expected response is > computed at the Diameter server and sent to the client. This > assumes a > secure connection to avoid eavesdropping, which is not a problem for > Diameter that mandates IPsec or TLS. I think Diameter can go for the > Radius approach for compatibility reasons. > > Proposal: Diameter will remove Digest-Expected-Response AVP and will > import Digest-HA1 from Radius. > > 3- Radius does not define UTF8String data types, so all these > attributes > will remain as String, but the Radius draft will indicate > that contain a UTF8String verbally (this is required by HTTP and SIP). > > 4- Currently here is a divergence on the definition of Digest-Stale > attribute: Diameter uses "true" and "false" (as per RFC2617), Radius > uses 1 and 0. We agreed to use "true" and "false" to avoid stupid > transcodings. > > 5- Diameter indicates that the Digest-* AVPs contain the > quotes from/to > the Digest directive, Radius assumes (although does not indicate) no > quotes. We agreed that the Digest-* attributes do not need to include > the quotes from HTTP Digest parameters. So, there will be an explicit > indication that quotes are not part of the attribute value. > > 6- We run into a problem when multiple SIP proxies are > authenticating the user, because at some point in time the > SIP request may contain several Proxy-Authorization headers. > The key here is the realm, it will be always different. If > different Diameter/Radius servers are > serving different realms, there is not problem. But, if a common > Diameter/Radius server is serving different realms, then the > server is > not able to determine which credentials should be evaluated. > > We propose that the Diameter/Radius client MUST send only one set of > credentials at a time, those belonging to the served realm. This > requires to configure the Diameter/Radius client with the realm it is > serving. We will include some text indicating this case. > > 7- Some of the attributes (e.g, Digest-Response and > Digest-Response-Auth) had an artificial limit of 32 octets in > the value. While this value is correct for MD5 hashes, if in > the future other hashes are added to HTTP Digest, will run > into trouble. Proposal: don't restrict the length of a value. > > 8- In the Radius document, scenario 1, we have a question. We > suspect that this scenario does not work if the Radius client > generates a nextnonce. The reason is that in the following > authentication, when the nextnonce becomes a nonce, the > Radius server will not recognize the nonce as locally > generated (it was generated by the Radius client), and > will reject the request with a "state=true". RFC 2617 seems > to describe > the case: > > If the > nextnonce field is present the client SHOULD use it when > constructing > the Authorization header for its next request. Failure of > the client > to do so may result in a request to re-authenticate from > the server > with the "stale=TRUE". > > Does anyone have any comment? Can anyone confirm that the > operation in > Digest is as we indicate? We will add some text indicating the > limitations of Scenario 1. > > 9- The Radius draft, in section 2.15, indicates: > > RADIUS > servers that do not implement a parameter contained in a > Digest-Auth-Param attribute MUST respond with an > Access-Reject > message. RADIUS clients that do not implement a parameter > contained in a Digest-Auth-Param attribute MUST reject the > original HTTP-style request. > > The problem is that the text seems to go against RFC 2617 that says: > > auth-param > This directive allows for future extensions. Any unrecognized > directive MUST be ignored. > > The proposal is to remove the above text from the RADIUS draft. > > > 10- Similar contradictory text was found in Section 2.16 of > the RADIUS > draft, that says: > > RADIUS servers that do > not implement AKA Digest MUST response with an Access Reject > message. > > We propose to remove the above text. The motivation is that the > algorithm already conveys the AKA (AKA extends the algorithm to be > AKAv1-MD5 and AKAv1-MD5-sess). The server chooses the > algorithm, so the > situation currently described, where the client may include an auts > attribute, is just an error case, where the client made a mistake and > included AUTS when not doing AKA. In case the Radius server does not > implement AKA authentication, it will safely ignore this AVP. > > 11- We noticed that most of the HTTP Digest directives contain just a > single token. However, the "qop" directive may contain a > comma-separated > collection of tokens. For instance, qop="auth,auth-int". The > question is > how do encode these tokens in the Digest-Qop attribute. The > options are: > > a) Treat the whole thing as one token and put it into the > attribute value. > b) Each token is an attribute, thus, there might be multiple > Digest-Qop > attributes in a particular Radius/Diameter message. > > We think that option b) is cleaner. Particularly it will be > easier for > the Diameter/Radius client to encode different values in different > attributes. > > Any comments to any of the above? > > Regards, > > Miguel > > > > > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Research Center Helsinki, Finland > From owner-aaa-wg@merit.edu Thu Nov 11 16:08:10 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28229 for ; Thu, 11 Nov 2004 16:08:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2477E91311; Thu, 11 Nov 2004 16:08:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E18AF91313; Thu, 11 Nov 2004 16:08:03 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C67B91311 for ; Thu, 11 Nov 2004 16:08:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 439AB585B4; Thu, 11 Nov 2004 16:08:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 636AB585B1 for ; Thu, 11 Nov 2004 16:08:01 -0500 (EST) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABL7fF21309; Thu, 11 Nov 2004 23:07:42 +0200 (EET) X-Scanned: Thu, 11 Nov 2004 23:05:19 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iABL5JmW008019; Thu, 11 Nov 2004 23:05:19 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Ibx183; Thu, 11 Nov 2004 23:05:16 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABL5Ga10087; Thu, 11 Nov 2004 23:05:16 +0200 (EET) Received: from [10.162.14.168] ([10.162.14.168]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 11 Nov 2004 23:05:11 +0200 Message-ID: <4193D404.7020505@nokia.com> Date: Thu, 11 Nov 2004 23:05:08 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Avi Lior Cc: "Beck01, Wolfgang" , Mari Carmen belinchon , Miguel-Angel Pallares , "ext Carolina Canales (ML/EEM)" , Pete McCann , Rajaniemi Jaakko Matti , Tammi Kalle Tapani , AAA mailing list , radiusext@ops.ietf.org Subject: Re: [AAA-WG]: Reconciling Radius/Diameter SIP application References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2004 21:05:12.0036 (UTC) FILETIME=[222AB240:01C4C832] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Absolutely right. Wolfgang, will you please change the type of the Digest-* attributes to "text" ? - Miguel Avi Lior wrote: > Hi, > > Wrt to UTF8String in diameter and lack of support in RADIUS. Well would the > RADIUS type TEXT work for you? > > Text is defined in 2865 as "Text contains UTF-8 encoded 10646 > [7] characters" > > >>-----Original Message----- >>From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] >>Sent: Thursday, November 11, 2004 8:55 AM >>To: Beck01, Wolfgang; Mari Carmen belinchon; Miguel-Angel >>Pallares; ext Carolina Canales (ML/EEM); Pete McCann; >>Rajaniemi Jaakko Matti; Tammi Kalle Tapani >>Cc: AAA mailing list; radiusext@ops.ietf.org >>Subject: [AAA-WG]: Reconciling Radius/Diameter SIP application >> >> >>Hi: >> >>I am deliberately cross posting to AAA and Radius-ext because >>I believe >>this topic is of interest for both lists. >> >>Yesterday Wolfgang and me met for a few hours and set the goal of >>reconcile the Diameter SIP application and the RADIUS HTTP/SIP Digest >>drafts. These are the drafts: >> >>http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-si >>p-app-04.txt >> >>http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt >> >>These are the main points we discuss. If you have any >>comments, speak up >>now, otherwise we will do the proposed changes in the relevant drafts: >> >>1- We agreed to modify the Diameter SIP application so that >>it imports >>the Digest-* AVP from the corresponding RADIUS attributes >>address space. This came out of a comment from Jari Arkko, >>and I think it is important >>to avoid duplication of AVP/attributes. >> >>As a side effect of the above, the SIP-Authentication-Context will >>disappear in Diameter SIP app. This was a grouped AVP that only >>contained a Digest-Entity-Body-Hash AVP. The latter will >>remain (in the >>RADIUS draft). >> >>2- We noticed a divergence in the Digest-Expected-Response AVP in >>Diameter, which does not exist in RADIUS. RADIUS defines a Digest-HA1 >>attribute. The difference: Digest-HA1 contains H(A1), which >>is computed >>at the Radius server and sent to the Radius client, and it is used to >>compute the expected response. In Diameter, the expected response is >>computed at the Diameter server and sent to the client. This >>assumes a >>secure connection to avoid eavesdropping, which is not a problem for >>Diameter that mandates IPsec or TLS. I think Diameter can go for the >>Radius approach for compatibility reasons. >> >>Proposal: Diameter will remove Digest-Expected-Response AVP and will >>import Digest-HA1 from Radius. >> >>3- Radius does not define UTF8String data types, so all these >>attributes >>will remain as String, but the Radius draft will indicate >>that contain a UTF8String verbally (this is required by HTTP and SIP). >> >>4- Currently here is a divergence on the definition of Digest-Stale >>attribute: Diameter uses "true" and "false" (as per RFC2617), Radius >>uses 1 and 0. We agreed to use "true" and "false" to avoid stupid >>transcodings. >> >>5- Diameter indicates that the Digest-* AVPs contain the >>quotes from/to >>the Digest directive, Radius assumes (although does not indicate) no >>quotes. We agreed that the Digest-* attributes do not need to include >>the quotes from HTTP Digest parameters. So, there will be an explicit >>indication that quotes are not part of the attribute value. >> >>6- We run into a problem when multiple SIP proxies are >>authenticating the user, because at some point in time the >>SIP request may contain several Proxy-Authorization headers. >>The key here is the realm, it will be always different. If >>different Diameter/Radius servers are >>serving different realms, there is not problem. But, if a common >>Diameter/Radius server is serving different realms, then the >>server is >>not able to determine which credentials should be evaluated. >> >>We propose that the Diameter/Radius client MUST send only one set of >>credentials at a time, those belonging to the served realm. This >>requires to configure the Diameter/Radius client with the realm it is >>serving. We will include some text indicating this case. >> >>7- Some of the attributes (e.g, Digest-Response and >>Digest-Response-Auth) had an artificial limit of 32 octets in >>the value. While this value is correct for MD5 hashes, if in >>the future other hashes are added to HTTP Digest, will run >>into trouble. Proposal: don't restrict the length of a value. >> >>8- In the Radius document, scenario 1, we have a question. We >>suspect that this scenario does not work if the Radius client >>generates a nextnonce. The reason is that in the following >>authentication, when the nextnonce becomes a nonce, the >>Radius server will not recognize the nonce as locally >>generated (it was generated by the Radius client), and >>will reject the request with a "state=true". RFC 2617 seems >>to describe >>the case: >> >> If the >> nextnonce field is present the client SHOULD use it when >>constructing >> the Authorization header for its next request. Failure of >>the client >> to do so may result in a request to re-authenticate from >>the server >> with the "stale=TRUE". >> >>Does anyone have any comment? Can anyone confirm that the >>operation in >>Digest is as we indicate? We will add some text indicating the >>limitations of Scenario 1. >> >>9- The Radius draft, in section 2.15, indicates: >> >> RADIUS >> servers that do not implement a parameter contained in a >> Digest-Auth-Param attribute MUST respond with an >>Access-Reject >> message. RADIUS clients that do not implement a parameter >> contained in a Digest-Auth-Param attribute MUST reject the >> original HTTP-style request. >> >>The problem is that the text seems to go against RFC 2617 that says: >> >> auth-param >> This directive allows for future extensions. Any unrecognized >> directive MUST be ignored. >> >>The proposal is to remove the above text from the RADIUS draft. >> >> >>10- Similar contradictory text was found in Section 2.16 of >>the RADIUS >>draft, that says: >> >> RADIUS servers that do >> not implement AKA Digest MUST response with an Access Reject >> message. >> >>We propose to remove the above text. The motivation is that the >>algorithm already conveys the AKA (AKA extends the algorithm to be >>AKAv1-MD5 and AKAv1-MD5-sess). The server chooses the >>algorithm, so the >>situation currently described, where the client may include an auts >>attribute, is just an error case, where the client made a mistake and >>included AUTS when not doing AKA. In case the Radius server does not >>implement AKA authentication, it will safely ignore this AVP. >> >>11- We noticed that most of the HTTP Digest directives contain just a >>single token. However, the "qop" directive may contain a >>comma-separated >>collection of tokens. For instance, qop="auth,auth-int". The >>question is >>how do encode these tokens in the Digest-Qop attribute. The >>options are: >> >>a) Treat the whole thing as one token and put it into the >>attribute value. >>b) Each token is an attribute, thus, there might be multiple >>Digest-Qop >>attributes in a particular Radius/Diameter message. >> >>We think that option b) is cleaner. Particularly it will be >>easier for >>the Diameter/Radius client to encode different values in different >>attributes. >> >>Any comments to any of the above? >> >>Regards, >> >> Miguel >> >> >> >> >>-- >>Miguel A. Garcia tel:+358-50-4804586 >>Nokia Research Center Helsinki, Finland >> -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Sun Nov 14 07:39:48 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05468 for ; Sun, 14 Nov 2004 07:39:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DC64191201; Sun, 14 Nov 2004 07:39:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B00CE91208; Sun, 14 Nov 2004 07:39:39 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5F1E791201 for ; Sun, 14 Nov 2004 07:39:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4BC0C588E7; Sun, 14 Nov 2004 07:39:38 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 3B341588A0 for ; Sun, 14 Nov 2004 07:39:37 -0500 (EST) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAECdZW16401 for ; Sun, 14 Nov 2004 14:39:35 +0200 (EET) X-Scanned: Sun, 14 Nov 2004 14:36:59 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iAECaxja020782 for ; Sun, 14 Nov 2004 14:36:59 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00VnWzr9; Sun, 14 Nov 2004 14:36:59 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAECara06929 for ; Sun, 14 Nov 2004 14:36:53 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 14 Nov 2004 14:36:53 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 14 Nov 2004 14:36:53 +0200 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 14 Nov 2004 14:36:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Date: Sun, 14 Nov 2004 14:36:52 +0200 Message-ID: <78577AECEB6226409F9F4BFB53FE183708F7B3@esebe054.ntc.nokia.com> Thread-Topic: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP Thread-Index: AcTH7b0lW3styzvmTr6f4mwsXNLlrQAAgaIAAJV0TwA= From: To: X-OriginalArrivalTime: 14 Nov 2004 12:36:53.0238 (UTC) FILETIME=[9EB4B160:01C4CA46] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, I think DIAMETER_MISSING_AVP can be used to indicate whatever missing AVP. The actual definition of the error-code in RFC 3588 does not limit the usage to mandatory AVPs only. What is described in Section 7.11 (which is not the definition of the error-code) is just one example how the error-code can be used. BR, Mikko > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext STURA Marco Consultant > Sent: 11 November, 2004 15:12 > To: Bernard Aboba > Cc: MORAND Lionel RD-CORE-ISS; aaa-wg@merit.edu > Subject: RE: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for=20 > optional AVP >=20 >=20 > I may agree on what you say, but after all it is always a missing AVP > what we are talking about. So, what suit best of an error of which > semantic is "missing AVP"? >=20 > Marco >=20 > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com]=20 > Sent: Thursday, November 11, 2004 1:55 PM > To: STURA Marco Consultant > Cc: MORAND Lionel RD-CORE-ISS; aaa-wg@merit.edu > Subject: RE: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for=20 > optional AVP >=20 > > I was thinking to similar case as you mentioned. But what=20 > value other > > than DIAMETER_MISSING_AVP should be used in this case? > > > > I don't see any other value available at the moment, that's why the > > DIAMETER_MISSING_AVP seems the most appropriate. >=20 > Looking through the error messages, it isn't clear that any of the > current > ones fit this circumstance. Essentially, you would be saying that the > semantics of the request are invalid. So a new error message is > probably > needed. >=20 > > Having said that, it is possible that some other AVP that *is* > mandatory > > may take on a value that implies the need for another optional AVP, > > which is missing. That would be a terminal error, but a Result_Code > > other than DIAMETER_MISSING_AVP should be used to indicate that. >=20 From owner-aaa-wg@merit.edu Mon Nov 15 22:27:03 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24310 for ; Mon, 15 Nov 2004 22:27:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4F8FA91273; Mon, 15 Nov 2004 22:26:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F14E91274; Mon, 15 Nov 2004 22:26:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B020E91273 for ; Mon, 15 Nov 2004 22:26:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 953D758A96; Mon, 15 Nov 2004 22:26:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dreadnought.cnchost.com (dreadnought.cnchost.com [207.155.248.18]) by segue.merit.edu (Postfix) with ESMTP id E1F9258AF1 for ; Mon, 15 Nov 2004 22:26:51 -0500 (EST) Received: from MedhaviLT (pool-141-156-161-57.esr.east.verizon.net [141.156.161.57]) by dreadnought.cnchost.com id WAA21316; Mon, 15 Nov 2004 22:26:51 -0500 (EST) [ConcentricHost SMTP Relay 1.17] Message-ID: <200411160326.WAA21316@dreadnought.cnchost.com> Reply-To: From: "Medhavi Bhatia" To: Subject: [AAA-WG]: [DiamTrans] reference in diameter-nasreq-17 Date: Mon, 15 Nov 2004 22:26:50 -0500 Organization: NexTone Communications MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D0_01C4CB62.33CC0A20" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTLjBvnwc58PhUfTV+L483afGMHLQ== Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00D0_01C4CB62.33CC0A20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I can't seem to locate this reference in the draft. Any pointers on this ? Thanks - Medhavi. ------=_NextPart_000_00D0_01C4CB62.33CC0A20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I can’t seem to locate this reference in the draft. Any = pointers on this ?

 

Thanks – Medhavi.

------=_NextPart_000_00D0_01C4CB62.33CC0A20-- From owner-aaa-wg@merit.edu Tue Nov 16 09:11:42 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01011 for ; Tue, 16 Nov 2004 09:11:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2F33891281; Tue, 16 Nov 2004 09:11:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2B4091282; Tue, 16 Nov 2004 09:11:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C276191281 for ; Tue, 16 Nov 2004 09:11:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id A966D58958; Tue, 16 Nov 2004 09:11:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.249]) by segue.merit.edu (Postfix) with ESMTP id 4B06058AF1 for ; Tue, 16 Nov 2004 09:11:32 -0500 (EST) Received: by mproxy.gmail.com with SMTP id w67so213094cwb for ; Tue, 16 Nov 2004 06:11:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=gRrftVJnfgmtJOJScqEJHxi8gH8+0gOUJ6L+bMJOhO76EVmHiHRCShlVBKL2i1Ol7tYDRPObWCf26F2sMUFTh1EF7MSec6H9NZ2tnYqdtyHDyz18NEUtvibLW4k5CD8wBvyZNhKKd/2kp+LqFu/oYEh2vzl52Td7M8TLRqGJ2U0= Received: by 10.11.117.66 with SMTP id p66mr771824cwc; Tue, 16 Nov 2004 06:11:31 -0800 (PST) Received: by 10.11.117.55 with HTTP; Tue, 16 Nov 2004 06:11:31 -0800 (PST) Message-ID: Date: Tue, 16 Nov 2004 15:11:31 +0100 From: Jo Hermans Reply-To: Jo Hermans To: mbhatia@nextone.com Subject: Re: [AAA-WG]: [DiamTrans] reference in diameter-nasreq-17 Cc: aaa-wg@merit.edu In-Reply-To: <200411160326.WAA21316@dreadnought.cnchost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <200411160326.WAA21316@dreadnought.cnchost.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable That should be [AAATrans], which points to RFC3539 (AAA Transport Profile). On Mon, 15 Nov 2004 22:26:50 -0500, Medhavi Bhatia wr= ote: > =20 > =20 >=20 > I can't seem to locate this reference in the draft. Any pointers on this = ?=20 >=20 > =20 >=20 > Thanks =E2=80=93 Medhavi.=20 --=20 Jo Hermans www.bluesweb.org "Eagles may soar, but weasels aren't sucked into jet engines" From owner-aaa-wg@merit.edu Tue Nov 16 19:39:43 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15761 for ; Tue, 16 Nov 2004 19:39:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DFB21912AF; Tue, 16 Nov 2004 19:39:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF1C09127F; Tue, 16 Nov 2004 19:39:30 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 522B0912AF for ; Tue, 16 Nov 2004 19:39:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 002C358AD9; Tue, 16 Nov 2004 19:39:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ws6-1.us4.outblaze.com (ws6-1.us4.outblaze.com [205.158.62.196]) by segue.merit.edu (Postfix) with SMTP id 4E6CB5859F for ; Tue, 16 Nov 2004 19:39:28 -0500 (EST) Received: (qmail 5310 invoked from network); 17 Nov 2004 00:39:26 -0000 Received: from unknown (HELO h000094929690.mitton.com) (david@mitton.com@66.30.125.93) by ws6-1.us4.outblaze.com with SMTP; 17 Nov 2004 00:39:26 -0000 Message-Id: <6.1.2.0.2.20041116193938.03e840a0@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 16 Nov 2004 19:41:54 -0500 To: mbhatia@nextone.com From: David Mitton Subject: Re: [AAA-WG]: [DiamTrans] reference in diameter-nasreq-17 Cc: aaa-wg@merit.edu In-Reply-To: References: <200411160326.WAA21316@dreadnought.cnchost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable On 11/16/2004 09:11 AM, Jo Hermans wrote: >That should be [AAATrans], which points to RFC3539 (AAA Transport Profile). > >On Mon, 15 Nov 2004 22:26:50 -0500, Medhavi Bhatia =20 >wrote: > > > > I can't seem to locate this reference in the draft. Any pointers on this= ? > > > > Thanks =AD Medhavi. >-- >Jo Hermans Already found by the RFC Editor and corrected. Dave.=20 From owner-aaa-wg@merit.edu Thu Nov 18 04:36:18 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05191 for ; Thu, 18 Nov 2004 04:36:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3895A91220; Thu, 18 Nov 2004 04:36:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 042FB912CB; Thu, 18 Nov 2004 04:36:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7EB8C91220 for ; Thu, 18 Nov 2004 04:36:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 68B2C584D0; Thu, 18 Nov 2004 04:36:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by segue.merit.edu (Postfix) with ESMTP id 764A9585A8 for ; Thu, 18 Nov 2004 04:36:09 -0500 (EST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Nov 2004 10:34:56 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CD51.DCD0D512" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE : [AAA-WG]: [DiamTrans] reference in diameter-nasreq-17 Date: Thu, 18 Nov 2004 10:34:48 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0260195B03D@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: [AAA-WG]: [DiamTrans] reference in diameter-nasreq-17 Thread-Index: AcTLjBvnwc58PhUfTV+L483afGMHLQBxYkWQ From: "MORAND Lionel RD-CORE-ISS" To: , X-OriginalArrivalTime: 18 Nov 2004 09:34:56.0280 (UTC) FILETIME=[DD581980:01C4CD51] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C4CD51.DCD0D512 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This draft is in the RFC Editor Queue! You can find it on the following = link: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-17.txt= =20 BR, =20 Lionel -----Message d'origine----- De : owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] De la part = de Medhavi Bhatia Envoy=E9 : mardi 16 novembre 2004 04:27 =C0 : aaa-wg@merit.edu Objet : [AAA-WG]: [DiamTrans] reference in diameter-nasreq-17 I can't seem to locate this reference in the draft. Any pointers on this = ? =20 Thanks - Medhavi. ------_=_NextPart_001_01C4CD51.DCD0D512 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
This=20 draft is in the RFC Editor Queue! You can find it on the following=20 link:
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nas= req-17.txt
 
BR,
 
Lionel
-----Message d'origine-----
De : = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu] De la part de Medhavi=20 Bhatia
Envoy=E9 : mardi 16 novembre 2004 = 04:27
=C0 :=20 aaa-wg@merit.edu
Objet : [AAA-WG]: [DiamTrans] = reference in=20 diameter-nasreq-17

I can’t seem to locate this reference = in the draft.=20 Any pointers on this ?

 

Thanks –=20 Medhavi.

------_=_NextPart_001_01C4CD51.DCD0D512-- From owner-aaa-wg@merit.edu Wed Nov 24 08:37:12 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23195 for ; Wed, 24 Nov 2004 08:37:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1485491201; Wed, 24 Nov 2004 08:37:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE32A91203; Wed, 24 Nov 2004 08:37:03 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6CF4191201 for ; Wed, 24 Nov 2004 08:37:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 542A658A27; Wed, 24 Nov 2004 08:37:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 70994589E5 for ; Wed, 24 Nov 2004 08:36:57 -0500 (EST) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 54BA989875; Wed, 24 Nov 2004 15:36:47 +0200 (EET) Message-ID: <41A48DF7.6090901@kolumbus.fi> Date: Wed, 24 Nov 2004 15:34:47 +0200 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: Miguel Garcia , "Beck01, Wolfgang" Cc: AAA mailing list , radiusext@ops.ietf.org Subject: Re: [AAA-WG]: Reconciling Radius/Diameter SIP application References: <41936F4C.5080201@nokia.com> In-Reply-To: <41936F4C.5080201@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Miguel Garcia wrote: > I am deliberately cross posting to AAA and Radius-ext because I believe > this topic is of interest for both lists. > > Yesterday Wolfgang and me met for a few hours and set the goal of > reconcile the Diameter SIP application and the RADIUS HTTP/SIP Digest > drafts. These are the drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-04.txt > > http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt > > These are the main points we discuss. If you have any comments, speak up > now, otherwise we will do the proposed changes in the relevant drafts: > > 1- We agreed to modify the Diameter SIP application so that it imports > the Digest-* AVP from the corresponding RADIUS attributes address space. > This came out of a comment from Jari Arkko, and I think it is important > to avoid duplication of AVP/attributes. > > As a side effect of the above, the SIP-Authentication-Context will > disappear in Diameter SIP app. This was a grouped AVP that only > contained a Digest-Entity-Body-Hash AVP. The latter will remain (in the > RADIUS draft). Great! > 2- We noticed a divergence in the Digest-Expected-Response AVP in > Diameter, which does not exist in RADIUS. RADIUS defines a Digest-HA1 > attribute. The difference: Digest-HA1 contains H(A1), which is computed > at the Radius server and sent to the Radius client, and it is used to > compute the expected response. In Diameter, the expected response is > computed at the Diameter server and sent to the client. This assumes a > secure connection to avoid eavesdropping, which is not a problem for > Diameter that mandates IPsec or TLS. I think Diameter can go for the > Radius approach for compatibility reasons. > > Proposal: Diameter will remove Digest-Expected-Response AVP and will > import Digest-HA1 from Radius. Ok. > 3- Radius does not define UTF8String data types, so all these attributes > will remain as String, but the Radius draft will indicate that contain a > UTF8String verbally (this is required by HTTP and SIP). Hm, I guess this is OK. > 4- Currently here is a divergence on the definition of Digest-Stale > attribute: Diameter uses "true" and "false" (as per RFC2617), Radius > uses 1 and 0. We agreed to use "true" and "false" to avoid stupid > transcodings. This is much better. Good. > 5- Diameter indicates that the Digest-* AVPs contain the quotes from/to > the Digest directive, Radius assumes (although does not indicate) no > quotes. We agreed that the Digest-* attributes do not need to include > the quotes from HTTP Digest parameters. So, there will be an explicit > indication that quotes are not part of the attribute value. This is better too. > 6- We run into a problem when multiple SIP proxies are authenticating > the user, because at some point in time the SIP request may contain > several Proxy-Authorization headers. The key here is the realm, it > will be always different. If different Diameter/Radius servers are > serving different realms, there is not problem. But, if a common > Diameter/Radius server is serving different realms, then the server is > not able to determine which credentials should be evaluated. > > We propose that the Diameter/Radius client MUST send only one set of > credentials at a time, those belonging to the served realm. This > requires to configure the Diameter/Radius client with the realm it is > serving. We will include some text indicating this case. I fail to see the problem, most likely due to the insufficient understanding of the protocol details on my part. But will your solution lead to some problem if there's roaming involved? > 7- Some of the attributes (e.g, Digest-Response and > Digest-Response-Auth) had an artificial limit of 32 octets in the > value. While this value is correct for MD5 hashes, if in the future > other hashes are added to HTTP Digest, will run into > trouble. Proposal: don't restrict the length of a value. Right. > 8- In the Radius document, scenario 1, we have a question. We suspect > that this scenario does not work if the Radius client generates a > nextnonce. The reason is that in the following authentication, when the > nextnonce becomes a nonce, the Radius server will not recognize the > nonce as locally generated (it was generated by the Radius client), and > will reject the request with a "state=true". RFC 2617 seems to describe > the case: > > If the > nextnonce field is present the client SHOULD use it when constructing > the Authorization header for its next request. Failure of the client > to do so may result in a request to re-authenticate from the server > with the "stale=TRUE". > > Does anyone have any comment? Can anyone confirm that the operation in > Digest is as we indicate? We will add some text indicating the > limitations of Scenario 1. In looking at this, I have the same question as you. So no help from me, sorry. > 9- The Radius draft, in section 2.15, indicates: > > RADIUS > servers that do not implement a parameter contained in a > Digest-Auth-Param attribute MUST respond with an Access-Reject > message. RADIUS clients that do not implement a parameter > contained in a Digest-Auth-Param attribute MUST reject the > original HTTP-style request. > > The problem is that the text seems to go against RFC 2617 that says: > > auth-param > This directive allows for future extensions. Any unrecognized > directive MUST be ignored. > > The proposal is to remove the above text from the RADIUS draft. Yes, this is correct. > 10- Similar contradictory text was found in Section 2.16 of the RADIUS > draft, that says: > > RADIUS servers that do > not implement AKA Digest MUST response with an Access Reject > message. > > We propose to remove the above text. The motivation is that the > algorithm already conveys the AKA (AKA extends the algorithm to be > AKAv1-MD5 and AKAv1-MD5-sess). The server chooses the algorithm, so the > situation currently described, where the client may include an auts > attribute, is just an error case, where the client made a mistake and > included AUTS when not doing AKA. In case the Radius server does not > implement AKA authentication, it will safely ignore this AVP. Right. > 11- We noticed that most of the HTTP Digest directives contain just a > single token. However, the "qop" directive may contain a comma-separated > collection of tokens. For instance, qop="auth,auth-int". The question is > how do encode these tokens in the Digest-Qop attribute. The options are: > > a) Treat the whole thing as one token and put it into the attribute value. > b) Each token is an attribute, thus, there might be multiple Digest-Qop > attributes in a particular Radius/Diameter message. > > We think that option b) is cleaner. Particularly it will be easier for > the Diameter/Radius client to encode different values in different > attributes. I think option a) is cleaner, although I don't care enough to think it should be a showstopper. But here's my reasoning: avoid unnecessary mapping work that the client needs to do; handle everything as much as possible by taking all text from the SIP syntax and putting it blindly into an AVP... --Jari From owner-aaa-wg@merit.edu Wed Nov 24 09:30:59 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27508 for ; Wed, 24 Nov 2004 09:30:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6B0BC9123C; Wed, 24 Nov 2004 09:30:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2EAB39123F; Wed, 24 Nov 2004 09:30:46 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 951A49123C for ; Wed, 24 Nov 2004 09:30:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id D3E4758A0D; Wed, 24 Nov 2004 09:30:37 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 16E13587C5 for ; Wed, 24 Nov 2004 09:30:34 -0500 (EST) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAOEUTv29144; Wed, 24 Nov 2004 16:30:30 +0200 (EET) X-Scanned: Wed, 24 Nov 2004 16:24:29 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iAOEOTr8031785; Wed, 24 Nov 2004 16:24:29 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00vjYCOc; Wed, 24 Nov 2004 16:22:31 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAOEMNa03144; Wed, 24 Nov 2004 16:22:23 +0200 (EET) Received: from [172.21.38.233] ([172.21.38.233]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 24 Nov 2004 16:22:23 +0200 Message-ID: <41A4991F.10309@nokia.com> Date: Wed, 24 Nov 2004 16:22:23 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Jari Arkko Cc: "Beck01, Wolfgang" , AAA mailing list , radiusext@ops.ietf.org Subject: Re: [AAA-WG]: Reconciling Radius/Diameter SIP application References: <41936F4C.5080201@nokia.com> <41A48DF7.6090901@kolumbus.fi> In-Reply-To: <41A48DF7.6090901@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Nov 2004 14:22:23.0411 (UTC) FILETIME=[03E9F030:01C4D231] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jari: Thanks for your comments. There are two points I want to discuss a bit further. See blow: Jari Arkko wrote: > Miguel Garcia wrote: > >> 6- We run into a problem when multiple SIP proxies are authenticating >> the user, because at some point in time the SIP request may contain >> several Proxy-Authorization headers. The key here is the realm, it >> will be always different. If different Diameter/Radius servers are >> serving different realms, there is not problem. But, if a common >> Diameter/Radius server is serving different realms, then the server is >> not able to determine which credentials should be evaluated. >> >> We propose that the Diameter/Radius client MUST send only one set of >> credentials at a time, those belonging to the served realm. This >> requires to configure the Diameter/Radius client with the realm it is >> serving. We will include some text indicating this case. > > > I fail to see the problem, most likely due to the insufficient > understanding of the protocol details on my part. But will > your solution lead to some problem if there's roaming > involved? Let me try to describe the problem. In HTTP there is typically a single Proxy-Aut* header, due to that typically there is a single proxy sitting between the client and the server. In SIP things get a bit more complicated, since it is common that a SIP request traverses several proxies, where theoretically each proxy could demand credentials. It is also valid that each SIP proxy requests credentials for the same or different realms than other SIP proxies. In other words, a SIP proxy can receive a SIP request that contain several Proxy-Authorization header fieldss. Each header field will contain the credentials for a particular realm. So let's assume that one of this proxies receives a request that contains several Proxy-Authorization headers. Which one should the SIP proxy put into the Radius/Diameter message and send it to the Radius/Diameter server? a) Put blindly everything, I mean, all the Proxy-Authorization headers. Repeat attributes (Radius will give us a problem since attributes are not grouped). b) Extract the credentials that are of interested (according to the realm) of the SIP server and RADIUS/Diameter server. This requires to configure the SIP server with the realm it is serving, but it has some benefits: first the Radius/Diameter message contains one set of credentials (no poblems with Radius); second, it allows the Radius/Diameter server to be authenticating several realms, so there is no uncertainity because there is only one set of credentials in the message. Therefore, we proposed to clarify all this issue and describe the need to configure the SIP server with the realm it is serving. This allows the server to select the appropriate credentials. > >> 11- We noticed that most of the HTTP Digest directives contain just a >> single token. However, the "qop" directive may contain a >> comma-separated collection of tokens. For instance, >> qop="auth,auth-int". The question is how do encode these tokens in the >> Digest-Qop attribute. The options are: >> >> a) Treat the whole thing as one token and put it into the attribute >> value. >> b) Each token is an attribute, thus, there might be multiple >> Digest-Qop attributes in a particular Radius/Diameter message. >> >> We think that option b) is cleaner. Particularly it will be easier for >> the Diameter/Radius client to encode different values in different >> attributes. > > > I think option a) is cleaner, although I don't care enough to > think it should be a showstopper. But here's my reasoning: > avoid unnecessary mapping work that the client needs to do; > handle everything as much as possible by taking all text > from the SIP syntax and putting it blindly into an AVP... > I don't care either. I just thought we shouldn't put too much work to the Diameter/Radius server about how to encode Digest directives. Approach a requires the Diameter/Radius server to be able to encode "auth", "aut-int", "auth,auth-int", and use it appropriately. If the number of tokens is just two, then any approach is feasible. - Miguel > --Jari -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Wed Nov 24 10:26:11 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03547 for ; Wed, 24 Nov 2004 10:26:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EC96C9120F; Wed, 24 Nov 2004 10:26:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B62F491242; Wed, 24 Nov 2004 10:26:05 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B46029120F for ; Wed, 24 Nov 2004 10:26:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 98B2F58ADD; Wed, 24 Nov 2004 10:26:04 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by segue.merit.edu (Postfix) with ESMTP id 4396158AD5 for ; Wed, 24 Nov 2004 10:26:04 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Wed, 24 Nov 2004 10:26:03 -0500 Message-ID: From: Avi Lior To: "'Jari Arkko'" , Miguel Garcia , "Beck01, Wolfgang" Cc: AAA mailing list , radiusext@ops.ietf.org Subject: RE: [AAA-WG]: Reconciling Radius/Diameter SIP application Date: Wed, 24 Nov 2004 10:26:01 -0500 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 Miquel, Jarri, > > 3- Radius does not define UTF8String data types, so all these > > attributes > > will remain as String, but the Radius draft will indicate > that contain a > > UTF8String verbally (this is required by HTTP and SIP). Just one point now. RADIUS "Text" type attributes are UTF-8 compliant. I just want to make sure that the definition of Text and UTF8String are the same. And they appear to be. From RFC 2865: text 1-253 octets containing UTF-8 encoded 10646 [7] characters. Text of length zero (0) MUST NOT be sent; omit the entire attribute instead. [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. From RFC 3588: This is a human readable string represented using the ISO/IEC IS 10646-1 character set, encoded as an OctetString using the UTF-8 [UFT8] transformation format described in RFC 2279. So where applicable the attributes in Sterman should be set to Text. From owner-aaa-wg@merit.edu Wed Nov 24 11:16:15 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07067 for ; Wed, 24 Nov 2004 11:16:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E37C191247; Wed, 24 Nov 2004 11:15:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 748FC91246; Wed, 24 Nov 2004 11:15:37 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EB49891247 for ; Wed, 24 Nov 2004 11:15:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 889B958A6B; Wed, 24 Nov 2004 11:15:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by segue.merit.edu (Postfix) with ESMTP id EFBA3588E1 for ; Wed, 24 Nov 2004 11:15:24 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Wed, 24 Nov 2004 11:15:24 -0500 Message-ID: From: Avi Lior To: "'Miguel Garcia'" , Jari Arkko Cc: "Beck01, Wolfgang" , AAA mailing list , radiusext@ops.ietf.org Subject: RE: [AAA-WG]: Reconciling Radius/Diameter SIP application Date: Wed, 24 Nov 2004 11:15:15 -0500 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 Option b) is cleaner because it requires less parsing work by AAA server. Regarding the following comment: > handle everything > as much as > > possible by taking all text from the SIP syntax and putting > it blindly > > into an AVP... Wolfgang's original document did that for all the attributes (using subtypes) which could have been handled by both RADIUS and Diameter. Lets not go there again. > > > >> 11- We noticed that most of the HTTP Digest directives > contain just a > >> single token. However, the "qop" directive may contain a > >> comma-separated collection of tokens. For instance, > >> qop="auth,auth-int". The question is how do encode these > tokens in the > >> Digest-Qop attribute. The options are: > >> > >> a) Treat the whole thing as one token and put it into the attribute > >> value. > >> b) Each token is an attribute, thus, there might be multiple > >> Digest-Qop attributes in a particular Radius/Diameter message. > >> > >> We think that option b) is cleaner. Particularly it will be easier > >> for > >> the Diameter/Radius client to encode different values in different > >> attributes. > > > > > > I think option a) is cleaner, although I don't care enough > to think it > > should be a showstopper. But here's my reasoning: avoid unnecessary > > mapping work that the client needs to do; handle everything > as much as > > possible by taking all text from the SIP syntax and putting > it blindly > > into an AVP... > > > > I don't care either. I just thought we shouldn't put too much work to > the Diameter/Radius server about how to encode Digest directives. > Approach a requires the Diameter/Radius server to be able to encode > "auth", "aut-int", "auth,auth-int", and use it appropriately. If the > number of tokens is just two, then any approach is feasible. > > - Miguel > > > > --Jari > > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Research Center Helsinki, Finland > From owner-aaa-wg@merit.edu Wed Nov 24 11:23:44 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07681 for ; Wed, 24 Nov 2004 11:23:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CBFE091243; Wed, 24 Nov 2004 11:23:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9564F91246; Wed, 24 Nov 2004 11:23:37 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 54D0C91243 for ; Wed, 24 Nov 2004 11:23:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3CA0D58AF4; Wed, 24 Nov 2004 11:23:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by segue.merit.edu (Postfix) with ESMTP id DA63458AC2 for ; Wed, 24 Nov 2004 11:23:35 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Wed, 24 Nov 2004 11:23:35 -0500 Message-ID: From: Avi Lior To: "'Jari Arkko'" , radiusext@ops.ietf.org, "'Miguel.An.Garcia@nokia.com'" , "'BeckW@t-systems.com'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Reconciling Radius/Diameter SIP application Date: Wed, 24 Nov 2004 11:23:32 -0500 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 Miguel, Wolfgang and Jari, I am trying to get a deeper understanding here. But it seems to me that in Scenario 1 where the RADIUS Client is generating the nonces, the client really needs to be the one that determines the staleness of the nonces and not the AAA. Therefore, the client will not even invoke the AAA server when the nonce is stale; and the AAA will just assume that all nonces are valid. > > 8- In the Radius document, scenario 1, we have a question. > We suspect > > that this scenario does not work if the Radius client generates a > > nextnonce. The reason is that in the following authentication, when > > the nextnonce becomes a nonce, the Radius server will not recognize > > the nonce as locally generated (it was generated by the Radius > > client), and will reject the request with a "state=true". RFC 2617 > > seems to describe the case: > > > > If the > > nextnonce field is present the client SHOULD use it when > constructing > > the Authorization header for its next request. Failure > of the client > > to do so may result in a request to re-authenticate from > the server > > with the "stale=TRUE". > > > > Does anyone have any comment? Can anyone confirm that the > operation in > > Digest is as we indicate? We will add some text indicating the > > limitations of Scenario 1. > > In looking at this, I have the same question as you. So no > help from me, sorry. > > > 9- The Radius draft, in section 2.15, indicates: > > > > RADIUS > > servers that do not implement a parameter contained in a > > Digest-Auth-Param attribute MUST respond with an > Access-Reject > > message. RADIUS clients that do not implement a parameter > > contained in a Digest-Auth-Param attribute MUST reject the > > original HTTP-style request. > > > > The problem is that the text seems to go against RFC 2617 that says: > > > > auth-param > > This directive allows for future extensions. Any unrecognized > > directive MUST be ignored. > > > > The proposal is to remove the above text from the RADIUS draft. > > Yes, this is correct. > > > 10- Similar contradictory text was found in Section 2.16 of > the RADIUS > > draft, that says: > > > > RADIUS servers that do > > not implement AKA Digest MUST response with an Access Reject > > message. > > > > We propose to remove the above text. The motivation is that the > > algorithm already conveys the AKA (AKA extends the algorithm to be > > AKAv1-MD5 and AKAv1-MD5-sess). The server chooses the > algorithm, so the > > situation currently described, where the client may include an auts > > attribute, is just an error case, where the client made a > mistake and > > included AUTS when not doing AKA. In case the Radius server > does not > > implement AKA authentication, it will safely ignore this AVP. > > Right. > > > 11- We noticed that most of the HTTP Digest directives > contain just a > > single token. However, the "qop" directive may contain a > comma-separated > > collection of tokens. For instance, qop="auth,auth-int". > The question is > > how do encode these tokens in the Digest-Qop attribute. The > options are: > > > > a) Treat the whole thing as one token and put it into the attribute > > value. > > b) Each token is an attribute, thus, there might be > multiple Digest-Qop > > attributes in a particular Radius/Diameter message. > > > > We think that option b) is cleaner. Particularly it will be > easier for > > the Diameter/Radius client to encode different values in different > > attributes. > > I think option a) is cleaner, although I don't care enough to > think it should be a showstopper. But here's my reasoning: > avoid unnecessary mapping work that the client needs to do; > handle everything as much as possible by taking all text from > the SIP syntax and putting it blindly into an AVP... > > --Jari > > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > From owner-aaa-wg@merit.edu Wed Nov 24 14:01:01 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20363 for ; Wed, 24 Nov 2004 14:01:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 99CE49124A; Wed, 24 Nov 2004 14:00:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 613E09124C; Wed, 24 Nov 2004 14:00:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 96E8C9124A for ; Wed, 24 Nov 2004 14:00:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id EEE45589C8; Wed, 24 Nov 2004 14:00:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 4891C58A6B for ; Wed, 24 Nov 2004 14:00:24 -0500 (EST) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 240EA8983E; Wed, 24 Nov 2004 21:00:21 +0200 (EET) Message-ID: <41A4D9CD.1010501@kolumbus.fi> Date: Wed, 24 Nov 2004 20:58:21 +0200 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: Miguel Garcia Cc: "Beck01, Wolfgang" , AAA mailing list , radiusext@ops.ietf.org Subject: Re: [AAA-WG]: Reconciling Radius/Diameter SIP application References: <41936F4C.5080201@nokia.com> <41A48DF7.6090901@kolumbus.fi> <41A4991F.10309@nokia.com> In-Reply-To: <41A4991F.10309@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Miguel Garcia wrote: > In HTTP there is typically a single Proxy-Aut* header, due to that > typically there is a single proxy sitting between the client and the > server. > > In SIP things get a bit more complicated, since it is common that a SIP > request traverses several proxies, where theoretically each proxy could > demand credentials. It is also valid that each SIP proxy requests > credentials for the same or different realms than other SIP proxies. > > In other words, a SIP proxy can receive a SIP request that contain > several Proxy-Authorization header fieldss. Each header field will > contain the credentials for a particular realm. > > So let's assume that one of this proxies receives a request that > contains several Proxy-Authorization headers. Which one should the SIP > proxy put into the Radius/Diameter message and send it to the > Radius/Diameter server? Thanks for the explanation. The situation is clearer to me now. > a) Put blindly everything, I mean, all the Proxy-Authorization headers. > Repeat attributes (Radius will give us a problem since attributes are > not grouped). I see the problem. > b) Extract the credentials that are of interested (according to the > realm) of the SIP server and RADIUS/Diameter server. This requires to > configure the SIP server with the realm it is serving, but it has some > benefits: first the Radius/Diameter message contains one set of > credentials (no poblems with Radius); second, it allows the > Radius/Diameter server to be authenticating several realms, so there is > no uncertainity because there is only one set of credentials in the > message. > > Therefore, we proposed to clarify all this issue and describe the need > to configure the SIP server with the realm it is serving. This allows > the server to select the appropriate credentials. This sounds reasonable, and my original worry turned out to be a non-issue. (I worried that this might somehow limit what the user's realm might be. But the client's header includes both the username, which might of the form jari@domain, and the challenging proxy's realm. Only the latter is used in matching what gets sent to the AAA server. In conclusion I could be jari@domain1 when traversing through three proxies that challenge me using realms domain2, domain3, and domain4, and a single AAA server could handle all of this.) --Jari From owner-aaa-wg@merit.edu Wed Nov 24 16:54:53 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07527 for ; Wed, 24 Nov 2004 16:54:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0731791214; Wed, 24 Nov 2004 16:54:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8F6E91254; Wed, 24 Nov 2004 16:54:47 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E4EF91214 for ; Wed, 24 Nov 2004 16:54:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 790555858B; Wed, 24 Nov 2004 16:54:46 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by segue.merit.edu (Postfix) with ESMTP id 1DFE85855D for ; Wed, 24 Nov 2004 16:54:46 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Wed, 24 Nov 2004 16:54:45 -0500 Message-ID: From: Avi Lior To: "'Jari Arkko'" , Miguel Garcia Cc: "Beck01, Wolfgang" , AAA mailing list , radiusext@ops.ietf.org Subject: RE: [AAA-WG]: Reconciling Radius/Diameter SIP application Date: Wed, 24 Nov 2004 16:54:44 -0500 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, Again I think that only option b is the valid one. Unless I am missing something, I think a Proxy must be able to identify the the Proxy-Authorization that is associated with it. From RFC 2616: "When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first outbound proxy that was expecting to receive credentials. A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request." Therefore you would think that a particular proxy would extract the credentials from its headers and those would be the only ones that are sent to the AAA infrastructure. And this also implies that the Proxy has a way to identify the Proxy-Authroization header. Is this right? > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Wednesday, November 24, 2004 1:58 PM > To: Miguel Garcia > Cc: Beck01, Wolfgang; AAA mailing list; radiusext@ops.ietf.org > Subject: Re: [AAA-WG]: Reconciling Radius/Diameter SIP application > > > Miguel Garcia wrote: > > > In HTTP there is typically a single Proxy-Aut* header, due to that > > typically there is a single proxy sitting between the > client and the > > server. > > > > In SIP things get a bit more complicated, since it is common that a > > SIP > > request traverses several proxies, where theoretically each > proxy could > > demand credentials. It is also valid that each SIP proxy requests > > credentials for the same or different realms than other SIP proxies. > > > > In other words, a SIP proxy can receive a SIP request that contain > > several Proxy-Authorization header fieldss. Each header field will > > contain the credentials for a particular realm. > > > > So let's assume that one of this proxies receives a request that > > contains several Proxy-Authorization headers. Which one > should the SIP > > proxy put into the Radius/Diameter message and send it to the > > Radius/Diameter server? > > Thanks for the explanation. The situation is clearer to me > now. > > > a) Put blindly everything, I mean, all the Proxy-Authorization > > headers. > > Repeat attributes (Radius will give us a problem since > attributes are > > not grouped). > > I see the problem. > > > b) Extract the credentials that are of interested (according to the > > realm) of the SIP server and RADIUS/Diameter server. This > requires to > > configure the SIP server with the realm it is serving, but > it has some > > benefits: first the Radius/Diameter message contains one set of > > credentials (no poblems with Radius); second, it allows the > > Radius/Diameter server to be authenticating several realms, > so there is > > no uncertainity because there is only one set of credentials in the > > message. > > > > Therefore, we proposed to clarify all this issue and > describe the need > > to configure the SIP server with the realm it is serving. > This allows > > the server to select the appropriate credentials. > > This sounds reasonable, and my original worry turned out > to be a non-issue. (I worried that this might somehow > limit what the user's realm might be. But the client's > header includes both the username, which might of the > form jari@domain, and the challenging proxy's realm. > Only the latter is used in matching what gets sent to > the AAA server. In conclusion I could be jari@domain1 > when traversing through three proxies that challenge > me using realms domain2, domain3, and domain4, and > a single AAA server could handle all of this.) > > --Jari > From owner-aaa-wg@merit.edu Wed Nov 24 17:08:54 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08252 for ; Wed, 24 Nov 2004 17:08:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ACDBD91229; Wed, 24 Nov 2004 17:08:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E93991254; Wed, 24 Nov 2004 17:08:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9714491229 for ; Wed, 24 Nov 2004 17:08:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 830C7585B9; Wed, 24 Nov 2004 17:08:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by segue.merit.edu (Postfix) with ESMTP id 41FA15843D for ; Wed, 24 Nov 2004 17:08:48 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Wed, 24 Nov 2004 17:08:47 -0500 Message-ID: From: Avi Lior Cc: "'AAA mailing list'" Subject: TEST [AAA-WG]: Reconciling Radius/Diameter SIP application Date: Wed, 24 Nov 2004 17:08:46 -0500 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 Test: I have been sending messages but something is reporting an error against one of the receipients not sure whom. From ninauk@gmail.com Wed Nov 24 20:15:42 2004 Received: from gmail.com (client-82-11-115-65.glfd.adsl.ntlworld.com [82.11.115.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23865 for ; Wed, 24 Nov 2004 20:15:30 -0500 (EST) Message-Id: <200411250115.UAA23865@ietf.org> From: "nina" Subject: Job application To: aaa-archive@ietf.org Content-Type: multipart/mixed; boundary="=_NextPart_2rfkindysadvnqw3nerasdf";charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Reply-To: ninauk@gmail.com Date: Thu, 25 Nov 2004 09:15:35 +0800 X-Priority: 3 X-Mailer: Foxmail 5.0 beta2 [cn] This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain Content-Transfer-Encoding: 7bit Dear Sir/Madam: I'm an overseas trained teacher and search job here in UK in the school.I used to be a teacher in China in a college for many years . I graduated from Beijing Teachers University and trained to become a teacher since 1984. I have got MBA degree in Germany .My Master degree and my Bachelor degree has been assessed by NARIC which comparable to the Master degree here in UK and Bachelor degree here in UK. Please see my attached CV for detail . I wish I could find a teaching related job here in UK . I can speak Chinese and English and some German. Look forward the possible interview opportunity from you! Thank you very much for your attention! Kind regards! Nina,Ni --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: application/octet-stream; name="CV(nina , teacher ).doc" Content-Disposition: attachment; filename="CV(nina , teacher ).doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAPgAAAAAAAAAA EAAAQAAAAAEAAAD+////AAAAAD0AAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAOSAJBAAA+FK/AAAAAAAAEAAAAAAABAAAkAwAAA4AYmpiav3P/c8AAAAAAAAAAAAAAAAAAAAA AAAECBYAOSkAAJ+lAACfpQAAkAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAJgBAAAAAAAAmAEAAJgB AAAAAAAAmAEAAAAAAACYAQAAAAAAAJgBAAAAAAAAmAEAABQAAAAAAAAAAAAAAKwBAAAAAAAAKAYA AAAAAAAoBgAAAAAAACgGAAAAAAAAKAYAABwAAABEBgAAPAAAAKwBAAAAAAAA0RsAACoBAACMBgAA lAAAACAHAAAAAAAAIAcAAAAAAAAgBwAAAAAAACAHAAAAAAAA/xAAADoAAAA5EQAAFAAAAE0RAAAM AAAAUBsAAAIAAABSGwAAAAAAAFIbAAAAAAAAUhsAAAAAAABSGwAAAAAAAFIbAAAAAAAAUhsAACQA AAD7HAAAIAIAABsfAABAAAAAdhsAABUAAAAAAAAAAAAAAAAAAAAAAAAAmAEAAAAAAABZEQAAAAAA AAAAAAAAAAAAAAAAAAAAAAApEAAA1gAAAP8QAAAAAAAAWREAAAAAAABZEQAAAAAAAHYbAAAAAAAA 5RIAAAAAAACYAQAAAAAAAJgBAAAAAAAAIAcAAAAAAAAAAAAAAAAAACAHAAAJCQAAixsAABYAAADl EgAAAAAAAOUSAAAAAAAA5RIAAAAAAABZEQAAygAAAJgBAAAAAAAAIAcAAAAAAACYAQAAAAAAACAH AAAAAAAAUBsAAAAAAAAAAAAAAAAAAOUSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAWREAAAAAAABQGwAAAAAAAOUSAAAGBQAA5RIAAAAAAADrFwAA HgAAABgaAAAYAAAAmAEAAAAAAACYAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZBoAAAAAAAAgBwAAAAAAAIAGAAAMAAAAEPYdAZvO xAGsAQAAfAQAACgGAAAAAAAAIxIAAI4AAAAwGgAACAAAAAAAAAAAAAAAZBoAAOwAAAChGwAAMAAA ANEbAAAAAAAAOBoAACwAAABbHwAAAAAAALESAAA0AAAAWx8AAAAAAABkGgAAAAAAAOUSAAAAAAAA rAEAAAAAAACsAQAAAAAAAJgBAAAAAAAAmAEAAAAAAACYAQAAAAAAAJgBAAAAAAAAAgDZAAAAICAg ICAgICAgICAgICBDVg1QZXJzb25hbCBpbmZvcm1hdGlvbgcTIEhZUEVSTElOSyAiaHR0cDovL3d3 dy50cmFuc2xhdG9yc2NhZmUuY29tL2NhZmUvIiBcbCAiVG9wIiAUCBUHB05hbWU6IER1YW4sTmkg LEVuZ2xpc2ggbmFtZTogbmluYSxuaQ1TZXg6ICAgRmVtYWxlICAgICAgICAgICAgIA1CaXJ0aGRh eTogTWFyY2ggOCwxOTYzDU5hdGlvbmFsaXR5OiBDaGluZXNlDUFjYWRlbWljIERlZ3JlZTogTUJB IGluIEVuZ2xpc2ggbGFuZ3VhZ2UgaW4gR2VybWFueQ1UZWw6MDE4OTI1Mzk1NTksTW9iaWxlOjA3 OTEwLTEwNTcyMw1FLW1haWw6IBMgSFlQRVJMSU5LICJtYWlsdG86bmluYW5pMTgyMDAxQHlhaG9v LmNvbS5oayIgARRuaW5hbmkxODIwMDFAeWFob28uY29tLmhrFQ1BZGQ6MyBoZWF0aGZpZWxkcyAs U2FuZHJvY2sgcm9hZCAsIFR1bmJyaWRnZSBXZWxscyAsIEtlbnQsIFROMiAzIFBVIC4NDUVkdWNh dGlvbgcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy50cmFuc2xhdG9yc2NhZmUuY29tL2NhZmUvIiBc bCAiVG9wIiAUCBUHBzEuIEF1Z3VzdCAyMDAwLSBBcHJpbCAyMDAyLCBNQkEgaW4gaW50ZXJuYXRp b25hbCBtYW5hZ2VtZW50LCBTdHV0dGdhcnQgSW5zdGl0dXRlIG9mIE1hbmFnZW1lbnQgYW5kIFRl Y2hub2xvZ3ksIFN0dXR0Z2FydCwgR2VybWFueSAodXNpbmcgRW5nbGlzaCBsYW5ndWFnZSBpbiB0 aGUgVU5JVkVSU0lUWSkLCzIuMTk4MC0xOTg0LCBCYWNoZWxvciBEZWdyZWUgb2YgUGhpbG9zb3Bo eSBmcm9tIG9uZSBvZiB0aGUgdG9wIHVuaXZlcnNpdGllcyBpbiBDaGluYS0tLUJlaWppbmcgVGVh Y2hlcnOSIFVuaXZlcnNpdHksIEJlaWppbmcsIENoaW5hLgsLDVdvcmsgRXhwZXJpZW5jZQcTIEhZ UEVSTElOSyAiaHR0cDovL3d3dy50cmFuc2xhdG9yc2NhZmUuY29tL2NhZmUvIiBcbCAiVG9wIiAU CBUHBzEuMjAwMi1ub3cuIEdlbmVyYWwgTWFuYWdlciAsIHNlbmlvciBjb25zdWx0YW50ICxsZWN0 dXJlciAgDUhpZXN1biBJbnRlcm5hdGlvbmFsIE1hbmFnZW1lbnQgU3lzdGVtIGFuZCBDb25zdWx0 aW5nIENvLixsdGQuIEhhbmd6aG91LCBDaGluYQ0yLk1heSAsMjAwMS1BdWd1c3QsIDIwMDEgLElu dGVybnNoaXAgaW4gTWFycXVhcmR0ICBHTUJIICwgR2VybWFueSANSW5kZXBlbmRlbnRseSBmaW5p c2ggYSBwcm9qZWN0IGFib3V0IG9wZW5pbmcgdXAgZmFyIGVhc3Rlcm4gcHVyY2hhc2luZyBtYXJr ZXQuDTMuMTk5NS0yMDAwICwgR2VuZXJhbCBNYW5hZ2VyICwgY29uc3VsdGFudCAsIGxlY3R1cmVy ICxIYW5nemhvdSBYaW5IZSBFY29ub21pYyBJbmZvcm1hdGlvbiBDb25zdWx0aW5nIENPLixMdGQg LixIYW5nemhvdSxDaGluYQ00LjE5ODQtMTk5NCwgdGVhY2hlciAsYXQgZGVwYXJ0bWVudCBvZiBQ b2xpdGljcyBhbmQgaGlzdG9yeSAsaW4gWmhlamlhbmcgRWR1Y2F0aW9uYWwgY29sbGVnZSAsSGFu Z3pob3UgLENoaW5hIAsNTGFuZ3VhZ2UgYWJpbGl0eQcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy50 cmFuc2xhdG9yc2NhZmUuY29tL2NhZmUvIiBcbCAiVG9wIiAUCBUHB0NoaW5lc2U6IE5hdGl2ZSBs YW5ndWFnZSANRW5nbGlzaDogIEZsdWVudCANR2VybWFuOiBCYXNpYyBsZXZlbCANQ29tcHV0ZXIg YWJpbGl0eSAHEyBIWVBFUkxJTksgImh0dHA6Ly93d3cudHJhbnNsYXRvcnNjYWZlLmNvbS9jYWZl LyIgXGwgIlRvcCIgFAgVBwdXb3JkIDIwMDAsIEV4Y2VsIDIwMDAsIFBvd2VyUG9pbnQgMjAwMCBl dGMuDVBlcnNvbmFsIGludGVyZXN0IAcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy50cmFuc2xhdG9y c2NhZmUuY29tL2NhZmUvIiBcbCAiVG9wIiAUCBUHB1N3aW1taW5nICwgVHJhdmVsaW5nICwgdGFi bGUgdGVubmlzICwgcmVhZGluZyBhbmQgd3JpdGluZyANTWFpbiBwdWJsaWNhdGlvbnMHEyBIWVBF UkxJTksgImh0dHA6Ly93d3cudHJhbnNsYXRvcnNjYWZlLmNvbS9jYWZlLyIgXGwgIlRvcCIgFAgV BwdCb29rOiBSZWZvcm0gYW5kIFJlZm9ybSBvZiBDaGluZXNlIE5hdGlvbmFsIENoYXJhY3RlcnMg LDE5ODYgaW4gQ2hpbmEgWW91dGggUHVibGljYXRpb25zICxCZWlKaW5nICxDaGluYSAuDXJlLXB1 Ymxpc2hlZCBpbiBISyBpbiAxOTg3IGJ5IFN1R3VhbmcgcHVibGljYXRpb25zIGluIEhLLg1NYW55 IGVjb25vbXkgcmVsYXRlZCBhcnRpY2xlcyBpbiBDaGluYSBuZXdzcGFwZXIgYW5kIG1hZ2F6aW5l cyBzaW5jZSAxOTgwknMgLg0NDQ0NDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAABEEAAAl BAAAJgQAACcEAABiBAAAYwQAAGQEAABlBAAAZgQAAGcEAADTBAAA2wQAADMFAAA0BQAARwUAAGAF AABiBQAAYwUAAGQFAAB9BQAAfgUAAMYFAADPBQAA0AUAANEFAAAMBgAADQYAAA4GAAAPBgAAEAYA ABEGAAC/BgAAwAYAAEYHAABVBwAAVgcAAFcHAACSBwAAkwcAAJQHAACVBwAAlgcAAJcHAAC8BwAA xgcAAMgHAADRBwAA0gcAANMHAAD6BwAACQgAABEIAAD47ufZ0Nm72bCrpqKmmqKmoo+aiJqm7ufZ 0Nm72bCrAIYA7ufZ0Nm72bCrAIYAhgCGAIYAAAAAAANvKAENMEoSADUIgVwIgW8oARUCCIEDagAA AAAGCAE1CIFVCAFcCIEPA2oAAAAANQiBVQgBXAiBBjUIgVwIgQAJNQiBXAiBbygBCENKFABhShQA ABVCKgFDShgAT0oDAFFKAwBwaAAAAAApA2oAAAAAQioBQ0oUAE9KAwBRSgMAVQgBbUgABG5IAARw aAAAAAB1CAERQioBT0oDAFFKAwBwaAAAAAAaA2oAAAAAQioBT0oDAFFKAwBVCAFwaAAAAAAADEIq CG8oAXBo////AAATMEoQADUIgUIqCFwIgXBo////AA01CIFDSiwAXAiBbygBADQABAAAEQQAACYE AABmBAAAZwQAAIwEAACnBAAAvgQAANMEAAAHBQAAKwUAAH8FAAD7AAAAAAAAAAAAAAAA8QAAAAAA AAAAAAAAAOgAAAAAAAAAAAAAAABnAAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAA AAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAWJAEXJAFJZgEAAAAClg8ABdYYCAEQAAgBEAAI ARAACAEQAAAAAAAAAAAACNYwAALx/yQf3x+AAgAACAEQAAgBEAAIARAACAEQAIAEcgAIARAACAEQ AAgBEAAIARAACdYEAAIAAhLWFAAAAP/AwMAAAAAAAAD/wMDAAAAAE9YwwMDAAAgBAADAwMAACAEA AMDAwAAIAQAAwMDAAAgBAAAAAAD/AAAAAAAAAP8AAAAAFPYCJxMVNgEa1gjAwMAAwMDAABvWCMDA wADAwMAAHNYIwMDAAMDAwAAd1gjAwMAAwMDAADTWBgABDwMPAGDWCgAAAP/AwMAAAABh9gMAAAkA AAMkAhYkAUlmAQAAAGEkAgoCABOkAAAUpAAAFiQBSWYBAAAAAAMPABSk8AAACwAEAACQDAAA/QAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAQAAQEBfwUAAMUFAADGBQAA 0AUAABAGAAARBgAARgcAAFYHAACWBwAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAADxAAAAAAAA AAAAAAAA6AAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAA AOgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfwAAFiQBFyQBSWYBAAAAApYPAAXWGAgBEAAIARAA CAEQAAgBEAAAAAAAAAAAAAjWMAAC8f/BHaMfgAbRHQgBEAAIARAACAEQAAgBEACABuIBCAEQAAgB EAAIARAACAEQAAnWBAACAAIS1hQAAAD/wMDAAAAAAAAA/8DAwAAAABPWMMDAwAAIAQAAwMDAAAgB AADAwMAACAEAAMDAwAAIAQAAAAAA/wAAAAAAAAD/AAAAABT2AgMTGtYIwMDAAMDAwAAb1gjAwMAA wMDAABzWCMDAwADAwMAAHdYIwMDAAMDAwAA01gYAAQ8DDwBg1goAAAD/wMDAAAAAYfYDAAAJAAAD JAIWJAFJZgEAAABhJAIKAgATpAAAFKQAABYkAUlmAQAAAAADDwAUpPAAAAiWBwAAlwcAANMHAAAi CAAAZQgAALQIAAAzCQAAowkAALQJAAD0CQAAfgAAAAAAAAAAAAAAAHoAAAAAAAAAAAAAAAB6AAAA AAAAAAAAAAAAegAAAAAAAAAAAAAAAHoAAAAAAAAAAAAAAAB6AAAAAAAAAAAAAAAAegAAAAAAAAAA AAAAAHAAAAAAAAAAAAAAAABnAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAMkAhYkAUlmAQAAAGEkAgoCABOkAAAUpAAAFiQBSWYB AAAAAAMPABSk8AAAgAAAFiQBFyQBSWYBAAAAApYPAAXWGAgBEAAIARAACAEQAAgBEAAAAAAAAAAA AAjWMAAC8f/VHoEggAIAAAgBEAAIARAACAEQAAgBEACAAgAACAEQAAgBEAAIARAACAEQAAnWBAAC AAIS1hQAAAD/wMDAAAAAAAAA/8DAwAAAABPWMMDAwAAIAQAAwMDAAAgBAADAwMAACAEAAMDAwAAI AQAAAAAA/wAAAAAAAAD/AAAAABT2AogTFTYBGtYIwMDAAMDAwAAb1gjAwMAAwMDAABzWCMDAwADA wMAAHdYIwMDAAMDAwAA01gYAAQ8DDwBg1goAAAD/wMDAAAAAYfYDAAAACREIAAAiCAAAPAgAADQJ AABICQAAcAkAAJAJAAChCQAAowkAAKwJAACzCQAAtAkAALUJAADwCQAA8QkAAPIJAADzCQAA9QkA ADYKAABHCgAASAoAAEkKAACECgAAhQoAAIYKAACHCgAAiAoAAIkKAAC0CgAAtQoAAMcKAADICgAA yQoAAAQLAAAFCwAABgsAAAcLAAAJCwAAEQsAABQLAAAdCwAARAsAAFQLAABVCwAAVgsAAFcLAACS CwAAkwsAAJQLAACVCwAAlwsAAJsLAACcCwAAnQsAADwMAACFDAAAhgwAAI0MAACODAAAjwwAAP0A /QD9AP0A8+fg0snStNKp/fPg0snStNKppAD95+DSydK00qkA/QD98+fg0snStNKpn/2fl/0A/QD9 AAAADzUIgTYIgVwIgV0IgW8oAQk1CIFcCIFvKAEIQ0oUAGFKFAAAFUIqAUNKGABPSgMAUUoDAHBo AAAAACkDagAAAABCKgFDShQAT0oDAFFKAwBVCAFtSAAEbkgABHBoAAAAAHUIARFCKgFPSgMAUUoD AHBoAAAAABoDagAAAABCKgFPSgMAUUoDAFUIAXBoAAAAAAAMQioIbygBcGj///8AABYwShAANQiB QioIXAiBbygBcGj///8AABMwShAANQiBQioIXAiBcGj///8AA28oAQA79AkAAPUJAAAPCgAAIQoA ADYKAABICgAAiAoAAH4AAAAAAAAAAAAAAAB6AAAAAAAAAAAAAAAAegAAAAAAAAAAAAAAAHoAAAAA AAAAAAAAAABwAAAAAAAAAAAAAAAAZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAJAAADJAIWJAFJZgEAAABhJAIKAgATpAAAFKQAABYkAUlmAQAA AAADDwAUpPAAAIAAABYkARckAUlmAQAAAAKWDwAF1hgIARAACAEQAAgBEAAIARAAAAAAAAAAAAAI 1jAAAvH/0x6BIIACAAAIARAACAEQAAgBEAAIARAAgAIAAAgBEAAIARAACAEQAAgBEAAJ1gQAAgAC EtYUAAAA/8DAwAAAAAAAAP/AwMAAAAAT1jDAwMAACAEAAMDAwAAIAQAAwMDAAAgBAADAwMAACAEA AAAAAP8AAAAAAAAA/wAAAAAU9gKIExU2ARrWCMDAwADAwMAAG9YIwMDAAMDAwAAc1gjAwMAAwMDA AB3WCMDAwADAwMAANNYGAAEPAw8AYNYKAAAA/8DAwAAAAGH2AwAAAAaICgAAiQoAALUKAADICgAA CAsAAH4AAAAAAAAAAAAAAAB6AAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAGcAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAkAAAMkAhYkAUlmAQAAAGEkAgoCABOkAAAUpAAAFiQBSWYBAAAA AAMPABSk8AAAgAAAFiQBFyQBSWYBAAAAApYPAAXWGAgBEAAIARAACAEQAAgBEAAAAAAAAAAAAAjW MAAC8f/UHoEggAIAAAgBEAAIARAACAEQAAgBEACAAgAACAEQAAgBEAAIARAACAEQAAnWBAACAAIS 1hQAAAD/wMDAAAAAAAAA/8DAwAAAABPWMMDAwAAIAQAAwMDAAAgBAADAwMAACAEAAMDAwAAIAQAA AAAA/wAAAAAAAAD/AAAAABT2AogTFTYBGtYIwMDAAMDAwAAb1gjAwMAAwMDAABzWCMDAwADAwMAA HdYIwMDAAMDAwAA01gYAAQ8DDwBg1goAAAD/wMDAAAAAYfYDAAAABAgLAAAJCwAARAsAAFYLAACW CwAAfgAAAAAAAAAAAAAAAHoAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAZwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAACQAAAyQCFiQBSWYBAAAAYSQCCgIAE6QAABSkAAAWJAFJZgEAAAAA Aw8AFKTwAACAAAAWJAEXJAFJZgEAAAAClg8ABdYYCAEQAAgBEAAIARAACAEQAAAAAAAAAAAACNYw AALx/+AegSCAAgAACAEQAAgBEAAIARAACAEQAIACAAAIARAACAEQAAgBEAAIARAACdYEAAIAAhLW FAAAAP/AwMAAAAAAAAD/wMDAAAAAE9YwwMDAAAgBAADAwMAACAEAAMDAwAAIAQAAwMDAAAgBAAAA AAD/AAAAAAAAAP8AAAAAFPYCiBMVNgEa1gjAwMAAwMDAABvWCMDAwADAwMAAHNYIwMDAAMDAwAAd 1gjAwMAAwMDAADTWBgABDwMPAGDWCgAAAP/AwMAAAABh9gMAAAAElgsAAJcLAAACDAAAPAwAAIoM AACLDAAAjAwAAI0MAACODAAAjwwAAJAMAAB+AAAAAAAAAAAAAAAAegAAAAAAAAAAAAAAAHoAAAAA AAAAAAAAAAB6AAAAAAAAAAAAAAAAegAAAAAAAAAAAAAAAHgAAAAAAAAAAAAAAAB4AAAAAAAAAAAA AAAAeAAAAAAAAAAAAAAAAHgAAAAAAAAAAAAAAAB2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAEPAAAD DwAUpPAAAIAAABYkARckAUlmAQAAAAKWDwAF1hgIARAACAEQAAgBEAAIARAAAAAAAAAAAAAI1jAA AvH/6R6BIIACAAAIARAACAEQAAgBEAAIARAAgAIAAAgBEAAIARAACAEQAAgBEAAJ1gQAAgACEtYU AAAA/8DAwAAAAAAAAP/AwMAAAAAT1jDAwMAACAEAAMDAwAAIAQAAwMDAAAgBAADAwMAACAEAAAAA AP8AAAAAAAAA/wAAAAAU9gKIExU2ARrWCMDAwADAwMAAG9YIwMDAAMDAwAAc1gjAwMAAwMDAAB3W CMDAwADAwMAANNYGAAEPAw8AYNYKAAAA/8DAwAAAAGH2AwAAAAqPDAAAkAwAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATAAMZA4ATJQAgAfsIIuILDGQSGw CAcisAgHI5CgBSSQoAUlsAAAF7BTAxiw4AMMkKkBAG4e8P8CAAAqOy23Tu1bywbQXG/I4w3J/4lQ TkcNChoKAAAADUlIRFIAAAAKAAAACgEDAAAAt/xd/gAAAA5nSUZ4TkVUU0NBUEUyLjABAAAkTphQ AAAABlBMVEUAzDP///9ros1IAAAAAnRSTlP/AOW3MEoAAAABYktHRAH/Ai3eAAAABGdJRmcCAADI ozqGRAAAAAxjbVBQSkNtcDA3MTIAAAAHT223pQAAABpJREFUGNNj+H2A4TMYPQSjA2DU4MDQwAAE AOpVDKRhdiITAAACIG1zT0dNU09GRklDRTkuMEdJRjg5YQoACgCAAQAAzDP///8h/wtORVRTQ0FQ RTIuMAMBAAAAIfkECcgAAQAsAAAAAAoACgAAAhKMDacBuehWa29GaJWlePcNWgUAIfkECRQAAQAs AAAAAAoACgAAAhSMDae4B9kejGE6uSRGcFetXYlUAAAh+QQJFAABACwAAAAACgAKAAACFIwNp8uR DR5LUsWKbn3ROqdZlFEAACH5BAkUAAEALAAAAAAKAAoAAAIRjI+pCBvtGkygqiqZsSfv6xUAIfkE CRQAAQAsAAAAAAoACgAAAg6Mj6mrwOHcWyAiyTDVBQAh+QQJFAABACwAAAAACgAKAAACDIyPqcsM DcNL08VUAAAh+QQJFAABACwAAAAACgAKAAACCoyPqcvtr4CT8BQAIfkEBRQAAQAsAAAAAAoACgAA AgiMj6nL7Q9jKwAh+QQFFAABACwCAAcAAgACAAACA0QCBQAh+QQFFAABACwEAAQAAgADAAACA0Qe UAAh+QQFFAABACwEAAMABAAHAAACB0R+hqG6qQoAIfkEBRQAAQAsAQACAAcACAAAAgyMA6fLCGkg e2jJAwoAIfkEBRQAAQAsBQAAAAUACQAAAglEjpmmjdyAkQUAIfkEBRQAAQAsAQABAAkACQAAAg6M A6epxg1XfLKiCykABQAh+QQFFAABACwBAAEACAAJAAACDIxhqZvIDxlwgS7rCgA7QOYkTQAAAABJ RU5ErkJgggAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADrAAAARAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyC AKoAS6kLAgAAABcAAAAaAAAAbgBpAG4AYQBuAGkAMQA4ADIAMAAwADEAQAB5AGEAaABvAG8ALgBj AG8AbQAuAGgAawAAAODJ6nn5us4RjIIAqgBLqQtCAAAAbQBhAGkAbAB0AG8AOgBuAGkAbgBhAG4A aQAxADgAMgAwADAAMQBAAHkAYQBoAG8AbwAuAGMAbwBtAC4AaABrAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAATAAoAAQBpAA8AAwAAAAQAAAAAAEYAAEDx/wIA RgAMAAIAY2uHZQAACwAAAAMkAzEkAGEkAwAkAENKFQBLSAIAUEoEAF9IAQRhShgAbUgJBG5IBAhz SAkEdEgECAAAVAACQAEAIgBUAAwABAAHaJiYIAAyAAAAFgACAAMkABOkGAEUpIwAMSQBQCYBYSQA IwA1CIFCKgFDSiQAS0gAAE9KAwBRSgMAXAiBYUokAHBoAAAAAAAAAAAAAAAAAAAAAAAAABwAQUDy /6EAHAAMAAYA2J6ki7VrPYRXW1NPAAAAAAAAAAAAAAAAUABeQAEA8gBQAAwACABuZhqQIAAoAFcA ZQBiACkAAAATAA8AAyQAE6RkABSkyAAxJAFhJAAAGQBCKgFDShgAS0gAAE9KAwBRSgMAcGgAAAAA ABoAV0CiAAEBGgAMAAIAgYm5cAAABgA1CIFcCIEYAP5PogARARgADAAEAGwAMQAyADEAAAAAACQA VUCiACEBJAAMAAQAhY2nfv6UpWMAAAwAPioBQioCcGgAAP8AAAAAAJAIAAAEAAAmAAAAAP////8A AAAAEQAAACYAAABmAAAAZwAAAIwAAACnAAAAvgAAANMAAAAHAQAAKwEAAH8BAADFAQAAxgEAANAB AAAQAgAAEQIAAEYDAABWAwAAlgMAAJcDAADTAwAAIgQAAGUEAAC0BAAAMwUAAKMFAAC0BQAA9AUA APUFAAAPBgAAIQYAADYGAABIBgAAiAYAAIkGAAC1BgAAyAYAAAgHAAAJBwAARAcAAFYHAACWBwAA lwcAAAIIAAA8CAAAiggAAIsIAACMCAAAjQgAAI4IAACPCAAAkggAAJgAAAAPMAAAAAAAAACAAAAA gKkAAAACMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgKkAAAACMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgKkAAAACMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgKkAAAAC MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgKkAAAACMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgKkAAAACMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgKkAAAACMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkA AAAAMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgAAEAAARCAAAjwwAAJAMAAAIAAAADQAAABIAAAAABAAAfwUAAJYHAAD0CQAAiAoAAAgL AACWCwAAkAwAAAkAAAALAAAADAAAAA4AAAAPAAAAEAAAABEAAAAABAAAkAwAAAoAAAAmAAAAYgAA AGQAAAAzAQAAYwEAAH0BAADQAQAADAIAAA4CAABWAwAAkgMAAJQDAAC0BQAA8AUAAPIFAABIBgAA hAYAAIYGAADIBgAABAcAAAYHAABWBwAAkgcAAJQHAACQCAAAE1h0/xWME1gU/xWAE1h0/xWME1h0 /xWME1h0/xWME1h0/xWME1h0/xWME1h0/xWMDwAA8GwAAAAAAAbwGAAAAAIIAAACAAAAEAAAAAEA AAABAAAAEQAAAB8AAfAsAAAAYgAH8CQAAAAGBio7LbdO7VvLBtBcb8jjDcn/AAcDAAAHAAAAMiYA AAAAogFAAB7xEAAAAP//AAAAAP8AgICAAPcAABAADwAC8IwIAAAQAAjwCAAAAAgAAAAQBAAADwAD 8CoIAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATw GgEAALIECvAIAAAAAgQAAAAKAACjAAvw1gAAAH8AEAAQAARBAQAAAAXBbgAAAAYBAgAAAP8BAAAI AIHDCAAAAILDJAAAAIQDAAAAAIYDAAAAAL8DCAAIAGgAdAB0AHAAOgAvAC8AdwB3AHcALgB0AHIA YQBuAHMAbABhAHQAbwByAHMAYwBhAGYAZQAuAGMAbwBtAC8AYwBhAGYAZQAvAGkAbQBhAGcAZQBz AC8ASQBuAGQAZQB4AFUAcAAuAGcAaQBmAAAAVABvAHAAAADQyep5+brOEYyCAKoAS6kLAgAAAAgA AAAEAAAAVABvAHAAAAAjACLxDAAAAJIDAwAAAL8DAAAAAgAAEPAEAAAABAAAAAAAEfAEAAAAAgAA AA8ABPAaAQAAsgQK8AgAAAAGBAAAAAoAAKMAC/DWAAAAfwAQABAABEEBAAAABcFuAAAABgECAAAA /wEAAAgAgcMIAAAAgsMkAAAAhAMAAAAAhgMAAAAAvwMIAAgAaAB0AHQAcAA6AC8ALwB3AHcAdwAu AHQAcgBhAG4AcwBsAGEAdABvAHIAcwBjAGEAZgBlAC4AYwBvAG0ALwBjAGEAZgBlAC8AaQBtAGEA ZwBlAHMALwBJAG4AZABlAHgAVQBwAC4AZwBpAGYAAABUAG8AcAAAANDJ6nn5us4RjIIAqgBLqQsC AAAACAAAAAQAAABUAG8AcAAAACMAIvEMAAAAkgMDAAAAvwMAAAACAAAQ8AQAAAACAAAAAAAR8AQA AAAEAAAADwAE8BoBAACyBArwCAAAAAcEAAAACgAAowAL8NYAAAB/ABAAEAAEQQEAAAAFwW4AAAAG AQIAAAD/AQAACACBwwgAAACCwyQAAACEAwAAAACGAwAAAAC/AwgACABoAHQAdABwADoALwAvAHcA dwB3AC4AdAByAGEAbgBzAGwAYQB0AG8AcgBzAGMAYQBmAGUALgBjAG8AbQAvAGMAYQBmAGUALwBp AG0AYQBnAGUAcwAvAEkAbgBkAGUAeABVAHAALgBnAGkAZgAAAFQAbwBwAAAA0Mnqefm6zhGMggCq AEupCwIAAAAIAAAABAAAAFQAbwBwAAAAIwAi8QwAAACSAwMAAAC/AwAAAAIAABDwBAAAAAEAAAAA ABHwBAAAAAMAAAAPAATwJgEAALIECvAIAAAACwQAAAAKAACjAAvw4gAAAH8AEAAQAARBAQAAAAXB bgAAAAYBAgAAAP8BAAAIAIHDCAAAAILDMAAAAIQDAAAAAIYDAAAAAL8DCAAIAGgAdAB0AHAAOgAv AC8AdwB3AHcALgB0AHIAYQBuAHMAbABhAHQAbwByAHMAYwBhAGYAZQAuAGMAbwBtAC8AYwBhAGYA ZQAvAGkAbQBhAGcAZQBzAC8ASQBuAGQAZQB4AFUAcAAuAGcAaQBmAAAAVABvAHAAAADQyep5+brO EYyCAKoAS6kLAgAAABgAAAAEAAAAQwBWACAAAAAEAAAAVABvAHAAAAAjACLxDAAAAJIDAwAAAL8D AAAAAgAAEPAEAAAAAAAAAAAAEfAEAAAABAAAAA8ABPAaAQAAsgQK8AgAAAAMBAAAAAoAAKMAC/DW AAAAfwAQABAABEEBAAAABcFuAAAABgECAAAA/wEAAAgAgcMIAAAAgsMkAAAAhAMAAAAAhgMAAAAA vwMIAAgAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHQAcgBhAG4AcwBsAGEAdABvAHIAcwBjAGEAZgBl AC4AYwBvAG0ALwBjAGEAZgBlAC8AaQBtAGEAZwBlAHMALwBJAG4AZABlAHgAVQBwAC4AZwBpAGYA AABUAG8AcAAAANDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAAQAAABUAG8AcAAAACMAIvEMAAAAkgMD AAAAvwMAAAACAAAQ8AQAAAADAAAAAAAR8AQAAAAFAAAADwAE8BoBAACyBArwCAAAAA8EAAAACgAA owAL8NYAAAB/ABAAEAAEQQEAAAAFwW4AAAAGAQIAAAD/AQAACACBwwgAAACCwyQAAACEAwAAAACG AwAAAAC/AwgACABoAHQAdABwADoALwAvAHcAdwB3AC4AdAByAGEAbgBzAGwAYQB0AG8AcgBzAGMA YQBmAGUALgBjAG8AbQAvAGMAYQBmAGUALwBpAG0AYQBnAGUAcwAvAEkAbgBkAGUAeABVAHAALgBn AGkAZgAAAFQAbwBwAAAA0Mnqefm6zhGMggCqAEupCwIAAAAIAAAABAAAAFQAbwBwAAAAIwAi8QwA AACSAwMAAAC/AwAAAAIAABDwBAAAAAUAAAAAABHwBAAAAAQAAAAPAATwGgEAALIECvAIAAAAEAQA AAAKAACjAAvw1gAAAH8AEAAQAARBAQAAAAXBbgAAAAYBAgAAAP8BAAAIAIHDCAAAAILDJAAAAIQD AAAAAIYDAAAAAL8DCAAIAGgAdAB0AHAAOgAvAC8AdwB3AHcALgB0AHIAYQBuAHMAbABhAHQAbwBy AHMAYwBhAGYAZQAuAGMAbwBtAC8AYwBhAGYAZQAvAGkAbQBhAGcAZQBzAC8ASQBuAGQAZQB4AFUA cAAuAGcAaQBmAAAAVABvAHAAAADQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAEAAAAVABvAHAAAAAj ACLxDAAAAJIDAwAAAL8DAAAAAgAAEPAEAAAABgAAAAAAEfAEAAAAAwAAAA8ABPBCAAAAEgAK8AgA AAABBAAAAA4AAFMAC/AeAAAAvwEAABAAywEAAAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR8AQAAAAB AAAAYwAAAA0CAACTAwAA8QUAAIUGAAAFBwAAkwcAAJAIAAALBAAAl9r//+Hd//8t2///d97//1QA AAAAAAcEAACX2v//4d3//y3b//933v//VAAAAAAABgQAAJfa///h3f//Ldv//3fe//9UAAAAAAAM BAAAR9v//z3o///d2///0+j//1QAAAAAAAIEAABH2///Pej//93b///T6P//VAAAAAAADwQAAEfb //896P//3dv//9Po//9UAAAAAAAQBAAAR9v//z3o///d2///0+j//1QAAAAAAP//AgAAAAwAXwBI AGwAdAA3ADMAOQA1ADQANwA5ADIADABfAEgAbAB0ADcAMwA5ADUANAA3ADkAMwARAAAAEQAAAJII AAAAAABAAQAAQGcAAABnAAAAkggAAAAAAABtAAAAdAAAAIQAAACLAAAAhQEAAJABAACSAQAAmgEA AKIBAACrAQAA0wMAANkDAAAJBAAAEAQAABIEAAAaBAAA6wQAAPMEAAD0BAAA+QQAABoFAAAhBQAA JAUAADIFAABzBQAAewUAAJEFAACZBQAA8QcAAPgHAAAgCAAAJwgAAJIIAAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAAAAAA cQAAAHQAAACCAQAAhAEAAKsDAAC0AwAADAQAABAEAAAiBAAALQQAALsEAADBBAAAQAUAAEsFAAAJ BwAAEwcAAMMHAADTBwAAAggAAAQIAACBCAAAiQgAAJIIAAAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAAAAAABEAAAC+AAAA0gAAAAcBAAArAQAAIQYAADYGAACS CAAABQAHAAUABwAFAAcABQAHAP//FAAAAAIAaAB6ADwAQwA6AFwARABvAGMAdQBtAGUAbgB0AHMA IABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAE4AaQAgAEQAdQBhAG4AXABMaGKXXABDAFYAKABu AGkAbgBhACAALAAgAHQAZQBhAGMAaABlAHIAIAApAC4AZABvAGMAAgBoAHoAPABDADoAXABEAG8A YwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBlAHQAdABpAG4AZwBzAFwATgBpACAARAB1AGEAbgBc AExoYpdcAEMAVgAoAG4AaQBuAGEAIAAsACAAdABlAGEAYwBoAGUAcgAgACkALgBkAG8AYwACAGgA egA8AEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABO AGkAIABEAHUAYQBuAFwATGhil1wAQwBWACgAbgBpAG4AYQAgACwAIAB0AGUAYQBjAGgAZQByACAA KQAuAGQAbwBjAAIAaAB6ADwAQwA6AFwARABvAGMAdQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0 AHQAaQBuAGcAcwBcAE4AaQAgAEQAdQBhAG4AXABMaGKXXABDAFYAKABuAGkAbgBhACAALAAgAHQA ZQBhAGMAaABlAHIAIAApAC4AZABvAGMAAgBoAHoAPABDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAg AGEAbgBkACAAUwBlAHQAdABpAG4AZwBzAFwATgBpACAARAB1AGEAbgBcAExoYpdcAEMAVgAoAG4A aQBuAGEAIAAsACAAdABlAGEAYwBoAGUAcgAgACkALgBkAG8AYwACAGgAegA8AEMAOgBcAEQAbwBj AHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABOAGkAIABEAHUAYQBuAFwA TGhil1wAQwBWACgAbgBpAG4AYQAgACwAIAB0AGUAYQBjAGgAZQByACAAKQAuAGQAbwBjAAIAaAB6 ADwAQwA6AFwARABvAGMAdQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAE4A aQAgAEQAdQBhAG4AXABMaGKXXABDAFYAKABuAGkAbgBhACAALAAgAHQAZQBhAGMAaABlAHIAIAAp AC4AZABvAGMAAgBoAHoAPABDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBlAHQA dABpAG4AZwBzAFwATgBpACAARAB1AGEAbgBcAExoYpdcAEMAVgAoAG4AaQBuAGEAIAAsACAAdABl AGEAYwBoAGUAcgAgACkALgBkAG8AYwACAGgAegA8AEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAA YQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABOAGkAIABEAHUAYQBuAFwATGhil1wAQwBWACgAbgBp AG4AYQAgACwAIAB0AGUAYQBjAGgAZQByACAAKQAuAGQAbwBjAAIAaAB6ADwAQwA6AFwARABvAGMA dQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAE4AaQAgAEQAdQBhAG4AXABM aGKXXABDAFYAKABuAGkAbgBhACAALAAgAHQAZQBhAGMAaABlAHIAIAApAC4AZABvAGMAAQBNfTZT dpfeif8P/w//D/8P/w//D/8P/w//DxAAAQAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E0AIR hDD9FcYFAAHQAgZehNACYIQw/W8oAQMAKAAAACkAAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgA AA+ESAMRhFz+FcYFAAFIAwZehEgDYIRc/gIAAQApAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAY AAAPhOwEEYRc/hXGBQAB7AQGXoTsBGCEXP4CAAIALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAA GAAAD4SQBhGEXP4VxgUAAZAGBl6EkAZghFz+AgADAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAA ABgAAA+ENAgRhFz+FcYFAAE0CAZehDQIYIRc/gIABAApAAEAAAACggEAAAAAAAAAAAAAAAAAAAAA AAAYAAAPhNgJEYRc/hXGBQAB2AkGXoTYCWCEXP4CAAUALgABAAAAAIABAAAAAAAAAAAAAAAAAAAA AAAAGAAAD4R8CxGEXP4VxgUAAXwLBl6EfAtghFz+AgAGAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAA AAAAABgAAA+EIA0RhFz+FcYFAAEgDQZehCANYIRc/gIABwApAAEAAAACggEAAAAAAAAAAAAAAAAA AAAAAAAYAAAPhMQOEYRc/hXGBQABxA4GXoTEDmCEXP4CAAgALgABAAAATX02UwAAAAAAAAAAAAAA AP///////wEAAAAAAP//AQAAABIAHv7gRRkACQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkE AAAAABEAAAAmAAAAZgAAAGcAAADGAQAA0AEAABACAAARAgAARgMAAFYDAACWAwAAlwMAAKMFAAC0 BQAA9AUAAPUFAAA2BgAASAYAAIgGAACJBgAAtQYAAMgGAAAIBwAACQcAAEQHAABWBwAAlgcAAJcH AACSCAAAAAAAAAgAAAACAQAAIgEAALYBAAAIAAAAAgEAACIBAAC2AQAACAAAAAIBAAAiAQAAtgEA AAgAAAACAQAAIgEAALYBAAAIAAAAAgEAACIBAAC2AQAACAAAAAIBAAAiAQAAtgEAAAgAAAACAQAA IgEAALYBAAD/QAGAAQDEAQAAxAEAAHAoxwFHAEcAxAEAAAAAAAB/AQAAAAAAAAIQAAAAAAAAAJAI AABAAAAIAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAAAAD/ /wAAAgD//wAAAAD//wAAAgD//wAAAAAFAAAARxaQAQAAAgIGAwUEBQIDBId6ACAAAACACAAAAAAA AAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIF BwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBId6 ACAAAACACAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAADcmkAEAAAILBgQDBQQEAgSHAgAgAAAA AAAAAAAAAAAAnwEAAAAAAABWAGUAcgBkAGEAbgBhAAAAOwaQAYYDAgEGAAMBAQEBAQMAAAAAAA4I EAAAAAAAAAABAAQAAAAAAItbU08AAFMAaQBtAFMAdQBuAAAAIAAEAHEIiBgAAKQBqANoAQAAAAAy oovGMqKLxjopikYCAAEAAAA9AQAADwcAAAEAAwAAAAQAAxAPAAAAAAAAAAAAAAABAAEAAAABAAAA AAAAAFkCAAAAAAAAAwAtABMAIQApACwALgA6ADsAPwBdAH0AqAC3AMcCyQIVIBYgGSAdICYgNiIB MAIwAzAFMAkwCzANMA8wETAVMBcwAf8C/wf/Cf8M/w7/Gv8b/x//Pf9A/1z/Xf9e/+D/AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAWwB7ALcA GCAcIAgwCjAMMA4wEDAUMBYwCP8O/zv/W//h/+X/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgHoAW0AJwAgoAyAAAAAAAAAAAA AAAAAAAAqwgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGYAAAAA AAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAACTKDUQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP//EgAAAAAAAAADAEMAVgAgAAAAAAAAAAYAaABpAGUAcwB1AG4AAgBoAHoAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAA AAB0AQAAEgAAAAEAAACYAAAAAgAAAKAAAAADAAAArAAAAAQAAAC4AAAABQAAAMgAAAAGAAAA1AAA AAcAAADgAAAACAAAAPAAAAAJAAAA/AAAABIAAAAIAQAACgAAACQBAAALAAAAMAEAAAwAAAA8AQAA DQAAAEgBAAAOAAAAVAEAAA8AAABcAQAAEAAAAGQBAAATAAAAbAEAAAIAAACoAwAAHgAAAAQAAABD ViAAHgAAAAEAAAAAViAAHgAAAAcAAABoaWVzdW4AAB4AAAABAAAAAGllcx4AAAABAAAAAGllcx4A AAAHAAAATm9ybWFsAAAeAAAAAwAAAGh6AG0eAAAAAgAAADIAAG0eAAAAEwAAAE1pY3Jvc29mdCBX b3JkIDkuMAAAQAAAAABGwyMAAAAAQAAAAAC89NRUqsQBQAAAAACs7NyazsQBQAAAAACs7NyazsQB AwAAAAEAAAADAAAAPQEAAAMAAAAPBwAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1Zwu GxCTlwgAKyz5rjQBAADwAAAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAgAAAAAYAAACIAAAAEQAA AJAAAAAXAAAAmAAAAAsAAACgAAAAEAAAAKgAAAATAAAAsAAAABYAAAC4AAAADQAAAMAAAAAMAAAA 0AAAAAIAAACoAwAAHgAAAAcAAABoaWVzdW4AAAMAAAAPAAAAAwAAAAMAAAADAAAAqwgAAAMAAAD8 CgkACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAAQAAABDViAADBAAAAIA AAAeAAAABQAAAMzixL8AAwAAAAEAAAAAAACACgAAAwAAAAAAAAAgAAAAAQAAADgAAAACAAAAQAAA AAEAAAACAAAADAAAAF9QSURfSExJTktTAAIAAACoAwAAQQAAADgKAACEAAAAAwAAAD0AfwADAAAA FQAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAJQAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgB0AHIAYQBu AHMAbABhAHQAbwByAHMAYwBhAGYAZQAuAGMAbwBtAC8AYwBhAGYAZQAvAAAAAAAfAAAABAAAAFQA bwBwAAAAAwAAAD0AfwADAAAAEgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAJQAAAGgAdAB0AHAAOgAv AC8AdwB3AHcALgB0AHIAYQBuAHMAbABhAHQAbwByAHMAYwBhAGYAZQAuAGMAbwBtAC8AYwBhAGYA ZQAvAAAAAAAfAAAABAAAAFQAbwBwAAAAAwAAAD0AfwADAAAADwAAAAMAAAAAAAAAAwAAAAUAAAAf AAAAJQAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgB0AHIAYQBuAHMAbABhAHQAbwByAHMAYwBhAGYA ZQAuAGMAbwBtAC8AYwBhAGYAZQAvAAAAAAAfAAAABAAAAFQAbwBwAAAAAwAAAD0AfwADAAAADAAA AAMAAAAAAAAAAwAAAAUAAAAfAAAAJQAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgB0AHIAYQBuAHMA bABhAHQAbwByAHMAYwBhAGYAZQAuAGMAbwBtAC8AYwBhAGYAZQAvAAAAAAAfAAAABAAAAFQAbwBw AAAAAwAAAD0AfwADAAAACQAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAJQAAAGgAdAB0AHAAOgAvAC8A dwB3AHcALgB0AHIAYQBuAHMAbABhAHQAbwByAHMAYwBhAGYAZQAuAGMAbwBtAC8AYwBhAGYAZQAv AAAAAAAfAAAABAAAAFQAbwBwAAAAAwAAAD0AfwADAAAABgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAA JQAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgB0AHIAYQBuAHMAbABhAHQAbwByAHMAYwBhAGYAZQAu AGMAbwBtAC8AYwBhAGYAZQAvAAAAAAAfAAAABAAAAFQAbwBwAAAAAwAAAAoAdQADAAAAAwAAAAMA AAAAAAAAAwAAAAUAAAAfAAAAIQAAAG0AYQBpAGwAdABvADoAbgBpAG4AYQBuAGkAMQA4ADIAMAAw ADEAQAB5AGEAaABvAG8ALgBjAG8AbQAuAGgAawAAAAAAHwAAAAEAAAAAAAAAAwAAAD0AfwADAAAA AAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAJQAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgB0AHIAYQBu AHMAbABhAHQAbwByAHMAYwBhAGYAZQAuAGMAbwBtAC8AYwBhAGYAZQAvAAAAAAAfAAAABAAAAFQA bwBwAAAAAwAAAHQAbwADAAAA/////wMAAAACBAAAAwAAAAQAAAAfAAAAAQAAAAAAAAAfAAAABAAA AFQAbwBwAAAAAwAAADIAbQADAAAA/////wMAAAACBAAAAwAAAAEAAAAfAAAANwAAAGgAdAB0AHAA OgAvAC8AdwB3AHcALgB0AHIAYQBuAHMAbABhAHQAbwByAHMAYwBhAGYAZQAuAGMAbwBtAC8AYwBh AGYAZQAvAGkAbQBhAGcAZQBzAC8ASQBuAGQAZQB4AFUAcAAuAGcAaQBmAAAAAAAfAAAAAQAAAAAA AAADAAAAdABvAAMAAAD/////AwAAAAYEAAADAAAABAAAAB8AAAABAAAAAAAAAB8AAAAEAAAAVABv AHAAAAADAAAAMgBtAAMAAAD/////AwAAAAYEAAADAAAAAQAAAB8AAAA3AAAAaAB0AHQAcAA6AC8A LwB3AHcAdwAuAHQAcgBhAG4AcwBsAGEAdABvAHIAcwBjAGEAZgBlAC4AYwBvAG0ALwBjAGEAZgBl AC8AaQBtAGEAZwBlAHMALwBJAG4AZABlAHgAVQBwAC4AZwBpAGYAAAAAAB8AAAABAAAAAAAAAAMA AAB0AG8AAwAAAP////8DAAAABwQAAAMAAAAEAAAAHwAAAAEAAAAAAAAAHwAAAAQAAABUAG8AcAAA AAMAAAAyAG0AAwAAAP////8DAAAABwQAAAMAAAABAAAAHwAAADcAAABoAHQAdABwADoALwAvAHcA dwB3AC4AdAByAGEAbgBzAGwAYQB0AG8AcgBzAGMAYQBmAGUALgBjAG8AbQAvAGMAYQBmAGUALwBp AG0AYQBnAGUAcwAvAEkAbgBkAGUAeABVAHAALgBnAGkAZgAAAAAAHwAAAAEAAAAAAAAAAwAAAHQA bwADAAAA/////wMAAAALBAAAAwAAAAQAAAAfAAAAAQAAAAAAAAAfAAAABAAAAFQAbwBwAAAAAwAA ADIAbQADAAAA/////wMAAAALBAAAAwAAAAEAAAAfAAAANwAAAGgAdAB0AHAAOgAvAC8AdwB3AHcA LgB0AHIAYQBuAHMAbABhAHQAbwByAHMAYwBhAGYAZQAuAGMAbwBtAC8AYwBhAGYAZQAvAGkAbQBh AGcAZQBzAC8ASQBuAGQAZQB4AFUAcAAuAGcAaQBmAAAAAAAfAAAAAQAAAAAAAAADAAAAdABvAAMA AAD/////AwAAAAwEAAADAAAABAAAAB8AAAABAAAAAAAAAB8AAAAEAAAAVABvAHAAAAADAAAAMgBt AAMAAAD/////AwAAAAwEAAADAAAAAQAAAB8AAAA3AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHQA cgBhAG4AcwBsAGEAdABvAHIAcwBjAGEAZgBlAC4AYwBvAG0ALwBjAGEAZgBlAC8AaQBtAGEAZwBl AHMALwBJAG4AZABlAHgAVQBwAC4AZwBpAGYAAAAAAB8AAAABAAAAAAAAAAMAAAB0AG8AAwAAAP// //8DAAAADwQAAAMAAAAEAAAAHwAAAAEAAAAAAAAAHwAAAAQAAABUAG8AcAAAAAMAAAAyAG0AAwAA AP////8DAAAADwQAAAMAAAABAAAAHwAAADcAAABoAHQAdABwADoALwAvAHcAdwB3AC4AdAByAGEA bgBzAGwAYQB0AG8AcgBzAGMAYQBmAGUALgBjAG8AbQAvAGMAYQBmAGUALwBpAG0AYQBnAGUAcwAv AEkAbgBkAGUAeABVAHAALgBnAGkAZgAAAAAAHwAAAAEAAAAAAAAAAwAAAHQAbwADAAAA/////wMA AAAQBAAAAwAAAAQAAAAfAAAAAQAAAAAAAAAfAAAABAAAAFQAbwBwAAAAAwAAADIAbQADAAAA//// /wMAAAAQBAAAAwAAAAEAAAAfAAAANwAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgB0AHIAYQBuAHMA bABhAHQAbwByAHMAYwBhAGYAZQAuAGMAbwBtAC8AYwBhAGYAZQAvAGkAbQBhAGcAZQBzAC8ASQBu AGQAZQB4AFUAcAAuAGcAaQBmAAAAAAAfAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAC AAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAA AAARAAAAEgAAABMAAAAUAAAA/v///xYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAD+////HgAA AB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAA /v///y4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAD+////NgAAADcAAAA4AAAAOQAAADoAAAA7 AAAAPAAAAP7////9////PwAAAP7////+/////v////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////UgBvAG8A dAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAoAtVAZvOxAFBAAAA gAAAAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAACgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABUAAAAAEAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIAAQAAAP//////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHQAAAFsfAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBu AHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEGAAAABQAAAP// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOSkAAAAAAAAFAFMAdQBt AG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA KAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0AAAAA EAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA bwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAANQAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgECAAAABwAAAP////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZgAAAAAAAABPAGIAagBlAGMAdABQAG8AbwBsAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgABAP////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAoAtVAZvOxAGgC1UBm87EAQAAAAAAAAAAAAAAAAEAAAD+//// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////AQD+/wMKAAD/ ////BgkCAAAAAADAAAAAAAAARhQAAABNaWNyb3NvZnQgV29yZCDOxLW1AAoAAABNU1dvcmREb2MA EAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --=_NextPart_2rfkindysadvnqw3nerasdf-- From bulletin@staffadministrator.com Thu Nov 25 02:41:06 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 CAA08976; Thu, 25 Nov 2004 02:41:06 -0500 (EST) Received: from sc3-24.217.132.172.charter-stl.com ([24.217.132.172]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CXEJY-0003Q1-ES; Thu, 25 Nov 2004 02:45:17 -0500 Received: from nq.ky48bsi.com [70.94.252.54] by sc3-24.217.132.172.charter-stl.com with SMTP; Thu, 25 Nov 2004 07:41:43 +0000 Message-ID: From: "Administrator" To: aaa-archive@ietf.org Subject: ADV: Staff Announcement Date: Thu, 25 Nov 04 07:41:43 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: QUALCOMM Windows Eudora Version 5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="72_.5D4F8_E3C_" X-Spam-Score: 21.1 (+++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d This is a multi-part message in MIME format. --72_.5D4F8_E3C_ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations: Members and Staff You Must Respond By 5 P.M. Monday, November 29, 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 Nonprofit Members and Staff who respond to this message before 5 P.M., Monday, November 29, 2004. All desktop computers are brand-new packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2005 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktops with the latest technology at an amazing price to all who call: 1-800-795-8466 by 5 P.M. Monday, November 29, 2004 The fast and powerful AT-3200 series Desktop features: * IBM 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 * Next Generation 2005 Technology * Premium video and sound -- For enhanced colors and graphics * 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 $499 ........................................ Your Cost $227 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-795-8466 by 5 P.M. Monday, November 29, 2004. and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. 6. Ask for Department C. Call Avtech Direct 1-800-795-8466 before 5 P.M. Monday, November 29, 2004 Visit our website at http://www.avtechcomputers.com If you wish to unsubscribe from this list, please go to http://www.avtechcomputers.com/announcements.asp Avtech Direct 22647 Ventura Blvd. Suite 374 Woodland Hills, CA 91364 --72_.5D4F8_E3C_-- From owner-aaa-wg@merit.edu Thu Nov 25 08:38:17 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11376 for ; Thu, 25 Nov 2004 08:38:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 17AFF912EC; Thu, 25 Nov 2004 08:38:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD0A2912E9; Thu, 25 Nov 2004 08:38:10 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4B992912EF for ; Thu, 25 Nov 2004 08:38:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D10F58AED; Thu, 25 Nov 2004 08:38:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id EE86E58A91 for ; Thu, 25 Nov 2004 08:38:07 -0500 (EST) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAPDc3S25318; Thu, 25 Nov 2004 15:38:03 +0200 (EET) X-Scanned: Thu, 25 Nov 2004 15:36:42 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iAPDagvn027941; Thu, 25 Nov 2004 15:36:42 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 001O4H2x; Thu, 25 Nov 2004 15:33:30 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAPDXGa19468; Thu, 25 Nov 2004 15:33:16 +0200 (EET) Received: from [172.21.38.233] ([172.21.38.233]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Nov 2004 15:33:15 +0200 Message-ID: <41A5DF1C.5030501@nokia.com> Date: Thu, 25 Nov 2004 15:33:16 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Jari Arkko Cc: "Beck01, Wolfgang" , AAA mailing list , radiusext@ops.ietf.org Subject: Re: [AAA-WG]: Reconciling Radius/Diameter SIP application References: <41936F4C.5080201@nokia.com> <41A48DF7.6090901@kolumbus.fi> <41A4991F.10309@nokia.com> <41A4D9CD.1010501@kolumbus.fi> In-Reply-To: <41A4D9CD.1010501@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Nov 2004 13:33:15.0724 (UTC) FILETIME=[515E58C0:01C4D2F3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jari Arkko wrote: > This sounds reasonable, and my original worry turned out > to be a non-issue. (I worried that this might somehow > limit what the user's realm might be. But the client's > header includes both the username, which might of the > form jari@domain, and the challenging proxy's realm. > Only the latter is used in matching what gets sent to > the AAA server. In conclusion I could be jari@domain1 > when traversing through three proxies that challenge > me using realms domain2, domain3, and domain4, and > a single AAA server could handle all of this.) > > --Jari Exactly, that is the scenario that we want to enable. - Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Thu Nov 25 08:38:57 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11456 for ; Thu, 25 Nov 2004 08:38:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 23514912E9; Thu, 25 Nov 2004 08:38:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E49B4912ED; Thu, 25 Nov 2004 08:38:53 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 79B24912E9 for ; Thu, 25 Nov 2004 08:38:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 19C6458AEE; Thu, 25 Nov 2004 08:38:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 2D4C258A91 for ; Thu, 25 Nov 2004 08:38:50 -0500 (EST) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAPDcgF22766; Thu, 25 Nov 2004 15:38:43 +0200 (EET) X-Scanned: Thu, 25 Nov 2004 15:34:32 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iAPDYWiI008325; Thu, 25 Nov 2004 15:34:32 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00hLlyXp; Thu, 25 Nov 2004 15:34:30 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAPDYPS16814; Thu, 25 Nov 2004 15:34:25 +0200 (EET) Received: from [172.21.38.233] ([172.21.38.233]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Nov 2004 15:34:15 +0200 Message-ID: <41A5DF58.4000500@nokia.com> Date: Thu, 25 Nov 2004 15:34:16 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Avi Lior Cc: "'Jari Arkko'" , "Beck01, Wolfgang" , AAA mailing list , radiusext@ops.ietf.org Subject: Re: [AAA-WG]: Reconciling Radius/Diameter SIP application References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Nov 2004 13:34:15.0553 (UTC) FILETIME=[75078710:01C4D2F3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Avi: I agree with you, and I think we all understand that for this issue option b is the correct one. - Miguel Avi Lior wrote: > Hi, > > Again I think that only option b is the valid one. Unless I am missing > something, I think a Proxy must be able to identify the the > Proxy-Authorization that is associated with it. From RFC 2616: > > "When multiple proxies are used in a chain, the > Proxy-Authorization header field is consumed by the first outbound > proxy that was expecting to receive credentials. A proxy MAY relay > the credentials from the client request to the next proxy if that is > the mechanism by which the proxies cooperatively authenticate a given > request." > > Therefore you would think that a particular proxy would extract the > credentials from its headers and those would be the only ones that are sent > to the AAA infrastructure. > > And this also implies that the Proxy has a way to identify the > Proxy-Authroization header. > > Is this right? > > >>-----Original Message----- >>From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] >>Sent: Wednesday, November 24, 2004 1:58 PM >>To: Miguel Garcia >>Cc: Beck01, Wolfgang; AAA mailing list; radiusext@ops.ietf.org >>Subject: Re: [AAA-WG]: Reconciling Radius/Diameter SIP application >> >> >>Miguel Garcia wrote: >> >> >>>In HTTP there is typically a single Proxy-Aut* header, due to that >>>typically there is a single proxy sitting between the >> >>client and the >> >>>server. >>> >>>In SIP things get a bit more complicated, since it is common that a >>>SIP >>>request traverses several proxies, where theoretically each >> >>proxy could >> >>>demand credentials. It is also valid that each SIP proxy requests >>>credentials for the same or different realms than other SIP proxies. >>> >>>In other words, a SIP proxy can receive a SIP request that contain >>>several Proxy-Authorization header fieldss. Each header field will >>>contain the credentials for a particular realm. >>> >>>So let's assume that one of this proxies receives a request that >>>contains several Proxy-Authorization headers. Which one >> >>should the SIP >> >>>proxy put into the Radius/Diameter message and send it to the >>>Radius/Diameter server? >> >>Thanks for the explanation. The situation is clearer to me >>now. >> >> >>>a) Put blindly everything, I mean, all the Proxy-Authorization >>>headers. >>>Repeat attributes (Radius will give us a problem since >> >>attributes are >> >>>not grouped). >> >>I see the problem. >> >> >>>b) Extract the credentials that are of interested (according to the >>>realm) of the SIP server and RADIUS/Diameter server. This >> >>requires to >> >>>configure the SIP server with the realm it is serving, but >> >>it has some >> >>>benefits: first the Radius/Diameter message contains one set of >>>credentials (no poblems with Radius); second, it allows the >>>Radius/Diameter server to be authenticating several realms, >> >>so there is >> >>>no uncertainity because there is only one set of credentials in the >>>message. >>> >>>Therefore, we proposed to clarify all this issue and >> >>describe the need >> >>>to configure the SIP server with the realm it is serving. >> >>This allows >> >>>the server to select the appropriate credentials. >> >>This sounds reasonable, and my original worry turned out >>to be a non-issue. (I worried that this might somehow >>limit what the user's realm might be. But the client's >>header includes both the username, which might of the >>form jari@domain, and the challenging proxy's realm. >>Only the latter is used in matching what gets sent to >>the AAA server. In conclusion I could be jari@domain1 >>when traversing through three proxies that challenge >>me using realms domain2, domain3, and domain4, and >>a single AAA server could handle all of this.) >> >>--Jari >> -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Fri Nov 26 16:28:10 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24876 for ; Fri, 26 Nov 2004 16:28:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8C7769121B; Fri, 26 Nov 2004 16:28:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E2FB9126A; Fri, 26 Nov 2004 16:28:03 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 606529121B for ; Fri, 26 Nov 2004 16:28:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 46F0D58FC0; Fri, 26 Nov 2004 16:28:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by segue.merit.edu (Postfix) with ESMTP id DDB0058FB5 for ; Fri, 26 Nov 2004 16:28:01 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Fri, 26 Nov 2004 16:27:59 -0500 Message-ID: From: Avi Lior To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Question about peer state machine and R-Conn-CER Date: Fri, 26 Nov 2004 16:27:56 -0500 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 I have a question about the diameter peer state machine. From 3588: I-Open Send-Message I-Snd-Message I-Open I-Rcv-Message Process I-Open I-Rcv-DWR Process-DWR, I-Open I-Snd-DWA I-Rcv-DWA Process-DWA I-Open R-Conn-CER R-Reject I-Open Stop I-Snd-DPR Closing I-Rcv-DPR I-Snd-DPA, Closed I-Disc I-Peer-Disc I-Disc Closed I-Rcv-CER I-Snd-CEA I-Open I-Rcv-CEA Process-CEA I-Open R-Conn-CER is actually not the best naming for this event. This is because R-* is used to represent the responder and its not in this case. However, I think that R-Reject should be Reject or I-Reject in the above state. Note in the R-Open state when R-Conn-CER is received the Action is R-Reject. It should reamin R-Reject or be changed to Reject. Is this correct? ----------------------------- Avi Lior Bridgewater Systems Corp. Phone: 613.591.9104 x 6417 Cell : 613.297.2177 From owner-aaa-wg@merit.edu Fri Nov 26 16:43:37 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26271 for ; Fri, 26 Nov 2004 16:43:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A627E9126A; Fri, 26 Nov 2004 16:43:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D89C9126B; Fri, 26 Nov 2004 16:43:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 63C189126A for ; Fri, 26 Nov 2004 16:43:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3BD4458F01; Fri, 26 Nov 2004 16:43:30 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by segue.merit.edu (Postfix) with ESMTP id E3FA058F98 for ; Fri, 26 Nov 2004 16:43:29 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Fri, 26 Nov 2004 16:43:29 -0500 Message-ID: From: Avi Lior To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: DPA DPR processing and the state machine Date: Fri, 26 Nov 2004 16:43:23 -0500 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 The peer state machine I think is not right: I-Open Send-Message I-Snd-Message I-Open I-Rcv-Message Process I-Open I-Rcv-DWR Process-DWR, I-Open I-Snd-DWA I-Rcv-DWA Process-DWA I-Open R-Conn-CER R-Reject I-Open Stop I-Snd-DPR Closing I-Rcv-DPR I-Snd-DPA, Closed I-Disc Looking at state I-Open for example. When I-Rcv-DPR comes in we peform two actions: We send an answer I-Snd-DPA and disconnect the the transport. But 3588 says: (Section 5.4.2) Upon receipt of this message (DPA), the transport connection is shutdown. Also section 5.4 says: The receiver of the Disconnect-Peer-Answer initiates the transport disconnect. But in the above statemachine the sender of the DPA is disconnecting the transport. I belive that the correct behavior is: The receiver of the DPR simply replies with a DPA and remains in the same state. The original sender of the DPR upon receiving the DPA (he is is in the closing state) will disconnect the transport which will trigger then generate an Peer-Disc etc.. ----------------------------- Avi Lior Bridgewater Systems Corp. Phone: 613.591.9104 x 6417 Cell : 613.297.2177 From owner-aaa-wg@merit.edu Mon Nov 29 12:52:03 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14072 for ; Mon, 29 Nov 2004 12:52:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A2EDA91344; Mon, 29 Nov 2004 12:51:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1075291343; Mon, 29 Nov 2004 12:51:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CF30991339 for ; Mon, 29 Nov 2004 12:51:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id B825458620; Mon, 29 Nov 2004 12:51:04 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by segue.merit.edu (Postfix) with ESMTP id 698DC58627 for ; Mon, 29 Nov 2004 12:51:04 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Mon, 29 Nov 2004 12:51:03 -0500 Message-ID: From: Avi Lior To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Found bug in AAATRNS Date: Mon, 29 Nov 2004 12:51:03 -0500 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 I don't know if anyone reported this before. Certainly that code has never been tested. The following code will always endup in the "default" case. The pcb->status = DOWN should be follow the switch statement. OnConnectionDown(pcb) { pcb->status = DOWN; CloseConnection(); switch (pcb->status){ case OKAY: Failover(pcb); SetWatchdog(); break; case SUSPECT: case REOPEN: SetWatchdog(); break; default: error("Shouldn't be here!); break; } }