From nobody Fri Jul 1 06:03:01 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA38212D5EB for ; Fri, 1 Jul 2016 06:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZs7t78fIR5D for ; Fri, 1 Jul 2016 06:02:55 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C2C12D507 for ; Fri, 1 Jul 2016 06:02:55 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 0020E42FDB316; Fri, 1 Jul 2016 13:02:50 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u61D2rMS027590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Jul 2016 13:02:53 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u61D2ket014100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Jul 2016 15:02:53 +0200 Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.62]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 1 Jul 2016 15:01:48 +0200 From: "Gardella, Maryse (Nokia - FR)" To: Dave Dolson , "dime@ietf.org" Thread-Topic: [Dime] RFC 4006 bis - IMEI Thread-Index: AdHS8KRXUuwo33kKTp24S5zATa6CnwABTOGwAB1boCA= Date: Fri, 1 Jul 2016 13:01:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] RFC 4006 bis - IMEI X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 13:02:59 -0000 Hi Dave, Indeed it was not clear to me whether the current definition explicitly exc= luded the IMEI or not. I was wondering about the behavior of the client in case the Software Versi= on Number (SVN) is not available.=20 Otherwise if a new value is needed for this distinction, I would propose th= e User-Equipment-Info-Type AVP to be extended with IMEI value=20 BR Maryse -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson Sent: jeudi 30 juin 2016 19:39 To: Gardella, Maryse (Nokia - FR); dime@ietf.org Subject: Re: [Dime] RFC 4006 bis - IMEI Maryse, If I understand correctly, you are proposing overloading a type, distinguis= hing the types only by length. Is there precedent for the overloading you propose, such as a 3GPP standard= or de facto standard usage that you can cite? Otherwise, IANA may assign new values for new types, and we aren't short on= space: http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml#aaa-par= ameters-41 -Dave -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Gardella, Maryse (No= kia - FR) Sent: Thursday, June 30, 2016 12:59 PM To: dime@ietf.org Subject: [Dime] RFC 4006 bis - IMEI All, As part of the updates to RFC 4006 I propose to consider the IMEI also when= refering to IMEISV, otherwise it is not clear if User-Equipment-Info-Type = value O can be used for IMEI.=20 In section 8.50. User-Equipment-Info-Type AVP in RFC4006,the following is s= pecified:=20 =20 IMEISV 0 The identifier contains the International Mobile Equipment Identifier and Software Version in the international IMEISV format according to 3GPP TS 23.003 [3GPPIMEI]. Which I propose to be updated as follows: =20 IMEI(SV) 0 The identifier contains the International Mobile Equipment Identifier and Software Version in the international IMEISV format,=20 or the International Mobile Equipment Identifier in the international IMEI= format=20 according to 3GPP TS 23.003 [3GPPIMEI].=20 Differentiation between IMEI (15 digits) and IMEISV (16 digits) is based on= AVP length, would this work? BR Maryse _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Fri Jul 1 10:11:01 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CABB12D764 for ; Fri, 1 Jul 2016 10:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHNsvGduitka for ; Fri, 1 Jul 2016 10:10:58 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40B9512D76E for ; Fri, 1 Jul 2016 10:10:57 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0195.001; Fri, 1 Jul 2016 13:10:55 -0400 From: Dave Dolson To: "Gardella, Maryse (Nokia - FR)" , "dime@ietf.org" Thread-Topic: [Dime] RFC 4006 bis - IMEI Thread-Index: AQHR05jjZU3yr50ZFUWIQJ60KVePjqADyu+w Date: Fri, 1 Jul 2016 17:10:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] RFC 4006 bis - IMEI X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 17:11:00 -0000 Maryse, OK, I understand your question. Reading 3GPP 23.003, IMEI and IMEISV are clearly defined as different thing= s in sections 6.2.1 and 6.2.2. And RFC4006 specifically says IMEISV.=20 So I would say RFC4006 is not ambiguous.=20 Also, the most recent 3GPP 32.299 indicates "The used value is 0 for the in= ternational mobile equipment identifier and software version according to 3= GPP TS 23.003." It seems reasonable to extend to a Type 4 for IMEI, but there does not seem= to have been a need, or there would have been an IANA allocation (which do= es not require RFC revision). Perhaps you could explain the need to the group? -Dave -----Original Message----- From: Gardella, Maryse (Nokia - FR) [mailto:maryse.gardella@nokia.com]=20 Sent: Friday, July 01, 2016 9:02 AM To: Dave Dolson; dime@ietf.org Subject: RE: [Dime] RFC 4006 bis - IMEI Hi Dave, Indeed it was not clear to me whether the current definition explicitly exc= luded the IMEI or not. I was wondering about the behavior of the client in case the Software Versi= on Number (SVN) is not available.=20 Otherwise if a new value is needed for this distinction, I would propose th= e User-Equipment-Info-Type AVP to be extended with IMEI value=20 BR Maryse -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson Sent: jeudi 30 juin 2016 19:39 To: Gardella, Maryse (Nokia - FR); dime@ietf.org Subject: Re: [Dime] RFC 4006 bis - IMEI Maryse, If I understand correctly, you are proposing overloading a type, distinguis= hing the types only by length. Is there precedent for the overloading you propose, such as a 3GPP standard= or de facto standard usage that you can cite? Otherwise, IANA may assign new values for new types, and we aren't short on= space: http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml#aaa-par= ameters-41 -Dave -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Gardella, Maryse (No= kia - FR) Sent: Thursday, June 30, 2016 12:59 PM To: dime@ietf.org Subject: [Dime] RFC 4006 bis - IMEI All, As part of the updates to RFC 4006 I propose to consider the IMEI also when= refering to IMEISV, otherwise it is not clear if User-Equipment-Info-Type = value O can be used for IMEI.=20 In section 8.50. User-Equipment-Info-Type AVP in RFC4006,the following is s= pecified:=20 =20 IMEISV 0 The identifier contains the International Mobile Equipment Identifier and Software Version in the international IMEISV format according to 3GPP TS 23.003 [3GPPIMEI]. Which I propose to be updated as follows: =20 IMEI(SV) 0 The identifier contains the International Mobile Equipment Identifier and Software Version in the international IMEISV format,=20 or the International Mobile Equipment Identifier in the international IMEI= format=20 according to 3GPP TS 23.003 [3GPPIMEI].=20 Differentiation between IMEI (15 digits) and IMEISV (16 digits) is based on= AVP length, would this work? BR Maryse _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Sun Jul 3 02:00:30 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A3912B03F for ; Sun, 3 Jul 2016 02:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvXM0oR0Wk7T for ; Sun, 3 Jul 2016 02:00:26 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4986312B00E for ; Sun, 3 Jul 2016 02:00:26 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 3 Jul 2016 05:00:25 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0294.000; Sun, 3 Jul 2016 05:00:24 -0400 From: Yuval Lifshitz To: "Gardella, Maryse (Nokia - FR)" , "Naveen Kottapalli" Thread-Topic: [Dime] draft-bertz-dime-rfc4006bis - 3GPP specifications references Thread-Index: AdHMmcl9QU9rEm9ETbuYBI9wapFCOwGUVrkAAAfhngAAf3sWUA== Date: Sun, 3 Jul 2016 09:00:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.143.1] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_C43C255C7106314F8D13D03FA20CFE4930C878E2wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Cc: "dime@ietf.org" Subject: Re: [Dime] draft-bertz-dime-rfc4006bis - 3GPP specifications references X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 09:00:29 -0000 --_000_C43C255C7106314F8D13D03FA20CFE4930C878E2wtlexchp2sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWUgd2l0aCBib3RoIHBvaW50cy4gQXMgdGhlIHJlZmVyZW5jZSB0byAyMi4xMTUgaXMgdmVy eSBnZW5lcmljLg0KSW4gbW9zdCBjYXNlcywgdGhvdWdoLCB3ZSBzaG91bGQgcmVmZXJlbmNlIHNw ZWNpZmljIDNHUFAgdmVyc2lvbnMuIFVubGlrZSBpbiBJRVRGLCB0aGV5IGRvbuKAmXQgcmVuYW1l IHRoZSBkb2N1bWVudCwgZXZlbiBpZiBzdWJzdGFudGlhbGx5IG1vZGlmaWVkIGJldHdlZW4gdmVy c2lvbnMuLg0KDQpGcm9tOiBHYXJkZWxsYSwgTWFyeXNlIChOb2tpYSAtIEZSKSBbbWFpbHRvOm1h cnlzZS5nYXJkZWxsYUBub2tpYS5jb21dDQpTZW50OiBUaHVyc2RheSwgSnVuZSAzMCwgMjAxNiA3 OjA1IFBNDQpUbzogTmF2ZWVuIEtvdHRhcGFsbGk7IFl1dmFsIExpZnNoaXR6DQpDYzogZGltZUBp ZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBkcmFmdC1iZXJ0ei1kaW1lLXJmYzQwMDZiaXMg LSAzR1BQIHNwZWNpZmljYXRpb25zIHJlZmVyZW5jZXMNCg0KSGkgYWxsLA0KDQpJIHdvdWxkIGNv bmN1ciB3aXRoIHRoZSBzdWdnZXN0aW9uIHRvIGp1c3QgbWVudGlvbiB0aGUgM0dQUCBzcGVjIHcv byB2ZXJzaW9uIGZvciB0aGUgcmVmZXJlbmNlIHRvIDIyLjExNSwgaW4gY2FzZSBpdCBpcyBwcm9w b3NlZCB0byBzdGljayB0byB0aGlzIDNHUFAgcmVmZXJlbmNlOg0KDQpbM0dQUENIQVJHXSBpcyBy ZWZlcmVkLXRvIGZvciB0aGUgcmVxdWlyZW1lbnQg4oCcIHRoYXQgYW4gYXBwbGljYXRpb24gbXVz dCBiZSBhYmxlIHRvIHJhdGUgc2VydmljZSBpbmZvcm1hdGlvbiBpbiByZWFsLXRpbWUu4oCdICBh cyBhbiBleGFtcGxlLCB3aGljaCByZW1haW5lZCBhcHBsaWNhYmxlIChhbHRob3VnaCBJIGNvdWxk IG5vdCBmaW5kIHRoZSBleGFjdCBzdGF0ZW1lbnQgaW4gdGhpcyB2NS4yLjAgcmVmZXJlbmNlZCB2 ZXJzaW9uKSB0byBzdWJzZXF1ZW50IHZlcnNpb25zIG9mIDIyLjExNSwgYW5kIHdlIGNvdWxkIGV4 cGVjdCB0aGlzIHRvIGJlIHN0aWxsIGFwcGxpY2FibGUgaW4gdGhlIGZ1dHVyZSB2ZXJzaW9ucyBz aW5jZSBpdCBpcyBnZW5lcmljIGVub3VnaC4NCg0KUmVnYXJkaW5nIHRoZSByZWZlcmVuY2UgdG8g WzNHUFBJTUVJXToNClRoZSBzdHJ1Y3R1cmUgb2YgSU1FSVNWIGRpZG4ndCBjaGFuZ2UgYmV0d2Vl biByZWxlYXNlIDUgYW5kIDEzLCBhbmQgd2lsbCBsaWtlbHkgbm90IGNoYW5nZSBpbiB0aGUgZnV0 dXJlLiBCdXQgc2luY2UgdGhpcyBpcyBhYm91dCBmb3JtYXQsIHdvdWxkbuKAmXQgaXQgYmUgYmV0 dGVyIHRvIHBvaW50IG9uIGFuIGV4cGxpY2l0IHZlcnNpb24sIGkuZS4gdGhlIGxhc3QgcHVibGlz aGVkIG9uZSAoUmVsLTEzKT8NCg0KQlINCk1hcnlzZQ0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGlt ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTmF2ZWVuIEtvdHRhcGFsbGkNClNlbnQ6 IGpldWRpIDMwIGp1aW4gMjAxNiAxNDoxOQ0KVG86IFl1dmFsIExpZnNoaXR6DQpDYzogZGltZUBp ZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRGltZV0gZHJhZnQt YmVydHotZGltZS1yZmM0MDA2YmlzIC0gM0dQUCBzcGVjaWZpY2F0aW9ucyByZWZlcmVuY2VzDQoN CklzIGl0IG1hbmRhdG9yeSB0byBtZW50aW9uIHRoZSB2ZXJzaW9uIG51bWJlcj8gIFNpbmNlIHRo ZSBzcGVjaWZpY2F0aW9uIG51bWJlcmluZyBrZWVwcyBjaGFuZ2luZyBmb3IgZXZlcnkgcmVsZWFz ZSwgc28gY2FuJ3Qgd2UganVzdCBtZW50aW9uIHRoZSBzcGVjaWZpY2F0aW9uIG51bWJlciB3aXRo b3V0IHZlcnNpb24/DQoNCllvdXJzLA0KTmF2ZWVuLg0KDQpPbiAyMiBKdW5lIDIwMTYgYXQgMjE6 MTYsIFl1dmFsIExpZnNoaXR6IDx5bGlmc2hpdHpAc2FuZHZpbmUuY29tPG1haWx0bzp5bGlmc2hp dHpAc2FuZHZpbmUuY29tPj4gd3JvdGU6DQpIaSBBbGwsDQpSRkM0MDA2IGN1cnJlbnRseSByZWZl cmVuY2UgcmVsNSAzR1BQIHNwZWNpZmljYXRpb25zLiBXb3VsZCBsaWtlIHRvIHByb3Bvc2UgdGhl IGZvbGxvd2luZyBjaGFuZ2VzIHRvIGl0IHdvdWxkIHBvaW50IHRvIGxhdGVzdCBzcGVjaWZpY2F0 aW9uczoNCkluIHBhZ2UgOTEsIHdlIGhhdmUgZm9sbG93aW5nIHRleHQ6DQoNClszR1BQSU1FSV0g IDNyZCBHZW5lcmF0aW9uIFBhcnRuZXJzaGlwIFByb2plY3Q7IFRlY2huaWNhbA0KICAgICAgICAg ICAgICAgU3BlY2lmaWNhdGlvbiBHcm91cCBDb3JlIE5ldHdvcmssIE51bWJlcmluZywgYWRkcmVz c2luZw0KICAgICAgICAgICAgICAgYW5kIGlkZW50aWZpY2F0aW9uLCAocmVsZWFzZSA1KSwgM0dQ UCBUUyAyMy4wMDMgdi4gNS44LjAsDQogICAgICAgICAgICAgICAyMDAzLTEyDQpDdXJyZW50IHZl cnNpb24gb2YgdGhhdCBzcGVjIGlzIDEzLjUuMCAoaHR0cDovL3d3dy5ldHNpLm9yZy9kZWxpdmVy L2V0c2lfdHMvMTIzMDAwXzEyMzA5OS8xMjMwMDMvMTMuMDUuMDBfNjAvdHNfMTIzMDAzdjEzMDUw MHAucGRmKQ0KVGhlIHN0cnVjdHVyZSBvZiBJTUVJIGRpZG4ndCBjaGFuZ2UgYmV0d2VlbiByZWxl YXNlIDUgYW5kIDEzLCBzbyB0aGUgY2hhbmdlIHNob3VsZCBub3QgaGF2ZSBvdGhlciBzaWRlIGVm ZmVjdHMsIHRoZXJlZm9yZSB3b3VsZCByZWNvbW1lbmQgZm9sbG93aW5nIHRleHQ6DQoNClszR1BQ SU1FSV0gIDNyZCBHZW5lcmF0aW9uIFBhcnRuZXJzaGlwIFByb2plY3Q7IFRlY2huaWNhbA0KICAg ICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiBHcm91cCBDb3JlIE5ldHdvcmssIE51bWJlcmluZywg YWRkcmVzc2luZw0KICAgICAgICAgICAgICAgYW5kIGlkZW50aWZpY2F0aW9uLCAocmVsZWFzZSAx MyksIDNHUFAgVFMgMjMuMDAzIHYuIDEzLjUuMCwNCiAgICAgICAgICAgICAgIDIwMTYtMDQuDQoN CkFub3RoZXIgM0dQUCBzcGVjaWZpY2F0aW9uIHJlZmVyZW5jZWQgZnJvbSBSRkM0MDA2IGlzIGlu IHBhZ2UgOTA6DQoNClszR1BQQ0hBUkddIDNyZCBHZW5lcmF0aW9uIFBhcnRuZXJzaGlwIFByb2pl Y3Q7IFRlY2huaWNhbA0KICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiBHcm91cCBTZXJ2aWNl cyBhbmQgU3lzdGVtIEFzcGVjdHMsIFNlcnZpY2UNCiAgICAgICAgICAgICAgIGFzcGVjdHM7IENo YXJnaW5nIGFuZCBCaWxsaW5nLCAocmVsZWFzZSA1KSwgM0dQUCBUUw0KICAgICAgICAgICAgICAg MjIuMTE1IHYuIDUuMi4xLCAyMDAyLTAzLg0KDQpPbmUgb3B0aW9uIGhlcmUgd291bGQgYmUgdG8g dXNlIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgYWJvdmUgc3BlYywgd2hpY2ggaXMgMTMuMy4w IChodHRwOi8vd3d3LmV0c2kub3JnL2RlbGl2ZXIvZXRzaV90cy8xMjIxMDBfMTIyMTk5LzEyMjEx NS8xMy4wMy4wMF82MC90c18xMjIxMTV2MTMwMzAwcC5wZGYpDQpJbiB0aGUgaW50cm9kdWN0aW9u LCB0aGUgc3BlYyBpcyB1c2VkIGFzIGp1c3RpZmljYXRpb24gdG8gd2h5IFJGQzQwMDYgd2FzIG5l ZWRlZCBhdCB0aGUgZmlyc3QgcGxhY2UsIGFuZCB3aHkgUkZDMzU4OCB3YXMgbm90IHN1ZmZpY2ll bnQgZm9yIHRoZXNlIG5lZWRzLiBTbywgYW55IGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIGFkZGVk IGluIHJlbGVhc2UgMTMgdmVyc2lvbiB3b3VsZCBvbmx5IHN0cmVzcyB0aGUgbmVjZXNzaXR5IG9m IFJGQzQwMDYuDQpXb3VsZCByZWNvbW1lbmQgdGhlIGZvbGxvd2luZyB0ZXh0Og0KDQpbM0dQUENI QVJHXSAzcmQgR2VuZXJhdGlvbiBQYXJ0bmVyc2hpcCBQcm9qZWN0OyBUZWNobmljYWwNCiAgICAg ICAgICAgICAgIFNwZWNpZmljYXRpb24gR3JvdXAgU2VydmljZXMgYW5kIFN5c3RlbSBBc3BlY3Rz LCBTZXJ2aWNlDQogICAgICAgICAgICAgICBhc3BlY3RzOyBDaGFyZ2luZyBhbmQgQmlsbGluZywg KHJlbGVhc2UgMTMpLCAzR1BQIFRTDQogICAgICAgICAgICAgICAyMi4xMTUgdi4gMTMuMy4wLCAy MDE2LTAzLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWls dG86ZGltZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc+XSBP biBCZWhhbGYgT2YgSm91bmkgS29yaG9uZW4NClNlbnQ6IEZyaWRheSwgSnVuZSAxNywgMjAxNiA2 OjM5IFBNDQpUbzogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbRGltZV0gZHJhZnQtYmVydHotZGltZS1yZmM0MDA2YmlzDQoNClRoYW5rcyBmb3IgdGhl ICJSRkM0MDA2YmlzIiB0ZWFtIGZvciBpbml0aWF0aW5nIHRoZSB3b3JrLiBTZWUgaW5saW5lDQoN CjYvMTcvMjAxNiwgMTowNCBBTSwgWXV2YWwgTGlmc2hpdHoga2lyam9pdHRpOg0KPiBEZWFyIGdy b3VwIG1lbWJlcnMsDQo+IFRoZXJlIGFyZSBzb21lIG1vcmUgbW9kaWZpY2F0aW9uIHRvIFJGQzQw MDYgdGhhdCB3ZSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgKGFsc28gbGlzdGVkIGhlcmU6IGh0dHBz Oi8vZ2l0aHViLmNvbS9sYmVydHowMi9yZmM0MDA2YmlzL2lzc3VlcykgdGhhdCBwcm9iYWJseSBy ZXF1aXJlIGZ1cnRoZXIgZGlzY3Vzc2lvbiBpbiB0aGUgZ3JvdXA6DQo+ICgxKSBVcGRhdGUgdGhl IElQdjYgcmVmZXJlbmNlDQoNClRoaXMgaXMgc3RyYWlnaHQgZm9yd2FyZC4gSnVzdCBtYWtlIHN1 cmUgdG8gcmVmZXJlbmNlIHRvIFJGQzQyOTFiaXMgd29yayBpbiA2TUFOIChkcmFmdC1pZXRmLTZt YW4tcmZjNDI5MWJpcykNCg0KPiAoMikgVXBkYXRlIHRoZSAzR1BQIGNoYXJnaW5nIHJlZmVyZW5j ZSAoY3VycmVudGx5IHBvaW50IHRvIHJlbDUuLi4pLg0KPiBIZXJlIHdlIG1heSB3YW50IHRvIGNo YW5nZSB0aGF0IHRvIHBvaW50IHRvIGEgZGlmZmVyZW50IGRvYyBhbHRvZ2V0aGVyDQo+ICgzR1BQ IFRTIDMyLjI5OSksIHdoaWNoIGlzIG1vcmUgcmVsZXZhbnQgKGFuZCBkaWRuJ3QgZXhpc3QgYXQg dGhlDQo+IHRpbWUpDQoNCkhlcmUsIHNvbWVvbmUgcmVhbGx5IG5lZWRzIHRvIGNoZWNrIHRoYXQg Y2hhbmdpbmcgdGhlIHJlZmVyZW5jZSAoVFMgYW5kDQpyZWxlYXNlKSBkb2VzIG5vdCBicmVhayBh bnl0aGluZy4gSSB3b3VsZCBlbmNvdXJhZ2UgeW91IHRvIGNvbWUgdXAgd2l0aCBhIHNob3J0IGFu YWx5c2lzIGUuZy4sIHRvIEJlcmxpbiBtZWV0aW5nLg0KDQo+ICgzKSBDaGFuZ2UgdGhlIEFWUCB0 YWJsZSBpbiBwYWdlIDU2LTU3LCBieSByZW1vdmluZyB0aGUgIkVuY3IiIGFuZA0KPiAiU0hPVUxE IE5PVCIgY29sdW1ucywgYW5kIHRoZSAiUCIgaW5kaWNhdGlvbiAoc2VlIGF0dGFjaGVkIGZpbGUp IC0NCj4gc2ltaWxhcmx5IHRvIHRoZSBjaGFuZ2UgbWFkZSBpbiBSRkM2NzMzDQoNClRoaXMgc2hv dWxkIGJlIHN0cmFpZ2ggZm9yd2FyZC4gVG8gbXkgdW5kZXJzdGFuZGluZyBubyBpbXBsZW1lbnRh dGlvbiBmb2xsb3dzIHRoZSAnZW5jcicgcmVjb21tZW5kYXRpb24gaW4gcHJhY3Rpc2UuIENvcnJl Y3Q/DQoNCj4gKDQpIFVwZ3JhZGUgUmVzdHJpY3Rpb24tRmlsdGVyLVJ1bGUgQVZQIHRvIGFsc28g c3VwcG9ydCBSRkMgNTc3Nw0KDQpBZ2FpbiBoZXJlIHNvbWUgZWZmb3J0IG5lZWRzIHRvIGJlIHB1 dCB0byBhbmFseXplIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXMgbWFpbnRhaW5lZCBpZiB3ZSB0 b3VjaCBSZXN0cmljdGlvbi1GaWx0ZXItUnVsZSBBVlAuIEkgd291bGQgZW5jb3VyYWdlIHlvdSB0 byBjb21lIHVwIHdpdGggYSBzaG9ydCBhbmFseXNpcyBlLmcuLCB0byBCZXJsaW4gbWVldGluZy4N Cg0KQWxzbywgSSdsbCBhZGQgKDUpIENyZWRpdC1Db250cm9sLUFuc3dlciB3aGVuICdFJyBpcyBz ZXQuIENoZWNrIHRoYXQgdGhlIGNvbW1hbmQgaXMgYWxpZ25lZCB3aXRoIFJGQzY3MzMgcmVnYXJk aW5nIHRoZSBlcnJvciByZXBsaWVzLg0KDQotIEpvdW5pDQoNCg0KDQo+DQo+IEFwcHJlY2lhdGUg eW91ciBmZWVkYmFjayENCj4NCj4gWXV2YWwNCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRGlNRSBtYWlsaW5nIGxpc3QNCj4gRGlN RUBpZXRmLm9yZzxtYWlsdG86RGlNRUBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kaW1lDQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZzxtYWls dG86RGlNRUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZGltZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmc8bWFpbHRvOkRpTUVAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0K --_000_C43C255C7106314F8D13D03FA20CFE4930C878E2wtlexchp2sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWdyZWUgd2l0aCBib3RoIHBvaW50cy4g QXMgdGhlIHJlZmVyZW5jZSB0bw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4yMi4xMTUgaXMgdmVyeSBnZW5lcmljLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5JbiBtb3N0IGNhc2VzLCB0aG91Z2gsIHdlIHNob3VsZCByZWZlcmVuY2Ugc3Bl Y2lmaWMgM0dQUCB2ZXJzaW9ucy4gVW5saWtlIGluIElFVEYsIHRoZXkgZG9u4oCZdCByZW5hbWUg dGhlIGRvY3VtZW50LCBldmVuIGlmIHN1YnN0YW50aWFsbHkgbW9kaWZpZWQgYmV0d2VlbiB2ZXJz aW9ucy4uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBHYXJkZWxsYSwgTWFyeXNlIChOb2tpYSAtIEZSKSBbbWFpbHRv Om1hcnlzZS5nYXJkZWxsYUBub2tpYS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXks IEp1bmUgMzAsIDIwMTYgNzowNSBQTTxicj4NCjxiPlRvOjwvYj4gTmF2ZWVuIEtvdHRhcGFsbGk7 IFl1dmFsIExpZnNoaXR6PGJyPg0KPGI+Q2M6PC9iPiBkaW1lQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJFOiBbRGltZV0gZHJhZnQtYmVydHotZGltZS1yZmM0MDA2YmlzIC0gM0dQUCBz cGVjaWZpY2F0aW9ucyByZWZlcmVuY2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkhpIGFsbCwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB3b3VsZCBjb25jdXIgd2l0aCB0aGUgc3VnZ2VzdGlvbiB0 byBqdXN0IG1lbnRpb24gdGhlIDNHUFAgc3BlYyB3L28gdmVyc2lvbiBmb3IgdGhlIHJlZmVyZW5j ZSB0byAyMi4xMTUsIGluIGNhc2UgaXQgaXMgcHJvcG9zZWQgdG8gc3RpY2sgdG8gdGhpcyAzR1BQ IHJlZmVyZW5jZTombmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WzNHUFBD SEFSR10gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KaXMgcmVm ZXJlZC10byBmb3IgdGhlIHJlcXVpcmVtZW50IOKAnCB0aGF0IGFuIGFwcGxpY2F0aW9uIG11c3Qg YmUgYWJsZSB0byByYXRlIHNlcnZpY2UgaW5mb3JtYXRpb24gaW4gcmVhbC10aW1lLuKAnSAmbmJz cDthcyBhbiBleGFtcGxlLCB3aGljaCByZW1haW5lZCBhcHBsaWNhYmxlIChhbHRob3VnaCBJIGNv dWxkIG5vdCBmaW5kIHRoZSBleGFjdCBzdGF0ZW1lbnQgaW4gdGhpcyB2NS4yLjAgcmVmZXJlbmNl ZCB2ZXJzaW9uKSB0byBzdWJzZXF1ZW50IHZlcnNpb25zDQogb2YgMjIuMTE1LCBhbmQgd2UgY291 bGQgZXhwZWN0IHRoaXMgdG8gYmUgc3RpbGwgYXBwbGljYWJsZSBpbiB0aGUgZnV0dXJlIHZlcnNp b25zIHNpbmNlIGl0IGlzIGdlbmVyaWMgZW5vdWdoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZGlu ZyB0aGUgcmVmZXJlbmNlIHRvDQo8L3NwYW4+WzNHUFBJTUVJXTombmJzcDs8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRoZSBzdHJ1Y3R1cmUgb2YgSU1FSVNWIGRpZG4ndCBjaGFuZ2UgYmV0d2VlbiByZWxlYXNl IDUgYW5kIDEzLCBhbmQgd2lsbCBsaWtlbHkgbm90IGNoYW5nZSBpbiB0aGUgZnV0dXJlLiBCdXQg c2luY2UgdGhpcyBpcyBhYm91dCBmb3JtYXQsIHdvdWxkbuKAmXQgaXQgYmUgYmV0dGVyDQogdG8g cG9pbnQgb24gYW4gZXhwbGljaXQgdmVyc2lvbiwgaS5lLiB0aGUgbGFzdCBwdWJsaXNoZWQgb25l IChSZWwtMTMpPyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CUjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NYXJ5c2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IERpTUUgWzxh IGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5OYXZlZW4gS290dGFwYWxsaTxicj4N CjxiPlNlbnQ6PC9iPiBqZXVkaSAzMCBqdWluIDIwMTYgMTQ6MTk8YnI+DQo8Yj5Ubzo8L2I+IFl1 dmFsIExpZnNoaXR6PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9y ZyI+ZGltZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEaW1lXSBkcmFm dC1iZXJ0ei1kaW1lLXJmYzQwMDZiaXMgLSAzR1BQIHNwZWNpZmljYXRpb25zIHJlZmVyZW5jZXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIGl0IG1hbmRh dG9yeSB0byBtZW50aW9uIHRoZSB2ZXJzaW9uIG51bWJlcj8mbmJzcDsgU2luY2UgdGhlIHNwZWNp ZmljYXRpb24gbnVtYmVyaW5nIGtlZXBzIGNoYW5naW5nIGZvciBldmVyeSByZWxlYXNlLCBzbyBj YW4ndCB3ZSBqdXN0IG1lbnRpb24gdGhlIHNwZWNpZmljYXRpb24gbnVtYmVyIHdpdGhvdXQgdmVy c2lvbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Zb3Vycyw8YnI+DQpOYXZlZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjIgSnVuZSAyMDE2IGF0IDIxOjE2LCBZdXZhbCBM aWZzaGl0eiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlsaWZzaGl0ekBzYW5kdmluZS5jb20iIHRhcmdl dD0iX2JsYW5rIj55bGlmc2hpdHpAc2FuZHZpbmUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBBbGwsPGJyPg0KUkZDNDAwNiBjdXJyZW50 bHkgcmVmZXJlbmNlIHJlbDUgM0dQUCBzcGVjaWZpY2F0aW9ucy4gV291bGQgbGlrZSB0byBwcm9w b3NlIHRoZSBmb2xsb3dpbmcgY2hhbmdlcyB0byBpdCB3b3VsZCBwb2ludCB0byBsYXRlc3Qgc3Bl Y2lmaWNhdGlvbnM6PGJyPg0KSW4gcGFnZSA5MSwgd2UgaGF2ZSBmb2xsb3dpbmcgdGV4dDo8YnI+ DQo8YnI+DQpbM0dQUElNRUldJm5ic3A7IDNyZCBHZW5lcmF0aW9uIFBhcnRuZXJzaGlwIFByb2pl Y3Q7IFRlY2huaWNhbDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtTcGVjaWZpY2F0aW9uIEdyb3VwIENvcmUgTmV0d29yaywgTnVtYmVy aW5nLCBhZGRyZXNzaW5nPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2FuZCBpZGVudGlmaWNhdGlvbiwgKHJlbGVhc2UgNSksIDNHUFAg VFMgMjMuMDAzIHYuIDUuOC4wLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsyMDAzLTEyPGJyPg0KQ3VycmVudCB2ZXJzaW9uIG9mIHRo YXQgc3BlYyBpcyAxMy41LjAgKDxhIGhyZWY9Imh0dHA6Ly93d3cuZXRzaS5vcmcvZGVsaXZlci9l dHNpX3RzLzEyMzAwMF8xMjMwOTkvMTIzMDAzLzEzLjA1LjAwXzYwL3RzXzEyMzAwM3YxMzA1MDBw LnBkZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuZXRzaS5vcmcvZGVsaXZlci9ldHNpX3Rz LzEyMzAwMF8xMjMwOTkvMTIzMDAzLzEzLjA1LjAwXzYwL3RzXzEyMzAwM3YxMzA1MDBwLnBkZjwv YT4pPGJyPg0KVGhlIHN0cnVjdHVyZSBvZiBJTUVJIGRpZG4ndCBjaGFuZ2UgYmV0d2VlbiByZWxl YXNlIDUgYW5kIDEzLCBzbyB0aGUgY2hhbmdlIHNob3VsZCBub3QgaGF2ZSBvdGhlciBzaWRlIGVm ZmVjdHMsIHRoZXJlZm9yZSB3b3VsZCByZWNvbW1lbmQgZm9sbG93aW5nIHRleHQ6PGJyPg0KPGJy Pg0KWzNHUFBJTUVJXSZuYnNwOyAzcmQgR2VuZXJhdGlvbiBQYXJ0bmVyc2hpcCBQcm9qZWN0OyBU ZWNobmljYWw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7U3BlY2lmaWNhdGlvbiBHcm91cCBDb3JlIE5ldHdvcmssIE51bWJlcmluZywg YWRkcmVzc2luZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDthbmQgaWRlbnRpZmljYXRpb24sIChyZWxlYXNlIDEzKSwgM0dQUCBUUyAy My4wMDMgdi4gMTMuNS4wLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsyMDE2LTA0Ljxicj4NCjxicj4NCkFub3RoZXIgM0dQUCBzcGVj aWZpY2F0aW9uIHJlZmVyZW5jZWQgZnJvbSBSRkM0MDA2IGlzIGluIHBhZ2UgOTA6PGJyPg0KPGJy Pg0KWzNHUFBDSEFSR10gM3JkIEdlbmVyYXRpb24gUGFydG5lcnNoaXAgUHJvamVjdDsgVGVjaG5p Y2FsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO1NwZWNpZmljYXRpb24gR3JvdXAgU2VydmljZXMgYW5kIFN5c3RlbSBBc3BlY3RzLCBT ZXJ2aWNlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2FzcGVjdHM7IENoYXJnaW5nIGFuZCBCaWxsaW5nLCAocmVsZWFzZSA1KSwgM0dQ UCBUUzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsyMi4xMTUgdi4gNS4yLjEsIDIwMDItMDMuPGJyPg0KPGJyPg0KT25lIG9wdGlvbiBo ZXJlIHdvdWxkIGJlIHRvIHVzZSB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGFib3ZlIHNwZWMs IHdoaWNoIGlzIDEzLjMuMCAoPGEgaHJlZj0iaHR0cDovL3d3dy5ldHNpLm9yZy9kZWxpdmVyL2V0 c2lfdHMvMTIyMTAwXzEyMjE5OS8xMjIxMTUvMTMuMDMuMDBfNjAvdHNfMTIyMTE1djEzMDMwMHAu cGRmIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5ldHNpLm9yZy9kZWxpdmVyL2V0c2lfdHMv MTIyMTAwXzEyMjE5OS8xMjIxMTUvMTMuMDMuMDBfNjAvdHNfMTIyMTE1djEzMDMwMHAucGRmPC9h Pik8YnI+DQpJbiB0aGUgaW50cm9kdWN0aW9uLCB0aGUgc3BlYyBpcyB1c2VkIGFzIGp1c3RpZmlj YXRpb24gdG8gd2h5IFJGQzQwMDYgd2FzIG5lZWRlZCBhdCB0aGUgZmlyc3QgcGxhY2UsIGFuZCB3 aHkgUkZDMzU4OCB3YXMgbm90IHN1ZmZpY2llbnQgZm9yIHRoZXNlIG5lZWRzLiBTbywgYW55IGFk ZGl0aW9uYWwgcmVxdWlyZW1lbnRzIGFkZGVkIGluIHJlbGVhc2UgMTMgdmVyc2lvbiB3b3VsZCBv bmx5IHN0cmVzcyB0aGUgbmVjZXNzaXR5IG9mIFJGQzQwMDYuPGJyPg0KV291bGQgcmVjb21tZW5k IHRoZSBmb2xsb3dpbmcgdGV4dDo8YnI+DQo8YnI+DQpbM0dQUENIQVJHXSAzcmQgR2VuZXJhdGlv biBQYXJ0bmVyc2hpcCBQcm9qZWN0OyBUZWNobmljYWw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U3BlY2lmaWNhdGlvbiBHcm91cCBT ZXJ2aWNlcyBhbmQgU3lzdGVtIEFzcGVjdHMsIFNlcnZpY2U8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YXNwZWN0czsgQ2hhcmdpbmcg YW5kIEJpbGxpbmcsIChyZWxlYXNlIDEzKSwgM0dQUCBUUzxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsyMi4xMTUgdi4gMTMuMy4wLCAy MDE2LTAzLjxicj4NCjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0K RnJvbTogRGlNRSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmci PmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBKb3VuaSBLb3Job25lbjxi cj4NClNlbnQ6IEZyaWRheSwgSnVuZSAxNywgMjAxNiA2OjM5IFBNPGJyPg0KVG86IDxhIGhyZWY9 Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFJl OiBbRGltZV0gZHJhZnQtYmVydHotZGltZS1yZmM0MDA2YmlzPGJyPg0KPGJyPg0KVGhhbmtzIGZv ciB0aGUgJnF1b3Q7UkZDNDAwNmJpcyZxdW90OyB0ZWFtIGZvciBpbml0aWF0aW5nIHRoZSB3b3Jr LiBTZWUgaW5saW5lPGJyPg0KPGJyPg0KNi8xNy8yMDE2LCAxOjA0IEFNLCBZdXZhbCBMaWZzaGl0 eiBraXJqb2l0dGk6PGJyPg0KJmd0OyBEZWFyIGdyb3VwIG1lbWJlcnMsPGJyPg0KJmd0OyBUaGVy ZSBhcmUgc29tZSBtb3JlIG1vZGlmaWNhdGlvbiB0byBSRkM0MDA2IHRoYXQgd2Ugd291bGQgbGlr ZSB0byBwcm9wb3NlIChhbHNvIGxpc3RlZCBoZXJlOg0KPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIu Y29tL2xiZXJ0ejAyL3JmYzQwMDZiaXMvaXNzdWVzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9n aXRodWIuY29tL2xiZXJ0ejAyL3JmYzQwMDZiaXMvaXNzdWVzPC9hPikgdGhhdCBwcm9iYWJseSBy ZXF1aXJlIGZ1cnRoZXIgZGlzY3Vzc2lvbiBpbiB0aGUgZ3JvdXA6PGJyPg0KJmd0OyAoMSkgVXBk YXRlIHRoZSBJUHY2IHJlZmVyZW5jZTxicj4NCjxicj4NClRoaXMgaXMgc3RyYWlnaHQgZm9yd2Fy ZC4gSnVzdCBtYWtlIHN1cmUgdG8gcmVmZXJlbmNlIHRvIFJGQzQyOTFiaXMgd29yayBpbiA2TUFO IChkcmFmdC1pZXRmLTZtYW4tcmZjNDI5MWJpcyk8YnI+DQo8YnI+DQomZ3Q7ICgyKSBVcGRhdGUg dGhlIDNHUFAgY2hhcmdpbmcgcmVmZXJlbmNlIChjdXJyZW50bHkgcG9pbnQgdG8gcmVsNS4uLiku PGJyPg0KJmd0OyBIZXJlIHdlIG1heSB3YW50IHRvIGNoYW5nZSB0aGF0IHRvIHBvaW50IHRvIGEg ZGlmZmVyZW50IGRvYyBhbHRvZ2V0aGVyPGJyPg0KJmd0OyAoM0dQUCBUUyAzMi4yOTkpLCB3aGlj aCBpcyBtb3JlIHJlbGV2YW50IChhbmQgZGlkbid0IGV4aXN0IGF0IHRoZTxicj4NCiZndDsgdGlt ZSk8YnI+DQo8YnI+DQpIZXJlLCBzb21lb25lIHJlYWxseSBuZWVkcyB0byBjaGVjayB0aGF0IGNo YW5naW5nIHRoZSByZWZlcmVuY2UgKFRTIGFuZDxicj4NCnJlbGVhc2UpIGRvZXMgbm90IGJyZWFr IGFueXRoaW5nLiBJIHdvdWxkIGVuY291cmFnZSB5b3UgdG8gY29tZSB1cCB3aXRoIGEgc2hvcnQg YW5hbHlzaXMgZS5nLiwgdG8gQmVybGluIG1lZXRpbmcuPGJyPg0KPGJyPg0KJmd0OyAoMykgQ2hh bmdlIHRoZSBBVlAgdGFibGUgaW4gcGFnZSA1Ni01NywgYnkgcmVtb3ZpbmcgdGhlICZxdW90O0Vu Y3ImcXVvdDsgYW5kPGJyPg0KJmd0OyAmcXVvdDtTSE9VTEQgTk9UJnF1b3Q7IGNvbHVtbnMsIGFu ZCB0aGUgJnF1b3Q7UCZxdW90OyBpbmRpY2F0aW9uIChzZWUgYXR0YWNoZWQgZmlsZSkgLTxicj4N CiZndDsgc2ltaWxhcmx5IHRvIHRoZSBjaGFuZ2UgbWFkZSBpbiBSRkM2NzMzPGJyPg0KPGJyPg0K VGhpcyBzaG91bGQgYmUgc3RyYWlnaCBmb3J3YXJkLiBUbyBteSB1bmRlcnN0YW5kaW5nIG5vIGlt cGxlbWVudGF0aW9uIGZvbGxvd3MgdGhlICdlbmNyJyByZWNvbW1lbmRhdGlvbiBpbiBwcmFjdGlz ZS4gQ29ycmVjdD88YnI+DQo8YnI+DQomZ3Q7ICg0KSBVcGdyYWRlIFJlc3RyaWN0aW9uLUZpbHRl ci1SdWxlIEFWUCB0byBhbHNvIHN1cHBvcnQgUkZDIDU3Nzc8YnI+DQo8YnI+DQpBZ2FpbiBoZXJl IHNvbWUgZWZmb3J0IG5lZWRzIHRvIGJlIHB1dCB0byBhbmFseXplIGJhY2t3YXJkIGNvbXBhdGli aWxpdHkgaXMgbWFpbnRhaW5lZCBpZiB3ZSB0b3VjaCBSZXN0cmljdGlvbi1GaWx0ZXItUnVsZSBB VlAuIEkgd291bGQgZW5jb3VyYWdlIHlvdSB0byBjb21lIHVwIHdpdGggYSBzaG9ydCBhbmFseXNp cyBlLmcuLCB0byBCZXJsaW4gbWVldGluZy48YnI+DQo8YnI+DQpBbHNvLCBJJ2xsIGFkZCAoNSkg Q3JlZGl0LUNvbnRyb2wtQW5zd2VyIHdoZW4gJ0UnIGlzIHNldC4gQ2hlY2sgdGhhdCB0aGUgY29t bWFuZCBpcyBhbGlnbmVkIHdpdGggUkZDNjczMyByZWdhcmRpbmcgdGhlIGVycm9yIHJlcGxpZXMu PGJyPg0KPGJyPg0KLSBKb3VuaTxicj4NCjxicj4NCjxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7 IEFwcHJlY2lhdGUgeW91ciBmZWVkYmFjayE8YnI+DQomZ3Q7PGJyPg0KJmd0OyBZdXZhbDxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IERpTUUgbWFpbGluZyBsaXN0PGJy Pg0KJmd0OyA8YSBocmVmPSJtYWlsdG86RGlNRUBpZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwvYT48 YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZGltZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZGltZTwvYT48YnI+DQomZ3Q7PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpEaU1FIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpEaU1FQGlldGYub3JnIj5EaU1FQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZSIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZTwvYT48YnI+DQo8 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CkRpTUUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciPkRp TUVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kaW1lIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kaW1lPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_C43C255C7106314F8D13D03FA20CFE4930C878E2wtlexchp2sandvi_-- From nobody Tue Jul 5 02:34:42 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A915312B012 for ; Tue, 5 Jul 2016 02:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxO9C4Y62VdD for ; Tue, 5 Jul 2016 02:34:36 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6A1126FDC for ; Tue, 5 Jul 2016 02:34:35 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 9F4015AF1018C; Tue, 5 Jul 2016 09:34:31 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u659YXJ1022174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Jul 2016 09:34:33 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u659YUft021165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Jul 2016 11:34:33 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.32]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 5 Jul 2016 11:34:11 +0200 From: "Trottin, Jean-Jacques (Nokia - FR)" To: Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] WGLC #1 for draft-ietf-dime-load-02 Thread-Index: AQHRtdE4tMkqClz2NEuuQj0gjsd2sp/qPcJQgAnlegCAAXp7AIAHXWgAgAOaJgCAADIrgIABPp8ggAAIp4CAB5znIA== Date: Tue, 5 Jul 2016 09:34:11 +0000 Message-ID: References: <5b31616d-efa3-ac03-8f1c-bd8883a35d65@gmail.com> <087A34937E64E74E848732CFF8354B9219758407@ESESSMB101.ericsson.se> <3e2082d80d8e45caaca581c9dcc98468@CSRRDU1EXM025.corp.csra.com> <71796571-c370-cae8-d456-9d2dfb02544c@usdonovans.com> <087A34937E64E74E848732CFF8354B921975C3F4@ESESSMB101.ericsson.se> <71ffc339-37e0-e4fd-a16e-59da7fe23b6d@usdonovans.com> <087A34937E64E74E848732CFF8354B921975E5AB@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B921975E824@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B921975E824@ESESSMB101.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 09:34:41 -0000 Hi MCruz I analysed your proposal about RDL and please see my JJ2> comment below you= r last comments in 5. Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo= me Envoy=E9=A0: jeudi 30 juin 2016 14:50 =C0=A0: Trottin, Jean-Jacques (Nokia - FR); Steve Donovan; dime@ietf.org Objet=A0: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02 Hello JJ, Nice to listening from you again. See comments below /MCruz -----Original Message----- From: Trottin, Jean-Jacques (Nokia - FR) [mailto:jean-jacques.trottin@nokia= .com] Sent: jueves, 30 de junio de 2016 13:00 To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org Cc: Uveges, Balint (Nokia - HU/Budapest); Wiehe, Ulrich (Nokia - DE/Munich) Subject: RE: [Dime] WGLC #1 for draft-ietf-dime-load-02 Dear all =20 About discussion regarding draft-ietf-dime-load-02, I was in line with the = new 02 version Steve distributed some time ago. I here reviewed Maria Cruz = comments and Steve's reactions. =20 Globally I remain in line with the Steve's hereafter comments. My main comm= ent is on .5 about server capacity. The other updates have for me no protoc= ol impact and were mainly wording enhancements and are worthwhile for me = . Please see my few comments in line (with JJ>). Main one is in 5. about the = capacity topic =20 I would also take this opportunity to indicate that due to my job evolution= , my colleague Balint Uveges will follow the load/overload dime aspects in = IETF. Best regards =20 JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo= me Envoy=E9=A0: mercredi 29 juin 2016 19:19 =C0=A0: Steve Donovan; dime@iet= f.org Objet=A0: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02 Hello Steve, Thanks for the responses, see some more comments below Best regards /MCruz On 6/27/16 2:18 AM, Maria Cruz Bartolome wrote: > >> 4.1 >> Now: >> None of this prevents a Diameter node from deciding to reduce the >> offered load based on load information. . >> >> Proposed >> (remove) >> >> Reasoning: >> This sentence is not properly linked to previous paragraph and it is=20 >> covered by previous paragraph already >> >> OK with this, though not sure it is necessary to delete. > SRD> This sentence adds emphasis to the point that a similar result=20 > SRD> can > happen between load and overload, leading into the next sentence outlinin= g the fundamental difference between the two. I don't see the harm in leav= ing it, even if what is says is implied by the previous paragraph. > MCRUZ> My problem with the sentence is that it is not straight forward to= what refers "none of this". The reader will look above to check what it re= fers to... and it seems to be the whole paragraph, i.e. the differences bet= ween load and overload. But this sentence refers again to something that is= mentioned above. Then, I think the sentence, as it is, is misleading that = turns reading a bit unease. SRD> How about: "A Diameter node can, however, decide to reduce offered load based on load information." MCRUZ> Fine >> 5. >> Now >> The second big difference between DOIC and Load is visibility of th= e >> DOIC or Load information within a Diameter network. DOIC informati= on >> is sent end-to-end resulting in the ability of all nodes in the pat= h >> of the answer message that carries the OC-OLR AVP to act on the >> information. The DOIC overload reports much remain in the message >> all the way from the reporting node to the node that is the target >> for the answer message. >> >> For the Load mechanism there are two types of load reports. >> >> The first is the load of the endpoint sending the answer message. >> This load report is carried end-to-end to enable any nodes that mak= e >> server selection decisions to use the load status of the sending >> endpoint as part of the server selection decision. >> >> The second type of load report is a peer report. This report is us= ed >> by Diameter nodes as part of the logic to select the next hop >> Diameter node and, as such, do not have significance beyond the pee= r >> node. These load reports are removed by the first supporting >> Diameter node to receive the report. >> >> Proposed: >> The second big difference between DOIC and Load is visibility of th= e >> DOIC or Load information within a Diameter network. DOIC informati= on >> is sent end-to-end resulting in the ability of all nodes in the pat= h >> of the answer message that carries the OC-OLR AVP to act on the >> information, *although only one node can actually consume the repor= t*. The DOIC overload reports much remain in the message >> all the way from the reporting node to the node that is the target >> for the answer message. > SRD> How about "although only one node actually reacts to the report", > changing consume to react. > MCRUZ> I think "consume" is better since it implies that from then on the= report is removed. SRD> How about consume and react? "although only one node actually consumes and reacts to the report" MCRUZ> Fine JJ> this would be the only place (here and I also think in DOIC RFC) where = "consume" word is used and raising the question what "consume" means, in pa= rticular this does not imply to remove the report. "react" was OK for me bu= t no opposition to "consume and react". =20 > >> *However,* for the Load mechanism there are two types of load repor= ts *and only the >> first one is transmitted end-to-end*. > SRD> This is covered in the following paragraphs. > MCRUZ> Yes, but I think we need an introduction for the analysis below, i= n order to understand we are going to compare. Trying to ease reading. SRD> Okay. ... > > 5. > Now > The goal is make it possible to use both the load values received as > a part of the Diameter Load mechanism and weight values received as = a > result of a DNS SRV query. As a result, the Diameter load value has > a range of 0-65535. This value and DNS SRV weight values are then > used in a distribution algorithm similar to that specified in > [RFC2782]. > > Comments: > In order to have an efficient load balancing algorithm, it is not enough = for the reacting node (for the node in charge of load balancing) to know th= e Load of each server, but it needs to know the load in relation to each se= rver capacity. Unless we do so, the Load value of a server can't be compare= d with the Load of a Server with a different weight. > Then, in my opinion, we need to find a way to provide a Load value that i= s in fact comparable with the rest of the Load values of the servers in the= group. > Reflecting a bit longer on this, I think we need then to define a group o= f servers in the load-balancing group, like a load-balancing context, and t= hen, for all servers in such a group we need to provide a relative value of= dynamic Load. > > Agree with the thought- if "Little Server" is 30% utilized and=20 > "Big Server" is 50% utilized, it still makes sense to send more=20 > traffic to Big Server. But I am not sure if that is withn the scope=20 > of this document. > SRD> I don't understand the concern. The load values supplied will be > input into the route selection algorithm as specified in RFC2782. If=20 > a node isn't getting enough traffic it will change its load value to a=20 > lower value and will start getting more traffic. > MCRUZ> Unless the LOAD info provided is in fact a value that represents t= he available capacity, then the load balancing will not select the less loa= ded server. Being able to select the less loaded server is the whole purpos= e of this mechanism, then we need to find a way to provide a LOAD value fro= m different servers that we are able to compare, i.e. the value provide mus= t indicate the available capacity regardless the static capacity of each se= rver. SRD> I view the goal of this a little differently. The goal is to make sure that requests are delivered to nodes with available capacity. It is n= ot strictly necessary that every request goes to the least loaded node. MCRUZ> Well, I do not agree. The whole purpose of providing LOAD info is to= be able to choose a node with available load (I agree), but among the nod= e with available load we need to choose the least loaded (or one of the lea= st loaded). It does not make sense, in my opinion, to simply select a node = with available load, when we are providing info about load. The information= provided should be valid to be able to select the least (or close to) load= ed. > Providing an example, let me use dynamic Load (say DL) in % (100% is tota= lly loaded) that I found it easier for calculation: > - Server1: weight=3D1500; DL=3D 2% > - Server2: weight=3D55000; DL=3D 70% > Then, if we only use DL in the LB algorithm, obviously Server 1 seems to = be clearly less loaded, but however, taking into account its weight is much= smaller it may be the other way around. In fact, if traffic is redirected = to this server, it may get overloaded rapidly (due to its small capacity). > One possible way to calculate the relative DL is to divide it by the wei= ght, then for this example: > - Server1 RDL=3D 10000 * (2/1500) =3D 13.33 > - Server2 RDL=3D 10000 * (70/55000) =3D 12.73 (I multiplied by 10000=20 > simply to get rid of the decimals for our discussion). > Then, we actually find out that available load for both servers is pretty= similar. In fact, in this case, a correct load balancing should select Ser= ver2 as the less loaded server instead of server1. > My proposal is to consider this reflection in the draft, and then make a = clear distinction between dynamic load (DL) and RELATIVE DL. We need to pro= vide the RDL in the message, not DL. SRD> This is about how the load value is calculated which is explicitly stated as being an implementation decision. MCRUZ> Not exactly. We need to reflect in the draft that the LOAD provided = should be the relative available load, taking into account the static weigh= t. This is the only way we are providing a load value that can possibly be = used by a client to LOAD-balance.=20 I could accept that we leave the way to do so up to implementations. Proposal: "LOAD should be calculated in a way that reflects the available l= oad independently of the weight of each server, in order to allow the Diame= ter node that performs server selection to accurateraly compare values from= different servers, i.e. LOAD value identifies the same amount of available= capacity, regardless the server that has calculate it. " JJ2> I analysed a bit more your example with Server1 RDL=3D 10000 * (2/1500= ) =3D 13.33 and Server2 RDL=3D 10000 * (70/55000) =3D 12.73 with the conclu= sion to select server2. This is a bit surprising as server 1 is only 2% loa= ded. This example is rather specific with a server 1 weight being 2,7% of s= erver 2 weight. I did another example with less difference in the weights - Server1: weight=3D30000; DL=3D 30% - Server2: weight=3D60000; DL=3D 50% This drives to=20 Server1 RDL=3D 10000 * (30/30000) =3D 10,0 Server2 RDL=3D 10000 * (50/60000) =3D 8,3 =20 Here also, if I follow your reasoning, this would drive to select server 2 = to increase its RDL. Again the result is to increase server2 load Even by taking a 80% load for server 2 (so a high load in practice) and 50%= for server 1=20 Server1 RDL=3D 10000 * (50/30000) =3D 16,7 Server2 RDL=3D 10000 * (80/60000) =3D 13,3 This still drives to select server 2, although the reasoning would be to in= crease server 1 load Nevertheless, if server 1 has only 30% load its RDL becomes 10 and it will= be selected, so here OK =20 Please check if I am wrong somewhere, but currently RDL, for me, can give = strange outputs. About static weight I agree that static weight can be useful, e.g. a last h= op DA can be configured with the server weight to distribute its traffic a= mong the servers it is connected to. =20 My point is about the targeted load balance between the servers. Often, the= objective is to have the same load among servers (even if they have some d= ifference in their capacity / weight), which is the way to maximize the tra= ffic without entering overload in any server. So the "DL" (as defined in th= e current draft) indicates whether they have the same load, and if the obje= ctive is achieved. For me I do not well see how you define the targeted loa= d among servers with the RDL you mentioned. If received load from servers is not the same, the sending node has to sen= d a bit more traffic to the less loaded node. For this, as you said, an obj= ective is to avoid oscillations, and sending node has to evaluate the amoun= t of traffic it will switch from the more loaded server to the less loaded = server, this switched traffic being not too high to avoid oscillations and = also not too low to avoid maintaining unbalanced situation. In the draft, i= t is left to implementation on the sending node on how to modify the curren= t traffic distribution among the servers according to the received load (DL= ), and I am OK on this. In my previous mail I indicated that the sending n= ode will adjust its traffic distribution according to the updated load (DL)= received from server and converge to the balanced situation, in this proce= ss, I agree that the weight attached to each server can be an additional us= eful input when available, but keeping the current load (DL) definition =09 JJ> I think we can remain with only the relative load information proposed= in the draft even when servers have different capacity. If a small capacit= y node sees its incoming traffic increasing it will quickly react by sendin= g a higher load value, which, when received by a sending node, will become = higher than the values received from other nodes with higher capacity. Sen= ding node will then reduce the traffic towards this node to ensure load bal= ancing and will continue to adjust according to the load values received. T= his seems a simple loopback mechanism ensuring a right load balancing. MCRUZ> This does not assure a proper load-balancing, because the client doe= s not have information it can compare, then it does not know which server i= s less loaded, not even approximately. Obviously, when a server gets more l= oaded it will provide the information, but this will cause oscillations, th= at could even be critical for a server. For example, if one server has a ve= ry small weight, compared to the rest, it may be selected as the destinatio= n of requests but it would get easily loaded, and again, it needs to react.= =20 Moreover, the servers in the pool with higher capacity will be normally und= erutilized. In general, resources are not efficiently use (bigger server te= nd to be underutilized), the load fluctuates a lot (specially for the small= servers), and some servers may be overloaded with peaks of traffic (small = servers). Then, my proposal is to include a normative sentence, as above, although th= e way to specifically do it may be operator specific. Then, on top of that,= the example I provided is useful to understand the situation and I think s= hould be in the draft as well. Do you think it is not sufficient? To add capacity value (weight, group of = servers) ..)increases the increases the complexity given this capacity may = vary over time (eg a partial failure) so possibly requiring to be dynamical= ly updated.=20 More sophisticated behaviors can be introduced (implementation specific) wi= thout impacting the protocol and AVPs specified in the draft. If justified = requirements drive to new AVPs, this could be part of future evolution, out= of the scope of the present draft . > > >> 5. >> Now >> The load report includes the relative load of the sending node. Th= is >> relative load is specified in a manner consistent with that defined >> for DNS SRV [RFC2782]. >> >> Proposed: >> The load report includes a value to identify the load of the sendin= g node, >> specified in a manner consistent with that defined >> for DNS SRV [RFC2782]. >> >> Agree. > SRD> I don't understand the need for this change. > MCRUZ> Using "relative" is misleading unless we clarify "relative to what= ". SRD> Okay. How about a small change to: "The load report includes a value **indicating** the load of the sending node..." MCRUZ> Fine JJ> "relative" also used in the proposed update definition of "load" in sec= tion 2, which is consistent with the definition of the Load-Value AVP in 7.= 3., so for me relative is not misleading. MCRUZ> I made same comment to that section. I think Steve's proposal is fin= e and more accurate. =20 >> ... >> 6.1.1 >> Now: >> The method for determining the load value included in the load repo= rt >> is an implementation decision. >> >> Comments: >> In line to comment above, I agree it should be implementation specific, = but we need to provide some guidance to be able to provide a value that cou= ld be used to achieve a successful load balancing. > SRD> See my comment above about DNS SRV algorithm. > MCRUZ> This is related to my comment above to 5, but to the part related = to a way to provide a LOAD value that represents the available capacity of = a server, taking into account its static capacity. SRD> Okay, I'll propose some text, based on your example, in the next version of the draft. This would be a non normative example of how someone= might compute the load value. MCRUZ> Including the example is fine. Although above I proposed some normat= ive text as well that I think we need to consider. JJ> see my above comments to 5. The sender adjusts its traffic according th= e evolution of the received load values. =20 MCRUZ> See my comments above. This causes a bunch of problems. ... > >> 7.3 >> Now: >> The Load-Value AVP is specified in a manner similar to the weight >> value in DNS SRV ([RFC2782]). >> >> The Load-Value has a range of 0-65535. >> >> A higher value indicates a lower load on the sending node. A lower >> value indicates that the sending node is heavily loaded. >> >> Stated another way, a node that has zero load would have a load >> value of 65535. A node that is 100% loaded would have a load >> value of 0. >> >> Comments: >> I think it could be easier to use a %. It is more straight forward to fi= gure out what it means. > SRD> Percentage can be mapped to the range 0-65535 if that is the > internal implementation decision. The goal here is to be consistent=20 > with RFC2782. > MCRUZ> Why do we need to keep consistency to that RFC? I think it is clea= rer to use a percentage, it is more straight forward to identify the availa= ble load we refer to. SRD> This was discussed and agreed to early in the process of writing this mechanism. There a a couple of reasons, first, its an algorithm that = has already been specified and implemented. Second, it allows someone who= has already implemented the DNS SRV algorithm to reuse it. =20 Third, while RFC6733 doesn't directly address load balancing/distribution, = it does reference use of DNS SRV for handling dynamic connections. It is n= ot unreasonable to expect that there are implementations would use the DNS = SRV value for nodes that don't support load, along with load values receive= d. MCRUZ> I do not remember a discussion about this, sorry. I had the impressi= on it was incorporated without much discussion. However, I do not see that it helps reusing DNS SRV. Does an implementation= take profit of anything previously implemented for DNS SRV when deciding w= hat load value include in the AVP? I think the server will calculate the LO= AD, and then it needs to reflect a value from totally-available to totally-= loaded. It is more straight forward and more intuitive to simply use 0-100 = as you agreed below. I did not consider the comment before, sorry, but I think now it can be eas= ily changed and simplify all the implementations and interpretation of LOAD= value, don't you think? > E.g. 50% loaded, using SRV is 32767,5; 25% is 49151,25; and so on. > In the mechanism we are defining we do not have the need to keep using a = complex value like this one, when we can simply use 0 to 100%, 0 (totally a= vailable), 100 (totally loaded). > In fact, this is in line to the definition in the doc: SRD> I really don't want to revisit this decision this late in the game. While not as intuitive to a casual reader of the specification as a = percentage value might be, Using the DNS SRV value works. ... JJ> Preliminary version of the draft started with %, then Steve proposed to= use the same definition as with SRV which didn't raise comments, I am OK t= o remain on Steve proposal. MCRUZ> There is no reason to keep it unless we think it has some advantages= , which as I explained above, I do not think there are. Let me know if you = see any advantages. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Tue Jul 5 06:16:28 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630DF12D556 for ; Tue, 5 Jul 2016 06:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Se7XsnDg5o7i for ; Tue, 5 Jul 2016 06:16:23 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A07612D0E9 for ; Tue, 5 Jul 2016 06:16:22 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id A1BD4818BD0A8; Tue, 5 Jul 2016 13:16:17 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u65DGKfq003970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Jul 2016 13:16:20 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u65DGKLr010888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Jul 2016 15:16:20 +0200 Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.62]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 5 Jul 2016 15:16:20 +0200 From: "Gardella, Maryse (Nokia - FR)" To: Dave Dolson , "dime@ietf.org" Thread-Topic: [Dime] RFC 4006 bis - IMEI Thread-Index: AdHS8KRXUuwo33kKTp24S5zATa6CnwABTOGwAB1boCAAD99PgADEmrXQ Date: Tue, 5 Jul 2016 13:16:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] RFC 4006 bis - IMEI X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 13:16:26 -0000 Hi Dave,=20 Do you mean, in case this new value would be needed, it is possible to hand= le this via IANA allocation w/o impacting existing RFC 4006? Could you clar= ify this for me? Thanks Maryse=20 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson Sent: vendredi 1 juillet 2016 19:11 To: Gardella, Maryse (Nokia - FR); dime@ietf.org Subject: Re: [Dime] RFC 4006 bis - IMEI Maryse, OK, I understand your question. Reading 3GPP 23.003, IMEI and IMEISV are clearly defined as different thing= s in sections 6.2.1 and 6.2.2. And RFC4006 specifically says IMEISV.=20 So I would say RFC4006 is not ambiguous.=20 Also, the most recent 3GPP 32.299 indicates "The used value is 0 for the in= ternational mobile equipment identifier and software version according to 3= GPP TS 23.003." It seems reasonable to extend to a Type 4 for IMEI, but there does not seem= to have been a need, or there would have been an IANA allocation (which do= es not require RFC revision). Perhaps you could explain the need to the group? -Dave -----Original Message----- From: Gardella, Maryse (Nokia - FR) [mailto:maryse.gardella@nokia.com]=20 Sent: Friday, July 01, 2016 9:02 AM To: Dave Dolson; dime@ietf.org Subject: RE: [Dime] RFC 4006 bis - IMEI Hi Dave, Indeed it was not clear to me whether the current definition explicitly exc= luded the IMEI or not. I was wondering about the behavior of the client in case the Software Versi= on Number (SVN) is not available.=20 Otherwise if a new value is needed for this distinction, I would propose th= e User-Equipment-Info-Type AVP to be extended with IMEI value=20 BR Maryse -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson Sent: jeudi 30 juin 2016 19:39 To: Gardella, Maryse (Nokia - FR); dime@ietf.org Subject: Re: [Dime] RFC 4006 bis - IMEI Maryse, If I understand correctly, you are proposing overloading a type, distinguis= hing the types only by length. Is there precedent for the overloading you propose, such as a 3GPP standard= or de facto standard usage that you can cite? Otherwise, IANA may assign new values for new types, and we aren't short on= space: http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml#aaa-par= ameters-41 -Dave -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Gardella, Maryse (No= kia - FR) Sent: Thursday, June 30, 2016 12:59 PM To: dime@ietf.org Subject: [Dime] RFC 4006 bis - IMEI All, As part of the updates to RFC 4006 I propose to consider the IMEI also when= refering to IMEISV, otherwise it is not clear if User-Equipment-Info-Type = value O can be used for IMEI.=20 In section 8.50. User-Equipment-Info-Type AVP in RFC4006,the following is s= pecified:=20 =20 IMEISV 0 The identifier contains the International Mobile Equipment Identifier and Software Version in the international IMEISV format according to 3GPP TS 23.003 [3GPPIMEI]. Which I propose to be updated as follows: =20 IMEI(SV) 0 The identifier contains the International Mobile Equipment Identifier and Software Version in the international IMEISV format,=20 or the International Mobile Equipment Identifier in the international IMEI= format=20 according to 3GPP TS 23.003 [3GPPIMEI].=20 Differentiation between IMEI (15 digits) and IMEISV (16 digits) is based on= AVP length, would this work? BR Maryse _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Tue Jul 5 08:31:36 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5063612D0EB for ; Tue, 5 Jul 2016 08:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xxCewlqOS3J for ; Tue, 5 Jul 2016 08:31:31 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5646E12D0AA for ; Tue, 5 Jul 2016 08:31:31 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0195.001; Tue, 5 Jul 2016 11:31:29 -0400 From: Dave Dolson To: "Gardella, Maryse (Nokia - FR)" , "dime@ietf.org" Thread-Topic: [Dime] RFC 4006 bis - IMEI Thread-Index: AQHR05jjZU3yr50ZFUWIQJ60KVePjqADyu+wgAZPw4D//9DdAA== Date: Tue, 5 Jul 2016 15:31:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] RFC 4006 bis - IMEI X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 15:31:33 -0000 Maryse, Referring to BCP26, https://tools.ietf.org/html/bcp26,=20 You can read about "Assignment by Designated Expert" in section 3 https://= tools.ietf.org/html/bcp26#section-3 I don't know who the designated expert would be, but I think the first step= would be to begin a thread on the dime mailing list to request the new all= ocation, justifying why it is needed. Hopefully the dime chairs can provide more insight on the process. -Dave -----Original Message----- From: Gardella, Maryse (Nokia - FR) [mailto:maryse.gardella@nokia.com]=20 Sent: Tuesday, July 05, 2016 9:16 AM To: Dave Dolson; dime@ietf.org Subject: RE: [Dime] RFC 4006 bis - IMEI Hi Dave,=20 Do you mean, in case this new value would be needed, it is possible to hand= le this via IANA allocation w/o impacting existing RFC 4006? Could you clar= ify this for me? Thanks Maryse=20 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson Sent: vendredi 1 juillet 2016 19:11 To: Gardella, Maryse (Nokia - FR); dime@ietf.org Subject: Re: [Dime] RFC 4006 bis - IMEI Maryse, OK, I understand your question. Reading 3GPP 23.003, IMEI and IMEISV are clearly defined as different thing= s in sections 6.2.1 and 6.2.2. And RFC4006 specifically says IMEISV.=20 So I would say RFC4006 is not ambiguous.=20 Also, the most recent 3GPP 32.299 indicates "The used value is 0 for the in= ternational mobile equipment identifier and software version according to 3= GPP TS 23.003." It seems reasonable to extend to a Type 4 for IMEI, but there does not seem= to have been a need, or there would have been an IANA allocation (which do= es not require RFC revision). Perhaps you could explain the need to the group? -Dave -----Original Message----- From: Gardella, Maryse (Nokia - FR) [mailto:maryse.gardella@nokia.com]=20 Sent: Friday, July 01, 2016 9:02 AM To: Dave Dolson; dime@ietf.org Subject: RE: [Dime] RFC 4006 bis - IMEI Hi Dave, Indeed it was not clear to me whether the current definition explicitly exc= luded the IMEI or not. I was wondering about the behavior of the client in case the Software Versi= on Number (SVN) is not available.=20 Otherwise if a new value is needed for this distinction, I would propose th= e User-Equipment-Info-Type AVP to be extended with IMEI value=20 BR Maryse -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson Sent: jeudi 30 juin 2016 19:39 To: Gardella, Maryse (Nokia - FR); dime@ietf.org Subject: Re: [Dime] RFC 4006 bis - IMEI Maryse, If I understand correctly, you are proposing overloading a type, distinguis= hing the types only by length. Is there precedent for the overloading you propose, such as a 3GPP standard= or de facto standard usage that you can cite? Otherwise, IANA may assign new values for new types, and we aren't short on= space: http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml#aaa-par= ameters-41 -Dave -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Gardella, Maryse (No= kia - FR) Sent: Thursday, June 30, 2016 12:59 PM To: dime@ietf.org Subject: [Dime] RFC 4006 bis - IMEI All, As part of the updates to RFC 4006 I propose to consider the IMEI also when= refering to IMEISV, otherwise it is not clear if User-Equipment-Info-Type = value O can be used for IMEI.=20 In section 8.50. User-Equipment-Info-Type AVP in RFC4006,the following is s= pecified:=20 =20 IMEISV 0 The identifier contains the International Mobile Equipment Identifier and Software Version in the international IMEISV format according to 3GPP TS 23.003 [3GPPIMEI]. Which I propose to be updated as follows: =20 IMEI(SV) 0 The identifier contains the International Mobile Equipment Identifier and Software Version in the international IMEISV format,=20 or the International Mobile Equipment Identifier in the international IMEI= format=20 according to 3GPP TS 23.003 [3GPPIMEI].=20 Differentiation between IMEI (15 digits) and IMEISV (16 digits) is based on= AVP length, would this work? BR Maryse _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Tue Jul 5 09:32:20 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6492912D5CA for ; Tue, 5 Jul 2016 09:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gG1RT8cm-ULd for ; Tue, 5 Jul 2016 09:32:16 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73D2A12B04E for ; Tue, 5 Jul 2016 09:32:15 -0700 (PDT) Received: by mail-pa0-x230.google.com with SMTP id uj8so8952646pab.3 for ; Tue, 05 Jul 2016 09:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=J8ovBcdeRCeGN7XdECKBT1iWSfCMrZ8EKDxuP9+CyZY=; b=KR0yaYN3xn71TN9yeiHv5uD1seexkKT+2mPiElXkj0sUkBwF77KULR+Qz+OB3vAh0j OADEG/6JYPC+YAYalghcVk/IzlDo4nh8DXWeTNQIlJCHVQOcPMcuXw2R/EBaJezVu2Em aRcGtsLhVS6qq6c3WAF1zRDeFbZ9cWoDFOEu2rcLotpMuF5FDUM6gjalpIL45Ad+ePqm eQWhwXkg+1qmKe4kFcgv97Bw1m54tb/Om8YuWotyl5XkW5h39NelToiPdSf7/q7GMtFk Lc4dhFfTtBA7PY5jCK73yu5hHk9FcRGB+TIK0/f+dENdX+DbWKNK/VIlbBFNCr20LK08 UJmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=J8ovBcdeRCeGN7XdECKBT1iWSfCMrZ8EKDxuP9+CyZY=; b=WVyWBLfVXgQrqcTuvwIRUS4NXhWTnOif4TU02fqI6R/+SvqYBFwjPAs0l00UOJrply YEhB+y6Rl8o/TZ8xF/hAak1oTPJIzEE9U/9BYvTP8Vs383K3tMX3S91J9KrTPf/AhY2e MgmE6pFLxbnJ226CYsHGxhjnxUTw8CDODy9qy7wyzOJeOMfTxfuOsAVwnHSAQEazBOZb pT0qLUC4PXvOIHjOb0f9Mpn4iMnzGDUS4GUkvqYSUxDEADX5oCmZEzNTrGF8NKw74W+A tvzTau4vJKFjjQ2f9JzNAJjIyvNAkFaWPB6HCBpvN6hmMV7DN0UN4CEV/vwFDgie5JAm opGw== X-Gm-Message-State: ALyK8tI+lxV9e1gizBi/RfnxyCu5KrHAhqjB8QbRsz+aU4xGWGnf3NhJ2SmGZZLqhhatCA== X-Received: by 10.66.248.3 with SMTP id yi3mr33588547pac.61.1467736334757; Tue, 05 Jul 2016 09:32:14 -0700 (PDT) Received: from [10.16.65.14] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id by5sm6464781pad.36.2016.07.05.09.32.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jul 2016 09:32:14 -0700 (PDT) References: To: Dave Dolson , "Gardella, Maryse (Nokia - FR)" , "dime@ietf.org" From: Jouni Korhonen Message-ID: Date: Tue, 5 Jul 2016 09:32:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dime] RFC 4006 bis - IMEI X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jouni.nospam@gmail.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 16:32:18 -0000 Designated experts would most likely be either Lionel or me. Basically the procedure goes like: there's a public spec (no need to be in IETF) or at least technical discussion (preferably in IETF) of the allocation need of the new code point, and once that is "done" someone does a request to IANA. Then IANA will contact the "expert", who evaluates the allocation requests and either grants or denies it. The more information there is available for the allocation requests the more comfortble the expert is backing up the request towards IANA. For example various 3GPP CT group secretaries have done allocation requests to IANA during years. Regarding the User-Equipment-Info-Type AVP doing the new allocation doing it in RFC4006bis would be "easy".. assuming we finish this discussion into an agreement for a need. - Jouni 7/5/2016, 8:31 AM, Dave Dolson kirjoitti: > Maryse, > Referring to BCP26, https://tools.ietf.org/html/bcp26, > You can read about "Assignment by Designated Expert" in section 3 https://tools.ietf.org/html/bcp26#section-3 > > I don't know who the designated expert would be, but I think the first step would be to begin a thread on the dime mailing list to request the new allocation, justifying why it is needed. > > Hopefully the dime chairs can provide more insight on the process. > > -Dave > > > -----Original Message----- > From: Gardella, Maryse (Nokia - FR) [mailto:maryse.gardella@nokia.com] > Sent: Tuesday, July 05, 2016 9:16 AM > To: Dave Dolson; dime@ietf.org > Subject: RE: [Dime] RFC 4006 bis - IMEI > > Hi Dave, > > Do you mean, in case this new value would be needed, it is possible to handle this via IANA allocation w/o impacting existing RFC 4006? Could you clarify this for me? > > Thanks > Maryse > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: vendredi 1 juillet 2016 19:11 > To: Gardella, Maryse (Nokia - FR); dime@ietf.org > Subject: Re: [Dime] RFC 4006 bis - IMEI > > Maryse, > OK, I understand your question. > > Reading 3GPP 23.003, IMEI and IMEISV are clearly defined as different things in sections 6.2.1 and 6.2.2. > And RFC4006 specifically says IMEISV. > > So I would say RFC4006 is not ambiguous. > > Also, the most recent 3GPP 32.299 indicates "The used value is 0 for the international mobile equipment identifier and software version according to 3GPP TS 23.003." > > It seems reasonable to extend to a Type 4 for IMEI, but there does not seem to have been a need, or there would have been an IANA allocation (which does not require RFC revision). > > Perhaps you could explain the need to the group? > > -Dave > > > -----Original Message----- > From: Gardella, Maryse (Nokia - FR) [mailto:maryse.gardella@nokia.com] > Sent: Friday, July 01, 2016 9:02 AM > To: Dave Dolson; dime@ietf.org > Subject: RE: [Dime] RFC 4006 bis - IMEI > > Hi Dave, > > Indeed it was not clear to me whether the current definition explicitly excluded the IMEI or not. > I was wondering about the behavior of the client in case the Software Version Number (SVN) is not available. > > Otherwise if a new value is needed for this distinction, I would propose the User-Equipment-Info-Type AVP to be extended with IMEI value > > > BR > Maryse > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: jeudi 30 juin 2016 19:39 > To: Gardella, Maryse (Nokia - FR); dime@ietf.org > Subject: Re: [Dime] RFC 4006 bis - IMEI > > Maryse, > > If I understand correctly, you are proposing overloading a type, distinguishing the types only by length. > > Is there precedent for the overloading you propose, such as a 3GPP standard or de facto standard usage that you can cite? > > Otherwise, IANA may assign new values for new types, and we aren't short on space: > http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml#aaa-parameters-41 > > > -Dave > > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Gardella, Maryse (Nokia - FR) > Sent: Thursday, June 30, 2016 12:59 PM > To: dime@ietf.org > Subject: [Dime] RFC 4006 bis - IMEI > > All, > > As part of the updates to RFC 4006 I propose to consider the IMEI also when refering to IMEISV, otherwise it is not clear if User-Equipment-Info-Type value O can be used for IMEI. > > > In section 8.50. User-Equipment-Info-Type AVP in RFC4006,the following is specified: > > IMEISV 0 > The identifier contains the International Mobile Equipment > Identifier and Software Version in the international IMEISV format > according to 3GPP TS 23.003 [3GPPIMEI]. > > Which I propose to be updated as follows: > > IMEI(SV) 0 > The identifier contains the International Mobile Equipment > Identifier and Software Version in the international IMEISV format, > or the International Mobile Equipment Identifier in the international IMEI format > according to 3GPP TS 23.003 [3GPPIMEI]. > > > Differentiation between IMEI (15 digits) and IMEISV (16 digits) is based on AVP length, would this work? > > BR > Maryse > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Tue Jul 5 10:09:37 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2CD12D662 for ; Tue, 5 Jul 2016 10:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uG_jAVj0J5iM for ; Tue, 5 Jul 2016 10:09:33 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E7E312D128 for ; Tue, 5 Jul 2016 10:09:32 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 958F332481E; Tue, 5 Jul 2016 19:09:30 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6D39D238075; Tue, 5 Jul 2016 19:09:30 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0294.000; Tue, 5 Jul 2016 19:09:30 +0200 From: To: "jouni.nospam@gmail.com" , Dave Dolson , "Gardella, Maryse (Nokia - FR)" , "dime@ietf.org" Thread-Topic: [Dime] RFC 4006 bis - IMEI Thread-Index: AdHS8KRXUuwo33kKTp24S5zATa6CnwABTOGwAB1boCAAD99PgADEmrXQAAEW2gAAAh02AAAFULFQ Date: Tue, 5 Jul 2016 17:09:29 +0000 Message-ID: <21004_1467738570_577BE9CA_21004_4347_1_6B7134B31289DC4FAF731D844122B36E01EE3EDA@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.7.5.154216 Archived-At: Subject: Re: [Dime] RFC 4006 bis - IMEI X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 17:09:36 -0000 For clarification, for Diameter related IANA allocation requests, it is und= er the responsibility of CT4 secretary. Now, as said by Dave and Jouni, we should clarify the requirement for an IM= EI specific value whereas only the IMEISV is actually used. Regards, Lionel > -----Message d'origine----- > De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen > Envoy=E9=A0: mardi 5 juillet 2016 18:32 > =C0=A0: Dave Dolson; Gardella, Maryse (Nokia - FR); dime@ietf.org > Objet=A0: Re: [Dime] RFC 4006 bis - IMEI >=20 > Designated experts would most likely be either Lionel or me. Basically the > procedure goes like: there's a public spec (no need to be in IETF) or at = least > technical discussion (preferably in IETF) of the allocation need of the n= ew code > point, and once that is "done" someone does a request to IANA. Then IANA = will > contact the "expert", who evaluates the allocation requests and either gr= ants or > denies it. The more information there is available for the allocation req= uests the > more comfortble the expert is backing up the request towards IANA. >=20 > For example various 3GPP CT group secretaries have done allocation reques= ts to > IANA during years. >=20 > Regarding the User-Equipment-Info-Type AVP doing the new allocation doing= it > in RFC4006bis would be "easy".. assuming we finish this discussion into an > agreement for a need. >=20 > - Jouni >=20 > 7/5/2016, 8:31 AM, Dave Dolson kirjoitti: > > Maryse, > > Referring to BCP26, https://tools.ietf.org/html/bcp26, > > You can read about "Assignment by Designated Expert" in section 3 > > https://tools.ietf.org/html/bcp26#section-3 > > > > I don't know who the designated expert would be, but I think the first = step > would be to begin a thread on the dime mailing list to request the new > allocation, justifying why it is needed. > > > > Hopefully the dime chairs can provide more insight on the process. > > > > -Dave > > > > > > -----Original Message----- > > From: Gardella, Maryse (Nokia - FR) [mailto:maryse.gardella@nokia.com] > > Sent: Tuesday, July 05, 2016 9:16 AM > > To: Dave Dolson; dime@ietf.org > > Subject: RE: [Dime] RFC 4006 bis - IMEI > > > > Hi Dave, > > > > Do you mean, in case this new value would be needed, it is possible to = handle > this via IANA allocation w/o impacting existing RFC 4006? Could you clari= fy this > for me? > > > > Thanks > > Maryse > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson > > Sent: vendredi 1 juillet 2016 19:11 > > To: Gardella, Maryse (Nokia - FR); dime@ietf.org > > Subject: Re: [Dime] RFC 4006 bis - IMEI > > > > Maryse, > > OK, I understand your question. > > > > Reading 3GPP 23.003, IMEI and IMEISV are clearly defined as different t= hings > in sections 6.2.1 and 6.2.2. > > And RFC4006 specifically says IMEISV. > > > > So I would say RFC4006 is not ambiguous. > > > > Also, the most recent 3GPP 32.299 indicates "The used value is 0 for the > international mobile equipment identifier and software version according = to > 3GPP TS 23.003." > > > > It seems reasonable to extend to a Type 4 for IMEI, but there does not = seem > to have been a need, or there would have been an IANA allocation (which d= oes > not require RFC revision). > > > > Perhaps you could explain the need to the group? > > > > -Dave > > > > > > -----Original Message----- > > From: Gardella, Maryse (Nokia - FR) [mailto:maryse.gardella@nokia.com] > > Sent: Friday, July 01, 2016 9:02 AM > > To: Dave Dolson; dime@ietf.org > > Subject: RE: [Dime] RFC 4006 bis - IMEI > > > > Hi Dave, > > > > Indeed it was not clear to me whether the current definition explicitly= excluded > the IMEI or not. > > I was wondering about the behavior of the client in case the Software V= ersion > Number (SVN) is not available. > > > > Otherwise if a new value is needed for this distinction, I would > > propose the User-Equipment-Info-Type AVP to be extended with IMEI > > value > > > > > > BR > > Maryse > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson > > Sent: jeudi 30 juin 2016 19:39 > > To: Gardella, Maryse (Nokia - FR); dime@ietf.org > > Subject: Re: [Dime] RFC 4006 bis - IMEI > > > > Maryse, > > > > If I understand correctly, you are proposing overloading a type, distin= guishing > the types only by length. > > > > Is there precedent for the overloading you propose, such as a 3GPP stan= dard > or de facto standard usage that you can cite? > > > > Otherwise, IANA may assign new values for new types, and we aren't shor= t on > space: > > http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml#aa > > a-parameters-41 > > > > > > -Dave > > > > > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Gardella, > > Maryse (Nokia - FR) > > Sent: Thursday, June 30, 2016 12:59 PM > > To: dime@ietf.org > > Subject: [Dime] RFC 4006 bis - IMEI > > > > All, > > > > As part of the updates to RFC 4006 I propose to consider the IMEI also = when > refering to IMEISV, otherwise it is not clear if User-Equipment-Info-Type= value O > can be used for IMEI. > > > > > > In section 8.50. User-Equipment-Info-Type AVP in RFC4006,the following = is > specified: > > > > IMEISV 0 > > The identifier contains the International Mobile Equipment > > Identifier and Software Version in the international IMEISV format > > according to 3GPP TS 23.003 [3GPPIMEI]. > > > > Which I propose to be updated as follows: > > > > IMEI(SV) 0 > > The identifier contains the International Mobile Equipment > > Identifier and Software Version in the international IMEISV forma= t, > > or the International Mobile Equipment Identifier in the international > IMEI format > > according to 3GPP TS 23.003 [3GPPIMEI]. > > > > > > Differentiation between IMEI (15 digits) and IMEISV (16 digits) is base= d on AVP > length, would this work? > > > > BR > > Maryse > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Jul 5 12:20:30 2016 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CC212D532; Tue, 5 Jul 2016 12:20:28 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160705192028.22362.42220.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2016 12:20:28 -0700 Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [Dime] Protocol Action: 'Diameter Routing Message Priority' to Proposed Standard (draft-ietf-dime-drmp-07.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 19:20:28 -0000 The IESG has approved the following document: - 'Diameter Routing Message Priority' (draft-ietf-dime-drmp-07.txt) as Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Stephen Farrell, Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ Technical Summary When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document addresses this by defining a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information Diameter nodes can factor that priority into routing, resource allocation and overload abatement decisions. Working Group Summary The document received a large support for adoption when initiated and it has been reviewed multiple times, with detailed comments and corrections. The version -03 addresses the last comments received after the WGLC process. There is a strong WG consensus on the content of this document, with a broad range of people, including key experts. Document Quality The proposed solution has not been implemented yet, as vendors are waiting for IANA AVP code value assignment before implementing. However, no issues are expected with implementation. Moreover, the solution defined in this document have been already introduced in standard specifications defined by 3GPP. It is therefore understood that the vendors implementing 3GPP specifications will implement this mechanism. Personnel The document shepherd is Lionel Morand. Stephen Farrell is being AD-like for this. From nobody Wed Jul 6 03:41:28 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA9212D0C7 for ; Wed, 6 Jul 2016 03:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrZRf9y__Cyz for ; Wed, 6 Jul 2016 03:41:25 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4153412B031 for ; Wed, 6 Jul 2016 03:41:25 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0195.001; Wed, 6 Jul 2016 06:41:23 -0400 From: Yuval Lifshitz To: "lionel.morand@orange.com" , "jouni.nospam@gmail.com" , Dave Dolson , "Gardella, Maryse (Nokia - FR)" , "dime@ietf.org" Thread-Topic: [Dime] RFC 4006 bis - IMEI Thread-Index: AQHR0vZJ6ucLEjBkbE6Ga3VB4LLp1aADzpSAgABFm4CABgfIgIAAJcUAgAAQ6QCAAAp3gIAA30IA Date: Wed, 6 Jul 2016 10:41:22 +0000 Message-ID: References: <21004_1467738570_577BE9CA_21004_4347_1_6B7134B31289DC4FAF731D844122B36E01EE3EDA@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <21004_1467738570_577BE9CA_21004_4347_1_6B7134B31289DC4FAF731D844122B36E01EE3EDA@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.143.1] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] RFC 4006 bis - IMEI X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 10:41:28 -0000 * In 3GPP TS 29.061 they use the AVP length to differentiate IMEI from IMEI= SV in the RADIUS AVP * In 3GPP TS 29.060 (GTP-C) they pad with ones in case that the software ve= rsion is not there So, my guess is that the gateway is probably using one of the above options= in when sending the value over Diameter. So, it is probably safe to assume= that the IMEISV enum is used to send both types of data. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, July 05, 2016 8:09 PM To: jouni.nospam@gmail.com; Dave Dolson; Gardella, Maryse (Nokia - FR); dim= e@ietf.org Subject: Re: [Dime] RFC 4006 bis - IMEI For clarification, for Diameter related IANA allocation requests, it is und= er the responsibility of CT4 secretary. Now, as said by Dave and Jouni, we should clarify the requirement for an IM= EI specific value whereas only the IMEISV is actually used. Regards, Lionel > -----Message d'origine----- > De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen=20 > Envoy=E9=A0: mardi 5 juillet 2016 18:32 =C0=A0: Dave Dolson; Gardella, Ma= ryse=20 > (Nokia - FR); dime@ietf.org Objet=A0: Re: [Dime] RFC 4006 bis - IMEI >=20 > Designated experts would most likely be either Lionel or me. Basically=20 > the procedure goes like: there's a public spec (no need to be in IETF)=20 > or at least technical discussion (preferably in IETF) of the=20 > allocation need of the new code point, and once that is "done" someone=20 > does a request to IANA. Then IANA will contact the "expert", who=20 > evaluates the allocation requests and either grants or denies it. The=20 > more information there is available for the allocation requests the more = comfortble the expert is backing up the request towards IANA. >=20 > For example various 3GPP CT group secretaries have done allocation=20 > requests to IANA during years. >=20 > Regarding the User-Equipment-Info-Type AVP doing the new allocation=20 > doing it in RFC4006bis would be "easy".. assuming we finish this=20 > discussion into an agreement for a need. >=20 > - Jouni >=20 > 7/5/2016, 8:31 AM, Dave Dolson kirjoitti: > > Maryse, > > Referring to BCP26, https://tools.ietf.org/html/bcp26, > > You can read about "Assignment by Designated Expert" in section 3 > > https://tools.ietf.org/html/bcp26#section-3 > > > > I don't know who the designated expert would be, but I think the=20 > > first step > would be to begin a thread on the dime mailing list to request the new=20 > allocation, justifying why it is needed. > > > > Hopefully the dime chairs can provide more insight on the process. > > > > -Dave > > > > > > -----Original Message----- > > From: Gardella, Maryse (Nokia - FR)=20 > > [mailto:maryse.gardella@nokia.com] > > Sent: Tuesday, July 05, 2016 9:16 AM > > To: Dave Dolson; dime@ietf.org > > Subject: RE: [Dime] RFC 4006 bis - IMEI > > > > Hi Dave, > > > > Do you mean, in case this new value would be needed, it is possible=20 > > to handle > this via IANA allocation w/o impacting existing RFC 4006? Could you=20 > clarify this for me? > > > > Thanks > > Maryse > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson > > Sent: vendredi 1 juillet 2016 19:11 > > To: Gardella, Maryse (Nokia - FR); dime@ietf.org > > Subject: Re: [Dime] RFC 4006 bis - IMEI > > > > Maryse, > > OK, I understand your question. > > > > Reading 3GPP 23.003, IMEI and IMEISV are clearly defined as=20 > > different things > in sections 6.2.1 and 6.2.2. > > And RFC4006 specifically says IMEISV. > > > > So I would say RFC4006 is not ambiguous. > > > > Also, the most recent 3GPP 32.299 indicates "The used value is 0 for=20 > > the > international mobile equipment identifier and software version=20 > according to 3GPP TS 23.003." > > > > It seems reasonable to extend to a Type 4 for IMEI, but there does=20 > > not seem > to have been a need, or there would have been an IANA allocation=20 > (which does not require RFC revision). > > > > Perhaps you could explain the need to the group? > > > > -Dave > > > > > > -----Original Message----- > > From: Gardella, Maryse (Nokia - FR)=20 > > [mailto:maryse.gardella@nokia.com] > > Sent: Friday, July 01, 2016 9:02 AM > > To: Dave Dolson; dime@ietf.org > > Subject: RE: [Dime] RFC 4006 bis - IMEI > > > > Hi Dave, > > > > Indeed it was not clear to me whether the current definition=20 > > explicitly excluded > the IMEI or not. > > I was wondering about the behavior of the client in case the=20 > > Software Version > Number (SVN) is not available. > > > > Otherwise if a new value is needed for this distinction, I would=20 > > propose the User-Equipment-Info-Type AVP to be extended with IMEI=20 > > value > > > > > > BR > > Maryse > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson > > Sent: jeudi 30 juin 2016 19:39 > > To: Gardella, Maryse (Nokia - FR); dime@ietf.org > > Subject: Re: [Dime] RFC 4006 bis - IMEI > > > > Maryse, > > > > If I understand correctly, you are proposing overloading a type,=20 > > distinguishing > the types only by length. > > > > Is there precedent for the overloading you propose, such as a 3GPP=20 > > standard > or de facto standard usage that you can cite? > > > > Otherwise, IANA may assign new values for new types, and we aren't=20 > > short on > space: > > http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml# > > aa > > a-parameters-41 > > > > > > -Dave > > > > > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Gardella,=20 > > Maryse (Nokia - FR) > > Sent: Thursday, June 30, 2016 12:59 PM > > To: dime@ietf.org > > Subject: [Dime] RFC 4006 bis - IMEI > > > > All, > > > > As part of the updates to RFC 4006 I propose to consider the IMEI=20 > > also when > refering to IMEISV, otherwise it is not clear if=20 > User-Equipment-Info-Type value O can be used for IMEI. > > > > > > In section 8.50. User-Equipment-Info-Type AVP in RFC4006,the=20 > > following is > specified: > > > > IMEISV 0 > > The identifier contains the International Mobile Equipment > > Identifier and Software Version in the international IMEISV forma= t > > according to 3GPP TS 23.003 [3GPPIMEI]. > > > > Which I propose to be updated as follows: > > > > IMEI(SV) 0 > > The identifier contains the International Mobile Equipment > > Identifier and Software Version in the international IMEISV forma= t, > > or the International Mobile Equipment Identifier in the=20 > > international > IMEI format > > according to 3GPP TS 23.003 [3GPPIMEI]. > > > > > > Differentiation between IMEI (15 digits) and IMEISV (16 digits) is=20 > > based on AVP > length, would this work? > > > > BR > > Maryse > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Wed Jul 6 05:39:02 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CB012D77F for ; Wed, 6 Jul 2016 05:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeO2hLUhi6Fr for ; Wed, 6 Jul 2016 05:38:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84BB912D77C for ; Wed, 6 Jul 2016 05:38:56 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id CACB32644FD; Wed, 6 Jul 2016 14:38:54 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.19]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 9C8B72380AE; Wed, 6 Jul 2016 14:38:54 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0294.000; Wed, 6 Jul 2016 14:38:54 +0200 From: To: Yuval Lifshitz , "jouni.nospam@gmail.com" , Dave Dolson , "Gardella, Maryse (Nokia - FR)" , "dime@ietf.org" Thread-Topic: [Dime] RFC 4006 bis - IMEI Thread-Index: AdHS8KRXUuwo33kKTp24S5zATa6CnwABTOGwAB1boCAAD99PgADEmrXQAAEW2gAAAh02AAAFULFQACC6tQAAB6LysA== Date: Wed, 6 Jul 2016 12:38:53 +0000 Message-ID: <19142_1467808734_577CFBDE_19142_892_1_6B7134B31289DC4FAF731D844122B36E01EE59A0@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <21004_1467738570_577BE9CA_21004_4347_1_6B7134B31289DC4FAF731D844122B36E01EE3EDA@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Subject: Re: [Dime] RFC 4006 bis - IMEI X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 12:39:00 -0000 There is a lot of historical stuff in 3GPP specifications, depending on the= release for which the specification was first edited. After a lot of discussion, the formats of IMEI/IMEISV have been clarified i= n the TS 23.003, defined as two distinct identifiers: IMEI =3D TAC | SNR |CD/SD 8-D 6-D 1-D IMEISV =3D TAC | SNR | SVN 8-D 6-D 2-D On some 3GPP interfaces, these Ids are conveyed into two different 3GPP-spe= cific AVPs. In such a case, they is no need to use the length to different = one from this other. And we are not running out of AVP codes. So no need to encapsulate in the s= ame AVP two values with two different semantics. regards, Lionel > -----Message d'origine----- > De=A0: Yuval Lifshitz [mailto:ylifshitz@sandvine.com] > Envoy=E9=A0: mercredi 6 juillet 2016 12:41 > =C0=A0: MORAND Lionel IMT/OLN; jouni.nospam@gmail.com; Dave Dolson; > Gardella, Maryse (Nokia - FR); dime@ietf.org > Cc=A0: Yuval Lifshitz > Objet=A0: RE: [Dime] RFC 4006 bis - IMEI >=20 > * In 3GPP TS 29.061 they use the AVP length to differentiate IMEI from IM= EISV in > the RADIUS AVP > * In 3GPP TS 29.060 (GTP-C) they pad with ones in case that the software = version > is not there >=20 > So, my guess is that the gateway is probably using one of the above optio= ns in > when sending the value over Diameter. So, it is probably safe to assume t= hat the > IMEISV enum is used to send both types of data. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of > lionel.morand@orange.com > Sent: Tuesday, July 05, 2016 8:09 PM > To: jouni.nospam@gmail.com; Dave Dolson; Gardella, Maryse (Nokia - FR); > dime@ietf.org > Subject: Re: [Dime] RFC 4006 bis - IMEI >=20 > For clarification, for Diameter related IANA allocation requests, it is u= nder the > responsibility of CT4 secretary. >=20 > Now, as said by Dave and Jouni, we should clarify the requirement for an = IMEI > specific value whereas only the IMEISV is actually used. >=20 > Regards, >=20 > Lionel >=20 > > -----Message d'origine----- > > De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen > > Envoy=E9=A0: mardi 5 juillet 2016 18:32 =C0=A0: Dave Dolson; Gardella, = Maryse > > (Nokia - FR); dime@ietf.org Objet=A0: Re: [Dime] RFC 4006 bis - IMEI > > > > Designated experts would most likely be either Lionel or me. Basically > > the procedure goes like: there's a public spec (no need to be in IETF) > > or at least technical discussion (preferably in IETF) of the > > allocation need of the new code point, and once that is "done" someone > > does a request to IANA. Then IANA will contact the "expert", who > > evaluates the allocation requests and either grants or denies it. The > > more information there is available for the allocation requests the more > comfortble the expert is backing up the request towards IANA. > > > > For example various 3GPP CT group secretaries have done allocation > > requests to IANA during years. > > > > Regarding the User-Equipment-Info-Type AVP doing the new allocation > > doing it in RFC4006bis would be "easy".. assuming we finish this > > discussion into an agreement for a need. > > > > - Jouni > > > > 7/5/2016, 8:31 AM, Dave Dolson kirjoitti: > > > Maryse, > > > Referring to BCP26, https://tools.ietf.org/html/bcp26, > > > You can read about "Assignment by Designated Expert" in section 3 > > > https://tools.ietf.org/html/bcp26#section-3 > > > > > > I don't know who the designated expert would be, but I think the > > > first step > > would be to begin a thread on the dime mailing list to request the new > > allocation, justifying why it is needed. > > > > > > Hopefully the dime chairs can provide more insight on the process. > > > > > > -Dave > > > > > > > > > -----Original Message----- > > > From: Gardella, Maryse (Nokia - FR) > > > [mailto:maryse.gardella@nokia.com] > > > Sent: Tuesday, July 05, 2016 9:16 AM > > > To: Dave Dolson; dime@ietf.org > > > Subject: RE: [Dime] RFC 4006 bis - IMEI > > > > > > Hi Dave, > > > > > > Do you mean, in case this new value would be needed, it is possible > > > to handle > > this via IANA allocation w/o impacting existing RFC 4006? Could you > > clarify this for me? > > > > > > Thanks > > > Maryse > > > > > > -----Original Message----- > > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson > > > Sent: vendredi 1 juillet 2016 19:11 > > > To: Gardella, Maryse (Nokia - FR); dime@ietf.org > > > Subject: Re: [Dime] RFC 4006 bis - IMEI > > > > > > Maryse, > > > OK, I understand your question. > > > > > > Reading 3GPP 23.003, IMEI and IMEISV are clearly defined as > > > different things > > in sections 6.2.1 and 6.2.2. > > > And RFC4006 specifically says IMEISV. > > > > > > So I would say RFC4006 is not ambiguous. > > > > > > Also, the most recent 3GPP 32.299 indicates "The used value is 0 for > > > the > > international mobile equipment identifier and software version > > according to 3GPP TS 23.003." > > > > > > It seems reasonable to extend to a Type 4 for IMEI, but there does > > > not seem > > to have been a need, or there would have been an IANA allocation > > (which does not require RFC revision). > > > > > > Perhaps you could explain the need to the group? > > > > > > -Dave > > > > > > > > > -----Original Message----- > > > From: Gardella, Maryse (Nokia - FR) > > > [mailto:maryse.gardella@nokia.com] > > > Sent: Friday, July 01, 2016 9:02 AM > > > To: Dave Dolson; dime@ietf.org > > > Subject: RE: [Dime] RFC 4006 bis - IMEI > > > > > > Hi Dave, > > > > > > Indeed it was not clear to me whether the current definition > > > explicitly excluded > > the IMEI or not. > > > I was wondering about the behavior of the client in case the > > > Software Version > > Number (SVN) is not available. > > > > > > Otherwise if a new value is needed for this distinction, I would > > > propose the User-Equipment-Info-Type AVP to be extended with IMEI > > > value > > > > > > > > > BR > > > Maryse > > > > > > -----Original Message----- > > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson > > > Sent: jeudi 30 juin 2016 19:39 > > > To: Gardella, Maryse (Nokia - FR); dime@ietf.org > > > Subject: Re: [Dime] RFC 4006 bis - IMEI > > > > > > Maryse, > > > > > > If I understand correctly, you are proposing overloading a type, > > > distinguishing > > the types only by length. > > > > > > Is there precedent for the overloading you propose, such as a 3GPP > > > standard > > or de facto standard usage that you can cite? > > > > > > Otherwise, IANA may assign new values for new types, and we aren't > > > short on > > space: > > > http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml# > > > aa > > > a-parameters-41 > > > > > > > > > -Dave > > > > > > > > > > > > -----Original Message----- > > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Gardella, > > > Maryse (Nokia - FR) > > > Sent: Thursday, June 30, 2016 12:59 PM > > > To: dime@ietf.org > > > Subject: [Dime] RFC 4006 bis - IMEI > > > > > > All, > > > > > > As part of the updates to RFC 4006 I propose to consider the IMEI > > > also when > > refering to IMEISV, otherwise it is not clear if > > User-Equipment-Info-Type value O can be used for IMEI. > > > > > > > > > In section 8.50. User-Equipment-Info-Type AVP in RFC4006,the > > > following is > > specified: > > > > > > IMEISV 0 > > > The identifier contains the International Mobile Equipment > > > Identifier and Software Version in the international IMEISV for= mat > > > according to 3GPP TS 23.003 [3GPPIMEI]. > > > > > > Which I propose to be updated as follows: > > > > > > IMEI(SV) 0 > > > The identifier contains the International Mobile Equipment > > > Identifier and Software Version in the international IMEISV for= mat, > > > or the International Mobile Equipment Identifier in the > > > international > > IMEI format > > > according to 3GPP TS 23.003 [3GPPIMEI]. > > > > > > > > > Differentiation between IMEI (15 digits) and IMEISV (16 digits) is > > > based on AVP > > length, would this work? > > > > > > BR > > > Maryse > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 > _________________________________________________________________ > ________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites ou > copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le > signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages > electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed,= used > or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Jul 6 07:19:26 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D742312D775 for ; Wed, 6 Jul 2016 07:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7SdZHSYdGtg for ; Wed, 6 Jul 2016 07:19:21 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2601B12D580 for ; Wed, 6 Jul 2016 07:18:53 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Wed, 6 Jul 2016 10:18:52 -0400 From: Dave Dolson To: "dime@ietf.org" Thread-Topic: RFC4006bis and IPv6 redirect address Thread-Index: AdHXkVHJsgQ0l6avTpqr0n/qLLXE1w== Date: Wed, 6 Jul 2016 14:18:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830FE6825wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: [Dime] RFC4006bis and IPv6 redirect address X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 14:19:26 -0000 --_000_E8355113905631478EFF04F5AA706E9830FE6825wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In RFC4006, we find the following in section 8.38, Redirect-Address-Type AV= P: IPv6 Address 1 The address type is in the form of IPv6 address, as defined in [IPv6Addr]. The address is a text representation of the address in either the preferred or alternate text form [IPv6Addr]. Conformant implementations MUST support the preferred form and SHOULD support the alternate text form for IPv6 addresses. [IPv6Addr] refers to obsolete RFC3513. We will change this to RFC4291, but = ... The above wording refers to two formats, "preferred" and "alternate", where= as both RFC3513 and RFC4291 refer to *three* formats: 1. "The preferred form is x:x:x:x:x:x:x:x,..." 2. "...a special syntax is available to compress the zeros..." 3. "An alternative form that is sometimes more convenient when dealin= g with a mixed environment of IPv4 and IPv6 nodes is x:x:x:x:x:x:d.d.d.d,..= ." See https://tools.ietf.org/html/rfc4291#section-2.2 Is it intended that all 3 forms be supported? Otherwise it seems that only = the long preferred form and the mixed alternative forms are permitted, not = the compressed form. My sense is that it was always intended that all of the forms described in = section 2.2 of RFC 4291 should be supported. -Dave --_000_E8355113905631478EFF04F5AA706E9830FE6825wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In RFC4006, we find the following in section 8.38, R= edirect-Address-Type AVP:

 

=    IPv6 Address        &n= bsp;           1

=       The address type is in the form of IPv6 addr= ess, as defined in

=       [IPv6Addr].  The address is a text repr= esentation of the address

=       in either the preferred or alternate text fo= rm [IPv6Addr].

=       Conformant implementations MUST support the = preferred form and

=       SHOULD support the alternate text form for I= Pv6 addresses.

 

[IPv6Addr] refers to obsolete RFC3513. We will chang= e this to RFC4291, but …

The above wording refers to two formats, “pref= erred” and “alternate”, whereas both RFC3513 and RFC4291 = refer to *three* formats:

1.       “The = preferred form is x:x:x:x:x:x:x:x,…”

2.     &= nbsp; “…a special syntax is available to comp= ress the zeros…”

3.     &= nbsp; “An alternative form that is sometimes more c= onvenient when dealing with a mixed environment of IPv4 and IPv6 nodes is x= :x:x:x:x:x:d.d.d.d,…”

 

See https://tools.ietf.org/html/rfc4291#section-2.2

 

 

Is it intended that all 3 forms be supported? Otherw= ise it seems that only the long preferred form and the mixed alternative fo= rms are permitted, not the compressed form.

 

My sense is that it was always intended that all of = the forms described in section 2.2 of RFC 4291 should be supported.

 

 

 

-Dave

 

 

--_000_E8355113905631478EFF04F5AA706E9830FE6825wtlexchp2sandvi_-- From nobody Wed Jul 6 07:58:30 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D526112D0D1 for ; Wed, 6 Jul 2016 07:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfiNQH1gtnIs for ; Wed, 6 Jul 2016 07:58:26 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C2912B01A for ; Wed, 6 Jul 2016 07:58:05 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Wed, 6 Jul 2016 10:58:04 -0400 From: Yuval Lifshitz To: "lionel.morand@orange.com" , "jouni.nospam@gmail.com" , Dave Dolson , "Gardella, Maryse (Nokia - FR)" , "dime@ietf.org" Thread-Topic: [Dime] RFC 4006 bis - IMEI Thread-Index: AQHR0vZJ6ucLEjBkbE6Ga3VB4LLp1aADzpSAgABFm4CABgfIgIAAJcUAgAAQ6QCAAAp3gIAA30IAgABneID//+MbAA== Date: Wed, 6 Jul 2016 14:58:03 +0000 Message-ID: References: <21004_1467738570_577BE9CA_21004_4347_1_6B7134B31289DC4FAF731D844122B36E01EE3EDA@OPEXCLILM43.corporate.adroot.infra.ftgroup> <19142_1467808734_577CFBDE_19142_892_1_6B7134B31289DC4FAF731D844122B36E01EE59A0@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <19142_1467808734_577CFBDE_19142_892_1_6B7134B31289DC4FAF731D844122B36E01EE59A0@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] RFC 4006 bis - IMEI X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 14:58:29 -0000 Having two codes is surely better.=20 My comment was regarding the current state, and the urgency of the change -= since the value is overloaded in one AVP/IE in RADIUS/GTP-C, it is probabl= y overloaded in the Diameter AVP when type is IMEISV. -----Original Message----- From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: Wednesday, July 06, 2016 3:39 PM To: Yuval Lifshitz; jouni.nospam@gmail.com; Dave Dolson; Gardella, Maryse (= Nokia - FR); dime@ietf.org Subject: RE: [Dime] RFC 4006 bis - IMEI There is a lot of historical stuff in 3GPP specifications, depending on the= release for which the specification was first edited. After a lot of discussion, the formats of IMEI/IMEISV have been clarified i= n the TS 23.003, defined as two distinct identifiers: IMEI =3D TAC | SNR |CD/SD 8-D 6-D 1-D IMEISV =3D TAC | SNR | SVN 8-D 6-D 2-D On some 3GPP interfaces, these Ids are conveyed into two different 3GPP-spe= cific AVPs. In such a case, they is no need to use the length to different = one from this other. And we are not running out of AVP codes. So no need to encapsulate in the s= ame AVP two values with two different semantics. regards, Lionel > -----Message d'origine----- > De=A0: Yuval Lifshitz [mailto:ylifshitz@sandvine.com] Envoy=E9=A0: mercre= di=20 > 6 juillet 2016 12:41 =C0=A0: MORAND Lionel IMT/OLN;=20 > jouni.nospam@gmail.com; Dave Dolson; Gardella, Maryse (Nokia - FR);=20 > dime@ietf.org Cc=A0: Yuval Lifshitz Objet=A0: RE: [Dime] RFC 4006 bis -=20 > IMEI >=20 > * In 3GPP TS 29.061 they use the AVP length to differentiate IMEI from=20 > IMEISV in the RADIUS AVP > * In 3GPP TS 29.060 (GTP-C) they pad with ones in case that the=20 > software version is not there >=20 > So, my guess is that the gateway is probably using one of the above=20 > options in when sending the value over Diameter. So, it is probably=20 > safe to assume that the IMEISV enum is used to send both types of data. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 > lionel.morand@orange.com > Sent: Tuesday, July 05, 2016 8:09 PM > To: jouni.nospam@gmail.com; Dave Dolson; Gardella, Maryse (Nokia -=20 > FR); dime@ietf.org > Subject: Re: [Dime] RFC 4006 bis - IMEI >=20 > For clarification, for Diameter related IANA allocation requests, it=20 > is under the responsibility of CT4 secretary. >=20 > Now, as said by Dave and Jouni, we should clarify the requirement for=20 > an IMEI specific value whereas only the IMEISV is actually used. >=20 > Regards, >=20 > Lionel >=20 > > -----Message d'origine----- > > De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni=20 > > Korhonen Envoy=E9=A0: mardi 5 juillet 2016 18:32 =C0=A0: Dave Dolson;=20 > > Gardella, Maryse (Nokia - FR); dime@ietf.org Objet=A0: Re: [Dime] RFC=20 > > 4006 bis - IMEI > > > > Designated experts would most likely be either Lionel or me.=20 > > Basically the procedure goes like: there's a public spec (no need to=20 > > be in IETF) or at least technical discussion (preferably in IETF) of=20 > > the allocation need of the new code point, and once that is "done"=20 > > someone does a request to IANA. Then IANA will contact the "expert",=20 > > who evaluates the allocation requests and either grants or denies=20 > > it. The more information there is available for the allocation=20 > > requests the more > comfortble the expert is backing up the request towards IANA. > > > > For example various 3GPP CT group secretaries have done allocation=20 > > requests to IANA during years. > > > > Regarding the User-Equipment-Info-Type AVP doing the new allocation=20 > > doing it in RFC4006bis would be "easy".. assuming we finish this=20 > > discussion into an agreement for a need. > > > > - Jouni > > > > 7/5/2016, 8:31 AM, Dave Dolson kirjoitti: > > > Maryse, > > > Referring to BCP26, https://tools.ietf.org/html/bcp26, > > > You can read about "Assignment by Designated Expert" in section 3 > > > https://tools.ietf.org/html/bcp26#section-3 > > > > > > I don't know who the designated expert would be, but I think the=20 > > > first step > > would be to begin a thread on the dime mailing list to request the=20 > > new allocation, justifying why it is needed. > > > > > > Hopefully the dime chairs can provide more insight on the process. > > > > > > -Dave > > > > > > > > > -----Original Message----- > > > From: Gardella, Maryse (Nokia - FR)=20 > > > [mailto:maryse.gardella@nokia.com] > > > Sent: Tuesday, July 05, 2016 9:16 AM > > > To: Dave Dolson; dime@ietf.org > > > Subject: RE: [Dime] RFC 4006 bis - IMEI > > > > > > Hi Dave, > > > > > > Do you mean, in case this new value would be needed, it is=20 > > > possible to handle > > this via IANA allocation w/o impacting existing RFC 4006? Could you=20 > > clarify this for me? > > > > > > Thanks > > > Maryse > > > > > > -----Original Message----- > > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson > > > Sent: vendredi 1 juillet 2016 19:11 > > > To: Gardella, Maryse (Nokia - FR); dime@ietf.org > > > Subject: Re: [Dime] RFC 4006 bis - IMEI > > > > > > Maryse, > > > OK, I understand your question. > > > > > > Reading 3GPP 23.003, IMEI and IMEISV are clearly defined as=20 > > > different things > > in sections 6.2.1 and 6.2.2. > > > And RFC4006 specifically says IMEISV. > > > > > > So I would say RFC4006 is not ambiguous. > > > > > > Also, the most recent 3GPP 32.299 indicates "The used value is 0=20 > > > for the > > international mobile equipment identifier and software version=20 > > according to 3GPP TS 23.003." > > > > > > It seems reasonable to extend to a Type 4 for IMEI, but there does=20 > > > not seem > > to have been a need, or there would have been an IANA allocation=20 > > (which does not require RFC revision). > > > > > > Perhaps you could explain the need to the group? > > > > > > -Dave > > > > > > > > > -----Original Message----- > > > From: Gardella, Maryse (Nokia - FR)=20 > > > [mailto:maryse.gardella@nokia.com] > > > Sent: Friday, July 01, 2016 9:02 AM > > > To: Dave Dolson; dime@ietf.org > > > Subject: RE: [Dime] RFC 4006 bis - IMEI > > > > > > Hi Dave, > > > > > > Indeed it was not clear to me whether the current definition=20 > > > explicitly excluded > > the IMEI or not. > > > I was wondering about the behavior of the client in case the=20 > > > Software Version > > Number (SVN) is not available. > > > > > > Otherwise if a new value is needed for this distinction, I would=20 > > > propose the User-Equipment-Info-Type AVP to be extended with IMEI=20 > > > value > > > > > > > > > BR > > > Maryse > > > > > > -----Original Message----- > > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson > > > Sent: jeudi 30 juin 2016 19:39 > > > To: Gardella, Maryse (Nokia - FR); dime@ietf.org > > > Subject: Re: [Dime] RFC 4006 bis - IMEI > > > > > > Maryse, > > > > > > If I understand correctly, you are proposing overloading a type,=20 > > > distinguishing > > the types only by length. > > > > > > Is there precedent for the overloading you propose, such as a 3GPP=20 > > > standard > > or de facto standard usage that you can cite? > > > > > > Otherwise, IANA may assign new values for new types, and we aren't=20 > > > short on > > space: > > > http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtm > > > l# > > > aa > > > a-parameters-41 > > > > > > > > > -Dave > > > > > > > > > > > > -----Original Message----- > > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Gardella,=20 > > > Maryse (Nokia - FR) > > > Sent: Thursday, June 30, 2016 12:59 PM > > > To: dime@ietf.org > > > Subject: [Dime] RFC 4006 bis - IMEI > > > > > > All, > > > > > > As part of the updates to RFC 4006 I propose to consider the IMEI=20 > > > also when > > refering to IMEISV, otherwise it is not clear if=20 > > User-Equipment-Info-Type value O can be used for IMEI. > > > > > > > > > In section 8.50. User-Equipment-Info-Type AVP in RFC4006,the=20 > > > following is > > specified: > > > > > > IMEISV 0 > > > The identifier contains the International Mobile Equipment > > > Identifier and Software Version in the international IMEISV for= mat > > > according to 3GPP TS 23.003 [3GPPIMEI]. > > > > > > Which I propose to be updated as follows: > > > > > > IMEI(SV) 0 > > > The identifier contains the International Mobile Equipment > > > Identifier and Software Version in the international IMEISV for= mat, > > > or the International Mobile Equipment Identifier in the=20 > > > international > > IMEI format > > > according to 3GPP TS 23.003 [3GPPIMEI]. > > > > > > > > > Differentiation between IMEI (15 digits) and IMEISV (16 digits) is=20 > > > based on AVP > > length, would this work? > > > > > > BR > > > Maryse > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 > _________________________________________________________________ > ________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, Orange decline toute responsabilite si ce message a ete alt= ere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not=20 > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and=20 > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have=20 > been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Jul 6 09:30:58 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132FF12D6AD for ; Wed, 6 Jul 2016 09:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxYFFOhyHN8v for ; Wed, 6 Jul 2016 09:30:54 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0128.outbound.protection.outlook.com [104.47.42.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7387B12D616 for ; Wed, 6 Jul 2016 09:30:54 -0700 (PDT) Received: from BY2FFO11FD028.protection.gbl (10.1.14.31) by BY2FFO11HUB028.protection.gbl (10.1.14.139) with Microsoft SMTP Server (TLS) id 15.1.523.9; Wed, 6 Jul 2016 16:30:53 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.39) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.39 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.39; helo=plsapdm3.corp.sprint.com; Received: from plsapdm3.corp.sprint.com (144.230.172.39) by BY2FFO11FD028.mail.protection.outlook.com (10.1.15.217) with Microsoft SMTP Server (TLS) id 15.1.523.9 via Frontend Transport; Wed, 6 Jul 2016 16:30:53 +0000 Received: from pps.filterd (plsapdm3.corp.sprint.com [127.0.0.1]) by plsapdm3.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u66FbP1i047007 for ; Wed, 6 Jul 2016 11:30:52 -0500 Received: from prewe13m08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by plsapdm3.corp.sprint.com with ESMTP id 23xav9cary-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 06 Jul 2016 11:30:52 -0500 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 6 Jul 2016 12:30:50 -0400 Received: from PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8]) by PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8%24]) with mapi id 15.00.1178.000; Wed, 6 Jul 2016 11:30:50 -0500 From: "Bertz, Lyle T [CTO]" To: "dime@ietf.org" Thread-Topic: New I-D: draft-bertz-dime-perflowmbr-00 Thread-Index: AdHXoI27HhmJQL9SSVCCcgs9eQDIkw== Date: Wed, 6 Jul 2016 16:30:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.44] Content-Type: multipart/alternative; boundary="_000_bda537d9971b46858976bb40b11ef23cPLSWE13M07adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.39; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(7916002)(2980300002)(438002)(199003)(189002)(19580395003)(107886002)(356003)(5003600100003)(106466001)(7696003)(11100500001)(97736004)(6116002)(19625215002)(15395725005)(7736002)(50986999)(790700001)(2351001)(7846002)(68736007)(108616004)(110136002)(33646002)(19617315012)(230783001)(229853001)(2906002)(16236675004)(19300405004)(3846002)(102836003)(450100001)(260700001)(84326002)(5250100002)(8936002)(512954002)(586003)(54356999)(2501003)(15975445007)(8676002)(1730700003)(81156014)(7906003)(92566002)(87936001)(6806005)(189998001)(5640700001)(4546004)(86362001)(81166006)(24736003)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB028; H:plsapdm3.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD028; 1:w+dhnvlLhkuBmJ0ECagBb4sCeghERPAwru+HrH7Bmn9lM8nYMspMRnmhoXH17BvrYE9Jo7c9WnkCna09EIJsptoSIwIJcUgSRHRwAn2bVVwNRQ4TLrX6C7+dRbz+TULvku11qm04jtfRmVAOLf2rC3Iip+/XTIoSQt/nkq7dSL22wC1fQ32qaqg55d7WgBqvPUc+N6dte83tRQVagosT+/XUk1LFsngeSOesR3ts5DktT5PXAqwdyahP2WcBhzFu6LzdLiiOhMW0kbZtLGUt8jzGVAL/mfHQyfLOZo8cI6ple2baV4RlJVi+ALMdHcE6xALLr5zVUO7dxYfeijeJ82HkwEdlIEoMiDJam+zQIBJ0DZpNVeFpICekMtEdXi8nli89RQQptVG8RAD69iljfMbhVsPPLIbeNNEwdrjapTikbZdxT+Ttg/suZmSkQ2eLgtRJZH4vCudIr9NYfEkr20nnoIqk7alD78d/C91Jxy85ilm0NEMGvHL75htA24wgYTSKV73dkGrT8XFUtxxGGQIN7H5MTI77vf3kNgvyW94= X-MS-Office365-Filtering-Correlation-Id: 842eadeb-f1b4-4250-783e-08d3a5bae627 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB028; 2:+QeXSD1aCl5gQXqq7PYXXpxxe0rlxBXvrWLkSJX+1ezkcmnSHR1k2xyEanp7U1dq4u8Zs6d2jZIHBaqL3HNTL6Ly2ezHdFzp4/gZVujvtEpfHsFqhLDiZUD4hpA7ws+/1GbjIl0KRacljSMgHP8CDwN4hLHbYotkTMQ/eTVDdrR82TCbD2wZdUlnZLCadP4B; 3:S6k6FbFdSkLeo7a1KOKBYM4+LK/nzVONqVGv3R3HrzQaxRC+5SIhnm5p2eYTxSkIZU8KN8zq5TanAogVsZFLAF0q8/yxW17WQGuXdb3Ut9iABfGXAE3KjjA1r5qGiPsORP9dzPNdb1j1/sEfVVXYKsTA9dYvXkYPKMpcwSUysfGrJAPGGPxWNiZN+Qn8EV59R09ZadvFW5i9IFJMDbTmRrayPP6Pp8SQIfs7l2ZERDWHwRwph4InuJ2Z1AThjHsbJW4+31WA/uL6k7kyd79GcQ==; 25:3KmdAfcDMsBgEOkOPyeCJT05yjLkP2sY7ksu8d72xeedKCxgiv8Fn28U1FMZFf3bXGt4DpygmkvUAnfxl0ZLYPLmqcxOMJcnpRGdbd/48rucOlMVZXXHrgG7bQgcxhbE3ofSSkAE8OKSLfXw6k7hgoajorukTQLoTqMf/Ix1UYviMLlKX1vx87zwsLXW8NAeXiC7NJNybVRAU9t6lcAJqsecxWFKkgB+vbVyA1uNx5opHZTmqI27OFzRQ49CH2r6GIvxz9sP46S9h/UxWe6Dx0qi7SNCP1HFYWMKF3mIHmYXwVyjCg5xwezpU85d7CPoendpfW0nd6fFOC/XnfcvqaJN/KjQu+mxHqEwuXpqXGzDQCVYmJJ4U0FzU4Ro5pc3bH76qaGUNOZbSukJs3CmXyV/8NASXfDENYBaXpoalLaiemLmwx4Kh25eMlf5Yhqv X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BY2FFO11HUB028; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB028; 20:fX9pfR2x9T16dVg0bIWn+4ccA5BmgcR2L8+wavVBCjfQWZ37++LCPmv6vpzABzajzOS49PWCi0DytUMLC6YJNfUd1pRZMmXpgoYTlPe3RBoAS72Mh+/RFVwdd6VtbJz9G7C52cZmsGlFKhdSvuWKfyFqRoeU2XFXIrMlUXPsl4bjKyodVF7HsgokVcllCbEco1lP+Wj9AU5Prno4ypY7VD2Z0sF4ERuvuwguArVQSz+n7I9MQKJ1V3sWtk4CvKJLtClpS41wYWIYxU8cN4v3hB2KpDeW/izsY8BJ+OoZyUOGUFcKrsIar7FDbkDSBZ6pCe3Cx63+vZdFuvmeQl5bIplOl2Acx5J3IEH4yMJO9DABf3i+qeLbIgRnfTEa/ZscWhIy4dbBuYjk0rduz+mhEQub9/23nYSLsMSIM6XEyLA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(120809045254105)(18430343700868)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13017025)(8121501046)(5005006)(13023025)(13018025)(13024025)(13015025)(10201501046)(3002001)(6055026); SRVR:BY2FFO11HUB028; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB028; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB028; 4:hdGPc9BSqXTpACOazLOU53E7N8koXbfPpnodkvE0oOxv663EUqznR10kz9z3VyVe4j4q8ly/QRJWrII1e1apV81q3iSn9CeEoF83+9pPMh2fCVq1jOfmNvH57WmtMy+92YCFC3mS+jB3MVKQcX1zH0OVoLra5AzljLGsNzxJPl+mwzFP4Su53hvCqCx364W6eMzxKZLsNECtVQEZr5hBHL223zsErYokIfTFyjDnyOepyQp6+azWz1nzWMUnXowQ+AQm1xJgoHa1nKgYRKNiZYorgYBuFFyUlk3OTJiW2QwonYCxOLNFjamuKwZW+9OpkjmnmMmFQ67imSSZMEEt/ppsn2QTJBcuhSiYw8wRfHcqq+/m71+zepTpP61eRKlvLYkoVVvuJ9/S85Cca+v5tI3u7BwcYpC7z925F7vnGxeGeLTPdsaPauk3/HEUc0a+/gBrv5CDiXe2slvubtT8LKFMKZAckrT18S1/oa8rXTrEltgCXjomxGIDFxHvU2/Thx+LrngcGY6enQLN3rukUpJyM945Iyk7lfLoeusOc3VWm1OFaF17oF5JrQFcjlSTfdSj3KeqF1M6DOMJG8H5eUa2DCtLvT9dSXxt1AvedbVmbNKqyRn9QhtM/jSmGLS1 X-Forefront-PRVS: 0995196AA2 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB028; 23:hAEK9T5t7g0rpjwG8QpT3dWRPu9gKvKpbHEBJ+2/?= =?us-ascii?Q?dICdj0csHO1y7AW1RICCgsPtYBRoP2oYsVjIb99WXZrlv/J5gJ0783gcJqgD?= =?us-ascii?Q?4f3iqiO+vvyuBQxXIi5DbtFADBcIroKbcJf7ef/JUooXjUEJrDsXnEa9Mvbl?= =?us-ascii?Q?hkCMe44F+xL97+ByIXstlhxbXEC+PQJOa+QUYEJTfNTNYUPKBbuQ8m6OVhUu?= =?us-ascii?Q?+f7+NnXuWrk18kBt5xuHBvp3jbDNEAPw+tlT1677wAUOTAdLSLKTDrgkw/I8?= =?us-ascii?Q?GZW1BjLNNk1y1DE1pPxesLSyPZOrvmcSH+rCTTNEZemI6r3zI4V0AOApMvW7?= =?us-ascii?Q?RBqnI92VezzcGfFihYbVXLcuHSAO2ajSFqBAwavxJ3QMGlepb6FoGe/MqHsv?= =?us-ascii?Q?HnJn+eizB4hm+qNFeaZsEqFTv5r7GTiHZm7udzHH/BhUDx/tyFyercHq5vK9?= =?us-ascii?Q?qp0fIg1W7p4gLeO3/zvBMAzkZXXMFCPSIrGwsplh3j0GafzXUoD9YRGIS1/M?= =?us-ascii?Q?fxsU1rp8EKql9JUFQ90NeAWUBfIi0GCRp16S7dM5CJzet+w/KiS6FfnMDiCf?= =?us-ascii?Q?W4LdojlgKpCZL3PY/VINqXaYm3e0k+6eB+XzBA6aFJUciucNjILurrKNfTfZ?= =?us-ascii?Q?aQq5Adl9RWkZaMQRLsJ5LOEzUsqPlc9i7AoIZQHJbPTIR1HjTw/7+ZsZOSFr?= =?us-ascii?Q?UiJ+nXE3kusAFQyQ6eiSpYBf/+C9MLZeCLwoqyUnpEwHwezG4k9yw9XoQWQg?= =?us-ascii?Q?zC39+3FMVu+J8WTqQLsZaqXiNfrN0uOCWTQKK7Sj1jQErx4eXIFJBufm2hxI?= =?us-ascii?Q?nuE396D6IJnxht3CpjrmrxKE5lAWwz1yLBInquGGdoluaJJcDy7myECQiaYY?= =?us-ascii?Q?YRtXYA+cTaNvhMVZrwfrlWx1r4oShxYPr6mIGsLA8VhP1PutJcZN9Eduv9+O?= =?us-ascii?Q?1C7LYceIOl66oNFpky0ZprnfGzdtnRvid3Mgy8Wlr7kaQlu+tFcuXX+5vJsw?= =?us-ascii?Q?4Nz7IT/xbyU/TEUoc/XCa2s++54ivAlidSsi2rio27My3/UpPLLPZ+fcCGiW?= =?us-ascii?Q?82LNwuFH37m+2bRi1uDpgyl+Mse9hDk/u+v0++ASrB4YO2Hx+jr6A2EsRyj4?= =?us-ascii?Q?i87XU2vaAQqxOFRz9H6JmPqE19xyKwgk7TEilC6OACYx2dDC4FKeG4YC0tUj?= =?us-ascii?Q?AiPUFu5fdbrT0K7pmqgXjZ+gvqvPXELmjSOMirJQw4dJlPDpZHnICl1cpQxA?= =?us-ascii?Q?WkIEDAtnTEkJ/8D7xVzUiCZ1yM4wD/t3iqEDdGmKJDzuP59qBjB3xpMC1FzC?= =?us-ascii?Q?IwAiWrMwwKkTaDXZEpi3FtJSvChE01ODAxmlWopVMzojeimZvMW7IfbsGR+b?= =?us-ascii?Q?DAsGsJ9puhDRFvqt2dk1jizoJrR83cBMUIK/6DaO9Qi/mjSWpot9EB7o2T4v?= =?us-ascii?Q?M0kNIkE+Jw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB028; 6:/p47PcPeN3ZFA0lweiVqpDo/0UrXjynM0km56YUdenZee9xRQEy5MwB5B6qs09Iz9+HeCFdza9+/j2TmhnBvupGksjledN9lZMxqvJgzbXfyXcP/40opddaLjfv7tVpbrtMDHvMWVhUkVrJgHS45zvtg6TjlWvhThkWMQDOY6tfIe7P/KOZyJUivpi6ARfFx+PXRfaJpx21oXSR0I6zdJsMWirE5gHRaFvdiTN/rSokAKajm23Jzj0lcpFSb9Bcltjmx4eBzLSfXfvtbJI+z+snWmXne4KOQDzAwKTDAXPBfqO1K1igFsn4Nh092fxuRGiSi1iOAK5aQ9CaBf1Uhi+WvsNhCj51M4hcqfJufFys=; 5:2HLX54D+YFtMh2NTSBViovbu5ConoqiRWxBgHZ7MCVPMZPiwZ+4C7M68hfd8At5kDEMktiYhsLl2t5kicy2ZcO52+QUlohaBZ7AArUfQSelSTroXPOIZtylAJTfeMMetXOcw2i4nFP+INHuWVY1OZQ==; 24:+WeKJlRsf9XCk6pt9/wF+hunsJKgblp6DLNZ1OSuQN34KGqQh61k3540KvfNzjscr01s0kr7/azJhPn+h6JWR/nshmw8c3qJL0E6UC20Ui4=; 7:vk0TH4iiuPXUKaV8mFniziiw9/J0kTBIpjdEY3Nz23pGzbFwS9H+z0Z+5H5t7/OKs89qiU5kecYpxNVypHtOVP8Ag4rJZR2cQYeqNoUwyFYgWlnwkCam5f3nMQrGNsZo0fH3ueAWw0vXkjy6VHkC4gDyvYpEmpL6SWC5VTiOKtjeeX3g5aHTEBwGYTSpOOief2PR72aWgFZ8m/9H6Dmzon5fLE6FfZdoaxkNM0SpY4DnldhGSIBBg7+1RjGMLA2n SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jul 2016 16:30:53.1190 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.39]; Helo=[plsapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB028 Archived-At: Subject: [Dime] New I-D: draft-bertz-dime-perflowmbr-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 16:30:57 -0000 --_000_bda537d9971b46858976bb40b11ef23cPLSWE13M07adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I have added a new I-D for consideration. It permits setting *per flow* ma= ximum bit rates. This can serve in some applications, e.g. video throttlin= g, to limit features such as resolutions as opposed to requiring deeper ins= pection. https://datatracker.ietf.org/doc/draft-bertz-dime-perflowmbr/ Thank you. Lyle ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_bda537d9971b46858976bb40b11ef23cPLSWE13M07adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,


I have added a new I-D for consideration.  It permits setting *per = flow* maximum bit rates.  This can serve in some applications, e.g= . video throttling, to limit features such as resolutions as opposed to req= uiring deeper inspection.

 

https://datatracker.ietf.org/doc/draft-bertz-dime-pe= rflowmbr/

 

Thank you.

 

Lyle


Learn more on how to swi= tch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details.


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_bda537d9971b46858976bb40b11ef23cPLSWE13M07adsprintcom_-- From nobody Wed Jul 6 09:36:49 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEAD126B6D for ; Wed, 6 Jul 2016 09:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLN5ZzcKNYcA for ; Wed, 6 Jul 2016 09:36:46 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0123.outbound.protection.outlook.com [104.47.42.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D246A12D13D for ; Wed, 6 Jul 2016 09:36:41 -0700 (PDT) Received: from BN1AFFO11OLC001.protection.gbl (10.58.52.30) by BN1AFFO11HUB021.protection.gbl (10.58.52.131) with Microsoft SMTP Server (TLS) id 15.1.523.9; Wed, 6 Jul 2016 16:36:40 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.80) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.80 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.80; helo=preapdm1.corp.sprint.com; Received: from preapdm1.corp.sprint.com (144.230.32.80) by BN1AFFO11OLC001.mail.protection.outlook.com (10.58.53.72) with Microsoft SMTP Server (TLS) id 15.1.534.7 via Frontend Transport; Wed, 6 Jul 2016 16:36:40 +0000 Received: from pps.filterd (preapdm1.corp.sprint.com [127.0.0.1]) by preapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u66GXguv016654 for ; Wed, 6 Jul 2016 12:36:39 -0400 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by preapdm1.corp.sprint.com with ESMTP id 240us6jqje-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 06 Jul 2016 12:36:39 -0400 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 6 Jul 2016 12:36:38 -0400 Received: from PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8]) by PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8%24]) with mapi id 15.00.1178.000; Wed, 6 Jul 2016 11:36:38 -0500 From: "Bertz, Lyle T [CTO]" To: "dime@ietf.org" Thread-Topic: New I-D submitted - draft-bertz-dime-policygroups Thread-Index: AdHXpBqnhBwS7hRvTsWnMfTVgDwwCg== Date: Wed, 6 Jul 2016 16:36:38 +0000 Message-ID: <3cae5ff501e74114bb1280d6d0468ef1@PLSWE13M07.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.44] Content-Type: multipart/alternative; boundary="_000_3cae5ff501e74114bb1280d6d0468ef1PLSWE13M07adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.32.80; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(7916002)(2980300002)(438002)(199003)(189002)(6806005)(2501003)(5250100002)(6116002)(4546004)(7736002)(5003600100003)(108616004)(97736004)(7696003)(19617315012)(86362001)(54356999)(7906003)(2351001)(102836003)(790700001)(8676002)(3846002)(33646002)(2900100001)(15975445007)(5640700001)(24736003)(107886002)(81156014)(1730700003)(512954002)(7846002)(81166006)(450100001)(260700001)(229853001)(189998001)(30436002)(586003)(92566002)(50986999)(356003)(68736007)(19580395003)(19625215002)(230783001)(106466001)(84326002)(11100500001)(2906002)(8936002)(19300405004)(15395725005)(16236675004)(110136002)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB021; H:preapdm1.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11OLC001; 1:RH3jXdPMSbpUU/YQrMOcedyscM7+Qq46WRep6+jdVSbjZ7XJnbJlejheOizG9Hz/RkH3zMCw74Fo5QGiWQDCKbWDwSoIG1YObYs5ApJsgDjz9Klz4JXhO7+dViZw6X3NoYFCr2fevZuwF6E1UF9vqHf0YAZWljw+xlnrCKkjIfOelalJ90wimpSoZQVrtK9JmGysCP1/KrbufbdSTAJ/iFkRV7UFesSEESCyBUrlwczkajr/mK3ziJ2e+8tpwOO0Y6c/XZAHnuVmosv6ZH5keUszVs/DzYI0X9JgUzFVhSqEqAfda58ShNRktEfv2gs++Mf2AyLRJeG5XCm+O8ZQcuFFE4pysoF/Ui8b+yVneu2BMdGsfjZ9sLyWNnOqtnAAKskmqDRZ24CoxbsR44bCR4SdTonIwAYDWGdoCnvvm6uOHqNfBLgUnrkGq3m5FU83QY0uKlKwwJj5MWMJH6xTVr8MOkbpH4PKJQ5vp/dFIBZxWm1li6f71wrG7tcxYxDe5sCIY0Sj+4C1S1mkqda9aXekasxhHVPskSNQsGHEob8= X-MS-Office365-Filtering-Correlation-Id: f6eeaa2b-6960-4def-f6c9-08d3a5bbb509 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB021; 2:dTJu/3UiaGmquNvw0HiG3MBTUKVAW5tYlob/Ch/xXhYPySUAq6BOBbvFs2F/u1FyG51fnVCgNk+NCH+lVB0Dp1XJBEh/eX2Aht1QiSTvGmhlRBW3ktXKI7V3V735S9wXR94I31GWVeTYGuy9osU33s33K+SHzfdsv5CvbMtRbiZhx9dW/Kh3XXJq+DkkyqQY; 3:/UkIrrIyiJbkN7+CxzdYaRmVEWW8qY73d2hPhkoEcgXhBgTTA8nOkWHdG2s4ihzGNLoq/CRrJPCD7tsr9x88xSkn0NwcWPey9BqZWLUh3cH2uQ2d6RwadrReY61Fr1TGNNiCLl0UD3diEU68vWepawNLL1dq4d9lglQWGKdXYtPerva4HQ+tp7YvQRGvfDlvMUzKWConaiVqZ23wCYWvT/guxmmOrI+8/adS+KRv3X/H4vrBLD2QEp+GZvMWt3MmsjoPDBpk5xD8hAjQ9JD2gA== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BN1AFFO11HUB021; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB021; 25:EprPUSwpOJig42UolfPHlPBjALr5Wga1u3F0n6v?= =?us-ascii?Q?xWVEfUVySpOe5ZOSxdBRQTni7fSW4v97kbFGHnHdVBLvdBSzWMOKqwR9b+ZA?= =?us-ascii?Q?Nu0c2AZwDl06unZIlygCWSkpFdJIUX6iaLHBO6rU0zB9Uo7YrD443jx9jzyW?= =?us-ascii?Q?7rRphPA0rVvMxnqV4YMFDLgJUMCBj5sVXCtIo8vXSpyGKC6LMyZgRlNgHxv1?= =?us-ascii?Q?VgGQvNoMndaD30sGH9/WnXz6JPskECQ6ujSIne8c7hFKZmOjvRu2rcWfnrvS?= =?us-ascii?Q?jSSFpf6AAqV/mCi69ihNLdd1px4FE1XJLGRX5kyEaGnOOzna8BJewOnRqIKj?= =?us-ascii?Q?mJD7d8d+Gy/dUnGS6JEyG/3j9XIjFQuDt2ny9G+vqCxYSUA7U9KTOphfCH+A?= =?us-ascii?Q?ejX97o9HpCg7qvZgIrQTVYw7Wj3fS4n5pEsuXhyHnA79hJHXJesjr8UY4L8q?= =?us-ascii?Q?25WONJDbg2KxiEFDlXfJXOTS7wNEscbVcx8ul9791HDVXRQEiTpuWsgZF1Nk?= =?us-ascii?Q?qPZXmlR1T3Mt2R1S0cOrzzgL4VH/8qtcZgCWZ0lWztjhjBOKa6Ko/9pqmnUB?= =?us-ascii?Q?jZqfUL2Duqo6B7LCCsk1Xdow1+Ck75Liaj/6ospHUCoq3D8PP80dV79/frz4?= =?us-ascii?Q?z8PT1M+RElc+Z/AjJPqqWocJ+MPQro0486D2JyryTZ7E+qns1V9FWRbITY34?= =?us-ascii?Q?SNu8aZo5h6uq7XSvQUGCeFBWpZlVh8hnyq9XHOkpSvY3dJpPXrSc5tnxvqi0?= =?us-ascii?Q?ME7OLqHfAHys5fR4mtuH33dxHHsIcc6OOFpBHeRsbieEtbihUr6GvME9A2vw?= =?us-ascii?Q?7dSwbYlATo2yOcElm+XExf6A31p+ujoxqASXLceTENkpk5vAWc1tgsgEF0R7?= =?us-ascii?Q?lNKHqBAoPBt0T/AyBwoC8CH8yQ1WpX9+9JlgDAiTjsbFI7cDUmWAHVxkM5nP?= =?us-ascii?Q?2DqUwHZFtovnRW1v6lv/sdtpiEEGIZL5Xi8bB1YC5z62X8OCDlPduyTJj5I3?= =?us-ascii?Q?Cfp9cqUb6N3vmSuvmqkLrXiZWJJuhArFZjTKSo+kbqsdGpfj/ltDx/EiRQgk?= =?us-ascii?Q?a+14MsSY=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB021; 20:RC5Ib2WtlQunK5Io7ZlcpQIvxXVMlXcx/M4UX2wa+C+25G6bWW2H6Tm5ggDpH4Ct8Ejr8+DUjvrBg3DX+6SveZMWHx3LdDybuWGlvSHnZp4M8vmcO0bXxC9PvV0ZsGqu3tC7WZQ9qAObz2GK/V6puoI71rXkkBI6tCbtt/xWslO5w4CBZ4kS8pIuGX6qf75Tdsjoq1vvIxnPjXel76NUbsp8qeF3UmIACq4BtGhbpgj9rhAbMI4WaxQHEWnbPyJ4l0DGMZmrA6QOc1xZ/85+BviGil4MxMc2er6C5/OPyLwILEQMfPg4CwnUNNfFh0yM71wO0E4lbR1NSRFPFCcZqCUHf1mLTQvg3UyzlqITlgeBa0wx6u9qzhc03DJ/p0vYQNfTVCZ73yf0fS/aKYabUscK2/EEWuhv3Pinl+nXip8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(18430343700868)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(13017025)(5005006)(13015025)(13018025)(13023025)(13024025)(3002001)(10201501046)(6055026); SRVR:BN1AFFO11HUB021; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB021; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB021; 4:w7q0M/u7CcySHhEls0JMcOjSAUobMdWQiB5pi5RmDCrfu3xt7IEI4Krp12exWhbokmnvCixlFgLKeeLHeF4aFUHEx2J3bI1iZGJgwZYTpllHgLvypVF3ijh2MK9gOyMIv3aMXVcUZ9LkxrTeuPg3W6DsJF66CnZa2KM8vxqILG1mu8D+6ho/t5cjemLqrFjnH1ANTxVhdcO3mDJcw4EsYw1XMbOSXL1Y4HKqFVot9+57/mDSX2phn2sTOZ8LpAvcxKrfOgh/mwL8iL1U9jFKgqIi49FZgqdw4QPlqyoOCgUWFu8QtU53tzxRvuN4fkKtptG4IxXDZHIWtJ/sLdw0yeVKM01IQOnNij4HgTLV2OgNFbmrioa11HbxOsdTC5rNaxX7//Th2vsgbJcfKKdJzDkJijosMZScQkg7v1EBU2LUHiwSXK3XTSHGcy8mOIKr17J12BGzhQyQuHo1sZ93I2u7DCMlIg1mCGSIFiSRgElrj/4E5LjskANpXOAya7gEdgyDKXQLBSBjDPYIORamnnfj10WWfXxzHvJqtZQAF0w0eI4Kl4coi4X30947vEX090pM7hJ2ytOuPqslmm4SMg== X-Forefront-PRVS: 0995196AA2 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB021; 23:q2ke1YfwEkPySeGSz9833fnR2M7MGYyH5XFeB/G?= =?us-ascii?Q?umW9sNOKqgihUDTaw31LQBs8fjhX9w/puH4AHlbgov+NCuhgXMPr9XMVYytV?= =?us-ascii?Q?tSYPEK08pIeJxKC+2wLio10UJTEnSlDtrzco4uRWAkTOxbhHXfKP5CjOZIn0?= =?us-ascii?Q?TwzzfA8OigHQQgvdSp1bY+Z74CY5n90he8tHphqjEK3Y9QvLuYMdYT2c1F5a?= =?us-ascii?Q?LeMkjFZ6bwDeGkmhAT1R6GpVn5cLZNnzYRTVkaohh6ByOa/zjY/3aBWlR/Jq?= =?us-ascii?Q?LJYqk1tsydEmz5suRTrwJ0++vToz1Da1rF0KomSCe9zlg7SQlmNAzSWJz4Iy?= =?us-ascii?Q?RhNUaggT6D6rpfpAmAPZcN16o7xz2S8XI2IWfxc3ZC0jzOS6L5+Y511oJEx/?= =?us-ascii?Q?JRJTBusu3QGX8LV0hOa4flUjk1X+U2D4DN+sAa6tLMQtILJ+C049QVg61qwe?= =?us-ascii?Q?FFi8bjGKJdRS0JHVWE2/uWeP7MA1oNP5dmiXmTQ1KzhSBQ9ZDzSF8Vb/caqa?= =?us-ascii?Q?OlVuFzEkrjEaAt2RoLhTdUFDwpzomkNd/Fk8C2oVtkmkxWggmc3ykqfk2Dj2?= =?us-ascii?Q?QYWWzG6nKp+5HN2WfGLrOJ3gy04syng6Dk3Ajs5LQGjF7ek+hBu43j7MvzC5?= =?us-ascii?Q?BW4D+uVe8pcqyNshJBxM8ro7A64aMjtEVLjM86OrecgnSLU1gT5/0j/1tc3Z?= =?us-ascii?Q?NCzbsWpTtES9MdP9sizDEZpFchRb/Iz4iNFedV6J8RPDVniktIfEzrj0Vu9V?= =?us-ascii?Q?TEkDdEefREfUC4mMZgU38y3A08I9x2tqSFg6ucngQmKRLYHPtWC4ZWExVcfP?= =?us-ascii?Q?aChy1+52MgjZqrtAq3Q8m3RuniQhy8IRqc5KJTOb+lyBJFL+eqhebPR2L0wG?= =?us-ascii?Q?OwlTAe8e5MdE7l+u2gGxzrChnbZAyaASrhNUAjZ7HLc/s0bbVTL33sjcapuT?= =?us-ascii?Q?EDSPoZdJCPn58KauApPG7mDNPuGZHyMXLjiRX8PQZocjhJTDs5hztVAXWpXM?= =?us-ascii?Q?A/bVvJmmOCNVDonTPX0vVpMOgRB1zZczXmnL3ZrHPrzqMxhaXlPy8WNbrp87?= =?us-ascii?Q?l7YVRsCp7V+mZMXOVAcD0LxaqucF67Mfx5MVO0fIJJfumeMx0HSc8se0qE3w?= =?us-ascii?Q?XwmNdKr0R/d/qDria6M4FjpEnjGdgWgO8DoG0QI9bVL4Ia1SoerRH98wmm01?= =?us-ascii?Q?mfL2paDqbxBO26QzM6bxIqzpZ4I5s5/ejsLxPRk+LGqcqHDxtHWSqRT65VgL?= =?us-ascii?Q?rewl6wGiu+2jagd/3jHivhSqm7AiYX+h/FXT866GohQEtUmOAgHPH4tF10eq?= =?us-ascii?Q?WVtMHjwLoefdh8moHpK1ZoZZg8UaV36dGOFR4HNQ/0/kGJZHRz8LVWnry1Nt?= =?us-ascii?Q?u3bPtK5PxIcoxrMkufmvw+u2KCZjwNUrUD6eZXKDd2Hi9xuxBiV/HlG1wAKV?= =?us-ascii?Q?djBrDSNkUnpwXUiTTLcOAwWFUMy8pSVs=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB021; 6:UjE8cZHNhnVz28cA/BhgR3OA/x0fWlkjmLZY5LxG6XmW1U3ECtWu0ys9uso46qz188ksYMdW9awakP2nieCb2vLBgHskeCNbBD98MLx9nVKnUYa8XAYNfpMo42h9qUP9O+gCOyDK797AK5HZDMIo7X68Iej7RZYShavpdmdYeduUzTYfa46xY0hBibLAtaoCd51qj5PJV4sBtnAWRSbP7jhoOA2uuf3LhuiWUvpI06mnhNgq4yddxqxLivCqBm7OiQWgSQAwUZqfZMBWxyvmj1dI3gCM8GKdh1pepuMbP8DTnyEGLXsfn21cC2s3WP3FGneesoXYXqlLDMjLZ0MLmU+DNwYsLkwMFACzTJqBvkc=; 5:7dR5pKRixwuo1J0avmFUUyBUAqygmftJUuTLaflvSLDJWzsZK0h6zV70tzG1ejYXV++6Hcg5rpz17b1P26X/OpYElxIa04j+QiYgjLM0A86RPRD396e+IYJW10J8+3BC6kS3LSW5Kv/H2twjWuUp1g==; 24:WZ7sw8+qwqT/82iQim8D9KS7QnHArzdznqD/rlPTUwdZUq96xlR7SO6arPjUzeNDcglO+p57XDmTSUayYLdjsTRFXDAF0n3aJiEjM8HjUOU=; 7:3aE+5Z0xVKdMA4oMl0ObIkyMQi27/8VTQofH6TqX5Ob9RZOoRTZqNSVPPkyb4O48P9K8PULeL6iphQH0nGrl6CFmCzvCgwhdUOxzst64sQdjX5dV+zUI++4Pgyg7fnnOjCmz3beVZxBmQGlhnWYJxreUx7zderX7XFxqVK8UZJop8juHMuKzUnzNRyxoO3oLnZ5F93LiGIHk0SBZQtJie8JxBQ6FkEmiXMYM6kYpAhjfknwh9WYvUBn6/sPfdW98 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jul 2016 16:36:40.3544 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.80]; Helo=[preapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB021 Archived-At: Subject: [Dime] New I-D submitted - draft-bertz-dime-policygroups X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 16:36:48 -0000 --_000_3cae5ff501e74114bb1280d6d0468ef1PLSWE13M07adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I have added a new I-D for consideration. It permits grouping by Base-Name= (common in some 3GPP) function as well as membership sets (bitset membersh= ips) that permit rules, filters and other policy entities to be used as a g= rouping mechanism and to support patterns for policy based provisioning. https://datatracker.ietf.org/doc/draft-bertz-dime-policygroups/ Thank you. Lyle ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_3cae5ff501e74114bb1280d6d0468ef1PLSWE13M07adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,


I have added a new I-D for consideration.  It permits grouping by Base= -Name (common in some 3GPP) function as well as membership sets (bitset mem= berships) that permit rules, filters and other policy entities to be used a= s a grouping mechanism and to support patterns for policy based provisioning.

 

https://datatracker.ietf.org/doc/draft-bertz-dime-p= olicygroups/

 

Thank you.

 

Lyle

 


Learn more on how to swi= tch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details.


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_3cae5ff501e74114bb1280d6d0468ef1PLSWE13M07adsprintcom_-- From nobody Wed Jul 6 09:42:52 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBDC12D13D for ; Wed, 6 Jul 2016 09:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-8sDj5YYHlR for ; Wed, 6 Jul 2016 09:42:48 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2B212B039 for ; Wed, 6 Jul 2016 09:42:48 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Wed, 6 Jul 2016 12:42:47 -0400 From: Dave Dolson To: "Bertz, Lyle T [CTO]" , "dime@ietf.org" Thread-Topic: New I-D: draft-bertz-dime-perflowmbr-00 Thread-Index: AdHXoI27HhmJQL9SSVCCcgs9eQDIkwABGo+Q Date: Wed, 6 Jul 2016 16:42:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830FE6E7Fwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] New I-D: draft-bertz-dime-perflowmbr-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 16:42:50 -0000 --_000_E8355113905631478EFF04F5AA706E9830FE6E7Fwtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lyle, This document doesn't define a "flow". What did you have in mind as a defin= ition? It sounds like you are thinking of a TCP or UDP connection? So if the inten= t were to limit video rates, each TCP or UDP connection would be granted th= e specified rate? -Dave From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO] Sent: Wednesday, July 06, 2016 12:31 PM To: dime@ietf.org Subject: [Dime] New I-D: draft-bertz-dime-perflowmbr-00 All, I have added a new I-D for consideration. It permits setting *per flow* ma= ximum bit rates. This can serve in some applications, e.g. video throttlin= g, to limit features such as resolutions as opposed to requiring deeper ins= pection. https://datatracker.ietf.org/doc/draft-bertz-dime-perflowmbr/ Thank you. Lyle ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_E8355113905631478EFF04F5AA706E9830FE6E7Fwtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lyle,

This document doesn= 217;t define a “flow”. What did you have in mind as a definitio= n?

 

It sounds like you are= thinking of a TCP or UDP connection? So if the intent were to limit video = rates, each TCP or UDP connection would be granted the specified rate?=

 

-Dave

 

 

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO]
Sent: Wednesday, July 06, 2016 12:31 PM
To: dime@ietf.org
Subject: [Dime] New I-D: draft-bertz-dime-perflowmbr-00

 

All,


I have added a new I-D for consideration.  It permits setting *per = flow* maximum bit rates.  This can serve in some applications, e.g= . video throttling, to limit features such as resolutions as opposed to req= uiring deeper inspection.

 

https://datatracker.ietf.org/doc/draft-bertz-dime-per= flowmbr/

 

Thank you.

 

Lyle

 

Learn more on how to switch to Sprint and save 50% on most Verizon, AT= &T or T-Mobile rates. See sprint.com/50off for details.


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

--_000_E8355113905631478EFF04F5AA706E9830FE6E7Fwtlexchp2sandvi_-- From nobody Wed Jul 6 09:44:23 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FF112D0EB for ; Wed, 6 Jul 2016 09:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQqwS4FqlL_0 for ; Wed, 6 Jul 2016 09:44:18 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0096.outbound.protection.outlook.com [104.47.40.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70BB012D629 for ; Wed, 6 Jul 2016 09:44:18 -0700 (PDT) Received: from BL2FFO11FD005.protection.gbl (10.173.160.34) by BL2FFO11HUB013.protection.gbl (10.173.160.105) with Microsoft SMTP Server (TLS) id 15.1.523.9; Wed, 6 Jul 2016 16:44:17 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com; Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BL2FFO11FD005.mail.protection.outlook.com (10.173.161.1) with Microsoft SMTP Server (TLS) id 15.1.534.7 via Frontend Transport; Wed, 6 Jul 2016 16:44:17 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u66Gfr5T003022; Wed, 6 Jul 2016 11:44:16 -0500 Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by plsapdm2.corp.sprint.com with ESMTP id 240mg44mxs-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 06 Jul 2016 11:44:16 -0500 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 6 Jul 2016 11:44:15 -0500 Received: from PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8]) by PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8%24]) with mapi id 15.00.1178.000; Wed, 6 Jul 2016 11:44:15 -0500 From: "Bertz, Lyle T [CTO]" To: Dave Dolson , "dime@ietf.org" Thread-Topic: New I-D: draft-bertz-dime-perflowmbr-00 Thread-Index: AdHXoI27HhmJQL9SSVCCcgs9eQDIkwABGo+QAAAmleA= Date: Wed, 6 Jul 2016 16:44:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.44] Content-Type: multipart/alternative; boundary="_000_d5a2213039d44096b87253727dbb8d6aPLSWE13M07adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.38; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(7916002)(2980300002)(438002)(377454003)(189002)(199003)(356003)(81166006)(8676002)(87936001)(5250100002)(19617315012)(33646002)(81156014)(84326002)(86362001)(108616004)(11100500001)(92566002)(2501003)(260700001)(7906003)(7736002)(68736007)(102836003)(24736003)(19625215002)(97736004)(15395725005)(5003600100003)(7696003)(107886002)(3846002)(6806005)(6116002)(2906002)(790700001)(19300405004)(4546004)(2950100001)(19580405001)(5001770100001)(54356999)(7846002)(76176999)(189998001)(2900100001)(19580395003)(8936002)(50986999)(512954002)(15975445007)(230783001)(586003)(106466001)(16236675004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB013; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD005; 1:dI/+lRoUK72IPZ6wD21qujP/g5VAPZa2BkljpAyVfmuYlL77+ys1I/brHwnnWjZeuIsToO5RvRT3pfkEldI39YqK27Ss6w+GEQPtsliIKMkipZAGqmDYvr3arAhBX4J4l3lpZaoaFgKpAh6nollPBPoX+a+WSj4WrlSlq1A/ERtnbAvSeGfBw/bU9PYnwfcJKfE5GVHAtAdPQjoQq13WKt5vAkgEvc9dOEy/vdsbqq5ZStOi4g246LeQyooh2TMZTveONY9fjyugu36aF++2DZioInrHmKn2cDqoRvFoMYusPterJIwzOlR90pVXGjz5d4Z2r0aKVcuh6Rfvdj6Iyws/RvzKQEuFa3+dw/oqEVyFdk4vTW5aJGRNl2Ctf7wmIXLh+pNi06pcE4l+qCGn05m3e3CkE1H5bB4xiH/ZzXaQdZafvP69jUJLpiuZvj9oc86JRj4+zjqGMu+Jb48fJS7E9pPm9IHUexxfk/rp1VMa0mJRlBhkF59Q9/mkjuBtuj5hwcNVRLYrjD16hKsTmXp/fdtmEXDMq0dJH9xaIFsb5BugIyVf8V9FAHRIFvGf X-MS-Office365-Filtering-Correlation-Id: cca956cb-90df-4cf5-e035-08d3a5bcc549 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB013; 2:VNTImWxAIqbiRchyOaJ5doCAwJcXvDtrCBaBPLieL6qRH4iAWTJ37vaDenwqqtbfzSMz0oAK5febd1b/v2qYi9B6AZv1p6IgVUVbuTEeTsUj9g6B83GiDy0wMm9kHLvw/kvYdCsqJROaF8hzvL33o3DMjXcZNCg6lXZyFBm8GLNoED+yVSHLK9HovhWLopX0; 3:6R5Wp5Ub9EongPmMnG+OOL0xw2F/0lpXJsaUYQdhZe5hjPZUcj8TyGS4UpIk+s9gd/5GVo0qbQnmLmIqZtQKDDB4iSbRXzcn1saxuQSNX19vLvGBP3dNivKTJS6ux8FICn/GMPMg77Lce7GmGQ0C6gOE8/SjGjIDf7oRcK6WE/jis+oOvzeEBKSPDk1rRafNb9aNMGiSDHDOv82nI34RfrCot4ki9pva4oQTi18amu8p8b8C+ebOy2vTNM2eiAtHv14/ByKr7RczQdEZ0nhXtw==; 25:ars+RvWv/LRqibFOFDZDVP/Z67VUUxrCA8hZD2v5vn5o62jHv8OOebgGjehUJJoG0/Wc0/YmB5gA+veHR6ARSqwm0l6K8GZJ78ixSznyUyo46qbrTXd+/1hrVzMJA7/hUC+uQtsWuCGN96ISLgauFv+zWAbWyCrOtk29qmZjchs5pSL+oTZ0nrVjQoJPffbY8RSkxTcgJz1Wu5+hDGq66OlbScCTUwoGKeii5vnBf6Y9d325ou5N9CkIiADbIICG/KG5Vd7uUFvHTCwOMirkefuCl7x/AqjZzmsVDOL9UvqE5H6M2fAoZnNFDsJflUeL32I2fjk6fFGo4GgLbRCBT3GNx1iE4gSv4+J+IIFs5lUVgklzX9WPyr7q7S+Ei4xp8d2Y7AKy9C82zplG1LotkQQtCHeYLOnlIXd5hcykicmHiJgqeEo/qESQQi4YA/hM X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BL2FFO11HUB013; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB013; 20:AP743zrGQ9yEj92Wekygg2JbKOpBOCjd/vTiELbk05UYldCH8n70g2BDUL8wzqubiEtrm4LGuFx5TUqArMQVVtGf7EjC0vccFJH9jQ9/NU4HxfDO9+aXqxLe8RmAOE9ycZiRfSrIZt9aN+FNx6e6Bha7yOihEHcC6giS2XHYIJelhQQA30SiUfd4msimHHMi4fxwEEmK/6kMTilQV0i6Lnz0Cl3rItxsbCS3SgH+S3tZoCAn1ouSxDNkhtDbDA8+Sqyr7HngyBRB9dEj9eRP9EV51d3KkE9RAPWbozXUZiztAb6Gzo8SS1LwjD7O350kd2V4JsH2FdRVXi3qwjvElkOfwtql1YeJlh2Q1GBbZiKVzgEofbKhEfj532YkxAgOst1v8Fwgo9kKcQoTDUAmq7JUo/xLhaqXp4ld1H3k/5E= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(120809045254105)(18430343700868)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13017025)(8121501046)(13018025)(5005006)(13024025)(13023025)(13015025)(3002001)(10201501046)(6055026); SRVR:BL2FFO11HUB013; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB013; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB013; 4:cRIA9TK4dr78iIwIw9dE0pBHZlHDwtvUAKtox0SNf6Fa/aL5j/k0EyqcVDDllc65Qnkw+izXHIW7jgDXBd4vae9yjfK2GZnYM9rxy2U0mH2ETZ+HI4RW4/otI2hF5/P87v+CO4zjHXMOnBVTe0PCPzRV6MWptlfzuGFhEfkpAKtU+IRgpTLdCllKsltoET/ZUK3KnDTLPU0lRRgTTWWBJDvuDkqw6bvVGJ5johN/nniXHbB5pQUBCujm+q52VkYKFCp6pfjZqy67vcwEp6AE4JfPotL8CPQlDQCAApO/vn9nDwE5QW419uG6RSOTXACjJTrrRBwh4VcOf9AGsiFSYujWM8xtAeHYlBNsookBlC4hTJNo2MbJ1ovEbPc9yJSozcQ169ou+3FCNfLp9C/hR7yQF36jXuf23iB7nmNVBcuGEWEedVXeF57wWWX9rE7lQ6DNi2NRZUpEjumyzTqJAKZ/fCfy7Wfrsj1q8DPUqoiF0J4VX7UbSZ+BUthY3aTGFTxEldopCDtvNWWjgJuh9HjVw4/IrKmyOWiOGq8rkCihOIaA2rXCeEQ/PfRcPDFZHpwTxaWhbY54wZMU8NNg+S2qHhkBo5pjofyBgDcc9t4UaLPadOkkDW0OScdDbaRL X-Forefront-PRVS: 0995196AA2 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB013; 23:sC2rAn3VHJCfLZKAi8VJodYAT9LcwOVndsC1SIPI?= =?us-ascii?Q?R6RBYP48bwgVRH7lOyE373FAKk0YqnVz/8Y1D2OWeghQ4BeunrbcFDXBgVzw?= =?us-ascii?Q?glNedRfAdBNu2EvJ4m/1jXO72bhpw2q2MRBrs5s3h6TF78mReUNV2O0bee6P?= =?us-ascii?Q?zojdODKfnNLaJRwXEiOQa0Zf4f7XajVlWQvTwWqHdkp7BMK5hGG3a24KP3Eu?= =?us-ascii?Q?LaArbobyH4NmP/w48u74l7F+IczlOIvnJ1VWtMV7D9XDqdHkvyLQLCqbrUyp?= =?us-ascii?Q?rD/9x5aZJ82RFpv5hHhUHYwNgTdRYHElhBdpZ/BsUOyTg2msp0VK7J6htXFm?= =?us-ascii?Q?FY/t2HqRBVuvxVicKy6qyei5xLAg2POTSoRoilvpVqvRisSLw2t4p3KCtoCf?= =?us-ascii?Q?SOA5BwcA/1Jz5Vwyr8XXK/VSE3b7Q9c0nlJOvbv9E5Ss4xRieFbcZzoPf1LZ?= =?us-ascii?Q?fewfOiMrM/n83SDEp39JjIQKYh7TemtvcH/LBF94ofFMLwdGaPkiOn4yNFBU?= =?us-ascii?Q?UdGxYGmyuVDDxBMipRzdCC3sau5LOcnlBzL05j0zhFc+McznnqxEypqh8ovn?= =?us-ascii?Q?aceTaF3stMy6yGuFz+dL/SM8+Xm9ezBgxtLqeKB8HpqyBvBhGIrsZQgMdHDU?= =?us-ascii?Q?xB4zscLVFT03AyNqO5FcHHn56griKvtFc99DdS0KPA/w1F/QfgQ3hZedTv/U?= =?us-ascii?Q?aS63wxQSNgy/5Oc/+VcNPZS+xwfx2a4IIidMFz8GUOEfodUi9676QMK7HcV8?= =?us-ascii?Q?J67xX0GcfIrsQ7nWv+kUJ519yRVNdKo1foQuayWVN7g9G9Sr4jC7srPVeRws?= =?us-ascii?Q?8vk/Z9gNsqXm7mAiNIF2OnJcn21O4bfAJernOS3cOgzeaH/4LGeAWt16NTH2?= =?us-ascii?Q?TUIURYmIKxF2sBw10bOJd4Et1PcLyjAqs5sxWzlNyav4UwMn7rkL4Ka46L4i?= =?us-ascii?Q?5hPGwfVFtcyFKwfgwmZUjaaXgOroPNJmxC4ODSuUI77x6U8b4T80DOkCda0Z?= =?us-ascii?Q?Jq5jGrQjUyA1XkUHY6rwQ0k/pypKyhx41RiBnk2Y79qR2ARXr5J8YHqXo5xw?= =?us-ascii?Q?Gj3KeEpLuLSnuM9fyuIw+aJezfN7Nj9n4+3C6eLfJG7XmrlfZ42rKp2sWJhK?= =?us-ascii?Q?UdlUrU+QzY+MSuFDxNBVBnjoiXPjHIwjEppuzCCzo2Yc5PTnM2PVVCgElVYA?= =?us-ascii?Q?Z0SOoSGrm5XmVXxGVeZcBRBlFofNv6L1JrOXVhPDUpOXKw90hDqmqMRZV0Q5?= =?us-ascii?Q?/ILB8mCf+6sde9jpKOXKAiDenaLxSHEUiZINlaaY6Ax7bA2WbfnoI4wKjKTC?= =?us-ascii?Q?nFGrp0f7vWu0lsyEqP4nCuxAoccQx4dmJSSuTTb6iGxMEBxP0htwxEhWF/XU?= =?us-ascii?Q?SNhyPFSnpXZEyHIcVjmPsKpmZHwe7eOGLATjzSkI3HAZrm5I6lbirQDX74iG?= =?us-ascii?Q?CU8Ogo7hGA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB013; 6:Ix88jSgMlF8MkdLv+ujZ/dxXfOI7+VEZ2H8yt0GmQyOTucK7LKUNP9zB3YgqQoWj0091XyUe/0vXU7XAu2PaQNQkuaKj1gszHrXj3dq+1AXB48MOw1oQGJ5p5gJMZ6FEqUt7G9+ig7GIDkjGPPx0X4qk601cTgv0VEZCnJAIpG6e/0CzyN2ru9Oo8Dbq6L5Gux/9WvvvjQU0aWC1IDkTd3IPdp23HqhQnbLH1UzaxxGEUzavlapbSam58fGtAnK2jSB+SYpTvN4CvZoZLAUfN9OBjNQ008GPnaEt41Oy6yhUSy8EWBmgf+mqPf4Ut2xCeIggNqKOW/shPZJdrB0bNUi1ukAJdEpDUc666HvDrpY=; 5:/MLZ+FkIs8NLGrDuGd/7T7yI1UGFFyRY4btpvFlz1MBi4unMuqOsUF4k+ynT7u0+0iIFfmC1elcorEGIQ17nnMn5ySIcDZ/zC2xtDoseoCDkk80tGbR0HJWoDFomQJDMUd3d78Xpqo2MTWdmOPfNvg==; 24:zr6FU4CWRmOqaKpHNYza39zWCoPJ31Sz62X3r0vt+HjFhv34ohg5Zfl36vDkzOyUxZhIpGF5ZK3X+vvOKE7wX0VgklHblNUFQRO3B6MydEM=; 7:jIWq0B4HuD2CJM2x3BJ54eK0JKrNv9bBeopJY+2eDABT3cYTjg8+5HSB1CbRRtcFJCDo/OSVC14Eh50Knt2201YIHHHvfw1Kukr3Py6WcXVhjSLH3P7M7+SrTcOuihIIkKqoH3fJGoqK4Sibvg/WCPHyvPlKGBGYcsTs/3c6eGYIdJbpNtHnsL2o57Y54AyeAmhnAn+zdZT50eldAwfchsSdpS9vPk/avze9xuoNFGhcKRVW8iGdbK0QGN/J1tND SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jul 2016 16:44:17.0199 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB013 Archived-At: Subject: Re: [Dime] New I-D: draft-bertz-dime-perflowmbr-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 16:44:22 -0000 --_000_d5a2213039d44096b87253727dbb8d6aPLSWE13M07adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hmm. Should say IP flow (5-tuple) but that may be in the wrong location. From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Wednesday, July 06, 2016 11:43 AM To: Bertz, Lyle T [CTO] ; dime@ietf.org Subject: RE: New I-D: draft-bertz-dime-perflowmbr-00 Lyle, This document doesn't define a "flow". What did you have in mind as a defin= ition? It sounds like you are thinking of a TCP or UDP connection? So if the inten= t were to limit video rates, each TCP or UDP connection would be granted th= e specified rate? -Dave From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO] Sent: Wednesday, July 06, 2016 12:31 PM To: dime@ietf.org Subject: [Dime] New I-D: draft-bertz-dime-perflowmbr-00 All, I have added a new I-D for consideration. It permits setting *per flow* ma= ximum bit rates. This can serve in some applications, e.g. video throttlin= g, to limit features such as resolutions as opposed to requiring deeper ins= pection. https://datatracker.ietf.org/doc/draft-bertz-dime-perflowmbr/ Thank you. Lyle ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_d5a2213039d44096b87253727dbb8d6aPLSWE13M07adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hmm.=

 

Should say IP flow (5-= tuple) but that may be in the wrong location.

 

 

From: Dave Dolson [mailto:ddolson@sandvine.co= m]
Sent: Wednesday, July 06, 2016 11:43 AM
To: Bertz, Lyle T [CTO] <Lyle.T.Bertz@sprint.com>; dime@ietf.o= rg
Subject: RE: New I-D: draft-bertz-dime-perflowmbr-00

 

Lyle,

This document doesn= 217;t define a “flow”. What did you have in mind as a definitio= n?

 

It sounds like you are= thinking of a TCP or UDP connection? So if the intent were to limit video = rates, each TCP or UDP connection would be granted the specified rate?=

 

-Dave

 

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO]
Sent: Wednesday, July 06, 2016 12:31 PM
To: dime@ietf.org
Subject: [Dime] New I-D: draft-bertz-dime-perflowmbr-00

 

All,


I have added a new I-D for consideration.  It permits setting *per = flow* maximum bit rates.  This can serve in some applications, e.g= . video throttling, to limit features such as resolutions as opposed to req= uiring deeper inspection.

 

https://datatracker.ietf.org/doc/draft-bertz-dime-per= flowmbr/

 

Thank you.

 

Lyle

 

Learn m= ore on how to switch to Sprint and save 50% on most Verizon, AT&T or T-= Mobile rates. See sprint.com/50off for details.


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

--_000_d5a2213039d44096b87253727dbb8d6aPLSWE13M07adsprintcom_-- From nobody Wed Jul 6 09:45:01 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D4912D159 for ; Wed, 6 Jul 2016 09:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-jFtEM7A1GV for ; Wed, 6 Jul 2016 09:44:56 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0136.outbound.protection.outlook.com [104.47.41.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA4112D511 for ; Wed, 6 Jul 2016 09:44:55 -0700 (PDT) Received: from BY2FFO11OLC004.protection.gbl (10.1.14.33) by BY2FFO11HUB025.protection.gbl (10.1.14.111) with Microsoft SMTP Server (TLS) id 15.1.523.9; Wed, 6 Jul 2016 16:44:54 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.36 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.36; helo=plsapdm1.corp.sprint.com; Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BY2FFO11OLC004.mail.protection.outlook.com (10.1.15.184) with Microsoft SMTP Server (TLS) id 15.1.534.7 via Frontend Transport; Wed, 6 Jul 2016 16:44:54 +0000 Received: from pps.filterd (plsapdm1.corp.sprint.com [127.0.0.1]) by plsapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u66Gffkf026165 for ; Wed, 6 Jul 2016 11:44:53 -0500 Received: from prewe13m08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by plsapdm1.corp.sprint.com with ESMTP id 240f5sy0dq-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 06 Jul 2016 11:44:53 -0500 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 6 Jul 2016 12:44:51 -0400 Received: from PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8]) by PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8%24]) with mapi id 15.00.1178.000; Wed, 6 Jul 2016 11:44:51 -0500 From: "Bertz, Lyle T [CTO]" To: "dime@ietf.org" Thread-Topic: New I-D submitted - draft-dime-bertz-domainmasks Thread-Index: AdHXpUMTjwH5HtOaTkSMb/UQkHGY2g== Date: Wed, 6 Jul 2016 16:44:50 +0000 Message-ID: <91a43d54b503478c8bfde9ab13c2c8b7@PLSWE13M07.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.44] Content-Type: multipart/alternative; boundary="_000_91a43d54b503478c8bfde9ab13c2c8b7PLSWE13M07adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.36; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(7916002)(2980300002)(438002)(199003)(189002)(106466001)(30436002)(4546004)(24736003)(102836003)(11100500001)(5003600100003)(8936002)(7906003)(512954002)(2351001)(110136002)(790700001)(7736002)(107886002)(5250100002)(6116002)(81166006)(33646002)(19625215002)(356003)(6806005)(2900100001)(7696003)(8676002)(5640700001)(3846002)(81156014)(19617315012)(86362001)(19580395003)(2906002)(15975445007)(189998001)(7846002)(92566002)(586003)(450100001)(229853001)(97736004)(68736007)(2501003)(19300405004)(50986999)(108616004)(230783001)(84326002)(260700001)(15395725005)(54356999)(16236675004)(87936001)(1730700003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB025; H:plsapdm1.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11OLC004; 1:YNMe1yti8NiRDYh5lkFS3pRj9cqGjCwOKOrAchWG4r3dmg1dnH1MRhffmPG5g1xdd3k9fltH0d5rW0qdNfoeenBIP92HBm1hOvAzBoX/7qT+QN7oVSHx7yP6Ib0Quz5HLl54skXzxpBAIJeDnozA/lldDgTh0EObQPVGj2U2gsaPbPIYQJikX52RC36D9QHSLXMHCD2oKUwzg89TY4jysAepJ+U+cagTZQoc8qa5Ldlk42Yt5sMLTgd4BnKayVj+m8M63eiqrfVXeTLxOBaRMhNPL0+1rSgh7J1FiE/wXV5l06nMJB0ZR39tQtnC0kcRPEQepkNH+CCf+DTTjO3CvzjH8N0NCy5mbrgdGScdlxF6WRq/YkNCrZwiK0ZnqnpRvnIHlSkxtssin1sF4kHcSCtaOM6eQpWsTrDEmGB5Gy0EiyEcwEHqpsTNAjxdU0MKwb6+yyyXmJjWZC4UpTBvtUjlRfalAjBIh3y2sEZar8PqT+xGXoTgCY8ajSrWuHwEWRW6sr7/B5QKMGft6rRwOWqeJfxAel8kMt6yZXy5t+U= X-MS-Office365-Filtering-Correlation-Id: 908e1b04-264d-442b-e3bb-08d3a5bcdb6e X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB025; 2:EIZBXiHHqjJVtJtRiFj6321h3FPdPcyuTmlbTa5z/Ie8fHFIXSvbEtXKA3CVY+QwtWGNeNC4yyY7I+OrdqOsn5zKBYz62LqOAFtTJN3QuxMjXfW4y3qartu+Y7nMAREk5h3jUGiepwHxFZupOBVOX4ccR7Czzk4vJirT+iJGuK9TFiedgTEzsn5QpI+EsRe1; 3:pZe/xbfb9dXMO10H2aQLzmQSwdo6mjElxfMRrQ5jRRURj/UbAlRg6niBQU0FidM7n2cZggOGOk7vIVGHAtsn86YErr6bIhlS//+wQ/7OH8E2ahLzYItKe6uiR/7RHKNo7XN+wtL+3rTqQEyyIAW4x0C83yMisl6IDUJj7MdrU5/6glJh6iK2LpMVMVq9xcSicS3YYe/x0WIAY/wbzKZR+wv3Suhh2uBwRV43UCQb6xlbkOjLyjgD7pVhWSCmOsI+XJwp6qdEYR9nWkaqgGFUJw==; 25:8cmgrIOf1Ngvuo4cpg1cfIMcXBpT7hxLJ6POu3rNVgdWVyw1/SGefhhSgZJHfKfVwaZWOEUTxUd6bq+YIZKlRi29Au3t/pdOmmkRvv+Yd9INod3b//AcWvH0QcnwUfTWh/ePWpkYLnrmDR96992KheWXj+Z5Q9MAXOSFMv6A92mpoahFj3ky0qr8302TdlGQSYfZVfPvzKECkbP/T032hWP+htIpzpsb3/LpdjiZU+iHGqfDIy+5+Y0HBiukaCanV6fiQqFK+EBHWcqznAXbEoIAK2QYE9Hrj3NIcaVCjVCtamzqU/ZjBPNFR/H6dGFmcn6Sc25B2Nf1ZlT8d1stfF7F108ofefzUZQi9PhKUZvkyl1lWBt2msQi7itOKCjxBhvV9kbFHvHhlsoSP5cInoNO6DkW8I7q5VBJe3jZ+oKyIzRmhScAS+5SzpH/FbNo X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BY2FFO11HUB025; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB025; 20:1NETvzyNyzMNYZ7kI+M0SdGrFtcVi41tjllIPJbUYS8gF2vZ68BAj4cxH7XP9JOPmzzd1Jof+zBADWj1tSnBrOP8IWIgP9mGY5AGrYvRCQOah0Dh7dT1sZbUxjaUPD6XjkF32Wr/SOHKA3xhM9/VhVIeZJ66DKFfTcgjf71MxHMa6ErssFSqB3eafjTp6WVSubodT126BBqMQP+tSdfcGpxgT/ruFCavB3lFSZ4LL3kW3iE4NQs8TOSIQWQSHMd3+IPBMPKRr6TMly6oZp+8ut28YHdcCMR8Yf3aGa/XKOr9P09bj+tgOpjlVnTvzDQNyF41y7ySiLrYBUFEHM09Vhf6FTm+CypqmMtMYmCp1bm9lq9kvd0psewnIvSBDxBiqHBRc9r7+f2n0N8nm0CaJ/tzMFYfW0m7bW4iibqYJgU= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(18430343700868)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13023025)(13024025)(13015025)(13017025)(8121501046)(13018025)(5005006)(10201501046)(3002001)(6055026); SRVR:BY2FFO11HUB025; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB025; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB025; 4:oZy4LC0ynjM2LJCbGPXrPpn5ScrH5xjz/ZgUj50RctyWOEcbgE+52jdbw0Qnv6Vfxo38VzOew5BLjGy0JCYCeCHY6tBBTQyQ6xxQFWZ+L/y3aHXd/1axRoq8ZQpDluBDPFcVuJ0qbexb+xaq8o8z8YOpm2qLfHLp0Pscu9iN07RYBfymg1z2V6LzTuVEesdS4WmRj4auJtZARqW22A83ktfTA9Y5q/nzfAEKW89cRxqWrQ6xgttV04fo/ebP8fjKKH+A7WHK03kUCXJzElTZ987iSl4f5PHanXLDlqrCPl/cngndfgZHrUex0nitczelBed/URPdqzEGyk6BJRyCQYXeTYfDSgMzte/i4/bQAdDzrd4ZeZCKwWqyTHRtrAO/gFU4fH4Z1PuSOEC38UcF5/hic/I+UcRCyVDR3OMtFMkuHoNq99xvdQnTWpziGjYVc4j0j/dPSdYfQB+79wpNOyhz3v0j/3NXQQHlTNdtjFn7w7En0Tx9lCJWPg6GxaH28NZljK15JBMCHlxJty5iLV3t63RhPfhebcdK0Cdd5d6kgnVM2R62o2rtckSh1U28Id2ie2/Ixzp/T+decNVpwQ== X-Forefront-PRVS: 0995196AA2 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB025; 23:tLWS5JfO24S150cZZUkw0GvVyCKkAKVeiH4k7r4b?= =?us-ascii?Q?hIwOiFlJME+penaHQFrC1rrmpEMuSqOeRfxqUma8HMrbcXPF7iQ0X4nkHA7T?= =?us-ascii?Q?ysJJBG/EUeth6YkJdGyE55xyR+oIdfMhaD45/Z31sEsawrty4m+hbNOPvy9l?= =?us-ascii?Q?QhDsijXAIUBpQEGEo0POM45QpmC+vfdWYWb1F/EpWH8xZxPat+144iRc4YN3?= =?us-ascii?Q?KmiJ/MNJF8aF00GHOBv9NbFKb8JaTlq0e3ThZWJTeamMrTX2xmZKU5pvLpbm?= =?us-ascii?Q?y+otjLAXfQ1XB08NIBLsT6RcNCHurYXAlGhmM0I/xe8OXQubT1ptUHrpVRT2?= =?us-ascii?Q?xmWZAhbcuY+AlpbpF0P3YJssNsLDK6TRXueZ9HfCaeZPqClfdVRopkvmOPZV?= =?us-ascii?Q?q5Q2JS0s9ZE/kOG1aRKSvN5ZRstzvfnDuyy92DBHLnWfHpuQxNio56jlaOzA?= =?us-ascii?Q?181ivJlx8SsmYsYlm2wa6hwalHfaFyVzJgn0XduJfv3aTzl0zKyB2RpwOcnS?= =?us-ascii?Q?eFaDiyaJCQmQRbzkDINmkc/+p9S66JoB8hXCbGYq3pdUP/XXCSVbdDYuXghr?= =?us-ascii?Q?9PltalrXMQgK2VMTGnkPuX6djCJ+1dsPFes/lR1sbBiiF8BQVV+72QzLs+/7?= =?us-ascii?Q?chw/t3WRXDFf3HcqW7fj39Xnd9PCcY4QgrWQJ6L3c/oNOC9JCYTmU3SFzRHq?= =?us-ascii?Q?+3+PQ4HIoqehr131LfK3beH0WYueZFzsPeRRoDlc16UofLWG4MpXEInLWvUk?= =?us-ascii?Q?ti+KqCuYaJG7qTDQ5+RXgSnyYQy/EFgTRUCwmHErQsGvv9atjnh0L0xsb7u4?= =?us-ascii?Q?H+Aj3XX2Omk8APLieP8Lg52yC6Sx+3fbZ/7K0098T+etZIQVALr7BVgXj/4U?= =?us-ascii?Q?VtH6iXtYIPLk3nbcnSV74/v21O4W4HmRNMjWZlVh6Af8A39RW3uFRHHWSRp0?= =?us-ascii?Q?xg/y08f/TJFzKcrQPDa1+7ao+byGEE1Gtco1hhUVybhzP0CKtp27O0yHfmKu?= =?us-ascii?Q?XM1xmWI7yS6lGTm+lFzo9EX2O+y/rBTiV8EwwKlARGZBHupmY6nGcfMHcsnf?= =?us-ascii?Q?tyMwmfOmE8U38APJS+CCqNrOFHxrrn89vdXsfGb3kp/PWZVMLVxRCSTpLuYg?= =?us-ascii?Q?FO315YDXh6P3JUQtl8TgksAahwj6PJsR5QUeAQ50+5aBL3FRl1xJKUGGDalo?= =?us-ascii?Q?LHRqi4+Ug9ZWKWbgNxgjU8qiRp4JXGZXvKLm88K/n1sEVKRLz4LO3rdJOzZ3?= =?us-ascii?Q?U8i0j7/UCJ4WtieaH6rHbIdrujiKIazys7F5QC9XaR0E06XYnDryDn4nZ4gp?= =?us-ascii?Q?b9xIb3blsuPlfuggORWvSeEs4wnGDGv+20Q5wY3V5npxMqYfr1MR3rgYnBjI?= =?us-ascii?Q?ezdDhrbZkW5ayWgtaaK980L1gjnsDjXlusq3hmKJ0LiDkgQZDzaRIEfLN2jp?= =?us-ascii?Q?ZSt2NqsK0md/H7c0z4ZS9vF3kQMyt+s=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB025; 6:AjgOvCLy2gClIqJbBxQtwaS+2oBRJvR2l/QBoG4+svp11Xqoyqg+t4wN1iSO0VnHU1vYpup1BTzpiNW4itoyIF10QJ3bgdL1YMfYf4iOi2YVaexZtdm1HPBPXMll2o3ROGSp8sC3OXKkwoD0G7OZGfyprIEaMDyjBiL1CCthV11VGerdYj7NbDT1hGbZu8Ye+7xSiNOuzdaCU/vYIrVZnMWG817U3wkWtyhLuDqAZUcNinoUjo0Dk/Cf0ffWivRyzqdUIQZd6iDxna/1wxDqAb9mHMMNxFLICWlWv1lMamLapY8fFCq66K/oudr8T5Pn/GtiugShR+9gVnneId7YqNYKDkPE8y4Cp2wDoCXGiU0=; 5:X5WcDYf+q9V+qrVXQ5HroNAC7AVEVvArQxh77rwYT+/z4G6yrwV0Omhdq9oydZ/NXWMLo7DCxVOqPToi31hgn+ibfHYbihxFO3x0weFdQVv8uzmb5zCsH/K27sxGA9tshcRAEqSqoXDfSsbJ/sVZ/g==; 24:kaSPO4GFy7AHgDtaPaAalgWCPnEDRvHv6MQf/jH/MylNZcPFzwTQWhufJ8lJPYyEuvgQiRAwRYR0thWWjYRwmHhcH8vFjAnmbQepatSrRyk=; 7:IbSED1MQlCi6ajxfZtPxl4Nc2saJj7dbY5wdSdMUfM/r1ssVltONHYKaqdtZQ1a2TbqeoW98ODOcfUetsv/vW0n+0qYUblEJA/csg69nNib/emix0fz2U8GfIUWdXzjDmxjFvRQDzwlEoR72KzP1KDLKOyejmZP0qXVlQ1cRu7Wy0pH2f6nLTDfHqmbe0uxdwS24+HK2Kj9Tnrj8uEZqQ7rhKRcIZVzjWMs1h1hv/GtJ18g65jXtoneHWgq2kXqj SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jul 2016 16:44:54.1412 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.36]; Helo=[plsapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB025 Archived-At: Subject: [Dime] New I-D submitted - draft-dime-bertz-domainmasks X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 16:45:00 -0000 --_000_91a43d54b503478c8bfde9ab13c2c8b7PLSWE13M07adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I have uploaded a new I-D for consideration. It extends RFC 5777 to suppor= t host-name (DNS Query) filters and arbitrary bitmasks for IP Addresses and= other structures to align Diameter signaling with many underling SDN filte= ring capabilities. https://datatracker.ietf.org/doc/draft-bertz-dime-domainmasks/ Thank you. Lyle ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_91a43d54b503478c8bfde9ab13c2c8b7PLSWE13M07adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,


I have uploaded a new I-D for consideration.  It extends RFC 5777 to s= upport host-name (DNS Query) filters and arbitrary bitmasks for IP Addresse= s and other structures to align Diameter signaling with many underling SDN = filtering capabilities.

 

https://datatracker.ietf.org/doc/draft-bertz-dime-do= mainmasks/

 

Thank you.

 

Lyle

 


Learn more on how to swi= tch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details.


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_91a43d54b503478c8bfde9ab13c2c8b7PLSWE13M07adsprintcom_-- From nobody Wed Jul 6 09:48:19 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFCB12D13D for ; Wed, 6 Jul 2016 09:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3vFxiGnI_6c for ; Wed, 6 Jul 2016 09:48:16 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC8B126B6D for ; Wed, 6 Jul 2016 09:48:12 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 6 Jul 2016 12:48:11 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0294.000; Wed, 6 Jul 2016 12:48:10 -0400 From: Dave Dolson To: "Bertz, Lyle T [CTO]" , "dime@ietf.org" Thread-Topic: New I-D: draft-bertz-dime-perflowmbr-00 Thread-Index: AdHXoI27HhmJQL9SSVCCcgs9eQDIkwABGo+QAAAmleAAABKD8A== Date: Wed, 6 Jul 2016 16:48:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830FE6F64wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] New I-D: draft-bertz-dime-perflowmbr-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 16:48:18 -0000 --_000_E8355113905631478EFF04F5AA706E9830FE6F64wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OK, I see in Security Considerations. For your use-case, is it acceptable that a client could open two 5-tuple co= nnections to achieve double the rate? From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com] Sent: Wednesday, July 06, 2016 12:44 PM To: Dave Dolson; dime@ietf.org Subject: RE: New I-D: draft-bertz-dime-perflowmbr-00 Hmm. Should say IP flow (5-tuple) but that may be in the wrong location. From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Wednesday, July 06, 2016 11:43 AM To: Bertz, Lyle T [CTO] >; dime@ietf.org Subject: RE: New I-D: draft-bertz-dime-perflowmbr-00 Lyle, This document doesn't define a "flow". What did you have in mind as a defin= ition? It sounds like you are thinking of a TCP or UDP connection? So if the inten= t were to limit video rates, each TCP or UDP connection would be granted th= e specified rate? -Dave From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO] Sent: Wednesday, July 06, 2016 12:31 PM To: dime@ietf.org Subject: [Dime] New I-D: draft-bertz-dime-perflowmbr-00 All, I have added a new I-D for consideration. It permits setting *per flow* ma= ximum bit rates. This can serve in some applications, e.g. video throttlin= g, to limit features such as resolutions as opposed to requiring deeper ins= pection. https://datatracker.ietf.org/doc/draft-bertz-dime-perflowmbr/ Thank you. Lyle ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_E8355113905631478EFF04F5AA706E9830FE6F64wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OK, I see in Security = Considerations.

 

For your use-case, is = it acceptable that a client could open two 5-tuple connections to achieve d= ouble the rate?

 

 

 

 

From: Bertz, L= yle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]
Sent: Wednesday, July 06, 2016 12:44 PM
To: Dave Dolson; dime@ietf.org
Subject: RE: New I-D: draft-bertz-dime-perflowmbr-00

 

Hmm.=

 

Should say IP flow (5-= tuple) but that may be in the wrong location.

 

 

From: Dave Dolson [mailto:ddolson@sandvine.com]
Sent: Wednesday, July 06, 2016 11:43 AM
To: Bertz, Lyle T [CTO] <Lyle.T.Bertz@sprint.com>; dime@ietf.org
Subject: RE: New I-D: draft-bertz-dime-perflowmbr-00

 

Lyle,

This document doesn= 217;t define a “flow”. What did you have in mind as a definitio= n?

 

It sounds like you are= thinking of a TCP or UDP connection? So if the intent were to limit video = rates, each TCP or UDP connection would be granted the specified rate?=

 

-Dave

 

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO]
Sent: Wednesday, July 06, 2016 12:31 PM
To: dime@ietf.org
Subject: [Dime] New I-D: draft-bertz-dime-perflowmbr-00

 

All,


I have added a new I-D for consideration.  It permits setting *per = flow* maximum bit rates.  This can serve in some applications, e.g= . video throttling, to limit features such as resolutions as opposed to req= uiring deeper inspection.

 

https://datatracker.ietf.org/doc/draft-bertz-dime-per= flowmbr/

 

Thank you.

 

Lyle

 

Learn more on how to switch to Sprint and save 50% on most Verizon, AT= &T or T-Mobile rates. See sprint.com/50off for details.


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

--_000_E8355113905631478EFF04F5AA706E9830FE6F64wtlexchp2sandvi_-- From nobody Wed Jul 6 09:55:22 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE4412D0DB for ; Wed, 6 Jul 2016 09:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6xddnJtHRs6 for ; Wed, 6 Jul 2016 09:55:17 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0138.outbound.protection.outlook.com [104.47.36.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81AB412B039 for ; Wed, 6 Jul 2016 09:55:17 -0700 (PDT) Received: from BN1BFFO11FD038.protection.gbl (10.58.144.32) by BN1BFFO11HUB050.protection.gbl (10.58.144.197) with Microsoft SMTP Server (TLS) id 15.1.523.9; Wed, 6 Jul 2016 16:55:15 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.39) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.39 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.39; helo=plsapdm3.corp.sprint.com; Received: from plsapdm3.corp.sprint.com (144.230.172.39) by BN1BFFO11FD038.mail.protection.outlook.com (10.58.144.101) with Microsoft SMTP Server (TLS) id 15.1.534.7 via Frontend Transport; Wed, 6 Jul 2016 16:55:15 +0000 Received: from pps.filterd (plsapdm3.corp.sprint.com [127.0.0.1]) by plsapdm3.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u66GqCAX015755; Wed, 6 Jul 2016 11:55:15 -0500 Received: from prewe13m08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by plsapdm3.corp.sprint.com with ESMTP id 23xav9cfmk-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 06 Jul 2016 11:55:14 -0500 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 6 Jul 2016 12:55:13 -0400 Received: from PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8]) by PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8%24]) with mapi id 15.00.1178.000; Wed, 6 Jul 2016 11:55:13 -0500 From: "Bertz, Lyle T [CTO]" To: Dave Dolson , "dime@ietf.org" Thread-Topic: New I-D: draft-bertz-dime-perflowmbr-00 Thread-Index: AdHXoI27HhmJQL9SSVCCcgs9eQDIkwABGo+QAAAmleAAABKD8AAAFziQ Date: Wed, 6 Jul 2016 16:55:12 +0000 Message-ID: <5976352e235d43598a2f2d86c919a65c@PLSWE13M07.ad.sprint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.44] Content-Type: multipart/alternative; boundary="_000_5976352e235d43598a2f2d86c919a65cPLSWE13M07adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.39; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(7916002)(2980300002)(438002)(189002)(377454003)(199003)(2950100001)(15975445007)(356003)(81166006)(3846002)(586003)(8676002)(87936001)(4546004)(81156014)(102836003)(790700001)(7736002)(7906003)(5250100002)(19580405001)(7696003)(2900100001)(68736007)(6806005)(11100500001)(512954002)(6116002)(5003600100003)(19617315012)(260700001)(107886002)(5001770100001)(189998001)(16236675004)(15395725005)(7846002)(97736004)(19580395003)(76176999)(84326002)(2906002)(19625215002)(86362001)(230783001)(50986999)(8936002)(54356999)(33646002)(30436002)(92566002)(24736003)(2501003)(106466001)(93886004)(19300405004)(108616004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB050; H:plsapdm3.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD038; 1:t4m0VATlKq9U6mBWkJxn3PpMtCzkUKV3y5aCRByZci4vIgVPdSVwfSlpkCm++UV2DmUfbUVjIUWds4i+ZqU6ZHXy2cvha6mLaLT/cSL93tid286WUyQ/CdzzGry+RYSB//Z0Tcx3mhemGfMOeBo90ZbUUwq/PjwUQkcDysiCuJ6MmJTqKK7xP4G+2k9UaNm/23EEh+fURjkTOTwCO9buUs7x250+07eNbdQ3SC4fR+W3i4WlBxzhdAXbZveFsflp7kJko2xtea6OZGScDoVw5L/OJhVtS/j/p0/pjxvZokgbWV1l3rWgdCcQlsp+AJ2C6y/eUR5yb9CL4v++B47sHmNsW6l8MDuTxsX8VmIPJh+pShbwHPuKty48keuUiNVsZeU9o2zPtGpNJawxYk5YeX4J5x0RPpAQJlJPMvrqqvmS3DfS0tZxr+wHHfE40z05ts4F0PFEC02KksaQsdLPVdyJSLaoRGI2gFiYlKKjTYKlQSVC/2kvCX/J0wOSte/BNqfkgDgg6mZMIjAsj1BJ9wGKmmOeLLO4zYK5arJiWVbeWjqU3YXaSXp5DUQKZXua X-MS-Office365-Filtering-Correlation-Id: c10f0550-c7fb-4258-656b-08d3a5be4db2 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB050; 2:WigROu3hvWcWRDHPWi1P2C04eX8dMIR36yaWvD7FYWlc6DeutP0po+GrJkrnAVb8WSoSSrXr4Up4MM3c3sWiPzKkKz4gVY6iIhm8TTFTgfhjxSSBHUeEqK0Z5f1wvsjLzxW49SZLRJf4Ow9P8Jaf7EVnBoLC1kYvkNAccQGjeH34iVmzybRjnpSOwKdkjOjz; 3:OO06AQIdKFrlogrRC06EbNP2iF2YVz2SE9tnBjUtoMS+R3ncruKptk+8FwoidyzlQi1kTAs4CEjtWgrCK+GgH0EEELSP0iowOuRbswItfm/IMTQTIXGl3Pf6qy4Y+T5GJcXxLSj7ZIM9V1JiOliXA7PoUrD20d7VifrnYxXQ3hy3/xZZ//G98oTTRyff/QwgZ4tmqSKcX+SXmrQySoT37VSlKgNUmJ7x5YtfL8QM9wNDXc6D4JVRqdQap08ytj02EF0ke3oVXibuCPS4CoQdbA== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BN1BFFO11HUB050; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1BFFO11HUB050; 25:zGrhJqZOru1jU+DUL5kXht0fsjBi3f40e4o2Zbd?= =?us-ascii?Q?Rj4f/KJMqDsSCbJN0l4vz5L3nNw2CnON5Yt+0i3IzfXqtaNQM3Gbqskm8iCV?= =?us-ascii?Q?SiCeJqJnD1oh6/xt/WDpJEi40CxL+LU7l3OLOhgMNlLhUhEV/1vtS2oy+kZP?= =?us-ascii?Q?UDYPZdWLXEgTH36IjIZCmCipXv8EEFICbHS06rPxcX++51sgSMQWCfvwGZc0?= =?us-ascii?Q?lGf2C9FCmunqdS6D1tEh4nhZt1uV/t6jVAVVPMdzqwwJOjjnVxhRgTJWbPzt?= =?us-ascii?Q?9Pv6jIftSZbkg3JT08MYuUlqGJ3oHcZwVzry9TDhN6AId/TMvDoU+z/c69hX?= =?us-ascii?Q?Pmn1iYjF/WYFTfmM/Gcx9Gq+2KIFRbFH31m+HCpgyQqF1Zwsm1IFGqoBGCGj?= =?us-ascii?Q?vmFMyqoLafvvj76Wy+PgLFWBlIv0QWLadb0BR7MxkrVESHMN/KFnRJMQtzfQ?= =?us-ascii?Q?1P2r2GDkvugP+R6MSIJfA6YRtztnSejbHZiw/V5GFi45JK0oe7Np8QXZqdiG?= =?us-ascii?Q?IAgWfwcPIaEerhzjKf6sw0qQApIJn/8luiPHTX+o8BvpkfuQL3iDhgxo2n7F?= =?us-ascii?Q?QoxMAqjHPQME6NgIJRvsa/s7wgP7v1oBa+3up1U3CsbJNGNoviPwwgorL1t9?= =?us-ascii?Q?HW9v9zWaX9EiU8JsGHBXR91wl+JD4oMEQqYqJlm2cmGh1IwUDoyU2IOEtavB?= =?us-ascii?Q?f7T9GGXfTBBdFdZr3dIVA1ew9pnZvq7rvumHT6OQZ2ZmIrMCiSSX6ioZYLHv?= =?us-ascii?Q?gzQBdL/tSahfg29Yrc317qRd7VC6KbP9u16esCk6OA9lhfWu1rCwAUzMGzKo?= =?us-ascii?Q?fp2X131MyaC2At0LrNUaAUi8gZbeZTpHB9RIb645ArWdw4VU50uxdAVKFa5Z?= =?us-ascii?Q?l+rKjBn6f33/kDxve0W6YuR57fKZCL2j8+fTbHc6RKepmEqASbZWD1juejJR?= =?us-ascii?Q?GdPTHJXF/DNu4TABtdT/jjaKHILEzqhPK8f8BiHAUPjiBfHXXqUjcOjJMekD?= =?us-ascii?Q?8wYLOyhTDu8UxyaUyzHLXfjw++rEJgwGRRD0n6Bg9Ce3qcafIA0Iw0ncahSe?= =?us-ascii?Q?YwzRmcZilnxtWcJ+vcBw5zbRa0iLy?= X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB050; 20:X+QaH2uQovv0HkY2AK4DZMzaqYciigR06jHBnHYz5LBEH0KvRLlm1wzwSdBVPlBa4xqvnlfcuPSmyph/o7tBYsNQOTH9I7TXnhb9UeRsymuP5Fy3GXPabhGZ6xfsFotHzGyk5idHSjT7e1XyRrK2iQEL+ZPAmH4w6jFAHsR+Xls6/FqcOogoBD98ccPnL6AycBhpkFrelpMtLN4r6RPGey5yX6KdXd9mFDzW6QD1syJpRud1wlI1g5Vy9QeveDxmrVldazDuoEzdZjv4AvXAOpZ4kmFTYfu2zDwqeDfH00C6KrAW7JJbwuUjf/zAnqsYGNJUQXwj/5ShwjTfrdrkVxdnq1jWQcTE7pOmGquljChCg/2n/FsSqcBKFdhm+1cLBI4knQynNj70dESXK1YDi4TgjZFs09x8yAmZs0j5CGY= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(120809045254105)(192374486261705)(18430343700868)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13018025)(13023025)(13015025)(13017025)(13024025)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN1BFFO11HUB050; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB050; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB050; 4:9NBEKN2oCFr7XN8ARsFURPD90Whn+5LEqU3nJfojYlGMAd7Y76DqZYyzAkXjKzrK3nXS1ioC72ATtFuWhn4khzQomFafIsFxCJmw5DXZjICuooRh+HAXRoHK4u1hzU6YOX6v+89eakhXYJN4hhFOuD3WbF+o6BXBS+uAi2DEisu69Fo9PnKGb2JTUcQtPn83rcoQ8qlCQ5EK186fLtDDqfJSIyz37LyQ1SpibBs5F4wLSVa1eK+A+OMz5VPnGNwy5ESJn7QCssuC9bvZkVW7bZlRFS9m8H2x+z2jpwLhDk5BHc+4017bh3LHAI/3LctBWZdYeI6GTZqDVgmsU3eMwqT+vuBz3Qo8hWnoX1Hhiij/ulXGziSvU/4mmc8i808B7N+gQ6trVZ0wXjbpwtrXfZ4JY4v93r7606PWG85o7gjpcYRpq9yzDO/XGKNI4Nb1me1krHgZBK6/6pBLCy2pnSMNPDNFbpzssPfSTa0Mw97yp/Oa429i4GBPBdxd7HqQlkekS2dgXG07cj4rUPwQ83AbbU99i/MZjasNlDUAN2CVNHbU30wMcHwdhkiNaV/5/SzbITjK9nLsqH1/gMTOqBkLDXVR6OQ6sN2S5j01Lo1WDubQ14URSObMPCh2znvLt5oABkUSAYbJ+JFr6NggZB945CBqW+lGZVd3S7OOf2g= X-Forefront-PRVS: 0995196AA2 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1BFFO11HUB050; 23:spF+IX1dwDe33u8zfkBvH164iqdZsveWBtVhStS?= =?us-ascii?Q?h+OTIgZF4EQhnTLOYx/RqlxyJdCj6qsTwT73FMTYpEfpZliunSdRFOKAW41+?= =?us-ascii?Q?uUljhhNKR1Mi5QuyeEKDEjkImW3Zpy+MnOK2PRa234EuG25D4haTT5Z206+r?= =?us-ascii?Q?iMZKSAaRgoJIYPQ1NJzswEPVn0C+gSv/l/FbrXGGdp3BWYiGQLVGVQ6Dwo4c?= =?us-ascii?Q?/B6WNjC6Jx9biShwDRjmkq1olMbL/3K0AvLrZunFdlDuEmZJLestBnuMMcdu?= =?us-ascii?Q?8Am2ozkZGd9q6MkXHtyRcyhxBDkYouXMVI6UBsjvyy/EVaNB05YYmm10WQCr?= =?us-ascii?Q?d+93NMhnQxtlvBSAg8YF+UFoo+13eYcDVEN6js73cexA6WuudlrM/APgrgk9?= =?us-ascii?Q?4W5w7zjfy6AjRgMujMFdpSNB2InpzRsqB19UCuauNUs1P4WwD/02QTQXeTWI?= =?us-ascii?Q?+FYQ3bkdPscdUQzJuSE4qymEkc9sFMCyrbkEkKJmKRSI63qMaX898bBD2rIe?= =?us-ascii?Q?L51LLUxkKiGpGvbt3duprfjWX88PodsSI/kOTa4ctEahe/DnchOnEjkzfNHG?= =?us-ascii?Q?cfXU6zDfmNosWjtDkX+6Ji4UC46ohx25+TKfJGba7JRBUkZIKkmjrD6OYj4f?= =?us-ascii?Q?DGG0iCSTGh69Y98pjfzCLkjd/kpyTR+v5BWccRRHoGj1J/3K7JtVxSE2cgMv?= =?us-ascii?Q?8HDJAAnuHSP7lXdWwWmwTqMGFjGz4qmxh/XV2+laSwqkqHJyS3J8Zzoi9PKB?= =?us-ascii?Q?NoKimMWPzFpN2h2hpNLbBlglgsBQybHsW/ILjsZba1PJxQXsl+jffVOMUVmv?= =?us-ascii?Q?ycWoS4EJny3gmJb93hHgjjyrxoVDthkwdfRK2aAZAAULzmNKEr/w4SflO8/E?= =?us-ascii?Q?CGy7bXVgTubBCseT/Ev0pl8/PgcPMzFFw1A8JBAcctbBWxIgstDo3jvqPwbx?= =?us-ascii?Q?rfSN44XuJgDnGs5EZSjoMxIqnPwyKrD88eWaArEKnSeOJSZd8NCXJ2lLNQMv?= =?us-ascii?Q?N/79LeU7Jty3/mMLRbVVkuexhb0TcwrImyYTy7g0ALAFNCBwz8hBlXVx7YXM?= =?us-ascii?Q?hrHj2KK0EmOxfhlxM6ikZT4HQHI+OlP7UOzboNeOnFe4Hc0nGzmeCjfx+SDF?= =?us-ascii?Q?skBLbYF6euM/z0VmthOHjT05/dGJ/XVXbtaACP5TkseM2rZfb6wHsLPRSSy3?= =?us-ascii?Q?GBcQOBmsvjXWvc7n0nUKU/YbK7ymPSw6plP1sHyKNpWepsYXlCA/ATxKDDTY?= =?us-ascii?Q?0dZlO3txyhq89n6fZLWeR7DW95pLsTB8dK5ifbREwySzwydb1ziAUZ51ya/p?= =?us-ascii?Q?+V+EvFMp/4q7uLZq0Q1J8NiX+4y8SfUCINwcfGtaHI//hRG3QVeqGDnr2Tme?= =?us-ascii?Q?mvHwi12L06YWKsreLrYdoPVsURpOLUs2Sr/DwXycDgSnDsT7GMT3N9Zj5P+a?= =?us-ascii?Q?7rRPHi/ThdiX/77HpvTU28IM5OgPtgpc9oeHTfB7nvJGx7v7wehnd?= X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB050; 6:3/l2yPxX17Wou0O3Ny5aIqHPac10EoYgoCGjM4Ae3nB3YV2MMtpQtn14jRXL7ahcYdRS+sp6Q/Tf/R6HnIvHbyHO68GnYYlV9JewhML+3fh9KgJetRL5sFO0vckkQ/Od0p6NE2GSioNc6BMw86AgeEqw9eFsutiExyxdMlWYDSHyr477Jc2xIZelhhyKgmGFE2+IbdAoNCNQ/H4AvbBmQnmyYs1+Uqzrr2OEw9i0N1SOubkJHi2PeH2BAQotjUfrfa5sB6/WY/WpM8HpygVpS6DvhhVR7581HCFDSegmE97gb4lmv1L43HotPccQccznvRESz38cClm8JSBI0+guF1Ov4tgVxOItbiWCOdsHMb8=; 5:q0Zz0ZVZL9QOuIN1yS2zQfsPjsdlGrx7BBRtvqBEEy3XonqMzINuz28trrdcDOETS5gpNiI1X3DneFG0QZg5+DjnENhwaJjzgxP+DPjWOLGkHu2Dq/+VsdToDp87Ko3QPclft/dVs720DBmSQ8Wp6g==; 24:Ubqc5pGsjOLlqWZPvS/NIGUo6MVvfytl/ZrDZa0wR9OcsXM5+TrEW89PRv5vsCAWWWhotbzpFlOwVMIwLovwwwD6dm5gvZH5ruP4lSLXEm4=; 7:bNRonYlcUKZk2Tzu6rvQq5gIckKHIIVYrv3xB9xHXsSkCa1IgjsqDZGsRb+4dB0TdYrD5wpiT7oo8GCEjQJo5eLkNo+yIA75QWrSL1q1/NKqhRrlJ6KdnLXzUXCwWdRPqHce9jB48/V4xg34CW1vNt0yzWc1bDEY4klUMXr540QrPsCB6a3Q6bUkqjv1WgDNibs4t+npp35vnADhPkM9ELlI3hwNMn38RCcIAD4dWTjsH+jguvC0q8pBCLoI8s2l SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jul 2016 16:55:15.3406 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.39]; Helo=[plsapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1BFFO11HUB050 Archived-At: Subject: Re: [Dime] New I-D: draft-bertz-dime-perflowmbr-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 16:55:21 -0000 --_000_5976352e235d43598a2f2d86c919a65cPLSWE13M07adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, if you are using the IPFilterRule or RFC 5777 Filter-Rule as it is tie= d to the Protocol field. I also intended for this not to conflict with mul= ti-path based protocols. If you are applying these attributes to another kind of Rule, e.g. 3GPP ADC= Rule, then sticking to the L3 is still fine. However, if you want to use = it for the Application level flow this document would need to be changed an= d we'd need to incorporate it in the draft. Is that something I should loo= k at for this document. More work would be needed to clarify interaction w= ith multipath and other protocols though. From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Wednesday, July 06, 2016 11:48 AM To: Bertz, Lyle T [CTO] ; dime@ietf.org Subject: RE: New I-D: draft-bertz-dime-perflowmbr-00 OK, I see in Security Considerations. For your use-case, is it acceptable that a client could open two 5-tuple co= nnections to achieve double the rate? From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com] Sent: Wednesday, July 06, 2016 12:44 PM To: Dave Dolson; dime@ietf.org Subject: RE: New I-D: draft-bertz-dime-perflowmbr-00 Hmm. Should say IP flow (5-tuple) but that may be in the wrong location. From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Wednesday, July 06, 2016 11:43 AM To: Bertz, Lyle T [CTO] >; dime@ietf.org Subject: RE: New I-D: draft-bertz-dime-perflowmbr-00 Lyle, This document doesn't define a "flow". What did you have in mind as a defin= ition? It sounds like you are thinking of a TCP or UDP connection? So if the inten= t were to limit video rates, each TCP or UDP connection would be granted th= e specified rate? -Dave From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO] Sent: Wednesday, July 06, 2016 12:31 PM To: dime@ietf.org Subject: [Dime] New I-D: draft-bertz-dime-perflowmbr-00 All, I have added a new I-D for consideration. It permits setting *per flow* ma= ximum bit rates. This can serve in some applications, e.g. video throttlin= g, to limit features such as resolutions as opposed to requiring deeper ins= pection. https://datatracker.ietf.org/doc/draft-bertz-dime-perflowmbr/ Thank you. Lyle ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_5976352e235d43598a2f2d86c919a65cPLSWE13M07adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, if you are using = the IPFilterRule or RFC 5777 Filter-Rule as it is tied to the Protocol fiel= d.  I also intended for this not to conflict with multi-path based pro= tocols. 

 

If you are applying th= ese attributes to another kind of Rule, e.g. 3GPP ADC Rule, then sticking t= o the L3 is still fine.  However, if you want to use it for the Applic= ation level flow this document would need to be changed and we’d need to incorporate it in the draft.  Is= that something I should look at for this document.  More work would b= e needed to clarify interaction with multipath and other protocols though.<= o:p>

 

 

From: Dave Dolson [mailto:ddolson@sandvine.co= m]
Sent: Wednesday, July 06, 2016 11:48 AM
To: Bertz, Lyle T [CTO] <Lyle.T.Bertz@sprint.com>; dime@ietf.o= rg
Subject: RE: New I-D: draft-bertz-dime-perflowmbr-00

 

OK, I see in Security = Considerations.

 

For your use-case, is = it acceptable that a client could open two 5-tuple connections to achieve d= ouble the rate?

 

 

 

 

From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]
Sent: Wednesday, July 06, 2016 12:44 PM
To: Dave Dolson; dime@ietf.org<= br> Subject: RE: New I-D: draft-bertz-dime-perflowmbr-00

 

Hmm.=

 

Should say IP flow (5-= tuple) but that may be in the wrong location.

 

 

From: Dave Dolson [mailto:ddolson@sandvine.com]
Sent: Wednesday, July 06, 2016 11:43 AM
To: Bertz, Lyle T [CTO] <Lyle.T.Bertz@sprint.com>; dime@ietf.org
Subject: RE: New I-D: draft-bertz-dime-perflowmbr-00

 

Lyle,

This document doesn= 217;t define a “flow”. What did you have in mind as a definitio= n?

 

It sounds like you are= thinking of a TCP or UDP connection? So if the intent were to limit video = rates, each TCP or UDP connection would be granted the specified rate?=

 

-Dave

 

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO]
Sent: Wednesday, July 06, 2016 12:31 PM
To: dime@ietf.org
Subject: [Dime] New I-D: draft-bertz-dime-perflowmbr-00

 

All,


I have added a new I-D for consideration.  It permits setting *per = flow* maximum bit rates.  This can serve in some applications, e.g= . video throttling, to limit features such as resolutions as opposed to req= uiring deeper inspection.

 

https://datatracker.ietf.org/doc/draft-bertz-dime-per= flowmbr/

 

Thank you.

 

Lyle

 

Learn m= ore on how to switch to Sprint and save 50% on most Verizon, AT&T or T-= Mobile rates. See sprint.com/50off for details.


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

--_000_5976352e235d43598a2f2d86c919a65cPLSWE13M07adsprintcom_-- From nobody Wed Jul 6 09:56:14 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7001B12D13D for ; Wed, 6 Jul 2016 09:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M02Me0ybXFJM for ; Wed, 6 Jul 2016 09:56:11 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0134.outbound.protection.outlook.com [104.47.34.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4491D12D0EB for ; Wed, 6 Jul 2016 09:56:11 -0700 (PDT) Received: from BL2FFO11OLC015.protection.gbl (10.173.160.34) by BL2FFO11HUB038.protection.gbl (10.173.160.242) with Microsoft SMTP Server (TLS) id 15.1.523.9; Wed, 6 Jul 2016 16:56:10 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.36 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.36; helo=plsapdm1.corp.sprint.com; Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BL2FFO11OLC015.mail.protection.outlook.com (10.173.160.81) with Microsoft SMTP Server (TLS) id 15.1.523.9 via Frontend Transport; Wed, 6 Jul 2016 16:56:10 +0000 Received: from pps.filterd (plsapdm1.corp.sprint.com [127.0.0.1]) by plsapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u66GscU8036511 for ; Wed, 6 Jul 2016 11:56:09 -0500 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by plsapdm1.corp.sprint.com with ESMTP id 240f5sy2m8-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 06 Jul 2016 11:56:09 -0500 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 6 Jul 2016 11:56:09 -0500 Received: from PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8]) by PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8%24]) with mapi id 15.00.1178.000; Wed, 6 Jul 2016 11:56:08 -0500 From: "Bertz, Lyle T [CTO]" To: "dime@ietf.org" Thread-Topic: New I-D Submitted: draft-bertz-dime-predictunits Thread-Index: AdHXpgQdMKqoCHiaRIyWNoRHauEl3g== Date: Wed, 6 Jul 2016 16:56:08 +0000 Message-ID: <23595558c1ba4777abd64d584c17a422@PLSWE13M07.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.44] Content-Type: multipart/alternative; boundary="_000_23595558c1ba4777abd64d584c17a422PLSWE13M07adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.36; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(7916002)(2980300002)(438002)(189002)(199003)(19625215002)(30436002)(102836003)(108616004)(106466001)(2906002)(356003)(81156014)(19300405004)(586003)(2501003)(7906003)(7846002)(7696003)(450100001)(68736007)(5640700001)(81166006)(2351001)(8936002)(230783001)(790700001)(229853001)(3846002)(24736003)(6116002)(1730700003)(8676002)(87936001)(97736004)(189998001)(512954002)(260700001)(11100500001)(15975445007)(6806005)(110136002)(107886002)(2900100001)(5250100002)(33646002)(16236675004)(19580395003)(19617315012)(15395725005)(5003600100003)(4546004)(7736002)(50986999)(54356999)(92566002)(84326002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB038; H:plsapdm1.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC015; 1:Pk6AXUxGdCk5habsKfk+9bA51635XFCIMjfMD1zLG5vsbk60+Y8VFdU5HDeG+EYEB96rgtWH6KxETdXhXRz6or+qgzkMr0wtQ/xFctu7oFbP+QYvSr6mYGaQarRaF/bi0p1o8tVftThcDHrEDmRf+brOgIe+ELDa4uIwxsPKFoLHPk9HxwIU+ngElWItMDbkRrj3rgsItBYr2BxPHcJzVhl42nCpoP7d9O5TRtwyrXgBhSZz3enHCJ+c2Qfizp7370eoGTN2taXLW4Qwz2lBLczcrb4FZcaZzJAP00/Z220CI5nG3AXhSvrMxgi+kn7/B4/IriojZfXo9QwrqEoi6a1cN+l3gZKZmk4hLjFHBJudbdv99sUx1FKxRPvCcOdF81RGG1664VREHRE4T2l3q/xr9SQysgWbzbfTMN132+kbdAQBz5xaT9GoU8PFInzbvlsYFSmlaxAC9ka+87Oolof3yv7WTm5RCk2hs1on4/E95IpFRJGjcfDXGw1tG2IxKUJvp4pSQpC4sfMNY0Ly+8sutmUgsD55iVMHpRSEdgc= X-MS-Office365-Filtering-Correlation-Id: d36a6f9a-2e3e-47ad-fdef-08d3a5be6e9a X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB038; 2:XnNS32YdrzQDTsvBhlegb4tvpYuRw5xyzdJridKba84CZ5p2hZAVWQ36tp6xfnjhXli3iGHpnR90A6mT/BthGkA7OgslkAVNhxroev2VLS6jBRXWWJZYqWTZu/Kim+T3R4HiiC3N8EKp9/8o7WwHNAgnE0GVapf5lerD4mRJYwxTR4HeAV6aeJHS868N5yNX; 3:5I6E2JX5Q8ZkMHcAE/RY17cBGBlzsZQT342gZurETSoUigGLE6MVNHfMVJvhGr/iVlRMBVHSsjnBuhlj5Ck13s0dXs33NINxOzDP0U7OlzT23Ftwu24hWR23YUTk5cd5dTHOSangtso2YdOKnj6/Fw8ZXhPp1Uk3dcj/g0qVpScxEjlRJuizNr8Kn/6+IAqho5mn9/c91NUOtCoc56Onn9+K2ngsW1mHNQtM9EOB5zpT6XJdUwqe93TUCJJE8sPCdUHlegaDtwoFE6F2+wx5Ug==; 25:IqVOQoSg5Gxaf8HUVeMcYjGWeQ5P2hpjdlNvvfFCpXx69G7474KzFAbU1JFL0vKjLSUU7kHcs5mbo85AdK+0zgkU0gS67uXuyK1Agp6rQOlGtJ9aHPwmtg/aBWWkMXT4uOkZuc9qGvpmDPBjmwnB3E7UTac5ibma6vozY7uFNixKgNm7lS4EEcvCcRCnkUC7nLVAelozrKTbwYIkUrMQuVRMez7qhMdKIj0wYv3/rO/kM/rncqc+bIMlGtvDfubic+jYwkEbF4ca+O2wTvxx2TcDPshLdZVtxED54imqMnvtV2fyusXYqqjUby8QmsYRruK7gMKKCHOJsAckgrbtUO0P1H23bfnjf2jnBFnF507fcddFcnS9Wx3sADajHII1EQLp6BAjajoHdORZbFWoWO5qi010r1FFhMr52VAKfOi+kD7zgNJBmeXgezeXnpMg X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BL2FFO11HUB038; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB038; 20:TMGdvd86BrT8eUG13dduG1kUYaEMzeMSvY+jUz/ci4Ybg1dWh2QdNWjzJ6xNAg2bfJ7VV1xQ3u0T4/bGfLpi1ZtcF2gJXDT90/si/m6RblFLR9VcRFAF9ZENJCZ5hLNb86oHwknDwivYDKPqQlH4d7T+cIQ2g6us0PFknlqGaiXjMAhQRHIlzW/hx1ks5GyUSB+ZvEtJX4Z+vZPzQH0Bs1hs4gyPLWNmgL06JgTPute88dO8Uu3eIW7jtffmS6aEh76OE7hylPPZ8RB1dlPSO5CzbaS7HI4J1fsCvEUbiQT6ovUAXBKBERlouXp1vRQMqu16dxN4ERnclcULD7x/cVuMW/pVnaAGc0atQnFbelEsANdeoBiyofJMjR90Yxcef+11kWOJscA3LqLU/y2OE9H1Ax76VuEsNfTysiLSAGA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(18430343700868)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13017025)(8121501046)(5005006)(13018025)(13024025)(13023025)(13015025)(10201501046)(3002001)(6055026); SRVR:BL2FFO11HUB038; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB038; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB038; 4:7d1En5VbpwGCltUklGONv5EaGW1uKxUjCPGXSUL/cEfdHtujxcoLePMzAId+gda+oP1HmtsnHya6uZbmoCFg9GbGbNFirSBEqQ1PFEIk4yRtlXT9ZItUoK30kuR007dkDWSvLLxv17XYgCZCDgd25vBfQJhQte0FyZ2aC2UoS+1HK9dF/TVpqKinmzD1QcSaMHlwYGAlrllmOxFTLpwO4FVnGN/WGvoVoReifoeyeMu8ui7RdqQ1/wGbuqtBXafZ3kdyrkj4ooi3r7z3JVlpUixMui4bjG1Wq3c2h5c17LJAnlNYScZFhyI5PHoCOoVAPrsPGUaN6GL2CUr5l5m0ZO2uhJMeaHgVg1Sxy4v0dnqPTWCfmXDaJf3v6F1juTPGeuJRynVfmfozvYaGbt4sCbxv2xmKy9VQ+wyxCJGTkwxe41vnuS14hlgpdBsfc7s+K4+CewUc6toWeebRe0vdaYvdic/lqEG0d3TnyVKw/UrU3ZZIhZd0igw+mRiN4s/vwiJtJlAEJNp22rHhs16kc0Y2bi9q5jd/QP+m4iuhRXWiSPFY/j/RnGwFgatkXq4u7r/yn3JXkmU9zN5mz+WDsg== X-Forefront-PRVS: 0995196AA2 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB038; 23:yCCEJZXFUtb6AKFSRoXHU+/X/8TH8gmDrwPTsOoQ?= =?us-ascii?Q?ck82bhNXPXSs0ROPvyt97etCdG2LBhHCBqFMzXlmsWeTkVEduQ5ggkoduyXa?= =?us-ascii?Q?7DzHyz8u9e2AM9BldZ4lKAqA+TAP4THTQmEjZpxsMvPLYLf71OtX7+JWE6oE?= =?us-ascii?Q?irnOp0jYQnzPq68U3iqQjc9bDGSBvo6dmMwLhL4AbldPdMPugL/qvLmFe9N3?= =?us-ascii?Q?d4oivfzGlhYMtTyX1d3IZVdlN1qlnVpYpLyQMgfqHzV+QxcbEvT6bdZVGGVa?= =?us-ascii?Q?bIvgO8H1aST16QpwxF8cPq7NE5gSo4E0/eyMhrdYu/xgnP5Yo9Dld7/FKqoc?= =?us-ascii?Q?Ym0a/eEXDR5vRUJ3lvaiZ+9LKosO+3LclcN8u6M7PIbHIfcRHyU7wzFf2Kew?= =?us-ascii?Q?zUnm8GuYR5G8fYqYFifxSY6t0w20L13NOoM1T4Qno1OJpA3vGcWiontrt4+m?= =?us-ascii?Q?v5pXMKfpafkKe67ju5i1swZFGohCpLtU6PNpUqGFuJxK3HzjVnwT7hNN9Z/W?= =?us-ascii?Q?oY4V9KeqeRpH0oOoKGwNkojwXWekuxNW6iue6MUxG5s3Kc0MxU9pijzuPpGh?= =?us-ascii?Q?VOpQtGwUOng87Oaiib7nhme/ovDEW1MO2C8vOwF/+uy0KMG7i1vOCIgtCkC/?= =?us-ascii?Q?tJk+akUiwgJu/PtHdwRNGnh2G3fOXpWLzZMdNnniB2X7UJzlVC9jktwwSLMK?= =?us-ascii?Q?luSYaImpYrbHsoUUvY/cBvfOSyAv3JnI8Y4dc2U6/GKRmR9EY3JJA5143shu?= =?us-ascii?Q?6Crg1FI7Y/7ddiwO4GS2QrF6aM+AFE+RVU5yad2VMKzPxFlPfgA89sw/dTNI?= =?us-ascii?Q?dLkGneoxVfBNI2ZE0vbECJRu2LOzex7D6q5hMbkr4O71l5+2ZCMC34T2c/lI?= =?us-ascii?Q?55d3owHvtUxdgVAWKrw8kfrFuxkwBilv4d/T9ejTQffqBXY85ube+2oMQnEQ?= =?us-ascii?Q?zDTi3sP1KF2hdGDI0OCuusJ/3HhF4BlrOtjcRWbqFabMH5un7eJTLGHp6XyL?= =?us-ascii?Q?kL4U+WDeFdBldsLYom7VUfLyxuREXzbcl+IloCX47WTCvDlVnnNwnK6a9FaT?= =?us-ascii?Q?vRk+x8H65ucpnJkxwPh7WeI9hSQS4myEYDFQKZrZKRC/Lw8VbEkT00/pMYH8?= =?us-ascii?Q?grEWHVop2pu6yYc5QGaRODaxGfDplyVkdxPCPjDjDDDbIQWkRRn4LKrH13kJ?= =?us-ascii?Q?gfLTj1Q9TWH8j/3/hgc1q44K4Icv0UDjoNvMiJU2esbg5RLC9gTjpPYUL8/t?= =?us-ascii?Q?nWpoDC9gSAVcUSLcCDcXF3l5Wx+gXc0xvvzfDJMZOgRJPLkedNA1GJWg/CDn?= =?us-ascii?Q?TQRw1m/Zysx4B5zNm9U7SDYFc+ACI2Wbv1llzCtru1sBEzI6zWR7tZGfdryg?= =?us-ascii?Q?UFWb06JQ7YAyOs8mTdy7EtglNHQ5tPQX235RLMuMJFoQJ/u7ektDupYYI9J+?= =?us-ascii?Q?4i9FJLnCOSlAgPHbxWK5MSFKT0lmnIs=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB038; 6:m5jT+25LAVLfwOZQGd/VqHgVqQ5FXTgXnPeGFVsDNa0w8OjU3OVmjvZZgRRx5+8K/zimaRN7t+MxfPdqEvIy6qvSt7jLRtwkpgUh7Y6mvs9mKNqrGpW8zLhgpNFuvp1ILKY0Z3lDEa+T22pYVWuQTE6swAQUfKXghMacIQuSalPh1DC09orEh3OTn47C4s6xGHJ9hQ6goBN3IBPsTN+n4CRxdD3XCRukoXnzwNh1iwLSR/te4EEArokpjqqSFlJr17pdK2+oU7XdIWgeceCQOujiCsb+ZGV+n31pqa7y0jFMNiDKlIORkdCPFJO5kEmHrR4ROG3zfouX5oYu7zFRin4mX5zqmsUc1YtDm3oqXW8=; 5:Ne9LhIKL1hrSaYfxjDaU8QYsVcuyX+f+zmfsIYSlRkt40KMHVJuM6HBC4CNa5SoduvAD5J30m1pTAnHFrsvLjNikdAxExk97CeM90ckLDfiAhWLrQ/ByS1gtKrNyd5CRKDTGteuvoeNoj+MxWCZAMQ==; 24:9ZbQx794OKTYjFALDDjHjg02rVQN7ZzdqNezI5k1wNpBjRc7nCC2Lw3ayzoYU2R7u1xWebvekduNKV0v2qqA+f+XyTTj+r5pQr3VNwNCn50=; 7:R4Zvzrs2TIvWZjyJCOmDjrC3fmgzOW8Rh0FI1brkP2Cb+Mdjs/tHZcpEV4k6dguFzREo4Qo+0xgvia9tIm+Tnvu7oCYXSpbW3r2iwx2Vk69/7aRM2G8aUzunAf4ZngRUpa1u2u72CMlOMeYxXXM097RKSqUB8RTK7YWuAiM3GYOvq017ob0oA3/BZoCktOESaE/czDxV8tiJxBJM+l7LEX3iAzwbYa+ZQvIAyDB7Rh7u7aHkmbbx6rWJtiXzo8w0 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jul 2016 16:56:10.5676 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.36]; Helo=[plsapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB038 Archived-At: Subject: [Dime] New I-D Submitted: draft-bertz-dime-predictunits X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 16:56:13 -0000 --_000_23595558c1ba4777abd64d584c17a422PLSWE13M07adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I have uploaded a new I-D for consideration. It permits a Diameter Client,= upon authorization for Service usage, to receive a prediction (estimation)= of the unit load. This is intended to assist Clients in estimating load o= f authorized usage. https://datatracker.ietf.org/doc/draft-bertz-dime-predictunits/ Thank you. Lyle ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_23595558c1ba4777abd64d584c17a422PLSWE13M07adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,


I have uploaded a new I-D for consideration.  It permits a Diameter Cl= ient, upon authorization for Service usage, to receive a prediction (estima= tion) of the unit load.  This is intended to assist Clients in estimat= ing load of authorized usage.

 

https://datatracker.ietf.org/doc/draft-bertz-dime-p= redictunits/

 

Thank you.

 

Lyle

 


Learn more on how to swi= tch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details.


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_23595558c1ba4777abd64d584c17a422PLSWE13M07adsprintcom_-- From nobody Wed Jul 6 10:30:22 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE86712D0EB for ; Wed, 6 Jul 2016 10:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJUI4jnjr7CX for ; Wed, 6 Jul 2016 10:30:19 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB77F12D129 for ; Wed, 6 Jul 2016 10:30:18 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Wed, 6 Jul 2016 13:30:17 -0400 From: Yuval Lifshitz To: "Bertz, Lyle T [CTO]" , Dave Dolson , "dime@ietf.org" Thread-Topic: New I-D: draft-bertz-dime-perflowmbr-00 Thread-Index: AdHXoI27HhmJQL9SSVCCcgs9eQDIkwABGo+QAAAmleAAABKD8AAAFziQAAE97GA= Date: Wed, 6 Jul 2016 17:30:17 +0000 Message-ID: References: <5976352e235d43598a2f2d86c919a65c@PLSWE13M07.ad.sprint.com> In-Reply-To: <5976352e235d43598a2f2d86c919a65c@PLSWE13M07.ad.sprint.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.143.1] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] New I-D: draft-bertz-dime-perflowmbr-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 17:30:21 -0000 * maybe good to mention how these rates work with the overall rates defined= for all flows of the filter * types in section 4 should be Unsigned32=20 From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO] Sent: Wednesday, July 06, 2016 7:55 PM To: Dave Dolson; dime@ietf.org Subject: Re: [Dime] New I-D: draft-bertz-dime-perflowmbr-00 Yes, if you are using the IPFilterRule or RFC 5777 Filter-Rule as it is tie= d to the Protocol field.=A0 I also intended for this not to conflict with m= ulti-path based protocols.=A0=20 If you are applying these attributes to another kind of Rule, e.g. 3GPP ADC= Rule, then sticking to the L3 is still fine.=A0 However, if you want to us= e it for the Application level flow this document would need to be changed = and we'd need to incorporate it in the draft.=A0 Is that something I should= look at for this document.=A0 More work would be needed to clarify interac= tion with multipath and other protocols though. From: Dave Dolson [mailto:ddolson@sandvine.com]=20 Sent: Wednesday, July 06, 2016 11:48 AM To: Bertz, Lyle T [CTO] ; dime@ietf.org Subject: RE: New I-D: draft-bertz-dime-perflowmbr-00 OK, I see in Security Considerations. For your use-case, is it acceptable that a client could open two 5-tuple co= nnections to achieve double the rate? From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]=20 Sent: Wednesday, July 06, 2016 12:44 PM To: Dave Dolson; dime@ietf.org Subject: RE: New I-D: draft-bertz-dime-perflowmbr-00 Hmm. Should say IP flow (5-tuple) but that may be in the wrong location. From: Dave Dolson [mailto:ddolson@sandvine.com]=20 Sent: Wednesday, July 06, 2016 11:43 AM To: Bertz, Lyle T [CTO] ; dime@ietf.org Subject: RE: New I-D: draft-bertz-dime-perflowmbr-00 Lyle, This document doesn't define a "flow". What did you have in mind as a defin= ition? It sounds like you are thinking of a TCP or UDP connection? So if the inten= t were to limit video rates, each TCP or UDP connection would be granted th= e specified rate? -Dave From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO] Sent: Wednesday, July 06, 2016 12:31 PM To: dime@ietf.org Subject: [Dime] New I-D: draft-bertz-dime-perflowmbr-00 All,=20 I have added a new I-D for consideration.=A0 It permits setting *per flow* = maximum bit rates.=A0 This can serve in some applications, e.g. video throt= tling, to limit features such as resolutions as opposed to requiring deeper= inspection. https://datatracker.ietf.org/doc/draft-bertz-dime-perflowmbr/ Thank you. Lyle ________________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details.=20 ________________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Wed Jul 6 11:18:23 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170C112B068; Wed, 6 Jul 2016 11:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CtXVjHe2LUD; Wed, 6 Jul 2016 11:18:18 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0136.outbound.protection.outlook.com [104.47.40.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7514612B04F; Wed, 6 Jul 2016 11:18:18 -0700 (PDT) Received: from BL2FFO11FD030.protection.gbl (10.173.160.33) by BL2FFO11HUB041.protection.gbl (10.173.161.57) with Microsoft SMTP Server (TLS) id 15.1.523.9; Wed, 6 Jul 2016 18:18:17 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.39) smtp.mailfrom=sprint.com; sandvine.com; dkim=none (message not signed) header.d=none;sandvine.com; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.39 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.39; helo=plsapdm3.corp.sprint.com; Received: from plsapdm3.corp.sprint.com (144.230.172.39) by BL2FFO11FD030.mail.protection.outlook.com (10.173.161.40) with Microsoft SMTP Server (TLS) id 15.1.534.7 via Frontend Transport; Wed, 6 Jul 2016 18:18:16 +0000 Received: from pps.filterd (plsapdm3.corp.sprint.com [127.0.0.1]) by plsapdm3.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u66ICuhb037865; Wed, 6 Jul 2016 13:18:16 -0500 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by plsapdm3.corp.sprint.com with ESMTP id 23xav9d18e-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 06 Jul 2016 13:18:16 -0500 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 6 Jul 2016 13:18:15 -0500 Received: from PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8]) by PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8%24]) with mapi id 15.00.1178.000; Wed, 6 Jul 2016 13:18:14 -0500 From: "Bertz, Lyle T [CTO]" To: "jouni.nospam@gmail.com" , "dime@ietf.org" Thread-Topic: RFC 4006 bis - Addition of Filter-Rule Thread-Index: AQHR0jyBE8lrISx8fUSaVsB8k0pW/KALvLGQ Date: Wed, 6 Jul 2016 18:18:14 +0000 Message-ID: <52395a50302b4e448dd05d99ca140f36@PLSWE13M07.ad.sprint.com> References: <126260c80f8b4afb87a67c39a66a4907@PLSWE13M07.ad.sprint.com> <49d1b984-2b96-8ef1-2a71-3abcd61e9208@gmail.com> In-Reply-To: <49d1b984-2b96-8ef1-2a71-3abcd61e9208@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.39; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(438002)(13464003)(199003)(189002)(377454003)(15975445007)(6806005)(305945005)(2950100001)(50466002)(2900100001)(46406003)(86362001)(189998001)(97736004)(5250100002)(19580405001)(50986999)(5003600100003)(76176999)(5001770100001)(33646002)(19580395003)(92566002)(97756001)(15395725005)(54356999)(2501003)(586003)(6116002)(356003)(2906002)(4326007)(102836003)(7846002)(8746002)(47776003)(108616004)(106466001)(106116001)(3846002)(8936002)(24736003)(87936001)(81156014)(8676002)(68736007)(7696003)(7736002)(23726003)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB041; H:plsapdm3.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD030; 1:p++Z7YTHoKAST5xxCUELWu9Vre8ZwMAWEgbsVz56GjWQKiOrleQJ5LvN+hLAGOATBjO3U2dk+OmF93CMpdmvZPrKx+ODXZYE2UyBYE3swDUOfWyMGyP4Hfr1YqfIOjyOXrZkJsRFhTIA3YT5t96Jnhf4e7UhhYaqGP74CN2CZLdaRVvp07o0mkQciuRlr8PC1MKEo2SLOw0VECZXv9U6hhX7KMeBXEJGjEwESllDRzO83W8q9RvG/v9IMOig+6h2y5bqUV9pOwlWrIpPOj1ooiax175csaqZfq2WZktjGKY70Zkek95j/bG2UMwyDf6PoBab+jmwOjtJY9ql5/WaBCWIkW9uPnYH0WJPIzKIIrQ0+Y2BRZnUp6yFIQ19UCX2+mtmMHeJ3TNOxTUt5rZOMDICRIU/C0hri1LwacW4uXCj4HAYiN9cUG7Jr5jqklBgl2LK/iwQuvfVCX8KshX+DJ00KFbHzdgYLmi3P3mR7QrR8U3XXT8p3eRzVGyKBPnn8vNh76kC1xAWfWiKmIsmOhNd8mn499LqTXjar7fa4p8vVPf8JxFgJFI3SaBeCTlH X-MS-Office365-Filtering-Correlation-Id: a5e93bed-d84f-48df-3866-08d3a5c9e6f5 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB041; 2:UHY71fTUVflIWMfsdtxdKA1Ia1ASRAGyKkagmHnYCgAIL07R5/BIHjVs1Ytl98FOumFErMRjpf0BFh5AkMAMCL50y0QqY12BQrAe+murWys9QEyV2LfzzP9ZSS3onIfp7q6eCOMzLlEJjRrFS1p51BlZJXn+M4r4SJqfNOKqIbsnIHo8AtrV3Io0lfHKj3lZ; 3:ki5aRPaZkuUPJ0FGdjaIIW53554c9etDoFalfudOoj5O0g9N/vpex3xpjg0j1NPKGPozabB7EeCdLE6mYAs2uFS+qDrYhr5d0kO9E+yGejsRvrahYQ+L4US/GJzZL17y4kxRviIzCayk1GJYiKSuHKt/S2faLYii5keT12vHyK+RzVU6JRXR0v+WLbblP6VaSvpxBOBkfYh7tPvN+0+C+/DX37hb+iqonJ9Yy3OBCSIQkKygf4HltKopKpQccsE7+4LqGxod/AnwHBb19xEO9Q==; 25:58a02gniSXPxxSQgi773H7xtNvrGfWEZIKZxrnQKuwJsh0oF++PwOgFjVrVQhAalTj9Qb2lvIzmhrSQ+TV90JG01OxgwHx5qfjNSEfSECzoZfL3sSXbPOzorNyxFbfC70huRn8IyIZwim7kz+noXuHEf6DlATTcREgz4ZHHKn0DYYtkSGDeSR5rRZsF5mi/gVxWatUYURQYfg0svsMY+/aVBCnBm1FXI5Ch+VInWQWi+Neq0Krx1CHt+/1yx7HPnfKMx/ZHcrAfFF8Zq+s0l4/IvreLOdro3Gdc75L3E16Rw79CHZIfaULQY5chPLC2QYqzZNQdjziYBK+sbebdetUfG83DUU1Duth9Sh9t1i5DYXhbicGE7/5eolyAQVjvNixY7/HBvI5palmqKKlxnP1yW/CGQj2OXxDm8OamXDJErYXI3wYHuPx47xRhRnjUK X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BL2FFO11HUB041; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB041; 20:+zSOsOEKbwwqfXHa+eHHhVDwLrGLwe7pB52lvwHnDwSqT4iyZVZBK/U2DFFTVhDcRoLFTJ5Y+GemUrLp7C2QM7q9yTg/nGmuHiEv/b1FM6biCXwEJhwde8IH8RrKy8KXjbrnmQP7HY9br1vZknLapZVggZiA7LPXeR5LIhZhm55Z8UQDGJNVV0H5OOgDPWZhIwfEZ8JWqOeK+P87bMG4pGd2M3UshPbP/Dg91qUPuptCUK5aiym7D6aI4rs6ShztWUk9Sj0v23l+jSsDeSTRZG9UTNnMS9stLi+ZPdag5Hq0ud86Sc8c8r0qos0n/EIlYIoy6hfkUuRwllcxUhhCHyayp+tIJxjwMCmIZc7map0ud22Km3v9jDRoul4v1mLjF7Zksd1RaVFY+AG1LAO2+C1WMnt4D4qn2axi3HWYJ8Q= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(18430343700868); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13017025)(8121501046)(13018025)(5005006)(13024025)(13023025)(13015025)(3002001)(10201501046)(6055026); SRVR:BL2FFO11HUB041; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB041; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB041; 4:OunqBt+uSptUESWaCZKPy2MNWWTpCHrfIW2vun5z2EfYsOR4vA48aqHu6oTvXfvd42yTxwAy8wzR/QVEoKiWodEgbX0lleA6ZQujNP7RpABr4NwcSD2IrV9hM+NL8EnhGru6W0tRTkVfglYgSqC4f/lyUWOIc9X97kh6stxl8hltn9otPwerldn/iw2PttxFJTXADaAA6VsoDebwbrGL+IxlL5Y06kvGfAJT0UOB2t38W3b+nNpWY3p3kFzO1kPzCiddJsH63QOV5AezGO37B/NYUcQEt2IzKZ3Wc372bViPTd4SlvDmLKzBgPgkNxF+erVJYVjv7sNiozv7wLYKarUqfnioRMdjpDeWBE6ahLXl+Ru3in6W1Exi1ZETy7TJMEridQcea9vQBrJAHnl70DmlSWR8MkvFyTndppCxcMZ4WiMiENuAd1h1W2l6Y8WggmW/66/FMNQZhfV0RT1n2Xv+byiFDkv0MQSzpom72slZQlU8IAF5tG3oUuITx4BjM0YBhsqL1K87JgWj88LEft+aNvP8QC7uIqtYr8W5knS5zMK/7sTYCHsCJiPINfVr X-Forefront-PRVS: 0995196AA2 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB041; 23:deA3UhuvSHiZKGe3tVmynYonIZ5gB2NDdT3hJJfy?= =?us-ascii?Q?1NOUFIYSnCcPUBrpnwj4DrQvE9f7HE0s0hCBJ1VSkj8rVDL88c7Ridg5Wneo?= =?us-ascii?Q?OqK4TTS8Od7D0+2RbjSnKY9y92u7ZCu8/+gNMGBWxpX2FQGE5vjWX6SJ3sZm?= =?us-ascii?Q?55sSpTk35ChQMBWUNc3vWkkzMmPlnxLl0TwoDAYF+PbjU3rVp5lCWSIwV8BP?= =?us-ascii?Q?ogEo7QHWLhFk9UQ/dwc/hUiEM6BPo7Y7df+CQToEPr4dZIP4aWeu931uSfs+?= =?us-ascii?Q?aUuO49ZpVkol4XYrtHHQpCkqXMYbzdCWdfdMRCdRltUnaYzHXxpH4xVgX71V?= =?us-ascii?Q?r1h4B316ajr9XT/KYRFx+jCqYclZ8kBz6WTIOnpPnZir0nP4wI6HfC+lvSVg?= =?us-ascii?Q?VBZ5q7AvBRnIc4MFBdu7aEpNiHK4YMlkicmeliMGtO0XDB/y1I7SSgz9sTwl?= =?us-ascii?Q?rL1UVIWd+Vdn53pwDmCc2CSTKeqIT8++bStEV3+0fb/TDGoqUgH32K1FwbJq?= =?us-ascii?Q?FYn/wFtpJFtUaKQjxVebHtHglOvmTkQ/5ozQeCHZVozVnbegWX2XFrT49ohJ?= =?us-ascii?Q?0XPFT5fTGNmYXnyGObmjltErblj3+BLGVuEfeeUfDwNP9BgCmj8NmWsH6Vtw?= =?us-ascii?Q?3ASZfpu53H/v3gdrTEqnKapSAA+WpfiMxdkyJwLJO4Pv2BRAqM7wHCm/gQlp?= =?us-ascii?Q?z2EDUKwlqXUhSDQTGF62srX8qXV6ZnH4DmqicEB2iSN7Fq+0l8ELeY8ZbGlZ?= =?us-ascii?Q?b/1TOwB0RV+Vp1jJHTTnjvnCbO/Tj8RLvl0Ft36PrUZdOGlTh8mcJVMifBp9?= =?us-ascii?Q?1pTOnDQMjhhjWMwZaWJ435JVhi1FP7z81rASDNHOJ8bjqFgM6MKUowoHabl1?= =?us-ascii?Q?qvDdMf3EVO/wcvoYzwKTV8Xd0BHnKViiifZN+RYRk7OWYOxryCd9tLCd5zxd?= =?us-ascii?Q?1/xIc8u6BLHWfQo3ZCURH90At0wqFGogRSWSGNSUoIlsqWEp8y+abn/inwsn?= =?us-ascii?Q?erwF44k0mQdS1/+vbnyxW8szU/OcW6/FV3zMLhDBElr2Mrleybk9Xxm/gmnm?= =?us-ascii?Q?MsKEU5F9wSAym74L3MZb4NvLC391BTAOWpTcGeZ+3RNVRQG0/LXQu0kjOfGQ?= =?us-ascii?Q?8iLQod8myk793fU9nxsY0+URzXYa4WcOvFZxgr3AQmI+EPIY5Kruua9V31j1?= =?us-ascii?Q?lsGKF0k/KvXYmigzsdHWptRK2Ea8y+4JG6sYI+KPZHiwQtk1/EIkc0vwBW+E?= =?us-ascii?Q?tUExGbJyseykG6233KywbfrROmjc5zKhwZwCEQKxo5Fld/9f1Tjf0ztHwMVO?= =?us-ascii?Q?QBkYhpeu1NdKDKGgUo1ESbvzqfnbxckB1lEtCWLlCygP?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB041; 6:lxuanufYCK4+VoTYfsB81kqdbk9dH8BhojSnuuWPTN6NLlWFMxAgHjgLmlHF2fkLevzhSg7Ta1rwjNzjLGEU8ExLSYrTCMXj8NNPSCeVdetx72nzwCe8W3SwABjZJK7mhNHPhtDTyERsXgtQN/Q+V44xqd6aw9hpmJedHqx7cinfoG16zHwxOYnEspcGtmlllV/Z8X8Uy7gXns6jAbLQsok1G1INWRmG4iYV6mPQTKd3AVLGn8G4ikVNC4FgiHOzrEcGEhxYSjDT1uXYJ4/Syfr7YVmN0o0PAQGkioPakQNheusf/omjSVM+WapkR1dWxEaaLZhdi3xl1GVMiM0vV1eyJvsE/nQnthvf5UVB7nc=; 5:YT5Hl3twE1zu8Btd9M4DekOFQffhpto+ArmxTBZetxLH/y5J+pA7UqXbhKhUrZT1woyOtb6Y90ZCHBGnFfjqRNv9kD8ysZb+M69PssL+pa243qKVd9AUVBVuDZ5H2/EiwARIEpMZ6/nx2+wppTMIHA==; 24:LfQ3UhLJWObWcBa6telT2CRsSQ3KBkhmcAyfY6rowaFV0GrW5IIa1EfMk7SWQ0EOaE1Y+xI+eyYdrZWts9I6p1AbKMioXptSZlZqtdrge2Y=; 7:T3MIpJ1XUGZJ9giU8b0VsYCRxQWXJqcaAAzDnTvNuKW2r5plcUmw2DXspOLIGAdoOgzMUVnlxzEjzgMTe6IHvde0orWo249LXosF2PE4oJYMeXoHUgoiuWrZcGKOhSiuhweshx1GzWhQALi+k5dsJ7hUtWPqxW917rOwzMVOM3pZ0mF7T9Zbn/kwSI7SQtEKLGn/ySFiq819439yuln8Ez0xCVP1l18l5SKjSlNBzAv0jXiGf4BalZC4fLiuJ7R0 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jul 2016 18:18:16.9807 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.39]; Helo=[plsapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB041 Archived-At: Cc: "dime-chairs@ietf.org" Subject: Re: [Dime] RFC 4006 bis - Addition of Filter-Rule X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 18:18:22 -0000 You're right. The other AVPs are direct sub-types of IPFilterRule or use the Filter-Id wh= ich RFC 7155 states should not be used where backward compatibility is not = required. It's also problematic that the Filter-Id is described as a list = of strings. So effectively the Final-Unit-Indication cannot convey QoS. We have some options (technically speaking): Option 1 - Final Units cannot specify QoS (do nothing) Option 2 - Create a 'side-car' AVP that, if present is add to the Final-Uni= t-Indication Rules but is permitted to carry QoS based rule. Option 3 - Create an alternative to Final-Unit-Indication AVP and recommend= when QoS based rules are used imo Option 1 - It seems a bit odd that we can only restrict to non-QoS paramete= rs which can hurt services that need some level of QoS even in some sort of= restricted mode. Option 2 - Ugly but technically feasible. However, it creates multiple AVP= s to look across which complicates logic. I don't like it but mention it h= ere for completeness Option 3 - Seems like the best option and similar to what happened in RFC 7= 155 for QoS-Filter-Rule. We can say if you want QoS you should use in the Final-Unit-Indication AVP then create = a new one -Lyle -----Original Message----- From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] Sent: Wednesday, June 29, 2016 2:29 PM To: Bertz, Lyle T [CTO] ; dime@ietf.org Cc: dime-chairs@ietf.org; Yuval Lifshitz ; Dave Dol= son Subject: Re: RFC 4006 bis - Addition of Filter-Rule I have an issue with this. The Final-Unit-Indication grouped AVP was design= ed to be non-extensible. Adding a new AVP into this group would change the = original ABNF and therefore then technically not be the same AVP anymore. - Jouni 6/29/2016, 7:37 AM, Bertz, Lyle T [CTO] kirjoitti: > All, > > > > As part of the updates to RFC 4006 I would propose that we add the > Filter-Rule specified in RFC 5777 where we use IPFilterRule. This > permits the specification of QoS filters (and other features not > supported by the IPFilterRule type) where they could only be > referenced by a Filter-Id (RFC 7155) which often uses an > out-of-(diameter)band mechanism. In the case of 4006, these values > are used in Redirect-Action (Section 5.6.2) and Restrict-Access Action (5= .6.3). > > > > To do this I would propose we add the Filter-Rule AVP as an option in > the Final-Unit-Indication AVP. > > > > Summary of changes > > 1. Wherever Restriction-Filter-Rule and Filter-Id were used, > Filter-Rule was added (Sections 5.6.2, 5.6.3, 8.34 and 8.35). > > 2. Added Filter-Rule as AVP in Final-Unit-Indication AVP. > > > > Fundamental Change (Final-Unit-Action AVP) > > > > Original > > Final-Unit-Indication ::=3D < AVP Header: 430 > > > { Final-Unit-Action } > > *[ Restriction-Filter-Rule ] > > *[ Filter-Id ] > > [ Redirect-Server ] > > > > New > > Final-Unit-Indication ::=3D < AVP Header: 430 > > > { Final-Unit-Action } > > *[ Restriction-Filter-Rule ] > > *[ Filter-Id ] > > *[ Filter-Rule ] > > [ Redirect-Server ] > > > > Also, in 8.34 the use of the Filter-Rule is noted as: > > > >> The Filter-Rule AVP is defined in [RFC5777]. The Filter-Rule AVP >> can be > >> used when QoS filter rules must be specified. > > > > If there are no objections to this, we can incorporate it into the > next set of changes. > > > > Lyle > > > > xml Diff below > > > > 15a16 > >> > "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5777.xml"> > > 1727,1732c1728,1734 > > < include one or more Restriction-Filter-Rule AVPs or one or more > > < Filter-Id AVPs in the Credit-Control-Answer message to enable the > > < user to access other services (for example, zero-rated services). I= n > > < such a case, the access device MUST drop all the packets not matchin= g > > < the IP filters specified in the Credit-Control-Answer message and, i= f > > < possible, redirect the user to the destination specified in the > > --- > >> include one or more Restriction-Filter-Rule AVPs, one or more >> Filter- > >> Rule AVPs , or one or more Filter-Id AVPs >> in > >> the Credit-Control-Answer message to enable the user to access >> other > >> services (for example, zero-rated services). In such a case, the > >> access device MUST drop all the packets not matching the IP >> filters > >> specified in the Credit-Control-Answer message and, if possible, > >> redirect the user to the destination specified in the > > 1803,1806c1805,1809 > > < filters given in the Restriction-Filter-Rule AVP(s) or according to > > < the IP packet filters identified by the Filter-Id AVP(s). The > > < credit-control server SHOULD include either the Restriction-Filter- > > < Rule AVP or the Filter-Id AVP in the Credit-Control-Answer message. > > --- > >> filters given in the Restriction-Filter-Rule AVP(s), Filter-Rule >> AVPs > >> or according to the IP packet filters > >> identified by the Filter-Id AVP(s). The credit-control server > >> SHOULD include either the Restriction-Filter-Rule AVP, Filter-Rule >> AVP > >> or the Filter-Id AVP in the Credit-Control-Answer message. > > 1827c1830,1831 > > < Restriction-Filter-Rule AVP, the Filter-Id AVP, or none of the above= . > > --- > >> Restriction-Filter-Rule AVP, the Filter-Rule AVP, the Filter-Id >> AVP, > >> or none of the above. > > 3610,3613c3614,3618 > > < Redirect-Server AVP MUST be present. The Restriction-Filter-Rule AV= P > > < or the Filter-Id AVP MAY be present in the Credit-Control-Answer > > < message if the user is also allowed to access other services that ar= e > > < not accessible through the address given in the Redirect-Server AVP. > > --- > >> Redirect-Server AVP MUST be present. The Restriction-Filter-Rule >> AVP(s), > >> Filter-Rule AVP(s) or the Filter-Id(s) >> AVP MAY be > >> present in the Credit-Control-Answer message if the user is also >> allowed > >> to access other services that are not accessible through the >> address > >> given in the Redirect-Server AVP. > > 3615,3616c3620,3621 > > < If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the > > < Restriction-Filter-Rule AVP or the Filter-Id AVP SHOULD be present. > > --- > >> If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, >> Filter-Rule AVP(s), > >> Restriction-Filter-Rule AVP(s) or the Filter-Id AVP(s) SHOULD be pres= ent. > > 3622a3628,3630 > >> The Filter-Rule AVP is defined in . The >> Filter-Rule AVP can be > >> used when QoS filter rules must be specified. > >> > > 3631a3640 > >> *[ Filter-Rule ] > > 3662,3665c3671,3674 > > < IP packet filters defined in the Restriction-Filter-Rule AVP or > > < according to the IP packet filters identified by the Filter-Id > > < AVP. All the packets not matching the filters MUST be dropped > > < (see ). > > --- > >> IP packet filters defined in the Restriction-Filter-Rule >> AVP(s), > >> Filter-Rule AVP(s) or according to the IP packet filters > >> identified by the Filter-Id AVP. All the packets not matching > >> the filters MUST be dropped (see ). > > 4668a4678,4679 > >> &RFC5777; > >> > > > > > > > > > ---------------------------------------------------------------------- > -- *Learn more on how to switch to Sprint and save 50% on most > Verizon, AT&T or T-Mobile rates. See sprint.com/50off > for details. > * > ---------------------------------------------------------------------- > -- > > This e-mail may contain Sprint proprietary information intended for > the sole use of the recipient(s). Any use by others is prohibited. If > you are not the intended recipient, please contact the sender and > delete all copies of the message. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Thu Jul 7 02:09:45 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A704D12B015 for ; Thu, 7 Jul 2016 02:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulnXbuSbC2lR for ; Thu, 7 Jul 2016 02:09:41 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2497D12B078 for ; Thu, 7 Jul 2016 02:09:40 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-50-577e1c512df7 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 02.97.12516.15C1E775; Thu, 7 Jul 2016 11:09:37 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.74]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0294.000; Thu, 7 Jul 2016 11:09:37 +0200 From: Maria Cruz Bartolome To: "Trottin, Jean-Jacques (Nokia - FR)" , "dime@ietf.org" Thread-Topic: [Dime] WGLC #1 for draft-ietf-dime-load-02 Thread-Index: AQHRtdE4jPBCVA2NJ0e3rvn8VsJS8Z/qPcJQgAnlegCAAXp7AIAHc18QgAOELwCAAE15MIABDQ4AgAA9q5CAB4YkgIADOjGQ Date: Thu, 7 Jul 2016 09:09:36 +0000 Message-ID: <087A34937E64E74E848732CFF8354B921975F63B@ESESSMB101.ericsson.se> References: <5b31616d-efa3-ac03-8f1c-bd8883a35d65@gmail.com> <087A34937E64E74E848732CFF8354B9219758407@ESESSMB101.ericsson.se> <3e2082d80d8e45caaca581c9dcc98468@CSRRDU1EXM025.corp.csra.com> <71796571-c370-cae8-d456-9d2dfb02544c@usdonovans.com> <087A34937E64E74E848732CFF8354B921975C3F4@ESESSMB101.ericsson.se> <71ffc339-37e0-e4fd-a16e-59da7fe23b6d@usdonovans.com> <087A34937E64E74E848732CFF8354B921975E5AB@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B921975E824@ESESSMB101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7tG6gTF24QcsnC4u5vSvYLDoOzGZx YPJYsuQnk8fdW5eYApiiuGxSUnMyy1KL9O0SuDJOd09lLDjpX3Hm/zWWBsYL9l2MnBwSAiYS C7vnMEPYYhIX7q1n62Lk4hASOMIo8fPUUVYIZxGjxLre62BVbAJ2EpdOv2ACsUUEciTeX13D AmILC5hLtB6+DBW3kPh8+hAzhJ0n8fHrBUYQm0VAReLxsxVsIDavgK/E9xtLwGwhgcWsErd2 pILYnAKxEkcePQCrZwS66PupNWAzmQXEJW49mc8EcamAxJI956GuFpV4+fgfK4StJLFi+yVG iHodiQW7P7FB2NoSyxa+ZobYKyhxcuYTlgmMorOQjJ2FpGUWkpZZSFoWMLKsYhQtTi0uzk03 MtZLLcpMLi7Oz9PLSy3ZxAiMlINbfuvuYFz92vEQowAHoxIPb0J9bbgQa2JZcWXuIUYJDmYl Ed7XknXhQrwpiZVVqUX58UWlOanFhxilOViUxHn9XyqGCwmkJ5akZqemFqQWwWSZODilGhjF nI3jBT4afP87vyiZp9BI/qT618kKqtsby2rXnvZokHt29oCpdX/6YraehYYH0m028s+63v/O wkpDrW9Orf/dKQwnT+sxzglNK67vzVD7oXMow/6QwrvZlzaZnJe12mrkISXKJd2an1N/2tDX 7LGT4+uXB77EWl7RPvzwwurv0twzfkvyqCmxFGckGmoxFxUnAgAtn/6ZkAIAAA== Archived-At: Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 09:09:43 -0000 Hello JJacques, all, See comments only to your last reflections. Best regards /MCruz =3D=3D=3D=3D=3D=3D from previous emails (begin) =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 5. > Now > The goal is make it possible to use both the load values received as > a part of the Diameter Load mechanism and weight values received as = a > result of a DNS SRV query. As a result, the Diameter load value has > a range of 0-65535. This value and DNS SRV weight values are then > used in a distribution algorithm similar to that specified in > [RFC2782]. > > Comments: > In order to have an efficient load balancing algorithm, it is not enough = for the reacting node (for the node in charge of load balancing) to know th= e Load of each server, but it needs to know the load in relation to each se= rver capacity. Unless we do so, the Load value of a server can't be compare= d with the Load of a Server with a different weight. > Then, in my opinion, we need to find a way to provide a Load value that i= s in fact comparable with the rest of the Load values of the servers in the= group. > Reflecting a bit longer on this, I think we need then to define a group o= f servers in the load-balancing group, like a load-balancing context, and t= hen, for all servers in such a group we need to provide a relative value of= dynamic Load. > > Agree with the thought- if "Little Server" is 30% utilized and=20 > "Big Server" is 50% utilized, it still makes sense to send more=20 > traffic to Big Server. But I am not sure if that is withn the scope=20 > of this document. > SRD> I don't understand the concern. The load values supplied will be > input into the route selection algorithm as specified in RFC2782. If=20 > a node isn't getting enough traffic it will change its load value to a=20 > lower value and will start getting more traffic. > MCRUZ> Unless the LOAD info provided is in fact a value that represents t= he available capacity, then the load balancing will not select the less loa= ded server. Being able to select the less loaded server is the whole purpos= e of this mechanism, then we need to find a way to provide a LOAD value fro= m different servers that we are able to compare, i.e. the value provide mus= t indicate the available capacity regardless the static capacity of each se= rver. SRD> I view the goal of this a little differently. The goal is to make sure that requests are delivered to nodes with available capacity. It is n= ot strictly necessary that every request goes to the least loaded node. MCRUZ> Well, I do not agree. The whole purpose of providing LOAD info is to= be able to choose a node with available load (I agree), but among the nod= e with available load we need to choose the least loaded (or one of the lea= st loaded). It does not make sense, in my opinion, to simply select a node = with available load, when we are providing info about load. The information= provided should be valid to be able to select the least (or close to) load= ed. > Providing an example, let me use dynamic Load (say DL) in % (100% is tota= lly loaded) that I found it easier for calculation: > - Server1: weight=3D1500; DL=3D 2% > - Server2: weight=3D55000; DL=3D 70% > Then, if we only use DL in the LB algorithm, obviously Server 1 seems to = be clearly less loaded, but however, taking into account its weight is much= smaller it may be the other way around. In fact, if traffic is redirected = to this server, it may get overloaded rapidly (due to its small capacity). > One possible way to calculate the relative DL is to divide it by the wei= ght, then for this example: > - Server1 RDL=3D 10000 * (2/1500) =3D 13.33 > - Server2 RDL=3D 10000 * (70/55000) =3D 12.73 (I multiplied by 10000=20 > simply to get rid of the decimals for our discussion). > Then, we actually find out that available load for both servers is pretty= similar. In fact, in this case, a correct load balancing should select Ser= ver2 as the less loaded server instead of server1. > My proposal is to consider this reflection in the draft, and then make a = clear distinction between dynamic load (DL) and RELATIVE DL. We need to pro= vide the RDL in the message, not DL. SRD> This is about how the load value is calculated which is explicitly stated as being an implementation decision. MCRUZ> Not exactly. We need to reflect in the draft that the LOAD provided = should be the relative available load, taking into account the static weigh= t. This is the only way we are providing a load value that can possibly be = used by a client to LOAD-balance.=20 I could accept that we leave the way to do so up to implementations. Proposal: "LOAD should be calculated in a way that reflects the available l= oad independently of the weight of each server, in order to allow the Diame= ter node that performs server selection to accurateraly compare values from= different servers, i.e. LOAD value identifies the same amount of available= capacity, regardless the server that has calculate it. " JJ2> I analysed a bit more your example with Server1 RDL=3D 10000 *=20 JJ2> (2/1500) =3D 13.33 and Server2 RDL=3D 10000 * (70/55000) =3D 12.73 wit= h=20 JJ2> the conclusion to select server2. This is a bit surprising as=20 JJ2> server 1 is only 2% loaded. This example is rather specific with a=20 JJ2> server 1 weight being 2,7% of server 2 weight. I did another=20 JJ2> example with less difference in the weights - Server1: weight=3D30000; DL=3D 30% - Server2: weight=3D60000; DL=3D 50% This drives to Server1 RDL=3D 10000 * (30/30000) =3D 10,0 Server2 RDL=3D 10000 * (50/60000) =3D 8,3 =20 Here also, if I follow your reasoning, this would drive to select server 2 = to increase its RDL. Again the result is to increase server2 load Even by taking a 80% load for server 2 (so a high load in practice) and 50%= for server 1 Server1 RDL=3D 10000 * (50/30000) =3D 16,7 Server2 RDL=3D 10000 * (80/60000) =3D 13,3 This still drives to select server 2, although the reasoning would be to in= crease server 1 load Nevertheless, if server 1 has only 30% load its RDL b= ecomes 10 and it will be selected, so here OK =20 Please check if I am wrong somewhere, but currently RDL, for me, can give = strange outputs. About static weight I agree that static weight can be useful, e.g. a last h= op DA can be configured with the server weight to distribute its traffic a= mong the servers it is connected to. =20 My point is about the targeted load balance between the servers. Often, the= objective is to have the same load among servers (even if they have some d= ifference in their capacity / weight), which is the way to maximize the tra= ffic without entering overload in any server. So the "DL" (as defined in th= e current draft) indicates whether they have the same load, and if the obje= ctive is achieved. For me I do not well see how you define the targeted loa= d among servers with the RDL you mentioned. If received load from servers is not the same, the sending node has to sen= d a bit more traffic to the less loaded node. For this, as you said, an obj= ective is to avoid oscillations, and sending node has to evaluate the amoun= t of traffic it will switch from the more loaded server to the less loaded = server, this switched traffic being not too high to avoid oscillations and = also not too low to avoid maintaining unbalanced situation. In the draft, i= t is left to implementation on the sending node on how to modify the curren= t traffic distribution among the servers according to the received load (DL= ), and I am OK on this. In my previous mail I indicated that the sending n= ode will adjust its traffic distribution according to the updated load (DL)= received from server and converge to the balanced situation, in this proce= ss, I agree that the weight attached to each server can be an additional us= eful input when available, but keeping the current load (DL) definition =3D=3D=3D=3D=3D=3D from previous emails (end) =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D About the examples you discussed above.=20 I think the results you got are valid. Take into account that the static we= ight identifies the server capability, then a server1 with weight:60000 has= double resources than a server2 with 30000. Then, server2 45% load is maki= ng usage of double of resources than server1 90% load. DL/Weight provides a value than indicates the load per "resource unit". The= n, the least loaded server is the one that has less load per "resource unit= ". This can be seen in the following example: Server1 RDL=3D 10000 * (45/30000) =3D 15 Server2 RDL=3D 10000 * (90/60000) =3D 15 Both servers are equally loaded, as long as the Big Server (Server2) is loa= ded double as the Small Server (Server1), that is half size in resources th= an Big Server. Then, JJacques, I think we agree the Diameter node that is responsible for = server selection should have the means to select the least loaded server, a= nd the available load depends on the capacity of each node, not only on the= DL that is identified at a moment in time. Then, I think we need to include some normative text on that, although the = specific means to achieve so could remain implementation specific. Proposed= text is: "LOAD should be calculated in a way that reflects the available load indepe= ndently of the weight of each server, in order to allow the Diameter node t= hat performs server selection to accurately compare values from different s= ervers, i.e. LOAD value identifies the same amount of available capacity, r= egardless the server that has calculate it. The means to calculate the LOA= D value that fulfils this requirement are implementation specific." I think, as Steve agreed, that the example could be included in the draft a= s well, it is very useful to understand how the static weight determines th= e available load. From nobody Thu Jul 7 08:20:12 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C431412D787 for ; Thu, 7 Jul 2016 08:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uy3Nw67byPb7 for ; Thu, 7 Jul 2016 08:20:09 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 216CE12D7E0 for ; Thu, 7 Jul 2016 08:20:09 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id i123so7015441pfg.0 for ; Thu, 07 Jul 2016 08:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=Lm9rG4OQy/Zcd24aaMfcf3hLrfS/dcFYOtMrj6EVLJg=; b=yycq5zK4oKUrLMqTNolbUCjvwzogmbvruQtqJe6du5w2w43GXWq487hEgxumzEqFSO r52BdVYiKJ/BVSOkr85fEzR/KeLYz7WDb0qVE86vK7VyfgChvokm7bjBRm6eAWtCat49 Tt1fqjT/JlHGF8PWy9+8rO6yCOii4Wdn2y6FMhO2Yq6/7YsxYFhybmcn5+cSTc4jNRcp FLKVSeWhgrWu6tSsLzoKJ1+VWtzqkMmZ7gh446P5fGii6HIVkmk5sc2IlQc7p3p/nXOR bWdMKY2uc5EGdXR0+8vnPTBtBCHMv0Ou7qPV/sSMSS94qnj0vRwG4N6mtzRTggmS/HNK SvDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:to:from:subject:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=Lm9rG4OQy/Zcd24aaMfcf3hLrfS/dcFYOtMrj6EVLJg=; b=RkU2uluVxbU2KRaYZAJ7pCpu6Iw/AA/tiakjWoCYDRz1ij+opUybpRi9L247bCyCKT yqfSkm3MU275LO1Kgl/6EwiyG6oHHUVtRTxAUON+7FpWERzVyMLExC9te30kTXYMACi7 946Ju+bt7owmtklUIlnLboFKJXA8rQinDsFP6n6+291ro1UCd/ga6/gWivxdyp8aJeIp 8Klut8modrS1fqj9M5/PPM1X0vjMYNzsJHuKWVOhkiiuLSAP+L/RgMwF4vnH1CBFhb8X pSiTdIZygJh3rVL4dwC96WnCVs2iALUROIaCclpxkLwnJiqoh/pm30i/P9KWaVbnMPtM VBQg== X-Gm-Message-State: ALyK8tKXt1+SJVtrKCe5izTB+wzHzA5mcfs4Exa5VYhXn5IFm3KlbjPQGojcbev/dvcvlQ== X-Received: by 10.98.21.4 with SMTP id 4mr1276352pfv.92.1467904808535; Thu, 07 Jul 2016 08:20:08 -0700 (PDT) Received: from [10.16.65.14] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id 75sm4875458pfy.32.2016.07.07.08.20.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jul 2016 08:20:07 -0700 (PDT) To: "dime@ietf.org" From: Jouni Korhonen Message-ID: <067bc372-46f1-22de-1e90-6a30ab126196@gmail.com> Date: Thu, 7 Jul 2016 08:20:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Dime] RFC4006bis pre-meeting in Berlin X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jouni.nospam@gmail.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 15:20:11 -0000 Folks, For those interested in RFC4006bis work we are going to have a side meeting during the IETF96 week before the Dime WG meeting. Details below: Meeting Name: Diameter CCbis (RFC4006bis) Assigned Room: Tegel Assigned Date: 07/18/2016 (Monday) Assigned Start Time: 20:15:00 Assigned End Time: 22:00:00 This is an informal meeting. - Jouni & Lionel From nobody Fri Jul 8 00:43:57 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813D412D0F5 for ; Fri, 8 Jul 2016 00:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXtL_kGxLupe for ; Fri, 8 Jul 2016 00:43:53 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1C912B071 for ; Fri, 8 Jul 2016 00:43:53 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 14C76208C6 for ; Fri, 8 Jul 2016 09:43:52 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id E405140076 for ; Fri, 8 Jul 2016 09:43:51 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0301.000; Fri, 8 Jul 2016 09:43:51 +0200 From: To: "dime@ietf.org" Thread-Topic: Draft agenda for IETF96 Thread-Index: AdHY69mSLTZW61crSGKNzldnOCsPdw== Date: Fri, 8 Jul 2016 07:43:51 +0000 Message-ID: <12427_1467963832_577F59B7_12427_2046_1_6B7134B31289DC4FAF731D844122B36E01EF7BCF@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dime] Draft agenda for IETF96 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 07:43:55 -0000 Here is the proposed agenda for the next IETF meeting in Berlin. Lionel & Jouni ****** IETF-96 DIME agenda 1000-1200 FRIDAY, July 22, 2016, Morning Session I (120 min) meeting room: Charlottenburg I=20=20=20 Jabber room: dime at jabber.ietf.org (Please join) =20=20=20=20=20=20=20=20=20=20 Chairs: Jouni Korhonen Lionel Morand =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 ** Draft Agenda ** =20=20=20=20=20=20=20=20=20=20 10:00 - 10:05, Preliminaries (5 minutes) ------------------------------------------ Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bashing =20=20=20=20=20=20=20=20=20=20 10:05 - 10:10, WG Document Status (5 minutes) ------------------------------------------ Slides: ... =09 * draft-ietf-dime-agent-overload-06 --> In WGLC --> IESG review=20 * draft-ietf-dime-doic-rate-control-04 --> In WGLC --> IESG review=20 * draft-ietf-dime-drmp-07 --> in RFC Ed Queue * draft-ietf-dime-e2e-sec-req-05 --> in IESG * draft-ietf-dime-group-signaling-06 --> In WG --> WGLC?=20 * draft-ietf-dime-load-02 --> In WG --> WGLC? 10:10 - 20 Dime working group draft discussions (10 minutes) ------------------------------------------------- 10:10 - 10:25 Diameter overload related drafts update, Steve/Chairs (5min) Draft: https://tools.ietf.org/html/draft-ietf-dime-load-02 https://tools.ietf.org/html/draft-ietf-dime-agent-overload-06 https://tools.ietf.org/html/draft-ietf-dime-rate-control-04 Slides: ... 10:15 - 10:20 Diameter Group Signaling update, Marco (5min) Draft: https://tools.ietf.org/html/draft-ietf-dime-group-signaling-06=20 Slides: ... 10:20 - 11:50 Individual draft discussions (90 minutes) ------------------------------------------- 10:20 - 11:20 Update of Diameter Credit-Control Application, Lyle/Dave (60m= in) Draft: https://tools.ietf.org/html/draft-bertz-dime-rfc4006bis-00=20 Slides: ... 11:20 - 11:25 Update of Diameter Design Guidelines, Lionel (5min) Draft: https://tools.ietf.org/html/draft-morand-dime-rfc7423bis-00=20 Slides: ... 11:25 - 11:30 Diameter Domain and Arbitrary Mask Filters, Lyle (5min) Draft: https://tools.ietf.org/html/draft-bertz-dime-domainmasks-00=20=20 Slides: ... 11:30 - 11:35 Diameter Per-Flow Max Bitrates, Lyle (5min) Draft: https://tools.ietf.org/html/draft-bertz-dime-perflowmbr-00=20=20= =20 Slides: ... 11:35 - 11:40 Diameter Policy Groups and Sets, Lyle (5min) Draft: https://tools.ietf.org/html/draft-bertz-dime-policygroups-00=20=20= =20=20 Slides: ... 11:45 - 11:50 Diameter Predicted Units, Lyle (5min) Draft: https://tools.ietf.org/html/draft-bertz-dime-predictunits-00=20=20= =20=20=20 Slides: ... =20=20 11:50 - 12:00 Wrap-up and Next (10 minutes) ----------------------------- Next Steps: WG Chairs & ADs WG Goals/Milestones status, next steps, Action Points, future of the WG Slides: ... ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Jul 8 06:16:45 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B6312D16B for ; Fri, 8 Jul 2016 06:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQytM1L29vbM for ; Fri, 8 Jul 2016 06:16:40 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0118.outbound.protection.outlook.com [104.47.41.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975BC12B03A for ; Fri, 8 Jul 2016 06:16:40 -0700 (PDT) Received: from BN1AFFO11FD008.protection.gbl (10.58.52.30) by BN1AFFO11HUB036.protection.gbl (10.58.52.147) with Microsoft SMTP Server (TLS) id 15.1.523.9; Fri, 8 Jul 2016 13:16:39 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com; Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BN1AFFO11FD008.mail.protection.outlook.com (10.58.52.68) with Microsoft SMTP Server (TLS) id 15.1.534.7 via Frontend Transport; Fri, 8 Jul 2016 13:16:39 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u68DFtun021695 for ; Fri, 8 Jul 2016 08:16:38 -0500 Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by plsapdm2.corp.sprint.com with ESMTP id 241vtr4de0-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 08 Jul 2016 08:16:38 -0500 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 8 Jul 2016 08:16:37 -0500 Received: from PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8]) by PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8%24]) with mapi id 15.00.1178.000; Fri, 8 Jul 2016 08:16:37 -0500 From: "Bertz, Lyle T [CTO]" To: "dime@ietf.org" Thread-Topic: New Version of I-D submitted - draft-bertz-dime-policygroups Thread-Index: AdHZGpzegyvP50OJQ6iyFI17pkGouQ== Date: Fri, 8 Jul 2016 13:16:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.23] Content-Type: multipart/alternative; boundary="_000_dd8949f670fb49439221a3f229543697PLSWE13M07adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.38; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(7916002)(2980300002)(438002)(377454003)(199003)(189002)(15975445007)(6116002)(19580395003)(450100001)(108616004)(86362001)(3900700001)(81166006)(2501003)(16236675004)(2900100001)(189998001)(15395725005)(6806005)(84326002)(8676002)(230783001)(5250100002)(5640700001)(102836003)(19580405001)(3846002)(11100500001)(110136002)(2906002)(19617315012)(1730700003)(586003)(87936001)(790700001)(81156014)(2351001)(97736004)(92566002)(4546004)(33646002)(7846002)(19625215002)(24736003)(8936002)(356003)(54356999)(107886002)(260700001)(7696003)(7906003)(68736007)(106466001)(512954002)(5003600100003)(19300405004)(50986999)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB036; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD008; 1:8iQbux8hMfcokFiqIXrBr5KhvevjLuqchOzEE1TEffEQV8Gs/NfCXgxbBBibN9BZrlpCScaB6mfUdZB+AxP6goQxkREOxtKbcoB5fDAoZYo+gyUssKMGlW2SuJjygad7Fi5YdbMmJvG1EaLW1qABPCdopwzxteFGo0pz/Iu/4WkV/vlImukkAnoaJCu9rfBCg/Y8op6FcQGQnukl4/b072kGunNlCB5sSci29IX4UUUcxnlmD1zEUO3qRcs+nEOczVP6v472nuBG8iw4xhfsqrcPQ7k3anZhVujYdiYNdysa10o1vmI18yU2kNe+Z4C7VKt1w5rMrpfu7Mvm/vWSTUUJciKNLrTvw5YnifFElNBIM34uIQ7eo8+ePCzfUWKnSRSWitzLTtHYRSqoaq8e87I4HrsD7jDHhqTzlLMqaD0Ux/yxQ2kku9Ab3xBMLLqrPixW5oTSyXH/u/ALbvI9juiWpmn64CI6PY3cByYVKTA9D+OJbW5d+CeZmXgA7m7l5s/1e5RJ1UWEYwNZiz2yrVBrxMLfl78Z4HSBCs8c+bA= X-MS-Office365-Filtering-Correlation-Id: cdbda66f-7527-410e-452b-08d3a73218b5 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB036; 2:gUInvxu5jeae5pyRBz3zucy4xIE3kN9dRbXdizqGrH/14QM68Mc9G+o+gwIv/VGL9lfMc1krWMM4DNlo2W/MBsWriEoBpU20F6ZjcjgMyQEipV+t2nSvGsCM+Z2IGA92FGtpnNzytyonfP+iPyI9Td/QOhR4VaLJylw4eKZwanRuWTf+rreZ0mzr/LfdY5Un; 3:DQyxO+O+bTg6fq4GYRMQVvl4ZqpziEcWwDrK+XLEtZ0bbO5oOCCa0M6/BkV11d2HMkR+1IInw3Ofipr9pLW8ujoHgj68VB9Pr6YskrLMWbBPl7VE3TQxL2VULcxKYn77ivfco6XNaQAj2V65kJAlvVKyJAX2BAUhZC9Ahz6PYFEScrLYMtpcezyjk4f3xlxZHdZvR+xEUtCG1hKnuOs/KVzUhSYgUNJrF7jBN8LBhuvc7oc8eEwaF1/r/xBkK8JwOoVTkKHUuYlNDf6BdjDO8Q==; 25:yUyNDpJ9ZpFhZxERADIIRZzhxL+W/wLbZi+XQyIpcCa+w6Jo6lZVve8+EqbJekwV1gIG7qXvvzXtZU1u16f7ecwBpM1PNWbhw9XMj7QrtZ6alYAGsTCoZXQF8qtd1f2pVSgiEu5LACBXeDMhsMXNrA/YtovnaiIji+AOB2qPyJLmFmE/0FyfkTqQV99Ugt6Qzh3bRizKgQH91C9ZU5vukpg564HebMUPjj6DRH0P4g98ny6qcLzJPdCihlSOIqDAuc2P6dMs25UsKoZsJzzN5pN8UlXvxG7eOlybwpxiEm8p8jZESHBhabALzsalyaWDRNxeDiBQ6zMT1HzrwBsTx+vVz8tv6jG9tEfRcjneb/suNE/x+4QRhhhWb/EId1eISuCrqktikyDpU6z3mkzn0sBYTzarBt3ZKmDdVO0LTtCW5MBuZFI2C7gWQJxZTJYu X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BN1AFFO11HUB036; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB036; 20:BW27th4wAdcBLF2if7nN4MssKZ9+agwmd5mcQMtTxSqPto87CIAp7q9RKV8ScjeeCF5dM10R0K9VMbFgbZcOtuRD5ABpakqAWfkDq0+Wse7wfLc9B3Uato7VnPz5CQmhkWFcq/xv+CGl9eP/1jvLPWwfjllPVY/EMY2IfYfGZ3SM8fLktPxkRdCpmTtQYFsOpD4+mrjKiPQVAdfRRAeeoleSE7DXnUQ6RXHuEIzZj6ROAjg04PU4KcA/Nv4oFlSCZsfQWW1P9tRQHyZ0hHHmheuX2VcbRbnQ46XKvZexOY5Ecd2oY4HeFvJdB7ugTepqlRgdLxgY6LDaFQAMXHd/yHTKHflG015TWRTsacMiBpMAuPy5TN+e27SHB2mMlbfaqxZgbP54QSr8ih0v9PSLgJuALefBUa0GPYB5lwi7QKQ= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(18430343700868)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13017025)(13018025)(8121501046)(5005006)(13024025)(13023025)(13015025)(3002001)(10201501046)(6055026); SRVR:BN1AFFO11HUB036; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB036; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB036; 4:rbeJeAdmEmjDQKaVURLuKjq2Fa+Hd9Qop2uzYs+uUOqTjVjVvioej2TO6nAviCIWK2pT3DZl34bA5euEcPv+5YxdjdHK1sof8dW9mouw0by4lCOUJQRxFbmxk459z2jIm+f5dDHyx6WaRsHlna7nAYW9uarCBmTr46pLooJ/5M11vfztt+TOSlZztiOj1x0prXkMKUIDBZwlYRrH2SgiEhsMAUs115x+b8CCtSDL9dp5sCveYdIByGaeFefgxJ0ctjLvGUBYzk7CVCyFeIfi2nXv5+3K2VOEelnAFD4ybZ1fypCH/1NHMas6epCbQbgKmyddq2xUaSmbdPozadXsYKwlPeIJRlL+tB9uWtJ4bRC6UC5c42mtbkH2Kb2G1b6bzdsLvKg+hFFWVn6j8UEYbUKEboPJ3jRtpaOXvQy/em5HuQec+KbXEYHV0sr/KVfw4Knl7p5e9SABprR0Q0m7jFPSQr8nO5nx4lTwpcPz6IPTGCi4qQgBEq/isnUdtdJQqXxOG4IO/DIvvdaZq2DaRtOPOri4l4jWiU/bIqxKn8hyG1ByraRbcCCRgUgs+scpxo+mTxe5VAzcco3lhVwZzw== X-Forefront-PRVS: 0997523C40 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB036; 23:aGznANHnJ9oPmMR8O7FyafPUeoSPpbIzpecPJOe?= =?us-ascii?Q?iNFb2OI4Ftm8d0Yu0Cw/MgpcCikBdqg9ZMsPKojl/ZjdGZlwCkcNeT05OXBm?= =?us-ascii?Q?ElnPKgZVmHfWD4uQq0WG9P6Y9EpjXAz+7TYRmG9tB4cLcsHAPQrRt43SBu2i?= =?us-ascii?Q?ZczOI2y5PjBvP/ML5bz1cu1eVR3ni8s+7U01P9Wn99iiIRVUeflUBDepf32F?= =?us-ascii?Q?RAI+hpoQhRx+83gFzxFKUe4KR73E1U8h71cYy/aWso4APpnnFbazV2sVokYK?= =?us-ascii?Q?CAVp/LMGKVPnBHCASTqe/kS1l3XxYUyL4+NVvsHS9rcox3/VmML2LXf2EGee?= =?us-ascii?Q?r5fq73CwoGLGBbnSTfUOrZyW02jCfVi10UdmJHH9eVGNkERlrJBMMlcvjRh2?= =?us-ascii?Q?Y+gNojoBZCjeeC6X8JLwS0ErAK1k8g9XSXQYUj+j8uE6WuPoTFCfCDB1Gu2m?= =?us-ascii?Q?IHmNx39yCHNQKVOQse5JJljIerqHFUinx3AUDGmqYhp9ovRaIZgDXB9jNMQR?= =?us-ascii?Q?VGHGDU5NDzgQcNdZv2aSL7H0DAoPlDGP0hcxBoQ+yg+5aXvidtaQbyryeWiT?= =?us-ascii?Q?Dn2LQCdjAwzYKotS6HSTd4aXr4iKDIdDbN7KFUMDPq1vJH356sOl3oUeTn7T?= =?us-ascii?Q?B+ZD6AS1kB8p5P/lM9BIJEhzry1YsykklP2zNcBl8r20/JaCnMFqR0TEezFr?= =?us-ascii?Q?5oEhDUGfvXdYhoHZR+VwpC2B3R0jxRhMrhLm9UEM5/1qBJWuDvkw7WGVZW/i?= =?us-ascii?Q?VUDTCN36zJspZEPcPKgvghGKpyfudcwuvJVYc/1z2CgMP/dV4LyFLWw1m/jz?= =?us-ascii?Q?80ejr2s3CPnVU8Bi5m8Ne5dFipTxKCL3DBdNk/A8us73WzliQHG/Ot47Fh77?= =?us-ascii?Q?XsRH4qHcD5jld7rWgADQ8QtQfH4n2mF2BAnVH5HcqcYRI7swnQGSpNJfjUfv?= =?us-ascii?Q?ofvONXRTe6eUSRme0KYLGsNBHunCFYGVkgljRdgtFqMSUvJ3NB85tOxpVKJg?= =?us-ascii?Q?vOalWBPWm7TxcHRG7dmjPP2gQxykJkOiIAsr144xTgqpfusXd0LyrYaTy7ci?= =?us-ascii?Q?jfVQsyZWile4Jb3AiGOoo4kWJpoTc1egvdrjvG58mNLX+jE5NLTILjXDWnAK?= =?us-ascii?Q?Le+IcXXh30v6+Cv2nP4oOgm5jd89ghb7ElB/ofRNofCBasdYVh0hvObtkKRM?= =?us-ascii?Q?MLBXNEcFIpcNYiPXtYEVkv/SWsbklxB9Pl05A1C5HzMLLp+S4F3s6R73myM2?= =?us-ascii?Q?P1SeiCes+gRfu9E4NhPXy8W8m73fGcziAdKSP1ZImwBg28/w0GEvX89WDg5x?= =?us-ascii?Q?nRpI4/ltNn/Hc422fekEfASBRy1dHNjlluCzcjB6jXRYwNLmIrzq797f3GAv?= =?us-ascii?Q?FjefGwBgUMYpeh4h9ndU8zNWAsu1CT+pqidaETy6PF/fhpdE5a271FTRr6up?= =?us-ascii?Q?RTi7xdF9o9qv6LEZKftdUNAEZF4zl83gacKYR8yjvluwfeE742ra7?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB036; 6:XbDTpl2yWJxbB1aU9lr2iGC0XFstnIag8GlzcqEbi56Xg+SLwX4XxkeFPeQ2wH+QqepJKFrIFD36nPz+BzQa0Bs1ISeJGgMkWscPEfQHBz7BPIbmCOQMkqAJv2C7ph+WrFt+uu2oEp9P28WFiJot3jNgohlXl3x2ljPJqtNa1tDCaZWN+ywZ8Wm3VcFjgbk6af6djtrR/QtRJrU63Bt3CnuTuUQAcPQnrUiNZ5anuVAFa8SXnDyN8kK0dGaYHYHiH4p3k17jmhW3tNvJ2cHsa2SgdTyilO+cmvwhgUj98/h+oAEIgTb3Wb0r1nAsI2UtN9xtEuANKlluibCeNkYJZuq3J2hA06jBNnZUKOyC5d0=; 5:oOGIA2JTcHgY04SvZRp38ohfInKSPsClujUumlaU5o4j3PWTP7/Gl7nyqT2SpLvRAMAazSKfMw3dBlyUM6ohCgpyCFQ6HswY67YsxfShxX0I8HgUaYS2S3wZDFmFPbVPvXWPTw1CjkDxhag+egdfGg==; 24:iH7IzX/Tka+KJyUnVmmZVH3Wb/xOfvV9iOE6WV35W8J/X5hB9EaSFKVDgJQaOxqyN3llYTwBXY7tfEt0j9g49dhTsJf9zoKr7aXqUqB29dA=; 7:WhHMF/YhjhFDDdlZJurn3tkegkRUAuGwi/ANkzqcESc3UJPK+LulBNJw7TKhUdJjCyeRVm1ETdr+Uj5T6uAJfsbsTdaYE5o3iqQH2O7KLHL/J6jFOG0XD7PN3LCY8jOUVV5tyhp1mdB9DOLWHpHv3SHgFRgp+4c9u3nIfbrXLwD9uZooRQ1Zk4L+zdN1nODuQdccm+T+Ycx+kb0aBJkmjLIsxrngjRq9jfAVDcgH/TiqPqJjLiEyOJ33ejXiQbBU SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jul 2016 13:16:39.2548 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB036 Archived-At: Subject: Re: [Dime] New Version of I-D submitted - draft-bertz-dime-policygroups X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 13:16:44 -0000 --_000_dd8949f670fb49439221a3f229543697PLSWE13M07adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, The Concepts Section has been updated per offline feedback. Added This mechanism creates a compact bit pattern to be used which notes when a Policy Entity or Policy Group applies to to an Authorized User. An Authorized User's memberships are assigned by a Policy-Membership. A Policy Entity is assigned membership via a Membership-Assignment. Multiple assignments may be applied to an Authorized User and Policy Entity but they MUST have unique Membership Domain values. It is also RECOMMENDED to avoid numerous Policy-Membership assignments for an Authorized User as it delays computation of the Policy Entities that should be applied to their Service. Memberships are matched by understanding the relationship between their values which are represented as sets of bits. These relationships are descibed as Match-Types and are specified as set relations, e.g. subset, superset, etc. To determine if a Rule is assigned to the User the following conditions MUST be true at least one Membership-Assignments must exist where Policy-Membership's Membership-Domain =3D Membership-Assignment's Membership-Domain Policy-Membership's Membership-Value MUST satisfy the Match-Type for the Membership-Assignments' Membership-Value From: Bertz, Lyle T [CTO] Sent: Wednesday, July 06, 2016 11:37 AM To: 'dime@ietf.org' Subject: New I-D submitted - draft-bertz-dime-policygroups All, I have added a new I-D for consideration. It permits grouping by Base-Name= (common in some 3GPP) function as well as membership sets (bitset membersh= ips) that permit rules, filters and other policy entities to be used as a g= rouping mechanism and to support patterns for policy based provisioning. https://datatracker.ietf.org/doc/draft-bertz-dime-policygroups/ Thank you. Lyle ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_dd8949f670fb49439221a3f229543697PLSWE13M07adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,=

 

The Concepts Section h= as been updated per offline feedback.

 

 

Added

 

   This mechanism creates a compact bit pattern = to be used which notes

   when a Policy Entity or Policy Group applies = to to an Authorized

   User.

 

   An Authorized User's memberships are assigned= by a Policy-Membership.

   A Policy Entity is assigned membership via a = Membership-Assignment.

   Multiple assignments may be applied to an Aut= horized User and Policy

   Entity but they MUST have unique Membership D= omain values.  It is

   also RECOMMENDED to avoid numerous Policy-Mem= bership assignments for

   an Authorized User as it delays computation o= f the Policy Entities

   that should be applied to their Service.=

 

   Memberships are matched by understanding the = relationship between

   their values which are represented as sets of= bits.  These

   relationships are descibed as Match-Types and= are specified as set

   relations, e.g. subset, superset, etc.

 

   To determine if a Rule is assigned to the Use= r the following

   conditions MUST be true at least one Membersh= ip-Assignments must

   exist where

 

      Policy-Membership's Membership-Domain =
=3D Membership-Assignment's
      Membership-Domain
 
      Policy-Membership's Membership-Value MU=
ST satisfy the Match-Type
      for the Membership-Assignments' Members=
hip-Value

 

 

From: Bertz, Lyle T [CTO]
Sent: Wednesday, July 06, 2016 11:37 AM
To: 'dime@ietf.org' <dime@ietf.org>
Subject: New I-D submitted - draft-bertz-dime-policygroups

 

All,


I have added a new I-D for consideration.  It permits grouping by Base= -Name (common in some 3GPP) function as well as membership sets (bitset mem= berships) that permit rules, filters and other policy entities to be used a= s a grouping mechanism and to support patterns for policy based provisioning.

 

https://datatracker.ietf.org/doc/draft-bertz-dime-p= olicygroups/

 

Thank you.

 

Lyle

 


Learn more on how to swi= tch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details.


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_dd8949f670fb49439221a3f229543697PLSWE13M07adsprintcom_-- From nobody Fri Jul 8 08:53:36 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D145912D7C3 for ; Fri, 8 Jul 2016 08:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oY3KUyzQYXa7 for ; Fri, 8 Jul 2016 08:53:31 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0136.outbound.protection.outlook.com [104.47.36.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8813012D098 for ; Fri, 8 Jul 2016 08:53:30 -0700 (PDT) Received: from BN1BFFO11FD044.protection.gbl (10.58.144.30) by BN1BFFO11HUB006.protection.gbl (10.58.144.153) with Microsoft SMTP Server (TLS) id 15.1.523.9; Fri, 8 Jul 2016 15:53:29 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com; Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BN1BFFO11FD044.mail.protection.outlook.com (10.58.144.107) with Microsoft SMTP Server (TLS) id 15.1.534.7 via Frontend Transport; Fri, 8 Jul 2016 15:53:28 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u68FrJrY019741 for ; Fri, 8 Jul 2016 10:53:28 -0500 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by plsapdm2.corp.sprint.com with ESMTP id 241vtr5g03-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 08 Jul 2016 10:53:28 -0500 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 8 Jul 2016 10:53:27 -0500 Received: from PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8]) by PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8%24]) with mapi id 15.00.1178.000; Fri, 8 Jul 2016 10:53:27 -0500 From: "Bertz, Lyle T [CTO]" To: "dime@ietf.org" Thread-Topic: New version of draft-bertz-dime-perflowmbr-01 Thread-Index: AdHZMK3zmda/YWBgTWm+FxKYprLEgg== Date: Fri, 8 Jul 2016 15:53:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.21] Content-Type: multipart/alternative; boundary="_000_eb509e65929540ffa3cac4ee465e7a20PLSWE13M07adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.38; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(7916002)(2980300002)(438002)(199003)(377454003)(189002)(7696003)(7736002)(512954002)(87936001)(8676002)(19300405004)(15395725005)(586003)(5003600100003)(1730700003)(6116002)(102836003)(19580395003)(81156014)(81166006)(19580405001)(2900100001)(86362001)(7846002)(3846002)(230783001)(356003)(790700001)(5640700001)(97736004)(24736003)(5250100002)(4546004)(11100500001)(2906002)(260700001)(16236675004)(110136002)(19625215002)(189998001)(84326002)(2501003)(106466001)(450100001)(50986999)(3900700001)(92566002)(108616004)(107886002)(33646002)(6806005)(2351001)(229853001)(54356999)(68736007)(8936002)(7906003)(15975445007)(19617315012); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB006; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD044; 1:+ZwF66nYm+PFIqnb+qU6dZj3r0pVLv6aioCco26XZm7rG3ee+FSlwExi96krsWwYYLLlKK/7J3FagGFcfDN2Z5XU1owhrIdy6SzRWhfN3+cCLbRg0OPt8X0+wmM+KpRWVTs1e+OZPaaRsHwD3h8dcl4Ofe9TWJr2kzjiIMDRqQteTqv18GdIF7QZSN5X/3v1nIWm21q/VI1jHo1dWNxGW94p9FskmSCbBrucwmPIZ/SN5PKdVYuQk09u7dGzGAe+nAucBFuVZGk8KpTET0V+IOiuZTbJcKAtQyzyBuZ3Mjxw+W9+I4FfeHDmoHObjc5uGgomChuzj9LE0vbi/n/GeZfG7tQioPDNns1DtS3BXhBsOc0U6+wcQvd/9HTeHtRP4HVFh3Kn/jO2HDv/23DunVdb33B+8GX5nvRoV+hBjf0iRIqgOBJMYxN/EQWKZUiWL32yAcjYS+7ANwszLO0D5tNgKL0IHY3279ga+Ix6SCeqZLMNJm1WeU0defO0cNWE0CkIPFwUVsgFefk3Myb7YnlJ4510xa1bhrro6Lj2KIA= X-MS-Office365-Filtering-Correlation-Id: 47889bbe-b4c4-46e9-bab7-08d3a7480155 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB006; 2:EKEMd+BWrRGPM7aPkAbu73JAGffdPq+NHHKaG30yMIwiAfjts8WYHyNeiHIJUbgqHUCMM1Qsg1DIR29WXZx5/hKinmfez6mdSr8s+t6Uk1RN1yJN8urtjDeAOIpji7wlWjLFCpvG1PvThikRnIoTEa4C9ZAjc2/ZAK4VF8NCB4TYwB79An6KfK9wccsZcD3h; 3:IpNfXtWfYZp+UkqOkgi3SMGtYD+F6+SnZJyKHel5uhjgmJlPIiWplk33o9cvV7jHqX9W5rXaY2cQv4JpOEVReDWs8ryRpSgVKplepYBCjuY0vIKbikmg4oCq/4wG8XCeGj8yo2Hcy1hVRrQ/Jae0qMnJ+omB17AvSDyGC/Uobk+tYQEsDofVxDhoyPiliajma36gsMTZHWgAFev3NsiIrBNRRHiAAdvHYTcflQvRcPsq263uu/c9Ue2Tk9UipO3lGWEi1WnMrD3wVoZ1hecHpA==; 25:QUKSebmQqpoiagsN1mo23TjRKnndRCZ14Xv11RU/45P+IjTs1wlSCJxM37epE8Ywmr6/Uwb84QTg44JvhFnzIIhjLEFd2Y9O0tpXgFzjTEollKNs0X+bK7etPHKPSjKs9g1nRTV2S4FtvKmDs/KDPTiTvPqly4E1yqf2POkMjOXKyLc7Q14YhB6n8tSA3J0KRCbpxOf71WzYG99BeMGmfuy288sdPdNmjTdfQkurmKvQ1PuWvDmO5cGE7ltyRNj5ZwIZ8vLt0BVIbHb8PQT9OdzMpsWz9v+619uRA3wnsNFwlKBlnpVOaLDEQbMI6ZUs9DQoTTQddUmQBQFfqU9n/iicgigcoEyZraoRk/BakEOaUGIK72KG9EHwtIBAaCz9q6Kd23YQFacigQNwYmA1zBT/isUoa4sEuR5KDhcdpNl28hoQRizNrvSRUR/15/6m X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BN1BFFO11HUB006; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB006; 20:VdxSfHKsAb3qRRAgovfA7U1urxXPHQPQCPeg0ligDB2wAd+xp1nXRwBc7AnxBvvCL99UewCgXWCPYOAf3jtW/WVfRGLhNHTWI6Ui11Sn+dkkwxM0GohvZ7891P+FWZfIsg8aFeblop0/mm+CLyBHqyo5FSA31LNXnL1cSL2FuO5jCVFtwwSwXOYo6ONB9iNXTZW519DQealPovUTewtL+VStBkIXasLjfNilZqiH+sYhaqiSvaE3GC1t3LkC6A+LmrmFQt6jPwRH82krmQo4rpfShymofdOtLnq52Trvs9EyMpKxSfP+GPPPoxkPGNr1ph+ix2yIWiWktfvaxvZzfDj92SatfZVkDA+Ix2b7WXGvTu1UbG71iyNJ2yN3wePRS679eULKUyvzTwx91NIVkFwDsFyUy/x+/KIZyqZuUqY= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(120809045254105)(18430343700868)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(13018025)(13017025)(13023025)(13024025)(13015025)(10201501046)(3002001)(6055026); SRVR:BN1BFFO11HUB006; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB006; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB006; 4:WT3uiGrr7brsTyHtCRtoyEMLBuj3QYBJc5YG49Hx+wYriF937+vn6cFi0ZJ2NhtKt8t1yxXwdVQKuns6J6CbowWnF2Fy5eSudlQJmC2Wbh3mXlo1kOvX1JSVDXDH1FlY87NZICQ0wHUTKY/j3Ow8A/+33yK2IP9vHdyhgqBvHJb8X3XUkzallSDVxrROz+KC5W8vMLJlaZSt65CO+8eoQ5EKXD3L5d/y+xrKzXtkujoOXYBBEWB/4JF4LC+NXFJwsSOs+1Bb+jn/cHY6YGe9dsyO389ohcQFUgf6uBibLMUZoXaC2w/eQgRDGybC0pSNf7NDV94FJ+bdQ4lpyNLCxlH1xMEPNkHM18HkHcvrWeih1mCkrOphJL3H+AIuaJiCQH0p3GvFj4ID2eDgOtebfn5OcRxAcEfme9IJldgyTcvyzCbwVcrwDbKh0Il8hBECHksD2yFft73LgTjnU5wYVDzlL3c+/tDUDTMfTsKn0CYFw3//aUpjsApnH8LIoyp3pXwVMUJYgOUulrUq5NWrNrzlUJmQtLH4wJzABi+e8OrUB5WNoRrmY2OegeuIbjoeNXSXDCGDevOV4Zrp4QDW2oPNJf0WGrYTIg20TUsPPQTpi0UxpFq9pAGUFzkA6H7k X-Forefront-PRVS: 0997523C40 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1BFFO11HUB006; 23:z8aaoGuJvl3cUmyn9jTG4uT4qCQWx3DIGd5m968?= =?us-ascii?Q?xAJmDcCODjzVTKe/OPq22lXagVMwx4LvLUep/tkjBkhVSbeXEDywuGMPcN4V?= =?us-ascii?Q?ddm92CfamD9Us3m/zG+HZ8IfN5UWA7vnDq6wFhMjoNHiBb3NcarppGOgpZFm?= =?us-ascii?Q?t0CcsbvRlq7QmmpzuaGLcXhZsRLEqgA6tpQIATwmKaEez91rHIn8Cqm2J7QA?= =?us-ascii?Q?mzuxV1N5sv6xSsidf5Fum6qRLPgQ95JJ0VGCohyRxskwq2Y7l5uI0SlB0gXw?= =?us-ascii?Q?ekupLSV1HwEA4G5r5F+QR4W3VMucQ3jB2BtvpMFNMH+wVM94fNkAIVt8kp/W?= =?us-ascii?Q?pm1mCNTKad2BlqrglMliIoDTF2Y6PCeuE0q6JTMWEQblPL2BRDOwMxjraHBf?= =?us-ascii?Q?kaOjAKclihqW02Su5BrJB8edLgXPO1VOxsXHyWD6Frwn8MwPMN9gGhtDF/To?= =?us-ascii?Q?PCiqp53VLwPtHbqvi5W9+qCD7cTWTimgAhXgB/h8Rf7bKbo/cghSAYb0tgbH?= =?us-ascii?Q?2tcJ7IJubUo7NUFXkEbs5GcWFk6EGAaLOR1KCNI1Fo9hBufH+sW/X0D8AlIc?= =?us-ascii?Q?g/Xz17fnEQqhqluwMQGEL2+2peXmkCWaJbr4goFwSRa8KNcaQhsI4A2o3y+J?= =?us-ascii?Q?9K1vvELPDj6sknsb33jQljcI8r1gBiGqZdB2tcK+VudrZIlBGPg4DZlGFI5v?= =?us-ascii?Q?EdKpm57KOIuVGQ1l4Zr9WEDzjKIRUNChZvntodBrSXfZfl19dZIlFHWYm/4+?= =?us-ascii?Q?vuwBVWU30TDrZxi9LJEqhCeXDaLWGshKIrx3+Ne1ADZEvTya7xNRD5lm2acU?= =?us-ascii?Q?bTWl/nDIvakvnWNAYo1bKwYmjOO42Hz+DLYZbSLc9XqVwoIM2cv0MR5SdUKc?= =?us-ascii?Q?n1WySHjealmY0xkyOhr9SvtyZBnVkXNnLEy6pAsnHgd620sdKfG6kNup00Nr?= =?us-ascii?Q?2mIWf47OLTk3EwpHcVmhNkgnuFOc37WxaML+i49/K3u365ufEqNqEDhOp+b1?= =?us-ascii?Q?6g7UhzxIauWIWxKT/IaTMwfSyhdeYW0IrVlQJEe7H396Z2V5w/Vf3uq490lo?= =?us-ascii?Q?e4WJu38DDbquhaaUCddDcQazvKgZ8F3zkX4Y+IF5DpUyIRN8lHx+sMkp7Ovo?= =?us-ascii?Q?m2Cwix+riXFF8IaCzv+f/f8uJYofJ6ET3lUh6rDULzOf1f+b/7H6qsHpjdZw?= =?us-ascii?Q?EwpsDevQhYp2ZOucisHCp/dAPk335MLHAc8LQuw+AHrt7WG6qtL3HKQ6WUbM?= =?us-ascii?Q?wBJ9ZdF20w77K2uDh74MQsCN4OpItJllDBGLSnUCF4ntmiaNd0CPSTLFbA7C?= =?us-ascii?Q?rs/11qDyZDFF5BHEfNmEGpnNAU1X+bnLN86Tz/MBHi1V5B65mJmNyrtP4o7q?= =?us-ascii?Q?BIadZEipiGo0/1mRhmQ/tCBtGFHwULm+tl/ocyRm6QSuGbxGxS1+8q1A7kjF?= =?us-ascii?Q?eIe8zIC94qrX6KX5uexZphpJPSp9BoIZV1BTlCy+M02gUf1Q4yQpn7WFTXFI?= =?us-ascii?Q?DQVaPAjjqs+J61w=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB006; 6:nXQtZzyCcL5aPbqFGo4Zu0QuGkWs++0AsNZ96lJlvW0J3G6ZgxjxcUCXzb3/Ya1zZmA+OHN4uk7ha4WwASG8rfFSoWbV+qh8bPfHNQjZSkKl22ignD5jUrP2694TKzzr6I0HafCEFowga9Ed7vgYGuhzyJ1Z7mrMcYwWlybmT8ZqFR7T5obKM4U0bj5nx7eAlD/vRroYyTmFp0BH02WgFDi1MsAHQ/ZEDqfesDDre1xI2bSnqvvugROWqIBQztCtOxrJ9dMzWnzz5+9tj15owUIHpW9Lab7EHGm0aFTnHls5AQa+6Ho57Y6vlZhExBcsRncqEVp4eYzXohl1KmJZ6jgsk7+RoaAYCQR2hZrYPek=; 5:plhzeNTPer0tQODaA0scmTNt41LaSI0Gwzus9dYNnMiFXuF0KEqk0vCUkwT6d8KVfg5FDOuXA5NDoobXRmW3VvGCpHx/vAyfyawIC9aWGBvqcLCOz+eHKLMk/DBcPKBUE0cGT0rSQcnyskqW0wctZQ==; 24:aLVwmrT5ynPC7Ptq1SK4R2YgcRBSAtQANw1PMHgdtodGvJxaPv8vGwQAtL0SD/f7X3pAqgjVdkHM4DH/Sw2Ey/uGogTODnGEMtMKixZsKW8=; 7:JbOA0wS6H2raNlB+4zmBFAdJ0VRm7cdPYA6rsJqqKA8p0F13kiNczb8gb0KtpKJULmMlJVjHIwPfb3MM5Kfh+xObPvBmmzI4KQi09HIa6jClefQ1dHWifJjI5BRQlbn8J4IjE7LGPdnM8AYmzXGBCWwpizotG7a9pJ/t9xG1kNS1mr/2TO7IQI53gFRkd0TWWk6BV60LTzcNqK2S/UD6n9Pv1hRfoFHVx7fgRS+R+wrmItiRlXJTgTB7rP8bD6a4 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jul 2016 15:53:28.9535 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1BFFO11HUB006 Archived-At: Subject: [Dime] New version of draft-bertz-dime-perflowmbr-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 15:53:34 -0000 --_000_eb509e65929540ffa3cac4ee465e7a20PLSWE13M07adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A new version of the draft has been added per feedback. It corrects the data types in the IANA section, adds IP flow (5 tuple) in t= he introduction and a new section on working with other max bit rate values= . Thank you. Lyle From: Bertz, Lyle T [CTO] Sent: Wednesday, July 06, 2016 11:31 AM To: 'dime@ietf.org' Subject: New I-D: draft-bertz-dime-perflowmbr-00 All, I have added a new I-D for consideration. It permits setting *per flow* ma= ximum bit rates. This can serve in some applications, e.g. video throttlin= g, to limit features such as resolutions as opposed to requiring deeper ins= pection. https://datatracker.ietf.org/doc/draft-bertz-dime-perflowmbr/ Thank you. Lyle ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_eb509e65929540ffa3cac4ee465e7a20PLSWE13M07adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A new version of the d= raft has been added per feedback. 

 

It corrects the data t= ypes in the IANA section, adds IP flow (5 tuple) in the introduction and a = new section on working with other max bit rate values.

 

Thank you.<= /span>

 

Lyle=

 

From: Bertz, Lyle T [CTO]
Sent: Wednesday, July 06, 2016 11:31 AM
To: 'dime@ietf.org' <dime@ietf.org>
Subject: New I-D: draft-bertz-dime-perflowmbr-00

 

All,


I have added a new I-D for consideration.  It permits setting *per = flow* maximum bit rates.  This can serve in some applications, e.g= . video throttling, to limit features such as resolutions as opposed to req= uiring deeper inspection.

 

https://datatracker.ietf.org/doc/draft-bertz-dime-per= flowmbr/

 

Thank you.

 

Lyle


Learn more on how to swi= tch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details.


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_eb509e65929540ffa3cac4ee465e7a20PLSWE13M07adsprintcom_-- From nobody Mon Jul 11 23:45:59 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B509A12B007 for ; Mon, 11 Jul 2016 23:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dz4VSrx2zpsb for ; Mon, 11 Jul 2016 23:45:55 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B7CA12B016 for ; Mon, 11 Jul 2016 23:45:55 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 9CD8726428B for ; Tue, 12 Jul 2016 08:45:53 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.62]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 7DC0B23807E for ; Tue, 12 Jul 2016 08:45:53 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%19]) with mapi id 14.03.0301.000; Tue, 12 Jul 2016 08:45:52 +0200 From: To: "dime@ietf.org" Thread-Topic: Update of RFC7423: Use of the 'E' bit in the Diameter Header Thread-Index: AdHcCJGU2tNioeXhQRq9v0m2cxk+Ag== Date: Tue, 12 Jul 2016 06:45:52 +0000 Message-ID: <11308_1468305953_57849221_11308_8803_1_6B7134B31289DC4FAF731D844122B36E01EFEEBD@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.7.12.55416 Archived-At: Subject: [Dime] Update of RFC7423: Use of the 'E' bit in the Diameter Header X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 06:45:58 -0000 Hi, As discussed at the last meeting, here is a draft of a new section to inclu= de in the RFC7423bis clarifying the use of the 'E' bit in answer commands. Please provide your comments. This text will be discussed in Berlin. Regards, Lionel ********************** 5.12. Use of the 'E' bit in the Diameter Header As described in the section 3 of [RFC6733], the Diameter command header includes an 8-bit field named "Command Flags" field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E T r r r r| Command Code = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application-ID = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Identifier = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Identifier = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- These Command Flags are used to characterize the type of Diameter message being sent/received, i.e. request or answer ('R' bit), proxyable message ('P' bit), error message ('E' bit) and retransmitted message ('T' bit). About the 'E' bit, the following definition is given: E(rror) If set, the message contains a protocol error, and the message will not conform to the CCF described for this command. Messages with the 'E' bit set are commonly referred to as error messages. This bit MUST NOT be set in request messages (see Section 7.2). Further details on the use of the 'E' bit are given in the section 7.2 of the [RFC6733]. In this section, it is explained that when a request (e.g. Diameter-EAP-Request) causes a protocol-related error i.e., DIAMETER_UNABLE_TO_DELIVER or DIAMETER_REDIRECT_INDICATION or any other error listed in section 7.1.3 of [RFC6733], the corresponding answer must not conform to the normal CCF grammar of the answer command (e.g. Diameter-EAP-Answer) but must conform to the following generic grammar: ::=3D < Diameter Header: code, ERR [, PXY] > 0*1< Session-Id > { Origin-Host } { Origin-Realm } { Result-Code } [ Origin-State-Id ] [ Error-Message ] [ Error-Reporting-Host ] [ Failed-AVP ] [ Experimental-Result ] * [ Proxy-Info ] * [ AVP ] Note that the message format given above is not totally correct. If the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION, the Redirect-Host AVP must be present. The message format should be as follow: ::=3D < Diameter Header: code, ERR [, PXY] > 0*1< Session-Id > { Origin-Host } { Origin-Realm } { Result-Code } [ Origin-State-Id ] [ Error-Message ] [ Error-Reporting-Host ] [ Failed-AVP ] [ Experimental-Result ] --> * [ Redirect-Host ] --> [ Redirect-Host-Usage ] --> [ Redirect-Max-Cache-Time ] * [ Proxy-Info ] * [ AVP ] It could be argued that the "*[AVP]" allows the presence of the Redirect-Host AVP, Redirect-Host-Usage AVP and Redirect-Max-Cache- Time AVP. However, as there is a clear condition for the presence of the redirection information in the answer in case the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION, it is better to include these AVP in the generic answer message CCF when the 'E' bit is set in the Diameter header. If it is used to report protocol errors, the 'E' bit can also be used to indicate permanent errors i.e., DIAMETER_UNABLE_TO_COMPLY or any other error listed in section 7.1.5 of RFC6733, as described in the following part of the introduction of the section 7.1.5 of [RFC6733]: "[...] In error conditions where it is not possible or efficient to compose application-specific answer grammar, answer messages with the 'E' bit set and which comply to the grammar described in Section 7.2 MAY also be used for permanent errors. Besides describing the possible use of the 'E' bit for permanent error cases, the text above further clarifies the rational for an answer in a generic command format when the 'E' bit is set. If an error is detected when processing the request at the Diameter protocol level, there is no need to generate an full answer complying to the CCF grammar of the answer command as defined in the application specification. Furthermore, when this answer is generated by a Diameter node in the Diameter signalling path acting as a Diameter Relay agent, it is not even possible to generate such an application- specific answer as a Relay agent is by definition application- agnostic. As the main purpose of the answer is to notify the error in the process of the request, the pertinent information to provide is already contained in the Result-Code (or Experimental-Result) of the answer. In addition, extra information that may also be present in the answer is useful for correcting the request or for debugging information (e.g. Failed AVP, Redirect-Host AVP, etc.). When defining the commands for a new application, it is RECOMMENDED to specifically refer to the section 7.2 of [RFC6733] for the CCF specification for the answer command when 'E' bit is set. AVPs that are= =20 supposed to be only used when the 'E' bit is set SHOULD NOT be included in the definition of new answer commands e.g. Redirect-Host AVP.=20=20 Diameter nodes supporting any application MUST expect to receive=20 answer commands that does not comply with the definition given in the application specification, as long as they are compliant with the generi= c=20 answer command's CCF when the 'E' bit is set. NOTE: The IETF RFC 6733 [RFC6733] is not totally self-consistent as AVPs related to redirection information (Redirect-Host AVP, Redirect-Host-Usage AVP and Redirect-Max-Cache-Time AVP) are included in the CCF specifications of Diameter base answer commands (Re-Auth-Answer (RAA), Session-Termination-Answer (STA) and Abort-Session-Answer (ASA)) instead of just referring to the generic CCF syntax when the 'E' bit is set. This could be misinterpreted as that "normal" answer commands can be used for providing redirection information. Using as reference the IETF RFC 6733 [RFC6733], other standard Diameter applications have included the Redirect-Host AVP, Redirect-Host-Usage AVP and Redirect-Max-Cache-Time AVP in the CCF specification of the answer commands (e.g. [RFC7155] or [RFC4006]). In the same logic, the same approach has been adopted in most of the vendor-specific Diameter applications defining new commands. Moreover, protocol implementors SHOULD ensure that some protocol errors are only handled on a per-hop basis and are not forwarded to other peers. For instance, the DIAMETER_REDIRECT_INDICATION is used to indicate to the request should be redirect to hosts that are supposed to be peers of the node receiving the answer. If the receiver of the answer is a Diameter relay/proxy agent, it may attempt to redirect the request to one of the hosts identified by a DiameterURI in the answer. If it is not able to forward the request to one of the identified hosts (e.g. no transport connection can be created with any of the identified hosts), the agent SHOULD return a DIAMETER_UNABLE_TO_DELIVER to the initiator of the request instead of forwarding DIAMETER_REDIRECT_INDICATION. The same principle SHOULD apply with DIAMETER_TOO_BUSY and DIAMETER_LOOP_DETECTED. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Jul 13 07:34:40 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6F312D838 for ; Wed, 13 Jul 2016 07:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tUqbMf_LO4x for ; Wed, 13 Jul 2016 07:34:34 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9F412D661 for ; Wed, 13 Jul 2016 07:34:34 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 856884203BF2E for ; Wed, 13 Jul 2016 14:34:29 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6DEYV6e019498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 13 Jul 2016 14:34:31 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6DEYPXB025050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 13 Jul 2016 16:34:31 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.32]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 13 Jul 2016 16:34:28 +0200 From: "Trottin, Jean-Jacques (Nokia - FR)" To: "dime@ietf.org" Thread-Topic: [Dime] WGLC #1 for draft-ietf-dime-load-02 Thread-Index: AQHRtdE4tMkqClz2NEuuQj0gjsd2sp/qPcJQgAnlegCAAXp7AIAHXWgAgAOaJgCAADIrgIABPp8ggAAIp4CAB5znIIADJcoAgAnFkrA= Date: Wed, 13 Jul 2016 14:34:27 +0000 Message-ID: References: <5b31616d-efa3-ac03-8f1c-bd8883a35d65@gmail.com> <087A34937E64E74E848732CFF8354B9219758407@ESESSMB101.ericsson.se> <3e2082d80d8e45caaca581c9dcc98468@CSRRDU1EXM025.corp.csra.com> <71796571-c370-cae8-d456-9d2dfb02544c@usdonovans.com> <087A34937E64E74E848732CFF8354B921975C3F4@ESESSMB101.ericsson.se> <71ffc339-37e0-e4fd-a16e-59da7fe23b6d@usdonovans.com> <087A34937E64E74E848732CFF8354B921975E5AB@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B921975E824@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B921975F63B@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B921975F63B@ESESSMB101.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 14:34:39 -0000 Hi MCruz, all, Thanks for your feedback.=20 I still have some understanding issues See comments to your last reflections. Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo= me Envoy=E9=A0: jeudi 7 juillet 2016 11:10 =C0=A0: Trottin, Jean-Jacques (Nokia - FR); dime@ietf.org Objet=A0: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02 Hello JJacques, all, See comments only to your last reflections. Best regards /MCruz =3D=3D=3D=3D=3D=3D from previous emails (begin) =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 5. > Now > The goal is make it possible to use both the load values received as > a part of the Diameter Load mechanism and weight values received as = a > result of a DNS SRV query. As a result, the Diameter load value has > a range of 0-65535. This value and DNS SRV weight values are then > used in a distribution algorithm similar to that specified in > [RFC2782]. > > Comments: > In order to have an efficient load balancing algorithm, it is not enough = for the reacting node (for the node in charge of load balancing) to know th= e Load of each server, but it needs to know the load in relation to each se= rver capacity. Unless we do so, the Load value of a server can't be compare= d with the Load of a Server with a different weight. > Then, in my opinion, we need to find a way to provide a Load value that i= s in fact comparable with the rest of the Load values of the servers in the= group. > Reflecting a bit longer on this, I think we need then to define a group o= f servers in the load-balancing group, like a load-balancing context, and t= hen, for all servers in such a group we need to provide a relative value of= dynamic Load. > > Agree with the thought- if "Little Server" is 30% utilized and=20 > "Big Server" is 50% utilized, it still makes sense to send more=20 > traffic to Big Server. But I am not sure if that is withn the scope=20 > of this document. > SRD> I don't understand the concern. The load values supplied will be > input into the route selection algorithm as specified in RFC2782. If=20 > a node isn't getting enough traffic it will change its load value to a=20 > lower value and will start getting more traffic. > MCRUZ> Unless the LOAD info provided is in fact a value that represents t= he available capacity, then the load balancing will not select the less loa= ded server. Being able to select the less loaded server is the whole purpos= e of this mechanism, then we need to find a way to provide a LOAD value fro= m different servers that we are able to compare, i.e. the value provide mus= t indicate the available capacity regardless the static capacity of each se= rver. SRD> I view the goal of this a little differently. The goal is to make sure that requests are delivered to nodes with available capacity. It is n= ot strictly necessary that every request goes to the least loaded node. MCRUZ> Well, I do not agree. The whole purpose of providing LOAD info is to= be able to choose a node with available load (I agree), but among the nod= e with available load we need to choose the least loaded (or one of the lea= st loaded). It does not make sense, in my opinion, to simply select a node = with available load, when we are providing info about load. The information= provided should be valid to be able to select the least (or close to) load= ed. > Providing an example, let me use dynamic Load (say DL) in % (100% is tota= lly loaded) that I found it easier for calculation: > - Server1: weight=3D1500; DL=3D 2% > - Server2: weight=3D55000; DL=3D 70% > Then, if we only use DL in the LB algorithm, obviously Server 1 seems to = be clearly less loaded, but however, taking into account its weight is much= smaller it may be the other way around. In fact, if traffic is redirected = to this server, it may get overloaded rapidly (due to its small capacity). > One possible way to calculate the relative DL is to divide it by the wei= ght, then for this example: > - Server1 RDL=3D 10000 * (2/1500) =3D 13.33 > - Server2 RDL=3D 10000 * (70/55000) =3D 12.73 (I multiplied by 10000=20 > simply to get rid of the decimals for our discussion). > Then, we actually find out that available load for both servers is pretty= similar. In fact, in this case, a correct load balancing should select Ser= ver2 as the less loaded server instead of server1. > My proposal is to consider this reflection in the draft, and then make a = clear distinction between dynamic load (DL) and RELATIVE DL. We need to pro= vide the RDL in the message, not DL. SRD> This is about how the load value is calculated which is explicitly stated as being an implementation decision. MCRUZ> Not exactly. We need to reflect in the draft that the LOAD provided = should be the relative available load, taking into account the static weigh= t. This is the only way we are providing a load value that can possibly be = used by a client to LOAD-balance.=20 I could accept that we leave the way to do so up to implementations. Proposal: "LOAD should be calculated in a way that reflects the available l= oad independently of the weight of each server, in order to allow the Diame= ter node that performs server selection to accurateraly compare values from= different servers, i.e. LOAD value identifies the same amount of available= capacity, regardless the server that has calculate it. " JJ2> I analysed a bit more your example with Server1 RDL=3D 10000 * JJ2> (2/1500) =3D 13.33 and Server2 RDL=3D 10000 * (70/55000) =3D 12.73 wit= h=20 JJ2> the conclusion to select server2. This is a bit surprising as=20 JJ2> server 1 is only 2% loaded. This example is rather specific with a=20 JJ2> server 1 weight being 2,7% of server 2 weight. I did another=20 JJ2> example with less difference in the weights - Server1: weight=3D30000; DL=3D 30% - Server2: weight=3D60000; DL=3D 50% This drives to Server1 RDL=3D 10000 * (30/30000) =3D 10,0 Server2 RDL=3D 10000 * (50/60000) =3D 8,3 =20 Here also, if I follow your reasoning, this would drive to select server 2 = to increase its RDL. Again the result is to increase server2 load Even by taking a 80% load for server 2 (so a high load in practice) and 50%= for server 1 Server1 RDL=3D 10000 * (50/30000) =3D 16,7 Server2 RDL=3D 10000 * (80/60000) =3D 13,3 This still drives to select server 2, although the reasoning would be to in= crease server 1 load Nevertheless, if server 1 has only 30% load its RDL b= ecomes 10 and it will be selected, so here OK =20 Please check if I am wrong somewhere, but currently RDL, for me, can give = strange outputs. About static weight I agree that static weight can be useful, e.g. a last h= op DA can be configured with the server weight to distribute its traffic a= mong the servers it is connected to. =20 My point is about the targeted load balance between the servers. Often, the= objective is to have the same load among servers (even if they have some d= ifference in their capacity / weight), which is the way to maximize the tra= ffic without entering overload in any server. So the "DL" (as defined in th= e current draft) indicates whether they have the same load, and if the obje= ctive is achieved. For me I do not well see how you define the targeted loa= d among servers with the RDL you mentioned. If received load from servers is not the same, the sending node has to sen= d a bit more traffic to the less loaded node. For this, as you said, an obj= ective is to avoid oscillations, and sending node has to evaluate the amoun= t of traffic it will switch from the more loaded server to the less loaded = server, this switched traffic being not too high to avoid oscillations and = also not too low to avoid maintaining unbalanced situation. In the draft, i= t is left to implementation on the sending node on how to modify the curren= t traffic distribution among the servers according to the received load (DL= ), and I am OK on this. In my previous mail I indicated that the sending n= ode will adjust its traffic distribution according to the updated load (DL)= received from server and converge to the balanced situation, in this proce= ss, I agree that the weight attached to each server can be an additional us= eful input when available, but keeping the current load (DL) definition =3D=3D=3D=3D=3D=3D from previous emails (end) =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D About the examples you discussed above.=20 I think the results you got are valid. Take into account that the static we= ight identifies the server capability, then a server1 with weight:60000 has= double resources than a server2 with 30000. Then, server2 45% load is maki= ng usage of double of resources than server1 90% load. DL/Weight provides a value than indicates the load per "resource unit". The= n, the least loaded server is the one that has less load per "resource unit= ". This can be seen in the following example: Server1 RDL=3D 10000 * (45/30000) =3D 15 Server2 RDL=3D 10000 * (90/60000) =3D 15 Both servers are equally loaded, as long as the Big Server (Server2) is loa= ded double as the Small Server (Server1), that is half size in resources th= an Big Server. Then, JJacques, I think we agree the Diameter node that is responsible for = server selection should have the means to select the least loaded server, a= nd the available load depends on the capacity of each node, not only on the= DL that is identified at a moment in time. Then, I think we need to include some normative text on that, although the = specific means to achieve so could remain implementation specific. Proposed= text is: "LOAD should be calculated in a way that reflects the available load indepe= ndently of the weight of each server, in order to allow the Diameter node t= hat performs server selection to accurately compare values from different s= ervers, i.e. LOAD value identifies the same amount of available capacity, r= egardless the server that has calculate it. The means to calculate the LOA= D value that fulfils this requirement are implementation specific." I think, as Steve agreed, that the example could be included in the draft a= s well, it is very useful to understand how the static weight determines th= e available load. I analysed your above new example which raises same questioning from = my side: By applying the factor 10000 for simplification we have=20 Server1 weight 6 so I can say that Server1 has a capacity of 6 resource u= nits =20 Server2 weight 3 so a capacity of 3 resource units. Server1 load (DL)=3D 90% so Server 1 consumed resource units=3D 6x90% =3D 5= ,4 Server2 load (DL)=3D 45% so Server 2 consumed resource units=3D 3x45% =3D 1= ,65 Then=20 Server1 remaining (available) resources=3D 6-5,4 =3D 0,6 =20 Server2 remaining (available) resources=3D 3-1,35 =3D 1,65=20 So in my understanding server2 (the smaller server) has still more availabl= e capacity than server 1, so I would conclude to transfer some traffic from= server 1 to server 2; But you said that both servers are equally loadedas= having the same RDL=3D15, and concluded the system being well balanced, wh= ich I do not agree You also mention that we should have the "same load per resource unit", whi= ch also raises questioning from me: If Server1 has a load of 90% for its 6 resource units, this also means that= each resource unit has a load of 90%.=20 I have difficulty to understand the definition of RDL =3D DL/Weight So I think we are not yet well aligned on a common understanding of the exa= mple, so thanks if you can give still some more explanation. I continued the same exercise but with my assumptions a) objective (according to my previous mail) is that the two servers have t= he same load, this drives to DL=3D75% with=20 Server1 load (DL)=3D 75% so Server 1 consumed resource units=3D 75% =3D 4,5 Server2 load (DL)=3D 75% so Server 2 consumed resource units=3D 3x75% =3D 2= ,25 Then=20 Server1 remaining resources=3D 6-4,5 =3D 1,75 =20 Server2 remaining resources=3D 3-2,25 =3D 0,75 but the % of remaining resou= rces compare to its capacity is the same for each server b) another possible objective is that the two servers have the same remaini= ng (available) resource, , this drives to=20 Server1 load (DL)=3D 81,3% so Server 1 consumed resource units=3D 6x81,3% = =3D 4,88 Server2 load (DL)=3D 62,4% so Server 2 consumed resource units=3D 3x62,4% = =3D 1,87=09 Then=20 Server1 remaining resources=3D 6-4,88 =3D 1,12 =20 Server2 remaining resources=3D 3-1,87 =3D 1,13 so same remaining resources Is this b) case relating more to your concern? The "least loaded" node woul= d be the one having the highest remaining capacity, so with traffic transfe= r to this node until both nodes have the same remaining capacity Other type of load balancing objectives may be considered, but load balanci= ng objectives are for me operator dependent and implementation specific. Then to come back to weights: - case a), as I said, according to received load from servers senders, a se= nder can adjust the traffic to converge to the same/nearly same load among = servers. The fact to know server weights would improve the convergence to t= his objective=20 - Case b) needs to have knowledge on the server weights as this is needed t= o evaluate the remaining resources objectives As indicated, server weights can be configured (eg for DAs in front of serv= ers) or obtained from a DNS query (as Steve mentioned), or through other me= ans that are out of the scope. I would like we share the same understanding before finalizing a normative = text Best regards JJacques =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Thu Jul 14 01:44:59 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2226812DB35 for ; Thu, 14 Jul 2016 01:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdrhSZMSw6XS for ; Thu, 14 Jul 2016 01:44:55 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB4E12DB0A for ; Thu, 14 Jul 2016 01:44:54 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-66-578751058e11 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C7.A3.18043.50157875; Thu, 14 Jul 2016 10:44:53 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.74]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0294.000; Thu, 14 Jul 2016 10:44:52 +0200 From: Maria Cruz Bartolome To: "Trottin, Jean-Jacques (Nokia - FR)" , "dime@ietf.org" Thread-Topic: [Dime] WGLC #1 for draft-ietf-dime-load-02 Thread-Index: AQHRtdE4jPBCVA2NJ0e3rvn8VsJS8Z/qPcJQgAnlegCAAXp7AIAHc18QgAOELwCAAE15MIABDQ4AgAA9q5CAB4YkgIADOjGQgAmsW4CAAU9Q4A== Date: Thu, 14 Jul 2016 08:44:52 +0000 Message-ID: <087A34937E64E74E848732CFF8354B9219761871@ESESSMB101.ericsson.se> References: <5b31616d-efa3-ac03-8f1c-bd8883a35d65@gmail.com> <087A34937E64E74E848732CFF8354B9219758407@ESESSMB101.ericsson.se> <3e2082d80d8e45caaca581c9dcc98468@CSRRDU1EXM025.corp.csra.com> <71796571-c370-cae8-d456-9d2dfb02544c@usdonovans.com> <087A34937E64E74E848732CFF8354B921975C3F4@ESESSMB101.ericsson.se> <71ffc339-37e0-e4fd-a16e-59da7fe23b6d@usdonovans.com> <087A34937E64E74E848732CFF8354B921975E5AB@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B921975E824@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B921975F63B@ESESSMB101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7hy5rYHu4wd5ZfBZze1ewWXQcmM3i wOSxZMlPJo+7ty4xBTBFcdmkpOZklqUW6dslcGX07L7AVnCzkbFi0fd1rA2M0zO6GDk4JARM JCbdqehi5AQyxSQu3FvPBmILCRxhlNj3AijOBWQvZpQ4+qufFSTBJmAncen0CyYQW0QgR+L9 1TUsILawgLlE6+HLUHELic+nDzFD2HUS35YdBrNZBFQlfj+fCLaAV8BX4tKr60wQC3axSSx8 1wWW4BSIlTj86THYMkagi76fWgM2lFlAXOLWk/lMEJcKSCzZc54ZwhaVePn4HyuErSTRuOQJ K0S9nsSNqVPYIGxtiWULXzNDLBaUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWF+em GxnppRZlJhcX5+fp5aWWbGIERsrBLb+tdjAefO54iFGAg1GJh3dBY1u4EGtiWXFl7iFGCQ5m JRHeCv/2cCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtSi2CyTBycUg2M xTq9c+fcN3u38M78znit5wK+8t82TCzcY9fkcvHi1eKNnPmaM66YrWHxXDbjQPUN0wcXe+qT WSz37F/vyK08V2WjKgdP1JWsnumvFnzNO+MSu+RxyAmVBxPTBObn6bz4bnfCKD2NY25o0qqT iwxm8UjFeGocFWXVua6+VSKK48K6rlOt67NVlFiKMxINtZiLihMBa0JilZACAAA= Archived-At: Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 08:44:58 -0000 Hello JJacques, Thanks for your analysis.=20 I checked this through and I agree the proposal I made of a possible RDL ca= lculation may not be providing the selection of the least loaded server in = all cases, the examples you made are very good to understand that. However, the concern behind keeps being perfectly valid, I think we need to= provide not the DL as such, but a value that takes into account the differ= ent servers' weights, in order to be able to compare the amount of free res= ources, that is, the capability of different servers to deal with traffic. In case we have servers with different weights (what is the most common sce= nario), both may be 50% loaded (DL), and this value is not useful for the = client to be able to perform load balancing. If a server has 4 times more r= esources than the other, obviously that server has more free resources and = it will be able to deal with more traffic. Therefore, my concern is that D= L does not provide enough information for the client to be able to perform = load balancing, that is the ultimate expectation of this mechanism. We need= a "relative" DL, taking into account servers' weights. Then, I would say that my proposal below keeps being valid. We need to reflect in the draft that the LOAD provided should be the relati= ve available load, taking into account the static weight. This is the only = way we are providing a load value that can possibly be used by a client to = LOAD-balance.=20 I agree that we leave the way to do so up to implementations. Proposal: "LOAD should be calculated in a way that reflects the available l= oad independently of the weight of each server, in order to allow the Diame= ter node that performs server selection to accurately compare values from d= ifferent servers, i.e. LOAD value identifies the same amount of available c= apacity, regardless the server that has calculate it. " Let me know if you could agree with these conclusions, or if you have a dif= ferent view. Thanks /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Trottin, Jean-Jacque= s (Nokia - FR) Sent: mi=E9rcoles, 13 de julio de 2016 16:34 To: dime@ietf.org Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02 Hi MCruz, all, Thanks for your feedback.=20 I still have some understanding issues See comments to your last reflections. Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo= me Envoy=E9=A0: jeudi 7 juillet 2016 11:10 =C0=A0: Trottin, Jean-Jacques (N= okia - FR); dime@ietf.org Objet=A0: Re: [Dime] WGLC #1 for draft-ietf-dime-= load-02 Hello JJacques, all, See comments only to your last reflections. Best regards /MCruz =3D=3D=3D=3D=3D=3D from previous emails (begin) =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 5. > Now > The goal is make it possible to use both the load values received as > a part of the Diameter Load mechanism and weight values received as = a > result of a DNS SRV query. As a result, the Diameter load value has > a range of 0-65535. This value and DNS SRV weight values are then > used in a distribution algorithm similar to that specified in > [RFC2782]. > > Comments: > In order to have an efficient load balancing algorithm, it is not enough = for the reacting node (for the node in charge of load balancing) to know th= e Load of each server, but it needs to know the load in relation to each se= rver capacity. Unless we do so, the Load value of a server can't be compare= d with the Load of a Server with a different weight. > Then, in my opinion, we need to find a way to provide a Load value that i= s in fact comparable with the rest of the Load values of the servers in the= group. > Reflecting a bit longer on this, I think we need then to define a group o= f servers in the load-balancing group, like a load-balancing context, and t= hen, for all servers in such a group we need to provide a relative value of= dynamic Load. > > Agree with the thought- if "Little Server" is 30% utilized and=20 > "Big Server" is 50% utilized, it still makes sense to send more=20 > traffic to Big Server. But I am not sure if that is withn the scope=20 > of this document. > SRD> I don't understand the concern. The load values supplied will be > input into the route selection algorithm as specified in RFC2782. If=20 > a node isn't getting enough traffic it will change its load value to a=20 > lower value and will start getting more traffic. > MCRUZ> Unless the LOAD info provided is in fact a value that represents t= he available capacity, then the load balancing will not select the less loa= ded server. Being able to select the less loaded server is the whole purpos= e of this mechanism, then we need to find a way to provide a LOAD value fro= m different servers that we are able to compare, i.e. the value provide mus= t indicate the available capacity regardless the static capacity of each se= rver. SRD> I view the goal of this a little differently. The goal is to make sure that requests are delivered to nodes with available capacity. It is n= ot strictly necessary that every request goes to the least loaded node. MCRUZ> Well, I do not agree. The whole purpose of providing LOAD info is to= be able to choose a node with available load (I agree), but among the nod= e with available load we need to choose the least loaded (or one of the lea= st loaded). It does not make sense, in my opinion, to simply select a node = with available load, when we are providing info about load. The information= provided should be valid to be able to select the least (or close to) load= ed. > Providing an example, let me use dynamic Load (say DL) in % (100% is tota= lly loaded) that I found it easier for calculation: > - Server1: weight=3D1500; DL=3D 2% > - Server2: weight=3D55000; DL=3D 70% > Then, if we only use DL in the LB algorithm, obviously Server 1 seems to = be clearly less loaded, but however, taking into account its weight is much= smaller it may be the other way around. In fact, if traffic is redirected = to this server, it may get overloaded rapidly (due to its small capacity). > One possible way to calculate the relative DL is to divide it by the wei= ght, then for this example: > - Server1 RDL=3D 10000 * (2/1500) =3D 13.33 > - Server2 RDL=3D 10000 * (70/55000) =3D 12.73 (I multiplied by 10000=20 > simply to get rid of the decimals for our discussion). > Then, we actually find out that available load for both servers is pretty= similar. In fact, in this case, a correct load balancing should select Ser= ver2 as the less loaded server instead of server1. > My proposal is to consider this reflection in the draft, and then make a = clear distinction between dynamic load (DL) and RELATIVE DL. We need to pro= vide the RDL in the message, not DL. SRD> This is about how the load value is calculated which is explicitly stated as being an implementation decision. MCRUZ> Not exactly. We need to reflect in the draft that the LOAD provided = should be the relative available load, taking into account the static weigh= t. This is the only way we are providing a load value that can possibly be = used by a client to LOAD-balance.=20 I could accept that we leave the way to do so up to implementations. Proposal: "LOAD should be calculated in a way that reflects the available l= oad independently of the weight of each server, in order to allow the Diame= ter node that performs server selection to accurateraly compare values from= different servers, i.e. LOAD value identifies the same amount of available= capacity, regardless the server that has calculate it. " JJ2> I analysed a bit more your example with Server1 RDL=3D 10000 * JJ2> (2/1500) =3D 13.33 and Server2 RDL=3D 10000 * (70/55000) =3D 12.73 wit= h=20 JJ2> the conclusion to select server2. This is a bit surprising as=20 JJ2> server 1 is only 2% loaded. This example is rather specific with a=20 JJ2> server 1 weight being 2,7% of server 2 weight. I did another=20 JJ2> example with less difference in the weights - Server1: weight=3D30000; DL=3D 30% - Server2: weight=3D60000; DL=3D 50% This drives to Server1 RDL=3D 10000 * (30/30000) =3D 10,0 Server2 RDL=3D 10000 * (50/60000) =3D 8,3 =20 Here also, if I follow your reasoning, this would drive to select server 2 = to increase its RDL. Again the result is to increase server2 load Even by taking a 80% load for server 2 (so a high load in practice) and 50%= for server 1 Server1 RDL=3D 10000 * (50/30000) =3D 16,7 Server2 RDL=3D 10000 * (80/60000) =3D 13,3 This still drives to select server 2, although the reasoning would be to in= crease server 1 load Nevertheless, if server 1 has only 30% load its RDL b= ecomes 10 and it will be selected, so here OK =20 Please check if I am wrong somewhere, but currently RDL, for me, can give = strange outputs. About static weight I agree that static weight can be useful, e.g. a last h= op DA can be configured with the server weight to distribute its traffic a= mong the servers it is connected to. =20 My point is about the targeted load balance between the servers. Often, the= objective is to have the same load among servers (even if they have some d= ifference in their capacity / weight), which is the way to maximize the tra= ffic without entering overload in any server. So the "DL" (as defined in th= e current draft) indicates whether they have the same load, and if the obje= ctive is achieved. For me I do not well see how you define the targeted loa= d among servers with the RDL you mentioned. If received load from servers is not the same, the sending node has to sen= d a bit more traffic to the less loaded node. For this, as you said, an obj= ective is to avoid oscillations, and sending node has to evaluate the amoun= t of traffic it will switch from the more loaded server to the less loaded = server, this switched traffic being not too high to avoid oscillations and = also not too low to avoid maintaining unbalanced situation. In the draft, i= t is left to implementation on the sending node on how to modify the curren= t traffic distribution among the servers according to the received load (DL= ), and I am OK on this. In my previous mail I indicated that the sending n= ode will adjust its traffic distribution according to the updated load (DL)= received from server and converge to the balanced situation, in this proce= ss, I agree that the weight attached to each server can be an additional us= eful input when available, but keeping the current load (DL) definition =3D=3D=3D=3D=3D=3D from previous emails (end) =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D About the examples you discussed above.=20 I think the results you got are valid. Take into account that the static we= ight identifies the server capability, then a server1 with weight:60000 has= double resources than a server2 with 30000. Then, server2 45% load is maki= ng usage of double of resources than server1 90% load. DL/Weight provides a value than indicates the load per "resource unit". The= n, the least loaded server is the one that has less load per "resource unit= ". This can be seen in the following example: Server1 RDL=3D 10000 * (45/30000) =3D 15 Server2 RDL=3D 10000 * (90/60000) =3D 15 Both servers are equally loaded, as long as the Big Server (Server2) is loa= ded double as the Small Server (Server1), that is half size in resources th= an Big Server. Then, JJacques, I think we agree the Diameter node that is responsible for = server selection should have the means to select the least loaded server, a= nd the available load depends on the capacity of each node, not only on the= DL that is identified at a moment in time. Then, I think we need to include some normative text on that, although the = specific means to achieve so could remain implementation specific. Proposed= text is: "LOAD should be calculated in a way that reflects the available load indepe= ndently of the weight of each server, in order to allow the Diameter node t= hat performs server selection to accurately compare values from different s= ervers, i.e. LOAD value identifies the same amount of available capacity, r= egardless the server that has calculate it. The means to calculate the LOA= D value that fulfils this requirement are implementation specific." I think, as Steve agreed, that the example could be included in the draft a= s well, it is very useful to understand how the static weight determines th= e available load. I analysed your above new example which raises same questioning from = my side: By applying the factor 10000 for simplification we have=20 Server1 weight 6 so I can say that Server1 has a capacity of 6 resource u= nits =20 Server2 weight 3 so a capacity of 3 resource units. Server1 load (DL)=3D 90% so Server 1 consumed resource units=3D 6x90% =3D 5= ,4 Server2 load (DL)=3D 45% so Server 2 consumed resource units=3D 3x45% =3D 1= ,65 Then Server1 remaining (available) resources=3D 6-5,4 =3D 0,6 Server2 remaining (available) resources=3D 3-1,35 =3D 1,65=20 So in my understanding server2 (the smaller server) has still more availabl= e capacity than server 1, so I would conclude to transfer some traffic from= server 1 to server 2; But you said that both servers are equally loadedas= having the same RDL=3D15, and concluded the system being well balanced, wh= ich I do not agree You also mention that we should have the "same load per resource unit", whi= ch also raises questioning from me: If Server1 has a load of 90% for its 6 resource units, this also means that= each resource unit has a load of 90%.=20 I have difficulty to understand the definition of RDL =3D DL/Weight So I th= ink we are not yet well aligned on a common understanding of the example, s= o thanks if you can give still some more explanation. I continued the same exercise but with my assumptions a) objective (according to my previous mail) is that the two servers have t= he same load, this drives to DL=3D75% with Server1 load (DL)=3D 75% so Server 1 consumed resource units=3D 75% =3D 4,5 Server2 load (DL)=3D 75% so Server 2 consumed resource units=3D 3x75% =3D 2= ,25 Then Server1 remaining resources=3D 6-4,5 =3D 1,75 Server2 remaining resources=3D 3-2,25 =3D 0,75 but the % of remaining resou= rces compare to its capacity is the same for each server b) another possible objective is that the two servers have the same remaini= ng (available) resource, , this drives to Server1 load (DL)=3D 81,3% so Server 1 consumed resource units=3D 6x81,3% = =3D 4,88 Server2 load (DL)=3D 62,4% so Server 2 consumed resource units=3D 3x62,4% = =3D 1,87=09 Then Server1 remaining resources=3D 6-4,88 =3D 1,12 Server2 remaining resources=3D 3-1,87 =3D 1,13 so same remaining resources Is this b) case relating more to your concern? The "least loaded" node woul= d be the one having the highest remaining capacity, so with traffic transfe= r to this node until both nodes have the same remaining capacity Other type of load balancing objectives may be considered, but load balanci= ng objectives are for me operator dependent and implementation specific. Then to come back to weights: - case a), as I said, according to received load from servers senders, a se= nder can adjust the traffic to converge to the same/nearly same load among = servers. The fact to know server weights would improve the convergence to t= his objective - Case b) needs to have knowledge on the server weights as this is needed t= o evaluate the remaining resources objectives As indicated, server weights can be configured (eg for DAs in front of serv= ers) or obtained from a DNS query (as Steve mentioned), or through other me= ans that are out of the scope. I would like we share the same understanding before finalizing a normative = text Best regards JJacques =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Sat Jul 16 12:48:23 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBE312D15A for ; Sat, 16 Jul 2016 12:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6uwFWQSd8kR for ; Sat, 16 Jul 2016 12:48:21 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E3512D142 for ; Sat, 16 Jul 2016 12:48:20 -0700 (PDT) Received: from mutabilis-2.local ([173.57.161.14]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6GJmFnw031637 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 16 Jul 2016 14:48:16 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.57.161.14] claimed to be mutabilis-2.local To: Maria Cruz Bartolome , Steve Donovan , "dime@ietf.org" References: <5b31616d-efa3-ac03-8f1c-bd8883a35d65@gmail.com> <087A34937E64E74E848732CFF8354B9219758407@ESESSMB101.ericsson.se> <3e2082d80d8e45caaca581c9dcc98468@CSRRDU1EXM025.corp.csra.com> <71796571-c370-cae8-d456-9d2dfb02544c@usdonovans.com> <087A34937E64E74E848732CFF8354B921975C3F4@ESESSMB101.ericsson.se> <71ffc339-37e0-e4fd-a16e-59da7fe23b6d@usdonovans.com> <087A34937E64E74E848732CFF8354B921975E5AB@ESESSMB101.ericsson.se> From: "A. Jean Mahoney" Message-ID: <192cffa8-1760-67f4-cc53-3ed16848ebd2@nostrum.com> Date: Sat, 16 Jul 2016 14:48:14 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <087A34937E64E74E848732CFF8354B921975E5AB@ESESSMB101.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2016 19:48:22 -0000 Hi all, Some observations below: Agree with the thought- if "Little Server" is 30% utilized >> and "Big Server" is 50% utilized, it still makes sense to send more >> traffic to Big Server. But I am not sure if that is withn the >> scope of this document. SRD> I don't understand the concern. >> The load values supplied will be input into the route selection >> algorithm as specified in RFC2782. If a node isn't getting enough >> traffic it will change its load value to a lower value and will >> start getting more traffic. MCRUZ> Unless the LOAD info provided is >> in fact a value that represents the available capacity, then the >> load balancing will not select the less loaded server. Being able >> to select the less loaded server is the whole purpose of this >> mechanism, then we need to find a way to provide a LOAD value from >> different servers that we are able to compare, i.e. the value >> provide must indicate the available capacity regardless the static >> capacity of each server. SRD> I view the goal of this a little differently. The goal is to > make sure that requests are delivered to nodes with available > capacity. It is not strictly necessary that every request goes to > the least loaded node. MCRUZ> Well, I do not agree. The whole purpose > of providing LOAD info is to be able to choose a node with available > load (I agree), but among the node with available load we need to > choose the least loaded (or one of the least loaded). It does not > make sense, in my opinion, to simply select a node with available > load, when we are providing info about load. The information provided > should be valid to be able to select the least (or close to) loaded. [ajm] (With my implementer's hat on) Having clients chase the least-loaded server can go wrong, especially when lighting up a network, and a server's load goes from 0 to fully loaded really quickly. Depending on the design and timing, all the clients think the first server is the least loaded and they *all* pick it. Boom - the server is now maxed out. Clients should *distribute* their load across servers. Now, distribution cannot be completely even, but that's OK. Because we're talking about load here. Not *overload*. If you've designed your system correctly, a fully loaded server is *not* in danger of overload. For instance - you've designed your system with 3 servers in a cluster that can handle one of their cluster mates going down. When "fully" loaded, each server in the cluster should never be so loaded such that they cannot handle one of their mates going down and taking on half of that mate's traffic. *Overload* should be a rare event - like a tornado wiping out a chunk of your mobile network, and everybody calling and texting everybody else to make sure that they're ok. Thanks! Jean (who has actually had a customer point to the aftermath of a tornado and tell her, "Your solution has to handle THAT.") From nobody Sat Jul 16 12:52:13 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8274712D15E for ; Sat, 16 Jul 2016 12:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61dhQoE9Pwq4 for ; Sat, 16 Jul 2016 12:52:10 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F181412D142 for ; Sat, 16 Jul 2016 12:52:09 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.294.0; Sat, 16 Jul 2016 15:52:08 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0294.000; Sat, 16 Jul 2016 15:52:08 -0400 From: Yuval Lifshitz To: "dime@ietf.org" Thread-Topic: slide for RFC4006bis discussion Thread-Index: AdHfmdgffm5vJqrITTiB8hPBrUVu1A== Date: Sat, 16 Jul 2016 19:52:07 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/mixed; boundary="_002_C43C255C7106314F8D13D03FA20CFE4930CA31D9wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: [Dime] slide for RFC4006bis discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2016 19:52:11 -0000 --_002_C43C255C7106314F8D13D03FA20CFE4930CA31D9wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear group, Attached slides for the RFC4006bis discussion. Please let me know if you wa= nt more topics to be added. Regards, Yuval --_002_C43C255C7106314F8D13D03FA20CFE4930CA31D9wtlexchp2sandvi_ Content-Type: application/pdf; name="RFC4006bis.pdf" Content-Description: RFC4006bis.pdf Content-Disposition: attachment; filename="RFC4006bis.pdf"; size=65210; creation-date="Sat, 16 Jul 2016 19:51:43 GMT"; modification-date="Sat, 16 Jul 2016 19:51:44 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjQKJSDi48/TCjQKMApvYmoKPDwKL1R5cGUKL0NhdGFsb2cKL05hbWVzCjw8Ci9KYXZh U2NyaXB0CjMKMApSCj4+Ci9QYWdlTGFiZWxzCjw8Ci9OdW1zClsKMAo8PAovUwovRAovU3QKMQo+ PgpdCj4+Ci9PdXRsaW5lcwoyCjAKUgovUGFnZXMKMQowClIKPj4KZW5kb2JqCjUKMApvYmoKPDwK L0NyZWF0b3IKKP7/AEcAbwBvAGcAbABlKQo+PgplbmRvYmoKNgowCm9iago8PAovVHlwZQovUGFn ZQovUGFyZW50CjEKMApSCi9NZWRpYUJveApbCjAKMAo3MjAKNDA1Cl0KL0NvbnRlbnRzCjcKMApS Ci9SZXNvdXJjZXMKOAowClIKL0Fubm90cwoxMAowClIKL0dyb3VwCjw8Ci9TCi9UcmFuc3BhcmVu Y3kKL0NTCi9EZXZpY2VSR0IKPj4KPj4KZW5kb2JqCjcKMApvYmoKPDwKL0ZpbHRlcgovRmxhdGVE ZWNvZGUKL0xlbmd0aAo5CjAKUgo+PgpzdHJlYW0KeJy1Vl1PFDEUbcJbX4RoYkj0yRgg0dLvj4QX DbCia4BlZDUuD0YChAzoool/39Mu43R2Vz6W2W122t5M77lzzr1th1QwTmN7PRpobtB/v6BDyhnn IlhvuE5vjM/xUuwuqLLGWZ6Wl/VEcuN0HJR0bBKfZ7RPLwEypOtvyp9n3zg9/ZViqf5XpzN5P6Mn dB9tmPkW0ffoK+FVSG09U0pTGZxXLGEYJYNkma3MbEII710y1oszY4UZUZWvCK1Hic1qEnslmZNG ekOdZ8Jxe014FeLbAn1xRde3f1z+ltRqrClOmlJZxYTSwYMSFpSFj2KkR3FMV0mHfCKbZIf0ySLZ Iu8w65MjjDukS/YwX4Rlh2yTp+Qx2jLe6ZLDNVqc063ifnF4JZgWVtqpgczkUmvHpDMWHKuRy4f7 VBpSGuUUFYEnp65B2CsyWCWODNbIM7I8E4IxkongzHSAyuUteXJ74vLICsogz9vMVmY2bbgNWdo2 TLMlrdYilggz2gRVbRNIw7gxyP8MJ/lTDiWEn5wgMST5mVchhOmi3x9NTlMrAjmUr25kwWA1VUif 9FAfh+R566hYYpX0k9Dz+D7B7fgHrpPBgOxiA1hAsi/h+fLf5vCILGR5z0yQwtiAkTXAvjOwMPHT kCM3wi8l+Br8Bdg+wLhL9jFfws7UI3tVOII547yQhv6Bo/f4nyPhmXbKCUU/0q9HnB5PD7rXaQTk mfFxdEG15ExoDkJra0kPWuM/9z9Ow1y0Vmac7BWcAF/AaAcyr4DPXXDcA79tCR33G8eVmIbdQasR o7qb6Dspnv2kf5sKZ5G4pKVNCos45iqztqtw7X/8++eicDx1mixvkM9gdBM8L6C0ujjRD8mHtH+l cm5JZ8eZ5jJeeSYjSOXcBJ632Fk4tik2jLm1dbGv/Y+T0MLRrpT3AfdKKrzFvZBZly6+3GvbMJa1 UXIpnbw2Vstz470PePhgOoBujQGu2cbNfMDj3pYOeDVJpMAlSXmILw3TVuDq2EioJw8onRtQwR63 ajrmnfWL7S+NV3HCCmVuZHN0cmVhbQplbmRvYmoKOQowCm9iago3ODAKZW5kb2JqCjEwCjAKb2Jq ClsKPDwKL1R5cGUKL0Fubm90Ci9TdWJ0eXBlCi9MaW5rCi9SZWN0ClsKMTQyLjMyNTUzCjk4LjQ5 NjA5CjMzOS42NDg3NwoxMTguNjA1NDcKXQovQm9yZGVyClsKMAowCjAKXQovQQo8PAovVHlwZQov QWN0aW9uCi9TCi9VUkkKL1VSSQoobWFpbHRvOkx5bGUuVC5CZXJ0ekBzcHJpbnQuY29tKQo+Pgo+ Pgo8PAovVHlwZQovQW5ub3QKL1N1YnR5cGUKL0xpbmsKL1JlY3QKWwoxNDguMzQ2MDQKNzYuNzQ2 MQozNDAuNzI5ODMKOTYuODU1NDgKXQovQm9yZGVyClsKMAowCjAKXQovQQo8PAovVHlwZQovQWN0 aW9uCi9TCi9VUkkKL1VSSQoobWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tKQo+Pgo+Pgo8PAov VHlwZQovQW5ub3QKL1N1YnR5cGUKL0xpbmsKL1JlY3QKWwoxNTIuMzQ1MDYKNTQuOTk2MQozNDAu Njg1ODgKNzUuMTA1NDgKXQovQm9yZGVyClsKMAowCjAKXQovQQo8PAovVHlwZQovQWN0aW9uCi9T Ci9VUkkKL1VSSQoobWFpbHRvOnlsaWZzaGl0ekBzYW5kdmluZS5jb20pCj4+Cj4+Cl0KZW5kb2Jq CjE0CjAKb2JqCjw8Ci9UeXBlCi9QYWdlCi9QYXJlbnQKMQowClIKL01lZGlhQm94ClsKMAowCjcy MAo0MDUKXQovQ29udGVudHMKMTUKMApSCi9SZXNvdXJjZXMKMTYKMApSCi9Bbm5vdHMKMTgKMApS Ci9Hcm91cAo8PAovUwovVHJhbnNwYXJlbmN5Ci9DUwovRGV2aWNlUkdCCj4+Cj4+CmVuZG9iagox NQowCm9iago8PAovRmlsdGVyCi9GbGF0ZURlY29kZQovTGVuZ3RoCjE3CjAKUgo+PgpzdHJlYW0K eJy1Vt9PE0EQnqRv+4QBRJ58ISoEl/3941EDLRgSBAvVWB+MBggpaNH/P3675ej1rirWu17udmbu br6Zb+amO2aSC5aOlxPBCIv1yzUbM8GFkNEFK0x+oqrjobRcM+2sdyK/PpoqSlhvkjBiFSVdL9mA 3QBkzHZejb5ffhbs4keOpThvLxbyfsnO2TGOccm3TL4nWcKrVMaFBOKDSEBAsFpFVTKNpiYjvIjZ VLw3tRRYCU2HgsiplFkslLRqxb0yRjLjIADN3TFdxPa6j7V/y3a6325+KqY91+mnWP98tlApAGN4 0DFGx/qTSvS/shfk6YTe0SF16WyT9a/YXn8B91IGHo0Waj5I4fgvyT+kCsaJGGerUJhKVZBBeWtn ylAyLV4HqQSP0XhbdLw2MfW4+o1Y51AZ+KvRp3gMRsMtkPC1lOuzQo/u69IQnPWTnCpIG3REp7RP u9Sj4ZA6dIC2+AhDD/IhHePawwO7sA9oifZw5xTSJ8g93H8LfQmWA7TSGi3jWMczh3QG6zKtNJ6E FdwaF+uJNI00rY6zVc5WW6pOHWm4CS6PwHdifYksvYe233iuznMXtKsH0B6rMVRzfdwSq3WkLVDp cAY091OcodCbxlcyzgugPValltVk11qidQ7UVh4UXTTrQW7UDj2H/CZbezgHaOaTPFIm12d58qQx MoC2k8cJ5KbDNfgjtTJaPSfmFkvhTJWfJ22Vog61TYKGaemA9+M8zO9NjmLjjW5wdc7MCaVFhqOv pr3eFsN1qG3S9AGAHUzlSROnZu7mVt6A3sv6WWmD1RTX0XLvcjvXompgz6V1CJhY8B6cVYE7n7fX IuArKhtHU6MSSnl1ZyxeLxv/ee8FH9xE/M8bCNjMW7/w3kvqyf5V1+eC5DLqoCxTlhsnjZzdJK/+ R+X+gAr2hNPzMR9cv3T8AhTugfAKZW5kc3RyZWFtCmVuZG9iagoxNwowCm9iago3MDQKZW5kb2Jq CjE4CjAKb2JqClsKXQplbmRvYmoKMTkKMApvYmoKPDwKL1R5cGUKL1BhZ2UKL1BhcmVudAoxCjAK UgovTWVkaWFCb3gKWwowCjAKNzIwCjQwNQpdCi9Db250ZW50cwoyMAowClIKL1Jlc291cmNlcwoy MQowClIKL0Fubm90cwoyMwowClIKL0dyb3VwCjw8Ci9TCi9UcmFuc3BhcmVuY3kKL0NTCi9EZXZp Y2VSR0IKPj4KPj4KZW5kb2JqCjIwCjAKb2JqCjw8Ci9GaWx0ZXIKL0ZsYXRlRGVjb2RlCi9MZW5n dGgKMjIKMApSCj4+CnN0cmVhbQp4nLVXWW8TMRAeqeLFL5QrpC2PCCjH1vfxCEqTtlRqQ5MWRHlA oFKhcBT4Z/AD+ezNkk12OVp2Y8WenbU93u8bezxnTGScxfIoFzQ3aN98YGeMZ5yLYL3hOvVYfEan 2HxgyhpneRo+mT1IbpyOwoQtPMT6lB2xjzByxjYeTz6fvubs3de0luL/5d2FZj9lJ2yIclaaW8S5 86/ErEJq66MR53k0BAtGySBLqslMpbnjIamKcTNNYStaU74AciYlFIuH2CqZOam1YNpCgDU7RbpY 25MR2tEXttH/9PGbZMplKv4kG53MExUXoHXmVQjBslHOxOgtu0e3aY/GtEU9GtDxMS3RNu3SSygG kHdpiHqADj3oj2iZNvFmDOkV5AHe7+N5GZpt6tNNuoaygj67dAjtNbq+zkbv2eboAit2zmZWSVe/ 7GLev8D5L7xqy0OY57VQlXgVXjpj5ogtqS7OrJA8C0E7U+whpUPcNfI3YhVCqTHfInpCZsFrhWlh CfuvzPh1uvKLlobMGZd/04IlTwdwkh7cJXen6GfbyYG24Fh91IfQHtEz1Cu0Sh2U6IBjaPYhdahL a7TW9Gq1DZm0BgMqS27a1IwHqxfRudESD1VL5+FhFf7RRSnzkG/sbns8VJbcHg/BLqLTaYmHqqXz 8PCdHG2Qpato75Ciy9Dd/aWz0Dlol9B3jPohZIvxffoxx9z30puibz7Hj6a/2buQBWl89bvbI1NI v4jxzZbYrDFVpnMJgTQkQg4SoUt0fA/NOL3uJYbuphOtg31/q+kVqqAy4WsBaRH8eLGaR6TbFvhV U/PgRy9/gRhSt6fiNeawccSlyITmGFBdW4uQh0qMXWkL8qqpecg7dB+gR4/v01Nox7ST7os7vyGh B2mQqOJxbzxsfNVCZybUo9QeI1JWou1qS4zUmDJAdh/H+ouE8KWIa4R7DHEG+CWc9g9Igr6NdAYJ yC716GPoHj3HFMMUeWZxozjM4tm1iT55ZMrTgQPodpLBLrxvGfVq87EECU8duC0SaSrheq0tIqum boOpwZSzWB+kMDJMKdbLxEweu/OtNkz4H0432l7akrtTJ8hvD4aO13FFmGZkjX+FD0jbTNA1n9JA ZqaU98FnChmWNQho1qW0nnukwWXlZKaUXEonp8pieFl57gwNc2Q62MA0BOOscRfO0ITKk1xVvQEj iATlZXS/TFuhxXxy3vkP5v5gFehxq+pt/jN/sfwEdsY0YAplbmRzdHJlYW0KZW5kb2JqCjIyCjAK b2JqCjkyNgplbmRvYmoKMjMKMApvYmoKWwpdCmVuZG9iagoyNAowCm9iago8PAovVHlwZQovUGFn ZQovUGFyZW50CjEKMApSCi9NZWRpYUJveApbCjAKMAo3MjAKNDA1Cl0KL0NvbnRlbnRzCjI1CjAK UgovUmVzb3VyY2VzCjI2CjAKUgovQW5ub3RzCjI4CjAKUgovR3JvdXAKPDwKL1MKL1RyYW5zcGFy ZW5jeQovQ1MKL0RldmljZVJHQgo+Pgo+PgplbmRvYmoKMjUKMApvYmoKPDwKL0ZpbHRlcgovRmxh dGVEZWNvZGUKL0xlbmd0aAoyNwowClIKPj4Kc3RyZWFtCnicvVdtT1MxFK7hW/UDJirGhG9EIdHS 995+1LAXYIExxmbIvhgNEDPQoT/Ff6Lx9/m0o9y73aE4dlmz255z2z495+k5tx1RwTgN5c24oblB /fGcjihnnAtvM8N17DEto1Oozqmyxlkehw9zQXLjdGgM6ZQQnme0Ty8AMqKbb4dfzz5wevotriX9 L0/nmv2MntADlFFhbhHmHluJWYXUNgsgLuMBCAhGSS8LqmGu0txxH1VpXK5JWAFNZcmReSt6MQmh VpI5qbWg2qIBNHvl6bS2d13U3Uu6Wf9y8V1S5ZgKP0m7J5NEhQVozTLlvbe0O2ai+4muk8EGaZF9 0idNckSWiSHvITU3aPczrXXnQBIwRxhu1Gy8NPE//HAbQrTl3k8SklQFQkQmnTETjBRU81MiJGfe a2fS5lfah+0ub2iWfSg15iu7jxmuPLcBCYFTcN2DH9esLAjMuLFFkzhksE4OyC7ZwrOObbGEzbEb 6y3IfWyXDt4soQ5P7J9lkuH/GsIxlKFzPuQAz+NxtxnbDC/WiCcK9Tb0HdJGy4TOL8lz8iKURduc ScOUsLps96KRciqtuR8qSzjwbPBqLfq6TVbh3To8f4TSBDV9yA20tiOXrQK3DdRN0osEdmK/HsYd onQwth/3QgMljNuB1I76nM/eou1z0jOFYCuZWB1rPrsf1ko4RMLPiYteDKZO5KQFKfDXQ1ld9Fqk 8cwZl5XXcwckeNPGXwkORGrNfYZEapiXE/Y/IY8rwRTxsDIDcC1u5nLWSsmpFYOlM53uQoYMw2px 72+RvdgOWXIPw7egbcSIC3ntEHLgtBbzYIi1waAaxwrDhEOolO2smEgjpv36tFoiy4CvYsz8jhmq HRkpfr/qV1+1ncIBZ5HLkt6yzGqpZiytYt87N+2KZ9X6vgyYgigFTQeZqo9M1YrfmCBvTwfQQ/Lz usMy6Akh8+t6ikeVrF8bxZSx0s6woVqSJFfTPluplKQZgImkwrkspyMxN051rXj+2weLjYko+vuR rhJzjNDMOCndDJMWcKNQKsvw1UPYZtZIrMLFeyTPcO8qKoe5UnKsRl4p0/Ci8r9vFpiDaW891Wjg 1mrc3DcLoca3M1Xe/LiceYUzMD73TFuhxeRtcOUu9N2MCu9xq2Zj3pq/UP4AKJD8VQplbmRzdHJl YW0KZW5kb2JqCjI3CjAKb2JqCjg3MAplbmRvYmoKMjgKMApvYmoKWwpdCmVuZG9iagoyOQowCm9i ago8PAovVHlwZQovUGFnZQovUGFyZW50CjEKMApSCi9NZWRpYUJveApbCjAKMAo3MjAKNDA1Cl0K L0NvbnRlbnRzCjMwCjAKUgovUmVzb3VyY2VzCjMxCjAKUgovQW5ub3RzCjMzCjAKUgovR3JvdXAK PDwKL1MKL1RyYW5zcGFyZW5jeQovQ1MKL0RldmljZVJHQgo+Pgo+PgplbmRvYmoKMzAKMApvYmoK PDwKL0ZpbHRlcgovRmxhdGVEZWNvZGUKL0xlbmd0aAozMgowClIKPj4Kc3RyZWFtCnicvVdLjxtF EG5k5dKX3VxQLohbBFGY9PvBDeR4HWzJa6/XXiAcEChZRU5gE34KP5ivqmfWY3sSFmOvrZnuru6u 51fVPTdSV0rS/5vSccqj/e2tvJGqUkrnkLxyvGJ7jEXUvJU2+BgUb1+tB0b56KizklsDel/LpXwH ITfy2XerP69/VfL1B9aled6/3ov7tXwlp/jftHhr4l2sBFdtXEgkJCZFgiDBW5NNi7Rak5yKKjOp 2bemNLJImk2NI9c99mIzoNaaKhrntHQBHUgLtacb3b6fo52/l88Gf7z7y0gbK0s/I+evNgNFCjhX JZtzDnJeIjH/XX4lnohTEfAk0RNf4knN+Gs5fyOfz/cQZuDxHFzultjw/RdP3CUkLqicN0PSkFoh 0clE7zdi0iLtHxRtYGZ20Tfwty4T4M1HursuNA78tr2nU+WVzSqQJKROy3Wf/X0blAMJ87FYtCkH ABiKgViKsZiJKUDxSDwUn4svRG9v+fYjxmZVOR1z7FDiAYTSvyf6eKZQ6Se0j8UlemdQbQmUPmYF l6DNxARjj7m5uMJ7AWpPKOA5iIjec9B6oA55fQ/PjN8jpg/aXA9tJDs5+G37Bhu6F90uxY/87sHW EevarWOP+82OfitUI4wWtb1lP3EiCRPx8iWzoYULOOmc2Z2ANiORRzE7p22zr8RFrepQ/Iz+GLLb BszEi5bRGXMTzBWzYcApojlm1R+KB4dW2blU2WTSrtqHTrx1lmur7yfNdwWJp+zxC45AyfcBHHtS p9zdADdmuNHMBGtnCE3hSBVkXNM7gUeZ/e02yo9jeXDbln/aGkLmgBPo7DZHihe65ynd2MZSqYjV qfiF2c+Yeo72irL90PZFraqIG4btMPKImM3xnjC7IwjpP6pL+RKOncL7fbiZYkDoo6hOheRYlfoy YVRT9GocLrCBO6XEFuBdbhRa2tMcFOfNcoLMBZfKZR1pOlvSkTBrrNq2/AdWgdC61re/cUQM2RdF e1rxhBU8YXxe1fhd1tk6hGWL24OwHI9UWDs81ufTYwaHAewHRzAut8El5zpMPh6CTbD3g+BdQcJy WSAoLdi1TVV5Uc5h0M646k4R8YJGiuoY84hGQ75gYp9B0cdodBvKRdfl7dC2BR8qpX2XIw9wwbc2 JRzBKGopeJOqEPnDTiVgpU1crYlGGRNNTWy2t4n/+aIPHpXLAZ8x6OAz0se9L/ralm8lu3vj0JXO uHJ4aXzlgnZ68/Ps0f8I3Cekwnsq2G6Zd44f/f8Bz3rOSQplbmRzdHJlYW0KZW5kb2JqCjMyCjAK b2JqCjk1NAplbmRvYmoKMzMKMApvYmoKWwpdCmVuZG9iagozNQowCm9iago8PAovVHlwZQovUGFn ZQovUGFyZW50CjEKMApSCi9NZWRpYUJveApbCjAKMAo3MjAKNDA1Cl0KL0NvbnRlbnRzCjM2CjAK UgovUmVzb3VyY2VzCjM3CjAKUgovQW5ub3RzCjM5CjAKUgovR3JvdXAKPDwKL1MKL1RyYW5zcGFy ZW5jeQovQ1MKL0RldmljZVJHQgo+Pgo+PgplbmRvYmoKMzYKMApvYmoKPDwKL0ZpbHRlcgovRmxh dGVEZWNvZGUKL0xlbmd0aAozOAowClIKPj4Kc3RyZWFtCnicvVhbbxtFFB7kt3lpI5GISvBWQVtg M/ed6RuVYzskUmrHsUMwDwjURshtSeGRn8EP5jtnd+2114aSeu3R7sycuZw55zuXWd9JnSlJ5dui 4ZRH/csbeSdVppROIXrleMZ6H5OoeiNt8HlQvHy+7Bjlc0eNuVzr0PtWTuVbMLmTx9/Nf7/9WcnX f/BZquf963vtfitfySHKXW1vTXsXUmJXbVyIxCSPihiBg7cmmRppviQ5lavEpGrdklLxIm42Vopc tliLVYdqa7LcOKelC2iAWyg1XZ3txRj1+L087r17+6eRNs8s/Ywcv1oFig7gXBZtSinIcYHE+Ff5 RDwTV6IremIgTsW1uBAdkaN9JV6KczHEyBT1CK1O+f4SYwPRB3WK3jFqmjl9Kse/yZPxPY4WVMy8 C7nffMBq4/9Q3Icg6IJKaRXBilRDUEeTe78CYY10fwy1UVlKDnKW3mJdIv8wW5pNHRqH/dbVp6E9 ZZMKxAmeVlPdJ38vUNkRM58XEq3ygU1cwyrILoawigsxm8E0vm8Y1nSLYV2COuKZE5QO6h8xNsEM 6p1i7Ao1rTrnVV3e7ZyZDZjxCNzWTZWOsWv5oyYz9sk1lbBrVktcg98Prg0+QkGpjOUJ9NyBTgfs +vQU+u8ANdL1BLQxUC4M4N+wIUS7/L7B+AXKAdqzpyXIBH0XJnKJgYH4Ytdy5gHU3JmmrB/BCUgF /jVDW8pyq72XCCzJrED4VysMNWfjBjfo+oyxIR88YyzJWS9Z6dMSzygeioAnsv+cMk5DtIoVBM6E 6x+AZI/3ILB6pU1Mans/q3ZqR6kmZSHG6Jpytguixpw9othkJ54vYKT8SxD22N3IJU/K4DiEuxWU wocqeCtwKCST016Ti7ZyfOdt5pDIN0jQXpDUXu0nSjYZCV8qm0PlDeNwhtZX4hvxGDF09gRXqhlN e4FM6alJQzm6x6hV2eaBx5jxdTGDQBxxTuyUftjhzHeB9s0yL7YjZLTrQjbT+Xo42JbeH3KoOMAO B6UoHZEg8oPSGpczyVp74mDXIgX4k/EbhGrPHI0O+zHHJiNxhABsUegmH/A+EofQ/KH4HGWjCYmf GLlRPXQv0nSXkSFM+4x0HVmy8y4bZhVdtthAO6K7tC76+k1ygmON2Fz73JviUFflDeUlSvEh0+Vj s/8+qHkwLZyylq55UZUGt15udn5b0TpLuUGIbYraounGPX1HNBnBaEmldC+ZLG75xc1ixKbYX6Sy 7uKeWQSiehj5DOb+CM+nDGfVOyyNuV+jHe081NB3bkIG3CDdDr5krY0xxcwCruANMnDOf3io6MIK cb4kGmVMbkpitbxO/N9ftNgjcykk6dDwefD5vb9otS3+FbDNS4TOdLIRYdv4zAXt9OrfFo8+5uqy nSu0p4LdzPOD8aPyD4luX4YKZW5kc3RyZWFtCmVuZG9iagozOAowCm9iagoxMDY2CmVuZG9iagoz OQowCm9iagpbCl0KZW5kb2JqCjQwCjAKb2JqCjw8Ci9UeXBlCi9QYWdlCi9QYXJlbnQKMQowClIK L01lZGlhQm94ClsKMAowCjcyMAo0MDUKXQovQ29udGVudHMKNDEKMApSCi9SZXNvdXJjZXMKNDIK MApSCi9Bbm5vdHMKNDQKMApSCi9Hcm91cAo8PAovUwovVHJhbnNwYXJlbmN5Ci9DUwovRGV2aWNl UkdCCj4+Cj4+CmVuZG9iago0MQowCm9iago8PAovRmlsdGVyCi9GbGF0ZURlY29kZQovTGVuZ3Ro CjQzCjAKUgo+PgpzdHJlYW0KeJy9VklvEzEUNsrNcChSkQCJG0Igget9OYLSJJRI3aZJKb0gUFuh tJDCT+EH89mzZCaTipImxMq8Rfb7nt9ie0oF4zSONzmjuQH9ckmnlDPORbDecJ1mzMuYFMklVdY4 y9PyyUyQ3DgdmQmdE+L3go7pFUCmdOvt5MfFZ07PfyZfyv/1+VLWL+gZ3ceY1myLaDvfJawKqa2P IM7zCAQEo2SQNdVkptLc8ZBU5bqZpsSKaMqXgZxxKYqlEKmSzEmtBdUWDNBsEenSt3cZaHZNt3rf r35JqhxT8SdpdtZMVHRAa+ZVCMHSLM9E9pW+JK8JJ6eRdEiX7JM+aKWyJLyi2Te6nS0BKYNh0hur FwOXhv8SkNtkRlseQjMzpaqWGeGlM6aRmppq+dwIyVkI2pmyC5QOse7lDWw7hlLD3nz4hGeGq8Bt REIH1UJ373eVlRWBGZfvqIlDXpBjcoQxQGGMyS45PUV1HEAo2HqhQBySEb57xfRhmjlIFTUE14Hu A+QOVseZ42TrPb4e0gAwG9FYBswhOazMbMD8PqYdgHMR9jDaWEsArJkPQOHpqtG8RdNIrtqIq0aa VVHw/6eKWjhEImVlOYxSGRzg20+h7SHbI4xnq/ZFmsCccb7tzx2QEE2bfi04JFJrHjwVSszvf5M8 XAumSFfvAkCLkxyNMiparptabQS6l9pvXHVR0bHHqf9in8Y2OwLdBo1LY4c2k1feEf3UsUPyMdk5 SZ2d9/dRsjuurNcumNx489RYZ2iMZ0E2QtNFxfWSH/10KO1U9bibzpudYtv3kbXHlceb5ElRsTtp ayPyYC1uq+CYNgKXadv1NZet1/OherTesm0DPkeE+6nEOuniOGnWap6mAfkEOZ7LvZSK4iYaoYgP MWK+xrUaW8sOEDIWnNV6wS5W8KxRynucWgrWrZHwwqVXLfd4BdaVk5lScimdLJTl8rryn583sMF0 sIFqMHhDG7f080ao/Imo2oEUTATlpcFxzbQVWjTfpk/vkr6bURE9btVizFvnL44/D05bLwplbmRz dHJlYW0KZW5kb2JqCjQzCjAKb2JqCjc3NQplbmRvYmoKNDQKMApvYmoKWwpdCmVuZG9iago0NQow Cm9iago8PAovVHlwZQovUGFnZQovUGFyZW50CjEKMApSCi9NZWRpYUJveApbCjAKMAo3MjAKNDA1 Cl0KL0NvbnRlbnRzCjQ2CjAKUgovUmVzb3VyY2VzCjQ3CjAKUgovQW5ub3RzCjQ5CjAKUgovR3Jv dXAKPDwKL1MKL1RyYW5zcGFyZW5jeQovQ1MKL0RldmljZVJHQgo+Pgo+PgplbmRvYmoKNDYKMApv YmoKPDwKL0ZpbHRlcgovRmxhdGVEZWNvZGUKL0xlbmd0aAo0OAowClIKPj4Kc3RyZWFtCnicvVhZ bxxFEG40b/0SIkJCFPIShSMSTPo+eECA1t5xstJ6b2KbBwRKLLQJ2CB+Cf8ij/YPpLqmZ+d0COsd 72inu6t7uo6vuqpmzihPGQ3X13lHMQ3tL6/pGWUpY9wbp5nCFc0xLArNayqNtobh4+tyIJi2KnTW tDEI91O6om+AyRl9+v36j9OfGX31J8pS/M9fbbX7KX1JJ3CdVfbmYe9cS9iVC2VcYGIdC4yAg5bC iwppXZIUs8wjqXiupBS8AjfpCkOWPbRiMQitFKkVSnGqDHSAm4mWLmT7YQ7t/Jw+3f/9zV+CSpvK 8BN0/rIOVBBAqdRJ772h8xyJ+a/0S/IVkeQFuU8SoklGhmREFtDukxVQHsN4iOMlWT6h89/o3nwL 5tKxVBqrdbcIxcb/YZr3wUgZ5n0do4JUwYg7AcLUQKqQtkeJC5Z6r6wuzoNUPpwAcUW3bUOhYL+m +bhLNZOemcAJzlLFdB/8s0FlR8y0zTWq8yEm+sSITMkEPOMBuU3uwv0W9FfkOcwmZEYG4CsD8gzv M6AmcXXTsz6sexaMLTk5gUcydDoPLvmQJFurJrtVswyQFlKpDv0uQIJci0FNsgSkXu5eFLSy0U0p BmjNjBzj6QsyzKIkGdhxBfMlAlNyULF9W+qwJoM2X7Go4RTWHSB1gciE3Ra4yxj5L+DpAfYq8vRi A++aNjhAWQ6B87eb2FR4y3fgdZe7lkNIl0onHG8Ls+vDVZ5kLvnNHOU2o067JhWfWCLqU/SKPRhN wSuy6A2anDwhn8PR/4TcgfttIH2DE0fgamO4Ejjgz8F5JhAGsuh0o8qWcYN75GPyKbmza5Wd0JBp pOxQu0csjbohLFuMyGfkR4wVZRzYAzO/iJCEkzTEWPDsCoRXuCrZnLpw6pcY1S864sQlcphgxLjo iBaX4cl+VPe2qfpRDGwZMA8KBcVXmHQaTlrKXHe+mkkKg5yc4yZhIguDpmke7lo9K0RqLPcdKl6D FXinwV/bb7lNreRQjAmQx4ua3/7dD0stQ5xtsatk3a6cVGaCPIAcQ1Fw9f8WeXuN3PAu8ZX1qZbO 2w4V+oZIsxuFqMUOIHqLZckSq7N9gGKAUX4ZCra8JjneIDSAyDPARBDi0DgmgCkmhSkgOatUKEXE +gkxnwKtL/yM4DClVYd6fcPnWgV7r/C12AF8j7ESbMbqUcwR5RlbYdpebbBcImIZrj1E1BJop4hg jucE95jAfF6dJjEkB35DDMvjTe45ipVogs50CKPj/JT3aA4Jr92ee+9qFslQ7hH63AQ1y2XP6+m8 MrpXyRnl+/EE1gyjJd4dkYZQGJX//iKT0Ty1kEC6Ve2v4pHqhqrXNiPyBcaTo1jhDCJ6eZQp0Cze kYoYcxfxnVVmRvG9NNYDH8F1H0JWgPURTBgoq2ZwBXdfxdfYcYh4CZQOzZLg0c6rWCtTpS2THfrv 4GOJlM7Bqw4Uyc5oAc5l8asZc8rUiOuSKJgQVkRi8XiV+L8/msAeqfLGUwUdbY22W3804TL/8CTb mZun3MO7XUikqTJc8fq3rwfXOZVXcwXrMSO7eb43fuH6FwlFxAsKZW5kc3RyZWFtCmVuZG9iago0 OAowCm9iagoxMTgzCmVuZG9iago0OQowCm9iagpbCl0KZW5kb2JqCjExCjAKb2JqCjw8Ci9DQQox LjAKL2NhCjEuMAo+PgplbmRvYmoKMTIKMApvYmoKPDwKL0NBCjAKL2NhCjAKPj4KZW5kb2JqCjgK MApvYmoKPDwKL0ZvbnQKPDwKL0ZvbnQyCjEzCjAKUgovRm9udDMKMzQKMApSCj4+Ci9QYXR0ZXJu Cjw8Cj4+Ci9YT2JqZWN0Cjw8Cj4+Ci9FeHRHU3RhdGUKPDwKL0FscGhhMAoxMQowClIKL0FscGhh MQoxMgowClIKPj4KL1Byb2NTZXQKWwovUERGCi9UZXh0Ci9JbWFnZUIKL0ltYWdlQwovSW1hZ2VJ Cl0KPj4KZW5kb2JqCjE2CjAKb2JqCjw8Ci9Gb250Cjw8Ci9Gb250MgoxMwowClIKL0ZvbnQzCjM0 CjAKUgo+PgovUGF0dGVybgo8PAo+PgovWE9iamVjdAo8PAo+PgovRXh0R1N0YXRlCjw8Ci9BbHBo YTAKMTEKMApSCi9BbHBoYTEKMTIKMApSCj4+Ci9Qcm9jU2V0ClsKL1BERgovVGV4dAovSW1hZ2VC Ci9JbWFnZUMKL0ltYWdlSQpdCj4+CmVuZG9iagoyMQowCm9iago8PAovRm9udAo8PAovRm9udDIK MTMKMApSCi9Gb250MwozNAowClIKPj4KL1BhdHRlcm4KPDwKPj4KL1hPYmplY3QKPDwKPj4KL0V4 dEdTdGF0ZQo8PAovQWxwaGEwCjExCjAKUgovQWxwaGExCjEyCjAKUgo+PgovUHJvY1NldApbCi9Q REYKL1RleHQKL0ltYWdlQgovSW1hZ2VDCi9JbWFnZUkKXQo+PgplbmRvYmoKMjYKMApvYmoKPDwK L0ZvbnQKPDwKL0ZvbnQyCjEzCjAKUgovRm9udDMKMzQKMApSCj4+Ci9QYXR0ZXJuCjw8Cj4+Ci9Y T2JqZWN0Cjw8Cj4+Ci9FeHRHU3RhdGUKPDwKL0FscGhhMAoxMQowClIKL0FscGhhMQoxMgowClIK Pj4KL1Byb2NTZXQKWwovUERGCi9UZXh0Ci9JbWFnZUIKL0ltYWdlQwovSW1hZ2VJCl0KPj4KZW5k b2JqCjMxCjAKb2JqCjw8Ci9Gb250Cjw8Ci9Gb250MgoxMwowClIKL0ZvbnQzCjM0CjAKUgo+Pgov UGF0dGVybgo8PAo+PgovWE9iamVjdAo8PAo+PgovRXh0R1N0YXRlCjw8Ci9BbHBoYTAKMTEKMApS Ci9BbHBoYTEKMTIKMApSCj4+Ci9Qcm9jU2V0ClsKL1BERgovVGV4dAovSW1hZ2VCCi9JbWFnZUMK L0ltYWdlSQpdCj4+CmVuZG9iagozNwowCm9iago8PAovRm9udAo8PAovRm9udDIKMTMKMApSCi9G b250MwozNAowClIKPj4KL1BhdHRlcm4KPDwKPj4KL1hPYmplY3QKPDwKPj4KL0V4dEdTdGF0ZQo8 PAovQWxwaGEwCjExCjAKUgovQWxwaGExCjEyCjAKUgo+PgovUHJvY1NldApbCi9QREYKL1RleHQK L0ltYWdlQgovSW1hZ2VDCi9JbWFnZUkKXQo+PgplbmRvYmoKNDIKMApvYmoKPDwKL0ZvbnQKPDwK L0ZvbnQyCjEzCjAKUgovRm9udDMKMzQKMApSCj4+Ci9QYXR0ZXJuCjw8Cj4+Ci9YT2JqZWN0Cjw8 Cj4+Ci9FeHRHU3RhdGUKPDwKL0FscGhhMAoxMQowClIKL0FscGhhMQoxMgowClIKPj4KL1Byb2NT ZXQKWwovUERGCi9UZXh0Ci9JbWFnZUIKL0ltYWdlQwovSW1hZ2VJCl0KPj4KZW5kb2JqCjQ3CjAK b2JqCjw8Ci9Gb250Cjw8Ci9Gb250MgoxMwowClIKL0ZvbnQzCjM0CjAKUgo+PgovUGF0dGVybgo8 PAo+PgovWE9iamVjdAo8PAo+PgovRXh0R1N0YXRlCjw8Ci9BbHBoYTAKMTEKMApSCi9BbHBoYTEK MTIKMApSCj4+Ci9Qcm9jU2V0ClsKL1BERgovVGV4dAovSW1hZ2VCCi9JbWFnZUMKL0ltYWdlSQpd Cj4+CmVuZG9iagoxMwowCm9iago8PAovVHlwZQovRm9udAovU3VidHlwZQovVHlwZTAKL0Jhc2VG b250Ci9NVUZVWlkrQXJpYWxNVAovRW5jb2RpbmcKL0lkZW50aXR5LUgKL0Rlc2NlbmRhbnRGb250 cwpbCjUwCjAKUgpdCi9Ub1VuaWNvZGUKNTEKMApSCj4+CmVuZG9iagozNAowCm9iago8PAovVHlw ZQovRm9udAovU3VidHlwZQovVHlwZTAKL0Jhc2VGb250Ci9NVUZVWlkrQXJpYWwtSXRhbGljTVQK L0VuY29kaW5nCi9JZGVudGl0eS1ICi9EZXNjZW5kYW50Rm9udHMKWwo1NAowClIKXQovVG9Vbmlj b2RlCjU1CjAKUgo+PgplbmRvYmoKNTEKMApvYmoKPDwKL0ZpbHRlcgovRmxhdGVEZWNvZGUKL0xl bmd0aAo1OAowClIKPj4Kc3RyZWFtCnicfVPLasMwELz7K3RMD8GSbCcEjKGkFHzog7r9AD3WqaGW jewc/PeVd500SSECP0Y7s7MrVvG+fCpdM7L43XemgpHVjbMehu7oDTANh8ZFQjLbmHFB+Dat6qM4 iKtpGKEtXd1Fec7ijxAcRj+x1aPtNDxE8Zu34Bt3YKuvfRVwdez7H2jBjYxHRcEs1CHRi+pfVQss Rtm6tCHejNM6aP4Yn1MPTCIWVIzpLAy9MuCVO0CU87AKlj+HVUTg7E2ck0rXBAPh9CtPEfOtPOZJ Qh7OJS8QZYRkQSJkyetsM00hjVtib0lbIxLLpikufcWtryB2Yi6dkn9OoZIlG7JrdJKLlkpPDW4m VHpCpWXyyj69tU8oYbYjLRDSiFJOyBKiCrL6/pGk6amY+bMRpIVTJtzU949E6UCTXG4uncQ/J01t 6xTZwtxvVG+Iho2KLaJMcUIGkcG2xS4ldNXoPFvzFTgPrjl6H2YW7wkO6zymjYPzVeq7flbh8wsx dgN9CmVuZHN0cmVhbQplbmRvYmoKNTMKMApvYmoKPDwKL0ZpbHRlcgovRmxhdGVEZWNvZGUKL0xl bmd0aAo1OQowClIKPj4Kc3RyZWFtCnicnLwJYFTVFTd+733rvHkz82Yy+0wmM5nMhDBAgCRAMJqn LC4QFtkSZCTIDqIEEBFBgrIJqGgr7oI7qEiAgAFpTSnVulBoXVq1CrWoaI1SSykFMvM/9755IVj7 //p9mcx95y3z3n33nvM7yz33IowQsqBGxCFt8sIF0afCf/wbHHkcIXH0tLnT57x7W92jQJ+E703T b7xt2tGNI4cjZKtHaEXhjKmTphxzv/EtQvevgN/0mQEHXGXeQtjfD/tFM+YsWDSx4vxY2D+GUMWU G2+ePEn8deMRhN4cCPsz5kxaNNfVbGtE6PzLcH107rypcxMf1rwO++8iZP2lsA8F4BsUXkABPon8 CGW/gu8Jus3MzJ6g5+mWfAO/bsl9EdqCtuGZaBt6HR3AJ+FX29Fe1Ix+i3xoILzXEvRztBqJaDwc uRtdCx8Bjv8cB7LNqBQ9Be3wFDoE145Dd6B9yIv92a/RMrSSew9+tRLZUCG6HI1AN6N78NDsLWgC OsrfhfqioegmNBc3Zmuz92YfyD6LnkN7ud9m25EVBdFk+BzKfif8Kftn1B1+8SB6BB3FD1h2Ix2e 0ghXPoHmoUe5NI+z07NnoQYxdCvUgUc16BBuJSm4+1T0FfbjJdwAuMsz2absQbgqjNJoBnoU7cMV +EoSEyZka7KHkBeesQju+gjaifbApwX9An2MVeFk9tnsSRRA3dDV8D7N6He4lcu0L89UQ4sJ0Eol qBLO3Ix+id5ER3Ac/4rcLKhCb0EXFmffR27UC42B2r4Av/wS/4vcAZ9l3Bv84OwVyA7tcj9tbfQb 9BccxKV4OB5LSsjN5EluHpLhib3gMwXNhPZ+GO7+GU7hPUQlh7ln+Jf4c2J+5ljWDj2SRI+hJ9Cv sA3eNIrn4zvxh/ivZACZSB4jn3M/57fyf5AmwVtfj+age9BL6F/Yhfvhkfg6PAMvwavx/fgRfAgf wSfI5WQ0mU2+52ZwDdwv+CvgM4qfz98lrBLWiScytZmDmd9n/pXtnV2FRgI/LIfaP4iehDfbiw6j j+BzFH2OBWzFdvhEcQyPwbfD5w58D34ab8FbcTM85Qj+HH+Nf8D/xOcIgo9IQiRGCuETJ/PIreTn 5HFyGD5HyLfk35yPK+RSXAVXxdVxN0OtVnMb4LOb+wsf5A/zWWjn3sJGYZOwRXhJOCCcFFXpThnJ 755/pr1r+2cZlFmT2ZjZmWnO/gV5oA+D0AoFqApqPwk+s6C/NwLHbUfvYRXaLoi74svwUGiZiXgW bsCLoCVX4Efxc6zur+D90Ep/xN9DnW0kzOrcg1SQK8hw+FxPppIGsoE8QJrJh+QsJ3FWzsF5uK7c lVyam8ot4G7jNnJN3Lvcp9zn3GnuPHyyvMIX8IV8kk/xV/IT+Vv4J/mv+K+ECcI7wheiIs4RV4kt 4t+lPtJl0ghppJSW7pP2SO/L9cCdv0a70auo0x8+xi3nBnG70b2kjA+Q35HfAT9PRFO4GgKcSrbg NWQpbiZFwiLxEnIJHoZO8klo6zfIJnKaXMLV4CF4FJpFehl3E938i7Cp4n+N2vj98G6/gzsvElV8 B/leVNFOjEglPPM3XE8+xb2DPuaOYol/Cn3CK9iH28gL3Ajggl/wlwm1KMY9jl7hGvBStJsMQkg5 J68HPh6GXwRcGI174zNcFnFkGHBRX+6v6C40m/wJtYEcr0EP4Sn8dHQvKsNL0FfoeZCKEuEmsavo wW+RmfxakoebEeG3wttV4iLMCW60Aqe5R8XvyUfoFnSYV9Bn3MtQ+8PkFa6GPylci2eABCxFq1BD djm6Tajl/4CnIw6PRQn+GKDbEq43H4PtMkCVCYBpe0C69wEOXM7VwBE/cM5Q4IsxgBCPwudhwAke OGgmyPg4QLHfoWZxNGlB0wU7BtRBiH8ncy0an30ePZKdjm7KPoC6Ax6szi6BO25BX6D70Ba8MnM7 mosiIDmf4aHCYHJYGJztTtaSj8gosvHi/oXWTmA/+gY+r8DOZcJraC3/RzQKVWfXZz8A7u4CCPsI ugFdg47DW34HT7iKa0VlmWFkR3YwNxfe9ygamX0hW4AVNCN7IxqO9qPnJAFNklLQx034D/C+t6Op 5NrsAm5qZia0w33QCjq01i2AP3frA8aMvlyvvuzSqkv6V/brW1Fe1rtXz9Ie3bulupZ0KU4miuKF sWhBJD8cCgb8Pq/Hnedyag67TbUqFlkSBZ4jGHUbFB9cH21K1jfxyfhVV3Wn+/FJcGBSpwP1TVE4 NPjia5qi9eyy6MVX6nDltB9dqRtX6h1XYi1ahaq6d4sOikebDg2MR1vw+JG1QN8zMF4XbWpjdA2j NzDaBnQsBj+IDvLPGBhtwvXRQU2DF85YO6h+INxuh1UZEB8wVeneDe1QrEBagWryxefuwL7LMCOI b1D/HQTJNqhUUzA+cFBTID6Q1qCJSwyaNKVpxMjaQQNDsVhd925NeMDk+A1NKH5FkyPFLkED2GOa xAFNEntMdCZ9G7QuuqNb69r1LRq6oT6lTolPmTShtombVEef4UzBcwc2+RYf91/YhZu7BtSu7nw2 xK0d5J8Zpbtr166ONm0eWdv5bIyWdXVwD/gtSQyuXzsYHr0eGnHIqCg8jaysq23CK+GRUfom9K2M 95saH0SP1M+KNlniV8RnrJ1VD10TXNuErr0ttjMY1Pdmj6HgoOja0bXxWFN1KF43aWB4hxutvfa2 XQE9Grj4TPduOzSn0bA77I4codo6E1M7zjGKXU6pIdd2tCymNYpfDQzRFJ0chZrUxuGd+tFiaj+0 dnI/uAz+6jD8qmkK9MjMJsuA+rVaf3qc/r5JSGjx6Np/IuCAeNu3Fx+ZlDsiJrR/IkpSPulgNThv 0k2pVFPXrpRFpAHQp1DHy9h+RfduC1tIPD5Xi8IGmg+NgLadVNe/FJo/FqMdvK5FRzfATlPjyFpj P4puCO1EemmqronU0zOt5hnPGHqm0TzT8fP6OHByM6LmqqdJTnb8OzRv3qAZ/Zuw9//n9FTj/JBR 8SEjx9dGB62tz7XtkNEX7Rnn+3Wcy1FNeQNquRDJUSTEsbPAlBM6LqY7tWoTn4B/kTH1lBZJBq5k R3B0cJNWf5VR1imx2P/4o5bsSfortrnws1w1m/qnLt6/5KL9i6qnruWgwqAqh4wev3atctE5YDXj gVfnNsDxaHRtLDqgCY0ByUzAf0u2tR/91oWadGiyAfQC4D/jUG73ogtDOboO/ih3du82GIBu7drB 8ejgtfVrJ7VkG2+IR7X42r3kADmwdu6gepNxWrL71oWaBq+vg7aagfuDUBB0xY44XjNyh47XjBpf u1cDX2HN6NqdBJMB9VfU7SiCc7V7owjp7CihR+lBuhOlO2gIhpfcSWR2fWivjlAjO8uzA2x/cgtG 7JhsHsNocgsxjmnmMQLHeOOYzo7RP4oxA0bXduYeJpJ13YEbCWYGtoDAYpcQijljzgQUGJTu+SjX el4X0DkU5VvhSnQ9t4vcCl6NAH7DLXvBzTmzqzBRLrRkz+iFyZJyq6iAouMxEgTR+p1FljmOIEmu UhyWRguxQHPrHpuj3PIZ5vgqgnWbsxwH1IYX/Klh2qlUVU17ldaeSle1V6HqKg0+7VVQYKerspJ+ e/XEqVQeV1Hm4cpYuaH3oe6f9jrUk9uFfSdPZr42SlDgaDwcKmb1TOoeJHBY+I4gbnkUb8AEzxLp E7XT6TZU3YaNOxu3XdOD3cz1z39mvoO7LMmMJPXCe0hDl+pKsQMjzSXJmtaCy3ahTXYZtrpT2mS/ HnEaF+U47mXnE+vZjdtPt2mn4e5V1VVQ6TROEmd53z59y0QJPh4N46MP/q5m/P7ltxVfGk/hVGbk fnwG27/7uP3ckbq1G1/7RaYgE73o+VN1tQvpohGLomHkstAaKJs4DNtmtIm73g7y16xpZAwQZ5od DkYcb7bZGPGt7lAUMsZhL7AT+8uuXB1T8PejeubFkbO8OAmfMi9YFhppXw4tXnhp8eLl+8fXHM6M xMfwX/bv3bh2/B/OtX/8XeaHjAy11LnJ5AOopR+t0q+xYqsSwiGFVyyq3aE5JdGKiZ9aKRLiOdnn sklgo1C7hZktYLW4eYmTsSIKVoS0qBu7XxeBu54TW/CDuk14DunOvHIUCMxdbzBJzan241Dh9nRV ZWmVy1cJ/9CFbEs3vXqidF5frw9eQZT69PWJktcnJYtFqbhP36TeY9NVefh+zj19ZY9liy+9eVH/ 4df0W7ig93J+2739SnYPnPxgebd7u9or1owZvuaea8bc1yNAeenFzGf4LvB2FTRstwIi8hJUbYSe xFwVIVjBVUghHOwgsZ/Ufzh4AjeDXbsZOG+z9amHoaVPpU8d19qAj4HZKFO3ae2M6Xr1LAOWc9Oa 9em759CIcb0r+3CHDjWsS9YEJl0Hz70ct5BZZA5IZTc9MJfM5UgNroFHxhEJCnPhggA/9x7aKMfT 2peotKYN3r0BOrEi5rmclOCW3btp7fdBsRpqz6GE7ie0slVGFbcjfjOc38yzWp5OM2kwKrXv0KFD 9Lco+xWphJ7l0Ki9iMt+ttNdSVqyn+lRd+VDHCbcJm47R7iFCLvhaoARDincCUROAF9uhYfzuxbD nau0U22awWOrhR6p9FLtIOW1VMqDyzDeuiFTGxC+Peum6DIm+xXvFFqB3/OJQ7c5VFW9YoxDtVqv GCO2ZE/oTrov+Om+pNEyRI9aKWVcBfundK/NdsWYsEhLh0pLSaPlDkIhUFeCEV5wR2w2H8DRCSYr lNADVFgsTqTSI8irqlCq9BgqBUE5BMUhaB/aQqEd4n/e6RTcSaR3+hKkjhHf6QGrVaS31OgRpKkq LemxjlteuGezGA1oYRBjUAjWX4IJ54WvC76O7DF9GC+uJmusaxxv2QWLZPWTQXlDPdcEBoRG503w TAhcG5otzbZOzrvRMztQH7qN3CoutC52rBYfljZqb/k/Jh+KH1o/cQQ7qktrS1sSiB+aabP5KH67 aSP55lv0WLy8pwUji8YQ+xS7gjVRmF5h2VDgZP3itNMTTpkedM5HFNuj8NMoojqIXYFkegViV6AN kTfXUT6Dl06n2qCkZLqBkblGwOkGlEb96B+Gb11dyvxDgPuaq09Zb6/XBbAkxguLk3mat6x3H6eW jBdK4pjZ721euHPBFbPee+r92+7fu3XJkq1b71hyTZq8h3l86csTd2WyH2cymV9ve/hV/ETmoe9P 4hl41nczV1EuPwqsdw64TkEf6wMVo+asVNgbIlYqxluwkqN6aza/jNxHHpH5l3lsQaJAOIuAVYLf VlhTKLQVEaYo3pI9xrAZiG90J2OvMGMvO2Mv6HM9QJnH5BDGLUFVAAGgmrVVt9N7CTgq6AIRAtZ9 uAqvRIbgNxjtyP5gh2pQVF1NIZFqyzRKg3Zhf7G4UxSlCoCaMnKu+fL3Rj/0eekC/vbLlhS8cuXb E6GWVSCvErRChPj3Igkkg7aATNUJEzcqK5RgR5hQAWvsYnJlSIPFqdn8eXniGBvlGaeTEd/pFk0D KuIWIpSDfPSCSISejYTtcCai0reNtJDXdJUoPl+0QHMSEi0AfCx9/xAtD6FSyiKpaloe7E3Fj3Q8 UHW5CHugbnE4ifmcY7rVlUfGRNz0GL33Tri18QKE8vq3Omv5n3oalUj6PPo09jC9zyXCJeJrwuvi a9Kb8lth6Wq1Th1tn61OsS92Lc6727Xf9UXwi9DJoPq69dU8EtLCWr4W0cRfZk9CKx5DMmwt0MPB iKLJovh2OOgOh4NyOAj4KQfDnC2itZBndw13YmcL9u+mb4BolXdhoiqmoCqmoCpUUBmaKfN97wHz UmHFr5HlKIo03E9XnburyURyM1kGhuM+UoQK8H07mNilAYRPpygWM3kDy6q6rT193Gmqz9X2Hik7 QLOhmZApg/1QGqfn5SQx4Ykl+wIH9elTUQ5SxzQXiCToMLBqRImXzvclvsQzj36/5ZHb73wc7807 8/v3Tl/1woGnJ0S2bbu8anLrHQe/mDb7Z4+vzTv80Tfbal/c/+yaSb2oBI7Nfsl7gfdSuHkP52cg 35LjQErs6gTf1oBfp53nDyNMZSOlwg4uiSugLRwRRSnxRMJ8pCQslNjiNtUfAGspqlFpi0pJdk+4 PFlKwfdQKf0gV2V1NejkNuj8tje0N1yV2sFUb/qlnd9FsHltg2yrbPwg5zjnwhB3rfdGbZZ7ivcW 223uVba17rtDz9kUIcoxprOqNjsvYXgupn1K7fPXMI1b23AFvIyH9+8jz6IAmaFboJYCVNPmMrvY ZXaxqwOLXfMnRm+Okqifiki0UTIvlcxLpY5LpflJBttJjJJaksCbnnqV/iq5obu/BffbGXgP78P9 QJ+36tYOjN7QrQU/kOOOVBvjjxwen0qlO2C5/TiVCzBaKLMYvALIAtwB4IIb6ii8gL1FoZgxhdS3 gzT5gzKIREsUL0yObS54cPay7U8vLRvqdlnnt6yaNXO9uzn2zSuL3p49bcqdGzInPvxVFt/lf2R1 051LnnI/SRYtnXznihXR3W9O3zll4uM9Ir+4tzXzzy+ptRAExNLAxlegfV/di9TsWf1l2j42kTEO g3CRlRYDzlkpMDgXWWkxoJ2VkswAj5USU1yybBynDSyzUmClyEoLKw214KpVZ6iPqlvVt1RhKDfU 9nOec4F4I1XkJEGxchLoE5vtbY53cxzP2RBRbWD0vkZeQzJ4X5t1BfE8XILeVvgWMu1VQVD0/IJy xVQcimFVMOI7Zl4oLbivbpP0wni51BirkDY4CBUGq81djsAVjBKO0B/T3wBxfA/9Ddltb8HrWX9/ S3Uw1RunqFhXaV9qTG1op6pOVzkrK5lLtLpHigc8cDgc0N0DJtTuRTYwAF2VgLbv69aySq6weyXH 5+dX0VvUATPANbpb1a2VauOISlVPVqqFYdh2r2TYUYdT//mHUuBnVuAyZ5kn7uScmGxsX0Ge+Nkb bzRnKvDE57g95695LvMUQNmD7bMpTlD7MCY8jyL4vJ6Xx7rTxUorAw1mpFgpdQFEdB+l8ph16GIl 5zcNGiZExkWUymPGoouVVj/rb3oR6+yLUWgvwtDaNtq8OGxXIh5P2EVVmNXB85GwzY6R5Adlz4xL RjDEosqFIg6VKhCp9oOAMhRkSlxMCTpYOSR4W/7a/I15L+T9Wv1Q/SQkW/L89q5BztJT6GndBwqF A6TR8hSPKy/vbbvDbc9z2x02gBs9j1ZEt28GH8/u0D04V6lXHTx+j0IRqBfdSavnnKjdrC3T7tN4 7f8AKn4GKn6M/Jqf+E1Q8W+IuvbjCuTAD4Lk9dtp3/1T4FJwMbhcBC9p6gsBoLB2SDvhCwh8fLXc IyUAyyGmgpj2wQ3gJ9T9mG064w2ATF7ME+MAaJDHLYFlmBzzC88jN97ZvG39uPVdtt5LPmp/dfiK +1uxvOCeU79tx43a2nUHn3505/BqL/n7y5mFEzKnf//m/TuPUUSpAf7ygB7KR10JtxfM75OsbZwt OSJqtpZsEsUmG8U72Chm+CestDNmYlcz5KCWimK4JOoFnVbgwAV4IuZwqEtEt2GbDayYkFAYcduU CEYJjf6KuSdaxKdRnvIxjeZj7okv50scev+Q9huTt9Jt2sE05a3uswN4oKR7BgYGRse7Rkdnc1Ok KfIs15ToAvmW8Ep5VfhD+X2vU4rSji02MEOkLwPqjFIxdkKiJ4qj8WiMnnDSWo6wEahnCL9HbccW qtLMOmOqcNDuhNlECZOzEh2clZivMc7SMNIA4OAFT75KbV9tQzdAtn56XoRJdYQBc4RBbKQFV+qF 1b6Jvpt9y3y8j7l/PtaKPi/9rc9La+prIUW7Uh2ehqHHOrNem6HUmDKDZsrxGb2UKrTOKAU+B5aS xcy9ECWqyVzU0okXIqfWl+o17O7Ehty5Xf5uV88ee/mYG8jl+6c3t996ZMVfMsefuPvEtk/b+w6/ d9i8Z5++ffGL/Cj7rJ41PS/77s+T6zP/+sPatjvwELwEb/3VlgPnP02/WNfy5MPbt0OLTgLd5hVe QDY0V7cftGEe/onMW0B5UKDpSTBvUW3zOY7QhhzObD6OBB3yfMvf0HBgpomEq4bNzXgZOEABe04Y h2mn0g1VNafahmmnqbdA/XJqC1Y6Kw3DDwSOxg9ExIlSvI/L1XcSt3t9pm1IH8de7s5/3M2f3bb+ wYwrc67lk234G/zm4zRmOAqkJgBS40Nx1JMbvBeFTVc9yGBY8udkJ3e0kO2XsrK7aeeVdGB38sLl zLMvZJIU7tgPsv0SU/C6s/tSqpSdSLLS+DllnEKG5OGO/SDbLzGRnf2cWdSl7ETSfwHmm1UUivSg ihX8FjKmRw9XLCIKXSIuW4RaFCxwcGoPixukHBQjqGw6TEeDEuykw8+Z4TnOvIrrkGmuyKPSyz3s jh4m054L8YGLgw/UQ2mj4cpcDOJVVhHRrIhoVOQ4i0U4TMWfez49BsR5vZAepI+lv/QwreNhb3rh /cyHwbNwaa4C5pfCSt8KLy7xXu29Ovml+nVPwdITL0VL8RJ+gdxgnafeYlvsW4fW4vX8Knm5dYW6 ynaP713nG3muQoCPneFokG6i0VK66R5NUkwJlERVFPEjFaqxuQfu1NImjERMGIlQGGEgGpn/ugVb 9pHpKJW7KGVelOrAmtR8hx4FrHFg5NAcxNGC79cDvf0MYPwMYPwMYPzzmzjMtZDpuqeInSxiJ4vY yaL5HtMRj3p0D/Fs6PWmqduYQmMBjVMd+q3DenZVplkj5sLX/XJ/4FM1oIa6nzSKjD+cTFaU57wr 03hGcCTP3QlzOgMQnjX3xi9fb/1m9pzV92ROf/RR5vT9N6yaPWPl3dOmr+l/9YZRy7dsu3PZC1yo 5OFZmz8+unnaQyXdDq7Zn0UYt973Kzx6xoq7Jk5eveJ8tmbD8Ocb73xxixmPo5IdAX24eS9ygKjE aXN4/EbJNCAr44aks4aLdYiyV2M2ON3Pp5SHyWYxK+OGmmQmWaxDuL2aGexrvnCCPsyr5RToiU5B h1etBWCcJJxgmpxm/O03NC0jTupdKIP7nYzDnSy44vQ7u6WsXSI0FD7cztntbjQCY+ZI2jSnOAZT +6iQ+uC08w6m0r2ZlujN+g+Yn0qjRjXtp7/pCER0qsQFi0/vykw+JxPq//LUi5/1o0eVdn6QXt4/ ONSrx6/zjotP4270zglOjy8OLo2sD66LPOrdGtwf/Mb7ZfR0NO9S75PebV6uf8kUkRRTazEOsuWP RcVol8hw+0RqGobpI/F7Iwy13UwrUWDKWIEpPgVmlKdgH65E1txpK21metpqnrZSbe282Ezc0I1a ALoPTADGDgkmRwnZUPzODjly6k7i3JC6SI5AU+dkKCdBHUaiqalRugGn6/7DJOywCi8jFeXFVEvD FoH4uJwsXJjETEg8THrmbvMumTRq6Yg+uM9rc/acx9Ib97XdvvjvT7/8MXnnuQWLdm5dsvQpPEpb fNPQZX+aq/rHzsbyn45i7dHMXzM/ZL7K7Hrlda78sT0HH18PqhqkZC+4Jqv4JBs966dHeQGJkoWI VTxXhUVeIVVg8iNCI4FPybkRgQaqd9s0Y/DJGH+iw0/w3Xvo0CGu7tCh8y8cOgS/mIs+5y/hf02z AXX1Pq5RIJwgcjIRXiPj4SBHxu8kurgPjwA/coTuQS/hl6I8Ccp8FQs93iKNG8+at4pqfBQoDda0 wZ8/qBkPz42XVGAPxp653DvnMxwhy7fgR3dlDmZ+tYu+3XiwRFThPcCAQrRCLwWWC5ElwSUhckNw aojMVifZyXh1tJ30sQ+0k1BAlnikFTudyFbixhFgse16PFYYqypQCqoKC6NVsVgEXR+5SbneN6tI uz7qxM5Z8Vwd6VAUcEAVHSxpZ4Mlp6tY5x93sphDGv5QOo0BGPv26Us7+kKQgacwaScSbUL8Jxzx 9ip6rd+zt85/1L838K93/ojR+Ltq+wRJyyE8s8g1q6b/Jannbug/c9OGR7yHPv7m+fqnFwy7pv7G zEPQ5gTdnBkpfSB8gK5E49C/9HF8TIt6Y7FEha3MPsh+tX9gbHDR4KuvHDvavrjE7k2U4KSla36y pCLYp3JAYqy/Lv+62NiSsVfXjZ3qn5qYVrIwuDh/XtFK/4rg+vx1sdXJgF0bYUfcKGrGKY7intYR VmKVvK+Rq9AANIS81jygP6cUUMetP46m5qZIah+uQcXktT2lVxU5JCy1kLt0hzbiMlTk2uwo6qnN BQN6H96KQuTJ5up+XYvgeguKkyd1S7QCVwRqxxkDZ+matnbqh6XbTrUf19rTbai0rS0N0HMcWKE6 fRwaOmcD0pBfgooQVUEs6O7rW8YZstO3j6uinBTFC3nicbv4smhR3zJR5OOFRUXFtF9cKNabp0OH zBMrTmJ3Tiahq+yEv/vyp0bWbZn5zA/zxj1ZWbhrQ6Qkv2LsvJUvZbYd+iaz9IMP8M/+iUV8Q+3u sjOZF//+WebuzJkBo6csxr/C+hm8bt6kd/f8adAYty3jvXN0vyUNV62epDfM0p8Zct2MPy3fhKs3 X5d+rH3Sekeo+NIR2HbfC7jwlU8y07/5Z+bJrU13zPx42bwvHvzFJ6c+xQ4cfeetbe9kPvvL212L A3jo3Q8PWPHOtDUbL9/wO+D4bDtCQp2wD6TZTvKpq3/GDMKeb86FGc6YsUmD4Km14bsQPxJ5I4qU u+isodtkkZY8tfzYPmG6D9P9y5nWU5hG9LJBB3bOyiJZisLuw0qLnd2f0RKjsd2hsSjPD8054gzT gITet44Zh8zQE1hZqvXUpsszLPXaGm6D9pbwhtiqndSsslCHx5IR2gxrk/YP9R+2f9gtvMrbeDtn VSwCz6s2uyxKkgq0LKoSRoi+sYONYkQl1Q2nCMfRYx56jIvyqht+ZYkIghwRObGFzNUtSFa/1gkm ZB+2gtlh1V1qFE2VuGtH8If5ozy3gcd8C8a6dYTaKh1VuQ0qVum+5pAOS2SZ1CgR6WeOD/9oIGgA vvDvB+4NBrS2NuSvrgoCNzP4aKMjjaml2sHVPfxsa+QQVFau1g4etB88uFowtoAqQ5qso4Y0RUaO r23mHZws7cuepGkNVNfU4XkN6f9qocFfHJfhOBfj8mIcHWLmSNnvSe2nL7U/9tRH+O+PDC4Mlwn7 zg7G+zMDyXi8ce+t96yj/tJGQNSvgb+cNM6AV+5FPPRUCR0X5PnB8bHxafH5lhUWcWbwFmGuZb71 LuEuq1jstXD+4q4Rb77F9Jg6Ilgs7BViYSpLnivStWtJCQrnR6ClCyIRJ5LBHsmwX/hN9U7tJd1G fWd/UlSpYwKG1Zd6glovootaLqJI+1GUaa1Exjmim3KVODph3q2zX39az6N3SyTVML2bqtB7qJQD i+kd1GA3qE8nl16hV0eiTEdFc2Njp5nxxIjcuNjZZsZgBiEaI2UKGx1Lpy6Z4O8Y+UpXtUNZNYzt 1xgBbOPvwmAHfEGTgGKponZcykkTSrARy6ajZGXOWKdAtZ3Ecay3Mc6RjMfgnKFugN5IklvemT9t +sr7xjX+an3mZ/jS5f2uGTL4ziczn+A51ycHjO8/+sH1mW3Cvrq9U69/vqx4f+P0HfW9uGud3mk1 V99ccm6zpPabPfja29i4x7TsV8JC0K356Pvdk8msfIKNPmXvekKfSKko6m2bDHbAgvxGtCJ/A3pU eIl7zraXa7a9aTuCjuf/I99pd+U78/O5rmIXZ9dwtOBK21j3OM/YwAxhdv7trnWuR7lH7I+Gt+Bn yRbnB/Y85EZBza0FeTqUv7NLJbN+B3Wp1BwI86G8iMqFIrxFSzquQckomKnBAh/rOh/rOh/rOl8y KmOANxrcUmkt5UBk8gQjQSOVZl0AvQFELt5iKHA4RUd4wbmZh31MaUCjuopAe/ukJNXlVKdQA41v PnBp5tdftGX++Nh2PODAn3G3S14vO/CzrX+dMOfLVc98Tkiv78/9Ct/0hy/wmB3H3um++YGnM9/f /1rm67X7qcXyJOD3eJAvB8rHAd0VLcADZEMenFrEgWSfycGdx79P64W5F7PgAjbCZGGMaVFYhoCf HWEMzSA1WJCvsfbQmCeqMUtX+58Z+l8mQ58xGTryEwyd201fxMW9eg64Te/DhSRZlAWZl3kx4A/6 iWhVQOoUUNNetzfPy4khzhfDLjsUfjkcw17FGaMRrVSqK/wtx2nK8T6vz+vyuAnweyLWOzewVwxc /iT+90vj76hbMH/Y4vsPrczswJX3P9drUM1DNw7blnlX2OfJH3pD5vDBFzKZrZN6b+vTa9DXz3/5 r64RePenAdvorBcratY9ohCRZUlCHE8bX7FErEiWKLeVaq5yaTR3TVSJ2ogStPEWYig3BmeMwyz/ F+BgsfwXlFAvuS7Hk7lmrTGBIl1z6vh/IEOvntAonlju+zRfdP5JLnX+A26FsG9bpvrljG0b1Agc Y34lvKEFPa1fyt7wPjDKzJeEF3w8SqJWQoLW/6e3oo4zYeqfvUrmP95JuWTCf32n40Y0j/pLP36f Ldyn578gTe0j6Lv039Y+jeLPHMCfvYA/CTxMD4bcIQ+pL8bXy3nYxRUVoZjLRxIoQhhAeGg9MBZ9 ETsXi4gWjJPFiSJTkopMSSqiksSiskVRjoOWKK5nY1HH2ZsyKyU3KPUx6z9mpZTRe5N5jcW4OJ81 WT5rsnzWZPnJqIIVBjUK8+GVQHLydRdBTY2WPp1rC401Bo3tdsTLoEFg3xi7rKT2LcjPQD4eCgfD gTAnqkkt4UkWJOUEn4wn/Lb8GPI68mJwsTsvKsFeoZCI4bAVBMnthCJiicVQEQcFYnGaFM1wquow CahogQFdkXBeBHBen9SDAMLR9D9qN4OwObmhZM59mSOb/5TZ1LwLj/hkE8YPJLfHbthz88oDt8b6 rcbk/jtOXkaqX8btx+bN34uv/9OHeH7z9Jaf95zbWDNyxfA1mw5mzjRO6oudtC+fBdQrpJKHVTpU 16p78zzlPBexKJuVIwpRBEKsMiCG2WWy2WUy7TILg/KoJIl0iJHZAXCehl6AYqMNIg3TdWX2AGb2 QLrRhm3EyjrMyjrMyjrMGs1lvbTqClThf2B2OcfsnVDRmxPgqA1HbSNs9ba5Nv6SOn8q3dCR7tKB kkbnp6qMvmeJZpXpUgaVGBQ7yAB841A+e4CcPXCgXRT2tT9Pxp8dTHa110BNX4fmWw4tx+FCPUDY +3CsJBIbL5RyZvq/WXNB9f5txJuJQF+XYyWcPtdMCTh9TmftQMGA0PydXf0uZXk8u8rKjW33nsa2 S4mxjSeMbX7E2PqDRt5PV5tWHhU2CNsFECWwue9Dm1ET4kuRjkago+gkElxROLgBcYIx+kub1Z9r 7m/N5v7ObG4qmMxgZ839NP9hXSeNM2BC7c5GsMrTdQ3zqto7rF46LMw0t/lH2/P1A9SshZajlmxX lmV7p65iAtwmIDlKzXjygh6TiNGMHGMOjjUK9z/D+un/UJHiT6nIL9MGilOso2i38QD5A9TuH9uo TDyMkOiA+mmcT1flrlaoAGGlOYwrQ6MwHpTtNidDI2gtIASautSFUqqLnhYcKmdBmMgWqx3JFqJY RfoGVo3W2gq13kOvsmqIjtTn3u2M+W7nmy9KI6Sh/OrWVu3IkVYagEmljPZFZlphgcQ6SGQlx0qe lQIrqdzqcUoRpiQAwSh62i94egorJdMRpBlbegHLBhGwGlVc5Q5WCCqHsB1Usgy6mb44vRsj2E1e I2ORC2lkrG7LaSPR7BB2W0QHBlKnSk8x26S6qsp4mXQnbmEAmQrpyxBxyG4SkvmF6ir1t9CU6tXq 1Q6uhE/Yutlruev4hbZF9tU22UoEudLWxz6cDOEGSrpcY7vCrjxMHuE2ShvlLdwLkugiDru9p0Dc gkBk1WbrKchAyuq1jmuxDq6lLFvAi7bZ7HaN9lO9q9FFXPvIFmTDvXYKUbkF99K9qkVhrrbhWCtR XV1mxdZ98MJ2bIWrSAtsHBiZ4U4mOyygjaKOuRrWWsjYV6NCvdAogOSRLbucFJoCNNM3XeVvp2zJ fFLYC3baPZ4GH7W6iiW2m58geK7UV129lLmqsOnVE11wSX+B1Ow54NIPEcl+yDzSIU0qnOsC5yjK n9lhV+jRXH7G+3tilfZuMZajsadvpb13X0bu7g5Hc3kYqTrwaVFDmgZRERVnMA19ffriGCAkjmPn w7gIX9fTG6jAE7HwWmbs9kytsO/cD/dfNeIx7vzZwfw75yr4Y+eiVLoeB41TQC0hvD+XtQWsdmI3 y8qwmvAv+1UvG+6iQwBAyQSwTJLdkiQTieNkC0+IRZJ5jgEoRQtTL9EjoJfooagoCiaiCR16STBE E/SGnmTykY5acdQ6wlpvnWtttApWucP0UpnpxXSSDSr1v9lg/H+qpQ4brBN0ptKpKtbJ6YZTP9ZD LKZWWbmaZz1sCDjNpD72quosl6NQQB/U9epJ7Qjow2ZZH1wJ7926Z3ClrPc2yN6VUmGA5V3vCQDZ 2yDp0biRjW2NV0p2N3zz6P6pPXlA5htkPpAeSp7Z4cn1v5kQyoTTYIEyTBUkdj7+Jkf2vXk+Ax2+ nF8Gnd14rpHOJwEr8VPhfWRHIezVhwQd2K253SFfKMTzGu+2+qwhfqtvj/0NO+fz+UMkmq87h+cN 9+nBWqHWMk4b45yYN9430T82OC60zvcI0QIRjnNFrBaPaYt4zD73UEljisKTjNJYZy79mKWf0g6T TH0mGTkZjPiGQZdkjv1ItAurGQYGG/NxvoNpIQfjBQe7uSNJOcDITmaWJRI7IVwgPPmCiW06s+mO 3q75ccYyOLV5Go17UleKGX19NVTWGznLCTi1aDJeg/u8gwe/1JzZ8/rhzL4tv8X5f/wEh277+v7f Zf5I3sZz8BMHMs/9+Whm8+7f4vG/zPwrcxiX49AubP1Z5gvDn+XbQc5syI9O6pGpztluMkQb4r5O u87NW9UIICLy+Q3vw2U26UX5hHtYYlOSWXpOlpHCAjSyllMop/Tu9M3lYDSI4T/ot7Ems7Ems7Em s/3fei7/6Y0FOuvvC0GbBqNpc81qumPMegNLmrmpEQItG4s5ge7wUEnJAzU3PlD3XeatzBp8+/4n 00N7rcjcLeyzu6bumfNapr39ZQ6vXzbhLo+NxgSeAqzaBm3oR4Wkvx5zWe3Y1Sc8vmCaPKeAt7CU a5mVEivBjWll3GUzhsaMYBYjrCYBDfv5LlewHLYndxUWlzvpfn5xuZbbOnJbOP+nXflJ4zxcr+W2 9Lx+NRAJ+zXha6KjrBPCc8LzLIvstzlWKmscD9m2OlocJ+xfOTTQ7VGnw+10OpwO1eIKkVjQq4gu mv8s+C0Wry8YiPhojXOxDPDWaCf4fChWyNjC73c47HLE5I3OQ+k50z+StD8umvMhRLNbmc1fzqx/ kUX/0tGiuUWNRVxRoZ90GkBnHOL/XzlE/K+4Gr9ky0/5tjnhCxz35yIhVHPmGCWVaoedylKWx2yk MQsdM0w6/aGckasrsu6odGj9na7+FABxA9OddsDRYKDSCUjrgq9dD1dqhW74FsC3AzrrOoUJfV5f XpzrQYAZ44wx2Th87Cmy9uC7i99+r6bLmKHZUwfG3DSue2zIX/BTKzcOe+iZTE9h3/Df3vb4h/mJ omG3ZBpwrxXr+1ml9lu4sr63XTmDzUaYkP2K/xv45D3Jb/ai4tw4a9IccGU5VD6Wr8DG1gOsDLLS ZgaEVZOwmkTYJNiEmUsvpEESVmJWTuYm8/O5BTyfKK7gKsMDuKulofmDCgYWDS4exdVJE/LHdbk7 zx6nzEP7uMgkEiaRNIlik4iz7jcuNoiESSRNopgy4WBKdbEli0gRV5zo4yiPD0wMKh0fHRsfk7jR Oss22z7NPdV/m3WxbbFjqXZL0fzEKm6t9W7bWsc92sqiuxIP2DY6NnoiORO6eyzpCiWDlmQJTiJU EnTxvXsl0VTAAVv320J3h0go4bV1jxQncELwChT/jCGSSHdLJOLlGLinnK7KtBE4oJs0Gy0tbTM+ Ib17oshuswqxcH4kJEsizxERJ4oK4ZgoRELdgzpl9fsAS9u8qDuLoDBrRcNRPALX47l4AxZxC27S 7d3pI+mjocbXWMyheIspo5aOdBdLEpXgEqru7HZCM5hO6QX0niXB3jEj8YJJY4yNtEML4KSLGk30 Ypcphq6OcRvXaCqtgV65WEq65niKZsrlQremnsvFbzXwCOmgYeoUbQWnj03HpOHzOjpc2HBBzHDn HSZ0eX0jpKx3LrJYVMzSWlhWeC7m63H7vLyPCZUIujM54VXbxN8uvfnFUSMmXJK5ceTM6Xf88PNn /r1K2OfYtrXpqcp++KPaxsWrzj3xZuYfj+A/ajfdM+6K+QMHTY/7JqX6PjP15l9Nmfnucvu6e5df N7ysbHaXS3YvvOXw/AVsTmhP0KP72LjeZ3pAZPglsVJkHr703/x8kXn40k/4+U5KCSQCvY/Y0guW FjJ/V9QYx3pVjGJSSnOKMN6NczGRE7qV4aOcA8cfTHf3cxMlz5uomDHcLHpHec8jnT1f6C0wMo+n v9TYrMLqXKij448mVdOYH8nL5PNrMyHBtm3b2X/Q/AOw5GiMyI1VXUk6avla+S2Z97bkokXl/CXy YP4aeaHjeeGEQ1IRcdLJM6LFbWoOt8mVQJzeQ9/enSSmZU46LHOi5WJ7x/QezFNNR7046h3hJfXe ud5GL+f9CQODxflMt0GJ5hLfDTWimPyrdKgRhc/5q4YaUTrUiJL2UPP8ghoxAug1GthpnS2NNmPO awqlcZkzZ7hVgCFsJFU5+foDUzLn3v9d5uzcA1duW/rhHmHf+R2fZs4/cy+2fc0NP7/z9d03HMBu aFUL2BaD6TwE3KbnCd0YyzBA5f25+FpHxO0sI1Ans7YjBveDwWxGsITYc6L/TXMugfgbIw1KYTlt NMxgaAFcREvCSiWYu/mXOtMHuIgFsViZyzR2CWD2MkNRQYJFFjARSj89pH16yFlWBoxUzcb/Q3pR qYC7oi5cQilVe6r16t3y3ZYNaqt6UrVG1REq4YlVJrkULAtWrUiGW1ZXs0FW+LVisURlwS3LAgK+ J4KbEMECj/o6qoBTPlXGU4nMAlZdKkfIuFHeIMM+xrqN6F0qJxJ8H9lECKFHnFFhhEB6gqu9QWgV TgoCuNtrdlnrtxjudgOdAEe/fs2YYhoMtPmNaaa5sV869Gu4025wmXciB/DJ33daXJhuZDcN+BgZ edSz7gKX9WGeNWLrAjD7/kdZwZ2QLYbLDN+5DJPL23/7B7y0R0Fhd7z+jfYD4EH9sXHuokV8CYuT BRCSFlLrkyyhWXQZI5hghBrtJleAPdieO8F1nGA+S4sxPgwMJRqRtAsswjPg51hJ1NzPjGRzh8k9 DlOngF3wfrPVmNfwvs4CYSUo6SxxJf2VqI+z0tXHfzW60nm160p/LRrnrHWN82sPyw87cl2tl2k4 GEh5yoVydaAwUB3iGS2MVq/zTBGmqLM9C4QF6u0eh+ChYSWXDAhHGKdVVzO+8jENStkjwvGCQEQJ 2EOB17XY7A6H6s5zuTxen98PHmDVLgH5o3Srupx0q4/3yJYoEggBH96NMfILshzx+N0ej9+lWiwR jwtIl1N1OKKa061pTpdFlf0eweHUAMSgSgLn1xwOi0WWCdTJ73I5nUgO+nxB7XILHomiSIXSA18d CXjknigd9wwEWvC6HYZBmg4GatqD/vb2YKDdP2zQ1IFfdlihZiSHGqC5dQrMXIOaznGdizfAPqvt 2sGDUFQdNKnOBbCjA9jRSbnWpdABe4NHE3Cw6wUezcWK7HBkl6oLej+DbeelUYej30kv4LI8g2Hz XLDJK8NxTPMWMH4yc/ubR4uC/RTs++YPw+Ph7l/+OnPTa5l3iiWfO/MWIF/1Qw/+rYj7rD2Y+fYf 65q5V84O5tPro1OvPPcM1axiDgFVQnQwiijTqaxk6tLWoS5ZyiDLaVFZiTsh4lmD93k+B4znTWA8 a5pBPxjzKzgHM22ZtlZ/QmcbuTaW/hx/Cfzoq10uXznc5SvdDgQfgIKjhYV6Zf4YPfUn/RIg+C5Q uJJ8idxVKbXzM/AMcYb1M5EXeI4TZckiihaRsygqHROOKla3olhFTrRw1Hr10qNclGBAOiyqVhGD QYCtLSSgWxTFwhEAXHsL8YOvZblWVxoVorTg3dBUVjWKuGuHk/sY3u3WLcDcbtOB0q3MSFBzhsHn OVOB+PfY7AdiFANTTJ9RewAsNGPzJbUHqoBm8VjgyNU9UikZYFBgqTCUWk0TYDQohjT5gHfCNPVF Vi0qvy97CnHZUyzPss7IA6Mek8UCHpEMX74l+9mOAHWGLuRf/ic0xpwXcNFJLml/51scGzHoiutx +PP2V8kcriYzeMmS+Rvw9vO72n9GuWddZibxM7tssJ7iuRQmmiCmkOSCdpPEV3ghgZFoDBTRkV5q SL0sPzEjt4gFGD+nqpgd1DFAnueMeeLOMs86fM9HH2VmSiMf/PdHD9InFWdm4mb2pGrdxwspSdQ4 kgK4EgVQha/wXEKiIye6wp72suUxmph46qcegWMVZc54RQw3Z+Z/9BG+JzPzQbGYPiP7l8xMsLn+ hjgEPgCupms1oAA/4HI2X9tcp4ED+6yA35qZeeedNDpxTfYEH+YvQ11QX7JF72axWboGbMGuJbau XSttfTx9Q/27Xt01bUt3nWWb2bW+51rbqpJHvY8Ft9o8XcyEkWK2hgGlng+82GVP4LUuBwOHu/zB 82kXeaAX0yx6OvlCHONyXUgGq6AG2nBKFfgK/KluXcsr+cpuV/NXdRsr16WmyTNTC9XV6lvqv23/ Tjn7ltsxr5UWlft6x9z+iSU3l5CScKm92n6ffZM9axc22bfbv7dz9o50N7uaW4fkG3NlklN6jM4G t7OEbLtIE7btSYoJdhY9ttvDnK+FvKjb/MyI8j/oDodph+SqjgYVK73DnLVkkjapc2z+jAkh5+m8 bhrMYxKTiBVRyzTnqn5rWKZFPO3aIjogTSddFBmWGAv4/Jma5kCxehWZhnhRC7lOtxfrdF5tNNkz uT0pVNJQC/WqwIX90CROsRhbslclizFH4uU9K1sryeZKXEmXW9Bn01v7WEKgL+EvLGU+WilT2KVM kZcWvS4eFkmBWC0S0c1sSLcx2ZR5KHYWl2FQIPpZQIZNGhFZtE20s+AMGx0Xe/W7MEJK1wQwvLhU SgMziS2+0NZhF7MIXOqLL6gtfDxV3daeOm7Mge/4bYPhAFd2pAozkadJcajBSBGl3lxf9qkoLzby cS8jzL3zejxury+e5GhirpF4DRdxVVP2ztq+/8r5V1XM/ng6Lhu0Ztlt+U3+m47cvebFEZrFV7g/ 7Lvh4M0Tes+ZOePpZP5dYwa/tHLY8mFuuy1YlFBu6n5pXYO/Yd0QfdI1PRadPLfy0n740y5hrUtN 6VX11w2/9FYqTatAmui4hIby8Vv67VhQHUVChTBIEKoLmgpIQUFhuCx8RXhuwYYCsX9elbcqONQ7 NJiW07ZaR9p7fXCWfKNthuMm703B1oKP1I99Hwc+z/vW923gr/nHCrIFgahQ6ih19xSqHbow1DFC mCZ8nP9P/qymah47LxIUCoNGVTxhu9VvRm38pgVGM/D0BGPuoiNWrFl1a7210cobGUdWJjFWf25Q 8bQZbzzJWNRqLjJipbPxaF/TI/oo2vfWBQC1bCEOxi7OMuRiwsEzeeCN4QzmTpYZtiJnLGSRIKQV 4w14M27CJzFfgKvxcMxh6rFQucFUpvIph2PGepj5ddhFWQ8z1sP0FSlvs0u9tHrYz1JFWLogDkSu 7HuRL0bZap6Rp8GOHQfObL+YWyk7wj9L0TO0UMM81BADRHf2KesdIR4NxQuLObev0+SX7i80z9tx w/YGPfPDL/bPJuVj7l/48nO3LHxZ2Nf+z/uG3/f2/Mz3mQ+fwBtfH7Pu0DtH3mCr24zInuDaAHWD +B97kS97Ui9kw4GsBS2sdLBSM9pU7uRHlduXObDDiulA/FyAet4Vtkr+MG/Fdo8k0waTWINJbP4H XasGSiZYh95/w4ioHEz3pl/qbl1pUXFBeEDeAN+ovFG++rx632PkMe5R27Pas0FVtgWUWWQmN0u4 RZ1ra7Q9r+627FF2q6pXXaX+lXD2womOmx3LHJwDU+xM9mTZAfVQrQ1oMzqGToJ/6nBY0YU6hqHq JkM6KEMyXnEU2WWGy4UhFqk4ZaLqd/pyxktF1lQBmCdgGev2FBhdOjPwdGbH9WFmmM44QmfscBVj giBjgqvDHsZuHsZ6HoZ3nqLDEi6QqiUi2dnojUJ/JjHtJBmr9rCrpV6h8oMdwQ+DQTqlgMzLLWnG ZmT3q4Oz807RrM95ZvqPs7JUSx+HfxaoAlYynTnsM+Zy5jLczWAU5Smuakf+9698nPnXvK/v3vbn gu2BZePXvPjsiln34pW+Vw/jfKy8jMny7U+FZt/46/c+PHAnYM5g4KWjRk4vfl1fohDelrCV2wba hAp3RXgcGa1c6x4Vnk6mCFMtk9314daC94UP8j4NfJH3hft7398CXzBs8RYUpIIUkIYEKTpJPcCx 7+HtTypsQ8gg22D31eFxyljbdNsX4lfes/iUXcMezm7VHIA5VsmJAHS4i0DnzKsMdMpof/7wKuvF hNNhXnAxExQzJkho2hEn1py6s97Z6ARcopxroJPTRSHBydQxxSmnSPncydDKyUI/tB+ddtqPTjON wGmmC1BCr2eCtMBlLJpgzN9n3OAqkljIwlip6XXpsHRUyko85Y/hEidFmPwwvSdFDLliPMMMCSnI eCYQKR/RCWloHJIFejrAhR2sYgFOQJyq47kYEP1egBo6Nh6ruGjuA8AO7jzprt/Ug8s+uGXW+3fV byzd1R59+ZaFz225fdFTq55cf+6ZTZhbO/JyYj87mLjefftXb3z87kGqkYaARooA0niAO57UfQUo 7AF/IS2kLWOsU7nZws2WqVbZY6zYxprquH4tpfLDbFq26yPhrPt0kO/l6h/oFb7cVRO8PDzSNSFw bXiSa05wUniRuMhzmpz2a8iLHTafb4SXhtk4b9ixQdusEU3jQ2FFQvvIi1RKTGRv1VlXaSDQD+YB LPjMWe4XLQvFzBqfbgP7iAXgbOYSFDZq2NGWt9FbWYq7ljfZsC1YQBOYEslyun2VmkEFuMBLdcME NouvzADTXO4s4wOtSNKLupabfW1IvYEA0U79Hmb9bmBFmPU4yxGj/X6xhkmn2KjRcTgGPHCaxaNr OqaTwQljQllVe0NVbvpVLgecWjbzTFgwRnDdUoxFA3GMTQQXuev3dftu79eZ77H7zx9gOz5/Qtm5 cvL69o/JSLXf2LuXbMVjfc804wLQoSrukvks828tun3fDPzgqgEznqc6Jw/YoVF4D/lwiR5xW7Aj UBroGdADcwOPqY/bttrkoK2LrSnQGuADtFn1YEF5vmzjVEdYwR6ScufxnIiUTW7szuaxNszT+Vxi NmtMn2qYmDziyAOYZTzs6tWvnGU+pMIF5RsQDuhUegO6DaQ352x2YY5mIZVn1C3nbv6QG61z50br vmFqniU4scWqwM5nc/bRM/7AfrwPxdBprCDTJ+3oC+qdguvEpK4t1ZY23FO6+lCl08jFdGtO0SKJ Mti9msUVQk7REcLgV3ZdvhynQB7nUUerjM75AnEEnKYw7aELhuzctCkveNfCoRNC/XpfO/DwYe7R 9Q2zywePcz2hDK6/Yf35aSB5V2RGct+A5EVQV/wbvd5qFdzdrAn3UOsgt2jJD+R3sybd3eKV1j7u a6yD3WOlWusM61nlnx57j3i34svilxUPLd7QbXM3qU+sT0l1t8HWwbFBJaNjo0tmSpNjk0vquzV2 +7j4ROy7+PfFTp9X9LSQHc1dwnkSU8VaFPVkirgRtaIj4HS2kKW6JoTDDmVQYVhVvJ6yRFnnpZ1+ MOcZndGLWUA34fcf8WHNp/vqfY0+vht0CRnTjaGxj6GxrwONfQyN6SII7Og3BhrTq+iiCDk09hnJ aIw4a8r6WX0G45wFDpxAhQWMmQoYMxUwZiooet1x2HHUkXXwBY5qx3CwNIx1+RhWO5iMOoKUVxyF bLp7mD7ZWM3EwbDZEUh1WxCj8JwadkFMG3IDTFpnhGYQzcT3NF0j5HhuBuhxI1bfACrcR5PWmS9R bMzypCjtA2+cjR8lO8+Pnrbd2nvAgqVr/Ha8sOmTkzf9/p79i5+f+snmX37zyPNLl2zZtnjRltrg yETvKeP7Nq3DVZ8+jPH6hxvPzzpzeNFLXNfft77+7q/f+DWV2tUIcSfYuMmDe5EXRMrjK2dLPjHH K8FXcIO4fTaeHfL4AuU+2ak63ZyAkSMsSG6ropo6VzW7m02O6cpCYQmLXtanPGvBrRbsZQrXq7Op B11Y6aYda6EerJNNQmDWvCVIr7OwKBFbZdBNO5qNFbJ1O+i0BbZ/eg9LDBzGBnlKyvuUN3lPeslc 72Zvkzfr5b3EzbrazbrUzTrfnTAypTSo1Um6CmQUuPcY4llSRy44dVb3MbTgzQTeTvlSZw0/ABEG D4S5HcM8V47wdzbcGlJm9m5D6tTFDGDO2jF8ABrDYjhhF+1Swi6qIWyTASEQDT0tRym6wl2Z4Rp4 vR5n3Mm6XvQ4Vzff0brwlSHNt8wecU8V+AE/PJB+9vH2ieSp1bePundp+2uADmugc6to5i+S8At6 gCgXwuu5yXhKLr543gw2nDcXDTIInnlILB5vLDzESpGVkjUX42w3Tel2c9pguzltsN2YGE+Yo8ax UmSlxOfip+fN+KlBCCbBntyfjQv3oc0/3LLBstnSZGm1HLWctEjIUmCZa2m0bModOmbJWpQCC9jv Ek84i0hTy/Tu7Kl3YCQKIq+IUkJA/CZ+M9/Et/LHeLGVP8kTxEf5I7DH84arR+iTc93Ps+7nFfp8 nikK3lQUvDmAyeqpUFbgh8k/ZoJ5bKlf2tWpzqv8pud1HkW++I9NlIb+XtPc3Mz/7fDhcx4+ee5j KqXQm9wZmgFP3tjDmQNoF8bXzP76Qe9lrDzAespYEyxHM4NCHCuOt3AO2z+E0yJnMWfHGTk/iklY TILLrR8ijhnD3aoQlxjNY0Hlk7tcxTTIfLIZti6BHYixA/oKOCLyvMCLfS1X8kJC7K7UKrdytygf c38VpedFHBeTUkKuFPtZqm3DbXV8nVgr1VmW8rcJj1jeEP/AfygeF7+W/iX+W/a4FEXgOJ6IomSx yLBjkeWEJLolSeR4PiEobkFQFOhung7R8QIddrFakcK3YIduEXgWDCyU6d6gKPPGNCNxbgMYc7ms fgYQVmOdrQQyxp0IO2iMOJEExmBXVKPhIFLQ7XovBg0sNxoZKeeMQ2hMAqCAuXiI+ZoooNr+Erty WmfFQNen0XLmAk1FaDhNUxHAqesYcQF73VdJx/jo+mSw9bOFCyVNrpKrOFbmxqtsQyy4wLKCIxa/ jWZagvNnrGWmK5Zu+ZUWOT+/SqST4PIrYfP+zijb7IjlVixjabINKJViGUJitnVnjGVk7vTSzWc7 tUrR2LA9lW12WM00W+pm0ke5PuWx7PbC09zuKlbQ9Kqdfvrjb3eEjMtxus6IrV1IoDAyM2ksHcex BOyOX/w6Mwu//lnmqWXCvvP7cVNmYfsUUrA4Q9cKvgsEoC+bw1Cj2zrj2EXYlZu30AmpLkInY3me zlh0Ef4YI9ACQxs2T6FvP2O+QnmFse3Zy9gaK4K36glQkw6hQNgkHBX44VCcFLgCYa7QKGQFHvSK QjhD1dA7MZXjATtvE8Kt6CSwUie9c+aC3snvpHcMtjIsVDlnnpppE9msmUiRgx80jL8Yfij+sPED Y44D2/vxH+2Cu5rZdAfDDhCTYE3Gyed7UV4OUrROmZYG4TSJfLP5wiYRMomgSeSb08rDJhEyiaBJ qGYKgc0k7CbhMIk8037UTMJlEk6TyDPNEM0kXCbhNAmbmUYrmwQdKtNrrLbyBH+cP275i++LqPCB cDpKfHI0bvGHohaOi0fCoocafhIW48GAphxJ4A2JzQmS8PmC9sQGJ3byLHzgZ6EDFo9n4QM3WyAl t3gaUIQFEVQWRGCReKeZStoplIDTesQvd0pAZMzqT2wI4RB7QKjjASH2gBANYznpA0LMSgmxaFOI ghUzl0IqfVTIDPqH6BO6IFIWZ7ePM7CLM7CLJ/ARhGlojRQgCnkcg7z8/4A8Fp9H3pxNdN70nk7p bmYcGSxpN1CwKNGCF+2KXXmxhWxESpkx3Cl+mu48v5nut7Px6IZ5iDpWoEtraC6E09d5uptddecl 3aozhF02j2k6mT7vf1O0dFVGlqnlY8sQMcuKOV+dbaynej8/a+FDBXe8/eSLu+ITLpv78+baKUOX 9+eTDw6beEPtvu172ovJEzdO7P/gs+0PkZ2LFo149P72j3IW9ZcgSV68Q88TODGPbNFatL9yX+Wd 5E7niTzVk4XAcrdp+GHtiP+YP+vno7Lb7va6wKLGotem2Oyq3WRauylx9lxWHFBFfmZF+5lFbWW2 tJXZ0tYOW9rKYMRayK7IrcsgwlW0r6xsLJkF15Vc1P20znSXlZnrVgz/1mF+ClvdqF3tP+knc/2b /U3+Vj/v50iZx8v4xst4yMu4x5swZpU4nbnJTj9pTis/MqedncxpPodurbrrx+b5MB9bPafjzzCw TzET+6ITKWNivDGiWV3ddsHG9opOiyIrksKJWtIp2kPYobhyDENnNjZQJcoYIzfE04krVj99y6f1 T43QlOaus6+a/wKffGj7oLk1vZe2zyerbppz+QPvtrPZ2QOzJ/hi6HkbCuDX93jY4rZ5xmpsbM2y E/pUSgXYCZekBNQrxavksWKdPF2cKcvlWn9Xf2+Ff5A2xDXEO8g/QZhguVZLu9Lea/1zhDmWKdoc 1xzvFP+t2GMRBdt13GhhtHKdeiM3VZiq3KgqvjAvOQGoOmeynTJz287oecwZKgoxHzvEWEfqWLZb YrHOXDTfHJZhRG7agbHIWm5qAiNadXtRorynhJGkSVGJky6sANnrKKAVvWIODZMBbWfsYjeyeBjT 2IuQaqehGbYmA2KDCSjMuIMFwnL4wdASsVUQkQ6Po8BEEAuh5RZiZ6uJoF5BGirLLcHemRO0hlQa zKz0xfxhznGgMVGWBzBKGGW5QbjBwlNzhV6VxxZCRLllETu73gOfvfs3n2Dv7X9bdzTTtnfn6lU7 d61cvZPk4eJ7F2b+0n7ob3fiCLa9+867v//NO29DZVdnZvIx4AoXiuCN+gJV665dqg3R+OpoU5QU REvUeH5vT+/8K/LnRjdE5f6+/qFrfNeE6uTr1Am+CaFZ8mx1pjbHNzvUGn3P/an/0+B7kePu45Fj 0WzUG+dTWspTwffXBvPXaOO1L6x/y89oVqed84bpUJ3oDdutyB4wGSJgMkQgN3EOqKIjCtYUXalX GhU+ytgiqufyEb808jQUv5mfaHoKHTPqjGE7hfJ2BctVXIDzykhZLgxuBMCNYHgCoZ8ejzOH4bRO w3DaRcNwp388DMeG+AHw2TBcwZV9/fiicbiOYbjUqeP/OQLHhuCclZ0H4PJMfeD1uNmSWsVOrlOP r362/wMz1hyZdcvR28ff18P5/MJFL72wYP6OzEzhF2tHjlyfffiZzLl1Q/u3n+OePXTwnQ/eefuP FA2uyszkjkG/ayiMF+k3WkmKdPVfQoaQ/6+9L4GTojj7frq6p7tndmbn2mv2mtl7YZHFZQFXVnZA blTABWQRBBVQDkUEbwJLvOMZTRSPCBJPMGFZEBY0LxivoEFJAhhvEo94xGAM+kZxd77/U929Owwg MW++3/f7vm9n999PVXVVd3XVU0899VRV9xVevSGzITImcnvhqkJXbbg2r6FwaHhoXmO4Me/c8Ll5 MwqbC3fre0If6h97P8kJ9BDF3qrMOtHPO0oM904Rc8Tr3jdz3sv6OPJh3rfCr2i+jNz8NCNdz8jX UNnZ6X3Jqe/kuS7b8EY8DeJXAv64f4a/2a8VSsNboaxxvzS8+TsNb35pePNLw5u/zVrbx36uDb/1 rhbdij5NSrjF9hcTkr+hUHrYjEfyDFiplDfSwmZIC5uRZY3RLPt3QWGqbc02rSXZ1Ryr2oH6w6uW FipBeyqsv21KO2S+o1fPuyf+qmP/gj8sfX7h6vaiJy5f9Mi6Sy/5ecccYQ48TemtGKs6rn7k1m9O Vn+xc+ezL+7e+yJryteicl9AvQbpnfip1WEloCklWq12staozdYWa7o7aLpNty8cdPtINZU02RDJ 46683VTM4lhYCYviQz4wYRXX0S1TnSOEf8aDSV2pLoXlIfqXZZzSk0ahp4VGPHck49T7gWkHLuZ3 KnB51TkvxqbAjuvT5T7NaRfzazSsVmEZpg30g9euHjSn4cyzBg0ZMvCsjEKt/MGFI098tGJEw4yL 23cjzw2Jj9T1KJk+KjQfy3RvKbEReaxMerOw5ShPepHuAedtC5ajxHEUO44ixxHjR10mrUzFGcUn uke7h5ZOKp5VvMR9q/ua0kfCa3v9WvW5s3NzsvuM6bU325UnJgoRqFE8OVPNqe6pnqlpU71TfXPN ue65nrlpc71zfRvLN1b4eQl/aY/+pVM8TWkzy2dWLi5ZXNpceqfnfu8dlXf3+mmfhzyPe39e8VDl hvLny7MqnRFEseMocRyljsN+Xt15BN15KN15TJ2HSO/EQ4V1U8yKMq9Hy42VZ2ppvQty2cheHOkl pygjDZGxkemRdZFXI7o/Eo0siLwb0aKR2yIi8itwQCb4Uc5+xTM4eoA3CweUXYogJaDIN1xsyMiq lbNigfRgraL0nlowv0AU5GcamrVGSNq9PnRsWx/Gw8xGWn7vtGiuklsaiYdzams4eT85u5JjHbm1 RuS3ZCIxThmJcaqItLFE5PwVn0XdbxVnkpH4YpO0TJX2xIWezK/b1VPpyffk9D2dzVk9HZnS01rf Kx0HNvFVeubKHBRV9KydUbO9RjTUNNeIGp7gK6Uca2gi+T1mFb6w3mfN+ZLcEuW8xSQXxkr9snfx y7z7Y7Zw+yZeLkWe3GxuW/jlQk5/8buOAShyvD0fBymU/BomdMJVn118mrMMqapqIc/KJQ1kPuM5 +yr+9MZCuQiJx+O854RJ5ws8si09NV5xXGGJK6NXeTAQCoQDql7si+WRu9LIU1zH4VCYAW9Rekke FZf4vGYPT55SWeH26FVaHkUDBazRWq/tkAc5BOpZtXz5ckqSmGyFnNYVcMiHDirKK3qLfrX9Bxy2 lQV/vFtRzkU0tPpvvGrJ5f3K7nzhnrGDT+j548Yf/GpKsMW7aM6SuVlZ1XnXbLt70pwXfvDq68pJ +fMunjX0pJKcsppRy08bcUVltGrkVeflnD719AEl+QVhT2nfwUumTll5xhMsW0sTX4iernsoW4ny Vw86nHdzdu4y6HDe6G45dMfhkS+bKK+V32FrhKM5opDi9XkUlbIC7iq/B7qQmuYPFFOx4jtEPfFY 6olXSRjmMPewGcZFRrNxu6ERlNpVRoux3dhl6HJzrr1L94BkVrnBQS6HsUZqtsPet/uN5D1Wl1mF YtOrrTVbgwFjq5hLOUr/9bNTrDbye1rW7MH73KN9xmsyuUcL9u0b2JG09a8s25rJ5wnE4AD5lQG5 u0MEck+pP2d+r2uu2fDkk+GqysIHVwYGzVotzr1ZMeZ33HJz+52n9splqxpk9T7+rrdy9RbK5Wnu zOxaEQtn8ebNz+ORUEZtVVgpNcNZXiWclYYOLIjyo75Zzrg0y1EysjrHpVllOdk8gMyVo9NsOS7N DsnJu85Vitmy88ruHJFmZ9jTePbsTrY0V2Rbb3FDkSWyle3ZSvZpuVyxFTwYzf08V1yUuyq3JTeR q/EiIp57klXp9dqTTp0dKX/rKebe5d7n1txOR+ru7Ejt+SaPnGWSi53lzJIcjbrl5I77tMghhjV7 BufwYafVqcrlXfXOyybRmHO1QLrP7+MtAfxKKww9NW8e+cxgHvHAs2fP5dBTkNJel1FRLnfpZMum 2J/dasOSPWf9fGwgbWNa8MLx428duPH+jSMvGNtvkbijfcMtx48Y33jbDaLu4Buo0VyeyUONekR/ fvvHF/abGNNtRTB1u43Iso2fna/9/zwum4IIJK0Gy3aZ5DF1Re/cVFMq31RQXZW8t0Zurdncz6VQ cbDOw12aL1jnzgrl15p8ELjpBlDFph62urkLi2qpEgc5eHAXl9VSFg7wvRFfWtm7lmI4+L09qNJd 7qmjfp6RNMIzSZkkmszJ7tnKbDHHnOO+nC5TLhNXmJe7L/Ncr1wvrlNvNG4wf+T+Ga1w/9jzBK32 /Io2G+s9O+h5zxu0x/NXes9zkA54euFxPDmU5amkcs8Az1iKe9yueCir1oXCqXU++8Q7inTW3Zhb /XIDFsmegcuCw+QIhEtFhgqXy5vGq0zfrkLZADurdlZRdefWowEewzTL3J4Mt9tDqhBl1o4Pl8cD 7VBu39ANj1slxVXtVbzFZjwetz4tqeQ9GXc1u4QLrrg7JuJKcdonv2e2/Cw30j6tfVpuzmfvT7Pf t9s5lxCsO/TtG7zs3V7h2vVL3gHk7KEI91WUX3bM/6/3y6I5VX/d0nGhVt5+zXkLJlwqbrBmo3hP xGZwWsg1nfdq2Jxmjevl5G+B15pBYXOstF+6rOk/uY5TTTK8f2JtnAjInlbX7d2h3zh2YHvjhNUR h5wTZucJQ7dNyPb+CYvZA3Irka7Z02TfdlnPkj6nF3I2qpmdJ6wXdnucTUbW20ylhl5sn/jImWiz X8sfjFmn7R7oHWfq850NXU2Iv7VxwLLJGdbqbd0eTe+WX2zSrFeK80qzmNc6sX1jujUXuT1eza5g XPo9QVUhLxRxRfeDZXxeuXPAG1SE5tGCHtvabPVFQX6d/c7A3p2B3fKlPPZGJckCTpefB3mXofTU enjE6OCZwVuDajBmfYHH/laG5jj4KyFxd7SoNpBfYE39xTdHS2s13esO63nuSMilkaanudPSzVCA wmqGkW/mpRWkl1KZ0dOsSq+lfsaJ5sD0oeoIPW6cao5JO9k/Ijg6dKb/9NA8Y6Z5XugK/UpjsblF 3+rfFPpSP+iuTAtWUqWvIr3SXxGqzjiBBoQuM68zV6h3ex9VHhOPpT3ifZI26VvTf6Pt1V93f6R9 5P9L6ID+jTs/TW7n98pjQLeW41vanLS62W07z5Pu10IUNA2zzPCXpbN5It1QfYq3zNeW2BsfwH2C D01UvhZM8SkZYd2TFiz3VAUnaKd7pgbnB5cEfxT0BD0aGixXh1UxqXvCqqsOVFs7iwPv85+l7eE/ L56hyr1ihsvt8ZhgZ08gyAsYx2xwUQhK66j4bI8/PfZs0DBjRjAUqnIZGS6XkY56LvOlZ/h86SYG 6VUeMwPJeQOZLU5IKEZIM/1Bb7pPZi+EfpTfVcjyJeTnN2p4Mr4K+BR+8VizT/W1KY/GPbGxHmWB Zxnv3hET4+6xQWVBcFmQN8lOjKcFXMoMObelQgI9+qTyVfir2VIPjpx6YNq0HOix+GdJNC3nyJvH bNEUlMd/Ye+YkR6oZ7CbMaYl2jh5oy/mjYmnE/sw1tlH6YldG6mPP4Z2vK/z2wNNY1pqG+W7r3at N/il6ggoahzT0lcuozUT+9YbMSs0ZL+FiF+PsGsTRgG4NiTBrlajD1+xlU4QW607dV68M122TBdM 7NvgiWkxOsHemGa/bGH3plAd9QJ4vjXctaPImoPj5iffUHSo9n20H4tkKZHD2XJPm1qhKmM6ntr6 eIPW9/EtK/udtGldx8anHu/xGkT0fe8HXxIXtq94eaeYffANseTJb1+FrPZDK/g7ZHVAKPwaJVtW BzrXEMQ9XVtz7T4/06+k6Zpw60L3gbH9csDnr66SvC1fd5q32R9S/MUROUscHxepm+K/S7vLvCf9 Xv9213Z9u/Gy3+2PZ9XlqmF3pi830E85MW25cmuaWR06Q2symtImp9+trPCsSNss2ry/SXsp/beB N9Q97t/53gx84Ak5bTTNS6GgP8cH/VB+ZyGdXX6dhI88HqHLtxAxZ1VV2dsvZ+u6aphut6Lrbt7b Bs0b6pdP8ft9gTRogsKXpnoDHt0v/J7AC/SCWwTKyJ1B5FaF7wWf4ivzqhler+pxu1VV6BhRer3k GRtSQqN8S73FHv/Zuntp3INeeHNcH6c3y7c/nxxPj6lLRfFYFPao4JLn7C8Syo4Z/XLgg8CBz+Sb 3LqahfxWrM300+yvQtX5/debktmtIwi3gHqz3uatjek5BXVp8qVIBXXe4uw6FWB/a1FdQO4tz6xT iovq3PF8550eVU1yVkPOwbMX/XrfbO7hB/DMu1qh+JVrOu7508975/cq2/Bax4+Vm95+48SOj0Wl 0vH1iD5D+h7s8La/ooxu6pjGvX5Rx3j1b+CkXDEP4+kca2mVtfZdjgfk0a/ZU68H4tWWyV9OvMqj 14phTQLIo89S2L3OlK7FjN5kZizwZPjVNDU/4g/paXo4HvLH0uLemM2Ukeqq3Ldzc3bmRgJMpD1L dnN5G/z5vBXgnfgF+XWVGZP86zxq3BdHzccq+9QG+GB43aEsX06oIq3CW+Hr7+3v65d+TzCtMlQZ HpnVFGoKN2XOCc0Jz8m8Qr/Ud0XwyowrM6/1/Sh4c+jm8I0ZKzyPpT0deCq4NeMTz18yvvS1B77O SOQXOqybFU7Lz9P8Q/3X+FV/pDP7lr0t1LlfeIDf7w1AtkMdjGSEw2UhTwY8fi+Ed1maJyMtzRPm TW1pOl+A8gP5ojp/W77IbxMNT/pRFvGMNjEhntYQiofE9NC2kAi1KUM2+ZViGpbn4VOytOIxbx/v WK86zpvwCi9ibKjmbRKiYWNebAkEOQqvnd83Dm7ld7nlBA68H+Hvr36WmxP4TLoohweiDuuayWtT mHevl4wKKZ0O6ZgD6fgUxu4fUVriIyVZNmYk3tk0oM5TPKAunV+mllkXtF8/08RDKYJiavNpknpa Fa6wVkQOkHt7bfWUv8lZUrwsY2Cv+pHZwXJXWscFv367qjha9d7GjvmDS/ssmVTbcd7jgcrSvHn+ Aq2y/Z5Lli+5VMw7+Jt1Q5oamZcrIRV3g5fTlWc2KZ3vd7MWiYTaxA5ThJQaa3ftK3E3HMqgQrn2 6dfx0XD0EJXu6kCdUucZpQwXw81R7rGBqcoEMcGc4h4XmK+cK84157qvUhabV7lvUq41b3R/rRzg L0iUKz3MKned+bD5mmJwq90cyKwV6C3cvG29JFSniBPdHmF6PGWKQG8uFH47vTib93PqnrN9ZH0Q VionVeke0ab4N6Jvd+lPiTOJyGAbsJy5K/atSlcoPZ4+I705/fN0l1R/S/lU+mLyLFWUdaSMpQWU IJVy5HxbxB9YXMTii43t1kol/mD9wvr3q+QyZ/ndiqr6wAcN9e0fyF0F9vAikP6c/Z5H26aEyn6y h1Jusu3RKj2TyxK+X2/mUuSitF4wu7BJbsPlrvmdVj8Xgk0+2pxX5zaz8k5iXbM1u856U0xWncgA crO6BBwvJeqn6CX8VhDF6N+3KLNSPLRocsdYdWb7MwuumKt8eodq6ndc1n7WVe77+A31+1FKIfnN cIPSqD4e0l1C0Tz1rCFpmurx1GO8FWk16qHqRDar9fSy9/UvWaa3858txgOfZddYnxMvsrF/p/LO TuXtV3bKHwlqVP8hprj+gHtk0x/jU1dG1kXEfmN/WLxrvBsWrxqvhsU2Y1tYrDPWhcVKY2VY3Gbc FhZLjaVhcdA8mCHmm/MzxBRzSobwmt4MkRE2jWyvP41U/9fp6tci3ScUb72P6vmjdOPi1eEFxjLj NkM1lPAJGfXpPm89VL14dm5t+iWKcYJZLxSqV9XbhCIiOQsftayYPEnGb1uRX8+VLmqYVt9e/1ng M+spra+44J8CO9j6RBcvXLhQWWj/lGlKZon8YEm2rhtFSW4l45lYzzN7DahVlZ84Lu253z18Xf24 HsOzzzyjy4WSGqF+LE5z7ZAl9Wb8NFlSn5ufZwjFVDLEPmNfWOwydoXFdmN7WLQYLWGx2lgdFncY d4TFD40fhsVFxkVhMcuclSEazUa7pDDIUyljbZjLxutDkaWjsBRzrcEBfRQUoKB6RUn313tRXhW+ 7EHonbi4fJcIgVpHkVUQvyphriwt/swMzyXWy6J6PyDd8jsu/Ml7hx5aWJ3ltHAhyo0/Xt+Xv+LI H3UZ0DfJfcYz0aoze/Xvp/7RcWj/RAENHN9jRNb0xi4Xy6356sfKSbKsFsfL/2C8Z4j1xrOG+MJU 7jQfNMUi84emmGjOMoUwFRMlYD9woXxgBfyuUOfTyceLeH92RScz2E/VbtW99TzkVDvXe/IjLDlS bjmPdxBpQ9QWtDAKFwWL7lBbvh3H4DnRVrpRK1G/IR/lIWpN0se/+mfzqhtncq5czF2w+9KOjk2b Ozou3b1g2i/P2Xv33XvO+aX6zcW7L0aYIjYv+sPFp5zVctbde/feDYL7dl075cpi3oVd1zr0CpCZ PNdGrsi98TffuGq6v/5LM8/kUFr9XkVPpi+PG7jpm3Xt5wXI9MLrRnyF7HTGoI7T6OQAfbPumysD ZId3/nxNuh0k6jrRIl6js7RFlAmMMgroMtckmqxcT1PEGlrCUAsorj1BFyPuGvgHg27ltIg/EXgX qAcmAbl22KnA2UAj+xF3C6fFNS7i60i6iKaYUVrgmpRox/3ucr1Is4EH4F6tvUeP6XV0AfwPId02 jWgAx0Gau/Q1tALh9+P8uQh7AHQy/A/CPRXp+thut3ELRZgCOsJ74Do32c9boT5D/bVFiT/hWZpw zdHAdbjHONDhwBjECYMOAa5XXqQblBcTq3EelK7G/a/ncGCoTUfiOtfifAPSlcJ/Ndy5yIcO6geK gErxBKGroKdBq/H8Z1jPDbxI5/Mzdz4T8m/n6XBYeRyTDNzzV0CJqEt8AOpOylsqrk7BKLUvNYPO A/KA8WInXaCdQgrK6x7XB6QywHlcTu8AJ2kz6TT4FeSz0bWR7mU/cKrEokS7dj+tUg/QCTh3pX4X nmMmyvt44CuqFn+l4/QyWgb+GorrLwcewDU/kvwwkybg/r1B+2ofSB66DrgZ99rvlBOXDfzLUa+n 417fcotA+kZgBOqlGZjP+cH9q7nMud6VSR11iPs+4kxlIDxbAs/OPMlpOD2uVWbz4eouSqsR5xaU 6z5QDcjkPDiQfGYD517AdSKADhQAvYEPgNXAPOBEYAxQiXsT7qtKfgXPMG9K/gBvuF5EGSJvkmet Z3hA1qfVZh60r8X3KdKfoHk2ivia3F6YZ5GX9c61uU0xzzhU8vc8yfd/4+dknuqkaHvapzSC8yDb IHjLodzukGduD3eJiXQD6L3g46uZZzl/DuVyYV6TZYI2YdP6pGftI9sIKERxic3rVzvUKYtOej49 hGvO0M+BTFlFI7XFNFL9MZ2jfU5D1R7U29UHYXgexG0Rn9Lp5nbqi7ocC/89KXQFw9ijzHVtx3Ou RXnuoZ+hTBdqe0SxtkdxudYmPnaRssO1ViyV7sNoKpTt1jmmjORz3zf834HY61oLmbk28YlrTyKB 57mD24TxqdIHiDkU4a1AM9DTrFJWmPOUNmMiBXSiA8ACLU4nuuI0QNuO+smEnEdbQPhE159om3oL +q89ideVZmoWe+g6I5POFndBpuFeYi9dzeDrg16UxEeH8FwqLznU4ddUyjLf5qkoqI7294qN9218 BXwJPhoDnoxw38DyWfYPkNHAdRa/Jr7p5M8d9DDoTQ5/pvDpvBT+9KbyZSqVfQvku9NOkY8bnedn +cgyjmUkyzmWM078VJqU/kdiDfiY5fBOmmK362Ibo5HHP9ttH3IY9X1GIqEPTzyqb0w8poYSj+k1 cP8RcCUexXNf3tmnTk502P1pD6cvtcIpzelHXX3pAluePSTlzRf0E9mPTpL5c+vraJnrIOodMlDm d5XdBlGeyPc8bQbK/F66Gc8RUa9He0Q4MJXLRNYFUQ73C9wnqj9FOXNfdAtdrb4JfYHT9qWg7C8a 6AzkfYcMQ5/KlMNcZ9Bq/VOq0SZC1m6nmVxX/BycH6578xLymZmQE3voeO1xxMkkD+KtkmUQp0cl X3DaeVCpUBbGuWSAZ09DHL7egzJNnEJ2eTwky0Kmhy7CPMxlgWvqmXS61Cc+pZWuiXQG2tCDRjM9 iGEqoV08hms8jHQTOS9Ilyv765/SmWhfN0A23QCZQ5L/pyQOqmvxPJdDrgNqM8poLeW4mlGG8+Sz D9UsGXs9tx91DZUzj+g/hRxmfeKn9COtiobp8+gWhN3igpzEfW9C2DVov33Qdm9E+qgttwn3vhHh nLaBdRnWEbi9GHEK681SDyCZB9ZTcH/1Y3pQHU03gI8Hmz9FOVxLx4GlWWksBI63IP1LbdxsQYYF LKoUqQH6AYeLvvR73CGNKMF96BZtOc3RJlGNejzabpCO036Htvo13af6abr2Et2ntdHN7NfCVAmN fZy6Ebolh79K4zhc/B7+FTRFq0f6G+hCbTotUteD93aTR5uNukY6163gk1Kk/wLXtaG8R1PUSWhb 18H9deIJjifvsTFxBkMbScfJdEmQeXWQkmcxBk81GnWK/LL7kPwir535dPJ4hPzJ5+TrIh3H0e6j epTTW0CZRTvGi1toLbBKvEEnq6fSFcpjia0o1+EpGJns1/opS4DeWj/aDCyHuxfofwHrLD90t370 JnAtrv0M6AZdTqJiLDaE+jNF2APACuBl51wy+D5HCk+GKy+x9RD/k+hrAOVAYisjNT7KuT/u1187 KbGVAV4czdCXUYZxKWWoFQgvRLoUvysP7elJKlUp8d/HytN3Ab8+SeUYT35Gpz5As/4FvJVEY0zt vuHfztu/C9TvMmCaLN+/UabFQ5Su7E28BTpJ2UsB9RLwIAD/cfCHnfJ06gnhd8rwlPoDrxCXeWp4 qj+1Xo/lFxtoejIcPujkhztoEENrQHwg1W/uoEEM/Xmce/5wv/boMTCFeqr3cp7AgxWH+/WxVMEQ pchrLqdBmwM6/a9CRgAcV6b30QgGt12G2IjxGtB5vh8NYySVa38uV/Ve67xTP069pNYP8hfXXqFR oOWgdaCNoKMdmtxmU9ttapgjS44UJ6Vt9DnaNf9fAtrOS8CLwAv/u++lEHgVCAD6W9BDGqBH7oF+ cibvOG2HLPm2GngEcmgC6GsIQ+/d0QPwwR1E2HmgPyM6+CXcFyN8j4WE0PJola1XRhC2yU5r2tdr tNIf/A3RNweAdVb6g2uAuXD/HUB/fvBt0GdAVyD+J0h3DeivrfPt0+G/FHga/k/hnw9Mhvt20EzQ XkAYCCH9XQzWRw4bh/7H6ZHHH/8qhc5yLvIZZZsX6JLUMcS/TJ36PAZNHWs49X8smmQzSKFWOWDM 9GfofS3JY5/vGuM4FPXZkQxtYqIdOqWX9WjWZVl/lvqjTeX4TeqxuC9RhkNZd2b9lXVn1l9BH5Q2 A5fMz0Qe58t82f1GsmxVDtADQADIs+k8xPlaVCRegezxg7+/xNjoIQb86cAkC4lX0Xf50ddtg9z9 EnQn/AWgXzp9miNbD5Oxx+jT/tP+79tH/ht9ao2N6Sk4WriDE2yMYqT2xd8Xx+q7/+2+/Ch9dHI/ /T/1O/28A/cgqmEY8cRWRqpeepgecAz/sfTc7+tP1Tu+tz9FL3H8qTjsfCrvOfpMLuV2IqXdfV/w 2EJ7skv3d/KQ2o4725vtRxkNSwbkQKXdh66GvID+nygA0Ecl7kDYUvNbqjF/QTXwPwmg3+z4DHQm nwNdqdzC9m3+in3HD+EPaDtl3Mk2Zh6Ln1P5lvVzqR+izKQcvJ3zT9XAQCAErAcucOqax5C49+sC vS6Pc7UpiS+1V4AUHfCYtB8tBH4Bvx9+P2Rxhh6E3I7To2yPB/WAeiDfx3fZ+BLt+pUyzmhpW15M IyHnL9T2sO0r8Zy06XUQf9uC51GuRh8adex08GeybciIsb0k0Wbb52boX6AfPAP9oZv7Dtx3kpwT mqexHfcL+omaRkNtG3KGY0tm+xT3V3pvCkg7RrId+T06XptKQ4EGzZqnmsj2F/UDOVdzPdvd1dPo aXt+q8Wzhh5wv0gPmDNpuLlMzjfdpd5PVyPsfuNWul+vkvMrE51+lfvEI9j+2JaZ22nTtJ85VSeQ +ZtKp7A9Jvm+TjpzOPrSL6QdyrJjHkO3QR//I2CmNV+R+OrI9s7Eb2275/l2H39pZ5+faqefSuPV pRj3OTbZR0D30lnadYBdxql5ce6Fcmk/mi7k6CZwnyFtfdZ8D9ugwknzcMNlOX8s62sU15nLhzbs 5/pPbNGs+bkh2uWILyii7Qcs26Ocn2PbMHCGeB3xH0AbvRBtBTyo3Snn8K6xgbiJR2S6+da8md4I NCBfs5FuDc8dOaBru5B4X5tIP5KQdrXEapGR2AJ6sXhZzjH67bnAiHYzTZA2za45wRytUtqtK7UJ AOofuAL+UvnsNpVlFUc6P8Z1/Ixsm+tNhHOmOtC2kdpxjc003IiDX9NouGsDlaoLoL9sh6zLR92N Rr366Wr1z1SonUDnqkGayVCGJ15RPgWFps4QnyD8ddAfw89zv6/RWc68mmWfpoMSL0FXAOy5XMYs hlijFNnzhE22u8ByI6yONkk411hDjyQB8RJ/Bg6Kn+DeQ2imaMM9ViEvuI8aQPtLAdKcY6PSvs8I 7Qy0sUNxciqQlml1KhDOtCwVdnhuKhDOdEgqED7kCPk4Wryj5eNo4eWpQHj5fyAfR7tuSSoQXvId +RuTCoSP+R75OFo5l6YC4aXfkY/TUoHw01LzAfmEcWzHCxibPgH6R7u//xj0FFBwX8dzcGN8kZht +/9ox7sbwPg3cQ+AsXJiiA3IvASPga8H/SuAcXVifBc6doDmW+swnPsk7gR6ApOse3Hajqese0vY 9+zYYKVv/wXob1L8WcCH1v3kvVn2bgUtAe61n+8G+74tVt477uyK35FvPaNM19KFhAqcjvRR0MYu dDxpIfEs6C8Btou+aOeL3YV2efAzb+ZrdckF+ka7FzJjBhH66gxjjUW1q+gUKXNfPaSvukjKw/fo MSnvEpB99VSj+6CH/IyGsN7AMtw1S8a/yTUTfRNBP5kk5/PmafvIpT1PEdcHNF27kIaqm6AXj4C8 xT3kvAyuzXKbdQ71RjoVkHOVck6I504up+s9G6X+EkCcDO0vyO89tA1jthtck0lBet3oDf/t6Ncf pMtdV9GV5gW0Tf8ced1Ds9FfRfXpVOf6IY10xrb6BeR2eaEX2NRcQecavRC+hmLah5Tvvh563S4a hzIb4Ny7c+7eoAyEP2LZVyT/Ad9WAafIPCO/0MM0jK0znHUDrmkok5kyP6fJOafHScMYnVz70XeP okrDDd2rmm5w59Aq/Ss8hw49tUrOy8+2y74Pzz8Z59Hxruup3Bm76++jnCeQx6E8H+fYA6C7Paid L/XFkJzXsu0BndS5Bs+3NdPNvFYiVa9x9KhOncK2EXTaHJznAeX+s/P5bZqkb1g2he3QTzOpiufx pE0kldp5kvN428FLtj5rbKPRhgr6CM3Wr6NG16kolzA1Gs9SyBhBOayfGYbU6y7gPtr1NXTRRipH 3Zxst/fLAG5LI+w2vhjhrwFPWO2R2xeHy7aJsPZ77fC5wBJgjnWezyWWWe72/db15bklVvx2tMME z8GJJFvNuxbkOCSWrKfaa6muO4x2zd0z/ww/Jv0XbWjchnlN1RHm+FPpnaDnO37oee+ijd6BtDFA d/ToVKpZ61OWWlTqhkwftunPmddY10ulqetXjrae5Tv0WKudOfTQdS8OPcum5Z3rco5Bk9fJdNFE wvan/6u2O9vmluvQI6w/sGxyXVQ/bPyUTGWdkGrrsay/j5bz/Lw25zvQuYbrh+CBQzGJwesJjgQd PQnDmH8obD3/qNBvQzrAjKYi8Q8G8rzcQuI+G5/aWM1QFYylAe3HqUj8Q+LI6+uG6j/DfQHzOAvG DgtS//8OoAzIQAs2Q5Lq3Bd+J6BlMIz9Nm5ykEgwnHJ3ytEpFzzbh3ju8zvz7Nzfvu7/tB7/p/Xy n3ru78p7Muw1eg7ltXv6EfON+pH4hwW5lmYNhW3oKNengLXASzbuZKCt5PJaJXUW+GmWXK/YmeYw PrgFY1OG7bfX3+g6NDsjx2oHvPbHAjUdqXyMWRb/GRVWOcl1O5bu9QGew2evsZ1ty75S9zh60F4n G2XZgn6X23kf7RmafajOl2i0xtOJ1egnXYgfdC2m4eLlxM9dV0ImfJ74jWsZdAEA97rGxg4bqyzd L7HOXgepy/XAa+jxZGBsW8jgOLjfIuBhW99mPfZiCx1/scK78uXIXvWfeI6DFJHrS+NyfD1Om4Mx /RyKqJ/iPPQFnm9Sz6bB3Geo/aFb8Zqby+31smx7eAfUgg/lMk59LKl98/oaXlcDyDU5XE8voA/g +C/I9M74vlLal+ZBjr9JUbn2B+fkmh5cg9c6sV6kYkThGgu+GI+44xO/U1eAjrTxT+BC5HcSzRHX 0HHqbIyHd0HfyUT4QmAB3DmgfqAJuB+4lI6X4QfBJ98gPqBq8P8W1IWxvQthX9u42QKfl+PtTTQT OvFMXM+Kt0emsaDTTOXX8l4z1SG4HuIJjJRUaBRqpu3Wcf5apNtmjd/ZrsDx5TknjrsrjuszGu6Z TcP1MHBjYqtrcGKr8jHVa1MoiDr1Af1Q16/Y4wfWo14FUFqJB+B/SaSuC3DmyW3q+gXNcZ1Ex7na oR+8BT7YR/Wur+g+VwNV6uPQjz1BzEsDAR7bzeb1xHIt8Z7EK47t24E+mTLdz9MI1CHx+g2HirW8 eQDPO1H2R3ItvcLa21pLI5Prp622JvVcYyhdjXY8HBhpr/uebc2PQQdF29OsdaqV2sNUYOlxPIbq QGkluD00QjZ02l6Z8po25i1bF0TSxBPi9zyuTQzguQoxjtdrybRnWuPSBNurfwKwzfL+pPmnuxj/ p+e3RMo81NHmi461NuNYazUO83/POZXUtRvHWstxTH/KnMux5svAq6wjD0e/sk1fk9gD/2bgx5Cv DzE0SiSkfdTS125U09C2F2MMOopKbZso20kLIb8KtZulTf8663oUhmwaYtnmE9/a+xykPZVtc6yX qjlyH0Suva+Brz/att/KfROddtpamsiylmWq7DN4bTfGaZA3M1m2iB3UV3xrySBljwSxLJJ2ySHI 4xBJpVv0tGXKEHKLvniWOy2o/sQOKZPSLZmlEq7XxvIM/a8lrwrUXEt+id2WDBLvII6DA8AnPFfD 42k5pub1EI/LvukbS05KWch2SLjlfhRr/OTnNsj7YI6lL9m65doU+pRDj6UX2mnW2mkOj2/P3aAv Ccs++UXqwWt7O8ddRH3l2ugP5XhlJM6zDtKl5zv2dllPqCNrbl9JHRfwfA7XrTOmt+xmHbuT6HQL sp/mcvwL9DIP+t1T5D0g4+R8z6LEATufPD6JgE9v6hz7OWM5Z6xBNFB7gB5Sz4Mu1IfXJMn+/umk 8e1DDLmGZAc9LNcygyJsJ+KNtPoN2Yc8D+wCfgf8Ddhr2anaX+e9Q1wuneOhlbx+oGOL6y2U1wvk Nk+hiL7V0lfUZrqY7eIM3lfAkHunHKxBu2I5vojtN/LX8wj4/eFQUJ7KCtTMILSCQhuQ4yryiF6e NMh4Hc9rsnmrmci7iSj9MaIguqEwuDoD6XIQLw80714L+fldKEgnigJFFxKVXE5UijIpRx9Q0Qv4 J1S+55A1XL/XCUmA3tWnP5oU8tIXfW7tny0MuJnoRGikAz8iOgn3a5hBNCRuYehSGx9ZGHaKjWYL I3Hf0V8RnYp+bSzSjZ9LdPobRBOhSUxCPia/YOHMXxNNqySaAV46B6O9mdC8Z19JdP7pRHPgvwAj pQV43os+IVo0gegKFONVeJ6lWUTNgW78W7j8u7F8NdEPX7Fw9cXd6Mb/x7j1KPjkfy+uKe5GN7rR jW50oxvd6EY3utGNbnSjG93oRje60Y1udKMb3ehGN7rRjW50oxvd6EY3utGNbnSjG93oRje60Y1u dOP/Sij8RSv6gurpZ2SQoABV81tftSfS/otcJLbQBLVyQ3lOdNfTag/aBwi1R2tVQXSLWqEWtA6M xtvUkg2hzBr/4OPUGK5WLY8xHBcA64BtgEbT1UKEB3BcBjQD64BtwC5Al3u2+GwMWACsBPbxGbVA zW+NRQODK9QI0kaQR7+aTfuBBKBSFMdqYCwwHbgNWAnoMh6HLACWAduAz+WZuJrdekdf5D279SZJ NsydXyO9Z1veqdOkd8MZTRY9dbxFh46yop1oRTu+1gruPcSiFb0sGiqraWbq8dVsH5ylZuEhs5Dx i3BUxHPkVxSK0io1k1oAoep2SFwNbSgtr1m5TdVIUYWq0EyKJrarSqsvWDPYIxJiP4UoKv4mPrPO iM82pAdrVg4eLf5M64BtgCr+jL8/iT/RMrGPyxzHBmAlsA14FdgP6GIf/t7F3zviHfKLt6kaaACm AyuBbcB+wBBv4xgQbzG3yCO7GwAh3sIxIN7EY72Jo1+8Adcb4g1k7Q+tA+pqtkhHVbXtiJbZjuw8 2xHKqmkTv2/9ugc4qhw1DY56Si2mQdRXLW4tOz7apua01s+Jton3NsSqoqsG9xG7qQUQyMlu3Hk3 xYBxwAzgIkCHay9ce6kZuB1YBbQA4DIcA0BMvAT8FthLfYA4MA4wxa5W3KZNvNpaPiQ6OEu8Il6k bJT4TvEbSX8rXpD0ZfG8pDtAC0FfEi+0FkZpcBrOE9IEQAOg1TjvEs9sKA1FE4ODYhvKLopjNdAA jAWmA7cButgmiltnRkO4yFP0kkmI2UofS/oIrTYpPjcaLz8ZDBjjQ/mJJ8GFw8rYynIRL7/rHnj5 UH7rHXDxofyam+HiQ/mVy+HiQ/n8S+HiQ/nMuXDxoXzKdLj4UD52Alw4tIkHNpdWRAeMnafEBvvF ZSily1BKl6GULiNNXMZ/9LXGebuvtWdPlNi98aoePaPNW5Xmp5Xm05Xm1UrzLKV5qdK8XGmuV5rP UpqrlOZ8pblQaY4rzU8pJ6AompX4xkO8dfEcpfklpfkXSvMipblcaS5TmkuV5pgyIN4milpH9ZVk mCQbBnOjAz1pEKSPXxShRIvA80WQCdtwfBVISF8ckWLFVuRIIdPiDT0bLH/vE2sWDB4pnkXCZ1EN z9K7gIYKehZs9Cwu8iwu4MexAZgObAf2AwlAR2wWobfJox/HaqABmA4sA/YDuszOfkDQAjuL62TG qu1Mj2WfeBZ/xfgrEkXxgkB+oCowUr0tX/EXKmMLE4ViAGVlEVEoaAbbFN+m//b987995B7sFreK 26gAFXG7TW9r/bog2qasaC1/Kjo4U7mbCjVwnVJH5UoZ6Am0SPr7Ub7JtJbyxVrQmtb8SUjmby3v Fd2qpHOqTdGv89+PfpzfJuD8KP+p6GuxNk1pje5ByNpN0d35N0Z3VLeZCHm6vE0B2RqTUbfknxD9 xUsy6nKcuLc1upTJpugP8kdE5+XLE7OsE2ctgi/uj55ePiU6Etcbmn9ONL4I19wUbcg/K1pvxerH aTZF+yALVZazJzLbI1/etKRQXnDigDbl/Hgv4y5jsjHW6G/UGL2MIiNqFBh5RoYZMgNmuuk1PaZp 6qZmCpPMjLbEvngVf+ExQ5cfeuQt3Qpp0h0QfBQkPwApFFPQaGoJq2PEmMYhypiW7efSmHNiLV81 lrQpnvFTWlwlQ5SW0BgaM2FIywlVY9qMxOktA6rGtBjjzpy8XlFubUJoi7ihTaEJk9uUBAddm9cS OnnyFlKU4LW35DGtvPaWpibKybq0IachNChYN3zoEQ4z7GPSB5VzDnEXtNw1pnFyy5qCppYadiQK msa03NkYmzp5i/KF8vmwoVuUvzNpmrxFHaR8Mex0DlcHDW1qGtOmTJLxKKb8HfHAMX+X8Ux0zByP YmahFe9eK14Z0iNeKRPEc7upTMYrc7tlPE3heOsXlQ4bur60VMbJjtEiGWdRdiw5zktliFNWJuNk NdNLMs5LWc0cp2WQjJKfjyiF+TKKkkv5Mkq+kiujTOqKUm1HubEzyo3yTqrSFSffiuPb58Tx7UOc qn/1N2tIVZWyYWDTuVOHzSoZNqNk2CxgRstNl56f09J8Tiy2/twmPhFrUctnnHPu+UzPntXSVDJr aMu5JUNj6wdOPcLpqXx6YMnQ9TR12ITJ66fGZw1tHRgfOKzk7KFNG0aMqx1wyL1u7LxX7bgjXGwc X6yW7zViwBFOD+DTI/heA/heA/heI+Ij5L1I8vi4yetNGtJ08lSLbhBpHvDrjLyipiFZgYsGSeYd WJSzNG8rtJXHKK2qqcVbMqTFB/Cp4wYfN5hPoU3xqXQE++1TOUsHFuVtVR6zTwUQHCwZQlWLL1l0 CeUMmzPU+l+EH4IWX8IFbh2rFh3th3PDWuJnD120mGhMS8/GMS0N46dMXm8YCJ3Bj9RyohOWljas LbHdCuyNwBM5UFU7I3JYPYe53XbEw+v/EpvKD103i6c2KPFCZTEtalJbCsdMEBAFE6bgWadOmbwV uhR3D4ua8ICLlCplkXMNO9v8QXSL8DM7WHyJ7bLLYrFNrZRIssgpks4fF1ZVZ4ktxgXpfwEPqb/4 CmVuZHN0cmVhbQplbmRvYmoKNTAKMApvYmoKPDwKL1R5cGUKL0ZvbnQKL1N1YnR5cGUKL0NJREZv bnRUeXBlMgovQmFzZUZvbnQKL01VRlVaWStBcmlhbE1UCi9DSURTeXN0ZW1JbmZvCjw8Ci9SZWdp c3RyeQooQWRvYmUpCi9PcmRlcmluZwooVUNTKQovU3VwcGxlbWVudAowCj4+Ci9Gb250RGVzY3Jp cHRvcgo1MgowClIKL0NJRFRvR0lETWFwCi9JZGVudGl0eQovRFcKNTU2Ci9XClsKMApbCjc1MAow CjAKMjc3CjAKMzU0Cl0KNgo5CjAKMTAKWwoxOTAKMzMzCjMzMwozODkKMAoyNzcKMzMzCjI3Nwoy NzcKXQoxOQoyOAo1NTYKMjkKWwoyNzcKMAo1ODMKMAowCjU1NgoxMDE1CjY2Ngo2NjYKNzIyCjcy Mgo2NjYKNjEwCjc3Nwo3MjIKMjc3CjAKMAo1NTYKODMzCjcyMgo3NzcKNjY2CjAKNzIyCjY2Ngo2 MTAKNzIyCjY2Ngo5NDMKMAo2NjYKMAoyNzcKMAoyNzcKMAo1NTYKMAo1NTYKNTU2CjUwMAo1NTYK NTU2CjI3Nwo1NTYKNTU2CjIyMgowCjUwMAoyMjIKODMzCl0KODEKODQKNTU2Cjg1ClsKMzMzCjUw MAoyNzcKNTU2CjUwMAo3MjIKXQo5MQo5Mwo1MDAKOTQKMTcwCjAKMTcxClsKMTAwMApdCjE3Mgox NzgKMAoxNzkKMTgwCjMzMwoxODEKWwowCjIyMgpdCjE4MwozNzMKMAozNzQKWwo2MDQKXQozNzUK Mzc5CjAKMzgwClsKNjA0Cl0KMzgxCjQwMwowCjQwNApbCjYwNApdCl0KPj4KZW5kb2JqCjUyCjAK b2JqCjw8Ci9UeXBlCi9Gb250RGVzY3JpcHRvcgovRm9udE5hbWUKL01VRlVaWStBcmlhbE1UCi9G bGFncwo0Ci9Gb250QkJveApbCi02NjQKLTMyNAoyMDAwCjEwMDUKXQovQXNjZW50CjcyOAovRGVz Y2VudAotMjEwCi9JdGFsaWNBbmdsZQowCi9DYXBIZWlnaHQKNzE2Ci9TdGVtVgo4MAovRm9udEZp bGUyCjUzCjAKUgo+PgplbmRvYmoKNTUKMApvYmoKPDwKL0ZpbHRlcgovRmxhdGVEZWNvZGUKL0xl bmd0aAo2MAowClIKPj4Kc3RyZWFtCnicfVLLasMwELz7K3RMD8GS/KABIwgpBR/6oG4/wJbWqaGW hewc/PeVd5M0SSEGP2Z3dmdXnnhXPpW2m1j87gddwcTazhoP43DwGlgD+85GQjLT6emI8Kn72kVx KK7mcYK+tO0QFQWLP0JynPzMVlszNPAQxW/egO/snq2+dlXA1cG5H+jBToxHSjEDbWj0UrvXugcW Y9m6NCHfTfM61PwxPmcHTCIWNIweDIyu1uBru4eo4OFSrHgOl4rAmps8p6qmJRgIp095yujv2mOf JPThXHKFKCMkFRUhS1x3W2gt0oQgtlaXEvmthNggLclRQqaIUkEoJ5QQ0oQ2iBJOyBCiQTN+f7SE NkhIM5Pq7vYJEK1BiZQEM3Mpkf6TSNPTlMsrp0XShoK0Qf5IQTqn7BjUGGxokWbpIrm4PrzlXy6W OxtFH7wPHkFfojkWW3QWztZ1g1uq8P4FyPvYZQplbmRzdHJlYW0KZW5kb2JqCjU3CjAKb2JqCjw8 Ci9GaWx0ZXIKL0ZsYXRlRGVjb2RlCi9MZW5ndGgKNjEKMApSCj4+CnN0cmVhbQp4nO19eXxURfbv qbpb7317Sbo7W3enkxDSCQESskAkDUkQCDsSEyAS9k32RRZFwAVkERTFXRABURCahCUgCszoACrK uI0zrjPG3YgL6rik7zt1b3cIcZl57/3eP+9Dwveeqrp1b1WdOnWWqgsAAQA9LAcO5PEL5/uu+Ciz EEseBBDqJs2ePOOq4zMKMP0L4qXJ1y6e9Nys3S8AGF8EyK6fMnHshLf31w4DKFqOzxRMwQLLlebx mG/EfNqUGfMXTb2jwyLMvw3Q4f1rZ40fS/YnrAOoO4b5phljF802p3EvAazeivV9s+dOnN13uHU2 5k8AiDuFo+BRsRMS+AxwAygfIz5hNDJV+ZLdi8xS/kX/hU8fjEL7OQbHYR00wE783Q8y4WECLIa1 +HsSPoM1sA3uIAdgHiyB7Zh+ijxNZ8NI5IILZsOfoTPhlHOwB24gZhDBDmfgLFTBHcoG4gAjeKAM 5sIR7jT3N+VL0ofMBAqJUA7D4BD3JbxJeHqF4BbmKTkgIGf/AmfpAOy3DeKgEPrBIBiNfXoM+/oc vEUyhTLlPfBDCIZjy4vhdngUnicb6ES6gG7nTgsjlPsVbAXfpIMM6ANTsdY8uA7ux3GcJwbiICfJ h5ybfzDyTeRHZTuOvAPkQy+ogAU4mmfhBfg7fAj/JiPIJBqkV3GzeYGfrMQrB7DPydAV+uPvQBgB dXA93Igcewj200e5dZFnIz8AQZngIAd7XQjdcfwjkVdn4R/ERjwknXQgfclwMpVsJT9TiRbTFXQ7 /YETuEz8LeAe5Q5y73DvcV/zfflF/EeiUclUKpUpyiJli3Jc+Sfy1AuZMADfORqugbE4qutgBdwE q3G2HsTfh2AL7IBD0AhH4Ci8Cu/BP+Eb+IFYSFfSg5SQSeRasojsJQfJYfIyeYXW0rF0Gz3LBbiR 2PZ2Hvhyfgg/j38lApGiyLrI/shLikWpV04pXygtyE0v8jwdOZoD1TARW74F7oD7sMXdsA/C+HsU 3oK34VPknB5/ZeIkLpJGOpIckksKyBAylIwkk8l8spisJLeTjeQ+8iAJkwbszTPkOfIP8gn5inyD nEE2UyO1Ui9Npdk0h3aig+hkuopupHvoQXoMf8/R1+ib9C36If2a/sjZOCf+pnIZXF+uPzeam8Ut 4hZzy7jdyM8XuPd5HufPymfy2fzN/A5+H/8y/zn/o2AUbhc2CfcKHwofiiDK4hXiEHGKeLfYKP5d 4qSh0iRpmXSjtFI6pANdQLcH6nF17MeRtvmho+EReJU8A++SnZyT7iZD6GNkM7FwbpjOPUD+KlTC bbSEhslAGs99SxaShRDHPU4uwAU4RHn6Jgnyj5GtcAxX0jo6nS7ireRq/nG+hcznX+E52gQ76Zes HdHJP4atLQQgM0hPTE2GGfAwdcILdDvOwhz4Ezws6ulGnPcNkEH7QjfSj80NPQ+f4+qwkVKYhuuk hTwqzKePkCXcJ9QEVaSFvkd6CPNhkijDCtJAB3EvkCZcecdQXirJFFpMxkELfES2kY/oCBhIb4JH +cnCa+QdEiSDhCkof8C/z/XjJlEHfQra/+yDA7gSzsIA7jSMJnfi6j9Lg9CPzoKHuKfJp3CAXM9P 5qZgLxdRntyEa2EPNHB9eSP0hgPcAXiG7OLeIEHYxy8iM8kmpaKlFr4Td/J7uf1CAZ+kPB95m+wg 55Sj9GsoVJ7nRkQmkwd5D67L63H1zkUOGWE3Pv8gaoydoMNUOq7H21Fe41C36XGV90HNNQCuId/g irkJuVRAMmEQTYXptJfkE50AUgd4QmEreSZ0JP/gd6F+OBrqdVWotOcVJT26FxcVdsvP69qlc26n nOxgVsfMDhnpaYFUv8+bkpyUmOBxu+LjnA67TbZazCajQa+TRAFnlUB2RaBPnS+cURfmMwJ9++aw fGAsFoxtU1AX9mFRn0vrhH11ajXfpTVDWHNSu5ohrWaotSaRfSVQkpPtqwj4wmfLA75GMnJoNabX lwdqfOFmNT1QTfMZasaMGb8fn/BVuKeU+8KkzlcR7rNwypqKunJ8336joSxQNtGQkw37DUZMGjEV dgVm7yeunkRNUFdF9/0UdGbsVTghUF4R9gTKWRfCXHrF2AnhIUOrK8oT/f6anOwwKRsfGBeGQO+w NahWgTK1mbBYFpbUZnxT2XBgrW9/9ok16xplGFcXNE0ITBg7ujrMja1hbdiC2G552LWkyX0xiy+3 l1Wvans3kVtT4Z7qY9k1a1b5wluHVre962fXmhp8Bz5L0/vUremDTa9jXHTnYkdY99lQtEFNDFSw krppvrA+0DswZc20OpyQhDVhGLbYX5+QEDqivA8JFb41V1UH/OHSxEDN2PKk/U5YM2xxgyfk81x6 Jyd7v2zTuLnfYo0mTOa2iYmt99SUWp2lKoe1spOwHgX6oRiEfeN92JPqAA6kiF0mFsGa8UVYDX9q CD4VnoDTMDWsL6tbI3dn5ez5sJAuB3xrvgOc9kDzF5eWjI2WiOnyd8CSTDhaBQzvx9LhYDCclcXk QirDicQ+9lTz3XKyFzbSgsBs2YcE2QdDqvGxmu65yHO/n83q2sYQjMNMePnQai3vg3GJ9RDKDdaE aR27cyJ2J24Eu7M8dqf18boAiu8BYO5aXFiX0frHKsc7KqZ0D5P4P7g9UbtfOTxQOXRkta9iTV2U t5VXXZLT7he13oumwo6yai6RRlM0kVPvoiSObq3MMtWmMJ+Of0RVkic0SjoURbWE+PqE5bq+2rXG 4Pf/lw81Kl+xp1Ry8bFoN8Pdg5fme1ySv6R7pjUcdpjPoJVXjVyzxnDJvT6od9as6RPw9VlTt2Zs o7J8XMAnB9YcoTvojjWzK+piM9qoHF2bGO6zrgYHMYV0R2ml0Ht/gKweuj9EVg8fWX1ERid29VXV 9ZTQsrreNfvT8F71ER9ASC2lraUs52M5qCQo6fVUp95KPBICWK7e5dUCNT++kYBapouVERjfSLUy WS3DnxxmxNn0C/iL1kqC/vspeYp0Qg9WooX1IPCNpNMBDgwSSxwk4NGJArtPgSNlDfpRz7iD8vcl LSWD5AslA1tKoBTT8i946dLZb/Pb0vFCgIdffNyJX0IC/Aw+/gQoConjGriZ6ItngMEGRAIDGc2k sIEQERpJ5eG+HYBQCh0hiIYLCOG5BmrH+gLMCZWEYLtAZwtE4AlPhExKSDnPOXmeEwjFK/BEovwd HNlIM0F4jeMysbeHJPCIo252BwfJTQPlJigNloDcUhKUm+RmsNmLi4nN7ipeZekUFG6Qnw3a1ILi Lp1J7RziKMyTOMKb8l/qNpVrIPbvvot8ifzsEnmTTEELr4dBIVua1E2ikqjndLzAgThNaqQr6/XA NdL7Q3ZKSQUYuH20guyDgYYZHzGuXWjBXiC3muWS75ttrmJiLwb5DGsxD9sTRamwoHBW8KX01A1j bddlnG14ZLNxsL8R2x1DGumTdAbOly8kk6VA93H3C/hiD7+wNxvfhYFN8vdNkNvcpbOj0C+NyaCZ 6aTxIAY6BJgPNRP7zIHnEOsT9qiRXGjgu7MuXWiGUnyINb8weDb77FmUDtitfMyvFU6g558Fd4fi uif1T6Jun9WW72GXDllmW76vUXk/5DPZ8uWkpbbFgeuyVmUJfl235D4wGRbLt7luC0iueMAFGUo3 2vIhPQUyfdz3rv7xf03wOQS/z2B2PZReKj4Un5CdUmr2BBvprftHaCNpHiR/P1DlVHNpc8uF75vV aQlqfKoN4g/UkoKCvK7oa0hiIJV2yy/sSTHrkjIyAqmiyDnj87oWFHTLZzny4IB7+j/2j23rTh/6 dlDJ/lM3bH7GvMsyfeDQ7QtH3D+2/N5pm6YseokbVlradPLH+vuI8Yd3vjj4+cyn9srXTVv2Q8un 1z8++ZUptz7yOVDlb+j7nUd5lMACW0N9dKJIRZ1OEvQGEy/qLCaTJOqsgl423WMi1IdLLEUyOSXJ RE08n8JRJ4eOkGRFd4iTTT/j0tfr/ILYSJ4KWSQJRZgDnelx600r3UGPfAHcpSUy+72A66q0pJmg sKB8ruoUXHXDs6s6uYOqwKII459VsuVZ4dlnV6lXSS5ZJT/bpXOA5DkCnJ8jfi6jgyh15Eo//uaZ K1v2fU5KyYfFfl3XOuHoT33IzshIegWZ/dady55ESTmqfCy8KbyKUeqWhs064sA5bsAJd7K5tlhw rn2yLd/mw+l3s6IuOLO82+mmGc5SuQ+3SOZlizM+ziPbrcWWO42keCOzM7w9x8h5cng9LEUhHhty Wpda4rM6SyRXIlJ+kqUsOb+MTfxH8oXaOQOb5WZVJEub7cW5tU1yywUbjhHXibYw1eln8+8SIeAD m+wo8Hfl1Yn3SaJNnXj+1T+Njmx9K/Jd5NSXr5EenxK/63DywQ2Rb3dufLf+3u8pnxiJ/ILxeGey jnAf//SqbctD51+KfPivL//CVssCXADTcZY5uCuklwWM6koFKjQqJxoysvJV6g6oNNTBGZdPOS4F CPrNhGYSymWCjlI9x20FPUF/O2QPlAKwuraE1HwZ3/4wj1EiuB6+x43DKCHBJYPkr2qD6GGxXG5w yUD5a5bBtKqtEKuETmyyu3TGB3D8eSSPLCB5f468xOYP3zgSY6WfsL9uOjBUuiWBFHCFUqG+QL5S ulLfR+5nr+FG2a/lZvBTddP1U01TzbPsUx2zEhbbb0y4jbvFtsb+uP1N+3sJiVsS3kug+0VadlX1 AQMkeHCEnzSYzGyk50IJOPcW2ZiUHxfCixBn4YAY7aDTEYrav7SkhOlRNjFsoRYnHgGr8n69xSce U06AgOCRAwGOFwQqSjqdYDJbLEarbLNZHM64OHu8y+2OW23R6VGnTGwQ7DZ00zNDw+JwEVFBSLHH Oe2Czh6nw7TN4rQJ1GbRGwwpRovTaLSwZeaOc+IbBOKOG0n1lqW6TJwEQt32TLvNZjQaDDgrej0G I41kwUGBENDTRtIjJKP5W+rWx8Xp3e5Ngt5iYXPbMZiv0rh0lYZKLHK+Jde4xbjPyM0y3mh8z8gZ cxNKE2jC8wbsxFK90bhJ7xM2CrQObZPgSbAY49yy0eV29dnDpjjIFjHx2Jgwzwku+YpN7pJ/sqv8 zZwlcu2ck4xrHiyUtXsntAyr4pGb8PG2CSYPMtowvGABlKq0uUSzZlFBiSqHVTqkQtsENsQ0xbO/ e4GioiJSVFSD62xO7VwUNEe8q6AQ5S3gKHCIEgmomoQbSbp+fVey/ooNlH4Xeenkfd3Gl9a2vPv0 Jqfe4/6zcPSX/k/tuauFW/dTH3rmB5K3Yccvvbg9K/acnPNLDVqWavQ77kZptUICPBAq2sU/5qDZ ju6ORY7b7LxFTrA6ZIscl+igtgSrNbqybLIfBQY8CX40+9SKs5nQSI6HUuOycsVScYhYJ84Wl4ui ODXJS+YTSmQr5GJTfaa6g7m1wZJagvakdmDLR9qKKgm2QAlOB+pVYZXKMcY8VXBtxVJJCdMygMvM 3zUe7YsF7XvAzzn8mj3JCPirSR6dsGXLlP5z5vdevzFyx/VbSNmx8LSiSXdEVgtH++2fOerYkp5W f8uT9MehO2v7jgpiV+pw1H/DUbsgDc6HVviZGk1mxvNqI2FrQbbbrfHuNFeiO96hF7zpjvg0lys6 ejvywWJ0Yi271cilWzK8RrtLf2t8Yp3bjz2Mg0CayheXNdOKXNKlpeldrqWq/rEy9XswXe/N8omd 0ViVZTDds6FM0z3IFVS3KGvfoGTVauqnjfZplbEYv+SWJvlDzWkqZm5Tp6CFiZegyRvYNW8KOciE iYFxMhiMcVIU4l3xLgcTImRjgLEUrbbG0zrk6eRDx6Z/Fvl5SMfRRbPfmlrcr+uUBU2rHyfWY8Wz bh/U/Zo5kVTh6BW7ljd8EehRvGJN5Atiu+vaytyWBVyWYBx084DQmFSmvTeiBRuDFqwQ/n4EstF8 oa3KYrbKjQkTY/n8Tis70gK+QFfk5/QFhGc38/Gmn5k1iV3Scwty7jJyVrMxK7uTGN8tuTgJikly cjwh3QI58ZyY002PLhjTIeYOWT57Zzu12mfbqb2R5jUU6bO6MMVhwKa6nErOSqhLYlk5NTPfl9Q5 ieYmnUt6P4lLaqRrG4pP41TI36FiuNByIdiMUjqnjfGzFeeio9rEmKpxMohyyYijUHLGM0PXLb9D BvvN6JavukPMH5LyO3SigVRJjHMyfuMv4z0fSE3beIIOOnB9+EiXru89WTr+muvPb274fhZ52ui8 atOorTXlRf3y//xwyZCqOxTY8WPkOfIPe96I9QPvH19RXFRXmdnrvnFzDtUtOj1KH2ftGbjiqry+ haMKRnRMruqT2e2euuvOzPw7476Ccr5d9ZC2hAoSKfGBTypAt4fT64jI0UxRkqJSLVA/OkISrmVR 1EsSk1cvYSaTKV9/ar5qNE1JKfm50BnCaIyR3c8d0qnGc8MRNDsx+xmV3iBb55cKcFCLTKJqMRj1 94s1N8JP/Ogm+wn5K7FGvAF+ZSASiHwtOB577KdmNpK/KB+JemZVYXOoq17Wo9cr+xJGxU2Nu44s ihNx0aYYTWh/TAR9u3jA+QCziQDNlHLs+kwzysZBS9atJmJiUqIPGYcYKRiJsZFODlkSyDY+61Yg s7GdbfGN5KcGT/5KFh001c7BNYZeUBPSYCk0B9G0lsTiE6SaIlelgeRxbIqZn1vowDTFKWaCUEg2 P3vMdXT97JOzcx5/tqHT5sj34Z3fLu6Iinnp7IKFGyeffovr8Mv2tyPKAzP/tHTgMexDBD0IC47V AA+GHOWknF5FrqL8RXPdqMwKBQUw+NDg+QWdUxB0GJ2lUMFJ0T6jXVXNrQGN7FJdyPBn3VHiQhb+ O2QSfGRpiG4TnjL6onPmSZBb3BcSmpE2u5s8zW6kqgfBTFp7E9bGXLEh+y8aJOqOfPT0E7mW0T2o 8flf3saxbf7yzmMzuROqR2SOzOL8qhRWh9w4iqjIcbyfyKLgl8CO0dNRImDM+F6DIO1DH1yoFzAo orYGDHYnH8F4NBpTtVzA+bjQpApSactFX8xB/BJ62JKZrCCbkt+KHHgnOTJLqlz74wtrsSVldWQW Dpv1YHQouS/0Q0lHN4XjMQRAqfcTu8D7RUkW9wnYdANP9qFDIhzipAoejmDQ/d5BbqDu0zWqSKA/ LLNO/LoPpBZlGI1zoZ+4I7OT3yED3k4mmyKz1ord1qLNGal8whfwPaEDdIOToaGjcki6Id0YMKVn dyf9iZirK9Zd7Z/s5/Ozs4x8bmaGmbNilBbIDHIOs6FrQmYwmG0wOw0Gc3ya10VcwxzeBCnD0NXL GV3V1niCcvvnUEquT8wosPpSoFoOzA7QgJISstnzIUVOmZXCpRyji1ARZ+BV9e9rgwO/r8XxMM62 YIopOgzwapuYhFuihrg4tk6Z3ouqPlR76SIGeqqeKyxIK1Q1H8Z2Ugem99ies8RWgyuQ4cAY2kKj C4OTr9k7ftOBobeOvYKM6B/XqXTx3Dv8h4u+PfLcvGpPj6T4w9YrMq6e9PDK3lPHjtxZd/PQyidX 1dw23G6yJPfvUprWdWKt/PCua/rMHjE78u9lg7tek08+ssp6S/Ca4gHjxjzB4uRy5HFfnGcHBOCX 0KQEH/rJKezC+wenL4hbY3vcdsQmdrTlppemXxlXFTcpTlziJ5zdGZfqwE7auaQ0TvQ6KA0QcBKm PghwaV6vKDkyweD2Wo16n700iUBSblJp0uCk80lCUhLzfUzow1KHnvmyDkcjKQh59J2BKT0YDGOA B6hKU1Vl1cQ2cQZTlHMxxNDcT83en1CdTu3enLLR1Q2zk0hhsLaGqLPDVGhL08UgJOopsT2TZ9lP l84YidWqRj6Pi0bkFg4nqoPkkNQ5sGtBuCSWk64HZ1StG3D3qSELl918xdStOVkzyMqxY7ZMWjFm 3PZC1E8tFwb3eve19Z9tGZM7a+4ZciB19e23kITrbr3rnocW4Kqeh7yOR3lOhHUhQzE31Tk58R6R V+PQEehOFRvW2ujoxKny9frF8n06QXTGOzvqy0g1rdaJ1jTLcCNJ64yO2EZmS3i71yh5vLwRqn0Y BlLylSXeJ2UkWavBIluopTK5qJKJLLqNqrTiEqy9JChtUo1IrRaIapJpT2PD13YgogLI+Q+W/7z1 yb+tIWTH7tP1ZN41M7aOWlRd/Qi5yXHq5Ptn9pIh+05uMU2cuyby8crVq29FiboWR3lG9Y+9sOsI JKMHg4Ozs1GOQbnSc6KFT/ZwU02N5kMWKd7iTO4oBeKutFxtEZ0ukkv8huy4KsMkg9CddDWUxFWS 3ob+caLbajUZjU69CRK9eslqMTi91Gh+0VJtelG2jrHOsm618tZGknbIL/uEDF/GEZIOF/dialEP qpsxJQgWyaBKvkGd+1oMFHD206McYGvRgRqJqO5JobYBY6Gc/MDj95zZcn7RXyYuOhB56bFI5+xp /ZdOuPXmCb2mT+17f/17r/2J9Np6nPb4qQ95etbyEcuf+GnZ7d3XvsFW2DTkRy+cdQ+kwokj4Ec+ 6JEhXuZBxzOuVDOuiJmpa91rPbzbc2UCqtqDnuc8XAaXbbwuYVUCD6wuJCYAZyc2azKkyaQOjRGR yRBM8GQ4n5iQbdto34oenJ33eU2SCyUDnbk7Q4lOny4jkOyzhly+fLDK1tnW95BTPdMyemriEdTk I7pXxYSD7YW2oAVXXQ1cKWeCTFTmzmEuCspK1EprwuKU/FEbTvzR3SpuSDgjcv7phc9NfoTA3c98 YPnlG/628bUHImlolVdPn3+cTLXf9MWMc7fsJVdu+eLFQcO8nrsfWkKWJJlW37EVV0ktAFeG/m88 /CU0LSCRTNLRWCy953jPKbhJhr3AzvGoYvg4zh4XH2/DNAgmo4kz6i22+PgACGgohcEWYvHpiZNm cw7kCM+J8aiNHPOd3HwZDb19PobM8fHVoOfno8eWy4KMRuo84NK/sA61TZt4oqmNP9aE6ya3KeqV qTtbaM2a5zDFElP99mL5jCTIJSWSrIVhc1gg5ggU5qnbey5J1SRSnhTgak9uS97mdefNG19xk390 z26FTvfzyc+f5O5fd8+cCb2SH3Z3Gz933S+TmCdXjsu9B/PkiDN03ZU8yZCI1+Q1Uz1J1/UjfXRX c6t0L9mkydIS3RLU10/pnrKJvJG3UCcGXZRzuSl1uwOaC6E3mQJm2Wk2yw7U0Uxbm5Ezej2WV5v1 G2Qiy/pcc6n5RvPLZl42DzaPMc8y82ZzI70hlJOAKlvvdiPf7IS5uu0UtkdPQDajzja7qnpe3Dpo o7mRi7Vtd4ha9Xb0jnZjyYnoRoGG5hiHY4GaZNGYiz9zoXZOG80tcRjoa2KIYT5T2Asm7h19852+ mw6uSu5bPq5+YtYYVNNnx41YO7doc8t6etO6tPzekxtORYpwpV6ByzVN3TeTSG7I8Bj3F+5j7juO 1zNPfkBuUf5g/XL9OT3n1efqt+j36Y/rFb0IAs8TDlmJ7lkmlaQAT5ysZDzjrSiIUiZvQK5J0kxe L6tcQ3lkL3TjC5fz53jKh4zWfH4Biwz4KOOiTAvOYftqaNMO8qGBnUrVx/SlGaV8qGe6mmuozNBK Lb38WOrMxIs9oN1K7qzRpFyNuqJV9U5WNbmDmqv3+EuDbX9qfjVHUYFn1+Y2kYgktJHy4BxSmCcR 9OJJRfBAMFL+7sF3+eazZ3928Bk//4PJcAHyNlnlbSQ0ok4gg4XlwjmB0xGvkCtsEfYJxwVFkCjH BVr3IoFDyVT3ImfGBM4Ox+FloMvhHE5XyIh+2hRtN7JqTGs0hVybqzENQm57KcSYBoxpas6SVIg5 ZJa2u6nGa4UaRSZBjEnAmKSWIpMgym1GD/diNwP2SznXyrrf3/9ETrFNKVKAgtm6+1mGsctytA9Z pF/oij42kh3SG/K3ZD8VOJ79sutM4GMq3ue6L7A3fm/qvuynXGKFpUo3wnK1fZLlxmxRT1J1qZZu ujxLH52YzTo+2Czncx2zKM3KYpwkPrkYVRwyNDklJeD1OX2swEe8Xp/Vbg84nE4nK3ASh8OZ7hU9 XpNJ1QpiljeFOXDZjeSVkNlp1durnTI4ZAdFX216yOxNllOqfTJ4ZS/1shIvUDmrmsgX9UFVECfG J3udsoMJtbbeNaDBYdp1YAtetGTb1LNEO+jCn5iyRZdbWNUJDRBTA5hyX5q8qBOCTCkEUeXmSapK cP2mYmibLnv3YPrELbXjb4kb2jD+lltcGw7e6ehdMnRXbeDag5vlXvkDH5+WOpXP2Denauo1E8Yv m9tlTstV9Jmq9PyScVt2tLTQs/28+aFx+7ZFDFFNXYxz6YLzoSHq2VqApukKaB9dFb3aNIku1i2y PWE7jgr6Rd0Zm4WLd1Fe5KjLpc5VSC6erc5VVEnLWDBXJlFdzTWSSMiGcaqYaXKZzWBQla2+kRyu N1XLSEKotslFlf0UvQF9DkqO1ruqSSM5GnK0mRv3RSXNJoO5R2rU3tKk6mzVwJVg7A4eucmtauAo x5kO1jiubthGA1u4yPFLeI06+N3tHaYfHbtiU8Kqg+vj+lWs/XveZD7jyIwJ6xb0uLHlBvrIuNxu vU9/G7Hjgp6AntIw5J4FfLDoCNjQNxqOvlEiC0c66Eld6uxUKgqJcc4UrsY5Mq4qpco7K67OK5YJ ZL680Lk0YUnKAU5I8vISOsdGqw9CObn5kOH3+ECSpdkSJ81LzZjYxitG30f1epgjOAftCXNxHHKh NgxtO6KQOTc9aasnOOHwPd+d+PyuyPl7rn9h+sGNs7rPHVcR571j5oh1c7qRTaTwxV1fvXg48tyu aX+6Y/MDuXVLrxw/auOWoQ++jOpP+Twyle+L47OBH34KpVZ4q/hrrCPjpluF7nHdvBX8QGu/OCGd 72QNxhXyJVZBZmePQ3HwSYwDNe5FZLH7NnIP/NsvetwZpiLSl0yWp7hFHYbjNsolu6jNFlWfsmxJ 1uy76PJajLZMsOh9CZAwJoEmNFJ/KI1FX3qbDU35alWzspMdGKCH1EymTiHV8AITDrkElWoQQ6zg kq9jLtGlZpop3FqkzVFbrQVcNvSwL8Zbq9SNVNXPRoe7liOtokJZ5NGBczhdzN22R3kcR/Ie89Zu Gnbv6Zlbt1cdn7pov80zt/LBEyvqKhZO7B2ZKjx919jKd17aGTm/c9CfWo5z/a7r1GsIGXN41aZ+ d7yCcjQV+Twd+YzqB74MGY+ayFLPbQm3JnMp7DQQWclOBUM2TCTE94Biy2AYBdNATGUqPicvn9FQ P1dSvpgSn3K1Bf0nWTaD05RILVZrQDY7McuCEEumWWRRiMx2rS16q7Va1s8243JFZsqyXCoPlsfI OIlkfEjW2zAqkf2ZZll2yX4DhicZ0Ja/g9ADDy75praVr7+2I80XnaFWb3OVRX42ukk9R91cbRPH xLsKtUCmNYaVMIil3zxw+10vPvD18rFbunR8MPLSwci9K8cOe2z6rWPHXFnbLXPRxn++/BcS2jpj 5p9/KuOufOie1US+ceVdPYfcMz/qiXKjkLNWuBBaqudu1W/S3aHnRXO8eafuFP8p/xMnZtBMvogU 0L5kMbmNSBYr5YwU+RZ1PzGUNUYF06qZd+QbhCxyvrrfb2dz1pkFuDLQOpiNhv4r1Fea5uKgSlat /QtHSEmb7dNa1YWciyb/CADOodMfNeIWF9ppc7xmvHNcKq1PidrtmqgDGvxNn/Mio2Pyi+ohpuQ0 P55D5bY1Z9hDwwoG988tGnO6eCSf8felCzvsSn0t0hypYvwahBqNQ35lwzcHjVlWjPoalTfYeTTH JNCDibvND/ofTOUWcks8m413m3gjW+q+qJz6Wa1yTNzCrXVvN+408324xcbVRi7LlOZPDRSZeJ/J yCWjD4CUJ660+GEOSCOkY4LXIQnejsZk9qmFPJ9ks1BQT6p9zGEnLNYJyTlsT+wrnQ/S5XSa/lW8 esab1jEf4uV4+n48iT/ZqeqkpiznBAdeqG1pqsXk3GY0FHNadxLYRgL7CMSmbXSBusiDJLrJf3GP P03b4r/4hUOcU9vaj3OqKiBjxMHOK6oWLUpLj/wzs6z89IHTf+X388sXXDMlJ+WGcwVVY0+talyx gkw3DprZp65XblbWUk/HWX2XHThyj6ludlXXrhkJBSPzh183+N5Ro0apOy1f0juFXZAAq0NZ/a2T rAutq6z3Wu5zPKYPJ51I+sSBxppw4LGC3ZhtM6HfwxmtX9nQwtbL8+1HSQQcNLHBWa03NdLEevN8 4zGaiMKaCHpkkjEtG4VV1m/Qc/pGuqEhsaiB7XPWBi80XWCn/XjV9howPLSpISGTnnRJHWe3/EIW DjoKORYEarEz+Tyl1xXXhjonrNiQvKHw5aH1KfuXutKzSjbdZeuWWRFYRqeuI8INkWXrWg7Ojvel 4viWo1wt5DPQvkdCCzw6j/5u4yHpkOHjuA/dkl6n199sutV9t3S3YTf3uKjrYCh0L5QWGuabFrjF bJIrF9v62fg4jxvdjniPMx69jBtxuuM9zO0QdE5dZ3Q7dITtkes88XqdS8y0oprzuA1CQma8RyfI rup45lBY3dWlHiJ7BnvGeGZ5eA/GiA2JuMKZL5Jk8nUWyDnhfeErgcsV2AcIHpfgEhIMRSejim8Q W7QDmy+wrSl2ahTUDoVPsGBDOzfQjAdzPdTTA0yo8Z9Fjm3bxfSden4QO0tQTxMCnOf46aX3pC4/ eLu935UD7pjqj0+uO/juYyfeXD+p7FE6saVmRG5JWf9lVYVryAsYohDYhr7bYuSpAR4KVdo7cD5T H0PINMR0m7Rav9y0g+w0HCZGURAM8XwHQxEIGDTn6QSnTifg2HQ0T9v/1I4SRAPG1NWgk3UUuRGH bpu6S/cV4WaRDYQSxXiUDFQ3ldmSavmu9uIRAlM7ujbBrmo5UbUd0BnsrnwSrPFzrYcIZMje8Chr fP5QMv54y1Y+o+Vw3d/n3ElvVMezBeOKQhxPAraf8aGHWJPeS6IdPVd6rnPcyi033mpa6bjFvTzh Hv3rzo/1nxg+cViS1LDRn68e95UZ5XwZDZvNbDIaLXHxLpfT7UlIcLEPokUD+yQajXcCWBwup/qN gmu8wcBG7rCMdzoTxPEJYHAcpRPASSceTkhyuRLs1baj5AgY6YSGEwZiaCRHGmg1QW9kQgM75W0k J0N6K7oinsT169Tv3eYM/H7OR3LL97URz/fuFs+gionlH7kHyt9/ibxqRlY1axxrVtlG7MU2tvGu buxFj1x+8xMBFiQEa+dALeMjYyQTF5WhbN9P/T6AEMusvZ0dlE/J6tTyXEBHu85pOtjy47FMnnYs inzMZ0QCkQspoybNmEizWpoXP3/rl+RfP/+Dzuq+a/r1LZvZ6UkLytJA5L2VWEJOu2zz2WgHa8g2 xDbJulh63ybaVBcjp0e+qI/XI9NEVEdUlCTgBYxJ9HqdwcChMJksFqvRSPV6A3oeOoteJLxVJ0kc R0UDOrhWFLIBomG8kUUGessAYh0PuvHSUZoKIjU2sD0IpsoIcR6UYRY6RkfJyyATbn+DembbhCuv 5QI7nVGv0U2t6EGWS+OkDpmme9ZSolFMaVzUsY+0VL9D3XI/Ajrl+/q0btZG5Xuc7Hydwa2mQ/o4 V77E5LYwGiIHCMlDtc9kN9AhowPhyEuRH06P7JpJur4T6U1Mp6elBiPP0kRqfHraWLK65eOWb9+s mBS5gXmnkaH8DchTJ9wbGu6L72wMmULxqwyC3mQ0x+tdhixjkVnU6fRmi0UCEgcOouOsspwnWZyS ZDFbDJLMmXUo0QaDXtQZOJ+DeWwWgn8shmo9OUrvhDhkDgqf3JTbnIumTj3eiR7sRT+tjB1lav6X WiLzz+pK1GVqK1Q3jQsL1SWKg2S2zVjUrTA1O7/7/vohbht56+mWUePuHV8amfSE7PGPmsJ3bPl4 yxbu6p8Hhuey3eI3uXe4QcKroAcHrGd8/aQBPVF7o/JJKBsTWWJHebO4Wdosb7btFHdKO+WdNoMk 2mQ9UIfBRIwVYDV4DdTQSFeGvDbJNk2WRQIVHKng9tGBRkOF2Vhh3mfyOGcviR4QMgFQD+mYAKhb v2i4tOMr9mWnZr1wzRApUIiLBZ3IQGuKk4MvZfg3jJUXdHy5NcU/cfYA++rTdzRGcVxvcM9wVwsH 1HEdCXVIF9PlQrFA5lnfHWaDngO71cLJBh1qFhHkaVab10ZtT9GVqI/N9P6QbHIYKlATUXGaVfJK VGK30Bul9x+ieqigBLQvv+pFOU7Oy0sM2eIO4TgrjPsMA6NfsDaSsgZ12OpHrIgLTTXal7/suwWm UVrT7ICI4VdsaP3E9eLHrsQZ/dp1YYd/RHmwMJP/GMd+t2mw/0iMAqhfrAvOpd/1SuHGWEu+03l0 6l+5eXTun44z+sKQHod/fqdlsuE96WfkmB7rE7UCXqWekUFQZnji53d+GmZgf4tOavuXdvT/FqNV aXEr5tG/kTh+HoxBTJWS4ZRQBY+QVYSnT8CT9AllE5cMX/B70Bkshi5YNgbpQlqs3Iv17+DnkVyk ixCzEbWI2xG7Ef9G3IdYg/UXsGfZO1oxj/A6L8wSqpS/YXs1wik4ihiF6dH8B1ArFmM/TkEVe5YH KMfyUfiuYeITMBLLJ+D9p7CsGunTmK/D9EZ8TsH0XzAdkdYTwHcfx/R5LO+K7zEj9mK/V3Mnse48 ZRl9gmThO0ciyrGNeUivRUzDemwc3Vg5OQVXkFOKDu/3wXQBtl+m1p8HE/AdnzOeIU/Y84MYLzG/ HNPbsB9beFBaMM22vDPpHphOnXCM7lGuwvFv18aNYOPGMbeOCfsf7dOvofVxWltgmze0xcW+/QrL 2+Eol0dsSO9HhBA96VmYwQ/A+fsA+gsfwnAGHRA38mkkjrGZnwDX60B5Evu5F1fo/SzfinlQyT8I Ju4CFOG9JeJm+BrLgXZBfA+P0S9gg5gOT6F8XY3vvw+xB9+5UJWFCXAVPt9Jfc+HkIDpRxCs7YwY nxhvcBVsl9bDCuT7L2xF4PNvIt4gp4gOAfj8cmx/EeM5m3dS1fIJvmco1hmL8GP5LBXz0LkohiM4 r1+jfL+J71odlcPRFymMjsptK1gfYlDlLAqV90/AWcQJxBnEW8iz2xF9MT0QEUaEMK/Dtt0oRxmq vKLMMNlU5QNlg8k/mytVZrUxVKsypq4ZIuDzLnzPvYjHxT2wFLEb8TjW+YStFyazrJ+xdzPZYjIT o6p8T4eD+J4CNk4mU62UrT2A2a1rEGUrRtm6Y7LPKA1BEaNcHhQwmWXyFqOML2r/cT2yNdFKL45V wf4lqvR1mBGV9eUxGuNFK90IV6v8rocDmJ7Ez4Vx3M1Qwb8KE2gEwkIRzuV0ZRkbG/0crtOdAKYp B2P+vnb0XgbpdTJNOAFfqvx8HR5COod/nabyr2MMs1v5VAByRthNl6npX9H2ICe0e4wytL33v1v+ fwL6hrAbJmH6M+F1RcHx3MnWhPQ56YzwxSiW1yOWI7J0QXKvbjpplEaALAJcENlaCEF3IQSFPEZT fBzqAYB0LB8hvAsLuPXQg/8cJpLlaAteJ3FSHNqAzeBhbdE34CYG9n6ks9vI0SUy116WYjQmr+0p 0/lRmVIpk2emg39Nlbdx/W5mtoHpZ9U+oI5WocqrMrNVPs/AOKT9YvJ5qZwqp9rI5xf4fnd7uWxP VduC+j22TtnaiI2f6Uem45iOZHqOFpPMWP329OLzJA/XyX2qHj4LI6Nr+y7EJsR4vJeB/Xwf1+1S psuwrdfEwTBefA6mcEkwThyJ7X0BdWIeJOK4v2y1qdcoX0TtadeYLWV8wvtfxOyo0Bl0qj57Ea5W 9c2LkKPaUewbs5/iDmgR40GKPnuerUN1Dc6BCjYP/CTYzN+pfIrjeJg7iPzGcv5qWKneAyjhvlLO 8uOUT5hN5DapOmgCf7fSxDWh7LFnr1FmCK/Ag2IPmND6PlYHKStj/RefgY95HKPwuGrzN8b0MZt7 3SrlM+ltHP9J+JA/jHWS4WPheTYW5EE3dUw16rPblBvZu6Qq5TD/KYwXjmAZQn3meuXzKD+q2vJC lWHGC3ynOFq12ceFv+K98fCWVAtXS+Ow3TnwseTCMtbWepz/TkjnK8+r9no52rccmMB9g7J1rSqL 04QVynNcI3hjdpg7hevuJuVN4XqkkxFs7CpFvY/rR/U32N8R34f+GfMnNqGNT4N7xO2wWHwZFvP/ hsXCB1i/G5Ry53Ed8Zjuo3wS1dsV6COXcj/AWCbfmi+j+TNSX+VNcYvaXoXaB+anzIMbuK/ganoY SlGXDNU9gbIyGvbgrVIAZRNimwb296yUb6No0UBOIL0FaSe8P5yT4WtM96d5gO439zze+zPO2Qx+ BSTzVcpHXBeUCxva+b9CFfkRBnNWaOCfR13dCGsxf4x3wONcGCTuAITV8pchQH5U/k1fUb7i70U7 VqK8yq+GB/kxkMfth33ca8q3KDMce064Hf2vNOWfyPfBiGMM5AOUzyp4WLwVBuP7H2D1ELPx/S4G vq/yT/W5NlD7GkO7PtNKyOH6QzHrL6YHXdJf7GtrP1ejn8T6+Bv9Y+NW34vPsTr8A1CIfHobka7R yNA2NP6/wNttqI9RnNPtzC6Iy1DnvYG6rwZ9Fjssx3deAGjphTiM9aqRfoFlPTCN86cUYVqPZTjP kQakFsQkLMc6yrNYVs4n4lrR9NRSLJuG9xuxHOe55TTmc5CeAvilGWHR0OJEegfiesSdiD4I0OjP 72j9UYYgXYZl+L5f7sZnfsB8HqbvQ/yIOI/YgliLz7yL97MRlZhfhJjCZPtXfs3/OP1te/bf0jZ2 rAjX4SftbdJ/TWPz+R9oe9sVm///RNv4oO2oxofYONrY0j+0mTGKr+jcFqibe6KOKmF6melGpo9V fRSlqh+g6cXPmA1Bugr14AWmi5k+RF38F9SHK5AuiPqgJ5EujPUL19gjarx7DLXQN7BO9QfehHVM X6vpGD0FW9v4LqPEPmqdHqrPPFcdfznajUn8B0oW81W4H+E2Sa/GhwXIi3Ex/4Plmc1D24y+tNI5 5heL36BduRr59Cbrg/K5al+qYCU+czWzuWjXT6NP04T2ZqsaR6LdQbt7XI0xnoa/qvq51T9WmF3K w7QNefATz+LvOOjHrQADlk1n72fxBDcI9egemMveZ0Bdrsdx6XA8OhZHd0cf/nYowLIJ0u0oL93V uHFhbH5xLf74Gz4N89HEVl8tOub2sqn2D5S9zM60bTf2nK4PzunXwLf6Z/9hjUXtfUGU3vDbflyb eKO97F0af4zlRytvcMuUg62+5kikuFZURHncvi+xtnAauv3emoytEUyv5rW9hHJe21soQcjRMoY5 wjZYyPwo1RdoRtgxpilWWGzVTcVk7AuFnfx5Nba+PvYulC8voidlfwnllPIy4ivMS/xK6Iy+wowo ylAGZPWZxzWfQvQhemh7AehLhtugGXkWx/iGWMD3wWf6QC+cv7/R4UoRnYMYCjX0tJKHvAsikvAd vdEmjlJ9NVBeRTl/Fek7fArcrcrnWATOP+JFzD+POIUoRARUXrmxDTv6ZZM1X4dWK17WHne3Osap WI/5jjdJ0+FaqSfiFFwrXIP8CuPa3I0+EYVaIRXj0eO41v6F7ygCB70OujPAT8o2chK6I1IQHehD 0J13wqv0DNp9tqf1NxIX2y/Q/G6CMTt5Evn5LuL1NntUTzLgvb9r+x8kC+FHft2NfLoG6c/Ii9no 3w/D/M9R7GwDGUER2zA2fQOewfj/PvTl9yPFdtA/2tweWHecBuVUdB/hDfSlN7dDWXvgs4zmtgeW M5reHtHyhPbAckZ7tweW9/6Nfvxevd/rx++VZ7QHlmf8D/Tj994baA8sD/xB/yrbA8sr/zf68Xt8 TmsPLE/7g34Mag8sH9S+H6i3F2n+WIT56g1R3/0B9q9PIEVfXjmHafTDgPmYTq2OWg/9RbAhKhDv 4fPM73wM8S/EV1jnBsRTCPS5IsxX/BTxASKESMRyP1L05SJ/QXyMwDYj32H5eKTsHvPtpiIyEBOi 8GjPt+DzkVoE+nyRxzF/L1L0YyPjou2x599CdMc8+phwFaZnAPv4Q/v372Zh2qz5vpGfkWIbLesx /ZnWF3Y/hgh7N46vxYv5LoggYjiwv9AHCkGcwfsYuyjosyrJCAfm/6n1QcG+Ki8hBmD+nKYXlE9x nQ7mDbgGJ0GJcBTOSxa4nlFV7zKdu1J5tY2tOq3qwg+glhMxblYwTitBX9oMB/iH4DvxOaVJfAJj kfHAfPd6pEHeo5xmvoLqL7yP8d9zsFr4Ad83E2PLYZBH38WYG9vgt2Fb6L8wu8va41bh/VVgU/cz j6h+DosJlxum4bN/grGiE32THlAuFUMZxiTlQrWyA/Xw05IIvYW5UCY+AsnCUijTdcH031X/px/X qLSIO0gCxuzPtdo/J0QwDtoWo7p34SmpBsu3wBD0bVIMvTFPme2MPB9ru82eZDHyc6QWgwDKCHRF Xx7n5JcB0T4vV300jG9j+6FCJq6/fLU/41X7GfMVv4aP+TWwWPJDlfAAxrAN6LMcVn3ItdjW0Gib 16q+FdpIqRN8LHSEMIvn1Zj6LIQEJ3hjlPkbMb9U4LHNTMhiewVqvH4K85MxH/VPW9/B9hEwlmd7 wO39mpgf1canUH3VVt83Nh6kzH62jj9Kf+VvrIeRLOZn+xOqb96eRvuk7k98oPKvH/M/pIegn7gb 6Y1EJyahrfuU6LDdRulN5XPxWeVNXQLK4w4oVf01tNHC26DoPmPfH0f+jPO0GF+NMRn79+EUXGuR I9qcKa8hMLZTsDxSj2Vh9FAKMD8T89diHuM19uV85MOo/jiAa/Bfmo5g6ziC8WIE1xbgmgO21pZo +gAwRiV72sQMYhR3Ieazsja+Wo3mT7ajbfx6Nv52dEy7fNV/G8uxNczOin5v7/IiVVpQbr+9uKep VJBTke9i/mzMj25PeW0f85N2NFWjESbDI5kct6ft9+V/b5/+D/zY6liMotJL/Gvlm3a0uPW84T/Q qP89L0qLkJ5BXuxCys7lZrfz22/43ViyCvUMO2OL0l/vq0Zjw1Ya9cvbny/EqLbPPE87s1P995Hq eQc7c/gDtJ5NrYRGxCtt6AcMqn//GxBTYCVit7QXdiCOx6i6d/oHEDfgcxtgt84LOxDH29BzDBf3 934bHIGViN38HbADcbwNPafit88NJ4gPYbsPYbs52F4O9vcM9vcMPsf8/z8A8oCN8bjOro7xA2YL /xBLYDqDzoDtGPCZndjOTpW+zRDje4yPMb7Extfa51j70ff+384jPwd1/h/gP83L/9S4/6jvbYF+ yWTmk0TpCfXs9pI+M75hv1fCXxHXi98i/RZ9FnZG8AQ0RvHB78lRbP+dmwh/RVyPdV+J4oNfycHd SpOKaF47V4Dz2O7j4kfYNq6D6PnsWBZj/RZ/JGwH5e96qTdSxit2HqHFZBtxvpkvsYHp+KjuK9Mb oE5aD7mqHv0AHkW7+zcWp/InYVLU3xuLYDYrGk8rOj6oPKLuyYhwLR2peAUd6oTTynphBCxgwP6l RDEkis6IPaj/IoiXEEuRJ4exT7dqYGc2GHN0Up5BHMP7p1G19ED0x3bR/478SfNVVfSKli/VfNHI tpju5RTlFeGY8rB6bk7U87l5OH/liI7cc1DO/AXs/xvcEIhTz1vuhlT1LCEcPUtgew/zoDOO/wfk RRI7P+d2qWUz1ft9WbyPtoXF/cnwQvT8xSfcjTER0ovfMkAmawtxNf+W8m92rqDylO3N4TvQH3yN +UXclxibPw19uUdgiYpziIei+By2cS/DEtIPltA9mL8PQWEJPwvpGcQLiB+xjhXWcCsw/RgiG97l 1sOjgg8+Qz93JmIzfQ112NOwhS6D7nh/N+fRQIegLA6BOi4VbkJ3Pp3eivcV6E4XIM3E+3+D9Ugf QzTQ8+AkGzE2fw02cMdQ93WDRfRteJFbDTO5zpBJv4J/cCbsywq4jzOhn6Mo/yKrlDDWN2G9oVxn 5TDWuYbTK59iHTvWmSc8if7yFfCI0IJ2/m2Q0FcPC9/DYKEUZX2I8k9+D0xGn+cWBMYyLR+w7xhQ Rr6gr+NcoADotG9FVEp3s4+80PMZodoj9Vsdcj8W7Na+5FG/z9Bkfhj6pJ9JA2G5ZEOfzgRTo9+V sPOiW/HZK/gPlJP43jpEBr8D2D/9RaN+WA2+yshkDtfohtgeKKPszIzNseaTKczv601fgTQWC0X3 oq5Fm30OYxW0G0ojIgllfCuD9i2MckKzrcp5zohzPB8E0Y081PavvOr51iSUnRXgb/O+m4SV0E3b R1VGXfzWRvkc38u+3RjEuZUidR9Y+7aG2e6RbfbVpml7akoD+u8LtTNI5QU6XGF+13J+tNLE6WE5 /Qc8hpjCdYSdTF7IDriH7FA+Y3JD34ADKDuViHFRVJJ/4rQo0BNl4CU6A2MqTCNG0gXKLJStYuTL MJSp/Yhd9AQUopx8gLLVF+8VcYWoIxbAPMQclJsr6RYYoOIrxDEIYh/Y+QvGssrtCAPiJpzrWSjn VpTpLvjOziiHRkwH1G+itLNd9WwSZcf+n2zbf/IJ/pMN/0/1ua2wFPvjxf4sYufKmMb5QLmLnsuL BtWnnIr3TdjfPLy/JfpNVImqy5CqvtZI5SaMh8e2993YnjubU5Tx1/ndypvIn1rEFgTG8QrGDEoW ogPKZZMWl0SGSmshgLrGGNV9qfj+LtinL6N8y2XyirJW2Oqfx/ztmD/I9tDPQRV3E8ZMRTBLO99U 90teROxChNm+iHredAbjBXaOfgaexLIT0X2QBsRRBDsTw/mNPI34O+I5xDHEo+y7NcaXVp91HFTh szer/DoHW3UDCIhH4SGUhYe45fAiWYX+3SrV372PgRaTLEQ23j+Ha2M19v1ZfN+T0Q/95v8Gtv8a pOg3wOI2jM9oyh+Dy//vwcdrEBJ+B89fCt2ii9DP1GDAuTchj8w+AIsJ8favYb0min9dClsfADvG pA6UGSfOXxy+K/4zDe5hAJ69F5GAdjoJY8vkVwBS8Bkf9s+P/EtFfqUlIX5BNToEoAP2I/NBgI5f AWS9cRn/rxDcy/5fjcu4jMu4jMu4jMu4jMu4jMu4jMu4jMu4jMu4jMu4jMu4jMu4jMu4jMu4jMu4 jMu4jMu4jMu4jP8vQNi/5AffQAmMBAEoyJALIwDoCjoQeOD3X9X5KfoE1grRXfXFeaFGuqtBjuvK aL3Eso83mOxdb+xlozthH+I44jyCh854HYwYg+Dw8Z31G1j9nfVjVNIwaGjX5YwOGNhVzYf6atRg 1qi+u0Y757F62xsqFrH89oau3bV8Vhctn5aOzct0O/bxvHq14jUXUYq4EcFj49sb4pK1x/RO9tij DQmJXa3H6aNY41F87lG1i4+GDHjbPlgcLNHzvQrJ5+xftFWvN6rXMeq1VL3mqldr9O5nrHX1ely9 7lOvueq1VL0OVq+z1KtanzTj7xf4+zn+fkY+C9khm4CXyNlE9pJQNgl5yRGiJ8b6fO8djcQYKsz3 dvKVebsi8nxXerORehFLs/p6cxD+rHJvIQH2zwETCjpwuQDAbtOFGsmew5FV5pZVZtA3ktL6rAHe XnrSHY7yrLkCxP0Ivj5rrvcZfNqnZgF8dHe99+ecRlJV7/3J26gj9d4fvY2UhBzef3ubvD94n/J+ 5+3vPZO123sEa91f7230NvJYa2tWI90dsnrXeodh55q8i7zXemf61FvX+pGEjN7x+NDIrJHeal8j a2WQT23lSi++5pC3Am+WZzUScsgb8t7mzctRH+3KHj3k7eKd6+3kVZvL1prrqPUtk5FD3g7YWKra SoV3hFlv1hdufFvauEvauFPauEza2Eva2EPaWCBt7CZt7CxtzJU2BqWN6dLGZMmps+tknUVn0hl0 Op2o43VUBzr1v/AOsn8N0ynKjIg8u/JqWqbsSrV/LJMSHYX+EHZwlbRyeG9SGT4xHirH+cLfDw80 EsPQkWEh0JuE7ZVQeVVvd7goWNkoKcPChcHKsDRkVPV+Qm6vwdIwXd1I4KrqRuJhRbckhu1l1Udw Vj23rE9kVLllfU0NxC8sdZfae9qK+5T/xqUuem3z/8S4L/1vYyqHLD6Cs1zdIHmvkDA7HLMbWXYj y7qTw5srh1eHn0iuCXdlCSW5pjK8abhvdPURspfsqSg/Qp5kpKb6CJdN9lYMY+VcdnlNTSVOjVoP xX4vq7eXEaynewNKWT0o1b2h1uOJVi+g1kOx0+rF+yCg1gvE+y6pl0KeZPWyGMF6rvchRa2X4nq/ Tb39RwMV5fsDgdi7jqp1jmrvCpeoVbxerOL3qlVwqXjVKl5C1Sp9LlbJiVbp1Fqlk9oSRy7W8Wp1 zL5YHTNrKfhf/UzsHQxWTGWyMqR6vw5615SN1mi8PLunOu9mT88diUfhFfYFerAmbAj0DhsDvaG0 1K3+R4SiKSxikYRgtXv43csSj/JAdqm1TVhsjt7K6ZXTi91C6WW3LFhsjd5yL+vhTzxKdkVvyVhs wzba9HP+/AX4A+6KqeWtf+ZFfxZE6XyoDGcNrwyXDh1ZvV+SKsKhuvIaLOscKzMaKxqVE1phJyws YYUc11qxtUyvj1ZEbhwanE0Ge0khdqEmOA+7gg215eD8eeoVF+j/Ap9xwtUKZW5kc3RyZWFtCmVu ZG9iago1NAowCm9iago8PAovVHlwZQovRm9udAovU3VidHlwZQovQ0lERm9udFR5cGUyCi9CYXNl Rm9udAovTVVGVVpZK0FyaWFsLUl0YWxpY01UCi9DSURTeXN0ZW1JbmZvCjw8Ci9SZWdpc3RyeQoo QWRvYmUpCi9PcmRlcmluZwooVUNTKQovU3VwcGxlbWVudAowCj4+Ci9Gb250RGVzY3JpcHRvcgo1 NgowClIKL0NJRFRvR0lETWFwCi9JZGVudGl0eQovRFcKNTU2Ci9XClsKMApbCjc1MAowCjAKMjc3 CjAKMzU0Cl0KNgo5CjAKMTAKWwoxOTAKXQoxMQoxNAowCjE1ClsKMjc3CjMzMwoyNzcKXQoxOAoy NAowCjI1ClsKNTU2Cl0KMjYKMzUKMAozNgpbCjY2NgowCjcyMgpdCjM5CjQzCjAKNDQKWwoyNzcK XQo0NQo0NwowCjQ4ClsKODMzCjAKMAo2NjYKMAo3MjIKNjY2CjYxMAo3MjIKNjY2Cl0KNTgKNjEK MAo2MgpbCjI3NwowCjI3NwpdCjY1CjY3CjAKNjgKNjkKNTU2CjcwClsKNTAwCjU1Ngo1NTYKMjc3 CjAKNTU2CjIyMgowCjAKMjIyCjgzMwpdCjgxCjg0CjU1Ngo4NQpbCjMzMwo1MDAKMjc3CjU1Ngo1 MDAKNzIyCjUwMAo1MDAKXQo5MwoxNzgKMAoxNzkKMTgwCjMzMwpdCj4+CmVuZG9iago1NgowCm9i ago8PAovVHlwZQovRm9udERlc2NyaXB0b3IKL0ZvbnROYW1lCi9NVUZVWlkrQXJpYWwtSXRhbGlj TVQKL0ZsYWdzCjY4Ci9Gb250QkJveApbCi01MTcKLTMyNAoxMzU4Cjk5NwpdCi9Bc2NlbnQKNzI4 Ci9EZXNjZW50Ci0yMDcKL0l0YWxpY0FuZ2xlCi0xMi4wCi9DYXBIZWlnaHQKNzE1Ci9TdGVtVgo4 MAovRm9udEZpbGUyCjU3CjAKUgo+PgplbmRvYmoKNTgKMApvYmoKMzgwCmVuZG9iago1OQowCm9i agozMTk1NQplbmRvYmoKNjAKMApvYmoKMzQ4CmVuZG9iago2MQowCm9iagoxNjk4MwplbmRvYmoK MQowCm9iago8PAovVHlwZQovUGFnZXMKL0tpZHMKWwo2CjAKUgoxNAowClIKMTkKMApSCjI0CjAK UgoyOQowClIKMzUKMApSCjQwCjAKUgo0NQowClIKXQovQ291bnQKOAo+PgplbmRvYmoKeHJlZgow IDYyCjAwMDAwMDAwMDIgNjU1MzUgZiAKMDAwMDA2Mzc4MyAwMDAwMCBuIAowMDAwMDAwMDAzIDAw MDAwIGYgCjAwMDAwMDAwMDAgMDAwMDAgZiAKMDAwMDAwMDAxNiAwMDAwMCBuIAowMDAwMDAwMTYw IDAwMDAwIG4gCjAwMDAwMDAyMDcgMDAwMDAgbiAKMDAwMDAwMDM3MyAwMDAwMCBuIAowMDAwMDEw MzE1IDAwMDAwIG4gCjAwMDAwMDEyMjcgMDAwMDAgbiAKMDAwMDAwMTI0NiAwMDAwMCBuIAowMDAw MDEwMjQzIDAwMDAwIG4gCjAwMDAwMTAyODEgMDAwMDAgbiAKMDAwMDAxMTgxMCAwMDAwMCBuIAow MDAwMDAxNzY4IDAwMDAwIG4gCjAwMDAwMDE5MzcgMDAwMDAgbiAKMDAwMDAxMDUwMSAwMDAwMCBu IAowMDAwMDAyNzE3IDAwMDAwIG4gCjAwMDAwMDI3MzcgMDAwMDAgbiAKMDAwMDAwMjc1NyAwMDAw MCBuIAowMDAwMDAyOTI2IDAwMDAwIG4gCjAwMDAwMTA2ODggMDAwMDAgbiAKMDAwMDAwMzkyOCAw MDAwMCBuIAowMDAwMDAzOTQ4IDAwMDAwIG4gCjAwMDAwMDM5NjggMDAwMDAgbiAKMDAwMDAwNDEz NyAwMDAwMCBuIAowMDAwMDEwODc1IDAwMDAwIG4gCjAwMDAwMDUwODMgMDAwMDAgbiAKMDAwMDAw NTEwMyAwMDAwMCBuIAowMDAwMDA1MTIzIDAwMDAwIG4gCjAwMDAwMDUyOTIgMDAwMDAgbiAKMDAw MDAxMTA2MiAwMDAwMCBuIAowMDAwMDA2MzIyIDAwMDAwIG4gCjAwMDAwMDYzNDIgMDAwMDAgbiAK MDAwMDAxMTk1NCAwMDAwMCBuIAowMDAwMDA2MzYyIDAwMDAwIG4gCjAwMDAwMDY1MzEgMDAwMDAg biAKMDAwMDAxMTI0OSAwMDAwMCBuIAowMDAwMDA3NjczIDAwMDAwIG4gCjAwMDAwMDc2OTQgMDAw MDAgbiAKMDAwMDAwNzcxNCAwMDAwMCBuIAowMDAwMDA3ODgzIDAwMDAwIG4gCjAwMDAwMTE0MzYg MDAwMDAgbiAKMDAwMDAwODczNCAwMDAwMCBuIAowMDAwMDA4NzU0IDAwMDAwIG4gCjAwMDAwMDg3 NzQgMDAwMDAgbiAKMDAwMDAwODk0MyAwMDAwMCBuIAowMDAwMDExNjIzIDAwMDAwIG4gCjAwMDAw MTAyMDIgMDAwMDAgbiAKMDAwMDAxMDIyMyAwMDAwMCBuIAowMDAwMDQ0NTkyIDAwMDAwIG4gCjAw MDAwMTIxMDUgMDAwMDAgbiAKMDAwMDA0NTI1MyAwMDAwMCBuIAowMDAwMDEyNTYxIDAwMDAwIG4g CjAwMDAwNjI5MzMgMDAwMDAgbiAKMDAwMDA0NTQ1MCAwMDAwMCBuIAowMDAwMDYzNDkxIDAwMDAw IG4gCjAwMDAwNDU4NzQgMDAwMDAgbiAKMDAwMDA2MzY5OSAwMDAwMCBuIAowMDAwMDYzNzE5IDAw MDAwIG4gCjAwMDAwNjM3NDEgMDAwMDAgbiAKMDAwMDA2Mzc2MSAwMDAwMCBuIAp0cmFpbGVyCjw8 Ci9TaXplCjYyCi9Sb290CjQKMApSCi9JbmZvCjUKMApSCj4+CnN0YXJ0eHJlZgo2Mzg5MQolJUVP Rgo= --_002_C43C255C7106314F8D13D03FA20CFE4930CA31D9wtlexchp2sandvi_-- From nobody Mon Jul 18 00:25:20 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF9612D155 for ; Mon, 18 Jul 2016 00:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5i6qKvpPLsB for ; Mon, 18 Jul 2016 00:25:17 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B50BB12D13E for ; Mon, 18 Jul 2016 00:25:16 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-f1-578c845ae81f Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 06.E3.18043.A548C875; Mon, 18 Jul 2016 09:25:14 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.179]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0294.000; Mon, 18 Jul 2016 09:25:14 +0200 From: Maria Cruz Bartolome To: "A. Jean Mahoney" , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] WGLC #1 for draft-ietf-dime-load-02 Thread-Index: AQHRtdE4jPBCVA2NJ0e3rvn8VsJS8Z/qPcJQgAnlegCAAXp7AIAHc18QgAOELwCAAE15MIAaxhMAgAJ0uOA= Date: Mon, 18 Jul 2016 07:25:13 +0000 Message-ID: <087A34937E64E74E848732CFF8354B92197696BD@ESESSMB101.ericsson.se> References: <5b31616d-efa3-ac03-8f1c-bd8883a35d65@gmail.com> <087A34937E64E74E848732CFF8354B9219758407@ESESSMB101.ericsson.se> <3e2082d80d8e45caaca581c9dcc98468@CSRRDU1EXM025.corp.csra.com> <71796571-c370-cae8-d456-9d2dfb02544c@usdonovans.com> <087A34937E64E74E848732CFF8354B921975C3F4@ESESSMB101.ericsson.se> <71ffc339-37e0-e4fd-a16e-59da7fe23b6d@usdonovans.com> <087A34937E64E74E848732CFF8354B921975E5AB@ESESSMB101.ericsson.se> <192cffa8-1760-67f4-cc53-3ed16848ebd2@nostrum.com> In-Reply-To: <192cffa8-1760-67f4-cc53-3ed16848ebd2@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbHdQzeqpSfcYP9BBYu5vSvYLBo6V7Ja bGjicWD2WLLkJ5PHrJ1PWDxWve1jDWCO4rJJSc3JLEst0rdL4Mr40fCGteCWQsXyxjXMDYxz pLoYOTkkBEwk/u+ZzgRhi0lcuLeerYuRi0NI4AijxIm/S5ggnCWMEvu3zmAGqWITsJO4dPoF WIeIQIXEgf4djCC2sIC5ROvhy1BxC4nPpw8B1XMA2UkSbxeEgYRZBFQlli7/ywJi8wr4Svy+ fYAZYv47ZokHP5ewgiQ4BewlXi8/A1bECHTR91NrwGYyC4hL3HoyH+pSAYkle84zQ9iiEi8f /2OFsJUkGpc8YYWo15O4MXUKG4StLbFs4WtmiMWCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEj yypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwNg5uOW31Q7Gg88dDzEKcDAq8fAuON4dLsSa WFZcmXuIUYKDWUmEt6WhJ1yINyWxsiq1KD++qDQntfgQozQHi5I4r/9LxXAhgfTEktTs1NSC 1CKYLBMHp1QDY2ZFUVGfrGLQx2kXggqPiEtmXDm6bL6Aw+87qfcu35oXFcPlUf5G4sJpnxa/ 7OPeXCKO+90mVB7cEHgsp2zXean+1r4+mSfP1mw0Lz2+kiPw2NJVXC1aUtOnLr++pLP25oeg oEeZC7PCfpXcSPRfdnXa7guPE9cXv5y22svmRLdZZ2Xams8iYkosxRmJhlrMRcWJAHGcQaCZ AgAA Archived-At: Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 07:25:19 -0000 Hello Jean, Thanks for providing your view. See MCRUZ 2> comments below Best regards /MCruz -----Original Message----- From: A. Jean Mahoney [mailto:mahoney@nostrum.com]=20 Sent: s=E1bado, 16 de julio de 2016 21:48 To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02 Hi all, Some observations below: Agree with the thought- if "Little Server" is 30% utilized >> and "Big Server" is 50% utilized, it still makes sense to send more=20 >> traffic to Big Server. But I am not sure if that is withn the scope=20 >> of this document. SRD> I don't understand the concern. >> The load values supplied will be input into the route selection=20 >> algorithm as specified in RFC2782. If a node isn't getting enough=20 >> traffic it will change its load value to a lower value and will start=20 >> getting more traffic. MCRUZ> Unless the LOAD info provided is >> in fact a value that represents the available capacity, then the load=20 >> balancing will not select the less loaded server. Being able to=20 >> select the less loaded server is the whole purpose of this mechanism,=20 >> then we need to find a way to provide a LOAD value from different=20 >> servers that we are able to compare, i.e. the value provide must=20 >> indicate the available capacity regardless the static capacity of=20 >> each server. SRD> I view the goal of this a little differently. The goal is to > make sure that requests are delivered to nodes with available=20 > capacity. It is not strictly necessary that every request goes to the=20 > least loaded node. MCRUZ> Well, I do not agree. The whole purpose > of providing LOAD info is to be able to choose a node with available=20 > load (I agree), but among the node with available load we need to=20 > choose the least loaded (or one of the least loaded). It does not make=20 > sense, in my opinion, to simply select a node with available load,=20 > when we are providing info about load. The information provided should=20 > be valid to be able to select the least (or close to) loaded. [ajm] (With my implementer's hat on) Having clients chase the least-loaded= server can go wrong, especially when lighting up a network, and a server's= load goes from 0 to fully loaded really quickly.=20 Depending on the design and timing, all the clients think the first server = is the least loaded and they *all* pick it. Boom - the server is now maxed = out. Clients should *distribute* their load across servers. MCRUZ 2> Yes, the purpose of the draft is to provide a LOAD value that is v= alid to distribute load across servers. Now, distribution cannot be completely even, but that's OK. Because we're t= alking about load here. Not *overload*. If you've designed your system corr= ectly, a fully loaded server is *not* in danger of overload.=20 MCRUZ 2> The issue is to be able to provide a LOAD value that allows the cl= ient to perform load distribution. If we do not take the weight into accoun= t, somehow (implementation dependent), the distribution will be very far fr= om even, it may cause very important traffic oscillations (e.g. small serve= rs will appear as low loaded but if traffic is sent towards then they may r= each overload threshold very soon) and big server will normally be underuti= lized. Therefore, the expected load distribution is far from being achieved= . For instance - you've designed your system with 3 servers in a cluster that= can handle one of their cluster mates going down. When "fully"=20 loaded, each server in the cluster should never be so loaded such that they= cannot handle one of their mates going down and taking on half of that mat= e's traffic. *Overload* should be a rare event - like a tornado wiping out a chunk of yo= ur mobile network, and everybody calling and texting everybody else to make= sure that they're ok. Thanks! Jean (who has actually had a customer point to the aftermath of a tornado a= nd tell her, "Your solution has to handle THAT.") From nobody Mon Jul 18 02:14:59 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B302412D1D3 for ; Mon, 18 Jul 2016 02:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynCc8AHMiHke for ; Mon, 18 Jul 2016 02:14:56 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9550012D0C2 for ; Mon, 18 Jul 2016 02:14:55 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0294.000; Mon, 18 Jul 2016 05:14:54 -0400 From: Yuval Lifshitz To: "dime@ietf.org" Thread-Topic: slide for RFC4006bis discussion Thread-Index: AdHfmdgffm5vJqrITTiB8hPBrUVu1ABOre8A Date: Mon, 18 Jul 2016 09:14:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/mixed; boundary="_002_C43C255C7106314F8D13D03FA20CFE4930CA5EC0wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] slide for RFC4006bis discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 09:14:58 -0000 --_002_C43C255C7106314F8D13D03FA20CFE4930CA5EC0wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the comments. Updated slides 3 and 4. -----Original Message----- From: Yuval Lifshitz=20 Sent: Saturday, July 16, 2016 10:52 PM To: dime@ietf.org Cc: Bertz, Lyle T [CTO] (Lyle.T.Bertz@sprint.com); Dave Dolson; Lionel.mora= nd@orange.com; Jouni.nosmap (jouni.nospam@gmail.com); Yuval Lifshitz Subject: slide for RFC4006bis discussion Dear group, Attached slides for the RFC4006bis discussion. Please let me know if you wa= nt more topics to be added. Regards, Yuval --_002_C43C255C7106314F8D13D03FA20CFE4930CA5EC0wtlexchp2sandvi_ Content-Type: application/pdf; name="RFC4006bis_1.pdf" Content-Description: RFC4006bis_1.pdf Content-Disposition: attachment; filename="RFC4006bis_1.pdf"; size=65693; creation-date="Mon, 18 Jul 2016 09:13:40 GMT"; modification-date="Mon, 18 Jul 2016 09:13:41 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjQKJSDi48/TCjQKMApvYmoKPDwKL1R5cGUKL0NhdGFsb2cKL05hbWVzCjw8Ci9KYXZh U2NyaXB0CjMKMApSCj4+Ci9QYWdlTGFiZWxzCjw8Ci9OdW1zClsKMAo8PAovUwovRAovU3QKMQo+ PgpdCj4+Ci9PdXRsaW5lcwoyCjAKUgovUGFnZXMKMQowClIKPj4KZW5kb2JqCjUKMApvYmoKPDwK L0NyZWF0b3IKKP7/AEcAbwBvAGcAbABlKQo+PgplbmRvYmoKNgowCm9iago8PAovVHlwZQovUGFn ZQovUGFyZW50CjEKMApSCi9NZWRpYUJveApbCjAKMAo3MjAKNDA1Cl0KL0NvbnRlbnRzCjcKMApS Ci9SZXNvdXJjZXMKOAowClIKL0Fubm90cwoxMAowClIKL0dyb3VwCjw8Ci9TCi9UcmFuc3BhcmVu Y3kKL0NTCi9EZXZpY2VSR0IKPj4KPj4KZW5kb2JqCjcKMApvYmoKPDwKL0ZpbHRlcgovRmxhdGVE ZWNvZGUKL0xlbmd0aAo5CjAKUgo+PgpzdHJlYW0KeJy1Vl1PFDEUbcJbX4RoYkj0yRgg0dLvj4QX DbCia4BlZDUuD0YChAzoool/39Mu43R2Vz6W2W122t5M77lzzr1th1QwTmN7PRpobtB/v6BDyhnn IlhvuE5vjM/xUuwuqLLGWZ6Wl/VEcuN0HJR0bBKfZ7RPLwEypOtvyp9n3zg9/ZViqf5XpzN5P6Mn dB9tmPkW0ffoK+FVSG09U0pTGZxXLGEYJYNkma3MbEII710y1oszY4UZUZWvCK1Hic1qEnslmZNG ekOdZ8Jxe014FeLbAn1xRde3f1z+ltRqrClOmlJZxYTSwYMSFpSFj2KkR3FMV0mHfCKbZIf0ySLZ Iu8w65MjjDukS/YwX4Rlh2yTp+Qx2jLe6ZLDNVqc063ifnF4JZgWVtqpgczkUmvHpDMWHKuRy4f7 VBpSGuUUFYEnp65B2CsyWCWODNbIM7I8E4IxkongzHSAyuUteXJ74vLICsogz9vMVmY2bbgNWdo2 TLMlrdYilggz2gRVbRNIw7gxyP8MJ/lTDiWEn5wgMST5mVchhOmi3x9NTlMrAjmUr25kwWA1VUif 9FAfh+R566hYYpX0k9Dz+D7B7fgHrpPBgOxiA1hAsi/h+fLf5vCILGR5z0yQwtiAkTXAvjOwMPHT kCM3wi8l+Br8Bdg+wLhL9jFfws7UI3tVOII547yQhv6Bo/f4nyPhmXbKCUU/0q9HnB5PD7rXaQTk mfFxdEG15ExoDkJra0kPWuM/9z9Ow1y0Vmac7BWcAF/AaAcyr4DPXXDcA79tCR33G8eVmIbdQasR o7qb6Dspnv2kf5sKZ5G4pKVNCos45iqztqtw7X/8++eicDx1mixvkM9gdBM8L6C0ujjRD8mHtH+l cm5JZ8eZ5jJeeSYjSOXcBJ632Fk4tik2jLm1dbGv/Y+T0MLRrpT3AfdKKrzFvZBZly6+3GvbMJa1 UXIpnbw2Vstz470PePhgOoBujQGu2cbNfMDj3pYOeDVJpMAlSXmILw3TVuDq2EioJw8onRtQwR63 ajrmnfWL7S+NV3HCCmVuZHN0cmVhbQplbmRvYmoKOQowCm9iago3ODAKZW5kb2JqCjEwCjAKb2Jq ClsKPDwKL1R5cGUKL0Fubm90Ci9TdWJ0eXBlCi9MaW5rCi9SZWN0ClsKMTQyLjMyNTUzCjk4LjQ5 NjA5CjMzOS42NDg3NwoxMTguNjA1NDcKXQovQm9yZGVyClsKMAowCjAKXQovQQo8PAovVHlwZQov QWN0aW9uCi9TCi9VUkkKL1VSSQoobWFpbHRvOkx5bGUuVC5CZXJ0ekBzcHJpbnQuY29tKQo+Pgo+ Pgo8PAovVHlwZQovQW5ub3QKL1N1YnR5cGUKL0xpbmsKL1JlY3QKWwoxNDguMzQ2MDQKNzYuNzQ2 MQozNDAuNzI5ODMKOTYuODU1NDgKXQovQm9yZGVyClsKMAowCjAKXQovQQo8PAovVHlwZQovQWN0 aW9uCi9TCi9VUkkKL1VSSQoobWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tKQo+Pgo+Pgo8PAov VHlwZQovQW5ub3QKL1N1YnR5cGUKL0xpbmsKL1JlY3QKWwoxNTIuMzQ1MDYKNTQuOTk2MQozNDAu Njg1ODgKNzUuMTA1NDgKXQovQm9yZGVyClsKMAowCjAKXQovQQo8PAovVHlwZQovQWN0aW9uCi9T Ci9VUkkKL1VSSQoobWFpbHRvOnlsaWZzaGl0ekBzYW5kdmluZS5jb20pCj4+Cj4+Cl0KZW5kb2Jq CjE0CjAKb2JqCjw8Ci9UeXBlCi9QYWdlCi9QYXJlbnQKMQowClIKL01lZGlhQm94ClsKMAowCjcy MAo0MDUKXQovQ29udGVudHMKMTUKMApSCi9SZXNvdXJjZXMKMTYKMApSCi9Bbm5vdHMKMTgKMApS Ci9Hcm91cAo8PAovUwovVHJhbnNwYXJlbmN5Ci9DUwovRGV2aWNlUkdCCj4+Cj4+CmVuZG9iagox NQowCm9iago8PAovRmlsdGVyCi9GbGF0ZURlY29kZQovTGVuZ3RoCjE3CjAKUgo+PgpzdHJlYW0K eJy1Vt9PE0EQnqRv+4QBRJ58ISoEl/3941EDLRgSBAvVWB+MBggpaNH/P3675ej1rirWu17udmbu br6Zb+amO2aSC5aOlxPBCIv1yzUbM8GFkNEFK0x+oqrjobRcM+2sdyK/PpoqSlhvkjBiFSVdL9mA 3QBkzHZejb5ffhbs4keOpThvLxbyfsnO2TGOccm3TL4nWcKrVMaFBOKDSEBAsFpFVTKNpiYjvIjZ VLw3tRRYCU2HgsiplFkslLRqxb0yRjLjIADN3TFdxPa6j7V/y3a6325+KqY91+mnWP98tlApAGN4 0DFGx/qTSvS/shfk6YTe0SF16WyT9a/YXn8B91IGHo0Waj5I4fgvyT+kCsaJGGerUJhKVZBBeWtn ylAyLV4HqQSP0XhbdLw2MfW4+o1Y51AZ+KvRp3gMRsMtkPC1lOuzQo/u69IQnPWTnCpIG3REp7RP u9Sj4ZA6dIC2+AhDD/IhHePawwO7sA9oifZw5xTSJ8g93H8LfQmWA7TSGi3jWMczh3QG6zKtNJ6E FdwaF+uJNI00rY6zVc5WW6pOHWm4CS6PwHdifYksvYe233iuznMXtKsH0B6rMVRzfdwSq3WkLVDp cAY091OcodCbxlcyzgugPValltVk11qidQ7UVh4UXTTrQW7UDj2H/CZbezgHaOaTPFIm12d58qQx MoC2k8cJ5KbDNfgjtTJaPSfmFkvhTJWfJ22Vog61TYKGaemA9+M8zO9NjmLjjW5wdc7MCaVFhqOv pr3eFsN1qG3S9AGAHUzlSROnZu7mVt6A3sv6WWmD1RTX0XLvcjvXompgz6V1CJhY8B6cVYE7n7fX IuArKhtHU6MSSnl1ZyxeLxv/ee8FH9xE/M8bCNjMW7/w3kvqyf5V1+eC5DLqoCxTlhsnjZzdJK/+ R+X+gAr2hNPzMR9cv3T8AhTugfAKZW5kc3RyZWFtCmVuZG9iagoxNwowCm9iago3MDQKZW5kb2Jq CjE4CjAKb2JqClsKXQplbmRvYmoKMTkKMApvYmoKPDwKL1R5cGUKL1BhZ2UKL1BhcmVudAoxCjAK UgovTWVkaWFCb3gKWwowCjAKNzIwCjQwNQpdCi9Db250ZW50cwoyMAowClIKL1Jlc291cmNlcwoy MQowClIKL0Fubm90cwoyMwowClIKL0dyb3VwCjw8Ci9TCi9UcmFuc3BhcmVuY3kKL0NTCi9EZXZp Y2VSR0IKPj4KPj4KZW5kb2JqCjIwCjAKb2JqCjw8Ci9GaWx0ZXIKL0ZsYXRlRGVjb2RlCi9MZW5n dGgKMjIKMApSCj4+CnN0cmVhbQp4nLVXW28TORQ+UsSLXyiXDWnLI1ou23V9vzyyahNaKrXZJi2I 7sMKBBUKlwL/DH7gfvZkyCQz7NLuTKzYZ87YPvb3HfvMuWCSC5bK74VghEX78h27YIILIaMLVpjc Y/UZnVLzjmlnvRN5+GzxoIT1JgkztvKQ6nN2yt7DyAXbfjz7eP63YG8+57WU/09vrjT7OXvNxigX lbllmrvYJWaVyriQjPggkiFYsFpFVVHNFiojvIhZVY5baEpbyZoOJZALKaNYPqRWK+6VMZIZBwHW 3Bzpcm1/TNBOPrHt4Yf3XxTTnuv0U2zyepmotABjeNAxRscmBROTV+wB3aNDmtIT2qERnZ1Rj/bo gF5AMYJ8QGPUI3TYgf6U1mgXb6aQ/oI8wvsjPK9Bs0dDukO3UNbR54BOoL1Ftx+yyVu2O7nCir13 3Gnlm5ddzvsfcP4Mr8aJGJd5LVUVXmVQ3tolYiuqqzMrleAxGm/LM6RNTKdG/UCsQ6gM5ltFTyoe g9GYFpZw/qqM36Yb32lpyZz1xZ5WLAU6hpPswF0Kd0p+tpcd6Akca4j6BNpT+hP1Om1QHyU54BSa I0h9GtAmbba9WuMiV85iQG3JbZta8ODMKjq/dMRD3dJleNiAfwxQqjwUB3vQHQ+1JXfHQ3Sr6PQ7 4qFu6TI8fCVP2+ToJtpfSdN16O5/1znoPLQ99J2i3oLsMH5I35aY+1p5U/Yt5vjW9p6DjzwqG+r7 7o5MqcIqxnc6YrPBVJXOHgJpzIQcZ0J7dPYAzTS/3skM3c83Wh/n/m7bK9RRcxkaAekQ/PRhtYzI oCvw66aWwU9e/hwxpOFMtb0gFT2XRmBAfVUdgh1r0XW9K7DrppbB7tMjwJ18fUhPoZ3Sfv5S3G+8 0nroMc7X3RaJdCq2Wl+1NNzGZpS6Y0SpWpzd6IiRBlMWyB7hQn+eEb6WcE1wTyEuAL+Ge/43UqBv O98+ErLPPYYYekjPMMU4x5xFxCivsXRr7aJPEZOKROAYuv1scADvW0O90X4UQarTBG6HRNpaoN7s isi6qXtgajTnLNXHOYCMc3L1IjNTRO3iqI0z/ifzg3aYj+TB3AmK7wZLZw/xcTDPxVrfRYhI2Gw0 DVtpISfTOoQYuEZu5SxCmfM5oRcBCXBVOVsolVDKq7myHF5VXjo3wxzcRBeZgWC9s/7KuZnURXqr 69++ksuog0rux42TRi6n5f3/wdy/WAV6wulmmz/NXyr/ALASM8cKZW5kc3RyZWFtCmVuZG9iagoy MgowCm9iago5MzAKZW5kb2JqCjIzCjAKb2JqClsKXQplbmRvYmoKMjQKMApvYmoKPDwKL1R5cGUK L1BhZ2UKL1BhcmVudAoxCjAKUgovTWVkaWFCb3gKWwowCjAKNzIwCjQwNQpdCi9Db250ZW50cwoy NQowClIKL1Jlc291cmNlcwoyNgowClIKL0Fubm90cwoyOAowClIKL0dyb3VwCjw8Ci9TCi9UcmFu c3BhcmVuY3kKL0NTCi9EZXZpY2VSR0IKPj4KPj4KZW5kb2JqCjI1CjAKb2JqCjw8Ci9GaWx0ZXIK L0ZsYXRlRGVjb2RlCi9MZW5ndGgKMjcKMApSCj4+CnN0cmVhbQp4nL1X224TMRA14s3wUCRuQuIN cZFg67vXj6A0aWlE2zRNUNUXBIIKhUuBT+FPQHwfZ2az3U12y6VkiZW1PWv7jOfMzNonUmdKUnlU NJzyqF++kydSZUrpFHKvHI9Y7mMQVe+kDT4GxdNnVccoHx01ZnKpQ89jOZXvAXIi1x/PPh6/UPLN Z9al/H96c67Vj+VruYdyUltb09rFLrGqNi7kBBJzRUBA8NYkUxPNKpFTUSUWlfMqSYlFaDYvDVm1 2Iplh2prsmic09IFNIAW5pYudXsyRj3+JNf7H95/MdLGzNLPyPHrRaJIAeey3KaUghwXTIxfyfvi 6IEYih0xFZviQKwJL56jt/lAjt/KjfE5kDS2o73yth2vXPg3dvgTQlxQKS0SUopqhOjcRO8XGKmJ zk+JNipLyUVfOr91idzdnNFs2tA4rNc0X+aVTSoQEgKnZroLX09ZWRGYj8WOFnHE0X2xJ7ZFD88+ 3OIinGOb6x76U7jLCG8uoqYn/GdN5Pg/ROcQQhpcTdnD87AY1uJmeHFHJGFRb0E+ErtoeRp8V9wU t7jMgTrZe/DLex9BjQErSXsY4TmBqvso9GaKvkMroN6AOSYYOWCVi+1MeCMjnl0ZZuWq65jphAhr qL9qpMobU/5/vLGBA+cgx9hg++6K27BsH9Y+QNmEXxAjxNcWe8mw5p4D1AUje2hNW5jsYcyA5z1F b5fllUtOVr2/aFJmkS8aW+yONW31/6GtCSQMLF2yMTmNJrL3hBmcoNxetTLGpyz6mLco9A9QMGjg XwMPEeicSsDzeZbMggGuiiudYGo+crUA3mF/bubeMsUOOV5Gy0mb8vyAExq5f088mye3PlqHqA/4 bZ+z8z76ROoGZ3MKt6OjbgyrfaYjoqW5z46JzN2yXa91S2QT8B4HzQ9OUrvMSP0r3J9/m5/Wjmmr VMukkOXBGduiWre2N1otm+J6p7ZvASyDqAyaEVLVFKlqyJ8Z6m8tB9Al8e10wBrooZD5frrE5Tl1 vTmdlPmmHGK0HH3DihNDf36WGDLAPgfjpPjGdWKBSAdYrW2LETpm2YZlo9/oluUmYMly7Xha8VlS X+TKIR+Dd8DbYCEMf32y7WQ7XrvMR2Niy5ZWcLGyNs9xOKG4D95Ai8jXaZXj+lkXziqhUdDGzIXl 9Lrwry9YWCNzKSTp0MDl3cdzX7C0LS6ptmFIhztqsrnxODBkLminFy/FN/6FvrNRYT0VbDvmH/NH 5SdRUCOqCmVuZHN0cmVhbQplbmRvYmoKMjcKMApvYmoKOTM3CmVuZG9iagoyOAowCm9iagpbCl0K ZW5kb2JqCjI5CjAKb2JqCjw8Ci9UeXBlCi9QYWdlCi9QYXJlbnQKMQowClIKL01lZGlhQm94ClsK MAowCjcyMAo0MDUKXQovQ29udGVudHMKMzAKMApSCi9SZXNvdXJjZXMKMzEKMApSCi9Bbm5vdHMK MzMKMApSCi9Hcm91cAo8PAovUwovVHJhbnNwYXJlbmN5Ci9DUwovRGV2aWNlUkdCCj4+Cj4+CmVu ZG9iagozMAowCm9iago8PAovRmlsdGVyCi9GbGF0ZURlY29kZQovTGVuZ3RoCjMyCjAKUgo+Pgpz dHJlYW0KeJy9V0uPG0UQbmTl0pfdXFAuiFsEUZj0+8EN5HgdbMlrr9deIBwQKFlFTmATfgo/mK+q Z9ZjexIWY6+tme6u7q7nV9U9N1JXStL/m9JxyqP97a28kapSSueQvHK8YnuMRdS8lTb4GBRvX60H RvnoqLOSWwN6X8ulfAchN/LZd6s/r39V8vUH1qV53r/ei/u1fCWn+N+0eGviXawEV21cSCQkJkWC IMFbk02LtFqTnIoqM6nZt6Y0skiaTY0j1z32YjOg1poqGue0dAEdSAu1pxvdvp+jnb+XzwZ/vPvL SBsrSz8j5682A0UKOFclm3MOcl4iMf9dfiWeiFMR8CTRE1/iSc34azl/I5/P9xBm4PEcXO6W2PD9 F0/cJSQuqJw3Q9KQWiHRyUTvN2LSIu0fFG1gZnbRN/C3LhPgzUe6uy40Dvy2vadT5ZXNKpAkpE7L dZ/9fRuUAwnzsVi0KQcAGIqBWIqxmIkpQPFIPBSfiy9Eb2/59iPGZlU5HXPsUOIBhNK/J/p4plDp J7SPxSV6Z1BtCZQ+ZgWXoM3EBGOPubm4wnsBak8o4DmIiN5z0HqgDnl9D8+M3yOmD9pcD20kOzn4 bfsGG7oX3S7Fj/zuwdYR69qtY4/7zY5+K1QjjBa1vWU/cSIJE/HyJbOhhQs46ZzZnYA2I5FHMTun bbOvxEWt6lD8jP4YstsGzMSLltEZcxPMFbNhwCmiOWbVH4oHh1bZuVTZZNKu2odOvHWWa6vvJ813 BYmn7PELjkDJ9wEce1Kn3N0AN2a40cwEa2cITeFIFWRc0zuBR5n97TbKj2N5cNuWf9oaQuaAE+js NkeKF7rnKd3YxlKpiNWp+IXZz5h6jvaKsv3Q9kWtqogbhu0w8oiYzfGeMLsjCOk/qkv5Eo6dwvt9 uJliQOijqE6F5FiV+jJhVFP0ahwusIE7pcQW4F1uFFra0xwU581ygswFl8plHWk6W9KRMGus2rb8 B1aB0LrWt79xRAzZF0V7WvGEFTxhfF7V+F3W2TqEZYvbg7Acj1RYOzzW59NjBocB7AdHMC63wSXn Okw+HoJNsPeD4F1BwnJZICgt2LVNVXlRzmHQzrjqThHxgkaK6hjziEZDvmBin0HRx2h0G8pF1+Xt 0LYFHyqlfZcjD3DBtzYlHMEoail4k6oQ+cNOJWClTVytiUYZE01NbLa3if/5og8elcsBnzHo4DPS x70v+tqWbyW7e+PQlc64cnhpfOWCdnrz8+zR/wjcJ6TCeyrYbpl3jh/9/wHPes5JCmVuZHN0cmVh bQplbmRvYmoKMzIKMApvYmoKOTU0CmVuZG9iagozMwowCm9iagpbCl0KZW5kb2JqCjM1CjAKb2Jq Cjw8Ci9UeXBlCi9QYWdlCi9QYXJlbnQKMQowClIKL01lZGlhQm94ClsKMAowCjcyMAo0MDUKXQov Q29udGVudHMKMzYKMApSCi9SZXNvdXJjZXMKMzcKMApSCi9Bbm5vdHMKMzkKMApSCi9Hcm91cAo8 PAovUwovVHJhbnNwYXJlbmN5Ci9DUwovRGV2aWNlUkdCCj4+Cj4+CmVuZG9iagozNgowCm9iago8 PAovRmlsdGVyCi9GbGF0ZURlY29kZQovTGVuZ3RoCjM4CjAKUgo+PgpzdHJlYW0KeJy9WFtvG0UU HuS3eWkjkYhK8FZBW2Az953pG5VjOyRSasexQzAPCNRGyG1J4ZGfwQ/mO2d37bXXhpJ67dHuzJy5 nDnnO5dZ30mdKUnl26LhlEf9yxt5J1WmlE4heuV4xnofk6h6I23weVC8fL7sGOVzR425XOvQ+1ZO 5VswuZPH381/v/1Zydd/8Fmq5/3re+1+K1/JIcpdbW9NexdSYldtXIjEJI+KGIGDtyaZGmm+JDmV q8Skat2SUvEibjZWily2WItVh2prstw4p6ULaIBbKDVdne3FGPX4vTzuvXv7p5E2zyz9jBy/WgWK DuBcFm1KKchxgcT4V/lEPBNXoit6YiBOxbW4EB2Ro30lXopzMcTIFPUIrU75/hJjA9EHdYreMWqa OX0qx7/Jk/E9jhZUzLwLud98wGrj/1DchyDogkppFcGKVENQR5N7vwJhjXR/DLVRWUoOcpbeYl0i /zBbmk0dGof91tWnoT1lkwrECZ5WU90nfy9Q2REznxcSrfKBTVzDKsguhrCKCzGbwTS+bxjWdIth XYI64pkTlA7qHzE2wQzqnWLsCjWtOudVXd7tnJkNmPEI3NZNlY6xa/mjJjP2yTWVsGtWS1yD3w+u DT5CQamM5Qn03IFOB+z69BT67wA10vUEtDFQLgzg37AhRLv8vsH4BcoB2rOnJcgEfRcmcomBgfhi 13LmAdTcmaasH8EJSAX+NUNbynKrvZcILMmsQPhXKww1Z+MGN+j6jLEhHzxjLMlZL1np0xLPKB6K gCey/5wyTkO0ihUEzoTrH4Bkj/cgsHqlTUxqez+rdmpHqSZlIcbomnK2C6LGnD2i2GQnni9gpPxL EPbY3cglT8rgOIS7FZTChyp4K3AoJJPTXpOLtnJ8523mkMg3SNBekNRe7SdKNhkJXyqbQ+UN43CG 1lfiG/EYMXT2BFeqGU17gUzpqUlDObrHqFXZ5oHHmPF1MYNAHHFO7JR+2OHMd4H2zTIvtiNktOtC NtP5ejjYlt4fcqg4wA4HpSgdkSDyg9IalzPJWnviYNciBfiT8RuEas8cjQ77MccmI3GEAGxR6CYf 8D4Sh9D8ofgcZaMJiZ8YuVE9dC/SdJeRIUz7jHQdWbLzLhtmFV222EA7oru0Lvr6TXKCY43YXPvc m+JQV+UN5SVK8SHT5WOz/z6oeTAtnLKWrnlRlQa3Xm52flvROku5QYhtitqi6cY9fUc0GcFoSaV0 L5ksbvnFzWLEpthfpLLu4p5ZBKJ6GPkM5v4Iz6cMZ9U7LI25X6Md7TzU0HduQgbcIN0OvmStjTHF zAKu4A0ycM5/eKjowgpxviQaZUxuSmK1vE7831+02CNzKSTp0PB58Pm9v2i1Lf4VsM1LhM50shFh 2/jMBe306t8Wjz7m6rKdK7Sngt3M84Pxo/IPiW5fhgplbmRzdHJlYW0KZW5kb2JqCjM4CjAKb2Jq CjEwNjYKZW5kb2JqCjM5CjAKb2JqClsKXQplbmRvYmoKNDAKMApvYmoKPDwKL1R5cGUKL1BhZ2UK L1BhcmVudAoxCjAKUgovTWVkaWFCb3gKWwowCjAKNzIwCjQwNQpdCi9Db250ZW50cwo0MQowClIK L1Jlc291cmNlcwo0MgowClIKL0Fubm90cwo0NAowClIKL0dyb3VwCjw8Ci9TCi9UcmFuc3BhcmVu Y3kKL0NTCi9EZXZpY2VSR0IKPj4KPj4KZW5kb2JqCjQxCjAKb2JqCjw8Ci9GaWx0ZXIKL0ZsYXRl RGVjb2RlCi9MZW5ndGgKNDMKMApSCj4+CnN0cmVhbQp4nL1WSW8TMRQ2ys1wKFKRAIkbQiCB6305 gtIklEjdpkkpvSBQW6G0kMJP4Qfz2bNkJpOKkibEyrxF9vue32J7SgXjNI43OaO5Af1ySaeUM85F sN5wnWbMy5gUySVV1jjL0/LJTJDcOB2ZCZ0T4veCjukVQKZ06+3kx8VnTs9/Jl/K//X5UtYv6Bnd x5jWbItoO98lrAqprY8gzvMIBASjZJA11WSm0tzxkFTlupmmxIpoypeBnHEpiqUQqZLMSa0F1RYM 0GwR6dK3dxlodk23et+vfkmqHFPxJ2l21kxUdEBr5lUIwdIsz0T2lb4krwknp5F0SJfskz5opbIk vKLZN7qdLQEpg2HSG6sXA5eG/xKQ22RGWx5CMzOlqpYZ4aUzppGammr53AjJWQjambILlA6x7uUN bDuGUsPefPiEZ4arwG1EQgfVQnfvd5WVFYEZl++oiUNekGNyhDFAYYzJLjk9RXUcQCjYeqFAHJIR vnvF9GGaOUgVNQTXge4D5A5Wx5njZOs9vh7SADAb0VgGzCE5rMxswPw+ph2AcxH2MNpYSwCsmQ9A 4emq0bxF00iu2oirRppVUfD/p4paOEQiZWU5jFIZHODbT6HtIdsjjGer9kWawJxxvu3PHZAQTZt+ LTgkUmsePBVKzO9/kzxcC6ZIV+8CQIuTHI0yKlqum1ptBLqX2m9cdVHRscep/2KfxjY7At0GjUtj hzaTV94R/dSxQ/Ix2TlJnZ3391GyO66s1y6Y3Hjz1FhnaIxnQTZC00XF9ZIf/XQo7VT1uJvOm51i 2/eRtceVx5vkSVGxO2lrI/JgLW6r4Jg2Apdp2/U1l63X86F6tN6ybQM+R4T7qcQ66eI4adZqnqYB +QQ5nsu9lIriJhqhiA8xYr7GtRpbyw4QMhac1XrBLlbwrFHKe5xaCtatkfDCpVct93gF1pWTmVJy KZ0slOXyuvKfnzewwXSwgWoweEMbt/TzRqj8iajagRRMBOWlwXHNtBVaNN+mT++SvptRET1u1WLM W+cvjj8PTlsvCmVuZHN0cmVhbQplbmRvYmoKNDMKMApvYmoKNzc1CmVuZG9iago0NAowCm9iagpb Cl0KZW5kb2JqCjQ1CjAKb2JqCjw8Ci9UeXBlCi9QYWdlCi9QYXJlbnQKMQowClIKL01lZGlhQm94 ClsKMAowCjcyMAo0MDUKXQovQ29udGVudHMKNDYKMApSCi9SZXNvdXJjZXMKNDcKMApSCi9Bbm5v dHMKNDkKMApSCi9Hcm91cAo8PAovUwovVHJhbnNwYXJlbmN5Ci9DUwovRGV2aWNlUkdCCj4+Cj4+ CmVuZG9iago0NgowCm9iago8PAovRmlsdGVyCi9GbGF0ZURlY29kZQovTGVuZ3RoCjQ4CjAKUgo+ PgpzdHJlYW0KeJy9WFlvHEUQbjRv/RIiQkIU8hKFIxJM+j54QIDW3nGy0npvYpsHBEostAnYIH4J /yKP9g+kuqZn53QI6x3vaKe7q3u6jq+6qmbOKE8ZDdfXeUcxDe0vr+kZZSlj3BunmcIVzTEsCs1r Ko22huHj63IgmLYqdNa0MQj3U7qib4DJGX36/fqP058ZffUnylL8z19ttfspfUkncJ1V9uZh71xL 2JULZVxgYh0LjICDlsKLCmldkhSzzCOpeK6kFLwCN+kKQ5Y9tGIxCK0UqRVKcaoMdICbiZYuZPth Du38nD7d//3NX4JKm8rwE3T+sg5UEECp1EnvvaHzHIn5r/RL8hWR5AW5TxKiSUaGZEQW0O6TFVAe w3iI4yVZPqHz3+jefAvm0rFUGqt1twjFxv9hmvfBSBnmfR2jglTBiDsBwtRAqpC2R4kLlnqvrC7O g1Q+nABxRbdtQ6Fgv6b5uEs1k56ZwAnOUsV0H/yzQWVHzLTNNarzISb6xIhMyQQ84wG5Te7C/Rb0 V+Q5zCZkRgbgKwPyDO8zoCZxddOzPqx7FowtOTmBRzJ0Og8u+ZAkW6smu1WzDJAWUqkO/S5AglyL QU2yBKRe7l4UtLLRTSkGaM2MHOPpCzLMoiQZ2HEF8yUCU3JQsX1b6rAmgzZfsajhFNYdIHWByITd FrjLGPkv4OkB9iry9GID75o2OEBZDoHzt5vYVHjLd+B1l7uWQ0iXSiccbwuz68NVnmQu+c0c5Taj TrsmFZ9YIupT9Io9GE3BK7LoDZqcPCGfw9H/hNyB+20gfYMTR+BqY7gSOODPwXkmEAay6HSjypZx g3vkY/IpubNrlZ3QkGmk7FC7RyyNuiEsW4zIZ+RHjBVlHNgDM7+IkISTNMRY8OwKhFe4KtmcunDq lxjVLzrixCVymGDEuOiIFpfhyX5U97ap+lEMbBkwDwoFxVeYdBpOWspcd76aSQqDnJzjJmEiC4Om aR7uWj0rRGos9x0qXoMVeKfBX9tvuU2t5FCMCZDHi5rf/t0PSy1DnG2xq2TdrpxUZoI8gBxDUXD1 /xZ5e43c8C7xlfWpls7bDhX6hkizG4WoxQ4geotlyRKrs32AYoBRfhkKtrwmOd4gNIDIM8BEEOLQ OCaAKSaFKSA5q1QoRcT6CTGfAq0v/IzgMKVVh3p9w+daBXuv8LXYAXyPsRJsxupRzBHlGVth2l5t sFwiYhmuPUTUEminiGCO5wT3mMB8Xp0mMSQHfkMMy+NN7jmKlWiCznQIo+P8lPdoDgmv3Z5772oW yVDuEfrcBDXLZc/r6bwyulfJGeX78QTWDKMl3h2RhlAYlf/+IpPRPLWQQLpV7a/ikeqGqtc2I/IF xpOjWOEMInp5lCnQLN6RihhzF/GdVWZG8b001gMfwXUfQlaA9RFMGCirZnAFd1/F19hxiHgJlA7N kuDRzqtYK1OlLZMd+u/gY4mUzsGrDhTJzmgBzmXxqxlzytSI65IomBBWRGLxeJX4vz+awB6p8sZT BR1tjbZbfzThMv/wJNuZm6fcw7tdSKSpMlzx+revB9c5lVdzBesxI7t5vjd+4foXCUXECwplbmRz dHJlYW0KZW5kb2JqCjQ4CjAKb2JqCjExODMKZW5kb2JqCjQ5CjAKb2JqClsKXQplbmRvYmoKMTEK MApvYmoKPDwKL0NBCjEuMAovY2EKMS4wCj4+CmVuZG9iagoxMgowCm9iago8PAovQ0EKMAovY2EK MAo+PgplbmRvYmoKOAowCm9iago8PAovRm9udAo8PAovRm9udDIKMTMKMApSCi9Gb250MwozNAow ClIKPj4KL1BhdHRlcm4KPDwKPj4KL1hPYmplY3QKPDwKPj4KL0V4dEdTdGF0ZQo8PAovQWxwaGEw CjExCjAKUgovQWxwaGExCjEyCjAKUgo+PgovUHJvY1NldApbCi9QREYKL1RleHQKL0ltYWdlQgov SW1hZ2VDCi9JbWFnZUkKXQo+PgplbmRvYmoKMTYKMApvYmoKPDwKL0ZvbnQKPDwKL0ZvbnQyCjEz CjAKUgovRm9udDMKMzQKMApSCj4+Ci9QYXR0ZXJuCjw8Cj4+Ci9YT2JqZWN0Cjw8Cj4+Ci9FeHRH U3RhdGUKPDwKL0FscGhhMAoxMQowClIKL0FscGhhMQoxMgowClIKPj4KL1Byb2NTZXQKWwovUERG Ci9UZXh0Ci9JbWFnZUIKL0ltYWdlQwovSW1hZ2VJCl0KPj4KZW5kb2JqCjIxCjAKb2JqCjw8Ci9G b250Cjw8Ci9Gb250MgoxMwowClIKL0ZvbnQzCjM0CjAKUgo+PgovUGF0dGVybgo8PAo+PgovWE9i amVjdAo8PAo+PgovRXh0R1N0YXRlCjw8Ci9BbHBoYTAKMTEKMApSCi9BbHBoYTEKMTIKMApSCj4+ Ci9Qcm9jU2V0ClsKL1BERgovVGV4dAovSW1hZ2VCCi9JbWFnZUMKL0ltYWdlSQpdCj4+CmVuZG9i agoyNgowCm9iago8PAovRm9udAo8PAovRm9udDIKMTMKMApSCi9Gb250MwozNAowClIKPj4KL1Bh dHRlcm4KPDwKPj4KL1hPYmplY3QKPDwKPj4KL0V4dEdTdGF0ZQo8PAovQWxwaGEwCjExCjAKUgov QWxwaGExCjEyCjAKUgo+PgovUHJvY1NldApbCi9QREYKL1RleHQKL0ltYWdlQgovSW1hZ2VDCi9J bWFnZUkKXQo+PgplbmRvYmoKMzEKMApvYmoKPDwKL0ZvbnQKPDwKL0ZvbnQyCjEzCjAKUgovRm9u dDMKMzQKMApSCj4+Ci9QYXR0ZXJuCjw8Cj4+Ci9YT2JqZWN0Cjw8Cj4+Ci9FeHRHU3RhdGUKPDwK L0FscGhhMAoxMQowClIKL0FscGhhMQoxMgowClIKPj4KL1Byb2NTZXQKWwovUERGCi9UZXh0Ci9J bWFnZUIKL0ltYWdlQwovSW1hZ2VJCl0KPj4KZW5kb2JqCjM3CjAKb2JqCjw8Ci9Gb250Cjw8Ci9G b250MgoxMwowClIKL0ZvbnQzCjM0CjAKUgo+PgovUGF0dGVybgo8PAo+PgovWE9iamVjdAo8PAo+ PgovRXh0R1N0YXRlCjw8Ci9BbHBoYTAKMTEKMApSCi9BbHBoYTEKMTIKMApSCj4+Ci9Qcm9jU2V0 ClsKL1BERgovVGV4dAovSW1hZ2VCCi9JbWFnZUMKL0ltYWdlSQpdCj4+CmVuZG9iago0MgowCm9i ago8PAovRm9udAo8PAovRm9udDIKMTMKMApSCi9Gb250MwozNAowClIKPj4KL1BhdHRlcm4KPDwK Pj4KL1hPYmplY3QKPDwKPj4KL0V4dEdTdGF0ZQo8PAovQWxwaGEwCjExCjAKUgovQWxwaGExCjEy CjAKUgo+PgovUHJvY1NldApbCi9QREYKL1RleHQKL0ltYWdlQgovSW1hZ2VDCi9JbWFnZUkKXQo+ PgplbmRvYmoKNDcKMApvYmoKPDwKL0ZvbnQKPDwKL0ZvbnQyCjEzCjAKUgovRm9udDMKMzQKMApS Cj4+Ci9QYXR0ZXJuCjw8Cj4+Ci9YT2JqZWN0Cjw8Cj4+Ci9FeHRHU3RhdGUKPDwKL0FscGhhMAox MQowClIKL0FscGhhMQoxMgowClIKPj4KL1Byb2NTZXQKWwovUERGCi9UZXh0Ci9JbWFnZUIKL0lt YWdlQwovSW1hZ2VJCl0KPj4KZW5kb2JqCjEzCjAKb2JqCjw8Ci9UeXBlCi9Gb250Ci9TdWJ0eXBl Ci9UeXBlMAovQmFzZUZvbnQKL01VRlVaWStBcmlhbE1UCi9FbmNvZGluZwovSWRlbnRpdHktSAov RGVzY2VuZGFudEZvbnRzClsKNTAKMApSCl0KL1RvVW5pY29kZQo1MQowClIKPj4KZW5kb2JqCjM0 CjAKb2JqCjw8Ci9UeXBlCi9Gb250Ci9TdWJ0eXBlCi9UeXBlMAovQmFzZUZvbnQKL01VRlVaWStB cmlhbC1JdGFsaWNNVAovRW5jb2RpbmcKL0lkZW50aXR5LUgKL0Rlc2NlbmRhbnRGb250cwpbCjU0 CjAKUgpdCi9Ub1VuaWNvZGUKNTUKMApSCj4+CmVuZG9iago1MQowCm9iago8PAovRmlsdGVyCi9G bGF0ZURlY29kZQovTGVuZ3RoCjU4CjAKUgo+PgpzdHJlYW0KeJyFU8tugzAQvPMVPraHCNtAokgI qUpViUMfKu0H+LGkSMUgQw78fc0uSZNUSi2BGe/Mzq5Yx7vysXTNyOI335kKRlY3znoYuoM3wDTs GxcJyWxjxgXh27Sqj+IgrqZhhLZ0dRflOYvfQ3AY/cTuHmyn4T6KX70F37g9u/vcVQFXh77/hhbc yHhUFMxCHRI9q/5FtcBilK1KG+LNOK2C5pfxMfXAJGJBxZjOwtArA165PUQ5D6tg+VNYRQTOXsU5 qXRNMBCOn/IYMV/KY54k5OFc8gJRRkgWJEKWvMw20xTSuCX2hrQ1IrEcmuLcV1z7CmIn5rZTqGTJ huwaneSipSrSS6f02ikhbbZFbQKENKKUE7KEyCyrb9eUpkffeVsL0sIxEx7q290rHWiSy/W5k/jj pOnn6BTZ4p9G9Zpo2KjYIMoUJ2QQGWxbbFNCF43OYzRP+2lGzcH7MJ54JXAu54lsHJxuTd/1swqf HwWX/2AKZW5kc3RyZWFtCmVuZG9iago1MwowCm9iago8PAovRmlsdGVyCi9GbGF0ZURlY29kZQov TGVuZ3RoCjU5CjAKUgo+PgpzdHJlYW0KeJycvAlgFEUWN15Vfc5Mz0zPfWYyk8lMSAYIkHAEommF oAjhPhJkJMgNIgQQEUGCyiGiorvgLXiDigQIGJBdI8vqerC4niuuyrqo6IqyLrIskJn/q+rpEFz3 /+33ZTLVr4/prq567/eOelUII4RMqBFxSJ28aGH08fBHf4cjjyAkjp42b/qct2+qewjok/C9fvp1 N00bNGWFHyFrPUKrRs6YOmnKUfdr3yH0q2b4Ta8ZcMBZ5i2AfTiGCmfMWbh4Ys/zYxH6tYpQzynX zZ08STx6WStCbyyE/RlzJi2e52y2NiKU+QtcH503f+q8xIc1r8D+eYQsvxX2oQB8g8KzKMAnETw3 +zV8j9NtZmb2OD1Pt+Rb+HVL7ovQFrQNz0Tb0CvoAD4Jv9qO9qJm9AfkQwPgvZaiX6PVSETj4cgd aCR8BDj+axzINqNS9Di0w+PoEFw7Dt2C9iEv9me/QcvRSu49+NVKZEUF6DI0HM1Fd+Eh2RvQBPQ5 fxvqjYag69E83Jitzd6dvS/7FHoa7eX+kG1DFhREk+FzKPu98OfsX1AX+MUG9CD6HN9n2o00eEoj XPkomo8e4tI8zk7PnoUaxNCNUAce1aBDuJWk4O5T0dfYj5dy/eEuT2absgfhqjBKoxnoIbQP98RX kJgwIVuTPYS88IzFcNcH0U60Bz4t6DfoCFaEk9mnsidRAHVGg+B9mtEfcSuXaVuRqYIWE6CVilEF nJmLfoteR+/gOH6VzBUUoYegCUuy7yM36o7GQG2fhV9+hf9FboHPcu41fmD2cmSDdrmXtjb6Pfor DuJSPAyPJcVkLnmMm49keGJ3+ExBM6G9H4C7f4ZTeA9RyGHuSf55/pyYlzmatUGPJNHD6FH0KrbC m0bxAnwr/hD/jfQnE8nD5Avu1/xW/l1pErz1NWgOugs9j/6FnbgPHoGvxjPwUrwa34sfxIfwO/g4 uYyMJrPJD9wMroH7DX85fEbxC/jbhFXCneLxTG3mYOZPmX9le2RXoRHADyug9hvQY/Bme9Fh9DF8 PkdfYAFbsA0+URzDY/DN8LkF34WfwFvwVtwMT3kHf4G/wT/in/A5guAjkhCJkQL4xMl8ciP5NXmE HIbPO+Q78m/OxxVwKa4nV8nVcXOhVqu59fDZzf2VD/KH+Sy0cw9ho7BJ2CI8LxwQToqKdKuM5LfP P9lW0vZZBmXWZDZmdmaas39FHujDILRCPqqE2k+Czyzo743AcdvRe1iBtgviEnwpHgItMxHPwg14 MbTk7fgh/DSr+4t4P7TSR/gHqLOVhFmdu5Ke5HIyDD7XkKmkgawn95Fm8iE5y0mchbNzHq6Eu4JL c1O5hdxN3EauiXub+5T7gjvNnYdPljfz+XwBn+RT/BX8RP4G/jH+a/5rYYLwlvClaBbniKvEFvEf Ui/pUmm4NEJKS/dIe6T35Xrgzt+h3egl1OEPH+VWcNXcbnQ3KeMD5I/kj8DPE9EUroYAp5IteA1Z hptJobBY7Ef64aHoJJ+Etn6NbCKnST+uBg/Go9As0l2/m+jmn4NNJf87dILfD+/2R7jzYlHBt5Af RAXtxIhUwDN/z3XjU9xb6Aj3OZb4x9EnvBn78AnyLDccuOA3/KVCLYpxj6AXuQa8DO0m1QiZz8nr gI+H4ucAF0bjHvgMl0UcGQpc1Jv7G7oNzSZ/RidAjteg+/EUfjq6G5Xhpehr9AxIRbFwvVgievAb ZCa/lrhwMyL8Vni7ClyIOcGNbsdp7iHxB/IxugEd5s3oM+4FqP1h8iJXw58URuIZIAHL0CrUkF2B bhJq+XfxdMThsSjBHwV0W8r14GOwXQ6oMgEwbQ9I9z7Agcu4GjjiB84ZAnwxBhDiIfg8ADjBAwfN BBkfByj2R9QsjiYtaLpgw4A6CPFvZUai8dln0IPZ6ej67H2oC+DB6uxSuOMW9CW6B23BKzM3o3ko ApLzGR4iDCSHhYHZLmQt+ZiMIhsv7l9o7QT2o2/h8yLsXCq8jNbyH6FRqCq7LvsBcHcnQNgH0bXo KnQM3vJ7eMKVXCsqywwlO7IDuXnwvp+jEdlns/nYjGZkr0PD0H70tCSgSVIK+rgJvwvvezOaSkZm F3JTMzOhHe6BVtCgtW4A/LlD6z9m9GVa1aWXVPbrW9Gnd8/ysh7du5V27dI5VVLcqSiZKIwXxKL5 kbxwKBjw+7wet8vpUO02q2Ixm2RJFHiOYNS5Oj6wPtqUrG/ik/Err+xC9+OT4MCkDgfqm6JwaODF 1zRF69ll0Yuv1ODKaT+7UtOv1NqvxGq0ElV26RytjkebDg2IR1vw+BG1QN81IF4XbTrB6BpGr2e0 FehYDH4QrfbPGBBtwvXR6qaBi2asra4fALfbYTH3j/efau7SGe0wW4C0ANXki8/bgX2XYkYQX3Xf HQTJVqhUUzA+oLopEB9Aa9DEJaonTWkaPqK2ekAoFqvr0rkJ958cv7YJxS9vsqfYJag/e0yT2L9J Yo+JzqRvg+6M7ujcunZdi4qurU8pU+JTJk2obeIm1dFnOFLw3AFNviXH/Bd24ebO/rWrO54NcWur /TOjdHft2tXRps0jajuejdGyrg7uAb8liYH1awfCo9dBIw4eFYWnkZV1tU14JTwySt+EvpX+flPj 1fRI/axokyl+eXzG2ln10DXBtU1o5E2xncGgtjd7FAWro2tH18ZjTVWheN2kAeEdbrR25E27Alo0 cPGZLp13qA69YXfY7DlCsXYkprafYxS7nFKDR7a3LKY1ig8ChmiKTo5CTWrj8E59aDG1D1o7uQ9c Bn91GH7VNAV6ZGaTqX/9WrUvPU5/3yQk1Hh07U8IOCB+4ruLj0zKHRET6k+IkpRP2lkNzht0UyrV VFJCWUTqD30KdbyU7ffs0nlRC4nH56lR2EDzoeHQtpPq+pZC88ditIPvbNHQtbDT1DiiVt+PomtD O5FWmqprIvX0TKtxxjOGnmk0zrT/vD4OnNyMqLnqaZKT7f921euqntG3CXv/f05P1c8PHhUfPGJ8 bbR6bX2ubQePvmhPP9+n/VyOanL1r+VCJEeREMfOAlNOaL+Y7tQqTXwC/kXG1FNaJBm4kh3B0YFN av2VellnjsX+xx+1ZE/SX7HNhZ/lqtnUN3Xxfr+L9i+qnrKWgwqDqhw8evzateaLzgGr6Q8clNsA x6PRtbFo/yY0BiQzAf8t2dY+9FsXatKgyfrTC4D/9EO53YsuDOXoOvij3Nml80AAurVrB8ajA9fW r53Ukm28Nh5V42v3kgPkwNp51fUG47Rk990Zahq4rg7aagbuC0JB0OU74njNiB0aXjNqfO1ecCai a0bX7iSY9K+/vG5HIZyr3RtFSGNHCT1KD9KdKN1BgzG85E4is+tDezWEGtlZnh1g+5NbMGLHZOMY RpNbiH5MNY4ROMbrxzR2jP5RjOk/urYj9zCRrOsC3EgwM7AFBBa7hFDMEXMkoMCgdM9HudbzmoDO oSgPThFB13C7yI3g1QjgN9ywF9ycM7sKEuVCS/aMVpAsLreIZlB0PEaCIFq+N8kyxxEkyZVmu6nR REzQ3JrHai83fYY5vpJgzeooxwGl4Vl/aqh6KlVZ01aptqXSlW2VqKpShU9bJRTY4ayooN/u3XAq 5eJ6lnm4Mlau73Goy6fdD3XjdmHfyZOZb/QSFDgaD4eKWD2TmgcJHBa+J4hbEcXrMcGzRPpE9XT6 BKo6gfU767dd05XdzPnTT5nv4S5LMyNIvfAeUtElmrnIjpHqlGRVbcFlu9AmmwxbzSFtsl2DOJWL chz3guPRdezGbadPqKfh7pVVlVDpNE4SR3nvXr3LRAk+HhXjzzf8sWb8/hU3FV0ST+FUZsR+fAbb vj/Sdu6durUbX/5NJj8Tvej5UzWlE+mkEpNZxchpojUwb+IwbJvRJu4aG8hfs6qSMUCcabbbGXGs 2WplxHea3WwmY+y2fBuxveDM1TEFfz+rpyuOHOVFSfiUecGyUEnbCmjxgkuKlqzYP77mcGYEPor/ un/vxrXj3z3XduT7zI8ZGWqpcZPJB1BLP1qlXWXBFnMIh8y82aTY7KpDEi2Y+KmVIiGek31OqwQ2 CrVbmNkCVoublzgZm0XBgpAadWP3KyJw19NiC96gWYWnkeZwlaNAYN46nUlqTrUdgwq3pSsrSiud vgr4hy5kW7rp3g2lXb29PngFUerV2ydKXp+ULBKlol69k1rXTVe68L2ce/rKrsuXXDJ3cd9hV/VZ tLDHCn7b3X2Kdw+YvKG8890ltp5rxgxbc9dVY+7pGqC89FzmM3wbeLtmNHS3GUTkeajacC2JuUpC sBlXIjPhYAeJfaS+w8ATmAt27WbgvM2Wxx+Alj6VPnVMPQF8DMxGmfqE2saYrnu3MmA5N61Zr957 Dg0f16OiF3foUMOdyZrApKvhuZfhFjKLzAGp7KwF5pF5HKnBNfDIOCJBYR5cEODn3UUb5Vha/QqV 1pyAd2+ATuwZ81xGinHL7t209vugWA2151BC8xNa2Uq9itsRvxnOb+ZZLU+nmTToldp36NAh+luU /ZpUQM9yaNRexGU/2+muIC3Zz7Sou+J+DhNuE7edI9wihN1wNcAIh8zccUSOA19uhYfzu5bAnSvV UydUncdWC11T6WXqQcprqZQHl2G8dX2mNiB8d9ZN0WVM9mveIbQCv+cRu2a1K4py+Ri7YrFcPkZs yR7XHHRf8NN9SaVliB61UEq/CvZPaV6r9fIxYZGWdoWWkkrLHYRCoGYORnjBHbFafQBHx5msUEIL UGExOZBCjyCvokCp0GOoFATlEBSHoH1oC4V2iP95p1NwJ5He6SuQOkZ8rwUsFpHeUqVHkKootKTH 2m954Z7NYjSghkGMQSFYfgsmnBe+Tvjas0e1oby4mqyxrLG/YRNMksVPql1DPFcF+odGuyZ4JgRG hmZLsy2TXdd5ZgfqQzeRG8VFliX21eID0kb1Df8R8qH4oeUTe7C9urS2tCWB+LGZNpuP4rebNpJv gUmLxcu7mTAyqQyxT7ErWBOF6RWm9fkO1i8OGz3hkOlBxwJEsT0KP40iqoPYFUimVyB2BVofef1O ymfw0unUCSgpmW5gZK4RcLoBpVEf+ofhW1eXMv4Q4L7q7FXWw+t1AiyJ8YKipEv1lvXo5VCT8QJJ HDP7vc2Ldi68fNZ7j79/0717ty5dunXrLUuvSpP3MI8veWHirkz2SCaT+d22B17Cj2bu/+EknoFn fT9zFeXyz4H1zgHXmdERbYBZrzkrzewNESvN+luwkqN6aza/nNxDHpT5F3hsQqJAOJOAFYLfNLOm MNNWRJiieEv2KMNmIL7VHIy9woy9bIy9oM+1AGUeg0MYtwQVAQSAatZWzUbvJeCooAlECFj24Uq8 EumC36C3I/uDHapBUVUVhUSqLdMoDdqF/cXiDlGUegLUlJFzzZe9N/r+L0oX8jdfujT/xSvenAi1 rAR5laAVIsS/F0kgGbQFZKpOmLhRWaEEO8KEClhjF5MrXRpMDtXqd7nEMVbKMw4HI77XTKoKVMQt RCgH+egFkQg9Gwnb4ExEoW8baSEvawox+3zRfNVBSDQf8LH0/UO0PIRKKYukqmh5sAcVP9L+QMXp JOyBmsnuIMZzjmoWp4uMibjpMXrvnXBr/QUI5fXvNNbyv/Q0KpH0efRp7GFar35CP/Fl4RXxZel1 +Y2wNEipU0bbZitTbEucS1x3OPc7vwx+GToZVF6xvOQiITWs5qkRVfxt9iS04lEkw9YEPRyMmFVZ FN8MB93hcFAOBwE/5WCYs0bUFvLUrmEO7GjB/t30DRCt8i5MFLMhqGZDUM1UUBmamRf43gPmpcKK XyYrUBSpuI+mOHZXkYlkLlkOhuM+Uojy8T07mNilAYRPpygWM3kDy6rqRFv6mMNQn6ttXVM2gGZd MyFDBvugNE7Pz0liwhNL9gYO6tWrZzlIHdNcIJKgw8CqESVeOt+b+BJPPvTDlgdvvvURvNd15k/v nb7y2QNPTIhs23ZZ5eTWWw5+OW32rx5Z6zr88bfbap/b/9SaSd2pBI7NfsV7gfdSuHkP52cg35Lj QErs6gDfloBfo53nDyNMZSOlwA4ujptBW9gjZnOxJxLmI8Vhodgatyr+AFhLUZVKW1RKsnvC5clS Cr6HSukHOSuqqkAnn4DOP/Ga+pqzQj2Y6kG/tPM7CVavtdq6yspXO8Y5FoW4kd7r1FnuKd4brDe5 V1nXuu8IPW01C1GOMZ1Fsdp4CcNzMe1Tap+/jGnc2op7wst4eP8+8hQKkBmaCWopQDWtTqOLnUYX O9ux2LlgYnRulET9VESijZJxqWRcKrVfKi1IMthOYpRUkwTe9NRL9FfJ9V38LbjPzsB7eB/uA/q8 VbO0Y/T6zi34vhx3pE4w/sjh8alUuh2W245RuQCjhTKLziuALMAdAC64oY7CC9hbFIoZU0i920mD PyiDSLRE8YLk2Ob8DbOXb39iWdkQt9OyoGXVrJnr3M2xb19c/ObsaVNuXZ85/uGrWXyb/8HVTbcu fdz9GFm8bPKtt98e3f369J1TJj7SNfKbu1szP31FrYUgIJYKNr4Z2velvUjJntVeoO1jFRnjMAgX WWnS4ZyVAoNzkZUmHdpZKckM8FgpMcUly/px2sAyKwVWiqw0sVJXC85aZYbykLJVeUMRhnBDrL/m OSeIN1JEThLMFk4CfWK1vsnxbo7jOSsiihWM3pfJy0gG72uzZkY8D5egN818C5n2kiCYtbz8crOh OMy6VcGI75l5YW7BvTWrpBXEy6XGWE9pvZ1QYbBY3eUIXMEo4Qj9Mf0NEMf20N+Q3bYWvI7193dU B1O9cYqKdaX6lcrUhnqq8nSlo6KCuUSru6Z4wAO73Q7d3X9C7V5kBQPQWQFo+75mKavgCrpUcHxe XiW9RR0wA1yjuRXNUqE0Dq9QtGSFUhCGbZcKhh11OPWffygFfmZPXOYo88QdnAOTjW23k0d/9dpr zZmeeOLT3J7zVz2deRygbEPbbIoT1D6MCc+gCD6vuVysO52stDDQYEaKhVIXQETzUcrFrEMnKzm/ YdAwIdIvopSLGYtOVlr8rL/pRayzL0ahvQhDa1tp8+KwzRzxeMJOqsIsdp6PhK02jCQ/KHtmXDKC IRZVLhRxqFSBSLUdBJShIFPsZErQzsrBwZvy1uZtdD3r+p3yofJJSDa5/LaSIGfqJnSz7AOFwgHS qC6zx+lyvWmzu20ut81uBbjRXLQimm0z+Hg2u+bBuUq9ZOfxexSKQL1oDlo9x0R1rrpcvUfl1f8D qPgZqPgx8qt+4jdAxb8+6tyPeyI73gCS12enbfcvgUv+xeByEbykqS8EgMLaIe2ALyDwsdVy15QA LIeYCmLaBzeAn1D3c7bpiDcAMq6YJ8YB0CCPWwLLMDnmN54Hr7u1edu6ces6bb2bfNz20rDb723F 8sK7Tv2hDTeqa+88+MRDO4dVeck/XsgsmpA5/afX7915lCJKDfCXB/RQHioh3F4wv0+ytnG05Iio 0VqyQRQZbBRvZ6OY7p+w0saYiV3NkINaKmbdJVEu6LR8O87HEzGHQ50imhVbrWDFhISCiNtqjmCU UOmvmHuiRnwq5Skf02g+5p74cr7EofcPqb83eCt9Qj2YprzVZXYAD5A0z4DAgOh45+jobG6KNEWe 5ZwSXSjfEF4prwp/KL/vdUhR2rFFOmaI9GVAnVEqxk5I9ERRNB6N0RMOWsvhVgL1DOH3qO3YQlWa UWdMFQ7anTCaKGFwVqKdsxILVMZZKkYqABy84MmXqO2rru8MyNZHc0WYVEcYMEcYxEZacIVWUOWb 6JvrW+7jfcz987FW9Hnpb31eWlNfCynclWr3NHQ91pH1TuhKjSkzaKYcn9FLqULriFLgc2ApWcTc C1GimsxJLZ14AXKovalew+4ObMid2+XvPGj22MvGXEsu2z+9ue3Gd27/a+bYo3cc3/ZpW+9hdw+d /9QTNy95jh9lm9Wtptul3/9lcn3mX++uPXELHoyX4q2vbjlw/tP0c3Utjz2wfTu06CTQbV7hWWRF 8zTbQSvm4Z/IvAmUBwWabgTzJsW6gOMIbchhzObjSNAuLzD9HQ0DZppIuCrYzMXLwQEK2HLCOFQ9 lW6orDl1Yqh6mnoL1C+ntmCFo0I3/EDgaPxARJwoxXs5nb0ncbvXZU4M7mXfy936zzv4s9vWbcg4 M+daPtmGv8WvP0JjhqNAagIgNT4UR924gXtR2HDVgwyGJX9OdnJHC9h+KSu7GHZecTt2Jy9czjz7 AiZJ4fb9INsvNgSvC7svpUrZiSQr9Z9TxilgSB5u3w+y/WID2dnPmUVdyk4k/RdgvllBoUhXqljB byFjunZ1xiKi0CnitEaoRcECB6f2sLhByk4xgsqm3XA0KMFO2v2cEZ7jjKu4dpnmCj0KvdzD7uhh Mu25EB+4OPhAPZQTNFyZi0G8xCoiGhUR9YocY7EIu6H4c8+nx4A4rxXQg/Sx9JcepnU87E0vvJ/x MHgWLs1VwPhSWOnd04uLvYO8g5JfKd90E0zd8DK0DC/lF8oNlvnKDdYlvjvRWryOXyWvsNyurLLe 5Xvb8ZrLWQDwsTMcDdJNNFpKN12iSYopgeKogiJ+pEA1NnfFHVragJGIASMRCiMMRCMLXjFh0z4y HaVyF6WMi1LtWJNaYNeigDV2jOyqndhb8L1aoIefAYyfAYyfAYx/QROHuRYyXfMUspOF7GQhO1m4 wGM44lGP5iGe9d1fN3QbU2gsoHGqXb+1W8/OijRrxFz4uk/uD3yqBtRQ94tGkf6Hk8me5TnvyjCe ERxxuTtgTkcAwrPmXffVK63fzp6z+q7M6Y8/zpy+99pVs2esvGPa9DV9B60ftWLLtluXP8uFih+Y tfnI55un3V/c+eCa/VmEces9r+LRM26/beLk1befz9asH/ZM463PbTHicVSyI6APN+9FdhCVOG0O j18vmQZkZVyXdNZwsXZR9qrMBqf7eZTyMNksYmVcV5PMJIu1C7dXNYJ9zRdO0Id51ZwCPd4h6PCS JR+Mk4QDTJPTjL/9uqZlxEmtE2Vwv4NxuIMFVxx+R+eUpVOEhsKH2TibzY2GY8wcSavqEMdgah8V UB+cdt7BVLoH0xI9WP8B81NpVKmm/fT37YGIDpW4YPFpJczkczCh/i9PvfhZP3tUaccHaeV9g0O8 Wvxq77j4NO4675zg9PiS4LLIuuCdkYe8W4P7g996v4qejrou8T7m3ebl+hZPEUkRtRbjIFv+WFSM dooMs02kpmGYPhK/N1xX2820EvmGjOUb4pNvRHny9+EKZMmdttBmpqctxmkL1daOi83E9Z2pBaD5 wARg7JBgcpSQdcXvaJcjh+YgjvWpi+QINHVOhnIS1G4kGpoapRtwuu4/TMJ2q/BS0rO8iGpp2CIQ H6eDhQuTmAmJh0nPvG3epZNGLRveC/d6ec6e81h67Z4TNy/5xxMvHCFvPb1w8c6tS5c9jkepS64f svzP8xT/2NlY/vPnWH0o87fMj5mvM7tefIUrf3jPwUfWgaoGKdkLrskqPslGz/poUV5AomQiYiXP VWKRN5NKMPkRoZHAx+XciEAD1bsnVH3wSR9/osNP8N176NAhru7QofPPHjoEv5iHvuD78b+j2YCa cg/XKBBOEDmZCC+T8XCQI+N3Ek3ch4eDHzlc86Dn8fNRngRlvpKFHm+Qxo1nzVtJNT4KlAZrTsCf P6jqD8+Nl/TEHow987i3zmc4QlZswQ/tyhzMvLqLvt14sEQU4T3AgAJ0u1YKLBciS4NLQ+Ta4NQQ ma1MspHxymgb6WUbYCOhgCzxSC1yOJC12I0jwGLbtXisIFaZb86vLCiIVsZiEXRN5HrzNb5Zheo1 UQd2zIrn6kiHooADKulgSRsbLDldyTr/mIPFHNLwh9JpDMDYu1dv2tEXggw8hUkbkWgT4j/jiLd7 4ct9nrpxwUP+vYF/vfURRuNvq+0VJC2H8MxC56yavv1ST1/bd+am9Q96Dx359pn6JxYOvar+usz9 0OYEzc2MkD4QPkBXoHHoX9o4PqZGvbFYoqe1zFZtG+QfEBtYOHDQFWNH25YU27yJYpw0leQli3sG e1X0T4z11+VdHRtbPHZQ3dip/qmJacWLgkvy5heu9N8eXJd3Z2x1MmBTh9sQN4qacWZ7UTfLcAux SN6XyZWoPxpMXm7u35cz51PHrS+OpualSGofrkFF5OU9pVcW2iUstZDbNLs6/FJU6NxsL+ymzgMD eh/eikLkseaqPiWFcL0JxcljminaE/cM1I7TB87SNSfaqB+WPnGq7Zjalj6BSk+cSAP0HANWqEof g4bO2YA05JegIkRVEAu6+3qXcbrs9O7l7FlOCuMFPPG4nXxZtLB3mSjy8YLCwiLaL04U68HToUPm iRUlsTsnk9BVNsLfcdnjI+q2zHzyx/njHqso2LU+UpzXc+z8lc9nth36NrPsgw/wr37CIr62dnfZ mcxz//gsc0fmTP/RU5bgV7F2Bt85f9Lbe/5cPcZtzXhvHd1nacOVqydpDbO0JwdfPePPKzbhqs1X px9um7TOHiq6ZDi23vMsLnjxk8z0b3/KPLa16ZaZR5bP/3LDbz459Sm24+hbb2x7K/PZX98sKQrg IXc80P/2t6at2XjZ+j8Cx2fbEBLqhH0gzTaSR139M0YQ9nxzLsxwxohN6gRPrQ3fhfiRyOtRpNxF Z3XdJou05Knlx/YJ032Y7l/GtJ6ZaUQvG3Rg5ywskmU2s/uw0mRj92e0xGhss6ssyvNjc444wzQg ofetY8YhM/QEVpaq3dTp8gxTvbqGW6++IbwmtqonVYss1OGxZLg6w9Kk/lP5p/WfNhOv8FbexlnM JoHnFatNFiVJAVoWFQkjRN/YzkYxopLihlOE4+gxDz3GRXnFDb8yRQRBjoic2ELmaSYkK99oBBOy D1vA7LBoTiWKpkrcyOH8Yf5znlvPY74FY80yXGmVPle49QpW6L5qlw5LZLnUKBHpV/YPP9IRNABf +PcD9wYD6okTyF9VGQRuZvBxgo40ppapB1d39bOtnkNQUbFaPXjQdvDgakHfAqoMbrKMGtwUGTG+ tpm3c7K0L3uSpjVQXVOH5zek/6uFBn9xXIbjXIxzxTg6xMyRsj+R2k+fb3v48Y/xPx4cWBAuE/ad HYj3ZwaQ8Xjj3hvvupP6SxsBUb8B/nLQOANeuRfx0FPFdFyQ5wfGx8anxReYbjeJM4M3CPNMCyy3 CbdZxCKvifMXlUS8eSbDY2qPYLGwV4iFqUwuZ6SkpLgYhfMi0NL5kYgDyWCPZNgv/IZ6p/aSZqW+ sz8pKtQxAcPqKy1BrRfRSS0XUaT9KMq0ViLjHNFNuUocnTDu1tGvP6256N0SSSVM76aY6T0UyoFF 9A5KsDPUp4NLb6ZXR6JMR0VzY2OnmfHEiNy42NlmxmA6IeojZWY2OpZO9Zvgbx/5Sle2QVk5lO3X 6AFs/e/CYAd8QZOAYqmkdlzKQRNKsB7LpqNkZY5Yh0C1jcRxrIc+zpGMx+Ccrm6A3kiSW95aMG36 ynvGNb66LvMrfMmKPlcNHnjrY5lP8Jxrkv3H9x29YV1mm7Cvbu/Ua54pK9rfOH1HfXdupMM7rWbQ 3OJzmyWlz+yBI29i4x7Tsl8Li0C35qEfdk8ms/II1vuUvetxbSKloqiHdTLYAQvzGtHteevRQ8Lz 3NPWvVyz9XXrO+hY3j/zHDZnniMvjysROzlKwtH8K6xj3eM8YwMzhNl5NzvvdD7EPWh7KLwFP0W2 OD6wuZAbBVW3GuTpUP7OThXM+q3uVKHaEeZDrojChSK8SU3ar0LJKJipwXwf6zof6zof6zpfMipj gDca3FJoLeVAZPIEPUEjlWZdAL0BRC7eoitwOEVHeMG5mY99TGlAozoLQXv7pCTV5VSnUAONbz5w SeZ3X57IfPTwdtz/wF9w536vlB341da/TZjz1aonvyCk+w/nXsXXv/slHrPj6FtdNt/3ROaHe1/O fLN2P7VYHgP8Hg/yZUd5OKA5o/m4v6zLg0ON2JHsMzi44/j3aa0g92ImnM9GmEyMMU1mliHgZ0cY QzNIDebnqaw9VOaJqszSVf9nhv6XwdBnDIaO/AJD53bTF3Fx9279b9J6cSFJFmVB5mVeDPiDfiJa zCB1ZlDTXrfX5eXEEOeLYacNCr8cjmGv2RGjEa1UqgT+VuA05Xif1+d1etwE+D0R65Eb2CsCLn8M //v58bfULVwwdMm9h1ZmduCKe5/uXl1z/3VDt2XeFvZ58oZcmzl88NlMZuukHtt6da/+5pmv/lUS gXd/ArCNznqxoGbNIwoRWZYkxPG08c2miAXJEuW2UtVZLo3mroqao1ZiDlp5E9GVG4MzxmGm/wtw MJn+C0oo/a7O8WSuWWsMoEjXnDr2H8jQvRs0iieW+z7BF55/jEud/4C7Xdi3LVP1Qsa6DWoEjjG/ Et7QhJ7QLmFveA8YZcZLwgs+EiVRCyFBy//TW1HHmTD1z14l8x/vZO434b++0zE9mkf9pZ+/zxbu 0/Nfkqa24fRd+m5rm0bxZw7gz17AnwQeqgVD7pCH1Bfha2QXdnKFhSjm9JEEihAGEB5aD4xFX8TG xSKiCeNkUaLQkKRCQ5IKqSSxqGxhlOOgJYrq2VjUMfamzErJDUodYf3HrJQyem8yv7EIF+WxJstj TZbHmiwvGTVjM4MaM/PhzYHk5KsvgpoaNX061xYqawwa222Pl0GDwL4+dllB7VuQnwF8PBQOhgNh TlSSasKTzE/KCT4ZT/iteTHktbticLHbFZVgr0BIxHDYAoLkdkARMcViqJCDArE4TYpmOFW2mwRU tMCA7plwXARwXp/UlQDC0fQ/ajeDsDm4IWTOPZl3Nv85s6l5Fx7+ySaM70tuj127Z+7KAzfG+qzG 5N5bTl5Kql7AbUfnL9iLr/nzh3hB8/SWX3eb11gz4vZhazYdzJxpnNQbO2hfPgWoV0AlDyt0qK5V 87o85TwXMZk3m98xE7NAiEUGxDC6TDa6TKZdZmJQHpUkkQ4xMjsAztPQC1BstEGkYboSZg9gZg+k G63YSiyswyyswyyswyzRXNZLq2aGKvwPzC7nmL0DKnpzAhy14qh1uLXeOs/K96vzp9IN7eku7Sip d36qUu97lmhWkS5lUIlBsYMMwDcO5VMHyNkDB9pEYV/bM2T82YFkV1sN1PQVaL4V0HIcLtAChL0P x0oisfFCKWem/5s1F1Tv33q8mQj0dTlWwulzzZSA0+c01g4UDAjN39nV5xKWx7OrrFzfdummbzsV 69t4Qt/mRfStP6jn/ZRY1fKosF7YLoAogc19D9qMmhBfijQ0HH2OTiLBGYWD6xEn6KO/tFn9ueb+ zmju743mpoLJDHbW3E/wH9Z10Dj9J9TubASrPF3XML+yrd3qpcPCTHMbf7Q9XzlAzVpoOWrJlrAs 21s1BRPgNgHJUWrGk2e1mET0ZuQYc3CsUbj/GdZP/4eKFH9JRX6V1lGcYh1Fu40HyLtQu39uozLx AEKiHeqncj5NkUssUAHCSmMYV4ZGYTwo26wOhkbQWkAINHWpE6UUJz0t2BXOhDCRTRYbkk3EbBHp G1hUWmsL1HoPvcqiIjpSn3u3M8a7nW++KI2QhvKrWlvVd95ppQGYVEpvX2SkFeZLrINEVnKs5Fkp sJLKrRanFGFKAhCMoqftgqdnZqVkOII0Y0vLZ9kgAlaiZme5nRWCwiFsA5Usg26mL07vxgh2k5fJ WOREKhmrWXPaSDQ6hN0W0YGB1KnSU8w2qaqs1F8m3YFbGECmQtpyROyym4RkfpGySvkDNKUySBlk 54r5hLWzrZa7ml9kXWxbbZUtRJArrL1sw8hgboCkyTXWy23mB8iD3EZpo7yFe1YSncRus3UTiFsQ iKxYrd0EGUhZGWkfiTVwLWXZBF601WqzqbSf6p2NTuLcR7YgK+6+U4jKLbi75lVMZuZq6461Oaop yy3Ysg9e2IYtcBVpgY0dIyPcyWSHBbRR1D5PxWoLGftSVKgXGgWQPLJll4NCU4Bm+qYr/W2ULZlP CnvBDrvH0uCjVlWyxHbjEwTPlfqqq5cxVxU23buhCy7pb5CSPQdc+iEi2Q+ZRzq4SYFzneAcRfkz O2xmejSXn/H+nliFrXOM5Wjs6V1h69Gbkbu7wNFcHkaqDnxa1JCmQVRExRlMQ1+v3jgGCInj2PEA LsRXd/MGeuKJWHg5M3Z7plbYd+7He68c/jB3/uxA/q1zPfmj56JUuh4BjZNPLSG8P5e1Bax2fDfL yrAY8C/7FS8b7qJDAEDJBLBMkt2SJBOJ42QTT4hJknmOAShFC0Mv0SOgl+ihqCgKBqIJ7XpJ0EUT 9IaWZPKRjlpw1DLcUm+ZZ2m0CBa53fRSmOnFdJIVKvW/2WD8f6qldhusA3Sm0qlK1snphlM/10Ms plZRsZpnPawLOM2kPvqS4iiXo1BAH9R170btCOjDZlkbWAHv3bpnYIWs9dDJHhVSQYDlXe8JANlD J+nRuJ6NbYlXSDY3fF10/9QeF5B5OpkHpIeSZ3Z4cv1vJIQy4dRZoAxTBYkdj7zOkX2vn89Ah6/g l0NnN55rpPNJwEr8VHgf2VAIe7XBQTt2q253yBcK8bzKuy0+S4jf6ttje83G+Xz+EInmaY5hrmE+ LVgr1JrGqWMcE13jfRP9Y4PjQnf6HiRqIMJxzojF5DFsEY/R5x4qaUxReJJRGuvMpR+z9FPaYZKh zyQ9J4MR3zLokoyxH4l2YRXDwGBjHs6zMy1kZ7xgZze3JykH6NnJzLJEYgeEC4QnXzCxDWc23d7b NT/PWAan1qXSuCd1pZjR11tFZT2Qo5yAU4sm4zW411t44PPNmT2vHM7s2/IHnPfRJzh00zf3/jHz EXkTz8GPHsg8/ZfPM5t3/wGP/23mX5nDuByHdmHLrzJf6v4s3wZyZkV+dFKLTHXMdpPB6mD31erV bt6iRAARkc+vex9Oo0kvyifcwxKbkszSc7CMFBagkdWcQjmldaFvLgejQQz/Qb+VNZmVNZmVNZn1 /9Zz+U9vLNBRf18I2jToTZtrVsMdY9YbWNLMTY0QaNlYzAF0u4dKiu+rue6+uu8zb2TW4Jv3P5Ye 0v32zB3CPptz6p45L2fa2l7g8LrlE27zWGlMoDZ7t/A98LAHdcJPahsmJjclScDf20MsYT6fOgPu fHdcLBG6+FLJfkKlr29yiDDENyiZFsbEa5NzhZu5JcI6bp2wAT3EPYWe5z5AH3i/RF/6vvQHw0IK lQj9BD4t3OffmPwgySe8Jclyb0VykH9QuDq/Oj44OVaudYzxjA+PzxubPy46rmCmMM0zO3lz8u7w 3clP/H9JBix+DLz//s5QBaL5dd1CFbzf7S8R+go84bydOKlT0u8VkBjjXEGB0B0kFEYido7IhRHJ FDS6PWh0e7A9xBdMuvy0s1yG6Lj0CCIjTjLRcRmiQwntEtpxrqtIMFrSWEJKYowXYowXYowXYkkA WgsTHIuf/t7CBMcSKL4gOBfkpibnqhpiw6JBOW/MV4EcZeob6hvpXHgIzaeqqWF+Qp+108GDosIF R3vlpMpBRax3soj/afX8isceffL3r2f2b2/C1W9QSbu+7astc54HAfs48wUO/WXGhKunPppOra64 +epWPOHIx3jKvlczTx/Znfn8rtL0I7hiJzb/KvNRBi7O/LGoX4Dyy+Og27aBzPlRAemrxZwWG3b2 Co/PnybPyedNLEVfZqXESnB7W1mTWvWhVD34yQiLQYAgfrHLGSyH7cldBUXlDrqfV1Su5rb23BbO /3lXXlI/D9eruS09rw0CImG7KnxVdJRlQnhOeL5pse0m+0rzGvv91q32Fvtx29d2FWzBqMPudjjs DrticoZILOg1i06aLy/4TSavLxiI+GiNc7Ev8O5pL/p8KFbAYMQPDGOTIwZTdUy9yLmKkaTtEdGY PyMaMMB8xHLmLYosWpyOFs4rbCzkCgv8pEPCBeMi//+KKOJ/1cPxflt+KRaSA+vAMX8uckYtrRyw pFJtsFNRyvLe9bR3oX1GUoc/lHOKNLOs2Svsal+Hsy9VmLiB2Vo20LvBQIUDNLMTvjYtXKEWuOGb D992VVvXIazs8/pcca4rAfCKMyBjeRuxx8nag28vefO9mk5jhmRPHRhz/bguscF/xY+v3Dj0/icz 3YR9w/5w0yMf5iUKh96QacDdb1/XxyK13cCV9b7pihls9sqE7Nf834X3UDfy+72oKDcunzQG6FnO nY/lt7BcjAArg6y0GgMIikFYDCJsEGyC1SUX0mYJKzErJ3OT+QXcQp5PFPXkKsL9uUHSkLzq/AGF A4tGcXXShLxxne5w2eKUeWgfFxpEwiCSBlFkEHHW/frFOpEwiKRBFFEmHEipTtZkISnkihK97OXx AYnq0vHRsfExiesss6yzbdPcU/03WZZYl9iXqTcULkis4tZa7rCutd+lriy8LXGfdaN9oyeSc7m6 xJLOUDJoShbjJELFQSffo3sSTQUcsHa5KXRHiIQSXmuXSFECJwSvQDFSH1KLdDFFIl6OGQMpwLO0 HmiimzQbXS89oX9CWpdEoc1qEWLhvEhIlkSeIyJOFBbAMVGIhLoENcrq94DuPeFFXVjEjVm3Ko7i 4bgez8PrsYhbcJNm60IfSR8NNb7KZKRumAwZNbWnR5mSqBgXU/PIZiM04+2Ulk/vWRzsEVM6YDrL zIAWwEknNbLpxU5DDJ3t43zO0VRaA91zsbd0zTGK6Wou1G8Afi7er7alU3SQOXWKtoLDx6bv0uGW Ojq83HBBzHDHHSZ0rt4RUtYjF4kuLGJpUGwWQW6MwOP2eXkfEyqqHpITXrJO/MOyuc+NGj6hX+a6 ETOn3/Ljr5/89yphn33b1qbHK/rgj2sbl6w69+jrmX8+iD9Sr79r3OULBlRPj/smpXo/OXXuq1Nm vr3CdufdK64eVlY2u1O/3YtuOLxgIZtD3A3srn1sHPgzLSAy/JJYKbKIkPTf4kIiiwhJvxAXclBK IBHofcSW6jC1kAW7ovq450tiFJNSmoOG8W6ci6Ed1ywMH+UcOP5ohEe+MFDyvIGKGd0tp3eU9zzY MVICvQVOybH0VyqbhVqVC421/9EkfBojJq5MHr82ExKs27ad/SfNVwHLn8YU3VjRzEl7LV8rvyHz 3pZcdLGc7ycP5K+SF9mfEY7bJQURB51sJZrchuZwG1wJxOk99O3dSWJ4cqTdkyNqLhZ8VOvKIhvp qBdHvcO9pN47z9vo5by/YJCyuLDhZpqjuYkSuhoxG/xrblcjZj4X39DViLldjZjTHurOXVAj+oBL jQp2fUfL9IQ+RzqF0rjMkTP0e4LjpCfhOfj6A1My597/Y+bsvANXbFv24R5h3/kdn2bOP3k3tn7D DTu/85Xd1x7AbmhVE9gWA+m8FXxCcwmdGcswQOX9uXhse4T2LCNQBzeoPWb7o85senCN2HKi/21z LuH8Wz1tzsxyIGlYStcCuJCWhJXmYO7mX2lMH+BCFvRkZS4z3SmAm8QcCzMSTLKAiVD66SH100OO sjJgpCqWLxLSCksFXII6cQlzqdJNqVfukO8wrVdalZOKJaoMVwhPLDLJpeyZsGJBMtyyqooNysOv zSZTVBbcsiwg4HsiuAkRTPCob6JmJJumyngqkVmAs1PFcBk3yutl2MdYsxKtU8VEgu8hmwgh9Igj KgwXSDehXlgvtAonBUFoIWt2Weq36OGZBjphkn79qj4lORg44denJedyBWiqgB5+cY8YX7sT2YFP /rHT5MR0I7tpgFDP4KSRmE5wWS8WiUFsHQnmD/4si7wDssVwmR5rKcPksrY/vIuXdc0v6ILXvdZ2 ADzujxrnLV7MF7O4Kpig0iJqfZKlNOsyowef9NC0zeAKsAfbcie49hPMx23R8wmAoUQ98nqBRXgG /BwriZL7mT45wW5wj93QKWAXvN9s0efBvK+xwGkxSjqKnUl/BerlqHD28g9CVzgGOa/w16Jxjlrn OL/6gPyAPdfVWpmKg4GUp1woVwYIA5TBntHCaOVqzxRhijLbs1BYqNzssQseGoZ0yoBwhHFaVRXj Kx/ToJQ9IhwvCESUgD3M8Lomq81uV9wup9Pj9fn94DVV7hKQP0q3itNBt9p4j2yKIoGQKAbswsgv yHLE43d7PH6nYjJFPE4gnQ7Fbo+qDreqOpwmRfZ7BLtDBRCDKgmcX7XbTSZZJlAnv9PpcCA56PMF 1ctMeASKIgVKD3w1JOARe6J0nDwQaMF37tAN0nQwUNMW9Le1BQNt/qHVUwd81W6FGpE/aoDm1rUw clNqOsYBL94A+6y2qQcPQlF50KA6FsCOdmBHB+Vap5kmeOg8moCDJRd4NBdbtMGRXYomaH10tp2f Ru2BoQ56AZe5dIZ1OWHjKsNxTPNcMH4sc/PrnxcG+5ix79t3h8XDXb76Xeb6lzNvFUk+d+YNQL6q +zf8vZD7rC2Y+e6fdzZzL54dyKfXRadece5JqlnFHAIqhGhgFFGmU1jJ1KW1XV2yFFOWA6WwEndA xLM67/N8DhjPG8B41jCDftTn43B2Ztoyba38gs7Wc7NMfTm+H/zo611OXznc5WvNBgQfgIKjhYl6 Zf4YPfVnrR8QfCconEm+WC4xl9r4GXiGOMPymcgLPMeJsmQSRZPImcwKzSGImi1us9kicqKJo9ar lx7logQD0mFRsYgYDAJsaSEBzWQ2mzgCgGtrIX7wtUwjNXOjmZhb8G5oKosSRdzIYeQehne7NRMw t9twoDQLMxKUnGHwRc5UIP49VtuBGMXAFNNn1B4AC03ffEXtgUqgWfweOHJ111RKBhgUWOoUpVbT hCkVisFNPuCdME2VkhWTwu/LnkJc9hTLy63T8wapx2QygUckw5dvyX62I0CdoQv5uv8JjTHHBVx0 kH5tb32HY8OrL78Gh79oe4nM4WoyA5cuXbAebz+/q+1XlHvuzMwkfmaXDdRSPJfCRBXEFJKc0G6S +CIvJDAS9YFFmhlADakX5Edn5BY9AePnVCWzg9oTKlyOmCfuKPPcie/6+OPMTGnEhn9/vIE+qSgz EzezJ1VpPl5ISaLKkRTAlSiAKnyR5xISHWnTzOxpL5gepomsp37pETjWs8wR7xnDzZkFH3+M78rM 3CAW0Wdk/5qZCTbX3xGHwAfAVXRtDxTg+1/G5vcb63pwYJ/l81szM2+9lUYnrsoe58P8pagT6k22 aJ1NVlNJwBosKbaWlFRYe3l6h/qWDCpJW9Mls6wzS+q7rbWuKn7I+3Bwq9XTyUgwKmJrXlDqmcBz nfYEXu50MHC407ueTzvJA7yYzrqgk3XEMU7nheTBntRAG0apfF++P9W5pLyCr+g8iL+y81i5LjVN nplapKxW3lD+bf13ytG73IZ5tbSw3Ncj5vZPLJ5bTIrDpbYq2z22TbasTdhk2277wcbZ2tMjbUpu 3ZpvjZVsTmkxunqAjSXw20Sa4G9LUkywsdEGmy3M+VrIc5rVz4wo/wZ3OEw7JFd1VF1k7hHmLMWT 1Ekdx3LOGBBynq4DQIO/TGISsUJqmeZc1e90y7SQp11bSBMY6CSdQt0SYwGfv1DTHChWr0LDEC9s IVdrtiKNzsOOJrsltyeFChpqoV4VuLAfGsQpFpNNdq9gYxKReHm3itYKsrkCV9DlObTZ9NY+lkDq S/gLSpmPVsoUdilT5KWFr4iHRZIvVolEdDMb0q1PTmYeio3FZRgUiH4WkGGTjEQWnRVtLDjDsinE 7n0ujKjTNSR0Ly6VUsFMYot1nGi3i1nENvXll9QWPpaqOtGWOqavmdD+2wbdAa5oTy1nIk+TKFGD nlJMvbne7NOzvEjP376UMPfO6/G4vb54kqOJ3HqiPlzEVU7ZO2v7/isWXNlz9pHpuKx6zfKb8pr8 179zx5rnhqsmX8H+sO/ag3Mn9Jgzc8YTybzbxgx8fuXQFUPdNmuwMGG+vssldQ3+hjsHa5Ou6rr4 5LmVl/TBn3YKq51qSq+sv3rYJTdSaVoF0kTHsVSUh9/QbsaCYi8UegrVglCV35RP8vMLwmXhy8Pz 8tfni31dld7K4BDvkGBaTltr7WnvNcFZ8nXWGfbrvdcHW/M/Vo74jgS+cH3n+y7wt7yj+dn8QFQo tZe6uwlVdk0YYh8uTBOO5P3En1UV1WPjRYJCYdCoZk/YZvEbURu/YYHRjE0twZi78B0LVi2apd7S aOH1DDULkxiLPzcIfdqIN+pBXYuxKI2Fzt5kAVrKWaNo31sWAtSyhVsYuzjKkJMJB8/kgdeHv5g7 Wabbipy+8EmCkFaM1+PNuAmfxHw+rsLDMIepx0LlBlOZyqMcjhnrYebXYSdlPcxYD9NXpLzNLvXS 6mE/Sy1i6aU4ELmi90W+GGWr+XpeDzt2DDiz7WJu1YPKVSylU9dCDfNRQwwQ3dGrrEeEeFQULyji 3L4Ok6W6PNs8f8e12xu0zI+/2T+blI+5d9ELT9+w6AVhX9tP9wy7580FmR8yHz6KN74y5s5Db73z GlsNaXj2OHcCUDeI/7kX+bIntQI2fMxa0MRKOytVvU3lDn5UuW25HdstmCZuzAOo551hi+QP8xZs 80gybTCJNZjE5gvRtY2gZIJ16P3X9IjKwXQP+qXu1hUmBeeH+7v6+0a5RvnqXfW+h8nD3EPWp9Sn gopsDZhnkZncLOEGZZ610fqMstu0x7xbUbzKKuVvhLMVTLTPtS+3c3ZMsTPZjWWT1EO11qPN6Cg6 Cf6p3W5BF+oYhqobDGmnDMl4xV5okxkuF4RYpOKUgarfaysYLxVaUvlgnoBlrNlSYHRpzMDTmB3X i5lhGuMIjbHDlYwJgowJBoU9jN08jPU8DO88hYclnC9VSUSysdE+M/2ZxLSTpK/yxK6WuofKD7YH P3QG6ZAyND+3BB6bwd+nDs7OP0VHJuYb6WKOilI1fQz+WaAKWMlw5rBPn/ubmxFhBKMoT3GVO/J+ ePFI5l/zv7lj21/ytweWj1/z3FO3z7obr/S9dBjnYfMLmKzY/nho9nW/e+/DA7cC5gwEXvpczwHH r2hLzYS3Jqzl1gFWoae7Z3gcGW0e6R4Vnk6mCFNNk9314db894UPXJ8GvnR96f7B9/fAlwxbvPn5 qSAFpMFBik5SV3Dsu3r7kp7WwaTaOtA9KDzOPNY63fql+LX3LD5lU7GHs1lUO2CORXIgAB3uItA5 8xIDnTLanz++xHox4bAbF1zMBEWMCRKq+o4Dqw7NUe9odAAuUc7V0cnhpJDgYOqY4pRDpHzuYGjl YKEf2o8OG+1Hh5F24jDSSyih1TNBWujUF9nQ13tg3OAslFjIQl/Z6xXpsPS5lJV4yh/DJE6KMPlh ek+K6HLFeIYZElKQ8UwgUj68A9LQOCQL9LSDCztYyQKcgDiVx3IxIPq9ADU0lyLW86K5MgA7uOMk zT5TDy7/4IZZ799Wv7F0V1v0hRsWPb3l5sWPr3ps3bknN2Fu7YjLiO3sQOJ8+81XXzvy9kGqkQaD RooA0niAOx7TfPko7AF/IS2kTWMsU7nZwlzTVIvs0Vf4Y011TBtJqbwwm8bv/Fg46z4d5Ls7+wa6 hy9z1gQvC49wTgiMDE9yzglOCi8WF3tOk9N+FXmx3erzDffSMBvnDdvXq5tVoqp8KGyW0D7yHJUS A9lbNdZVKgj0BhfAgs9YFeGiZcSYWePTrGAfsQCc1ViyxEoNO9ryVnorU1FJeZMVW4P5NOEtkSyn 25eoGZSP871UN0xgsz7LdDDN5VozPlALJa2wpNzoa13qdQSIduj3MOt3HSvCrMdZTiHt94s1TDrF Ro2OwTHggdMsHl3TPv0QTugTECvbGipz0/VycwaoZTPfgAV9xN8txVg0EMfYwgEid82+zt/v/Sbz A3b/5QNsw+ePm3eunLyu7QgZofQZe8fSrXis78lmnA86VMGdMp9l/q1Gt++bgTes6j/jGapzXMAO jcJ7yIeLtYjbhO2B0kC3gBaYF3hYecS61SoHrZ2sTYHWAB+gzaoF88vzZCun2MNm7CEpt4vnRGTe 5MburIu1oUvjc4n8rDF9im5i8ogj92GWIbOre59ylimTCueXr0c4oFHpDWhWkN6cs9mJOZoFVJ5R 55y7+WNutM6dG637lql5lhDHFjcDO5+t8YCe9Af2430ohk5jMzJ80va+oN4puE5M6k6kTqR195Su VlXh0HN33apDNEmiDHavanKGkEO0hzD4lSUrVuAUyON86miV0TmCII6A0xSmPXSBmZ2bNrmCty0a MiHUp8fIAYcPcw+ta5hdPnCc81HzwPpr152fBpJ3eWYE9y1IXgSV4N9r9RaL4O5sSbiHWKrdoikv kNfZknR3jldYermvsgx0j5VqLTMsZ80/eWxd452LLo1fWjSkaH3nzZ2lXrFexVWdB1oGxqqLR8dG F8+UJscmF9d3bux8pOh47Pv4D0UOn1f0tJAdzZ3CLompYjWKujFF3Iha0TvgdLaQZZoqhMN2c3VB WDF7PWWJso5Lgf1ozEs7oxWxgG7C73/Hh1Wf5qv3Nfr4ztAlZExnhsY+hsa+djT2MTSmi2awo9/q aEyvooto5NDYpycvMuKsIetntRmMcxbacQIV5DNmymfMlM+YKb/wFfth++f2rJ3Pt1fZh4Gloa/j yLDazmTUHqS8Yi9gyyOE6ZP11W/sDJvtgVTnhTEKz6mhF8S0ITfApHZEaAbRTHxP0zVljuVmDB/T Y/UNoMJ9dJID8yWK9FnBFKV94I2z8aNkx/n007ZbevRfuGyN34YXNX1y8vo/3bV/yTNTP9n8228f fGbZ0i3blizeUhsckegxZXzvpjtx5acPYLzugcbzs84cXvw8V/Kn1lfe/t1rv6NSuxoh7jgbN9mw F3lBpDy+crZEGHO8EnxPrprbZ+XZIY8vUO6THYrDzQkY2cOC5LaYFUPnKkZ3s8lUJSwUljBpZb3K sybcasJepnC9Gpuq0omVbtqxJurBOtikFWbNm4L0OhOLErFVKd20o9lYIVvnhU5zYfun97BE0qFs kKe4vFd5k/ekl8zzbvY2ebNe3kvcrKvdrEvdrPPdCT2zToVanaSrhkaBe48iniUB5YJTZzUfQwve SPjukF93VvcDEGHwQJjbMdRzxXB/R8OtIWVkezekTl3MAMYsL90HoDEshhM20SYlbKISwlYZEALR 0NMKlKIrIpbproHX63HEHazrRY9jdfMtrYteHNx8w+zhd1WCH/DjfemnHmmbSB5fffOou5e1vQzo sAY6t5JmiiMJP6sFiPlCeD03edOciy+eN4IN541FpnSCZx4Si8frC1WxUmSlZMnFONsMU7rNmGba ZkwzbdMXUiDMUeNYKbJS4nPx0/NG/FQnBINgT+7LxoV70eYfZlpv2mxqMrWaPjedNEnIlG+aZ2o0 bcodOmrKmsz5JrDfJZ5wJpGmImpd2FNvwUgURN4sSgkB8Zv4zXwT38of5cVW/iRPEB/l34E9ntdd PUKfnOt+nnU/b6bP55mi4A1FwRsDmKyeZsoK/FD550wwny0NTbs61XFV6PT8jqPIF/+xifXQ32ua m5v5vx8+fM7DJ88doVIKvcmdoTMmyGt7OGMA7cL4mtFfP2rd9ZUqWE/pa8jlaGZQiGPF8SbObv2n cFrkTMZsSj3nx2wQJoPgcuvNiGPGcDeaiVOMulhQ+eQuZxENMp9shq1TYAdi7IB2OxwReV7gxd6m K3ghIXYx15pv5G4wH+H+JkrPiDguJqWEXCH2MVVZh1nr+DqxVqozLeNvEh40vSa+y38oHhO/kf4l /lv2OM1mgeN4IoqSySTDjkmWE5LoliSR4/mEYHYLgtkM3c3TITpeoMMuFgsy8y3YrpkEngUDC2S6 Vx1l3piqJ1quB2MuNwuEAYRFX5ctgfRxJ8IO6iNOJIEx2BVVaBiIFHS71p1BA8ulR/oUBcYhNCYB UMBcPMR8TRRQrH+NXTGto2Kg6xmpOXOBpiI0nKapCODUtY+4gL3uq6BjfHQ9O9j62UKXkipXypUc K3PjVdbBJpxvup0jJr+VZuaC86evfaeZTZ3zKkxyXl6lSCdN5lWINFkvyjY7YrkV7lhadQNKpViG kJht3RljGbw7vXTz2U61QtQ3bE9hmx0WIy2bupn0Uc5PeSy7vfA0t7uSFTS9aqef/vi7HSH9cpyu 02NrFxIo9ExeGkvHcSwBu+PnvsnMwq98lnl8ubDv/H7clFnUNoXkL8nQtaVvAwHozea81GjWjjh2 EXbl5rl0QKqL0ElfzqkjFl2EP/oItMDQhs1r6d1Hn99S3lPfduuub/UV5Fu1BKhJu5AvbBI+F/hh UJwUuHxhntAoZAUe9IqZcLqqoXdiKscDdt4mhFvRSWClDnrnzAW9k9dB7+hspVuocs48NdImslkj kSIHP2gofzH8UPxh4wf6nBi29/M/2gW3NbPpMbodICbBmoyTL/YiVw5S1A6ZuTrhMIg8o/nCBhEy iKBB5BnLEIQNImQQQYNQjBQCq0HYDMJuEC7DflQNwmkQDoNwGWaIahBOg3AYhNXIHZUNgg6VaTUW a3mCP8YfM/3V92VU+EA4HSU+ORo3+UNRE8fFI2HRQw0/CYvxYEA1v5PA6xObEyTh8wVtifUO7OBZ +IClrjpYPJ6FD9xsQZ3cYntAERZEUFgQgUXiHUbqcYdQAk5rEb/cIQGRMas/sT6EQ+wBofYHhNgD QjSM5aAPCDErJcSiTSEKVsxcCin0USEj6B+iT+iESFmc3T7OwC7OwC6ewO8gTENrJB9RyOMY5OX9 B+Sx+Dzy5myi84b3dEpzM+NIZ0mbjoKFiRa8eFfsiostZD1SyozhDvHTdMf58HS/jY1HN8xH1LEC XVpDcyEcvo7TI22K25V0K44Qdlo9hulk+Lz/TdHSVTxZppaPLVvFLCvmfHW0sR7v8cysRffn3/Lm Y8/tik+4dN6vm2unDFnRl09uGDrx2tp92/e0FZFHr5vYd8NTbfeTnYsXD3/o3raPcxb1VyBJXrxD cwmc6CJb1Bb1b9zXrpPcaZfIUz1ZACx3k4ofUN/xH/Vn/XxUdtvcXidY1Fj0Ws1Wm2IzmNZmSJwt lxUHVKGfWdF+ZlFbmC1tYba0pd2WtjAYsRSwK3LreIhwFe0rCxtLZsF1cy7qflpjusvCzHULhn/L UD+Frc7Urvaf9JN5/s3+Jn+rn/dzpMzjZXzjZTzkZdzjTeizkByO3OS4XzSnzT8zpx0dzGk+h26t mvPn5vlQH1ttqf1PN7BPMRP7ohMpPXlbH9Gk+dvtNrZXdJjMslkyc6KadIi2ELabnTmGoTNhG6gS ZYyRG+LpwBWrn7jh0/rHh6vm5pLZVy54lk/ev716Xk2PZW0LyKrr51x239ttbDb/gOxxvgh63ooC +JU9Hn8uTf04E226xp42lVIBdsIpmQPKFeKV8lixTp4uzpTlcrWvs6+3p79aHewc7K32TxAmmEaq aWfaO9I/R5hjmqLOcc7xTvHfiD0mUbBezY0WRpuvVq7jpgpTzdcpZl+YlxwAVB0z2U4ZuW1nNBdz hgpDzMcOMdaR2pd5l1isMxfNN4ZlGJGbpqIvypebysKIVs1WmCjvJmEkqVJU4qQLK4Z2/xzQil4x h4bJgLYxdrHpWTyMaWyFSLHR0AxbwwOxwQQUZtzBAmE5/Pj/2vsWOCmKq9/T1T3dPbMzO899zL5m 9r2wyOKygAsrOyAvQQVcQBZBUIHIQxHBN8E1PtD4jCaKxggS4wNMWBaEBU3A+AoYlCSAUaOSiEZj CMYP/aK4O/d/qruXYUBJ8uX+7u/eu7P771NVXdVdXXXq1KlTVd1SWpJ8ayYlcDsWTIKkCc1+cb98 +wydnMemMvuV/amcEFhYPQ1q1rSj+cPZE8M2UbkOoMnV5L7AdYFbY3WFY4XlizPJfo1m6tB72KO3 vviWkn3tx7e923lgc9uym9vW37SsTYSVyjuv6Pxjx86Pv6MUKb5fv/Lr37z4yg5kdlnnHK0YXBGi IuW+xGJv4KTAqYExAa0x3hoXsXgPb2lhbVZt4dDCS+N3x82BOQPzR+eMzm82z/VOzZmaP9ec550T uDhnXv62+O8ib+e+nfe7ov2R/UX74sl4dqlWHajO6qcNDIzQRgemBN7P+LiwM5ARzFSzC3iqTs8u yMygzKjDEFGHIaL2Rku4ynZ5lIAn4ZnhafFocckW8YS9HvEDa52GJ9dZn+iMFLp2YFrTdh7m7X5y reJiJdxX9LXN4JYB3DKGlxMdfz7OmYYLpEzDBY6ahvs8fRpOTvFD4MtpuNjIAbnKUfNwXdNw1Yf2 HzsDZ+3rqE+dgAs7/UF2VkS+gq0yqKbU+LJHB95z0S275l7+7rVT7uodfOyKq9Y8vnjRus45rp9/ d/z425PLf9x5+LYzBnYcVh/d+cIre17Z8TpLg1Gdc9R9qPcAFShXJeZniGrRM3eQGCOu9uqNWY3R MdG7i1YWuerCdfmNRcPCw/Kbwk35F4YvzJ9R1FK0W98T+kD/yPuX3EAPUeKtzqoX/bynixHeKWKO eMP7Vu572R9FP8j/SvgVzRfJK8gwMvVIgYbKzsnsS059p8512YY34mkQvxLwJ/wz/C1+rUga3opk jful4c3fZXjzS8ObXxre/O3W2j72c234rZ05uhV9mpRwi+0vbKR+c6PsmBmP1BmwMilvpIXNkBY2 I9sao1n278KidNuabVpLsas5VrVDDcdWLS1UgvZUWH/blHbUfEevnvdP/HnnwQW/W/riwlUdxU9d teixtVdc/uPOOcIcdJbSWzFWdt7w2J1fnqb+dOfO51/evfdl1pRvQuW+hHoN0juJM2vCSkBTSrU6 7TStSZutLdZ0d9B0m25fOOj2kWoqGbIhksdddbepmCXxsBIWJUd9kMQqrq+3THWNEP6RCKZ0pboU lkfpX5ZxSk8ZhZ4VGvnC8YxT+wPTDl3G7+Dg8qp3XqROge3LMuW+3mmX8WtXrFZhGaYN9IM3rRo8 p/Hc8wYPHTrovEiRVvHIwlEDH68c2Tjjso7dyHNj8kN1HUqmjwrNxzLdW0psVB6rUt5EbTkqUl68 fMh5O4flKHUcJY6j2HHE+VGvk1amkkjJQPdo97CySSWzSpa473TfWPZYeE2vX6o+d05ebk6fMb32 5rjyxUQhArWKJ3eqOdU91TM1Y6p3qm+uOdc91zM3Y653rm9DxYZKPy/hL+vRv2yKpzljZsXMqsWl i8tayu71POS9p+r+Xj/o86jnSe+PKx+tWl/xYkV2lTOCKHEcpY6jzHHYz6s7j6A7D6U7j6nzEOmd RKiofopZWe71aHnxiiwto3dhHhvZS6K95BRltDE6Njo9ujb6WlT3R2PRBdF3o1oseldURH8ODsgC P8rZr0SEowd4c3lA2aUIUgKKfCPK+kh2nZwVC2QG6xSl99TC+YWisCDL0Kw1QtLu9YFj2/ogEWY2 0gp6Z8TylLyyaCKcW1fLyfvJ2ZVc68itNSq/PRSNc8ponFNFpY0lKuev+Czqfos4l4zkpxulZaqs Jy70dEH9rp5KT74np+/pbM7q6ciUntb6Xuk4tJGv0jNP5qC4smfdjNpttaKxtqVW1PIEXxnlWkMT ye9xq/CF9f5zzpfklhjnLS65MF7ml72LX+bdH7eF25eJCiny5MsJbAu/XMjpL3nXMQBFT7bn4yCF Ul/bhU64+sBlZznLkKqrF/KsXMpA5gDP2Vfzp1oWykVIPB7nPSdMul74kmPpqYnKk4pKXZFeFcFA KBAOqHqJL55P7iojX3GdhENRBN7izNJ8Kin1ec0ennylqtLt0au1fIoFClmjtV7zIg9yCNSz+vrr r6cUiclWyGlHAo76MEZlRWVv0a+u/4BjtrLgj3e3yrmIxjb/rdcuuapf+b0vPTB2yCk9v9f07Z9P CbZ6F81ZMjc7uyb/xq33T5rz0rdfe0M5tWDeZbOGnVqaW157+vVnjby6KlY96tpv5Z499ewBpQWF YU9Z3yFLpk5Zcc5TLFvLkp+Knq4HKEeJ8VcyOp13uXbtMuh0vgBgOXTH4ZEvJ6mok9/ta4KjJaqQ 4vV5FJWyA+5qvwe6kJrhD5RQieI7Sj3xWOqJV0ka5nD38BnGpUaLcbehEZTalUarsc3YZehyM7e9 q/uQZFa5wUEuh7FGarbD3uf9peQ9VpdZhWLTq601W4MBY4uYS7lK/3Wz06w28vtr1uzBfu7RDvCa TO7Rgn37BranbP0rz7Fm8nkCMThAfpVC7u4QgbwzGi6Y3+vGG9c//XS4uqrokRWBwbNWiQtvV4z5 nXfc3nHvmb3y2KoGWb2PvwOv3LCZ8niaOyunTsTD2bx585NENBSpqw4rZWY426uEszPQgQVRftQ3 2xmXZjtKRnbXuDS7PDeHB5B5cnSaI8elOSE5ede1SjFHdl45XSPSnIg9jWfP7uRIc0WOtSUYRZbM UbblKDln5XHFVvJgNO+TPHFp3sq81rxknsaLiHjuSVal12tPOnV1pPxtsLh7l3ufW3M7Ham7qyO1 55s8cpZJLnaWM0tyNOqWkzvus6JHGdbsGZxjh51WpyqXdzU4LydFY87TApk+v4+3BPAr0DD01Lz5 5DOD+cQDz549r4eegpT2uozKCrlLJ0c2xf7sVhuX7Dnvx2MDGRsygpeMH3/noA0PbRh18dh+i8Q9 HevvOHnk+Ka7bhH1h99EjebxTB5q1CP689tiPrXf3JlpK4Lp221Etm387PpMxCcJ2RREIGU1WI7L JI+pK3rXppoy+WaLmurUvTVya82mfi6FSoL1Hu7SfMF6d3aooM7kg8BN14MqNvWw1c1dVFxHVTjI wYO7pLyOsnGA783E0qredRTHwe/tQVXuCk899fOMopGeScok0WxOds9WZos55hz3VXSlcqW42rzK faVnmbJM3Kzeatxiftf9I1ru/p7nKVrl+TltMtZ5ttOLnjdpj+ev9J7nMB3y9MLjeHIp21NFFZ4B nrGU8LhdiVB2nQuFU+d8Jox3FOmsuzG3+uUGLJI9A5cFh8kRCJeKDBUulzeDV5m+XY2yAXZW76ym mq6tRwM8hmmWuz0Rt9tDqhDl1o4Pl8cD7VBu39ANj1slxVXjVbwlZiKRsD5FquQ/nXC1uIQLroQ7 LhJKScZffstseSAv2jGtY1pe7oH90+z3M3fNJQTrj35bCy97t1e4Hvml7gBy9lCE+yrKzzrn/2J/ eSy3+q+bOy/RKjpu/NaCCVeIW6zZKN4TsQmcFnJN570aNqdZ43o5+VvotWZQ2Bwr7Zcua/pPruNU Uwzvf7E2TgRkT6vr9u7QLx07sL1xwuqIQ84Js+uEodsmZHv/hMXsAbmVSNfsabKvjljPUj6/GHI2 qpldJ6wXvHucTUbW22+lhl5in/jQmWizP+MQjFun7R7oHWfq8531R5oQf5vlkGWTM6zV27o9mt4t v/ClWa+g55Vmca91YtuGTGsucluihl3BhPR7gqpCXijiiu4Hy/i8cueAN6gIzaMFPba12eqLgvz5 g52BvTsDu+VLnOyNSpIFnC4/H/IuovTUenjE6OC5wTuDajBufbHJ/raK5jj4qzIJd6y4LlBQaE39 JTbFyuo03esO6/nuaMilkaZnuDMyzVCAwmrEKDDzMwozy6jc6GlWZ9ZRP2OgOShzmDpSTxhnmmMy TvOPDI4Ones/OzTPmGl+K3S1fo2x2Nysb/FvDH2mH3ZXZQSrqMpXmVnlrwzVRE6hAaErzZvN5er9 3seVJ8QTGY95n6aN+pbMX2l79TfcH2of+v8cOqR/6S7IkNv5vfIY0K3l+JY2J61udtvO92T6tRAF TcMsN/zlmWyeyDRUn+It97Un9yYGcJ/gQxOVr5FTfEokrHsyghWe6uAE7WzP1OD84JLgd4OeoEdD g+XqsComfU9YTfWhGmtncWA//1naHv7zExFV7hUzXG6PxwQ7ewJBXsA4Zr2LQlBaT0/M9vgz488H DTNuBEOhapcRcbmMTNRzuS8z4vNlmhikV3vMCJLzBjJbnJBQjJBm+oPeTJ/MXgj9KL/bkuVLyM9v YPFEPg/4FH5RXYtP9bUrjyc88bEeZYHnOt69IyYm3GODyoLgdUHeJDsxkRFwKTPk3JYKCfT408rn 4c9nSz04euahadNyocfinyXRtNzjbx6zRVNQHv+JvWNGZqCBwW7GmNZY0+QNvrg3Lp5N7sNYZx9l JndtoD7+ONrxvq5vVTSPaa1rku9K27XO4JfwI6C4aUxrX7mM1kzuW2fErdCQ/dYqfj3Cro0YBeDa kAS72ow+fMU2OkVsse7UdfGudDkyXTC5b70nrsXpFHtjmv2yhd0bQ/XUKyRfjrIufGRHkTUHx81P vtHqaO37634skqVEDufIPW1qpaqM6Xxmy5ONWt8nN6/od+rGtZ0bnnmyx+sQ0T/cH9whLulY/spO Mfvwm2LJ01+9Blnth1bwd8jqgFD4tVu2rA50rSFIeI5szbX7/Cy/kqFrwq0L3QfG9ssBn7+mWvK2 fD1u/iZ/SPGXROUscWJctH6K/z7tPvOBzAf921zb9G3GK363P5Fdn6eG3Vm+vEA/ZWDG9cqdGWZN 6Byt2WjOmJx5v7Lcszxjk2j3/ipjR+avA2+qe9y/8b0VeN8TctpohpdCQX+uD/qh/C5HJrv8Ogkf eTxCl2+tYs6qrra3X87WddUw3W5F1928tw2aN9Qvn+L3+wIZ0ASFL0P1Bjy6X/g9gZfoJbcIlJM7 QuRWhe8ln+Ir96oRr1f1uN2qKnSMKL1e8owNKaHTfUu9JR7/+bp7acKDXnhTQh+nt8i3hZ+WyIyr S0XJWBT26cElL9hfsJQdM/rlwPuBQwfkm/+ONAv5bWGb6afZXxGr9/uXmZLZrSMIt4AGs8HmrQ2Z uYX1GfIlWoX13pKcehVgf1txfUDuLc+qV0qK692JAuedHtXNclZDzsGzF/163xzu4QfwzLtaqfiV Gzsf+OOPexf0Kl//euf3lNvefnNg50eiSun8YmSfoX0Pd3o7XlVGN3dO416/uHO8+jdwUp6Yh/F0 rrW0ylr7LscD8ujX7KnXQ4kay+QvJ17l0WvFsCYB5NFnKexeZ0rXYkZvKjMWeiJ+NUMtiPpDeoYe ToT88YyEN24zZbSmOu/tvNydedEAE2nPkt1c/np/AW8FeCdxcUF9VWSSf61HTfgSqPl4VZ+6AB8M rzuU7csNVWZUeit9/b39ff0yHwhmVIWqwqOym0PN4easOaE54TlZV+tX+K4OXhO5Jusm33eDt4du D98aWe55IuPZwDPBLZG/eP4c+czXEfgikiwoclg3O5xRkK/5h/lv9Kv+aFf2LXtbqGu/8AC/3xuA bIc6GI2Ew+UhTwQevxfCuzzDE8nI8IR5U1uGzheggkCBqCnYWiAK2kXj036URSLSLiYkMhpDiZCY HtoaEqF2ZehGv1JCw/M9fEqWViLu7eMd61XHeZNe4UWM9TW8TUI0bsiPL4EgR+F18Pvpwa387r/c wKH9Uf5e74G83MAB6aJcHog6rGumrk1h3l0mGRVSOhPSMRfS8RmM3T+kjOSHSqpsjCTf2Tig3lMy oD6TX76XVR+0Xz/TzEMpgmJq82mKelodrrRWRA6Qe3tt9ZS/4Vpacl1kUK+GUTnBCldG58W/fLu6 JFb93obO+UPK+iyZVNf5rScDVWX58/yFWlXHA5dfv+QKMe/wr9YObW5iXq6CVNwNXs5UntuodL0P 0FokEmoX200RUmqt3bWvJtxwKIOL5NqnXyZGw9FDVLlrAvVKved0ZYQYYZ7uHhuYqkwQE8wp7nGB +cqF4kJzrvtaZbF5rfs25SbzVvcXyiH+4kiF0sOsdtebPzFfVwxutZsCWXUCvYWbt62XhuoVMdDt EabHU64I9OZC4a8ZiPN5P6fuOd9H1geEpXJSnekR7Yp/A/p2l/6MOJeIDLYBy5m7Et/KTIUyE5kz MlsyP8l0SfW3jE9lLibPUkVZS8pYWkBJUkm+F4ui/sDiYhZfbGy3VioFOtixv1ouc5bfOaluCLzf 2NDxvtxVYA8vApkv2O8FtW1KqOyneygVJtserdIzuSzh++UmLkUuSuuFxAub5TZc7prfafNzIdjk w0359W4zO/9U1jXbcuqtN8Vk14sIkJd9RMDxUqJ+il7KbwVRjP59i7OqxKOLJneOVWd2PLfg6rnK x/eopn7PlR3nXev+IX/R4CBKKSS/MW9QBjUkQrpLKJqngTUkTVM9ngaMt6JtRgNUnegmtYFe8b7x Gcv0Dv6zxXjgQE6t9fn5YhsHdyrv7FTefnWn/JGgJvW/xBTX73CPHPp9YuqK6NqoOGgcDIt3jXfD 4jXjtbDYamwNi7XG2rBYYawIi7uMu8JiqbE0LA6bhyNivjk/IqaYUyLCa3ojIhI2jRyvP4NU/xeZ 6hci0ycUb4OPGvgjhuMSNeEFxnXGXYZqKOFTIg2ZPm8DVL1ETl5d5uWKcYrZIBRqUNW7hCKiuQsf t6yYPEnGb1uRX1uWLmqc1tDRcCBwwHpK66s/+Cd+8RkGD5ctXLhQWWj/lGlKVqn8wE2OrhvFKW4l 8ly857m9BtSpyvcdl/bCb35yc8O4HiNyzj3niAslNVL9SJzl2i5L6q3EWbKkPjE/iQjFVCJin7Ev LHYZu8Jim7EtLFqN1rBYZawKi3uMe8LiO8Z3wuJS49KwmGXOiogms8kuKQzyVIqsCXPZeH0oskwU lmKuMTigj4ICFNSgKJn+Bi/Kq9KXMxi9ExeX73IhUOsoskriVyXMlaXFnyXiucQGWVT7A9Itv/uD RnLAoUcXVlc5LVyIclOm8erOiCE/AjSgb4r7nOdi1ef26t9P/b3j0P6BAho0vsfI7OlNR1wst+ar HymnyrJanKj4nfGeIdYZzxviU1O513zEFIvM75hiojnLFMJUTJSA/cBF8oEV8LtCXU8nHy/q/dHV XcxgP1WHVffW85BT7VzvqY+w5Hi55TzeQ6QNVVvRwihcHCy+R239ahyD50Tb6FatVP2SfJSPqLUp H4vrn8OrbpzJuQoxd8HuKzo7N27q7Lxi94JpP7tg7/3377ngZ+qXl+2+DGGK2LTod5edcV7reffv 3Xs/CO575NppVxbzLjlyraOvAJnJc23kij54seujzdP9DZ+Z+SaH0qr3KnsyfWXcoI1fru34VoBM L7xuxFfITmcM7jyLTgvQl2u/vCZAdnjXz9es20Givgut4nU6T1tEWcDpRiFd6ZpEk5VlNEWspiUM tZAS2lN0GeKuhn8I6BZOi/gTgXeBBmASkGeHnQmcDzSxH3E3c1pc41K+jqSLaIoZowWuSckO3O8+ 18s0G3gY7lXae/SEXk8Xw/8o0m3ViAZwHKS5T19NyxH+EM5fiLCHQSfD/wjcU5Guj+12G3dQlCmg I7wHrnOb/byV6nPUX1uU/COepRnXHA3cjHuMAx0BjEGcMOhQYJnyMt2ivJxchfOgdAPuv4zDgWE2 HYXr3ITzjUhXBv8NcOchHzqoHygGqsRThK6CngWtwfOfYz038DJdxM/c9UzIv52nY2HlcUwqcM+f A6WiPvk+qDslb+m4IQ2nq32pBXQekA+MFzvpYu0MUlBeD7jeJ5UBzuNyegc4VZtJZ8GvIJ9Nrg30 IPuBMyUWJTu0h2ileohOwblr9PvwHDNR3icDn1ON+CudpJfTdeCvYbj+9cDDuOaHkh9m0gTcvzdo X+19yUM3A7fjXgedcuKygf961OvZuNdX3CKQvgkYiXppAeZzfnD/Gi5zrndlUmc94u5HnKkMhOdI 4NmZJzkNp8e1ym0+XHWE0irEuQPlug9UA7I4Dw4kn9nAuZdwnSigA4VAb+B9YBUwDxgIjAGqcG/C fVXJr+AZ5k3JH+AN18soQ+RN8qz1DA/L+rTazCP2tfg+xfpTNM9GMV+T2wvzLPKyzrk2tynmGYdK /p4n+f5v/JzMU10UbU/7mEZyHmQbBG85lNsd8szt4T4xkW4BfRB8fAPzLOfPoVwuzGuyTNAmbNqQ 8qx9ZBsBhSgutXn9Boc6ZdFFL6JHcc0Z+gWQKStplLaYRqnfowu0T2iY2oN6u/ogDM+DuK3iYzrb 3EZ9UZdj4X8gjS5nGHuUua5teM41KM899COU6UJtjyjR9igu15rkRy5StrvWiKXSfQxNh7LNOseU kXruXw3/dyD2utZAZq5J/sW1J5nE89zDbcL4WOkDxB2K8DagBehpVivLzXlKuzGRAjrRIWCBlqCB rgQN0LahfrIg59EWED7R9Ufaqt6B/mtP8g2lhVrEHrrZyKLzxX2QabiX2Es3MPj6oJem8NFRPJfO Sw51+DWdssy3eSoGqqP9vWpjv43Pgc/AR2PAk1HuG1g+y/4BMhq42eLX5Jdd/LmdfgJ6m8OfaXw6 L40/vel8mU5l3wL57rRT5ONW5/lZPrKMYxnJco7ljBM/naak/65YDT5mObyTptjtusTGaOTxT3bb hxxGfZ+TTOojko/rG5JPqKHkE3ot3L8HXMnH8dxXdfWpk5Oddn/aw+lLrXDKcPpRV1+62JZnj0p5 8yl9X/ajk2T+3Ppaus51GPUOGSjzu9JugyhP5HueNgNl/iDdjueIqsvQHhEOTOUykXVBlMv9AveJ 6g9QztwX3UE3qG9BX+C0fSko+4tGOgd53y7D0Kcy5TDXObRK/5hqtYmQtdtoJtcVPwfnh+vevJx8 ZhbkxB46WXsScbLIg3grZRkk6HHJF5x2HlQqlIVxIRng2bMQh6/3iEyToJBdHo/KspDpoYswD3NZ 4Jp6Fp0t9YmPaYVrIp2DNvSI0UKPYJhKaBdP4Bo/QbqJnBeky5P99Q/oXLSvWyCbboHMIcn/U5KH 1TV4nqsg1wG1BWW0hnJdLSjDefLZh2mWjF3G7UddTRXMI/oPIIdZn/gBfVerpuH6PLoDYXe4ICdx 39sQdiPabx+03VuRPmbLbcK9b0U4p21kXYZ1BG4vRoLCeovUA0jmgfUU3F/9iB5RR9Mt4OMh5g9Q DjfRSWBpVhqLgJMtSP9SG7dbkGEBiyrFaoC+zeGiL/0Wd8ggSnIfulm7nuZok6hWPRltN0gnab9B W/2Cfqj6abq2g36otdPt7NfCVAWNfZy6Abolh79G4zhc/Bb+5TRFa0D6W+gSbTotUteB93aTR5uN ukY6153gkzKk/xTXtaG8R1PUSWhbN8P9RfIpjifvsSF5DkMbRSfJdCmQeXWQlmcxBk81GnWK/LL7 qPwir135dPJ4nPzJ5+TrIh3H0X5IDSinPwDlFu0cL+6gNcBK8Sadpp5JVytPJLegXEekYVSqX+un LAF6a/1oE3A93L1AfwGstfzQ3frRW8BNuPZzoOt1OYmKsdhQ6s8UYQ8Dy4FXnHOp4PscLzwVrvzk lqP8T6OvAZRDyS2M9Pgo5/64X3/t1OQWBnhxNEO/jiLGFRRRKxFehHRpflc+2tPTVKZS8r9PlKdv An59UsoxkfqMTn2AZv8T+EMKjTO1+4Z/O2//LlC/1wHTZPn+jbIsHqJMZW/yD6CTlL0UUC8HDwLw nwR/2ClPp54Qfq8MT6s/8ApxmaeHp/vT6/VEfrGepqfC4YMufriHBjO0RsQH0v3mdhrM0F/EuReP 9WuPnwBTqKf6IOcJPFh5rF8fS5UMUYa85nEatDmgy/8aZATAcWV6H41kcNtliA0YrwFd5/vRcEZK ufbnclUftM479ePUS3r9IH8J7VU6HbQCtB60CXS0Q1PbbHq7TQ9zZMnx4qS1jT5fd83/l4C2swN4 GXjpf/e9FAKvAgFA/wP0kEbokXugn5zLO047IEu+qgEegxyaAPo6wtB7d/YAfHAHEfYt0B8RHf4M 7ssQvsdCUmj5tNLWK6MI22inNe3rNVnpD/+K6MtDwFor/eHVwFy4/w6gPz/8NuhzoMsR/y9IdyPo L63zHdPhvwJ4Fv6P4Z8PTIb7btAs0F5AGAgh/X0M1keOGYf+x+nxxx//LIXOciHyGWObF+iS9DHE P02d+jwBTR9rOPV/IppiM0ijVjlgzPQn6H2tqWOfbxrjOBT12ZkKbWKyAzqll/Vo1mVZf5b6o03l +E3qsbgvUcShrDuz/sq6M+uvoI9Im4FL5mcij/Nlvux+I1W2KofoYSAA5Nt0HuJ8ISqTr0L2+MHf n2Fs9CgD/kxgkoXka+i7/OjrtkLufga6E/5C0M+cPs2RrcfI2BP0af9p/7/aR/4bfWqtjelp+Lpw B6fYOJ2R3hf/qzhR3/1v9+Vf00en9tP/U7/TzztwD6ZahpFIbmGk66XH6AEn8J9Iz/1X/el6x7/s T9NLHH86jjmfznuOPpNHeV1Ia3f/KnhsoT19RPd38pDejrvam+1HGQ1PBeRAld2HroK8gP6fLATQ RyXvQdhS8yuqNX9KtfA/DaDf7DwAOpPPga5Q7mD7drID/u/AH9B2yriTbcw8ET+n8y3r51I/RJlJ OXg3559qgEFACFgHXOzUNY8hce83BHpdHudqU5Kfaa8CaTrgCWk/Wgj8FH4//H7I4ogehNxO0ONs jwf1gHog38cfsfElO/RrZJzR0ra8mEZBzl+i7WHbV/IFadPrJP62Bc+j3IA+NObY6eDPYtuQEWd7 SbLdts/N0D9FP3gO+kM39x247yQ5JzRPYzvup/R9NYOG2TbkiGNLZvsU91d6bwpIO0aqHfk9Olmb SsOARs2ap5rI9hf1fTlXs4zt7upZ9Kw9v9XqWU0Pu1+mh82ZNMK8Ts433ac+RDcg7CHjTnpIr5bz KxOdfpX7xOPY/tiWmddl07SfOV0nkPmbSmewPSb1vk46cwT60k+lHcqyY55At0Ef/11gpjVfkfz8 +PbO5K9tu+dFdh9/RVefn26nn0rj1aUY9zk22cdA99J52s2AXcbpeXHuhXLp+DpdyNFN4D5H2vqs +R62QYVT5uFGyHL+SNbX6VxnLh/asJ/rP7lZs+bnhmpXIb6gqHYQsGyPcn6ObcPAOeINxH8YbfQS tBXwoHavnMO70QbiJh+T6eZb82Z6E9CIfM1GutU8d+SAbjqC5H5tIn1XQtrVkqtEJLkZ9DLxipxj 9NtzgVHtdpogbZpH5gRztSppt67SJgCof+Bq+Mvks9tUllUC6fwY1/Ezsm2uNxHOmeog20ZqxzU2 0QgjAX7NoBGu9VSmLoD+sg2yrgB1Nxr16qcb1D9RkXYKXagGaSZDGZF8VfkYFJo6Q/wF4W+Afg9+ nvt9nc5z5tUs+zQdltgBXQGw53IZsxhitVJszxM22+5Cy42wetoo4VxjNT2WAsRL/gk4LL6Pew+l maId91iJvOA+agDtLw1Ic4GNKvs+I7Vz0MaOxmnpQFqmNelAONPydNjheelAONOh6UD40OPk4+vi fV0+vi68Ih0Ir/gP5OPrrluaDoSXfkP+xqQD4WP+hXx8XTmXpQPhZd+Qj7PSgfCz0vMB+YRxbOdL GJs+Bfp7u7//CPQMUHBf5wtwY3yRnG37f2/Hux/A+Df5AICxcnKoDci8JI+Bl4H+FcC4Ojn+CDq3 gxZY6zCc+yTvBXoCk6x7cdrOZ6x7S9j37Fxvpe/4Keiv0vzZwAfW/eS9WfZuAS0FHrSf7xb7vq1W 3jvvPRK/s8B6Rpmu9QiSKnA20sdAm46g82kLyedBfwawXfRlO1/sLrLLg595E1/riFygL7UHITNm EKGvjhirLapdS2dImfvaUX3VpVIevkdPSHmXhOxroFrdBz3kRzSU9QaW4a5ZMv5trpnomwj6ySQ5 nzdP20cu7UWKut6n6dolNEzdCL14JOQt7iHnZXBtltusc6i30pmAnKuUc0I8d3IVLfNskPpLAHEi 2p+R3wdoK8Zst7gmk4L0utEb/rvRrz9CV7mupWvMi2mr/gnyuodmo7+K6dOp3vUdGuWMbfWLye3y Qi+wqbmcLjR6IXw1xbUPqMC9DHrdLhqHMhvg3Ltr7t6gCMIfs+wrkv+Ar6qBM2SekV/oYRrG1hFn 3YBrGspkpszPWXLO6UnSMEYn10H03adTleGG7lVDt7hzaaX+OZ5Dh55aLeflZ9tl34fnn4xv0cmu ZVThjN31/SjnCeRxKM/HOfYA6G6PaBdJfTEk57Vse0AXda7B820tdDuvlUjXaxw9qkunsG0EXTYH 53lAuf/sen6bpugblk1hG/TTLKrmeTxpE0mndp7kPN428JKtzxpbabShgj5Gs/Wbqcl1JsolTE3G 8xQyRlIu62eGIfW6i7mPdn0BXbSJKlA3p9nt/UqA29JIu40vRvjrwFNWe+T2xeGybSKs40E7fC6w BJhjnedzyessd8dB6/ry3BIrfgfaYZLn4ESKreZdC3IcEk/VU+21VDcfQ4/M3TP/jDgh/SdtaNyG eU3Vceb40+m9oBc5fuh576KN3oO0cUB39Oh0qlnrU5ZaVOqGTH9i0x8zr7Gul07T16983XqWb9Bj rXbm0KPXvTj0PJtWdK3LOQFNXSdzhCaTtj/zn7Xd2Ta3PIceZ/2BZZM7QvVjxk+pVNYJqbYey/r7 aDnPz2tzvgFda7i+Ax44GpMYvJ7geNDRkzCM+UfD1vO/FvpdSAeYsXQk/4uBPF9vIflDGx/bWMVQ FYylAe176Uj+l8Tx19cN03+E+wLmSRaM7Rak/v8NQBmQgRZshiTVuS/8RkDLYBgHbdzmIJlkOOXu lKNTLni2D/DcF3Xl2bm/fd3/aT3+T+vlP/Xc35T3VNhr9BzKa/f04+Yb9SPxXxbkWprVFLaho1yf AdYAO2zcy0BbyeO1Suos8NMsuV6xK80xfHAHxqYM22+vv9F1aHZGrtUOeO2PBWo+XvkYsyz+Myqt cpLrdizd6308h89eYzvbln1l7nH0iL1ONsayBf0ut/M+2nM0+2idL9lkjaeTq9BPuhA/6FpMI8Qr yR+7roFM+CT5K9d10AUA3OtGG9ttrLR0v+Raex2kLtcDr6YnU4GxbRGD4+B+i4Cf2Po267GXWej8 sxV+JF+O7FX/gec4TFG5vjQhx9fjtDkY08+hqPoxzkNf4Pkm9Xwawn2G2h+6Fa+5ucpeL8u2h3dA LfhQLuPUJ1LaN6+v4XU1gFyTw/X0EvoAjv+STO+M76ukfWke5PhbFJNrf3BOrunBNXitE+tFKkYU rrHgi/GIOz75G3U56Cgb/wAuQX4n0RxxI52kzsZ4eBf0nSyELwQWwJ0L6geagYeAK+hkGX4YfPIl 4gOqBv+vQV0Y27sQ9oWN2y3weTne3kgzoRPPxPWseHtkGgs6zVR+Ke81Ux2K6yGewEhJhUahZtlu HedvQrqt1vid7QocX55z4riPxHEdoBGe2TRCDwO3Jre4hiS3KB9RgzaFgqhTH9APdf2qPX5gPeo1 AKWVfBj+HSJ9XYAzT25T109pjutUOsnVAf3gD+CDfdTg+px+6GqkKn0c+rGniHlpEMBju9m8nliu Jd6TfNWxfTvQJ1OW+0UaiTokXr/hULGGNw/geSfK/kiupVdYe1tjaWRy/bTV1qSeawyjG9CORwCj 7HXfs635MeigaHuatU61SvsJFVp6HI+hOlFaSW4PTZANXbZXprymjXnL1gWRNPmU+C2Pa5MDeK5C jOP1WjLtuda4NMn26u8DbLN8KGX+6T7G/+n5LZE2D/V180UnWptxorUax/j/xTmV9LUbJ1rLcUJ/ 2pzLiebLwKusI49Av7JVX53cA/8m4HuQr48yNEompX3U0tduVTPQthdjDHo6ldk2UbaTFkF+FWm3 S5v+zdb1KAzZNNSyzSe/svc5SHsq2+ZYL1Vz5T6IPHtfA19/tG2/lfsmuuy0dTSRZS3LVNln8Npu jNMgb2aybBHbqa/4ypJByh4JYlkk7ZJDkcehkkq36GnLlKHkFn3xLPdaUP3J7VImZVoySyVcr53l GfpfS14VqnmW/BK7LRkk3kEcB4eAv/BcDY+n5Zia10M8KfumLy05KWUh2yHhlvtRrPGTn9sg74M5 kb5k65Zr0ugzDj2RXminWWOnOTa+PXeDviQs++SXqQev7e0adxH1lWujP5DjlVE4zzrIET3fsbfL ekIdWXP7Svq4gOdzuG6dMb1lN+vcnUKnW5D9NJfjn6GXedDvniHvARkn53sWJQ/Z+eTxSRR8elvX 2M8ZyzljDaJB2sP0qPot6EJ9eE2S7O+fTRnfPsqQa0i200/kWmZQhO1EvFFWvyH7kBeBXcBvgL8B ey07VccbvHeIy6VrPLSC1w90bnb9AeX1ErnNMyiqb7H0FbWFLmO7OIP3FTDk3ikHq9GuWI4vYvuN /PU8Dn57LBSUp7IcNTMYraDIBuS4ijyilycNMl7H85ps3moh8m4kynyCKIhuKAyujiBdLuLlg+Y/ aKGg4AgKM4liQPElRKVXEZWhTCrQB1T2Av4Ble8FZA3X73VKCqB39emPJoW89EWfW/cnogEYndSj /E/NJhqM+zXiekPuJhp2qYURP7MwMtfGEhutFkbjHmdWoJsDj4xHuibkc6KH6ByUV3MV0ZTPLUz7 lGj6ZKILVhHNfIhodhvRRauJ5kIDnwf/gneIFqJ+F+URXX4j0bV9iL59DVHLCKLvJLrxb+GJb8YN 4NMbOy3ctKob3fj/GL84Pm7O+9+Ms7vRjW50oxvd6EY3utGNbnSjG93oRje60Y1udKMb3ehGN7rR jW50oxvd6EY3utGNbnSjG93oRje60Y1udKMb3fi/Egp/0Yo+pQb6ERkkKEA1/NZX7amMX5CLxGaa oFatr8iN7XpW7UH7AKH2aKsujG1WK9XCtkGxRLtauj6UVesfcpIax9Vq5DGO4wJgLbAV0Gi6WoTw AI7XAS3AWmArsAvQ5Z4tPhsHFgArgH18Ri1UC9riscCQSjWKtFHk0a/m0EEgCagUw7EGGAtMB+4C VgC6jMchC4DrgK3AJ/JMQs1pu6cv8p7Tdpsk6+fOr5Xe8y3v1GnSu/6cZoueOd6iw063og20op1c ZwX3HmrRyl4WDZXXtjD1+Gq3DclWs/GQ2cj4pTgq4gXyKwrFaKWaRa2AUHU7JKGG1pdV1K7Yqmqk qEJVaCbFkttUpc0XrB3iEUlxkEIUE38TB6wz4sD6zGDtiiGjxZ9oLbAVUMWf8PdH8Ue6TuzjMsex EVgBbAVeAw4CutiHv3fx9454h/zibaoBGoHpwApgK3AQMMTbOAbEH5hb5JHdjYAQf8AxIN7CY72F o1+8Cdeb4k1k7XdtA+prN0tHdY3tiJXbjpx82xHKrm0Xv237ogc4qgI1DY56Ri2hwdRXLWkrPznW rua2NcyJtYv31serYyuH9BG7qRUQyMlu3Hk3xYFxwAzgUkCHay9ce6kFuBtYCbQC4DIcA0Bc7AB+ DeylPkACGAeYYlcbbtMuXmurGBobki1eFS9TDkp8p/iVpL8WL0n6inhR0u2gRaA7xEttRTEakoHz hDQB0ABoDc67xHPry0Kx5JCg2Iqyi+FYAzQCY4HpwF2ALraKkraZsRAu8gztMAkx2+gjSR+jVSYl 5sYSFaeBAeN8qBh4Klw4rIivqBCJivsegJcPFXfeAxcfKm68HS4+VFxzPVx8qJh/BVx8qJg5Fy4+ VEyZDhcfKsZOgAuHdvHwprLK2ICx85T4EL+4EqV0JUrpSpTSlaSJK/mPvtA4bz9s69kTJfZgorpH z1jLFqXlWaXlbKVlldIyS2lZqrRcr7Q0KC3nKS3VSkuB0lKktCSUlmeUU1AULUpiw1He+kSu0rJD afmp0rJIaalQWsqVljKlJa4MSLSL4rbT+0oyXJL1Q7jRgZ46GNLHL4pRosXg+WLIhK04vgYkpS+B SPESK3K0iGnJ+p6Nlr/3wNoFQ0aJ55HweVTD8/QuoKGCngcbPY+LPI8L+HFsBKYD24CDQBLQEbsE Gb9LHv041gCNwHTgOuAgoMvsHAQELbCzuFZmrMbO9Fj2iefxV4K/YlGcKAwUBKoDo9S7ChR/kTK2 KFkkBlB2NhGFgmawXfFt/G/fP/7bR+4hbnGnuIsKURF32/Suti8KY+3K8raKZ2JDspT7qUgD1yn1 VKGUg55Ci6S/HxWYTOuoQKwBrW0rmIRk/raKXrEtSian2hj7omB/7KOCdgHnhwXPxF6Pt2tKW2wP QtZsjO0uuDW2vabdRMizFe0KyJa4jLq54JTYT3fIqNfjxINtsaVMNsa+XTAyNq9AnphlnThvEXwJ f+zsiimxUbjesIILYolFuObGWGPBebEGK1Y/TrMx1gdZqLacPZHZHgXypqVF8oITB7QrFyV6GfcZ k42xRn+j1uhlFBsxo9DINyJmyAyYmabX9JimqZuaKUwyI+3JfYlq/sJjRJcfeuQt3Qpp0h0QfMRB Cj3FFDSaWsPqGDGmaagypnXbhTTmgnjr502l7Ypn/JRWV+lQpTU0hsZMGNp6SvWYdiN5duuA6jGt xrhzJ69TlDubEdoqbmlXaMLkdiXJQTflt4ZOm7yZFCV40x35TKtuuqO5mXKzr2jMbQwNDtaPGHac wwz7mPJB5dyj3IWt941pmty6urC5tZYdycLmMa33NsWnTt6sfKp8MnzYZuXvTJonb1YHK58OP5vD 1cHDmpvHtCuTZDyKK39HPHDM32U8Ex0zx6O4WWTFe9CKV470iFfGBPHcbiqX8crdbhlPUzjeukVl w4etKyuTcXLitEjGWZQTT42zoxxxystlnOwW2iHj7Mhu4Titg2WUggJEKSqQUZQ8KpBRCpQ8GWXS kSg1dpRbu6LcKu+kKkfiFFhxfPucOL59iFP9z/5mDa2uVtYPar5w6vBZpcNnlA6fBcxove2Ki3Jb Wy6Ix9dd2Mwn4q1qxYwLLryI6fmzWptLZw1rvbB0WHzdoKnHOT2VTw8qHbaOpg6fMHnd1MSsYW2D EoOGl54/rHn9yHF1A466161d96obd5yLjeOL1fG9Rg44zukBfHok32sA32sA32tkYqS8F0keHzd5 nUlDm0+batH1IsMDfp2RX9w8NDtw6WDJvIOKc5fmb4G28gRlVDe3ekuHtvoAPnXSkJOG8Cm0KT6V iWC/fSp36aDi/C3KE/apAIKDpUOpevHliy6n3OFzhln/i/BD0OLLucCtY/Wir/vh3PDWxPnDFi0m GtPas2lMa+P4KZPXGQZCZ/AjtQ50wjIyhrcnt1mBvRE4kANVtSsihzVwmNttRzy2/i+3qfzQdYt4 Zr2SKFIW06JmtbVozAQBUTBhCp516pTJW6BLcfewqBkPuEipVhY517CzzR9Etwg/s4PFl9suuywW 29RKiSSLnCLp+nFhVXeV2GJckP4XQWLOOQplbmRzdHJlYW0KZW5kb2JqCjUwCjAKb2JqCjw8Ci9U eXBlCi9Gb250Ci9TdWJ0eXBlCi9DSURGb250VHlwZTIKL0Jhc2VGb250Ci9NVUZVWlkrQXJpYWxN VAovQ0lEU3lzdGVtSW5mbwo8PAovUmVnaXN0cnkKKEFkb2JlKQovT3JkZXJpbmcKKFVDUykKL1N1 cHBsZW1lbnQKMAo+PgovRm9udERlc2NyaXB0b3IKNTIKMApSCi9DSURUb0dJRE1hcAovSWRlbnRp dHkKL0RXCjU1NgovVwpbCjAKWwo3NTAKMAowCjI3NwowCjM1NApdCjYKOQowCjEwClsKMTkwCjMz MwozMzMKMzg5CjAKMjc3CjMzMwoyNzcKMjc3Cl0KMTkKMjgKNTU2CjI5ClsKMjc3CjAKNTgzCjAK MAo1NTYKMTAxNQo2NjYKNjY2CjcyMgo3MjIKNjY2CjYxMAo3NzcKNzIyCjI3NwowCjAKNTU2Cjgz Mwo3MjIKNzc3CjY2Ngo3NzcKNzIyCjY2Ngo2MTAKNzIyCjY2Ngo5NDMKMAo2NjYKMAoyNzcKMAoy NzcKMAo1NTYKMAo1NTYKNTU2CjUwMAo1NTYKNTU2CjI3Nwo1NTYKNTU2CjIyMgowCjUwMAoyMjIK ODMzCl0KODEKODQKNTU2Cjg1ClsKMzMzCjUwMAoyNzcKNTU2CjUwMAo3MjIKXQo5MQo5Mwo1MDAK OTQKMTcwCjAKMTcxClsKMTAwMApdCjE3MgoxNzgKMAoxNzkKMTgwCjMzMwoxODEKWwowCjIyMgpd CjE4MwozNzMKMAozNzQKWwo2MDQKXQozNzUKMzc5CjAKMzgwClsKNjA0Cl0KMzgxCjQwMwowCjQw NApbCjYwNApdCl0KPj4KZW5kb2JqCjUyCjAKb2JqCjw8Ci9UeXBlCi9Gb250RGVzY3JpcHRvcgov Rm9udE5hbWUKL01VRlVaWStBcmlhbE1UCi9GbGFncwo0Ci9Gb250QkJveApbCi02NjQKLTMyNAoy MDAwCjEwMDUKXQovQXNjZW50CjcyOAovRGVzY2VudAotMjEwCi9JdGFsaWNBbmdsZQowCi9DYXBI ZWlnaHQKNzE2Ci9TdGVtVgo4MAovRm9udEZpbGUyCjUzCjAKUgo+PgplbmRvYmoKNTUKMApvYmoK PDwKL0ZpbHRlcgovRmxhdGVEZWNvZGUKL0xlbmd0aAo2MAowClIKPj4Kc3RyZWFtCnicfVLLasMw ELz7K3RMD8GS/KABIwgpBR/6oG4/wJbWqaGWhewc/PeVd5M0SSEGP2Z3dmdXnnhXPpW2m1j87gdd wcTazhoP43DwGlgD+85GQjLT6emI8Kn72kVxKK7mcYK+tO0QFQWLP0JynPzMVlszNPAQxW/egO/s nq2+dlXA1cG5H+jBToxHSjEDbWj0UrvXugcWY9m6NCHfTfM61PwxPmcHTCIWNIweDIyu1uBru4eo 4OFSrHgOl4rAmps8p6qmJRgIp095yujv2mOfJPThXHKFKCMkFRUhS1x3W2gt0oQgtlaXEvmthNgg LclRQqaIUkEoJ5QQ0oQ2iBJOyBCiQTN+f7SENkhIM5Pq7vYJEK1BiZQEM3Mpkf6TSNPTlMsrp0XS hoK0Qf5IQTqn7BjUGGxokWbpIrm4PrzlXy6WOxtFH7wPHkFfojkWW3QWztZ1g1uq8P4FyPvYZQpl bmRzdHJlYW0KZW5kb2JqCjU3CjAKb2JqCjw8Ci9GaWx0ZXIKL0ZsYXRlRGVjb2RlCi9MZW5ndGgK NjEKMApSCj4+CnN0cmVhbQp4nO19eXxURfbvqbpb7317Sbo7W3enkxDSCQESskAkDUkQCDsSEyAS 9k32RRZFwAVkERTFXRABURCahCUgCszoACrKuI0zrjPG3YgL6rik7zt1b3cIcZl57/3eP+9Dwvee qrp1b1WdOnWWqgsAAQA9LAcO5PEL5/uu+CizEEseBBDqJs2ePOOq4zMKMP0L4qXJ1y6e9Nys3S8A GF8EyK6fMnHshLf31w4DKFqOzxRMwQLLlebxmG/EfNqUGfMXTb2jwyLMvw3Q4f1rZ40fS/YnrAOo O4b5phljF802p3EvAazeivV9s+dOnN13uHU25k8AiDuFo+BRsRMS+AxwAygfIz5hNDJV+ZLdi8xS /kX/hU8fjEL7OQbHYR00wE783Q8y4WECLIa1+HsSPoM1sA3uIAdgHiyB7Zh+ijxNZ8NI5IILZsOf oTPhlHOwB24gZhDBDmfgLFTBHcoG4gAjeKAM5sIR7jT3N+VL0ofMBAqJUA7D4BD3JbxJeHqF4Bbm KTkgIGf/AmfpAOy3DeKgEPrBIBiNfXoM+/ocvEUyhTLlPfBDCIZjy4vhdngUnicb6ES6gG7nTgsj lPsVbAXfpIMM6ANTsdY8uA7ux3GcJwbiICfJh5ybfzDyTeRHZTuOvAPkQy+ogAU4mmfhBfg7fAj/ JiPIJBqkV3GzeYGfrMQrB7DPydAV+uPvQBgBdXA93Igcewj200e5dZFnIz8AQZngIAd7XQjdcfwj kVdn4R/ERjwknXQgfclwMpVsJT9TiRbTFXQ7/YETuEz8LeAe5Q5y73DvcV/zfflF/EeiUclUKpUp yiJli3Jc+Sfy1AuZMADfORqugbE4qutgBdwEq3G2HsTfh2AL7IBD0AhH4Ci8Cu/BP+Eb+IFYSFfS g5SQSeRasojsJQfJYfIyeYXW0rF0Gz3LBbiR2PZ2Hvhyfgg/j38lApGiyLrI/shLikWpV04pXygt yE0v8jwdOZoD1TARW74F7oD7sMXdsA/C+HsU3oK34VPknB5/ZeIkLpJGOpIckksKyBAylIwkk8l8 spisJLeTjeQ+8iAJkwbszTPkOfIP8gn5inyDnEE2UyO1Ui9Npdk0h3aig+hkuopupHvoQXoMf8/R 1+ib9C36If2a/sjZOCf+pnIZXF+uPzeam8Ut4hZzy7jdyM8XuPd5HufPymfy2fzN/A5+H/8y/zn/ o2AUbhc2CfcKHwofiiDK4hXiEHGKeLfYKP5d4qSh0iRpmXSjtFI6pANdQLcH6nF17MeRtvmho+ER eJU8A++SnZyT7iZD6GNkM7FwbpjOPUD+KlTCbbSEhslAGs99SxaShRDHPU4uwAU4RHn6Jgnyj5Gt cAxX0jo6nS7ireRq/nG+hcznX+E52gQ76ZesHdHJP4atLQQgM0hPTE2GGfAwdcILdDvOwhz4Ezws 6ulGnPcNkEH7QjfSj80NPQ+f4+qwkVKYhuukhTwqzKePkCXcJ9QEVaSFvkd6CPNhkijDCtJAB3Ev kCZcecdQXirJFFpMxkELfES2kY/oCBhIb4JH+cnCa+QdEiSDhCkof8C/z/XjJlEHfQra/+yDA7gS zsIA7jSMJnfi6j9Lg9CPzoKHuKfJp3CAXM9P5qZgLxdRntyEa2EPNHB9eSP0hgPcAXiG7OLeIEHY xy8iM8kmpaKlFr4Td/J7uf1CAZ+kPB95m+wg55Sj9GsoVJ7nRkQmkwd5D67L63H1zkUOGWE3Pv8g aoydoMNUOq7H21Fe41C36XGV90HNNQCuId/girkJuVRAMmEQTYXptJfkE50AUgd4QmEreSZ0JP/g d6F+OBrqdVWotOcVJT26FxcVdsvP69qlc26nnOxgVsfMDhnpaYFUv8+bkpyUmOBxu+LjnA67TbZa zCajQa+TRAFnlUB2RaBPnS+cURfmMwJ9++awfGAsFoxtU1AX9mFRn0vrhH11ajXfpTVDWHNSu5oh rWaotSaRfSVQkpPtqwj4wmfLA75GMnJoNabXlwdqfOFmNT1QTfMZasaMGb8fn/BVuKeU+8KkzlcR 7rNwypqKunJ8336joSxQNtGQkw37DUZMGjEVdgVm7yeunkRNUFdF9/0UdGbsVTghUF4R9gTKWRfC XHrF2AnhIUOrK8oT/f6anOwwKRsfGBeGQO+wNahWgTK1mbBYFpbUZnxT2XBgrW9/9ok16xplGFcX NE0ITBg7ujrMja1hbdiC2G552LWkyX0xiy+3l1Wvans3kVtT4Z7qY9k1a1b5wluHVre962fXmhp8 Bz5L0/vUremDTa9jXHTnYkdY99lQtEFNDFSwkrppvrA+0DswZc20OpyQhDVhGLbYX5+QEDqivA8J Fb41V1UH/OHSxEDN2PKk/U5YM2xxgyfk81x6Jyd7v2zTuLnfYo0mTOa2iYmt99SUWp2lKoe1spOw HgX6oRiEfeN92JPqAA6kiF0mFsGa8UVYDX9qCD4VnoDTMDWsL6tbI3dn5ez5sJAuB3xrvgOc9kDz F5eWjI2WiOnyd8CSTDhaBQzvx9LhYDCclcXkQirDicQ+9lTz3XKyFzbSgsBs2YcE2QdDqvGxmu65 yHO/n83q2sYQjMNMePnQai3vg3GJ9RDKDdaEaR27cyJ2J24Eu7M8dqf18boAiu8BYO5aXFiX0frH Ksc7KqZ0D5P4P7g9UbtfOTxQOXRkta9iTV2Ut5VXXZLT7he13oumwo6yai6RRlM0kVPvoiSObq3M MtWmMJ+Of0RVkic0SjoURbWE+PqE5bq+2rXG4Pf/lw81Kl+xp1Ry8bFoN8Pdg5fme1ySv6R7pjUc dpjPoJVXjVyzxnDJvT6od9as6RPw9VlTt2Zso7J8XMAnB9YcoTvojjWzK+piM9qoHF2bGO6zrgYH MYV0R2ml0Ht/gKweuj9EVg8fWX1ERid29VXV9ZTQsrreNfvT8F71ER9ASC2lraUs52M5qCQo6fVU p95KPBICWK7e5dUCNT++kYBapouVERjfSLUyWS3DnxxmxNn0C/iL1kqC/vspeYp0Qg9WooX1IPCN pNMBDgwSSxwk4NGJArtPgSNlDfpRz7iD8vclLSWD5AslA1tKoBTT8i946dLZb/Pb0vFCgIdffNyJ X0IC/Aw+/gQoConjGriZ6ItngMEGRAIDGc2ksIEQERpJ5eG+HYBQCh0hiIYLCOG5BmrH+gLMCZWE YLtAZwtE4AlPhExKSDnPOXmeEwjFK/BEovwdHNlIM0F4jeMysbeHJPCIo252BwfJTQPlJigNloDc UhKUm+RmsNmLi4nN7ipeZekUFG6Qnw3a1ILiLp1J7RziKMyTOMKb8l/qNpVrIPbvvot8ifzsEnmT TEELr4dBIVua1E2ikqjndLzAgThNaqQr6/XANdL7Q3ZKSQUYuH20guyDgYYZHzGuXWjBXiC3muWS 75ttrmJiLwb5DGsxD9sTRamwoHBW8KX01A1jbddlnG14ZLNxsL8R2x1DGumTdAbOly8kk6VA93H3 C/hiD7+wNxvfhYFN8vdNkNvcpbOj0C+NyaCZ6aTxIAY6BJgPNRP7zIHnEOsT9qiRXGjgu7MuXWiG UnyINb8weDb77FmUDtitfMyvFU6g558Fd4fiuif1T6Jun9WW72GXDllmW76vUXk/5DPZ8uWkpbbF geuyVmUJfl235D4wGRbLt7luC0iueMAFGUo32vIhPQUyfdz3rv7xf03wOQS/z2B2PZReKj4Un5Cd Umr2BBvprftHaCNpHiR/P1DlVHNpc8uF75vVaQlqfKoN4g/UkoKCvK7oa0hiIJV2yy/sSTHrkjIy AqmiyDnj87oWFHTLZzny4IB7+j/2j23rTh/6dlDJ/lM3bH7GvMsyfeDQ7QtH3D+2/N5pm6Yseokb VlradPLH+vuI8Yd3vjj4+cyn9srXTVv2Q8un1z8++ZUptz7yOVDlb+j7nUd5lMACW0N9dKJIRZ1O EvQGEy/qLCaTJOqsgl423WMi1IdLLEUyOSXJRE08n8JRJ4eOkGRFd4iTTT/j0tfr/ILYSJ4KWSQJ RZgDnelx600r3UGPfAHcpSUy+72A66q0pJmgsKB8ruoUXHXDs6s6uYOqwKII459VsuVZ4dlnV6lX SS5ZJT/bpXOA5DkCnJ8jfi6jgyh15Eo//uaZK1v2fU5KyYfFfl3XOuHoT33IzshIegWZ/dady55E STmqfCy8KbyKUeqWhs064sA5bsAJd7K5tlhwrn2yLd/mw+l3s6IuOLO82+mmGc5SuQ+3SOZlizM+ ziPbrcWWO42keCOzM7w9x8h5cng9LEUhHhtyWpda4rM6SyRXIlJ+kqUsOb+MTfxH8oXaOQOb5WZV JEub7cW5tU1yywUbjhHXibYw1eln8+8SIeADm+wo8Hfl1Yn3SaJNnXj+1T+Njmx9K/Jd5NSXr5Ee nxK/63DywQ2Rb3dufLf+3u8pnxiJ/ILxeGeyjnAf//SqbctD51+KfPivL//CVssCXADTcZY5uCuk lwWM6koFKjQqJxoysvJV6g6oNNTBGZdPOS4FCPrNhGYSymWCjlI9x20FPUF/O2QPlAKwuraE1HwZ 3/4wj1EiuB6+x43DKCHBJYPkr2qD6GGxXG5wyUD5a5bBtKqtEKuETmyyu3TGB3D8eSSPLCB5f468 xOYP3zgSY6WfsL9uOjBUuiWBFHCFUqG+QL5SulLfR+5nr+FG2a/lZvBTddP1U01TzbPsUx2zEhbb b0y4jbvFtsb+uP1N+3sJiVsS3kug+0VadlX1AQMkeHCEnzSYzGyk50IJOPcW2ZiUHxfCixBn4YAY 7aDTEYrav7SkhOlRNjFsoRYnHgGr8n69xSceU06AgOCRAwGOFwQqSjqdYDJbLEarbLNZHM64OHu8 y+2OW23R6VGnTGwQ7DZ00zNDw+JwEVFBSLHHOe2Czh6nw7TN4rQJ1GbRGwwpRovTaLSwZeaOc+Ib BOKOG0n1lqW6TJwEQt32TLvNZjQaDDgrej0GI41kwUGBENDTRtIjJKP5W+rWx8Xp3e5Ngt5iYXPb MZiv0rh0lYZKLHK+Jde4xbjPyM0y3mh8z8gZcxNKE2jC8wbsxFK90bhJ7xM2CrQObZPgSbAY49yy 0eV29dnDpjjIFjHx2Jgwzwku+YpN7pJ/sqv8zZwlcu2ck4xrHiyUtXsntAyr4pGb8PG2CSYPMtow vGABlKq0uUSzZlFBiSqHVTqkQtsENsQ0xbO/e4GioiJSVFSD62xO7VwUNEe8q6AQ5S3gKHCIEgmo moQbSbp+fVey/ooNlH4Xeenkfd3Gl9a2vPv0Jqfe4/6zcPSX/k/tuauFW/dTH3rmB5K3Yccvvbg9 K/acnPNLDVqWavQ77kZptUICPBAq2sU/5qDZju6ORY7b7LxFTrA6ZIscl+igtgSrNbqybLIfBQY8 CX40+9SKs5nQSI6HUuOycsVScYhYJ84Wl4uiODXJS+YTSmQr5GJTfaa6g7m1wZJagvakdmDLR9qK Kgm2QAlOB+pVYZXKMcY8VXBtxVJJCdMygMvM3zUe7YsF7XvAzzn8mj3JCPirSR6dsGXLlP5z5vde vzFyx/VbSNmx8LSiSXdEVgtH++2fOerYkp5Wf8uT9MehO2v7jgpiV+pw1H/DUbsgDc6HVviZGk1m xvNqI2FrQbbbrfHuNFeiO96hF7zpjvg0lys6ejvywWJ0Yi271cilWzK8RrtLf2t8Yp3bjz2Mg0Ca yheXNdOKXNKlpeldrqWq/rEy9XswXe/N8omd0ViVZTDds6FM0z3IFVS3KGvfoGTVauqnjfZplbEY v+SWJvlDzWkqZm5Tp6CFiZegyRvYNW8KOciEiYFxMhiMcVIU4l3xLgcTImRjgLEUrbbG0zrk6eRD x6Z/Fvl5SMfRRbPfmlrcr+uUBU2rHyfWY8Wzbh/U/Zo5kVTh6BW7ljd8EehRvGJN5Atiu+vaytyW BVyWYBx084DQmFSmvTeiBRuDFqwQ/n4EstF8oa3KYrbKjQkTY/n8Tis70gK+QFfk5/QFhGc38/Gm n5k1iV3Scwty7jJyVrMxK7uTGN8tuTgJiklycjwh3QI58ZyY002PLhjTIeYOWT57Zzu12mfbqb2R 5jUU6bO6MMVhwKa6nErOSqhLYlk5NTPfl9Q5ieYmnUt6P4lLaqRrG4pP41TI36FiuNByIdiMUjqn jfGzFeeio9rEmKpxMohyyYijUHLGM0PXLb9DBvvN6JavukPMH5LyO3SigVRJjHMyfuMv4z0fSE3b eIIOOnB9+EiXru89WTr+muvPb274fhZ52ui8atOorTXlRf3y//xwyZCqOxTY8WPkOfIPe96I9QPv H19RXFRXmdnrvnFzDtUtOj1KH2ftGbjiqry+haMKRnRMruqT2e2euuvOzPw7476Ccr5d9ZC2hAoS KfGBTypAt4fT64jI0UxRkqJSLVA/OkISrmVR1EsSk1cvYSaTKV9/ar5qNE1JKfm50BnCaIyR3c8d 0qnGc8MRNDsx+xmV3iBb55cKcFCLTKJqMRj194s1N8JP/Ogm+wn5K7FGvAF+ZSASiHwtOB577Kdm NpK/KB+JemZVYXOoq17Wo9cr+xJGxU2Nu44sihNx0aYYTWh/TAR9u3jA+QCziQDNlHLs+kwzysZB S9atJmJiUqIPGYcYKRiJsZFODlkSyDY+61Ygs7GdbfGN5KcGT/5KFh001c7BNYZeUBPSYCk0B9G0 lsTiE6SaIlelgeRxbIqZn1vowDTFKWaCUEg2P3vMdXT97JOzcx5/tqHT5sj34Z3fLu6Iinnp7IKF Gyeffovr8Mv2tyPKAzP/tHTgMexDBD0IC47VAA+GHOWknF5FrqL8RXPdqMwKBQUw+NDg+QWdUxB0 GJ2lUMFJ0T6jXVXNrQGN7FJdyPBn3VHiQhb+O2QSfGRpiG4TnjL6onPmSZBb3BcSmpE2u5s8zW6k qgfBTFp7E9bGXLEh+y8aJOqOfPT0E7mW0T2o8flf3saxbf7yzmMzuROqR2SOzOL8qhRWh9w4iqjI cbyfyKLgl8CO0dNRImDM+F6DIO1DH1yoFzAoorYGDHYnH8F4NBpTtVzA+bjQpApSactFX8xB/BJ6 2JKZrCCbkt+KHHgnOTJLqlz74wtrsSVldWQWDpv1YHQouS/0Q0lHN4XjMQRAqfcTu8D7RUkW9wnY dANP9qFDIhzipAoejmDQ/d5BbqDu0zWqSKA/LLNO/LoPpBZlGI1zoZ+4I7OT3yED3k4mmyKz1ord 1qLNGal8whfwPaEDdIOToaGjcki6Id0YMKVndyf9iZirK9Zd7Z/s5/Ozs4x8bmaGmbNilBbIDHIO s6FrQmYwmG0wOw0Gc3ya10VcwxzeBCnD0NXLGV3V1niCcvvnUEquT8wosPpSoFoOzA7QgJISstnz IUVOmZXCpRyji1ARZ+BV9e9rgwO/r8XxMM62YIopOgzwapuYhFuihrg4tk6Z3ouqPlR76SIGeqqe KyxIK1Q1H8Z2Ugem99ies8RWgyuQ4cAY2kKjC4OTr9k7ftOBobeOvYKM6B/XqXTx3Dv8h4u+PfLc vGpPj6T4w9YrMq6e9PDK3lPHjtxZd/PQyidX1dw23G6yJPfvUprWdWKt/PCua/rMHjE78u9lg7te k08+ssp6S/Ca4gHjxjzB4uRy5HFfnGcHBOCX0KQEH/rJKezC+wenL4hbY3vcdsQmdrTlppemXxlX FTcpTlziJ5zdGZfqwE7auaQ0TvQ6KA0QcBKmPghwaV6vKDkyweD2Wo16n700iUBSblJp0uCk80lC UhLzfUzow1KHnvmyDkcjKQh59J2BKT0YDGOAB6hKU1Vl1cQ2cQZTlHMxxNDcT83en1CdTu3enLLR 1Q2zk0hhsLaGqLPDVGhL08UgJOopsT2TZ9lPl84YidWqRj6Pi0bkFg4nqoPkkNQ5sGtBuCSWk64H Z1StG3D3qSELl918xdStOVkzyMqxY7ZMWjFm3PZC1E8tFwb3eve19Z9tGZM7a+4ZciB19e23kITr br3rnocW4Kqeh7yOR3lOhHUhQzE31Tk58R6RV+PQEehOFRvW2ujoxKny9frF8n06QXTGOzvqy0g1 rdaJ1jTLcCNJ64yO2EZmS3i71yh5vLwRqn0YBlLylSXeJ2UkWavBIluopTK5qJKJLLqNqrTiEqy9 JChtUo1IrRaIapJpT2PD13YgogLI+Q+W/7z1yb+tIWTH7tP1ZN41M7aOWlRd/Qi5yXHq5Ptn9pIh +05uMU2cuyby8crVq29FiboWR3lG9Y+9sOsIJKMHg4Ozs1GOQbnSc6KFT/ZwU02N5kMWKd7iTO4o BeKutFxtEZ0ukkv8huy4KsMkg9CddDWUxFWS3ob+caLbajUZjU69CRK9eslqMTi91Gh+0VJtelG2 jrHOsm618tZGknbIL/uEDF/GEZIOF/dialEPqpsxJQgWyaBKvkGd+1oMFHD206McYGvRgRqJqO5J obYBY6Gc/MDj95zZcn7RXyYuOhB56bFI5+xp/ZdOuPXmCb2mT+17f/17r/2J9Np6nPb4qQ95etby Ecuf+GnZ7d3XvsFW2DTkRy+cdQ+kwokj4Ec+6JEhXuZBxzOuVDOuiJmpa91rPbzbc2UCqtqDnuc8 XAaXbbwuYVUCD6wuJCYAZyc2azKkyaQOjRGRyRBM8GQ4n5iQbdto34oenJ33eU2SCyUDnbk7Q4lO ny4jkOyzhly+fLDK1tnW95BTPdMyemriEdTkI7pXxYSD7YW2oAVXXQ1cKWeCTFTmzmEuCspK1Epr wuKU/FEbTvzR3SpuSDgjcv7phc9NfoTA3c98YPnlG/628bUHImlolVdPn3+cTLXf9MWMc7fsJVdu +eLFQcO8nrsfWkKWJJlW37EVV0ktAFeG/m88/CU0LSCRTNLRWCy953jPKbhJhr3AzvGoYvg4zh4X H2/DNAgmo4kz6i22+PgACGgohcEWYvHpiZNmcw7kCM+J8aiNHPOd3HwZDb19PobM8fHVoOfno8eW y4KMRuo84NK/sA61TZt4oqmNP9aE6ya3KeqVqTtbaM2a5zDFElP99mL5jCTIJSWSrIVhc1gg5ggU 5qnbey5J1SRSnhTgak9uS97mdefNG19xk390z26FTvfzyc+f5O5fd8+cCb2SH3Z3Gz933S+TmCdX jsu9B/PkiDN03ZU8yZCI1+Q1Uz1J1/UjfXRXc6t0L9mkydIS3RLU10/pnrKJvJG3UCcGXZRzuSl1 uwOaC6E3mQJm2Wk2yw7U0Uxbm5Ezej2WV5v1G2Qiy/pcc6n5RvPLZl42DzaPMc8y82ZzI70hlJOA KlvvdiPf7IS5uu0UtkdPQDajzja7qnpe3Dpoo7mRi7Vtd4ha9Xb0jnZjyYnoRoGG5hiHY4GaZNGY iz9zoXZOG80tcRjoa2KIYT5T2Asm7h19852+mw6uSu5bPq5+YtYYVNNnx41YO7doc8t6etO6tPze kxtORYpwpV6ByzVN3TeTSG7I8Bj3F+5j7juO1zNPfkBuUf5g/XL9OT3n1efqt+j36Y/rFb0IAs8T DlmJ7lkmlaQAT5ysZDzjrSiIUiZvQK5J0kxeL6tcQ3lkL3TjC5fz53jKh4zWfH4Biwz4KOOiTAvO YftqaNMO8qGBnUrVx/SlGaV8qGe6mmuozNBKLb38WOrMxIs9oN1K7qzRpFyNuqJV9U5WNbmDmqv3 +EuDbX9qfjVHUYFn1+Y2kYgktJHy4BxSmCcR9OJJRfBAMFL+7sF3+eazZ3928Bk//4PJcAHyNlnl bSQ0ok4gg4XlwjmB0xGvkCtsEfYJxwVFkCjHBVr3IoFDyVT3ImfGBM4Ox+FloMvhHE5XyIh+2hRt N7JqTGs0hVybqzENQm57KcSYBoxpas6SVIg5ZJa2u6nGa4UaRSZBjEnAmKSWIpMgym1GD/diNwP2 SznXyrrf3/9ETrFNKVKAgtm6+1mGsctytA9ZpF/oij42kh3SG/K3ZD8VOJ79sutM4GMq3ue6L7A3 fm/qvuynXGKFpUo3wnK1fZLlxmxRT1J1qZZuujxLH52YzTo+2Czncx2zKM3KYpwkPrkYVRwyNDkl JeD1OX2swEe8Xp/Vbg84nE4nK3ASh8OZ7hU9XpNJ1QpiljeFOXDZjeSVkNlp1durnTI4ZAdFX216 yOxNllOqfTJ4ZS/1shIvUDmrmsgX9UFVECfGJ3udsoMJtbbeNaDBYdp1YAtetGTb1LNEO+jCn5iy RZdbWNUJDRBTA5hyX5q8qBOCTCkEUeXmSapKcP2mYmibLnv3YPrELbXjb4kb2jD+lltcGw7e6ehd MnRXbeDag5vlXvkDH5+WOpXP2Denauo1E8Yvm9tlTstV9Jmq9PyScVt2tLTQs/28+aFx+7ZFDFFN XYxz6YLzoSHq2VqApukKaB9dFb3aNIku1i2yPWE7jgr6Rd0Zm4WLd1Fe5KjLpc5VSC6erc5VVEnL WDBXJlFdzTWSSMiGcaqYaXKZzWBQla2+kRyuN1XLSEKotslFlf0UvQF9DkqO1ruqSSM5GnK0mRv3 RSXNJoO5R2rU3tKk6mzVwJVg7A4eucmtauAox5kO1jiubthGA1u4yPFLeI06+N3tHaYfHbtiU8Kq g+vj+lWs/XveZD7jyIwJ6xb0uLHlBvrIuNxuvU9/G7Hjgp6AntIw5J4FfLDoCNjQNxqOvlEiC0c6 6Eld6uxUKgqJcc4UrsY5Mq4qpco7K67OK5YJZL680Lk0YUnKAU5I8vISOsdGqw9CObn5kOH3+ECS pdkSJ81LzZjYxitG30f1epgjOAftCXNxHHKhNgxtO6KQOTc9aasnOOHwPd+d+PyuyPl7rn9h+sGN s7rPHVcR571j5oh1c7qRTaTwxV1fvXg48tyuaX+6Y/MDuXVLrxw/auOWoQ++jOpP+Twyle+L47OB H34KpVZ4q/hrrCPjpluF7nHdvBX8QGu/OCGd72QNxhXyJVZBZmePQ3HwSYwDNe5FZLH7NnIP/Nsv etwZpiLSl0yWp7hFHYbjNsolu6jNFlWfsmxJ1uy76PJajLZMsOh9CZAwJoEmNFJ/KI1FX3qbDU35 alWzspMdGKCH1EymTiHV8AITDrkElWoQQ6zgkq9jLtGlZpop3FqkzVFbrQVcNvSwL8Zbq9SNVNXP Roe7liOtokJZ5NGBczhdzN22R3kcR/Ie89ZuGnbv6Zlbt1cdn7pov80zt/LBEyvqKhZO7B2ZKjx9 19jKd17aGTm/c9CfWo5z/a7r1GsIGXN41aZ+d7yCcjQV+Twd+YzqB74MGY+ayFLPbQm3JnMp7DQQ WclOBUM2TCTE94Biy2AYBdNATGUqPicvn9FQP1dSvpgSn3K1Bf0nWTaD05RILVZrQDY7McuCEEum WWRRiMx2rS16q7Va1s8243JFZsqyXCoPlsfIOIlkfEjW2zAqkf2ZZll2yX4DhicZ0Ja/g9ADDy75 praVr7+2I80XnaFWb3OVRX42ukk9R91cbRPHxLsKtUCmNYaVMIil3zxw+10vPvD18rFbunR8MPLS wci9K8cOe2z6rWPHXFnbLXPRxn++/BcS2jpj5p9/KuOufOie1US+ceVdPYfcMz/qiXKjkLNWuBBa qudu1W/S3aHnRXO8eafuFP8p/xMnZtBMvogU0L5kMbmNSBYr5YwU+RZ1PzGUNUYF06qZd+QbhCxy vrrfb2dz1pkFuDLQOpiNhv4r1Fea5uKgSlat/QtHSEmb7dNa1YWciyb/CADOodMfNeIWF9ppc7xm vHNcKq1PidrtmqgDGvxNn/Mio2Pyi+ohpuQ0P55D5bY1Z9hDwwoG988tGnO6eCSf8felCzvsSn0t 0hypYvwahBqNQ35lwzcHjVlWjPoalTfYeTTHJNCDibvND/ofTOUWcks8m413m3gjW+q+qJz6Wa1y TNzCrXVvN+408324xcbVRi7LlOZPDRSZeJ/JyCWjD4CUJ660+GEOSCOkY4LXIQnejsZk9qmFPJ9k s1BQT6p9zGEnLNYJyTlsT+wrnQ/S5XSa/lW8esab1jEf4uV4+n48iT/ZqeqkpiznBAdeqG1pqsXk 3GY0FHNadxLYRgL7CMSmbXSBusiDJLrJf3GPP03b4r/4hUOcU9vaj3OqKiBjxMHOK6oWLUpLj/wz s6z89IHTf+X388sXXDMlJ+WGcwVVY0+talyxgkw3DprZp65XblbWUk/HWX2XHThyj6ludlXXrhkJ BSPzh183+N5Ro0apOy1f0juFXZAAq0NZ/a2TrAutq6z3Wu5zPKYPJ51I+sSBxppw4LGC3ZhtM6Hf wxmtX9nQwtbL8+1HSQQcNLHBWa03NdLEevN84zGaiMKaCHpkkjEtG4VV1m/Qc/pGuqEhsaiB7XPW Bi80XWCn/XjV9howPLSpISGTnnRJHWe3/EIWDjoKORYEarEz+Tyl1xXXhjonrNiQvKHw5aH1KfuX utKzSjbdZeuWWRFYRqeuI8INkWXrWg7Ojvel4viWo1wt5DPQvkdCCzw6j/5u4yHpkOHjuA/dkl6n 199sutV9t3S3YTf3uKjrYCh0L5QWGuabFrjFbJIrF9v62fg4jxvdjniPMx69jBtxuuM9zO0QdE5d Z3Q7dITtkes88XqdS8y0oprzuA1CQma8RyfIrup45lBY3dWlHiJ7BnvGeGZ5eA/GiA2JuMKZL5Jk 8nUWyDnhfeErgcsV2AcIHpfgEhIMRSejim8QW7QDmy+wrSl2ahTUDoVPsGBDOzfQjAdzPdTTA0yo 8Z9Fjm3bxfSden4QO0tQTxMCnOf46aX3pC4/eLu935UD7pjqj0+uO/juYyfeXD+p7FE6saVmRG5J Wf9lVYVryAsYohDYhr7bYuSpAR4KVdo7cD5TH0PINMR0m7Rav9y0g+w0HCZGURAM8XwHQxEIGDTn 6QSnTifg2HQ0T9v/1I4SRAPG1NWgk3UUuRGHbpu6S/cV4WaRDYQSxXiUDFQ3ldmSavmu9uIRAlM7 ujbBrmo5UbUd0BnsrnwSrPFzrYcIZMje8ChrfP5QMv54y1Y+o+Vw3d/n3ElvVMezBeOKQhxPAraf 8aGHWJPeS6IdPVd6rnPcyi033mpa6bjFvTzhHv3rzo/1nxg+cViS1LDRn68e95UZ5XwZDZvNbDIa LXHxLpfT7UlIcLEPokUD+yQajXcCWBwup/qNgmu8wcBG7rCMdzoTxPEJYHAcpRPASSceTkhyuRLs 1baj5AgY6YSGEwZiaCRHGmg1QW9kQgM75W0kJ0N6K7oinsT169Tv3eYM/H7OR3LL97URz/fuFs+g ionlH7kHyt9/ibxqRlY1axxrVtlG7MU2tvGubuxFj1x+8xMBFiQEa+dALeMjYyQTF5WhbN9P/T6A EMusvZ0dlE/J6tTyXEBHu85pOtjy47FMnnYsinzMZ0QCkQspoybNmEizWpoXP3/rl+RfP/+Dzuq+ a/r1LZvZ6UkLytJA5L2VWEJOu2zz2WgHa8g2xDbJulh63ybaVBcjp0e+qI/XI9NEVEdUlCTgBYxJ 9HqdwcChMJksFqvRSPV6A3oeOoteJLxVJ0kcR0UDOrhWFLIBomG8kUUGessAYh0PuvHSUZoKIjU2 sD0IpsoIcR6UYRY6RkfJyyATbn+DembbhCuv5QI7nVGv0U2t6EGWS+OkDpmme9ZSolFMaVzUsY+0 VL9D3XI/Ajrl+/q0btZG5Xuc7Hydwa2mQ/o4V77E5LYwGiIHCMlDtc9kN9AhowPhyEuRH06P7JpJ ur4T6U1Mp6elBiPP0kRqfHraWLK65eOWb9+smBS5gXmnkaH8DchTJ9wbGu6L72wMmULxqwyC3mQ0 x+tdhixjkVnU6fRmi0UCEgcOouOsspwnWZySZDFbDJLMmXUo0QaDXtQZOJ+DeWwWgn8shmo9OUrv hDhkDgqf3JTbnIumTj3eiR7sRT+tjB1lav6XWiLzz+pK1GVqK1Q3jQsL1SWKg2S2zVjUrTA1O7/7 /vohbht56+mWUePuHV8amfSE7PGPmsJ3bPl4yxbu6p8Hhuey3eI3uXe4QcKroAcHrGd8/aQBPVF7 o/JJKBsTWWJHebO4Wdosb7btFHdKO+WdNoMk2mQ9UIfBRIwVYDV4DdTQSFeGvDbJNk2WRQIVHKng 9tGBRkOF2Vhh3mfyOGcviR4QMgFQD+mYAKhbv2i4tOMr9mWnZr1wzRApUIiLBZ3IQGuKk4MvZfg3 jJUXdHy5NcU/cfYA++rTdzRGcVxvcM9wVwsH1HEdCXVIF9PlQrFA5lnfHWaDngO71cLJBh1qFhHk aVab10ZtT9GVqI/N9P6QbHIYKlATUXGaVfJKVGK30Bul9x+ieqigBLQvv+pFOU7Oy0sM2eIO4Tgr jPsMA6NfsDaSsgZ12OpHrIgLTTXal7/suwWmUVrT7ICI4VdsaP3E9eLHrsQZ/dp1YYd/RHmwMJP/ GMd+t2mw/0iMAqhfrAvOpd/1SuHGWEu+03l06l+5eXTun44z+sKQHod/fqdlsuE96WfkmB7rE7UC XqWekUFQZnji53d+GmZgf4tOavuXdvT/FqNVaXEr5tG/kTh+HoxBTJWS4ZRQBY+QVYSnT8CT9All E5cMX/B70Bkshi5YNgbpQlqs3Iv17+DnkVykixCzEbWI2xG7Ef9G3IdYg/UXsGfZO1oxj/A6L8wS qpS/YXs1wik4ihiF6dH8B1ArFmM/TkEVe5YHKMfyUfiuYeITMBLLJ+D9p7CsGunTmK/D9EZ8TsH0 XzAdkdYTwHcfx/R5LO+K7zEj9mK/V3Mnse48ZRl9gmThO0ciyrGNeUivRUzDemwc3Vg5OQVXkFOK Du/3wXQBtl+m1p8HE/AdnzOeIU/Y84MYLzG/HNPbsB9beFBaMM22vDPpHphOnXCM7lGuwvFv18aN YOPGMbeOCfsf7dOvofVxWltgmze0xcW+/QrL2+Eol0dsSO9HhBA96VmYwQ/A+fsA+gsfwnAGHRA3 8mkkjrGZnwDX60B5Evu5F1fo/SzfinlQyT8IJu4CFOG9JeJm+BrLgXZBfA+P0S9gg5gOT6F8XY3v vw+xB9+5UJWFCXAVPt9Jfc+HkIDpRxCs7YwYnxhvcBVsl9bDCuT7L2xF4PNvIt4gp4gOAfj8cmx/ EeM5m3dS1fIJvmco1hmL8GP5LBXz0LkohiM4r1+jfL+J71odlcPRFymMjsptK1gfYlDlLAqV90/A WcQJxBnEW8iz2xF9MT0QEUaEMK/Dtt0oRxmqvKLMMNlU5QNlg8k/mytVZrUxVKsypq4ZIuDzLnzP vYjHxT2wFLEb8TjW+YStFyazrJ+xdzPZYjITo6p8T4eD+J4CNk4mU62UrT2A2a1rEGUrRtm6Y7LP KA1BEaNcHhQwmWXyFqOML2r/cT2yNdFKL45Vwf4lqvR1mBGV9eUxGuNFK90IV6v8rocDmJ7Ez4Vx 3M1Qwb8KE2gEwkIRzuV0ZRkbG/0crtOdAKYpB2P+vnb0XgbpdTJNOAFfqvx8HR5COod/nabyr2MM s1v5VAByRthNl6npX9H2ICe0e4wytL33v1v+fwL6hrAbJmH6M+F1RcHx3MnWhPQ56YzwxSiW1yOW I7J0QXKvbjpplEaALAJcENlaCEF3IQSFPEZTfBzqAYB0LB8hvAsLuPXQg/8cJpLlaAteJ3FSHNqA zeBhbdE34CYG9n6ks9vI0SUy116WYjQmr+0p0/lRmVIpk2emg39Nlbdx/W5mtoHpZ9U+oI5Wocqr MrNVPs/AOKT9YvJ5qZwqp9rI5xf4fnd7uWxPVduC+j22TtnaiI2f6Uem45iOZHqOFpPMWP329OLz JA/XyX2qHj4LI6Nr+y7EJsR4vJeB/Xwf1+1SpsuwrdfEwTBefA6mcEkwThyJ7X0BdWIeJOK4v2y1 qdcoX0TtadeYLWV8wvtfxOyo0Bl0qj57Ea5W9c2LkKPaUewbs5/iDmgR40GKPnuerUN1Dc6BCjYP /CTYzN+pfIrjeJg7iPzGcv5qWKneAyjhvlLO8uOUT5hN5DapOmgCf7fSxDWh7LFnr1FmCK/Ag2IP mND6PlYHKStj/RefgY95HKPwuGrzN8b0MZt73SrlM+ltHP9J+JA/jHWS4WPheTYW5EE3dUw16rPb lBvZu6Qq5TD/KYwXjmAZQn3meuXzKD+q2vJClWHGC3ynOFq12ceFv+K98fCWVAtXS+Ow3TnwseTC MtbWepz/TkjnK8+r9no52rccmMB9g7J1rSqL04QVynNcI3hjdpg7hevuJuVN4XqkkxFs7CpFvY/r R/U32N8R34f+GfMnNqGNT4N7xO2wWHwZFvP/hsXCB1i/G5Ry53Ed8Zjuo3wS1dsV6COXcj/AWCbf mi+j+TNSX+VNcYvaXoXaB+anzIMbuK/ganoYSlGXDNU9gbIyGvbgrVIAZRNimwb296yUb6No0UBO IL0FaSe8P5yT4WtM96d5gO439zze+zPO2Qx+BSTzVcpHXBeUCxva+b9CFfkRBnNWaOCfR13dCGsx f4x3wONcGCTuAITV8pchQH5U/k1fUb7i70U7VqK8yq+GB/kxkMfth33ca8q3KDMce064Hf2vNOWf yPfBiGMM5AOUzyp4WLwVBuP7H2D1ELPx/S4Gvq/yT/W5NlD7GkO7PtNKyOH6QzHrL6YHXdJf7Gtr P1ejn8T6+Bv9Y+NW34vPsTr8A1CIfHobka7RyNA2NP6/wNttqI9RnNPtzC6Iy1DnvYG6rwZ9Fjss x3deAGjphTiM9aqRfoFlPTCN86cUYVqPZTjPkQakFsQkLMc6yrNYVs4n4lrR9NRSLJuG9xuxHOe5 5TTmc5CeAvilGWHR0OJEegfiesSdiD4I0OjP72j9UYYgXYZl+L5f7sZnfsB8HqbvQ/yIOI/YgliL z7yL97MRlZhfhJjCZPtXfs3/OP1te/bf0jZ2rAjX4SftbdJ/TWPz+R9oe9sVm///RNv4oO2oxofY ONrY0j+0mTGKr+jcFqibe6KOKmF6melGpo9VfRSlqh+g6cXPmA1Bugr14AWmi5k+RF38F9SHK5Au iPqgJ5EujPUL19gjarx7DLXQN7BO9QfehHVMX6vpGD0FW9v4LqPEPmqdHqrPPFcdfznajUn8B0oW 81W4H+E2Sa/GhwXIi3Ex/4Plmc1D24y+tNI55heL36BduRr59Cbrg/K5al+qYCU+czWzuWjXT6NP 04T2ZqsaR6LdQbt7XI0xnoa/qvq51T9WmF3Kw7QNefATz+LvOOjHrQADlk1n72fxBDcI9egemMve Z0Bdrsdx6XA8OhZHd0cf/nYowLIJ0u0oL93VuHFhbH5xLf74Gz4N89HEVl8tOub2sqn2D5S9zM60 bTf2nK4PzunXwLf6Z/9hjUXtfUGU3vDbflybeKO97F0af4zlRytvcMuUg62+5kikuFZURHncvi+x tnAauv3emoytEUyv5rW9hHJe21soQcjRMoY5wjZYyPwo1RdoRtgxpilWWGzVTcVk7AuFnfx5Nba+ PvYulC8voidlfwnllPIy4ivMS/xK6Iy+wowoylAGZPWZxzWfQvQhemh7AehLhtugGXkWx/iGWMD3 wWf6QC+cv7/R4UoRnYMYCjX0tJKHvAsikvAdvdEmjlJ9NVBeRTl/Fek7fArcrcrnWATOP+JFzD+P OIUoRARUXrmxDTv6ZZM1X4dWK17WHne3OsapWI/5jjdJ0+FaqSfiFFwrXIP8CuPa3I0+EYVaIRXj 0eO41v6F7ygCB70OujPAT8o2chK6I1IQHehD0J13wqv0DNp9tqf1NxIX2y/Q/G6CMTt5Evn5LuL1 NntUTzLgvb9r+x8kC+FHft2NfLoG6c/Ii9no3w/D/M9R7GwDGUER2zA2fQOewfj/PvTl9yPFdtA/ 2tweWHecBuVUdB/hDfSlN7dDWXvgs4zmtgeWM5reHtHyhPbAckZ7tweW9/6Nfvxevd/rx++VZ7QH lmf8D/Tj994baA8sD/xB/yrbA8sr/zf68Xt8TmsPLE/7g34Mag8sH9S+H6i3F2n+WIT56g1R3/0B 9q9PIEVfXjmHafTDgPmYTq2OWg/9RbAhKhDv4fPM73wM8S/EV1jnBsRTCPS5IsxX/BTxASKESMRy P1L05SJ/QXyMwDYj32H5eKTsHvPtpiIyEBOi8GjPt+DzkVoE+nyRxzF/L1L0YyPjou2x599CdMc8 +phwFaZnAPv4Q/v372Zh2qz5vpGfkWIbLesx/ZnWF3Y/hgh7N46vxYv5LoggYjiwv9AHCkGcwfsY uyjosyrJCAfm/6n1QcG+Ki8hBmD+nKYXlE9xnQ7mDbgGJ0GJcBTOSxa4nlFV7zKdu1J5tY2tOq3q wg+glhMxblYwTitBX9oMB/iH4DvxOaVJfAJjkfHAfPd6pEHeo5xmvoLqL7yP8d9zsFr4Ad83E2PL YZBH38WYG9vgt2Fb6L8wu8va41bh/VVgU/czj6h+DosJlxum4bN/grGiE32THlAuFUMZxiTlQrWy A/Xw05IIvYW5UCY+AsnCUijTdcH031X/px/XqLSIO0gCxuzPtdo/J0QwDtoWo7p34SmpBsu3wBD0 bVIMvTFPme2MPB9ru82eZDHyc6QWgwDKCHRFXx7n5JcB0T4vV300jG9j+6FCJq6/fLU/41X7GfMV v4aP+TWwWPJDlfAAxrAN6LMcVn3ItdjW0Gib16q+FdpIqRN8LHSEMIvn1Zj6LIQEJ3hjlPkbMb9U 4LHNTMhiewVqvH4K85MxH/VPW9/B9hEwlmd7wO39mpgf1canUH3VVt83Nh6kzH62jj9Kf+VvrIeR LOZn+xOqb96eRvuk7k98oPKvH/M/pIegn7gb6Y1EJyahrfuU6LDdRulN5XPxWeVNXQLK4w4oVf01 tNHC26DoPmPfH0f+jPO0GF+NMRn79+EUXGuRI9qcKa8hMLZTsDxSj2Vh9FAKMD8T89diHuM19uV8 5MOo/jiAa/Bfmo5g6ziC8WIE1xbgmgO21pZo+gAwRiV72sQMYhR3Ieazsja+Wo3mT7ajbfx6Nv52 dEy7fNV/G8uxNczOin5v7/IiVVpQbr+9uKepVJBTke9i/mzMj25PeW0f85N2NFWjESbDI5kct6ft 9+V/b5/+D/zY6liMotJL/Gvlm3a0uPW84T/QqP89L0qLkJ5BXuxCys7lZrfz22/43ViyCvUMO2OL 0l/vq0Zjw1Ya9cvbny/EqLbPPE87s1P995HqeQc7c/gDtJ5NrYRGxCtt6AcMqn//GxBTYCVit7QX diCOx6i6d/oHEDfgcxtgt84LOxDH29BzDBf3934bHIGViN38HbADcbwNPafit88NJ4gPYbsPYbs5 2F4O9vcM9vcMPsf8/z8A8oCN8bjOro7xA2YL/xBLYDqDzoDtGPCZndjOTpW+zRDje4yPMb7Extfa 51j70ff+384jPwd1/h/gP83L/9S4/6jvbYF+yWTmk0TpCfXs9pI+M75hv1fCXxHXi98i/RZ9FnZG 8AQ0RvHB78lRbP+dmwh/RVyPdV+J4oNfycHdSpOKaF47V4Dz2O7j4kfYNq6D6PnsWBZj/RZ/JGwH 5e96qTdSxit2HqHFZBtxvpkvsYHp+KjuK9MboE5aD7mqHv0AHkW7+zcWp/InYVLU3xuLYDYrGk8r Oj6oPKLuyYhwLR2peAUd6oTTynphBCxgwP6lRDEkis6IPaj/IoiXEEuRJ4exT7dqYGc2GHN0Up5B HMP7p1G19ED0x3bR/478SfNVVfSKli/VfNHItpju5RTlFeGY8rB6bk7U87l5OH/liI7cc1DO/AXs /xvcEIhTz1vuhlT1LCEcPUtgew/zoDOO/wfkRRI7P+d2qWUz1ft9WbyPtoXF/cnwQvT8xSfcjTER 0ovfMkAmawtxNf+W8m92rqDylO3N4TvQH3yN+UXclxibPw19uUdgiYpziIei+By2cS/DEtIPltA9 mL8PQWEJPwvpGcQLiB+xjhXWcCsw/RgiG97l1sOjgg8+Qz93JmIzfQ112NOwhS6D7nh/N+fRQIeg LA6BOi4VbkJ3Pp3eivcV6E4XIM3E+3+D9UgfQzTQ8+AkGzE2fw02cMdQ93WDRfRteJFbDTO5zpBJ v4J/cCbsywq4jzOhn6Mo/yKrlDDWN2G9oVxn5TDWuYbTK59iHTvWmSc8if7yFfCI0IJ2/m2Q0FcP C9/DYKEUZX2I8k9+D0xGn+cWBMYyLR+w7xhQRr6gr+NcoADotG9FVEp3s4+80PMZodoj9Vsdcj8W 7Na+5FG/z9Bkfhj6pJ9JA2G5ZEOfzgRTo9+VsPOiW/HZK/gPlJP43jpEBr8D2D/9RaN+WA2+yshk DtfohtgeKKPszIzNseaTKczv601fgTQWC0X3oq5Fm30OYxW0G0ojIgllfCuD9i2MckKzrcp5zohz PB8E0Y081PavvOr51iSUnRXgb/O+m4SV0E3bR1VGXfzWRvkc38u+3RjEuZUidR9Y+7aG2e6RbfbV pml7akoD+u8LtTNI5QU6XGF+13J+tNLE6WE5/Qc8hpjCdYSdTF7IDriH7FA+Y3JD34ADKDuViHFR VJJ/4rQo0BNl4CU6A2MqTCNG0gXKLJStYuTLMJSp/Yhd9AQUopx8gLLVF+8VcYWoIxbAPMQclJsr 6RYYoOIrxDEIYh/Y+QvGssrtCAPiJpzrWSjnVpTpLvjOziiHRkwH1G+itLNd9WwSZcf+n2zbf/IJ /pMN/0/1ua2wFPvjxf4sYufKmMb5QLmLnsuLBtWnnIr3TdjfPLy/JfpNVImqy5CqvtZI5SaMh8e2 993YnjubU5Tx1/ndypvIn1rEFgTG8QrGDEoWogPKZZMWl0SGSmshgLrGGNV9qfj+LtinL6N8y2Xy irJW2Oqfx/ztmD/I9tDPQRV3E8ZMRTBLO99U90teROxChNm+iHredAbjBXaOfgaexLIT0X2QBsRR BDsTw/mNPI34O+I5xDHEo+y7NcaXVp91HFThszer/DoHW3UDCIhH4SGUhYe45fAiWYX+3SrV372P gRaTLEQ23j+Ha2M19v1ZfN+T0Q/95v8Gtv8apOg3wOI2jM9oyh+Dy//vwcdrEBJ+B89fCt2ii9DP 1GDAuTchj8w+AIsJ8favYb0min9dClsfADvGpA6UGSfOXxy+K/4zDe5hAJ69F5GAdjoJY8vkVwBS 8Bkf9s+P/EtFfqUlIX5BNToEoAP2I/NBgI5fAWS9cRn/rxDcy/5fjcu4jMu4jMu4jMu4jMu4jMu4 jMu4jMu4jMu4jMu4jMu4jMu4jMu4jMu4jMu4jMu4jMu4jMu4jP8vQNi/5AffQAmMBAEoyJALIwDo CjoQeOD3X9X5KfoE1grRXfXFeaFGuqtBjuvKaL3Eso83mOxdb+xlozthH+I44jyCh854HYwYg+Dw 8Z31G1j9nfVjVNIwaGjX5YwOGNhVzYf6atRg1qi+u0Y757F62xsqFrH89oau3bV8Vhctn5aOzct0 O/bxvHq14jUXUYq4EcFj49sb4pK1x/RO9tijDQmJXa3H6aNY41F87lG1i4+GDHjbPlgcLNHzvQrJ 5+xftFWvN6rXMeq1VL3mqldr9O5nrHX1ely97lOvueq1VL0OVq+z1KtanzTj7xf4+zn+fkY+C9kh m4CXyNlE9pJQNgl5yRGiJ8b6fO8djcQYKsz3dvKVebsi8nxXerORehFLs/p6cxD+rHJvIQH2zwET CjpwuQDAbtOFGsmew5FV5pZVZtA3ktL6rAHeXnrSHY7yrLkCxP0Ivj5rrvcZfNqnZgF8dHe99+ec RlJV7/3J26gj9d4fvY2UhBzef3ubvD94n/J+5+3vPZO123sEa91f7230NvJYa2tWI90dsnrXeodh 55q8i7zXemf61FvX+pGEjN7x+NDIrJHeal8ja2WQT23lSi++5pC3Am+WZzUScsgb8t7mzctRH+3K Hj3k7eKd6+3kVZvL1prrqPUtk5FD3g7YWKraSoV3hFlv1hdufFvauEvauFPauEza2Eva2EPaWCBt 7CZt7CxtzJU2BqWN6dLGZMmps+tknUVn0hl0Op2o43VUBzr1v/AOsn8N0ynKjIg8u/JqWqbsSrV/ LJMSHYX+EHZwlbRyeG9SGT4xHirH+cLfDw80EsPQkWEh0JuE7ZVQeVVvd7goWNkoKcPChcHKsDRk VPV+Qm6vwdIwXd1I4KrqRuJhRbckhu1l1UdwVj23rE9kVLllfU0NxC8sdZfae9qK+5T/xqUuem3z /8S4L/1vYyqHLD6Cs1zdIHmvkDA7HLMbWXYjy7qTw5srh1eHn0iuCXdlCSW5pjK8abhvdPURspfs qSg/Qp5kpKb6CJdN9lYMY+VcdnlNTSVOjVoPxX4vq7eXEaynewNKWT0o1b2h1uOJVi+g1kOx0+rF +yCg1gvE+y6pl0KeZPWyGMF6rvchRa2X4nq/Tb39RwMV5fsDgdi7jqp1jmrvCpeoVbxerOL3qlVw qXjVKl5C1Sp9LlbJiVbp1Fqlk9oSRy7W8Wp1zL5YHTNrKfhf/UzsHQxWTGWyMqR6vw5615SN1mi8 PLunOu9mT88diUfhFfYFerAmbAj0DhsDvaG01K3+R4SiKSxikYRgtXv43csSj/JAdqm1TVhsjt7K 6ZXTi91C6WW3LFhsjd5yL+vhTzxKdkVvyVhswzba9HP+/AX4A+6KqeWtf+ZFfxZE6XyoDGcNrwyX Dh1ZvV+SKsKhuvIaLOscKzMaKxqVE1phJywsYYUc11qxtUyvj1ZEbhwanE0Ge0khdqEmOA+7gg21 5eD8eeoVF+j/Ap9xwtUKZW5kc3RyZWFtCmVuZG9iago1NAowCm9iago8PAovVHlwZQovRm9udAov U3VidHlwZQovQ0lERm9udFR5cGUyCi9CYXNlRm9udAovTVVGVVpZK0FyaWFsLUl0YWxpY01UCi9D SURTeXN0ZW1JbmZvCjw8Ci9SZWdpc3RyeQooQWRvYmUpCi9PcmRlcmluZwooVUNTKQovU3VwcGxl bWVudAowCj4+Ci9Gb250RGVzY3JpcHRvcgo1NgowClIKL0NJRFRvR0lETWFwCi9JZGVudGl0eQov RFcKNTU2Ci9XClsKMApbCjc1MAowCjAKMjc3CjAKMzU0Cl0KNgo5CjAKMTAKWwoxOTAKXQoxMQox NAowCjE1ClsKMjc3CjMzMwoyNzcKXQoxOAoyNAowCjI1ClsKNTU2Cl0KMjYKMzUKMAozNgpbCjY2 NgowCjcyMgpdCjM5CjQzCjAKNDQKWwoyNzcKXQo0NQo0NwowCjQ4ClsKODMzCjAKMAo2NjYKMAo3 MjIKNjY2CjYxMAo3MjIKNjY2Cl0KNTgKNjEKMAo2MgpbCjI3NwowCjI3NwpdCjY1CjY3CjAKNjgK NjkKNTU2CjcwClsKNTAwCjU1Ngo1NTYKMjc3CjAKNTU2CjIyMgowCjAKMjIyCjgzMwpdCjgxCjg0 CjU1Ngo4NQpbCjMzMwo1MDAKMjc3CjU1Ngo1MDAKNzIyCjUwMAo1MDAKXQo5MwoxNzgKMAoxNzkK MTgwCjMzMwpdCj4+CmVuZG9iago1NgowCm9iago8PAovVHlwZQovRm9udERlc2NyaXB0b3IKL0Zv bnROYW1lCi9NVUZVWlkrQXJpYWwtSXRhbGljTVQKL0ZsYWdzCjY4Ci9Gb250QkJveApbCi01MTcK LTMyNAoxMzU4Cjk5NwpdCi9Bc2NlbnQKNzI4Ci9EZXNjZW50Ci0yMDcKL0l0YWxpY0FuZ2xlCi0x Mi4wCi9DYXBIZWlnaHQKNzE1Ci9TdGVtVgo4MAovRm9udEZpbGUyCjU3CjAKUgo+PgplbmRvYmoK NTgKMApvYmoKMzY4CmVuZG9iago1OQowCm9iagozMjM3NwplbmRvYmoKNjAKMApvYmoKMzQ4CmVu ZG9iago2MQowCm9iagoxNjk4MwplbmRvYmoKMQowCm9iago8PAovVHlwZQovUGFnZXMKL0tpZHMK Wwo2CjAKUgoxNAowClIKMTkKMApSCjI0CjAKUgoyOQowClIKMzUKMApSCjQwCjAKUgo0NQowClIK XQovQ291bnQKOAo+PgplbmRvYmoKeHJlZgowIDYyCjAwMDAwMDAwMDIgNjU1MzUgZiAKMDAwMDA2 NDI2NiAwMDAwMCBuIAowMDAwMDAwMDAzIDAwMDAwIGYgCjAwMDAwMDAwMDAgMDAwMDAgZiAKMDAw MDAwMDAxNiAwMDAwMCBuIAowMDAwMDAwMTYwIDAwMDAwIG4gCjAwMDAwMDAyMDcgMDAwMDAgbiAK MDAwMDAwMDM3MyAwMDAwMCBuIAowMDAwMDEwMzg2IDAwMDAwIG4gCjAwMDAwMDEyMjcgMDAwMDAg biAKMDAwMDAwMTI0NiAwMDAwMCBuIAowMDAwMDEwMzE0IDAwMDAwIG4gCjAwMDAwMTAzNTIgMDAw MDAgbiAKMDAwMDAxMTg4MSAwMDAwMCBuIAowMDAwMDAxNzY4IDAwMDAwIG4gCjAwMDAwMDE5Mzcg MDAwMDAgbiAKMDAwMDAxMDU3MiAwMDAwMCBuIAowMDAwMDAyNzE3IDAwMDAwIG4gCjAwMDAwMDI3 MzcgMDAwMDAgbiAKMDAwMDAwMjc1NyAwMDAwMCBuIAowMDAwMDAyOTI2IDAwMDAwIG4gCjAwMDAw MTA3NTkgMDAwMDAgbiAKMDAwMDAwMzkzMiAwMDAwMCBuIAowMDAwMDAzOTUyIDAwMDAwIG4gCjAw MDAwMDM5NzIgMDAwMDAgbiAKMDAwMDAwNDE0MSAwMDAwMCBuIAowMDAwMDEwOTQ2IDAwMDAwIG4g CjAwMDAwMDUxNTQgMDAwMDAgbiAKMDAwMDAwNTE3NCAwMDAwMCBuIAowMDAwMDA1MTk0IDAwMDAw IG4gCjAwMDAwMDUzNjMgMDAwMDAgbiAKMDAwMDAxMTEzMyAwMDAwMCBuIAowMDAwMDA2MzkzIDAw MDAwIG4gCjAwMDAwMDY0MTMgMDAwMDAgbiAKMDAwMDAxMjAyNSAwMDAwMCBuIAowMDAwMDA2NDMz IDAwMDAwIG4gCjAwMDAwMDY2MDIgMDAwMDAgbiAKMDAwMDAxMTMyMCAwMDAwMCBuIAowMDAwMDA3 NzQ0IDAwMDAwIG4gCjAwMDAwMDc3NjUgMDAwMDAgbiAKMDAwMDAwNzc4NSAwMDAwMCBuIAowMDAw MDA3OTU0IDAwMDAwIG4gCjAwMDAwMTE1MDcgMDAwMDAgbiAKMDAwMDAwODgwNSAwMDAwMCBuIAow MDAwMDA4ODI1IDAwMDAwIG4gCjAwMDAwMDg4NDUgMDAwMDAgbiAKMDAwMDAwOTAxNCAwMDAwMCBu IAowMDAwMDExNjk0IDAwMDAwIG4gCjAwMDAwMTAyNzMgMDAwMDAgbiAKMDAwMDAxMDI5NCAwMDAw MCBuIAowMDAwMDQ1MDczIDAwMDAwIG4gCjAwMDAwMTIxNzYgMDAwMDAgbiAKMDAwMDA0NTczNiAw MDAwMCBuIAowMDAwMDEyNjIwIDAwMDAwIG4gCjAwMDAwNjM0MTYgMDAwMDAgbiAKMDAwMDA0NTkz MyAwMDAwMCBuIAowMDAwMDYzOTc0IDAwMDAwIG4gCjAwMDAwNDYzNTcgMDAwMDAgbiAKMDAwMDA2 NDE4MiAwMDAwMCBuIAowMDAwMDY0MjAyIDAwMDAwIG4gCjAwMDAwNjQyMjQgMDAwMDAgbiAKMDAw MDA2NDI0NCAwMDAwMCBuIAp0cmFpbGVyCjw8Ci9TaXplCjYyCi9Sb290CjQKMApSCi9JbmZvCjUK MApSCj4+CnN0YXJ0eHJlZgo2NDM3NAolJUVPRgo= --_002_C43C255C7106314F8D13D03FA20CFE4930CA5EC0wtlexchp2sandvi_-- From nobody Mon Jul 18 02:46:27 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3441412D6B8 for ; Mon, 18 Jul 2016 02:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uCmMAsZ3NQP for ; Mon, 18 Jul 2016 02:46:22 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4689612D7E7 for ; Mon, 18 Jul 2016 02:42:11 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id p64so28372797pfb.1 for ; Mon, 18 Jul 2016 02:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=4VI4/hoKtVXGrYJTnkUhPZa1X5W0yGPJ/wCvU24xXg4=; b=cIABJRCs74hDIJJK3ZVUTbEr7SMGIXxlJacKYhBtqpMIw/xgXH4Qq08cP1Dze5GyR8 o0K1DNjoqb5LQ0FI1Wuo1icx6/Kj+U3V1UBguWTffrjEpeMUkFcDnLJ7RlMiMfARo0QS wVrR+wY+kUQMBSv5EGoxdJI4MY1XLSZbWkdsIuyf3oMY2onmxzbifo+IIRFh8PVJaSuo iKIDHsv3n82GdPbL6wOhG7mMr7EGFw8ON31tyqzrklzKyAdDsDCsSNJ8jhgroCFdTdZr YhCVY2JJ0dVNhaYYwhHJ70khzKq+cRVa5xzicN0gZUDoTSzxZJrKQkFzLdmL0omC+5Xg Gp/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=4VI4/hoKtVXGrYJTnkUhPZa1X5W0yGPJ/wCvU24xXg4=; b=e7DHLOis6WrGWPdOMbTdQ/BARjsIyZxD6jnF3dnBlV4VsLTqOCdsQl0W7i03Svujtq jw7JffJo1ZnG86oBgIlvwyWWAlqonNJeioQWr0I/IeIhY/oBv6yNGLTl4OHdFA217Xbg s9VK49HW5TPmvXSWZbWjfEWc+h8JyvFsSI3crzGv1Udky7R2YAWvRh6ojy54VzUoqsKw GMV6B06646YRs8Ijr5UaZjUjZzAFgA2umUe3gzWlq2+TbxyL1rroNJWwUxZye11sA98x vjz6+y2vReLrTlsyk3yzXocdzeYP5OOZ519Yedyp80Ms8X3Tuohs3wqQOC8b1ox1tihg T14Q== X-Gm-Message-State: ALyK8tL8qYarwq2XrJ+VqlVJdTEuM0O35YCgdM+9BpJHGG0TdVnrTQtrKQr696d0zGiKgA== X-Received: by 10.98.11.86 with SMTP id t83mr44483628pfi.51.1468834930288; Mon, 18 Jul 2016 02:42:10 -0700 (PDT) Received: from [10.240.251.90] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id yt4sm2914874pab.26.2016.07.18.02.42.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jul 2016 02:42:09 -0700 (PDT) References: To: Yuval Lifshitz , "dime@ietf.org" From: Jouni Korhonen Message-ID: <747c3ab4-0aef-0f9f-1f33-8ab899385f07@gmail.com> Date: Mon, 18 Jul 2016 02:42:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dime] slide for RFC4006bis discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jouni.nospam@gmail.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 09:46:25 -0000 Quick notes.. for the IPv6 redirect address you should reference to rfc5952. To make this properly, I think you should comform with all possible ways to write the addresses (specifically the zero compression stuff). However, I am also fine limiting the options to two as it leaves less room for incompatabililty issues ;) - Jouni 7/18/2016, 2:14 AM, Yuval Lifshitz kirjoitti: > Thanks for the comments. Updated slides 3 and 4. > > -----Original Message----- > From: Yuval Lifshitz > Sent: Saturday, July 16, 2016 10:52 PM > To: dime@ietf.org > Cc: Bertz, Lyle T [CTO] (Lyle.T.Bertz@sprint.com); Dave Dolson; Lionel.morand@orange.com; Jouni.nosmap (jouni.nospam@gmail.com); Yuval Lifshitz > Subject: slide for RFC4006bis discussion > > Dear group, > Attached slides for the RFC4006bis discussion. Please let me know if you want more topics to be added. > > Regards, > > Yuval > From nobody Mon Jul 18 02:50:39 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49DB512D738 for ; Mon, 18 Jul 2016 02:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xNPHsEE74dg for ; Mon, 18 Jul 2016 02:50:35 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0104.outbound.protection.outlook.com [104.47.32.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6771D12D795 for ; Mon, 18 Jul 2016 02:47:17 -0700 (PDT) Received: from BN1AFFO11FD017.protection.gbl (10.58.52.32) by BN1AFFO11HUB012.protection.gbl (10.58.52.122) with Microsoft SMTP Server (TLS) id 15.1.523.9; Mon, 18 Jul 2016 09:47:15 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.81) smtp.mailfrom=sprint.com; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.81 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.81; helo=preapdm2.corp.sprint.com; Received: from preapdm2.corp.sprint.com (144.230.32.81) by BN1AFFO11FD017.mail.protection.outlook.com (10.58.52.77) with Microsoft SMTP Server (TLS) id 15.1.534.7 via Frontend Transport; Mon, 18 Jul 2016 09:47:14 +0000 Received: from pps.filterd (preapdm2.corp.sprint.com [127.0.0.1]) by preapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u6I9iGpQ036332; Mon, 18 Jul 2016 05:47:14 -0400 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by preapdm2.corp.sprint.com with ESMTP id 247dxt17b6-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 18 Jul 2016 05:47:14 -0400 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 18 Jul 2016 05:47:13 -0400 Received: from PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8]) by PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8%24]) with mapi id 15.00.1178.000; Mon, 18 Jul 2016 04:47:13 -0500 From: "Bertz, Lyle T [CTO]" To: Yuval Lifshitz , "dime@ietf.org" , "jouni.nospam@gmail.com" Thread-Topic: slide for RFC4006bis discussion Thread-Index: AdHfmdgffm5vJqrITTiB8hPBrUVu1ABOre8AAAt/jQD//6x94Q== Date: Mon, 18 Jul 2016 09:47:12 +0000 Message-ID: <1468835231519.92530@sprint.com> References: , <747c3ab4-0aef-0f9f-1f33-8ab899385f07@gmail.com> In-Reply-To: <747c3ab4-0aef-0f9f-1f33-8ab899385f07@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.91.95] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.32.81; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(438002)(189002)(377454003)(51914003)(199003)(13464003)(8676002)(86362001)(5250100002)(117636001)(2906002)(92566002)(81166006)(15395725005)(356003)(81156014)(36756003)(8936002)(5003600100003)(7736002)(7696003)(11100500001)(5890100001)(106466001)(50466002)(15975445007)(23756003)(189998001)(586003)(7846002)(6806005)(6116002)(76176999)(3900700001)(5001770100001)(54356999)(2900100001)(2201001)(305945005)(19580395003)(2501003)(8746002)(102836003)(50986999)(19580405001)(47776003)(3846002)(68736007)(97736004)(87936001)(2950100001)(4326007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB012; H:preapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD017; 1:/xiV+hxsnOxZbVK5z5dXECblAWiEdWACKzb1E6oLgOJIMZOLyaneKdUG3KcBie8n4niWQv/vlY48/F/d2ve1uhuU92ASz4n7s6wMwUbskEecU2lYZeuR4ziCgRsboKEQ3CDT42spnjEHnia1odngvfD7mDkmW/FOQqNZqBDliJo4Xzcqr4GQhvZXieu+hSoa8NIrB/7Brf4ur1VCXCKYYr/+d2a28Z9rw8pVAQb+M5S397smPI36QGe/VrMLB/zg9YB0luDt6EEO8qrjO4s+QEqb229z/JovcCNJlox8lPMHpMCq36pIW9OMiFJekchw27W+tTaqI8UQAhAceUg2erEGozCSvNmxt/PhRJ2E83LmsY8nxFZYAeUFPqwY++31udqVqFohWPKvRrcgbLHeO7xtyZdcgkRPX3Ww6opRhPUdZEBT/xZb1r071jCgbaStRzzxTN+YKDmm0FpvEIvdP9drlOkGg2MaAG1h9YOZsjC2v/pim91cWRfOrA37ISpVsLuHPuMt0rMW7/p8wG/8ASIUrQb7mBKcFdYY9hN33KwyygQzJ4tXLPfgCUENiejm X-MS-Office365-Filtering-Correlation-Id: 436e31a2-727a-4321-70a4-08d3aef07fde X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB012; 2:LoJDR7hxnU8Xih+qm8oVAq3jEp1XnUw+SwtvyJClGqALRDMnlMXINIJDIvpVjhKc1/WSY8QsYIOm36WhL3Rl0JO1xRsWW5/K9XqtZaB717Xilm5cAg5DM++FK5KO9o/GeL6wQcMAcjjO/E9g8c8TBi8qIB9yM0b2klm+LtQsoeKH+aF6Pf8DfHOI9NCEwMtc; 3:IHEi0dm6G020BTsCli+un8QciZzdj1G7QYgjG1l13GuYM0vyjeaEfETjbPJAS8tLr/rjeXCYf5LhXwDq30nO5H1sfRsHCk46qRGX2Uk5XhbsWC2+gbltdxdOXB5i4pXKxg5YNSCXq27Wy+rXkYjk+2FJelEQ6QWVPXUhzz7eoiI/ulm6i4sb5nqhri7c/eehVU9k2bdHvhWoQRi0IvKD+AJHM8VXzjJzEAOGQk0X4d9QxWY5Bs3kXzqO/MS+TZFeQYsUpBgy8g/BL0lfMOFDTQ== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BN1AFFO11HUB012; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB012; 25:u2HEu0/EbfKl9eObS0Q3NWw3KA3JgGwIlc4JALj62+ah56Lw9HvImamTMcjCRTr3WL6Ms7VccvpLB79qbGlaH3K5YzQukvAjjcuVBzU3G48Y74IlSc6tElCgaw5PfiVSkfsK/ceCGhe1KqfFpE9ro/HdRlfdPWNiSjkoQPLxz+3+UrvLN6Zc+qP20F1SzT7Ft2vB9cRCFiWs4iROhMTN6n7JgPp34s/awvxv1V3/Vbh//3MtKvrAa1WJruFW5icSDypxgzHRv4iweZ2PFlUtxVSx/wIDdVEn51MyfUBee0hgZA6UiF+3QK0sw1QwxiObsmmKzL+IDDCVwwzY2E6gsjGGzkX0S4dPu3D/ex8bCG2nLvXzUIOX8c6USEYVhvGAdee5PCSuIyqndyZUhVurf94sGdAU7fJ0N0i6KQ+1jCt8rxJgCxdfjMu8siahJTMDCVXNfDWPIhtnnvoo4QYUrwC5VQESk0NRFiGm/UQbyJ0k5tllg+PpF6qHZIEpV3nxSMRdUHa6XfHQxoyNiUJkRURAe580k6XQMzwk+d16Hrk3agGerxJH9b3p/ypqzJN7hib5JSuNdT5B7Zgxv24V+LSYz4zqqnCooO8z5kz+GoU0MAQ2RumGsDMAmaZ8BOf79H+JAwe9nqUFCMWR1rQ+5d1v1QLt/HufHcp1SrwJtfHKOzrYFRUZRRy+crg8wkyl6YC/OUUL4P5V989V3do/J0FAf/g5ey0GCRmiRLFCs7brKpgTsN+Ijy04Y9RV74skIAx9krCVkbU1t4rAOQXvsqugv6L54JjjhMK05jl7PbIcz12CdCVbA7jloQ867NB4TTye394wbH/u+bm15bZL4w7dcWyYjFV1RUMSFEpyW6+csz508Tt1elHePHN+WY2qB5sQxwxI5ZoYi/MhIdFEPg== X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB012; 20:LLbf7/MAZ/358vRn4Pvc0VP4upBoab2fO6qywDfjIwenBfka8Hkx4ZsrzX6bh2Lkj4Ovgo/MHkSBkCJygyHDb6uIQh5BNhd1yw+GgzYCi++DVguzEGM6J9fvEYZ+gA+e1Zj+VInFe32UWwCLHKndtHHOS959m2VtA5YgKzP8oLqDXh77yGK52PmMQK7GyT0tmo4T+sBi03RgY2P8FH+qxjprtRDYUWeO2BZPTFsnLqQf132s6cfWmYhqt8OVMHok63jjFpKwTqO3AVcyNxl01Q64QTpTPuYMDLeTNMEHHWdtPpRyKWjD0UuNZtTqUsKd/2cpptYfoDSO1o4K3c+ntCmEuPrwEdvvgETFmH3km38dk6WkvRBy5PBBrPGm+BAOYAgXgimbLTsYpDCZ9b2F3GaTlzt1+WeBRh/ijg3sxhE= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(18430343700868)(18271650672692); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13018025)(13024025)(8121501046)(5005006)(13017025)(13023025)(13015025)(3002001)(10201501046)(6055026); SRVR:BN1AFFO11HUB012; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB012; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB012; 4:vLAc74TV1xJ3BRk8Ct3VcIbxB0+Ms668+zmxA7w6JVYJbDUL8fE45b4hCZvINI7mZ/+QnU84PObfSW7Gj7BCAmi9syuI7fdldNqn7OSHYo+yR9w787G2DUQI6xFUHCcQ2KVTDfh06LCmI8Q1Ol8o0YLZDR30YckqbFjKa+oL62dWQr2gbXDRuaHsJthvucMeC52t/LGNdAbGnvoQ5L84X2YGO/ndBDRNliPpUoKN/Tpu9nM5s5I5gd2959qNYQhSPAWYUYTUIQn5DwDHTkZ+NGYOhw4uVirFgy/F11WR/YVzqGpgg3WRGWQrklz6Ssc4Fgh7lbUX7INh39ufq9CMS8mMDwsOxedGeEbeuKVGYhxkdf1ZAbdhhIYx2viDk/1Drj+CebHck5nK9qR5wp7h1b4KX6l7nUJkuuW4ckktXqWzWgxRzMeD+HU6LeJPPJMSXz3SHuvUjkWrMp+x0OZb2hEqSmDhvjkeGJEwsz4LaNEuNaa4+B9AjugoeAA4tL2PvZKJJEjUOOG4O8EIFa1zbQ43nOT9F+yg0WMA+4pnryJ6NhH0qJcpwobJCNbfsRD4 X-Forefront-PRVS: 00073DB75F X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BN1AFFO11HUB012; 23:fhmGLwmsudKhzm3oNBSPd8sVLwTNrYjCdkUc0?= =?iso-8859-1?Q?HQwLYzGmoXV4pa2Mqc4XruqePacZHQg3e1PYFf3ZUlP2+pb0Wy5g8lnBF9?= =?iso-8859-1?Q?nEhmycHgPFS5WIqh8F8Gp+q7ExCZAwiHcHDSyvNePZFJ57CHQUY0tftQ/l?= =?iso-8859-1?Q?uWHhCC+NbaTcbgIsTeZNOInnW4Mr2wkeTAqQi4dw5Sko2qxUdWj7iJlD4m?= =?iso-8859-1?Q?D4JzW4WaB/lV1s7XtiN0XW5ypQ6eyuuw1vbn7mFfBageN6Rn6CKrDH2Uhp?= =?iso-8859-1?Q?/A0XSLk/c7WDEK6xjyu/oUtx+2wyMo9tH4GeuLQEKUFTYruI3RMrR9Vos/?= =?iso-8859-1?Q?CDiHWr0OpvCEVaS6Z5QXgwecV7aOxWx7aOFrYACaR686sgmWY1g113PEGJ?= =?iso-8859-1?Q?jgmeMfU2zAzT6rVLTCNt3jVaoPZoG1FV2fCzexT3IVnRhl+TE2XCbZCeLY?= =?iso-8859-1?Q?IwmCys+jjNrn/CUtaHU0rx9W7zh9Dpd+1/zXzIBSmYx2QS0Bl19fR8gFyf?= =?iso-8859-1?Q?tJbm8sMCczRycpFXQB6R/yZoLY+HOtjbtJOqXbG6FFWF5wkKSkq/n5d6Tn?= =?iso-8859-1?Q?yxL3vG5bbGmf7sTfgixx+iZ3HxV04autOA6G9vmUJsYA/yBIQoLE8N2Q9E?= =?iso-8859-1?Q?zT3FHqe2FtYZyxsjIJ5ld3TF/Z7XqlqJu57aSf2hwRdFK7vQJ8muQgXB0R?= =?iso-8859-1?Q?BoUEfN4/6113Eb+H+tvw0xQtV/H0xGKNOq23eY0B3F2kEw/AIVXNuXaw7/?= =?iso-8859-1?Q?23FnfLAI6T0+SdlZuZ7jnsfFywUSruv5nyg4cMrh9cBnv0UPFXp0/sJOnX?= =?iso-8859-1?Q?W7lBI6wv8aZVk6tzh9lph82428Th6qBnH5zWcBDf3ckHbv/EQOEa9TLfO6?= =?iso-8859-1?Q?B+gV+Dqd0FxSYEDgina1nx1Sl2CKgIZNWegRPDhrNHBCmab4sTsTJFAKdL?= =?iso-8859-1?Q?KEx0kX/ebMyWlQi/71g1BXrhcydOYqZh+2Xnhq/ck/NIhqwbMeNx8/3fcn?= =?iso-8859-1?Q?hl17mPp64G3sSHWjcoUMyooR6eP0y64gwmDa4IbqWHhQPOaYYyoB7caLEd?= =?iso-8859-1?Q?cazZ+F9w0F8CkR4+iaAjyYmllERq/Ln9UU9ZfhJdeUmFq7hp5J7ro7XP9w?= =?iso-8859-1?Q?kV8Z8Qal02Zi+ln2xMgFXlfE2vdCDlUm4WlI1pBSuSda06BX7be3rncPod?= =?iso-8859-1?Q?c4ydIqLZV1MuGnpE8R9O6nvN1u5VOMA9hlSWxeecBeTu8FcD080nfShKJG?= =?iso-8859-1?Q?GAkmEUYbVm3gW4BqF5L0Jx1oLRM4EgaBsDME3zqSei2HpQSsIdNAvWGnRe?= =?iso-8859-1?Q?aS8eTsRfjShAUMF8lkUNtiw7mtyh2iKQCjINSUAue5A0AkozT6nkCdi9w6?= =?iso-8859-1?Q?QnY+Xo4oLt/BWUvuXKMwVjO4VWV51p3sGVc9R2VAIaugeYtQ8kUXw=3D?= =?iso-8859-1?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB012; 6:GaJFb1xKQFj/sAliW9Zz1vZu9csaKzWePiKJpNBva5XoiCYrto6wkEuxVnNJ2B6IsfGKgJD55eHS/q0l0a6E4eI6h2mbgp01NpJglnBkRITRB05uzfmvjl9eSiS5w9GLUEFuAci9UNdUsquRgewYb/FWqN5EfIjkBDzExJmk5M/REEYYeyALuOnaHb/1eLK02418IorEK3FK2a2fxDmw7y2kG+OQ+Bqgjmmuh/OfrmoDQh4H69aHHC+LsJOkdJrljbK/EdXJ2hNemvqTIFrlY/70H/aw8aYIWDrDpN5mSbn3rBVZ9gwsTVXumHFrutf956ohtG3Ag9wAhcoqcBNlKeX1qs1VV8JrE/M/i5Wwsf0=; 5:CpfqttfP9OU4e7zyEonKqw1zEqBH3/mZXrGBaRnljn8iPTC3jFRWCAcQJPjyG7qHRWhFfm1KsQl1Pe8+uk7EVVphKyTqCSb+Nu+y9uaSWdbU2Xo0s5MME1DIQl1caq5alE9obG/0ZIxfvLekY7mpMQ==; 24:beSPxcY3rqFw2YYfs/bSYoKxSUdcnBI30UC/xObiCw7fnW3K/ONL5GvVbYHLeSREJtD2ih2bmwQ4bm+eOwPqPCUtwwAtU87ciyBgOSriMfw=; 7:3HX5L/UAnub/rVTDh9q31On9NGyNvJqSFNdlSh81bkZ/W5jLXDVAkPV2qXp1RfJN/VzCnPmy+CZwlOFi/jSLA2o3v6X03kAi5ReaIVmYV6685hp7Nit6She2GBRvCaueXhei1LG7HVG0FteMVBvdDyYViiTTwmTpKR+PuBCdIntcttGfl26BJBXPwpV6WperWz4Zkwvvw+Pe8rHYooXp9Ik24zjB+HfTAANs2yJD6R7Agn7e7JUclTpeKDx7qMDq SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jul 2016 09:47:14.9416 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.81]; Helo=[preapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB012 Archived-At: Subject: Re: [Dime] slide for RFC4006bis discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 09:50:38 -0000 Tonight we can lock down options; I would like to be more declarative as we= ll if there is no feedback on the list. If we feel we have addressed issu= es raised to date I would push for closing the document quickly, i.e. push = a change into the document not, if we agree upon an option, as opposed to l= eaving it open on the list awaiting feedback that may not come. - Lyle ________________________________________ From: Jouni Korhonen Sent: Monday, July 18, 2016 4:42 AM To: Yuval Lifshitz; dime@ietf.org Cc: Bertz, Lyle T [CTO]; Dave Dolson; Lionel.morand@orange.com Subject: Re: slide for RFC4006bis discussion Quick notes.. for the IPv6 redirect address you should reference to rfc5952. To make this properly, I think you should comform with all possible ways to write the addresses (specifically the zero compression stuff). However, I am also fine limiting the options to two as it leaves less room for incompatabililty issues ;) - Jouni 7/18/2016, 2:14 AM, Yuval Lifshitz kirjoitti: > Thanks for the comments. Updated slides 3 and 4. > > -----Original Message----- > From: Yuval Lifshitz > Sent: Saturday, July 16, 2016 10:52 PM > To: dime@ietf.org > Cc: Bertz, Lyle T [CTO] (Lyle.T.Bertz@sprint.com); Dave Dolson; Lionel.mo= rand@orange.com; Jouni.nosmap (jouni.nospam@gmail.com); Yuval Lifshitz > Subject: slide for RFC4006bis discussion > > Dear group, > Attached slides for the RFC4006bis discussion. Please let me know if you = want more topics to be added. > > Regards, > > Yuval > ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Mon Jul 18 03:10:37 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FDD12D08C for ; Mon, 18 Jul 2016 03:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rP8F2Yos487F for ; Mon, 18 Jul 2016 03:10:34 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7F2312D4FB for ; Mon, 18 Jul 2016 03:10:33 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0294.000; Mon, 18 Jul 2016 06:10:31 -0400 From: Dave Dolson To: "jouni.nospam@gmail.com" , Yuval Lifshitz , "dime@ietf.org" Thread-Topic: slide for RFC4006bis discussion Thread-Index: AdHfmdgffm5vJqrITTiB8hPBrUVu1ABOre8AAAlnGwAAB3XeMA== Date: Mon, 18 Jul 2016 10:10:31 +0000 Message-ID: References: <747c3ab4-0aef-0f9f-1f33-8ab899385f07@gmail.com> In-Reply-To: <747c3ab4-0aef-0f9f-1f33-8ab899385f07@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] slide for RFC4006bis discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 10:10:36 -0000 I find it unlikely that only some of the IPv6 notations are supported in re= al implementations. RFC4006 is not clear enough to be interpreted rigorously, I don't think. -----Original Message----- From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Monday, July 18, 2016 11:42 AM To: Yuval Lifshitz; dime@ietf.org Cc: Bertz, Lyle T [CTO] (Lyle.T.Bertz@sprint.com); Dave Dolson; Lionel.mora= nd@orange.com Subject: Re: slide for RFC4006bis discussion Quick notes.. for the IPv6 redirect address you should reference to rfc5952= . To make this properly, I think you should comform with all possible ways to= write the addresses (specifically the zero compression stuff).=20 However, I am also fine limiting the options to two as it leaves less room = for incompatabililty issues ;) - Jouni 7/18/2016, 2:14 AM, Yuval Lifshitz kirjoitti: > Thanks for the comments. Updated slides 3 and 4. > > -----Original Message----- > From: Yuval Lifshitz > Sent: Saturday, July 16, 2016 10:52 PM > To: dime@ietf.org > Cc: Bertz, Lyle T [CTO] (Lyle.T.Bertz@sprint.com); Dave Dolson;=20 > Lionel.morand@orange.com; Jouni.nosmap (jouni.nospam@gmail.com); Yuval=20 > Lifshitz > Subject: slide for RFC4006bis discussion > > Dear group, > Attached slides for the RFC4006bis discussion. Please let me know if you = want more topics to be added. > > Regards, > > Yuval > From nobody Mon Jul 18 09:02:04 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB5712DA2C for ; Mon, 18 Jul 2016 09:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwA3qc0D7kZu for ; Mon, 18 Jul 2016 09:02:00 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF6012DA29 for ; Mon, 18 Jul 2016 09:02:00 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 6CF5E961E3E9A; Mon, 18 Jul 2016 16:01:55 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6IG1wJY008104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2016 16:01:58 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6IG1vBU013045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Jul 2016 18:01:57 +0200 Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.62]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 18 Jul 2016 18:01:57 +0200 From: "Gardella, Maryse (Nokia - FR)" To: "jouni.nospam@gmail.com" , "dime@ietf.org" Thread-Topic: [Dime] RFC4006bis pre-meeting in Berlin Thread-Index: AQHR2GMRu82mQTbB3Eymi0B61X0YxKAeaYjg Date: Mon, 18 Jul 2016 16:01:57 +0000 Message-ID: References: <067bc372-46f1-22de-1e90-6a30ab126196@gmail.com> In-Reply-To: <067bc372-46f1-22de-1e90-6a30ab126196@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] RFC4006bis pre-meeting in Berlin X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 16:02:02 -0000 Hi,=20 I could not find the "Tegel" Room on the PDF floor Plan available under the= IETF meeting webpage.=20 Can this room be easily found once arriving in the Meeting Hotel?=20 Thanks Maryse=20 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: jeudi 7 juillet 2016 17:20 To: dime@ietf.org Subject: [Dime] RFC4006bis pre-meeting in Berlin Folks, For those interested in RFC4006bis work we are going to have a side meeting= during the IETF96 week before the Dime WG meeting. Details below: Meeting Name: Diameter CCbis (RFC4006bis) Assigned Room: Tegel Assigned Date: 07/18/2016 (Monday) Assigned Start Time: 20:15:00 Assigned End Time: 22:00:00 This is an informal meeting. - Jouni & Lionel _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Mon Jul 18 12:13:21 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D1F12D0E9 for ; Mon, 18 Jul 2016 12:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X72LkwpjKcx3 for ; Mon, 18 Jul 2016 12:13:18 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B0D12B00D for ; Mon, 18 Jul 2016 12:13:18 -0700 (PDT) Received: from mutabilis-2.local ([173.57.161.14]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6IJDAEx010842 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 18 Jul 2016 14:13:11 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.57.161.14] claimed to be mutabilis-2.local To: Maria Cruz Bartolome , Steve Donovan , "dime@ietf.org" References: <5b31616d-efa3-ac03-8f1c-bd8883a35d65@gmail.com> <087A34937E64E74E848732CFF8354B9219758407@ESESSMB101.ericsson.se> <3e2082d80d8e45caaca581c9dcc98468@CSRRDU1EXM025.corp.csra.com> <71796571-c370-cae8-d456-9d2dfb02544c@usdonovans.com> <087A34937E64E74E848732CFF8354B921975C3F4@ESESSMB101.ericsson.se> <71ffc339-37e0-e4fd-a16e-59da7fe23b6d@usdonovans.com> <087A34937E64E74E848732CFF8354B921975E5AB@ESESSMB101.ericsson.se> <192cffa8-1760-67f4-cc53-3ed16848ebd2@nostrum.com> <087A34937E64E74E848732CFF8354B92197696BD@ESESSMB101.ericsson.se> From: "A. Jean Mahoney" Message-ID: Date: Mon, 18 Jul 2016 14:13:09 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <087A34937E64E74E848732CFF8354B92197696BD@ESESSMB101.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 19:13:20 -0000 Hi Maria, OK, I see your point. I keep thinking that since DNS is so cool everyone would use it... On 7/18/16 2:25 AM, Maria Cruz Bartolome wrote: > MCRUZ 2> The issue is to be able to provide a LOAD value that allows > the client to perform load distribution. If we do not take the weight > into account, somehow (implementation dependent), the distribution > will be very far from even, it may cause very important traffic > oscillations (e.g. small servers will appear as low loaded but if > traffic is sent towards then they may reach overload threshold very > soon) and big server will normally be underutilized. Therefore, the > expected load distribution is far from being achieved. In section 5, the implementer is told to find server capacity via the DNS SRV query and then use it to calculate load: The goal is make it possible to use both the load values received as a part of the Diameter Load mechanism and weight values received as a result of a DNS SRV query. As a result, the Diameter load value has a range of 0-65535. This value and DNS SRV weight values are then used in a distribution algorithm similar to that specified in [RFC2782]. But what if the Diameter node does NOT use DNS [1]? According to RFC 6733, Section 5.2, DNS is "MUST be supported" but only "MAY be used". So where does the peer get the weight information if all of its connections are manually configured? I guess weights could be manually configured, but that becomes difficult to maintain as peers are upgraded. So the question becomes: Do we make use of DNS a MUST for this solution, or do we have reporting peers include capacity in their load reports? Thanks! Jean [1] I've seen large-scale deployments with only manual configuration for all Diameter connections, with no DNS servers in the network. From nobody Mon Jul 18 18:15:05 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404C412DBC4 for ; Mon, 18 Jul 2016 18:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFnsUS-X6oG9 for ; Mon, 18 Jul 2016 18:15:02 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E2112DBC2 for ; Mon, 18 Jul 2016 18:15:01 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.294.0; Mon, 18 Jul 2016 21:14:59 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0294.000; Mon, 18 Jul 2016 21:14:59 -0400 From: Dave Dolson To: "Gardella, Maryse (Nokia - FR)" , "jouni.nospam@gmail.com" , "dime@ietf.org" Thread-Topic: [Dime] RFC4006bis pre-meeting in Berlin Thread-Index: AQHR2GMPx5pEPgLOcUe3HOvnM/mSFKAerbOAgABXdRc= Date: Tue, 19 Jul 2016 01:14:58 +0000 Message-ID: <20160719011457.5697618.45799.98220@sandvine.com> References: <067bc372-46f1-22de-1e90-6a30ab126196@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] RFC4006bis pre-meeting in Berlin X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 01:15:04 -0000 Yes, see the map in reception. Original Message From: Gardella, Maryse (Nokia - FR) Sent: Monday, July 18, 2016 6:02 PM To: jouni.nospam@gmail.com; dime@ietf.org Subject: Re: [Dime] RFC4006bis pre-meeting in Berlin Hi, I could not find the "Tegel" Room on the PDF floor Plan available under the= IETF meeting webpage. Can this room be easily found once arriving in the Meeting Hotel? Thanks Maryse -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: jeudi 7 juillet 2016 17:20 To: dime@ietf.org Subject: [Dime] RFC4006bis pre-meeting in Berlin Folks, For those interested in RFC4006bis work we are going to have a side meeting= during the IETF96 week before the Dime WG meeting. Details below: Meeting Name: Diameter CCbis (RFC4006bis) Assigned Room: Tegel Assigned Date: 07/18/2016 (Monday) Assigned Start Time: 20:15:00 Assigned End Time: 22:00:00 This is an informal meeting. - Jouni & Lionel _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Tue Jul 19 00:19:16 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EBD12DC79 for ; Tue, 19 Jul 2016 00:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia94csDRu9v7 for ; Tue, 19 Jul 2016 00:18:54 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28C1612D100 for ; Tue, 19 Jul 2016 00:18:54 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 43E909E0DA212; Tue, 19 Jul 2016 07:18:50 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6J7IpMJ024382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2016 07:18:52 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6J7IfaU000351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Jul 2016 09:18:51 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.32]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 19 Jul 2016 09:18:48 +0200 From: "Trottin, Jean-Jacques (Nokia - FR)" To: Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] WGLC #1 for draft-ietf-dime-load-02 Thread-Index: AQHRtdE4tMkqClz2NEuuQj0gjsd2sp/qPcJQgAnlegCAAXp7AIAHXWgAgAOaJgCAADIrgIABPp8ggAAIp4CAB5znIIADJcoAgAnFkrCAATPWAIAG/7gg Date: Tue, 19 Jul 2016 07:18:47 +0000 Message-ID: References: <5b31616d-efa3-ac03-8f1c-bd8883a35d65@gmail.com> <087A34937E64E74E848732CFF8354B9219758407@ESESSMB101.ericsson.se> <3e2082d80d8e45caaca581c9dcc98468@CSRRDU1EXM025.corp.csra.com> <71796571-c370-cae8-d456-9d2dfb02544c@usdonovans.com> <087A34937E64E74E848732CFF8354B921975C3F4@ESESSMB101.ericsson.se> <71ffc339-37e0-e4fd-a16e-59da7fe23b6d@usdonovans.com> <087A34937E64E74E848732CFF8354B921975E5AB@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B921975E824@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B921975F63B@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9219761871@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B9219761871@ESESSMB101.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 07:19:14 -0000 Hi MCruz=20 I continued to investigate your inputs; I am sorry but I still have issue= s with your analysis and proposal. We have to be careful on the definitions to put in the draft. In the curren= t v2 draft we have: - a definition in section 2 indicating the "relative capacity" of a node.=20 - the Load-Value AVP (section 7.3) conveying "relative load information" wi= th a 0-65535 value range, value O corresponding to a fully loaded node and = 65535 to a node having no load=20 Dynamic Load (say DL) that you defined in % (100% is totally loaded) for ea= sier calculations in a previous mail is equivalent to the above defined loa= d although some difference in their value definition so in line with the cu= rrent draft. Then, you want to consider servers with different capacities (and I agree t= hat the Load control mechanism covers this case); so you proposed to introd= uce a "LOAD value that identifies the same amount of available capacity reg= ardless the server that has calculate it ". For this you introduced the RDL= =3D DL/ Weight with the intent to have a load per "resource unit", but th= is RDL is not for me rightly defined and does not work (as shown in my prev= ious mail) given that if a server comprising several resource units having = a global DL of 40% , this means that each resource units in average also h= as a 40% load. I do not think you can divide a DL by a weight. So I do not yet identify how you evaluate this new Load value. It is import= ant that the server sending this info and the traffic sender give the same = meaning to this new Load value. You need to do some proposals/ examples on= this calculation, and how you fulfill the load balancing objective. =20 So I still remain on the current Load definition of the V2 draft and weight= s (eg obtained by DNS), allowing each sender to evolve its traffic distribu= tion towards a load balancing objective. I even described two possible obje= ctives in a previous mail for the sender (according to operator policy): - one ensuring each server to have the same proportion of available capacit= y compared to its size (in fact to converge to the same DL). - one ensuring each server to have the same available capacity independentl= y of its size (your use case). To note that when the overall traffic increases, the two above objectives w= ill consume the capacities of all servers before entering in overload, whic= h can also be an objective of the Load Control mechanism. Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo= me Envoy=E9=A0: jeudi 14 juillet 2016 10:45 =C0=A0: Trottin, Jean-Jacques (Nokia - FR); dime@ietf.org Objet=A0: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02 Hello JJacques, Thanks for your analysis.=20 I checked this through and I agree the proposal I made of a possible RDL ca= lculation may not be providing the selection of the least loaded server in = all cases, the examples you made are very good to understand that. However, the concern behind keeps being perfectly valid, I think we need to= provide not the DL as such, but a value that takes into account the differ= ent servers' weights, in order to be able to compare the amount of free res= ources, that is, the capability of different servers to deal with traffic. In case we have servers with different weights (what is the most common sce= nario), both may be 50% loaded (DL), and this value is not useful for the = client to be able to perform load balancing. If a server has 4 times more r= esources than the other, obviously that server has more free resources and = it will be able to deal with more traffic. Therefore, my concern is that D= L does not provide enough information for the client to be able to perform = load balancing, that is the ultimate expectation of this mechanism. We need= a "relative" DL, taking into account servers' weights. Then, I would say that my proposal below keeps being valid. We need to reflect in the draft that the LOAD provided should be the relati= ve available load, taking into account the static weight. This is the only = way we are providing a load value that can possibly be used by a client to = LOAD-balance.=20 I agree that we leave the way to do so up to implementations. Proposal: "LOAD should be calculated in a way that reflects the available l= oad independently of the weight of each server, in order to allow the Diame= ter node that performs server selection to accurately compare values from d= ifferent servers, i.e. LOAD value identifies the same amount of available c= apacity, regardless the server that has calculate it. " =09 Let me know if you could agree with these conclusions, or if you have a dif= ferent view. Thanks /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Trottin, Jean-Jacque= s (Nokia - FR) Sent: mi=E9rcoles, 13 de julio de 2016 16:34 To: dime@ietf.org Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02 Hi MCruz, all, Thanks for your feedback.=20 I still have some understanding issues See comments to your last reflections. Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo= me Envoy=E9=A0: jeudi 7 juillet 2016 11:10 =C0=A0: Trottin, Jean-Jacques (N= okia - FR); dime@ietf.org Objet=A0: Re: [Dime] WGLC #1 for draft-ietf-dime-= load-02 Hello JJacques, all, See comments only to your last reflections. Best regards /MCruz =3D=3D=3D=3D=3D=3D from previous emails (begin) =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 5. > Now > The goal is make it possible to use both the load values received as > a part of the Diameter Load mechanism and weight values received as = a > result of a DNS SRV query. As a result, the Diameter load value has > a range of 0-65535. This value and DNS SRV weight values are then > used in a distribution algorithm similar to that specified in > [RFC2782]. > > Comments: > In order to have an efficient load balancing algorithm, it is not enough = for the reacting node (for the node in charge of load balancing) to know th= e Load of each server, but it needs to know the load in relation to each se= rver capacity. Unless we do so, the Load value of a server can't be compare= d with the Load of a Server with a different weight. > Then, in my opinion, we need to find a way to provide a Load value that i= s in fact comparable with the rest of the Load values of the servers in the= group. > Reflecting a bit longer on this, I think we need then to define a group o= f servers in the load-balancing group, like a load-balancing context, and t= hen, for all servers in such a group we need to provide a relative value of= dynamic Load. > > Agree with the thought- if "Little Server" is 30% utilized and=20 > "Big Server" is 50% utilized, it still makes sense to send more=20 > traffic to Big Server. But I am not sure if that is withn the scope=20 > of this document. > SRD> I don't understand the concern. The load values supplied will be > input into the route selection algorithm as specified in RFC2782. If=20 > a node isn't getting enough traffic it will change its load value to a=20 > lower value and will start getting more traffic. > MCRUZ> Unless the LOAD info provided is in fact a value that represents t= he available capacity, then the load balancing will not select the less loa= ded server. Being able to select the less loaded server is the whole purpos= e of this mechanism, then we need to find a way to provide a LOAD value fro= m different servers that we are able to compare, i.e. the value provide mus= t indicate the available capacity regardless the static capacity of each se= rver. SRD> I view the goal of this a little differently. The goal is to make sure that requests are delivered to nodes with available capacity. It is n= ot strictly necessary that every request goes to the least loaded node. MCRUZ> Well, I do not agree. The whole purpose of providing LOAD info is to= be able to choose a node with available load (I agree), but among the nod= e with available load we need to choose the least loaded (or one of the lea= st loaded). It does not make sense, in my opinion, to simply select a node = with available load, when we are providing info about load. The information= provided should be valid to be able to select the least (or close to) load= ed. > Providing an example, let me use dynamic Load (say DL) in % (100% is tota= lly loaded) that I found it easier for calculation: > - Server1: weight=3D1500; DL=3D 2% > - Server2: weight=3D55000; DL=3D 70% > Then, if we only use DL in the LB algorithm, obviously Server 1 seems to = be clearly less loaded, but however, taking into account its weight is much= smaller it may be the other way around. In fact, if traffic is redirected = to this server, it may get overloaded rapidly (due to its small capacity). > One possible way to calculate the relative DL is to divide it by the wei= ght, then for this example: > - Server1 RDL=3D 10000 * (2/1500) =3D 13.33 > - Server2 RDL=3D 10000 * (70/55000) =3D 12.73 (I multiplied by 10000=20 > simply to get rid of the decimals for our discussion). > Then, we actually find out that available load for both servers is pretty= similar. In fact, in this case, a correct load balancing should select Ser= ver2 as the less loaded server instead of server1. > My proposal is to consider this reflection in the draft, and then make a = clear distinction between dynamic load (DL) and RELATIVE DL. We need to pro= vide the RDL in the message, not DL. SRD> This is about how the load value is calculated which is explicitly stated as being an implementation decision. MCRUZ> Not exactly. We need to reflect in the draft that the LOAD provided = should be the relative available load, taking into account the static weigh= t. This is the only way we are providing a load value that can possibly be = used by a client to LOAD-balance.=20 I could accept that we leave the way to do so up to implementations. Proposal: "LOAD should be calculated in a way that reflects the available l= oad independently of the weight of each server, in order to allow the Diame= ter node that performs server selection to accurateraly compare values from= different servers, i.e. LOAD value identifies the same amount of available= capacity, regardless the server that has calculate it. " JJ2> I analysed a bit more your example with Server1 RDL=3D 10000 * JJ2> (2/1500) =3D 13.33 and Server2 RDL=3D 10000 * (70/55000) =3D 12.73 wit= h=20 JJ2> the conclusion to select server2. This is a bit surprising as=20 JJ2> server 1 is only 2% loaded. This example is rather specific with a=20 JJ2> server 1 weight being 2,7% of server 2 weight. I did another=20 JJ2> example with less difference in the weights - Server1: weight=3D30000; DL=3D 30% - Server2: weight=3D60000; DL=3D 50% This drives to Server1 RDL=3D 10000 * (30/30000) =3D 10,0 Server2 RDL=3D 10000 * (50/60000) =3D 8,3 =20 Here also, if I follow your reasoning, this would drive to select server 2 = to increase its RDL. Again the result is to increase server2 load Even by taking a 80% load for server 2 (so a high load in practice) and 50%= for server 1 Server1 RDL=3D 10000 * (50/30000) =3D 16,7 Server2 RDL=3D 10000 * (80/60000) =3D 13,3 This still drives to select server 2, although the reasoning would be to in= crease server 1 load Nevertheless, if server 1 has only 30% load its RDL b= ecomes 10 and it will be selected, so here OK =20 Please check if I am wrong somewhere, but currently RDL, for me, can give = strange outputs. About static weight I agree that static weight can be useful, e.g. a last h= op DA can be configured with the server weight to distribute its traffic a= mong the servers it is connected to. =20 My point is about the targeted load balance between the servers. Often, the= objective is to have the same load among servers (even if they have some d= ifference in their capacity / weight), which is the way to maximize the tra= ffic without entering overload in any server. So the "DL" (as defined in th= e current draft) indicates whether they have the same load, and if the obje= ctive is achieved. For me I do not well see how you define the targeted loa= d among servers with the RDL you mentioned. If received load from servers is not the same, the sending node has to sen= d a bit more traffic to the less loaded node. For this, as you said, an obj= ective is to avoid oscillations, and sending node has to evaluate the amoun= t of traffic it will switch from the more loaded server to the less loaded = server, this switched traffic being not too high to avoid oscillations and = also not too low to avoid maintaining unbalanced situation. In the draft, i= t is left to implementation on the sending node on how to modify the curren= t traffic distribution among the servers according to the received load (DL= ), and I am OK on this. In my previous mail I indicated that the sending n= ode will adjust its traffic distribution according to the updated load (DL)= received from server and converge to the balanced situation, in this proce= ss, I agree that the weight attached to each server can be an additional us= eful input when available, but keeping the current load (DL) definition =3D=3D=3D=3D=3D=3D from previous emails (end) =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D About the examples you discussed above.=20 I think the results you got are valid. Take into account that the static we= ight identifies the server capability, then a server1 with weight:60000 has= double resources than a server2 with 30000. Then, server2 45% load is maki= ng usage of double of resources than server1 90% load. DL/Weight provides a value than indicates the load per "resource unit". The= n, the least loaded server is the one that has less load per "resource unit= ". This can be seen in the following example: Server1 RDL=3D 10000 * (45/30000) =3D 15 Server2 RDL=3D 10000 * (90/60000) =3D 15 Both servers are equally loaded, as long as the Big Server (Server2) is loa= ded double as the Small Server (Server1), that is half size in resources th= an Big Server. Then, JJacques, I think we agree the Diameter node that is responsible for = server selection should have the means to select the least loaded server, a= nd the available load depends on the capacity of each node, not only on the= DL that is identified at a moment in time. Then, I think we need to include some normative text on that, although the = specific means to achieve so could remain implementation specific. Proposed= text is: "LOAD should be calculated in a way that reflects the available load indepe= ndently of the weight of each server, in order to allow the Diameter node t= hat performs server selection to accurately compare values from different s= ervers, i.e. LOAD value identifies the same amount of available capacity, r= egardless the server that has calculate it. The means to calculate the LOA= D value that fulfils this requirement are implementation specific." I think, as Steve agreed, that the example could be included in the draft a= s well, it is very useful to understand how the static weight determines th= e available load. I analysed your above new example which raises same questioning from = my side: By applying the factor 10000 for simplification we have=20 Server1 weight 6 so I can say that Server1 has a capacity of 6 resource u= nits =20 Server2 weight 3 so a capacity of 3 resource units. Server1 load (DL)=3D 90% so Server 1 consumed resource units=3D 6x90% =3D 5= ,4 Server2 load (DL)=3D 45% so Server 2 consumed resource units=3D 3x45% =3D 1= ,65 Then Server1 remaining (available) resources=3D 6-5,4 =3D 0,6 Server2 remaining (available) resources=3D 3-1,35 =3D 1,65=20 So in my understanding server2 (the smaller server) has still more availabl= e capacity than server 1, so I would conclude to transfer some traffic from= server 1 to server 2; But you said that both servers are equally loadedas= having the same RDL=3D15, and concluded the system being well balanced, wh= ich I do not agree You also mention that we should have the "same load per resource unit", whi= ch also raises questioning from me: If Server1 has a load of 90% for its 6 resource units, this also means that= each resource unit has a load of 90%.=20 I have difficulty to understand the definition of RDL =3D DL/Weight So I th= ink we are not yet well aligned on a common understanding of the example, s= o thanks if you can give still some more explanation. I continued the same exercise but with my assumptions a) objective (according to my previous mail) is that the two servers have t= he same load, this drives to DL=3D75% with Server1 load (DL)=3D 75% so Server 1 consumed resource units=3D 75% =3D 4,5 Server2 load (DL)=3D 75% so Server 2 consumed resource units=3D 3x75% =3D 2= ,25 Then Server1 remaining resources=3D 6-4,5 =3D 1,75 Server2 remaining resources=3D 3-2,25 =3D 0,75 but the % of remaining resou= rces compare to its capacity is the same for each server b) another possible objective is that the two servers have the same remaini= ng (available) resource, , this drives to Server1 load (DL)=3D 81,3% so Server 1 consumed resource units=3D 6x81,3% = =3D 4,88 Server2 load (DL)=3D 62,4% so Server 2 consumed resource units=3D 3x62,4% = =3D 1,87=09 Then Server1 remaining resources=3D 6-4,88 =3D 1,12 Server2 remaining resources=3D 3-1,87 =3D 1,13 so same remaining resources Is this b) case relating more to your concern? The "least loaded" node woul= d be the one having the highest remaining capacity, so with traffic transfe= r to this node until both nodes have the same remaining capacity Other type of load balancing objectives may be considered, but load balanci= ng objectives are for me operator dependent and implementation specific. Then to come back to weights: - case a), as I said, according to received load from servers senders, a se= nder can adjust the traffic to converge to the same/nearly same load among = servers. The fact to know server weights would improve the convergence to t= his objective - Case b) needs to have knowledge on the server weights as this is needed t= o evaluate the remaining resources objectives As indicated, server weights can be configured (eg for DAs in front of serv= ers) or obtained from a DNS query (as Steve mentioned), or through other me= ans that are out of the scope. I would like we share the same understanding before finalizing a normative = text Best regards JJacques =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Tue Jul 19 01:00:58 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809A512D099 for ; Tue, 19 Jul 2016 01:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEPUGTCY_1Fv for ; Tue, 19 Jul 2016 01:00:53 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C26F12D09C for ; Tue, 19 Jul 2016 01:00:51 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-15-578dde313132 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 21.F8.18043.13EDD875; Tue, 19 Jul 2016 10:00:49 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.179]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0294.000; Tue, 19 Jul 2016 10:00:49 +0200 From: Maria Cruz Bartolome To: "Trottin, Jean-Jacques (Nokia - FR)" , "dime@ietf.org" Thread-Topic: [Dime] WGLC #1 for draft-ietf-dime-load-02 Thread-Index: AQHRtdE4jPBCVA2NJ0e3rvn8VsJS8Z/qPcJQgAnlegCAAXp7AIAHc18QgAOELwCAAE15MIABDQ4AgAA9q5CAB4YkgIADOjGQgAmsW4CAAU9Q4IAHpPOAgAAoZnA= Date: Tue, 19 Jul 2016 08:00:48 +0000 Message-ID: <087A34937E64E74E848732CFF8354B921976CB78@ESESSMB101.ericsson.se> References: <5b31616d-efa3-ac03-8f1c-bd8883a35d65@gmail.com> <087A34937E64E74E848732CFF8354B9219758407@ESESSMB101.ericsson.se> <3e2082d80d8e45caaca581c9dcc98468@CSRRDU1EXM025.corp.csra.com> <71796571-c370-cae8-d456-9d2dfb02544c@usdonovans.com> <087A34937E64E74E848732CFF8354B921975C3F4@ESESSMB101.ericsson.se> <71ffc339-37e0-e4fd-a16e-59da7fe23b6d@usdonovans.com> <087A34937E64E74E848732CFF8354B921975E5AB@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B921975E824@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B921975F63B@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9219761871@ESESSMB101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbHdT9fwXm+4wfKNhhZze1ewWXQcmM3i wOSxZMlPJo+7ty4xBTBFcdmkpOZklqUW6dslcGV87tnAUvBjA2PF5CUz2BsYN/QxdjFyckgI mEg8vreHHcIWk7hwbz1bFyMXh5DAEUaJi72zGSGcJYwSdw/1M4FUsQnYSVw6/QLMFhHIkXh/ dQ0LiC0sYC7RevgyVNxC4vPpQ8wgzSICXYwSZ//tYANJsAioStxcsx6ogYODV8BXYt5bHYgF F9klHi/ezAxSwykQK9H34hUriM0IdNL3U2vAhjILiEvcejKfCeJUAYkle84zQ9iiEi8f/2OF sJUkFt3+DFWvJ3Fj6hQ2CFtbYtnC12D1vAKCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG 0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwHg5uOW31Q7Gg88dDzEKcDAq8fAqSPaGC7EmlhVX 5h5ilOBgVhLh5bkLFOJNSaysSi3Kjy8qzUktPsQozcGiJM7r/1IxXEggPbEkNTs1tSC1CCbL xMEp1cAoeP4Vw/n7y7NiciuNklNYTXROyPQ6LZSO+2rRx6fYuYPV8PfT7ZNFa3jrlqw2eRzS njHh2tStN84dta3/qK/CPpsz1XlRnlrOk7d5XqWHKt4d1vSdc3h3QLWApEFA9PcZhXwTn5pV HvF0XNSha3WHvXyjkuTe65XLEx75MAiemamkaHx/Y74SS3FGoqEWc1FxIgDhbdLrkwIAAA== Archived-At: Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 08:00:56 -0000 Hello JJacques, In relation to the objectives you mentioned in the email, I think we need t= o be able to select servers according to the available capacity, this is wh= at a load balancing is about in my opinion, then it is specifically related= to your objective: "- one ensuring each server to have the same available capacity independe= ntly of its size (your use case)." I think there are important drawbacks if the client selects servers without= taking into account the real available capacity, as I explained before: "the distribution will be very far from even, it may cause very important t= raffic oscillations (e.g. small servers will appear as low loaded but if tr= affic is sent towards then they may reach overload threshold very soon) and= big server will normally be underutilized.". It is easy to understand tha= t a big server in a pool where there as smaller servers will be underutili= zed, since even if it is 70% (e.g.) loaded, it may not be then selected (in= front of other having e.g. 50%), but the available capacity of that big se= rver is much bigger. If traffic is moved towards small servers, when they a= re considered to be low loaded, then the traffic will increase rapidly towa= rds then, and since the real capacity is very small (since they are small s= ervers), then they will get into high load level very easily, even it is po= ssible to push then into overload, depending on how fast the load balancing= algorithm is adjusted. About the RDL, I used that term to ease explanation, in order to explain th= at we need to define that the Load calculated by each server should not be = used without taking into account the weight of each server in comparison wi= th the rest of servers in the pool. =20 You mentioned, and I agreed, that we should not limit implementations, ther= efore the calculation should remain application independent. As long as the= Load value takes into account servers' weight (RDL).=20 Therefore, the key point is to define clearly that LOAD value to be used in= the load-balancing should take into account servers' weight.=20 In order to cover that, I proposed following sentence, that I will copy her= e again. I would appreciate if you could provide comments to the sentence i= tself, in order to get a common agreement: "LOAD should be calculated in a way that reflects the available load indepe= ndently of the weight of each server, in order to allow the Diameter node t= hat performs server selection to accurately compare values from different s= ervers, i.e. LOAD value identifies the same amount of available capacity, r= egardless the server that has calculate it. The means to calculate the LOA= D value that fulfils this requirement are implementation specific." Best regards /MCruz -----Original Message----- From: Trottin, Jean-Jacques (Nokia - FR) [mailto:jean-jacques.trottin@nokia= .com]=20 Sent: martes, 19 de julio de 2016 9:19 To: Maria Cruz Bartolome; dime@ietf.org Subject: RE: [Dime] WGLC #1 for draft-ietf-dime-load-02 Hi MCruz=20 I continued to investigate your inputs; I am sorry but I still have issue= s with your analysis and proposal. We have to be careful on the definitions to put in the draft. In the curren= t v2 draft we have: - a definition in section 2 indicating the "relative capacity" of a node.=20 - the Load-Value AVP (section 7.3) conveying "relative load information" wi= th a 0-65535 value range, value O corresponding to a fully loaded node and = 65535 to a node having no load=20 Dynamic Load (say DL) that you defined in % (100% is totally loaded) for ea= sier calculations in a previous mail is equivalent to the above defined loa= d although some difference in their value definition so in line with the cu= rrent draft. Then, you want to consider servers with different capacities (and I agree t= hat the Load control mechanism covers this case); so you proposed to introd= uce a "LOAD value that identifies the same amount of available capacity reg= ardless the server that has calculate it ". For this you introduced the RDL= =3D DL/ Weight with the intent to have a load per "resource unit", but th= is RDL is not for me rightly defined and does not work (as shown in my prev= ious mail) given that if a server comprising several resource units having = a global DL of 40% , this means that each resource units in average also h= as a 40% load. I do not think you can divide a DL by a weight. So I do not yet identify how you evaluate this new Load value. It is import= ant that the server sending this info and the traffic sender give the same = meaning to this new Load value. You need to do some proposals/ examples on= this calculation, and how you fulfill the load balancing objective. =20 So I still remain on the current Load definition of the V2 draft and weight= s (eg obtained by DNS), allowing each sender to evolve its traffic distribu= tion towards a load balancing objective. I even described two possible obje= ctives in a previous mail for the sender (according to operator policy): - one ensuring each server to have the same proportion of available capacit= y compared to its size (in fact to converge to the same DL). - one ensuring each server to have the same available capacity independentl= y of its size (your use case). To note that when the overall traffic increases, the two above objectives w= ill consume the capacities of all servers before entering in overload, whic= h can also be an objective of the Load Control mechanism. Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo= me Envoy=E9=A0: jeudi 14 juillet 2016 10:45 =C0=A0: Trottin, Jean-Jacques (= Nokia - FR); dime@ietf.org Objet=A0: Re: [Dime] WGLC #1 for draft-ietf-dime= -load-02 Hello JJacques, Thanks for your analysis.=20 I checked this through and I agree the proposal I made of a possible RDL ca= lculation may not be providing the selection of the least loaded server in = all cases, the examples you made are very good to understand that. However, the concern behind keeps being perfectly valid, I think we need to= provide not the DL as such, but a value that takes into account the differ= ent servers' weights, in order to be able to compare the amount of free res= ources, that is, the capability of different servers to deal with traffic. In case we have servers with different weights (what is the most common sce= nario), both may be 50% loaded (DL), and this value is not useful for the = client to be able to perform load balancing. If a server has 4 times more r= esources than the other, obviously that server has more free resources and = it will be able to deal with more traffic. Therefore, my concern is that D= L does not provide enough information for the client to be able to perform = load balancing, that is the ultimate expectation of this mechanism. We need= a "relative" DL, taking into account servers' weights. Then, I would say that my proposal below keeps being valid. We need to reflect in the draft that the LOAD provided should be the relati= ve available load, taking into account the static weight. This is the only = way we are providing a load value that can possibly be used by a client to = LOAD-balance.=20 I agree that we leave the way to do so up to implementations. Proposal: "LOAD should be calculated in a way that reflects the available l= oad independently of the weight of each server, in order to allow the Diame= ter node that performs server selection to accurately compare values from d= ifferent servers, i.e. LOAD value identifies the same amount of available c= apacity, regardless the server that has calculate it. " =09 Let me know if you could agree with these conclusions, or if you have a dif= ferent view. Thanks /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Trottin, Jean-Jacque= s (Nokia - FR) Sent: mi=E9rcoles, 13 de julio de 2016 16:34 To: dime@ietf.org Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02 Hi MCruz, all, Thanks for your feedback.=20 I still have some understanding issues See comments to your last reflections. Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo= me Envoy=E9=A0: jeudi 7 juillet 2016 11:10 =C0=A0: Trottin, Jean-Jacques (N= okia - FR); dime@ietf.org Objet=A0: Re: [Dime] WGLC #1 for draft-ietf-dime-= load-02 Hello JJacques, all, See comments only to your last reflections. Best regards /MCruz =3D=3D=3D=3D=3D=3D from previous emails (begin) =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 5. > Now > The goal is make it possible to use both the load values received as > a part of the Diameter Load mechanism and weight values received as = a > result of a DNS SRV query. As a result, the Diameter load value has > a range of 0-65535. This value and DNS SRV weight values are then > used in a distribution algorithm similar to that specified in > [RFC2782]. > > Comments: > In order to have an efficient load balancing algorithm, it is not enough = for the reacting node (for the node in charge of load balancing) to know th= e Load of each server, but it needs to know the load in relation to each se= rver capacity. Unless we do so, the Load value of a server can't be compare= d with the Load of a Server with a different weight. > Then, in my opinion, we need to find a way to provide a Load value that i= s in fact comparable with the rest of the Load values of the servers in the= group. > Reflecting a bit longer on this, I think we need then to define a group o= f servers in the load-balancing group, like a load-balancing context, and t= hen, for all servers in such a group we need to provide a relative value of= dynamic Load. > > Agree with the thought- if "Little Server" is 30% utilized and=20 > "Big Server" is 50% utilized, it still makes sense to send more=20 > traffic to Big Server. But I am not sure if that is withn the scope=20 > of this document. > SRD> I don't understand the concern. The load values supplied will be > input into the route selection algorithm as specified in RFC2782. If=20 > a node isn't getting enough traffic it will change its load value to a=20 > lower value and will start getting more traffic. > MCRUZ> Unless the LOAD info provided is in fact a value that represents t= he available capacity, then the load balancing will not select the less loa= ded server. Being able to select the less loaded server is the whole purpos= e of this mechanism, then we need to find a way to provide a LOAD value fro= m different servers that we are able to compare, i.e. the value provide mus= t indicate the available capacity regardless the static capacity of each se= rver. SRD> I view the goal of this a little differently. The goal is to make sure that requests are delivered to nodes with available capacity. It is n= ot strictly necessary that every request goes to the least loaded node. MCRUZ> Well, I do not agree. The whole purpose of providing LOAD info is to= be able to choose a node with available load (I agree), but among the nod= e with available load we need to choose the least loaded (or one of the lea= st loaded). It does not make sense, in my opinion, to simply select a node = with available load, when we are providing info about load. The information= provided should be valid to be able to select the least (or close to) load= ed. > Providing an example, let me use dynamic Load (say DL) in % (100% is tota= lly loaded) that I found it easier for calculation: > - Server1: weight=3D1500; DL=3D 2% > - Server2: weight=3D55000; DL=3D 70% > Then, if we only use DL in the LB algorithm, obviously Server 1 seems to = be clearly less loaded, but however, taking into account its weight is much= smaller it may be the other way around. In fact, if traffic is redirected = to this server, it may get overloaded rapidly (due to its small capacity). > One possible way to calculate the relative DL is to divide it by the wei= ght, then for this example: > - Server1 RDL=3D 10000 * (2/1500) =3D 13.33 > - Server2 RDL=3D 10000 * (70/55000) =3D 12.73 (I multiplied by 10000=20 > simply to get rid of the decimals for our discussion). > Then, we actually find out that available load for both servers is pretty= similar. In fact, in this case, a correct load balancing should select Ser= ver2 as the less loaded server instead of server1. > My proposal is to consider this reflection in the draft, and then make a = clear distinction between dynamic load (DL) and RELATIVE DL. We need to pro= vide the RDL in the message, not DL. SRD> This is about how the load value is calculated which is explicitly stated as being an implementation decision. MCRUZ> Not exactly. We need to reflect in the draft that the LOAD provided = should be the relative available load, taking into account the static weigh= t. This is the only way we are providing a load value that can possibly be = used by a client to LOAD-balance.=20 I could accept that we leave the way to do so up to implementations. Proposal: "LOAD should be calculated in a way that reflects the available l= oad independently of the weight of each server, in order to allow the Diame= ter node that performs server selection to accurateraly compare values from= different servers, i.e. LOAD value identifies the same amount of available= capacity, regardless the server that has calculate it. " JJ2> I analysed a bit more your example with Server1 RDL=3D 10000 * JJ2> (2/1500) =3D 13.33 and Server2 RDL=3D 10000 * (70/55000) =3D 12.73 wit= h=20 JJ2> the conclusion to select server2. This is a bit surprising as=20 JJ2> server 1 is only 2% loaded. This example is rather specific with a=20 JJ2> server 1 weight being 2,7% of server 2 weight. I did another=20 JJ2> example with less difference in the weights - Server1: weight=3D30000; DL=3D 30% - Server2: weight=3D60000; DL=3D 50% This drives to Server1 RDL=3D 10000 * (30/30000) =3D 10,0 Server2 RDL=3D 10000 * (50/60000) =3D 8,3 =20 Here also, if I follow your reasoning, this would drive to select server 2 = to increase its RDL. Again the result is to increase server2 load Even by taking a 80% load for server 2 (so a high load in practice) and 50%= for server 1 Server1 RDL=3D 10000 * (50/30000) =3D 16,7 Server2 RDL=3D 10000 * (80/60000) =3D 13,3 This still drives to select server 2, although the reasoning would be to in= crease server 1 load Nevertheless, if server 1 has only 30% load its RDL b= ecomes 10 and it will be selected, so here OK =20 Please check if I am wrong somewhere, but currently RDL, for me, can give = strange outputs. About static weight I agree that static weight can be useful, e.g. a last h= op DA can be configured with the server weight to distribute its traffic a= mong the servers it is connected to. =20 My point is about the targeted load balance between the servers. Often, the= objective is to have the same load among servers (even if they have some d= ifference in their capacity / weight), which is the way to maximize the tra= ffic without entering overload in any server. So the "DL" (as defined in th= e current draft) indicates whether they have the same load, and if the obje= ctive is achieved. For me I do not well see how you define the targeted loa= d among servers with the RDL you mentioned. If received load from servers is not the same, the sending node has to sen= d a bit more traffic to the less loaded node. For this, as you said, an obj= ective is to avoid oscillations, and sending node has to evaluate the amoun= t of traffic it will switch from the more loaded server to the less loaded = server, this switched traffic being not too high to avoid oscillations and = also not too low to avoid maintaining unbalanced situation. In the draft, i= t is left to implementation on the sending node on how to modify the curren= t traffic distribution among the servers according to the received load (DL= ), and I am OK on this. In my previous mail I indicated that the sending n= ode will adjust its traffic distribution according to the updated load (DL)= received from server and converge to the balanced situation, in this proce= ss, I agree that the weight attached to each server can be an additional us= eful input when available, but keeping the current load (DL) definition =3D=3D=3D=3D=3D=3D from previous emails (end) =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D About the examples you discussed above.=20 I think the results you got are valid. Take into account that the static we= ight identifies the server capability, then a server1 with weight:60000 has= double resources than a server2 with 30000. Then, server2 45% load is maki= ng usage of double of resources than server1 90% load. DL/Weight provides a value than indicates the load per "resource unit". The= n, the least loaded server is the one that has less load per "resource unit= ". This can be seen in the following example: Server1 RDL=3D 10000 * (45/30000) =3D 15 Server2 RDL=3D 10000 * (90/60000) =3D 15 Both servers are equally loaded, as long as the Big Server (Server2) is loa= ded double as the Small Server (Server1), that is half size in resources th= an Big Server. Then, JJacques, I think we agree the Diameter node that is responsible for = server selection should have the means to select the least loaded server, a= nd the available load depends on the capacity of each node, not only on the= DL that is identified at a moment in time. Then, I think we need to include some normative text on that, although the = specific means to achieve so could remain implementation specific. Proposed= text is: "LOAD should be calculated in a way that reflects the available load indepe= ndently of the weight of each server, in order to allow the Diameter node t= hat performs server selection to accurately compare values from different s= ervers, i.e. LOAD value identifies the same amount of available capacity, r= egardless the server that has calculate it. The means to calculate the LOA= D value that fulfils this requirement are implementation specific." I think, as Steve agreed, that the example could be included in the draft a= s well, it is very useful to understand how the static weight determines th= e available load. I analysed your above new example which raises same questioning from = my side: By applying the factor 10000 for simplification we have=20 Server1 weight 6 so I can say that Server1 has a capacity of 6 resource u= nits =20 Server2 weight 3 so a capacity of 3 resource units. Server1 load (DL)=3D 90% so Server 1 consumed resource units=3D 6x90% =3D 5= ,4 Server2 load (DL)=3D 45% so Server 2 consumed resource units=3D 3x45% =3D 1= ,65 Then Server1 remaining (available) resources=3D 6-5,4 =3D 0,6 Server2 remaining (available) resources=3D 3-1,35 =3D 1,65=20 So in my understanding server2 (the smaller server) has still more availabl= e capacity than server 1, so I would conclude to transfer some traffic from= server 1 to server 2; But you said that both servers are equally loadedas= having the same RDL=3D15, and concluded the system being well balanced, wh= ich I do not agree You also mention that we should have the "same load per resource unit", whi= ch also raises questioning from me: If Server1 has a load of 90% for its 6 resource units, this also means that= each resource unit has a load of 90%.=20 I have difficulty to understand the definition of RDL =3D DL/Weight So I th= ink we are not yet well aligned on a common understanding of the example, s= o thanks if you can give still some more explanation. I continued the same exercise but with my assumptions a) objective (according to my previous mail) is that the two servers have t= he same load, this drives to DL=3D75% with Server1 load (DL)=3D 75% so Server 1 consumed resource units=3D 75% =3D 4,5 Server2 load (DL)=3D 75% so Server 2 consumed resource units=3D 3x75% =3D 2= ,25 Then Server1 remaining resources=3D 6-4,5 =3D 1,75 Server2 remaining resources=3D 3-2,25 =3D 0,75 but the % of remaining resou= rces compare to its capacity is the same for each server b) another possible objective is that the two servers have the same remaini= ng (available) resource, , this drives to Server1 load (DL)=3D 81,3% so Server 1 consumed resource units=3D 6x81,3% = =3D 4,88 Server2 load (DL)=3D 62,4% so Server 2 consumed resource units=3D 3x62,4% = =3D 1,87=09 Then Server1 remaining resources=3D 6-4,88 =3D 1,12 Server2 remaining resources=3D 3-1,87 =3D 1,13 so same remaining resources Is this b) case relating more to your concern? The "least loaded" node woul= d be the one having the highest remaining capacity, so with traffic transfe= r to this node until both nodes have the same remaining capacity Other type of load balancing objectives may be considered, but load balanci= ng objectives are for me operator dependent and implementation specific. Then to come back to weights: - case a), as I said, according to received load from servers senders, a se= nder can adjust the traffic to converge to the same/nearly same load among = servers. The fact to know server weights would improve the convergence to t= his objective - Case b) needs to have knowledge on the server weights as this is needed t= o evaluate the remaining resources objectives As indicated, server weights can be configured (eg for DAs in front of serv= ers) or obtained from a DNS query (as Steve mentioned), or through other me= ans that are out of the scope. I would like we share the same understanding before finalizing a normative = text Best regards JJacques =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Tue Jul 19 08:56:35 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4B212D686 for ; Tue, 19 Jul 2016 08:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUiB3G0QkCjB for ; Tue, 19 Jul 2016 08:56:31 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE4812DDCE for ; Tue, 19 Jul 2016 08:45:54 -0700 (PDT) Received: from [213.61.67.150] (port=44618 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bPXDP-003Mr4-DF for dime@ietf.org; Tue, 19 Jul 2016 08:45:53 -0700 To: dime@ietf.org References: <5b31616d-efa3-ac03-8f1c-bd8883a35d65@gmail.com> <3e2082d80d8e45caaca581c9dcc98468@CSRRDU1EXM025.corp.csra.com> <71796571-c370-cae8-d456-9d2dfb02544c@usdonovans.com> <087A34937E64E74E848732CFF8354B921975C3F4@ESESSMB101.ericsson.se> <71ffc339-37e0-e4fd-a16e-59da7fe23b6d@usdonovans.com> <087A34937E64E74E848732CFF8354B921975E5AB@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B921975E824@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B921975F63B@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9219761871@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B921976CB78@ESESSMB101.ericsson.se> From: Steve Donovan Message-ID: <83f3128d-a86e-ec7d-badf-16d15aaf423b@usdonovans.com> Date: Tue, 19 Jul 2016 17:45:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <087A34937E64E74E848732CFF8354B921976CB78@ESESSMB101.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 15:56:34 -0000 Maria Cruz, JJacques, Jean, Thanks for the good discussion. I haven't had a chance to respond but I = will soon. I need to work through a few scenarios that I hope to be=20 able to show that the SRV algorithm will work without knowledge of the=20 amount of remaining capacity. Steve On 7/19/16 10:00 AM, Maria Cruz Bartolome wrote: > Hello JJacques, > > In relation to the objectives you mentioned in the email, I think we ne= ed to be able to select servers according to the available capacity, this= is what a load balancing is about in my opinion, then it is specifically= related to your objective: > "- one ensuring each server to have the same available capacity inde= pendently of its size (your use case)." > > I think there are important drawbacks if the client selects servers wit= hout taking into account the real available capacity, as I explained befo= re: > "the distribution will be very far from even, it may cause very importa= nt traffic oscillations (e.g. small servers will appear as low loaded but= if traffic is sent towards then they may reach overload threshold very s= oon) and big server will normally be underutilized.". It is easy to unde= rstand that a big server in a pool where there as smaller servers will b= e underutilized, since even if it is 70% (e.g.) loaded, it may not be the= n selected (in front of other having e.g. 50%), but the available capacit= y of that big server is much bigger. If traffic is moved towards small se= rvers, when they are considered to be low loaded, then the traffic will i= ncrease rapidly towards then, and since the real capacity is very small (= since they are small servers), then they will get into high load level ve= ry easily, even it is possible to push then into overload, depending on h= ow fast the load balancing algorithm is adjusted. > > About the RDL, I used that term to ease explanation, in order to explai= n that we need to define that the Load calculated by each server should n= ot be used without taking into account the weight of each server in compa= rison with the rest of servers in the pool. > You mentioned, and I agreed, that we should not limit implementations, = therefore the calculation should remain application independent. As long = as the Load value takes into account servers' weight (RDL). > Therefore, the key point is to define clearly that LOAD value to be use= d in the load-balancing should take into account servers' weight. > In order to cover that, I proposed following sentence, that I will copy= here again. I would appreciate if you could provide comments to the sent= ence itself, in order to get a common agreement: > > "LOAD should be calculated in a way that reflects the available load in= dependently of the weight of each server, in order to allow the Diameter = node that performs server selection to accurately compare values from dif= ferent servers, i.e. LOAD value identifies the same amount of available c= apacity, regardless the server that has calculate it. The means to calcu= late the LOAD value that fulfils this requirement are implementation spec= ific." > > Best regards > /MCruz > > -----Original Message----- > From: Trottin, Jean-Jacques (Nokia - FR) [mailto:jean-jacques.trottin@n= okia.com] > Sent: martes, 19 de julio de 2016 9:19 > To: Maria Cruz Bartolome; dime@ietf.org > Subject: RE: [Dime] WGLC #1 for draft-ietf-dime-load-02 > > Hi MCruz > > I continued to investigate your inputs; I am sorry but I still have i= ssues with your analysis and proposal. > > We have to be careful on the definitions to put in the draft. In the cu= rrent v2 draft we have: > - a definition in section 2 indicating the "relative capacity" of a nod= e. > - the Load-Value AVP (section 7.3) conveying "relative load information= " with a 0-65535 value range, value O corresponding to a fully loaded nod= e and 65535 to a node having no load > > Dynamic Load (say DL) that you defined in % (100% is totally loaded) fo= r easier calculations in a previous mail is equivalent to the above defin= ed load although some difference in their value definition so in line wit= h the current draft. > > Then, you want to consider servers with different capacities (and I agr= ee that the Load control mechanism covers this case); so you proposed to = introduce a "LOAD value that identifies the same amount of available capa= city regardless the server that has calculate it ". For this you introduc= ed the RDL =3D DL/ Weight with the intent to have a load per "resource u= nit", but this RDL is not for me rightly defined and does not work (as sh= own in my previous mail) given that if a server comprising several resour= ce units having a global DL of 40% , this means that each resource units= in average also has a 40% load. I do not think you can divide a DL by a= weight. > So I do not yet identify how you evaluate this new Load value. It is im= portant that the server sending this info and the traffic sender give the= same meaning to this new Load value. You need to do some proposals/ exa= mples on this calculation, and how you fulfill the load balancing objecti= ve. > =20 > So I still remain on the current Load definition of the V2 draft and we= ights (eg obtained by DNS), allowing each sender to evolve its traffic di= stribution towards a load balancing objective. I even described two possi= ble objectives in a previous mail for the sender (according to operator p= olicy): > - one ensuring each server to have the same proportion of available cap= acity compared to its size (in fact to converge to the same DL). > - one ensuring each server to have the same available capacity independ= ently of its size (your use case). > > To note that when the overall traffic increases, the two above objectiv= es will consume the capacities of all servers before entering in overload= , which can also be an objective of the Load Control mechanism. > > Best regards > > JJacques > > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Barto= lome Envoy=E9 : jeudi 14 juillet 2016 10:45 =C0 : Trottin, Jean-Jacques (= Nokia - FR); dime@ietf.org Objet : Re: [Dime] WGLC #1 for draft-ietf-dime= -load-02 > > Hello JJacques, > > Thanks for your analysis. > I checked this through and I agree the proposal I made of a possible RD= L calculation may not be providing the selection of the least loaded serv= er in all cases, the examples you made are very good to understand that. > However, the concern behind keeps being perfectly valid, I think we nee= d to provide not the DL as such, but a value that takes into account the = different servers' weights, in order to be able to compare the amount of = free resources, that is, the capability of different servers to deal with= traffic. > In case we have servers with different weights (what is the most common= scenario), both may be 50% loaded (DL), and this value is not useful fo= r the client to be able to perform load balancing. If a server has 4 time= s more resources than the other, obviously that server has more free reso= urces and it will be able to deal with more traffic. Therefore, my conce= rn is that DL does not provide enough information for the client to be ab= le to perform load balancing, that is the ultimate expectation of this me= chanism. We need a "relative" DL, taking into account servers' weights. > > Then, I would say that my proposal below keeps being valid. > We need to reflect in the draft that the LOAD provided should be the re= lative available load, taking into account the static weight. This is the= only way we are providing a load value that can possibly be used by a cl= ient to LOAD-balance. > I agree that we leave the way to do so up to implementations. > Proposal: "LOAD should be calculated in a way that reflects the availab= le load independently of the weight of each server, in order to allow the= Diameter node that performs server selection to accurately compare value= s from different servers, i.e. LOAD value identifies the same amount of a= vailable capacity, regardless the server that has calculate it. " > =09 > Let me know if you could agree with these conclusions, or if you have a= different view. > Thanks > /MCruz > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Trottin, Jean-Ja= cques (Nokia - FR) > Sent: mi=E9rcoles, 13 de julio de 2016 16:34 > To: dime@ietf.org > Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02 > > Hi MCruz, all, > > Thanks for your feedback. > I still have some understanding issues > > See comments to your last reflections. > > Best regards > JJacques > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Barto= lome Envoy=E9 : jeudi 7 juillet 2016 11:10 =C0 : Trottin, Jean-Jacques (N= okia - FR); dime@ietf.org Objet : Re: [Dime] WGLC #1 for draft-ietf-dime-= load-02 > > Hello JJacques, all, > > See comments only to your last reflections. > Best regards > /MCruz > > > =3D=3D=3D=3D=3D=3D from previous emails (begin) =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >> 5. >> Now >> The goal is make it possible to use both the load values received= as >> a part of the Diameter Load mechanism and weight values received= as a >> result of a DNS SRV query. As a result, the Diameter load value= has >> a range of 0-65535. This value and DNS SRV weight values are th= en >> used in a distribution algorithm similar to that specified in >> [RFC2782]. >> >> Comments: >> In order to have an efficient load balancing algorithm, it is not enou= gh for the reacting node (for the node in charge of load balancing) to kn= ow the Load of each server, but it needs to know the load in relation to = each server capacity. Unless we do so, the Load value of a server can't b= e compared with the Load of a Server with a different weight. >> Then, in my opinion, we need to find a way to provide a Load value tha= t is in fact comparable with the rest of the Load values of the servers i= n the group. >> Reflecting a bit longer on this, I think we need then to define a grou= p of servers in the load-balancing group, like a load-balancing context, = and then, for all servers in such a group we need to provide a relative v= alue of dynamic Load. >> >> Agree with the thought- if "Little Server" is 30% utilized and >> "Big Server" is 50% utilized, it still makes sense to send more >> traffic to Big Server. But I am not sure if that is withn the scope >> of this document. >> SRD> I don't understand the concern. The load values supplied will be= >> input into the route selection algorithm as specified in RFC2782. If >> a node isn't getting enough traffic it will change its load value to a= >> lower value and will start getting more traffic. >> MCRUZ> Unless the LOAD info provided is in fact a value that represent= s the available capacity, then the load balancing will not select the les= s loaded server. Being able to select the less loaded server is the whole= purpose of this mechanism, then we need to find a way to provide a LOAD = value from different servers that we are able to compare, i.e. the value = provide must indicate the available capacity regardless the static capaci= ty of each server. > SRD> I view the goal of this a little differently. The goal is to make= > sure that requests are delivered to nodes with available capacity. It = is not strictly necessary that every request goes to the least loaded nod= e. > MCRUZ> Well, I do not agree. The whole purpose of providing LOAD info i= s to be able to choose a node with available load (I agree), but among t= he node with available load we need to choose the least loaded (or one of= the least loaded). It does not make sense, in my opinion, to simply sele= ct a node with available load, when we are providing info about load. The= information provided should be valid to be able to select the least (or = close to) loaded. > > >> Providing an example, let me use dynamic Load (say DL) in % (100% is t= otally loaded) that I found it easier for calculation: >> - Server1: weight=3D1500; DL=3D 2% >> - Server2: weight=3D55000; DL=3D 70% >> Then, if we only use DL in the LB algorithm, obviously Server 1 seems = to be clearly less loaded, but however, taking into account its weight is= much smaller it may be the other way around. In fact, if traffic is redi= rected to this server, it may get overloaded rapidly (due to its small ca= pacity). >> One possible way to calculate the relative DL is to divide it by the = weight, then for this example: >> - Server1 RDL=3D 10000 * (2/1500) =3D 13.33 >> - Server2 RDL=3D 10000 * (70/55000) =3D 12.73 (I multiplied by 10000 >> simply to get rid of the decimals for our discussion). >> Then, we actually find out that available load for both servers is pre= tty similar. In fact, in this case, a correct load balancing should selec= t Server2 as the less loaded server instead of server1. >> My proposal is to consider this reflection in the draft, and then make= a clear distinction between dynamic load (DL) and RELATIVE DL. We need t= o provide the RDL in the message, not DL. > SRD> This is about how the load value is calculated which is explicitly= > stated as being an implementation decision. > MCRUZ> Not exactly. We need to reflect in the draft that the LOAD provi= ded should be the relative available load, taking into account the static= weight. This is the only way we are providing a load value that can poss= ibly be used by a client to LOAD-balance. > I could accept that we leave the way to do so up to implementations. > Proposal: "LOAD should be calculated in a way that reflects the availab= le load independently of the weight of each server, in order to allow the= Diameter node that performs server selection to accurateraly compare val= ues from different servers, i.e. LOAD value identifies the same amount of= available capacity, regardless the server that has calculate it. " > > JJ2> I analysed a bit more your example with Server1 RDL=3D 10000 * > JJ2> (2/1500) =3D 13.33 and Server2 RDL=3D 10000 * (70/55000) =3D 12.73= with > JJ2> the conclusion to select server2. This is a bit surprising as > JJ2> server 1 is only 2% loaded. This example is rather specific with a= > JJ2> server 1 weight being 2,7% of server 2 weight. I did another > JJ2> example with less difference in the weights > - Server1: weight=3D30000; DL=3D 30% > - Server2: weight=3D60000; DL=3D 50% > This drives to > Server1 RDL=3D 10000 * (30/30000) =3D 10,0 > Server2 RDL=3D 10000 * (50/60000) =3D 8,3=09 > Here also, if I follow your reasoning, this would drive to select serve= r 2 to increase its RDL. Again the result is to increase server2 load > > Even by taking a 80% load for server 2 (so a high load in practice) and= 50% for server 1 > Server1 RDL=3D 10000 * (50/30000) =3D 16,7 > Server2 RDL=3D 10000 * (80/60000) =3D 13,3 > This still drives to select server 2, although the reasoning would be t= o increase server 1 load Nevertheless, if server 1 has only 30% load its= RDL becomes 10 and it will be selected, so here OK > > Please check if I am wrong somewhere, but currently RDL, for me, can g= ive strange outputs. > > About static weight I agree that static weight can be useful, e.g. a la= st hop DA can be configured with the server weight to distribute its tra= ffic among the servers it is connected to. > > My point is about the targeted load balance between the servers. Often,= the objective is to have the same load among servers (even if they have = some difference in their capacity / weight), which is the way to maximize= the traffic without entering overload in any server. So the "DL" (as def= ined in the current draft) indicates whether they have the same load, and= if the objective is achieved. For me I do not well see how you define th= e targeted load among servers with the RDL you mentioned. > > If received load from servers is not the same, the sending node has t= o send a bit more traffic to the less loaded node. For this, as you said,= an objective is to avoid oscillations, and sending node has to evaluate = the amount of traffic it will switch from the more loaded server to the l= ess loaded server, this switched traffic being not too high to avoid osci= llations and also not too low to avoid maintaining unbalanced situation. = In the draft, it is left to implementation on the sending node on how to = modify the current traffic distribution among the servers according to th= e received load (DL), and I am OK on this. In my previous mail I indicat= ed that the sending node will adjust its traffic distribution according t= o the updated load (DL) received from server and converge to the balanced= situation, in this process, I agree that the weight attached to each ser= ver can be an additional useful input when available, but keeping the cur= rent load (DL) definition =3D=3D=3D=3D=3D=3D from previous emails (= end) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > About the examples you discussed above. > I think the results you got are valid. Take into account that the stati= c weight identifies the server capability, then a server1 with weight:600= 00 has double resources than a server2 with 30000. Then, server2 45% load= is making usage of double of resources than server1 90% load. > DL/Weight provides a value than indicates the load per "resource unit".= Then, the least loaded server is the one that has less load per "resourc= e unit". > This can be seen in the following example: > Server1 RDL=3D 10000 * (45/30000) =3D 15 > Server2 RDL=3D 10000 * (90/60000) =3D 15 > Both servers are equally loaded, as long as the Big Server (Server2) is= loaded double as the Small Server (Server1), that is half size in resour= ces than Big Server. > > Then, JJacques, I think we agree the Diameter node that is responsible = for server selection should have the means to select the least loaded ser= ver, and the available load depends on the capacity of each node, not onl= y on the DL that is identified at a moment in time. > Then, I think we need to include some normative text on that, although = the specific means to achieve so could remain implementation specific. Pr= oposed text is: > "LOAD should be calculated in a way that reflects the available load in= dependently of the weight of each server, in order to allow the Diameter = node that performs server selection to accurately compare values from dif= ferent servers, i.e. LOAD value identifies the same amount of available c= apacity, regardless the server that has calculate it. The means to calcu= late the LOAD value that fulfils this requirement are implementation spec= ific." > I think, as Steve agreed, that the example could be included in the dra= ft as well, it is very useful to understand how the static weight determi= nes the available load. > > I analysed your above new example which raises same questioning f= rom my side: > By applying the factor 10000 for simplification we have > Server1 weight 6 so I can say that Server1 has a capacity of 6 resour= ce units > Server2 weight 3 so a capacity of 3 resource units. > Server1 load (DL)=3D 90% so Server 1 consumed resource units=3D 6x90% =3D= 5,4 > Server2 load (DL)=3D 45% so Server 2 consumed resource units=3D 3x45% =3D= 1,65 Then > Server1 remaining (available) resources=3D 6-5,4 =3D 0,6 > Server2 remaining (available) resources=3D 3-1,35 =3D 1,65 > > So in my understanding server2 (the smaller server) has still more avai= lable capacity than server 1, so I would conclude to transfer some traffi= c from server 1 to server 2; But you said that both servers are equally = loadedas having the same RDL=3D15, and concluded the system being well ba= lanced, which I do not agree > > You also mention that we should have the "same load per resource unit",= which also raises questioning from me: > If Server1 has a load of 90% for its 6 resource units, this also means = that each resource unit has a load of 90%. > I have difficulty to understand the definition of RDL =3D DL/Weight So = I think we are not yet well aligned on a common understanding of the exam= ple, so thanks if you can give still some more explanation. > > I continued the same exercise but with my assumptions > a) objective (according to my previous mail) is that the two servers ha= ve the same load, this drives to DL=3D75% with > Server1 load (DL)=3D 75% so Server 1 consumed resource units=3D 75% =3D= 4,5 > Server2 load (DL)=3D 75% so Server 2 consumed resource units=3D 3x75% =3D= 2,25 Then > Server1 remaining resources=3D 6-4,5 =3D 1,75 > Server2 remaining resources=3D 3-2,25 =3D 0,75 but the % of remaining r= esources compare to its capacity is the same for each server > > b) another possible objective is that the two servers have the same rem= aining (available) resource, , this drives to > Server1 load (DL)=3D 81,3% so Server 1 consumed resource units=3D 6x81,= 3% =3D 4,88 > Server2 load (DL)=3D 62,4% so Server 2 consumed resource units=3D 3x62,= 4% =3D 1,87=09 > Then > Server1 remaining resources=3D 6-4,88 =3D 1,12 > Server2 remaining resources=3D 3-1,87 =3D 1,13 so same remaining resour= ces > > Is this b) case relating more to your concern? The "least loaded" node = would be the one having the highest remaining capacity, so with traffic t= ransfer to this node until both nodes have the same remaining capacity > > Other type of load balancing objectives may be considered, but load bal= ancing objectives are for me operator dependent and implementation speci= fic. > > Then to come back to weights: > - case a), as I said, according to received load from servers senders, = a sender can adjust the traffic to converge to the same/nearly same load = among servers. The fact to know server weights would improve the converge= nce to this objective > - Case b) needs to have knowledge on the server weights as this is need= ed to evaluate the remaining resources objectives > > As indicated, server weights can be configured (eg for DAs in front of = servers) or obtained from a DNS query (as Steve mentioned), or through ot= her means that are out of the scope. > > I would like we share the same understanding before finalizing a normat= ive text > > Best regards > > JJacques > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Thu Jul 21 07:08:17 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8FB12B075 for ; Thu, 21 Jul 2016 07:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi4I3OkikWQC for ; Thu, 21 Jul 2016 07:08:09 -0700 (PDT) Received: from mailport7.csra.com (mailport7.csra.com [131.131.97.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21CA412D579 for ; Thu, 21 Jul 2016 07:08:09 -0700 (PDT) Received: from csrrdu1exm030.corp.csra.com (HELO mail.csra.com) ([10.8.2.30]) by mailport7.csra.com with ESMTP/TLS/AES256-SHA; 21 Jul 2016 10:07:55 -0400 Received: from CSRRDU1EXM025.corp.csra.com (10.8.2.25) by CSRRDU1EXM025.corp.csra.com (10.8.2.25) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 21 Jul 2016 10:08:06 -0400 Received: from CSRRDU1EXM025.corp.csra.com ([10.8.2.25]) by CSRRDU1EXM025.corp.csra.com ([10.8.2.25]) with mapi id 15.00.1178.000; Thu, 21 Jul 2016 10:08:06 -0400 From: "Gunn, Janet P" To: "dime@ietf.org" Thread-Topic: Discussion on draft-ietf-dime-load-02 Thread-Index: AdHjV9EenBXE/iQXQzyoamjFUeGPxw== Date: Thu, 21 Jul 2016 14:08:06 +0000 Message-ID: <248b648144a14fd4ad5bff65cdc40886@CSRRDU1EXM025.corp.csra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.136.2.8] Content-Type: multipart/alternative; boundary="_000_248b648144a14fd4ad5bff65cdc40886CSRRDU1EXM025corpcsraco_" MIME-Version: 1.0 Archived-At: Subject: [Dime] Discussion on draft-ietf-dime-load-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 14:08:16 -0000 --_000_248b648144a14fd4ad5bff65cdc40886CSRRDU1EXM025corpcsraco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do not think I am going to be able to remotely participate in Friday's DI= ME meeting, but I do want to make a high level comment on the discussion a= bout draft-ietf-dime-load-02. A lot of the current discussion seems to be focusing on the best load balan= cing ALGORITHM, and the right way to calculate the load VALUE. I think that this ID needs to focus on the means for SHARING load informati= on, without pre-supposing the way in which the "load value" will be used, o= r how I is caclulated I suspect that most of the environments in which load balancing will be dep= loyed will be "walled gardens", so there is not an overwhelming need for n= odes in different environments to use the load value in the same way, or ev= en use the same load balancing approach. I look forward to reading the minutes, and further discussion on line. Janet This electronic message transmission contains information from CSRA that ma= y be attorney-client privileged, proprietary or confidential. The informati= on in this message is intended only for use by the individual(s) to whom it= is addressed. If you believe you have received this message in error, plea= se contact me immediately and be aware that any use, disclosure, copying or= distribution of the contents of this message is strictly prohibited. NOTE:= Regardless of content, this email shall not operate to bind CSRA to any or= der or other contract unless pursuant to explicit written agreement or gove= rnment initiative expressly permitting the use of email for such purpose. --_000_248b648144a14fd4ad5bff65cdc40886CSRRDU1EXM025corpcsraco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do not think I am going to be able to remotely par= ticipate in Friday's DIME meeting, but I do want to make a high level = comment on the discussion about draft-ietf-dime-load-02.

 

A lot of the current discussion seems to be focusing= on the best load balancing ALGORITHM, and the right way to calculate the l= oad VALUE.

 

I think that this ID needs to focus on the means for= SHARING load information, without pre-supposing the way in which the "= ;load value" will be used, or how I is caclulated

 

I suspect that most of the environments in which loa= d balancing will be deployed will be "walled gardens", so there i= s not an overwhelming need for  nodes in different environments to use= the load value in the same way, or even use the same load balancing approach.

 

I look forward to reading the minutes, and further d= iscussion on line.

 

Janet


This electronic message transmission contains information from CSRA that= may be attorney-client privileged, proprietary or confidential. The inform= ation in this message is intended only for use by the individual(s) to whom= it is addressed. If you believe you have received this message in error, please contact me immediately and= be aware that any use, disclosure, copying or distribution of the contents= of this message is strictly prohibited. NOTE: Regardless of content, this = email shall not operate to bind CSRA to any order or other contract unless pursuant to explicit written ag= reement or government initiative expressly permitting the use of email for = such purpose.

--_000_248b648144a14fd4ad5bff65cdc40886CSRRDU1EXM025corpcsraco_-- From nobody Thu Jul 21 07:37:31 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE90412D677 for ; Thu, 21 Jul 2016 07:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-bUClZXF344 for ; Thu, 21 Jul 2016 07:37:25 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 3369812D666 for ; Thu, 21 Jul 2016 07:37:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 1B3231BA7; Thu, 21 Jul 2016 14:37:24 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQlvjaVzS5A1; Thu, 21 Jul 2016 14:37:24 +0000 (UTC) Received: from dhcp-b14d.meeting.ietf.org (dhcp-b14d.meeting.ietf.org [31.133.177.77]) by mail.networkradius.com (Postfix) with ESMTPSA id AACD1B92; Thu, 21 Jul 2016 14:37:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <248b648144a14fd4ad5bff65cdc40886@CSRRDU1EXM025.corp.csra.com> Date: Thu, 21 Jul 2016 16:37:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <08CCC2E7-96FB-4433-A940-B22D22DCA09A@deployingradius.com> References: <248b648144a14fd4ad5bff65cdc40886@CSRRDU1EXM025.corp.csra.com> To: "Gunn, Janet P" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "dime@ietf.org" Subject: Re: [Dime] Discussion on draft-ietf-dime-load-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 14:37:30 -0000 On Jul 21, 2016, at 4:08 PM, Gunn, Janet P wrote: >=20 > I do not think I am going to be able to remotely participate in = Friday's DIME meeting, but I do want to make a high level comment on = the discussion about draft-ietf-dime-load-02. > =20 > A lot of the current discussion seems to be focusing on the best load = balancing ALGORITHM, and the right way to calculate the load VALUE. I don't see much in the way of a load-balancing algorithm in the = draft. Just a discussion that the systems can use the load values to do = load-balancing, and a small discussion on active/active vs = active/passive. Which part refers to specific algorithms? > I think that this ID needs to focus on the means for SHARING load = information, without pre-supposing the way in which the "load value" = will be used, or how I is calculated The systems should use "load value" to do load balancing. That = necessitates some discussion of how that value is used. > I suspect that most of the environments in which load balancing will = be deployed will be "walled gardens", so there is not an overwhelming = need for nodes in different environments to use the load value in the = same way, or even use the same load balancing approach. I suspect that there are very few stable load-balancing algorithms. = As such, I think everyone will end up implementing pretty much the same = thing. I do have other concerns with the graph. Using inverted numbers for = "load" is confusing. Perhaps an explanation that the numbers refer to = *capacity* would be good. And capacity is measured on an arbitrary = scale from 0..65535. Section A.10 is also confusing: When removing a node in a controlled way (e.g. for maintenance purpose, so outside a failure case), it might be appropriate to progressively reduce the traffic to this node by routing traffic to other nodes. Simple load information (load percentage) would be not sufficient. Why? The load numbers of 0 (loaded) to 65535 (unloaded) are just load = percentage described in a 16-bit fixed-width number. Why does a = percentage make any difference? Further: The handling of the node removal is implementation specific but it can rely on the evolution of the load information received from the node to be removed I suspect the simple way to implement node removal is for the node to = just gradually report loads leading to 0. Once the reported load is = zero, and it has no active traffic, it can be safely removed. This = should be suggested in the draft as a safe way to remove nodes. Also, A.9 says: The previous scenarios assume that traffic can be load balanced among all peers that are eligible to handle a request. That is, the peers operate in an "active-active" configuration. In an "active-standby" configuration, traffic would be load-balanced among active peers. Requests would only be sent to peers in a "standby" state if the active peers became unavailable. For example, requests might be diverted to a stand-by peer if one or more active peers becomes overloaded. If it's possible for the nodes to signal the active/passive state in = the protocol, it would help a lot. It would mean that the difference = between active/active and active/passive is just signalling, and not = configuration. i.e. a node may signal load 65535, but also desire itself to be in the = "passive" state. Perhaps some way of having references would be good. = i.e. "load on system B is 0, unless the load on system A is also 0, in = which case load on B is 65535". I'm not sure how to implement that, tho. Alan DeKok. From nobody Thu Jul 21 15:20:41 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9323D12D7DE for ; Thu, 21 Jul 2016 15:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHy3kfzkgycE for ; Thu, 21 Jul 2016 15:20:37 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF8C12D7D8 for ; Thu, 21 Jul 2016 15:20:37 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0294.000; Thu, 21 Jul 2016 18:20:36 -0400 From: Yuval Lifshitz To: "Bertz, Lyle T [CTO]" , "dime@ietf.org" Thread-Topic: New I-D Submitted: draft-bertz-dime-predictunits Thread-Index: AdHXpgQdMKqoCHiaRIyWNoRHauEl3gLuMLEwAAClcYMADyWvEA== Date: Thu, 21 Jul 2016 22:20:35 +0000 Message-ID: References: <23595558c1ba4777abd64d584c17a422@PLSWE13M07.ad.sprint.com>, <1469113864156.93181@sprint.com> In-Reply-To: <1469113864156.93181@sprint.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_C43C255C7106314F8D13D03FA20CFE4930CAA2F9wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] New I-D Submitted: draft-bertz-dime-predictunits X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 22:20:40 -0000 --_000_C43C255C7106314F8D13D03FA20CFE4930CAA2F9wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for clarifying. The load on the client (at least in clients I know) is measured with: # con= current subscribers, # concurrent flows, bits/sec, packets/sec. I assume that the server could estimate (based on past experience) the abov= e, but as you mentioned below, they are all time based. Even # concurrent f= lows is driven by time, as we are not interested in the total amount of low= s the user had, but only how many it had at the same time. In addition, don't think that the server could be estimating the cpu impact= on the client. From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com] Sent: Thursday, July 21, 2016 5:11 PM To: Yuval Lifshitz Subject: Re: New I-D Submitted: draft-bertz-dime-predictunits kk, Sends units back to the client like a G-S-U or U-S-U so that it can get an = estimate of load. However, I would suspect it will send back multiple valu= es representing different dimensions (the *[AVP] cop out). One thing I st= ruggled with and have asked some for advice on is whether it should be give= n a time range and respond from Server to Client as a list? e.g. [ uses X Mbps, Y% CPU, 3K packets from T1 to T2 ], [ uses A Mbps, B% C= PU, C packets from T2 to T3 ] it definitely needs improvement ________________________________ From: Yuval Lifshitz = > Sent: Thursday, July 21, 2016 9:48 AM To: Bertz, Lyle T [CTO] Cc: Yuval Lifshitz Subject: RE: New I-D Submitted: draft-bertz-dime-predictunits Hi, I really don't understand this one. How is load translated to bytes, time e= tc? How would the server know how much the user is going to consume? In general would be good to understand the usecase behind. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO] Sent: Wednesday, July 06, 2016 6:56 PM To: dime@ietf.org Subject: [Dime] New I-D Submitted: draft-bertz-dime-predictunits All, I have uploaded a new I-D for consideration. It permits a Diameter Client,= upon authorization for Service usage, to receive a prediction (estimation)= of the unit load. This is intended to assist Clients in estimating load o= f authorized usage. https://datatracker.ietf.org/doc/draft-bertz-dime-predictunits/ Thank you. Lyle ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_C43C255C7106314F8D13D03FA20CFE4930CAA2F9wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for clarifying.=

The load on the client= (at least in clients I know) is measured with: # concurrent subscribers, #= concurrent flows, bits/sec, packets/sec.

I assume that the serv= er could estimate (based on past experience) the above, but as you mentione= d below, they are all time based. Even # concurrent flows is driven by time= , as we are not interested in the total amount of lows the user had, but only how many it had at the same time.

In addition, don’= ;t think that the server could be estimating the cpu impact on the client.<= o:p>

 

 

From: Bertz, L= yle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]
Sent: Thursday, July 21, 2016 5:11 PM
To: Yuval Lifshitz
Subject: Re: New I-D Submitted: draft-bertz-dime-predictunits

 

kk,

 

Sends units back to the client like a G-S-U or U-S-U so that it = can get an estimate of load.  However, I would suspect it will send ba= ck multiple values representing different dimensions (the *[AVP] cop out).   One thing I struggled with and have asked some for advice= on is whether it should be given a time range and respond from Server to C= lient as a list?

 

 

e.g. [ uses X Mbps, Y% CPU, 3K packets from T1 to T2&n= bsp;], [ uses A Mbps,&= nbsp;B% CPU, C packets from T2 to T3 ]

 

it definitely needs improvement<= o:p>

 

 

From: Yuval Lifshitz <ylifshitz@sandvine.com>
Sent: Thursday, July 21, 2016 9:48 AM
To: Bertz, Lyle T [CTO]
Cc: Yuval Lifshitz
Subject: RE: New I-D Submitted: draft-bertz-dime-predictunits=

 = ;

Hi,

I really don’t u= nderstand this one. How is load translated to bytes, time etc? How would th= e server know how much the user is going to consume?

In general would be go= od to understand the usecase behind.

 

From: DiME [mailto:d= ime-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO]
Sent: Wednesday, July 06, 2016 6:56 PM
To: dime@ietf.org
Subject: [Dime] New I-D Submitted: draft-bertz-dime-predictunits

 

All,


I have uploaded a new I-D for consideration.  It permits a Diameter Cl= ient, upon authorization for Service usage, to receive a prediction (estima= tion) of the unit load.  This is intended to assist Clients in estimat= ing load of authorized usage.

 

https://datatracker.i= etf.org/doc/draft-bertz-dime-predictunits/

 

Thank you.<= /span>

 

Lyle=

 

 

Learn more on how to switch to Sprint and save 50% on most Verizon, AT= &T or T-Mobile rates. See sprint.com/50off for details.


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

--_000_C43C255C7106314F8D13D03FA20CFE4930CAA2F9wtlexchp2sandvi_-- From nobody Fri Jul 22 02:58:06 2016 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DA212D837; Fri, 22 Jul 2016 02:58:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160722095804.12182.70157.idtracker@ietfa.amsl.com> Date: Fri, 22 Jul 2016 02:58:04 -0700 Archived-At: Cc: draft-ietf-dime-e2e-sec-req@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [Dime] Document Action: 'AVP Level Security for Non-neighboring Diameter Nodes: Scenarios and Requirements' to Informational RFC (draft-ietf-dime-e2e-sec-req-05.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 09:58:04 -0000 The IESG has approved the following document: - 'AVP Level Security for Non-neighboring Diameter Nodes: Scenarios and Requirements' (draft-ietf-dime-e2e-sec-req-05.txt) as Informational RFC This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Stephen Farrell, Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-e2e-sec-req/ Summary The document shepherd is Lionel Morand. The responsible Area Director is Stephen Farrell. If Diameter provides a hop-by-hop security (using TLS, DTLS or IPSec) between peers, the Diameter base protocol does not provide a mechanism for end-to-end security. This document describes a set of requirements for providing Diameter security at the level of individual Attribute-Value Pairs. Intended Status: Informational This document will be used to evaluate future candidate solutions. From nobody Sat Jul 23 21:20:32 2016 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6369D126579; Sat, 23 Jul 2016 21:20:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160724042031.2548.27666.idtracker@ietfa.amsl.com> Date: Sat, 23 Jul 2016 21:20:31 -0700 Archived-At: Subject: [Dime] The DIME WG has placed draft-bertz-dime-rfc4006bis in state "Candidate for WG Adoption" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 04:20:31 -0000 The DIME WG has placed draft-bertz-dime-rfc4006bis in state Candidate for WG Adoption (entered by Jouni Korhonen) The document is available at https://datatracker.ietf.org/doc/draft-bertz-dime-rfc4006bis/ Comment: As agreed in IETF96 this document is a candidate for a WG Item. From nobody Sat Jul 23 21:50:44 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D94312D5B0 for ; Sat, 23 Jul 2016 21:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zt_oR7sa5ai for ; Sat, 23 Jul 2016 21:50:37 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23F3B12D178 for ; Sat, 23 Jul 2016 21:50:37 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id p64so53446243pfb.1 for ; Sat, 23 Jul 2016 21:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:date:message-id:cc:to :mime-version; bh=NHvgiMJoq+T8URyxz9muQvBcfqk3ZGPzYwrNlSY9jI4=; b=Dw2I9wvxLwSpZOLlXL/8V1z7VOt8AIIjXDKhPQ/qetOX5ice7tOZGq2OVNJof6fZdv AXte0vdmaPbZyEvupaJghvQ8/1xmzcEmV2rpt21WgGgwkdTRSctrma6up5X98rtmlvtv HBBziYXaOzEop11Ixzy2CK8eLMD/YHkqqZlK9BfL+xtm38T+CUJin7M2kYrDc9v34Xnq yuxVqzKJhw0c1UNor0rxUu2VAE6auflMIs8wlyvEJdzn+z1ZZZK20L5YcAUBqJZ3WGmn AQphRQJSGlXFHHSJz4wlQk7IE7wt2vT8pfhgXQ9jnW/U6Jy2F9yHa4mGzsSZViRgwUCp xypw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :message-id:cc:to:mime-version; bh=NHvgiMJoq+T8URyxz9muQvBcfqk3ZGPzYwrNlSY9jI4=; b=jo0aK+H910Y+zsM2FOXZxBpQbkGmUSYsdi2AlyhoG+tR4aTqm0JRlR11K6e8vdCx0X lQRI74dp3ZQ9w8UHJLMGNrpruJ8ypnr+8AOD6WOsMFqH0/D+ZgzTIhCISEMZHPCHFsnE X0VSgcNViWLfxi0g+QOKoUYjGPYTk9C0clR7NoEQhHeuVQfgrod5Bagi13rn8sSBCbxj q8pAj8nkCmcFXLMb26dZDhhA3KhRGCcfoUA4SdeH3Wk2aPA9oQomQqmm/s80VLi9yAvW FaaJgnVgXZsZSBn8B39DCRhPhQGJvDzvA+MOlABP648v8y5jmy2fMzHLh+T+gusaE1RC DjsA== X-Gm-Message-State: AEkoousOcYQH6Ne5mELpuQiI9lGyesbVaI1U74NgMpvePYnn/GtdUGGa7mtLnVd+ukklRQ== X-Received: by 10.98.85.134 with SMTP id j128mr16692754pfb.6.1469335836499; Sat, 23 Jul 2016 21:50:36 -0700 (PDT) Received: from [10.0.0.5] (c-24-5-144-221.hsd1.ca.comcast.net. [24.5.144.221]) by smtp.gmail.com with ESMTPSA id 3sm30321448pfe.81.2016.07.23.21.50.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 23 Jul 2016 21:50:35 -0700 (PDT) From: Jouni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 23 Jul 2016 21:50:34 -0700 Message-Id: <96E3A272-1C0B-4C5F-A6FE-2A5F7E6F6A65@gmail.com> To: "dime@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [Dime] WG Adoption call for draft-bertz-dime-rfc4006bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 04:50:38 -0000 Folks, As already supported in IETF96 Berlin meeting we are ratifying the = adoption of draft-bertz-dime-rfc4006bis-01 as a WG Item. The WG adoption = call ends 8/7/2016. Voice you support or opposition (with a reason why) = on the mailing list. - Lionel & Jouni=20= From nobody Mon Jul 25 11:24:22 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31B512B075 for ; Mon, 25 Jul 2016 11:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RKs_aBvtozp for ; Mon, 25 Jul 2016 11:24:20 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2F912D0C2 for ; Mon, 25 Jul 2016 11:24:20 -0700 (PDT) Received: by mail-pa0-x230.google.com with SMTP id ks6so63704900pab.0 for ; Mon, 25 Jul 2016 11:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=13E93ZRjq6hv3++eig7wi1A3MTfwQ0sk564uShdLYIY=; b=LzHHH1G7G/4vlL0ijBRgG3nRFonECbDDvpbOtFb38032MdvgK7JHHEkOYgpSo0QbDs evxqip6VECljouppPOC4xCXm6AnOPocDfZ2xQPake4ga8UXyXDjy0gFoqIWk7qOAeyhT xg5QoLkfkabsNOwjqYtif4q4aqNaeO6QtVeTbUPMzWdoYPCEN4UWAXP15cRD9CX6USdG 8xyHitosA2F/7xemRWjqvg/7k+RN/cAu5OAPZkIdNebCwlgfDw8k0L3ccYTDvXfrX1VH tXrdpRnEBswrlmslQb/sNPztD+kknz9TpEW3fbIPmIa9VrGV/0rp/7QXJ/ji35uZOih5 sT5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=13E93ZRjq6hv3++eig7wi1A3MTfwQ0sk564uShdLYIY=; b=ISux0m+g0AWL6SQly4MYGzqY7nbV4dQkSfjaJtN2vRaNWndU7jM96wiBvx/NHYphfc H/3nmrPGbkXlgtgtsZqGrE4GWTZIn08T8I4sgg/gavKRepExzjzpl+8tLualZDVA+ZL5 Vf4Rl7O2Seaq/cdbTKhuCDclKOAXVnIYN+Kzy/uYD7QSKhsbTYQaYv+qLWI2wSkMuTzS gMEY1BSWdHaMaPTadh6G53R+4BJivtUTjZBveXpsy4qXTfHl6VQgKJPZZ4tBh2dKSY4f 1RVwITsvc97MxJJ0CuMRGt4p/4aw4ewOb/S27yGTyblLz0IQItcl7y8lYvEhJqmPw5at +n1A== X-Gm-Message-State: AEkoouumwLWHPwTIXAucmApUyScLAjw2Dx/UbMpK3tzUC6fnyqNMmk88O9WEuTWmUs80tA== X-Received: by 10.66.242.166 with SMTP id wr6mr31912240pac.147.1469471059959; Mon, 25 Jul 2016 11:24:19 -0700 (PDT) Received: from [10.100.23.170] (66.238.57.130.ptr.us.xo.net. [66.238.57.130]) by smtp.googlemail.com with ESMTPSA id o8sm9755065pav.5.2016.07.25.11.24.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jul 2016 11:24:19 -0700 (PDT) References: <96E3A272-1C0B-4C5F-A6FE-2A5F7E6F6A65@gmail.com> To: "dime@ietf.org list" From: Jouni Korhonen Message-ID: <8beef813-51ee-5976-a5e0-bc5fdf8dc5eb@gmail.com> Date: Mon, 25 Jul 2016 11:24:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <96E3A272-1C0B-4C5F-A6FE-2A5F7E6F6A65@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dime] WG Adoption call for draft-bertz-dime-rfc4006bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jouni.nospam@gmail.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 18:24:22 -0000 I support the adoption. - Jouni 7/23/2016, 9:50 PM, Jouni kirjoitti: > Folks, > > As already supported in IETF96 Berlin meeting we are ratifying the adoption of draft-bertz-dime-rfc4006bis-01 as a WG Item. The WG adoption call ends 8/7/2016. Voice you support or opposition (with a reason why) on the mailing list. > > - Lionel & Jouni > From nobody Mon Jul 25 11:41:49 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BDC12D0B4 for ; Mon, 25 Jul 2016 11:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gk_WwfO1GLu0 for ; Mon, 25 Jul 2016 11:41:45 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B5C12B042 for ; Mon, 25 Jul 2016 11:41:45 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.294.0; Mon, 25 Jul 2016 14:41:44 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0294.000; Mon, 25 Jul 2016 14:41:44 -0400 From: Dave Dolson To: "jouni.nospam@gmail.com" , "dime@ietf.org list" Thread-Topic: [Dime] WG Adoption call for draft-bertz-dime-rfc4006bis-01 Thread-Index: AQHR5WbyuP7RLGsVx0qxrJJglNe/v6Apu7cA///BxeA= Date: Mon, 25 Jul 2016 18:41:42 +0000 Message-ID: References: <96E3A272-1C0B-4C5F-A6FE-2A5F7E6F6A65@gmail.com> <8beef813-51ee-5976-a5e0-bc5fdf8dc5eb@gmail.com> In-Reply-To: <8beef813-51ee-5976-a5e0-bc5fdf8dc5eb@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] WG Adoption call for draft-bertz-dime-rfc4006bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 18:41:47 -0000 Support (and also editor) -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Monday, July 25, 2016 2:24 PM To: dime@ietf.org list Subject: Re: [Dime] WG Adoption call for draft-bertz-dime-rfc4006bis-01 I support the adoption. - Jouni 7/23/2016, 9:50 PM, Jouni kirjoitti: > Folks, > > As already supported in IETF96 Berlin meeting we are ratifying the adopti= on of draft-bertz-dime-rfc4006bis-01 as a WG Item. The WG adoption call end= s 8/7/2016. Voice you support or opposition (with a reason why) on the mail= ing list. > > - Lionel & Jouni > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime