From nobody Tue May 3 14:31:41 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 D1CE312D91B; Tue, 3 May 2016 14:31:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 14:31:39 -0700 Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org Subject: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 03 May 2016 21:31:40 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-dime-drmp-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) Given the two key security threats identified in Section 11 -- that authorized nodes can issue requests with artificially high priority in order to get better treatment, and that unauthorized intermediaries can modify the priorities that senders set -- I don't see how it is legitimate to claim that either 5.1 or 5.2 are appropriate use cases for DRMP. The spec seems to assume that this mechanism will only be used in scenarios where nodes and agents have some out-of-band trust relationship established with each other (the shepherd write-up talks about a "trusted environment"), but that is certainly not the case in many disaster and emergency scenarios. If that really is a limitation on the scope of applicability of this mechanism, that should be stated in the document, and those use cases should either be removed or modified to explain the limitations on their applicability. (2) Section 6 says: "The mechanism for how the agent determines which requests are throttled is implementation dependent and is outside the scope of this document." How is a node supposed to determine how to set its priorities if each agent makes implementation-specific decisions about what those priorities mean? I understood the document to be saying that Diameter applications would have to define what he priority levels mean within their own contexts, but then I would have expected the interpretation of priorities amongst all nodes and agents implementing the same application to be the same. (3) Section 8 says: "Diameter nodes SHOULD use the PRIORITY_10 priority as this default value." If the determination of the priority schemes are all application-specific, how is it appropriate for this spec to define what the default priority should be for all applications? Shouldn't applications specify their own defaults? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 11 says: "DRMP gives Diameter nodes the ability to influence which requests are throttled during overload scenarios." But the information is not limited to use during overload scenarios, and the spec specifically allows its use for prioritized routing in absence of overload. This should be stated here too. From nobody Tue May 3 16:42:53 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 BEC2012DA31; Tue, 3 May 2016 16:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.402 X-Spam-Level: * X-Spam-Status: No, score=1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_PBL=3.335, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 zHKS9ILcIDTi; Tue, 3 May 2016 16:42:50 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5435D12DA2D; Tue, 3 May 2016 16:42:50 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 77011A0933; Wed, 4 May 2016 01:42:48 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 4897C120077; Wed, 4 May 2016 01:42:48 +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.0294.000; Wed, 4 May 2016 01:42:47 +0200 From: To: Alissa Cooper , "iesg@ietf.org" Thread-Topic: Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) Thread-Index: AQHRpYMvTq3AStFXOUWR/+tcAlPv8p+n3/eR Date: Tue, 3 May 2016 23:42:46 +0000 Message-ID: <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> In-Reply-To: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E01E4C8AEOPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-dime-drmp@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 03 May 2016 23:42:53 -0000 --_000_6B7134B31289DC4FAF731D844122B36E01E4C8AEOPEXCLILM43corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxpc3NhLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3Lg0KUGxlYXNlIGZpbmQgYmVs b3cgc29tZSBjbGFyaWZpY2F0aW9ucywgd2FpdGluZyBmb3IgYXV0aG9ycyBmZWViYWNrLg0KDQpS ZWdhcmRzLA0KDQpMaW9uZWwNCg0KRW52b3nDqSBkZXB1aXMgU3VyZmFjZQ0KDQpEZSA6IEFsaXNz YSBDb29wZXI8bWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluPg0KRW52b3nDqSA6IOKAjm1hcmRp4oCO IOKAjjPigI4g4oCObWFp4oCOIOKAjjIwMTYg4oCOMjPigI464oCOMzENCsOAIDogaWVzZ0BpZXRm Lm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4NCkNjIDogZHJhZnQtaWV0Zi1kaW1lLWRybXBAaWV0 Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtZGltZS1kcm1wQGlldGYub3JnPiwgTGlvbmVsIE1PUkFO RDxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPiwgZGltZS1jaGFpcnNAaWV0Zi5vcmc8 bWFpbHRvOmRpbWUtY2hhaXJzQGlldGYub3JnPiwgTGlvbmVsIE1PUkFORDxtYWlsdG86bGlvbmVs Lm1vcmFuZEBvcmFuZ2UuY29tPiwgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4N Cg0KQWxpc3NhIENvb3BlciBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlv biBmb3INCmRyYWZ0LWlldGYtZGltZS1kcm1wLTA1OiBEaXNjdXNzDQoNCldoZW4gcmVzcG9uZGlu ZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0K ZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZy ZWUgdG8gY3V0IHRoaXMNCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBs ZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNz LWNyaXRlcmlhLmh0bWwNCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBh bmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVy IGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaW1lLWRybXAvDQoNCg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpESVNDVVNTOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQooMSkgR2l2ZW4gdGhlIHR3byBrZXkgc2VjdXJp dHkgdGhyZWF0cyBpZGVudGlmaWVkIGluIFNlY3Rpb24gMTEgLS0gdGhhdA0KYXV0aG9yaXplZCBu b2RlcyBjYW4gaXNzdWUgcmVxdWVzdHMgd2l0aCBhcnRpZmljaWFsbHkgaGlnaCBwcmlvcml0eSBp bg0Kb3JkZXIgdG8gZ2V0IGJldHRlciB0cmVhdG1lbnQsIGFuZCB0aGF0IHVuYXV0aG9yaXplZCBp bnRlcm1lZGlhcmllcyBjYW4NCm1vZGlmeSB0aGUgcHJpb3JpdGllcyB0aGF0IHNlbmRlcnMgc2V0 IC0tIEkgZG9uJ3Qgc2VlIGhvdyBpdCBpcw0KbGVnaXRpbWF0ZSB0byBjbGFpbSB0aGF0IGVpdGhl ciA1LjEgb3IgNS4yIGFyZSBhcHByb3ByaWF0ZSB1c2UgY2FzZXMgZm9yDQpEUk1QLiBUaGUgc3Bl YyBzZWVtcyB0byBhc3N1bWUgdGhhdCB0aGlzIG1lY2hhbmlzbSB3aWxsIG9ubHkgYmUgdXNlZCBp bg0Kc2NlbmFyaW9zIHdoZXJlIG5vZGVzIGFuZCBhZ2VudHMgaGF2ZSBzb21lIG91dC1vZi1iYW5k IHRydXN0IHJlbGF0aW9uc2hpcA0KZXN0YWJsaXNoZWQgd2l0aCBlYWNoIG90aGVyICh0aGUgc2hl cGhlcmQgd3JpdGUtdXAgdGFsa3MgYWJvdXQgYSAidHJ1c3RlZA0KZW52aXJvbm1lbnQiKSwgYnV0 IHRoYXQgaXMgY2VydGFpbmx5IG5vdCB0aGUgY2FzZSBpbiBtYW55IGRpc2FzdGVyIGFuZA0KZW1l cmdlbmN5IHNjZW5hcmlvcy4gSWYgdGhhdCByZWFsbHkgaXMgYSBsaW1pdGF0aW9uIG9uIHRoZSBz Y29wZSBvZg0KYXBwbGljYWJpbGl0eSBvZiB0aGlzIG1lY2hhbmlzbSwgdGhhdCBzaG91bGQgYmUg c3RhdGVkIGluIHRoZSBkb2N1bWVudCwNCmFuZCB0aG9zZSB1c2UgY2FzZXMgc2hvdWxkIGVpdGhl ciBiZSByZW1vdmVkIG9yIG1vZGlmaWVkIHRvIGV4cGxhaW4gdGhlDQpsaW1pdGF0aW9ucyBvbiB0 aGVpciBhcHBsaWNhYmlsaXR5Lg0KDQpbTE1dIEkgdGhpbmsgdGhhdCB3aGF0IGlzIG1pc3Npbmcg aXMgdGhhdCBEaWFtZXRlciBpcyBtYWlubHkgKGlmIG5vdCBvbmx5KSB1c2VkIGluIG1vYmlsZSBv cGVyYXRvciBuZXR3b3Jrcy4gVGhlIHRleHQgbWFrZXMgcmVmZXJlbmNlIHRvIHRoZSBSRkM3Njgz IHdoZXJlIHRoZSBvdmVyb2xvYWQgY29udGdyb2wgbWVjaGFuaXNtIGlzIGludHJvZHVjZWQgdG8g c29sdmUgb3ZlcmxvYWQgc2l0dWF0aW9ucyBpbiB0ZWxjbyBuZXR3b3Jrcy4gVGhpcyBhZGRpdGlv bmFsIG1lY2hhbmlzbSBpcyBzZWVuIGFzIGEgY29tcGxlbWVudCBvZiB0aGlzIG92ZXJsb2FkIGNv bnRyb2wgbWVjaGFuaXNtLiBOb3csIGlmIGl0IGlzIHVuZGVyc3Rvb2QgdGhhdCBpdCBpcyBhIG1l Y2hhbmlzbSBkZWZpbmVkIGZvciDigJx0cnVzdGVkIGVudmlyb25tZW504oCdIGkuZS4gbW9iaWxl IG5ldHdvcmtzLCB0aGUgdXNlIG9mIHByaW9yaXR5IGluZGljYXRpb25zIGluIGVtZXJnZW5jeSBh bmQgZGlzYXN0ZXIgc2NlbmFyaW9zIHNlZW1zIGxlZ2l0aW1hdGUuDQoNCigyKSBTZWN0aW9uIDYg c2F5czoNCg0KICAgICJUaGUgbWVjaGFuaXNtIGZvciBob3cgdGhlIGFnZW50IGRldGVybWluZXMg d2hpY2ggcmVxdWVzdHMgYXJlDQogICAgICAgdGhyb3R0bGVkIGlzIGltcGxlbWVudGF0aW9uIGRl cGVuZGVudCBhbmQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YNCiAgICAgICB0aGlzIGRvY3VtZW50 LiINCg0KSG93IGlzIGEgbm9kZSBzdXBwb3NlZCB0byBkZXRlcm1pbmUgaG93IHRvIHNldCBpdHMg cHJpb3JpdGllcyBpZiBlYWNoDQphZ2VudCBtYWtlcyBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYyBk ZWNpc2lvbnMgYWJvdXQgd2hhdCB0aG9zZSBwcmlvcml0aWVzDQptZWFuPyBJIHVuZGVyc3Rvb2Qg dGhlIGRvY3VtZW50IHRvIGJlIHNheWluZyB0aGF0IERpYW1ldGVyIGFwcGxpY2F0aW9ucw0Kd291 bGQgaGF2ZSB0byBkZWZpbmUgd2hhdCBoZSBwcmlvcml0eSBsZXZlbHMgbWVhbiB3aXRoaW4gdGhl aXIgb3duDQpjb250ZXh0cywgYnV0IHRoZW4gSSB3b3VsZCBoYXZlIGV4cGVjdGVkIHRoZSBpbnRl cnByZXRhdGlvbiBvZiBwcmlvcml0aWVzDQphbW9uZ3N0IGFsbCBub2RlcyBhbmQgYWdlbnRzIGlt cGxlbWVudGluZyB0aGUgc2FtZSBhcHBsaWNhdGlvbiB0byBiZSB0aGUNCnNhbWUuDQoNCltMTV0g SSB1bmRlcnN0YW5kLiBJIHRoaW5rIHRoYXQgdGhlIHRleHQgc2hvdWxkIHNheSDigJxUaGUgbWVj aGFuaXNtIGZvciBob3cgdGhlIGFnZW50IGRldGVybWluZXMgd2hpY2ggcmVxdWVzdHMgYXJlIGMo Y2FuZGlkYXRlcykgdG8gYmUgdGhyb3R0bGVk4oCdLiBBbmQsIHdoZW4gdGhlcmUgYXJlIHJlcXVl c3RzIHRvIHRocm90dGxlLCB0aGUgcHJpb3JpdHkgaW5kaWNhdGlvbiBpcyB1c2VkIHRvIGRldGVy bWluZSDigJx3aGljaCByZXF1ZXN0cyB0byByb3V0ZSBmaXJzdCwgd2hpY2ggcmVxdWVzdHMgdG8g dGhyb3R0bGUgYW5kIHdoZXJlIHRoZSByZXF1ZXN0IGlzIHJvdXRlZC4gIEZvciBpbnN0YW5jZSwg cmVxdWVzdHMgd2l0aCBoaWdoZXIgIHByaW9yaXR5IG1pZ2h0IGhhdmUgYSBsb3dlciBwcm9iYWJp bGl0eSBvZiBiZWluZyB0aHJvdHRsZWQuIOKAnS4NCg0KKDMpIFNlY3Rpb24gOCBzYXlzOg0KDQog IkRpYW1ldGVyIG5vZGVzIFNIT1VMRCB1c2UgdGhlIFBSSU9SSVRZXzEwIHByaW9yaXR5IGFzIHRo aXMgZGVmYXVsdA0KdmFsdWUuIg0KDQpJZiB0aGUgZGV0ZXJtaW5hdGlvbiBvZiB0aGUgcHJpb3Jp dHkgc2NoZW1lcyBhcmUgYWxsDQphcHBsaWNhdGlvbi1zcGVjaWZpYywgaG93IGlzIGl0IGFwcHJv cHJpYXRlIGZvciB0aGlzIHNwZWMgdG8gZGVmaW5lIHdoYXQNCnRoZSBkZWZhdWx0IHByaW9yaXR5 IHNob3VsZCBiZSBmb3IgYWxsIGFwcGxpY2F0aW9ucz8gU2hvdWxkbid0DQphcHBsaWNhdGlvbnMg c3BlY2lmeSB0aGVpciBvd24gZGVmYXVsdHM/DQoNCltMTV0gaXQgaXMgbmVlZGVkIHRvIHRha2Ug aW50byBhY2NvdW50IHRoYXQgdGhlIHVzZSBvZiBwcmlvcml0eSBpbmRpY2F0aW9uIGluIERpYW1l dGVyIHdpbGwgYmUgb3B0aW9uYWwgYW5kIHRoYXQgbGVnYWN5IGltcGxlbWVudGF0aW9uIHdpbGwg bm90IGluY2x1ZGUgYW55IHByaW9yaXR5IGluZGljYXRpb24gaW4gRGlhbWV0ZXIgcmVxdWVzdHMu IEFmdGVyIGRpc2N1c3Npb24sIGl0IHdhcyBkZWNpZGVkIHRoYXQgcmVxdWVzdHMgd2l0aG91dCBw cmlvcml0eSBzaG91bGQgYmUgaGFuZGxlZCBhcyB3aXRoIGEgcHJpb3JpdHkgc2V0IHRvIDEwLiBU aGlzIG1ha2VzIHRoZSBkaWZmZXJlbmNlIHdpdGggcmVxdWVzdHMgd2l0aCBhbiBleHBsaWNpdCBs b3dlciBwcmlvcml0aWVzIGFuZCBvdGhlciB3aXRoIGhpZ2hlciBwcmlvcml0aWVzLiAxMCBpcyB1 c2VkIGFzIOKAnGF2ZXJhZ2XigJ0gcHJpb3JpdHksIHdpdGggdGhlIHBvc3NpYmlsaXR5IG9mIHNw ZWNpZmljIG9wZXJhdG9yIHBvbGljaWVzIHRvIHVzZSBhbm90aGVyIHZhbHVlLg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpTZWN0aW9uIDExIHNheXM6ICJEUk1Q IGdpdmVzIERpYW1ldGVyIG5vZGVzIHRoZSBhYmlsaXR5IHRvIGluZmx1ZW5jZQ0Kd2hpY2ggcmVx dWVzdHMgYXJlIHRocm90dGxlZCBkdXJpbmcgb3ZlcmxvYWQgc2NlbmFyaW9zLiIgQnV0IHRoZQ0K aW5mb3JtYXRpb24gaXMgbm90IGxpbWl0ZWQgdG8gdXNlIGR1cmluZyBvdmVybG9hZCBzY2VuYXJp b3MsIGFuZCB0aGUgc3BlYw0Kc3BlY2lmaWNhbGx5IGFsbG93cyBpdHMgdXNlIGZvciBwcmlvcml0 aXplZCByb3V0aW5nIGluIGFic2VuY2Ugb2YNCm92ZXJsb2FkLiBUaGlzIHNob3VsZCBiZSBzdGF0 ZWQgaGVyZSB0b28uDQoNCltMTV0gcmlnaHQuDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4 cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVz IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwK T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh dmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_6B7134B31289DC4FAF731D844122B36E01E4C8AEOPEXCLILM43corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVu dD0iV2luZG93cyBNYWlsIDE3LjUuOTYwMC4yMDkxMSI+DQo8c3R5bGUgdHlwZT0idGV4dC9jc3Mi PjwhLS1odG1sIHsgZm9udC1mYW1pbHk6ICJDb2xvciBFbW9qaSIsICJDYWxpYnJpIiwgIlNlZ29l IFVJIiwgIk1laXJ5byIsICJNaWNyb3NvZnQgWWFIZWkgVUkiLCAiTWljcm9zb2Z0IEpoZW5nSGVp IFVJIiwgIk1hbGd1biBHb3RoaWMiLCAic2Fucy1zZXJpZiI7IH0tLT48L3N0eWxlPjxzdHlsZSBk YXRhLWV4dGVybmFsc3R5bGU9InRydWUiPjwhLS0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaCB7Cm1hcmdpbi10b3A6MGluOwptYXJn aW4tcmlnaHQ6MGluOwptYXJnaW4tYm90dG9tOjBpbjsKbWFyZ2luLWxlZnQ6LjVpbjsKbWFyZ2lu LWJvdHRvbTouMDAwMXB0Owp9CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwgewptYXJnaW46MGluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KcC5Nc29MaXN0UGFyYWdy YXBoQ3hTcEZpcnN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCBkaXYuTXNvTGlzdFBh cmFncmFwaEN4U3BGaXJzdCwgCnAuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIGxpLk1zb0xp c3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIApw Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBk aXYuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0IHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdo dDowaW47Cm1hcmdpbi1ib3R0b206MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9t Oi4wMDAxcHQ7CmxpbmUtaGVpZ2h0OjExNSU7Cn0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5 IGRpcj0ibHRyIj4NCjxkaXYgZGF0YS1leHRlcm5hbHN0eWxlPSJmYWxzZSIgZGlyPSJsdHIiIHN0 eWxlPSJmb250LWZhbWlseTogJ0NhbGlicmknLCAnU2Vnb2UgVUknLCAnTWVpcnlvJywgJ01pY3Jv c29mdCBZYUhlaSBVSScsICdNaWNyb3NvZnQgSmhlbmdIZWkgVUknLCAnTWFsZ3VuIEdvdGhpYycs ICdzYW5zLXNlcmlmJztmb250LXNpemU6MTJwdDsiPg0KPGRpdj5IaSBBbGlzc2EsPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3LjwvZGl2Pg0K PGRpdj5QbGVhc2UgZmluZCBiZWxvdyBzb21lIGNsYXJpZmljYXRpb25zLCB3YWl0aW5nIGZvciBh dXRob3JzIGZlZWJhY2suPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+TGlvbmVsPGJyPg0KPC9kaXY+DQo8ZGl2IGRh dGEtc2lnbmF0dXJlYmxvY2s9InRydWUiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RW52b3nD qSBkZXB1aXMgU3VyZmFjZTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0icGFkZGluZy10b3A6IDVweDsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDIyOSwgMjI5LCAy MjkpOyBib3JkZXItdG9wLXdpZHRoOiAxcHg7IGJvcmRlci10b3Atc3R5bGU6IHNvbGlkOyI+DQo8 ZGl2Pjxmb250IGZhY2U9IiAnQ2FsaWJyaScsICdTZWdvZSBVSScsICdNZWlyeW8nLCAnTWljcm9z b2Z0IFlhSGVpIFVJJywgJ01pY3Jvc29mdCBKaGVuZ0hlaSBVSScsICdNYWxndW4gR290aGljJywg J3NhbnMtc2VyaWYnIiBzdHlsZT0ibGluZS1oZWlnaHQ6IDE1cHQ7IGxldHRlci1zcGFjaW5nOiAw LjAyZW07IGZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCAmcXVvdDtTZWdvZSBVSSZx dW90OywgJnF1b3Q7TWVpcnlvJnF1b3Q7LCAmcXVvdDtNaWNyb3NvZnQgWWFIZWkgVUkmcXVvdDss ICZxdW90O01pY3Jvc29mdCBKaGVuZ0hlaSBVSSZxdW90OywgJnF1b3Q7TWFsZ3VuIEdvdGhpYyZx dW90OywgJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMnB0OyI+PGI+RGUmbmJz cDs6PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzphbGlzc2FAY29vcGVydy5pbiIgdGFyZ2V0PSJf cGFyZW50Ij5BbGlzc2ENCiBDb29wZXI8L2E+PGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+Jm5i c3A74oCObWFyZGnigI4g4oCOM+KAjiDigI5tYWnigI4g4oCOMjAxNiDigI4yM+KAjjrigI4zMTxi cj4NCjxiPsOAIDo8L2I+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciIHRhcmdl dD0iX3BhcmVudCI+aWVzZ0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+Jm5ic3A7 PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtZGltZS1kcm1wQGlldGYub3JnIiB0YXJnZXQ9Il9w YXJlbnQiPmRyYWZ0LWlldGYtZGltZS1kcm1wQGlldGYub3JnPC9hPiwNCjxhIGhyZWY9Im1haWx0 bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iIHRhcmdldD0iX3BhcmVudCI+TGlvbmVsIE1PUkFO RDwvYT4sIDxhIGhyZWY9Im1haWx0bzpkaW1lLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfcGFy ZW50Ij4NCmRpbWUtY2hhaXJzQGlldGYub3JnPC9hPiwgPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5t b3JhbmRAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfcGFyZW50Ij4NCkxpb25lbCBNT1JBTkQ8L2E+LCA8 YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyIgdGFyZ2V0PSJfcGFyZW50Ij5kaW1lQGlldGYu b3JnPC9hPjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgZGly PSIiPg0KPGRpdj5BbGlzc2EgQ29vcGVyIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90 IHBvc2l0aW9uIGZvcjxicj4NCmRyYWZ0LWlldGYtZGltZS1kcm1wLTA1OiBEaXNjdXNzPGJyPg0K PGJyPg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFj dCBhbmQgcmVwbHkgdG8gYWxsPGJyPg0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBU byBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXM8YnI+DQppbnRyb2R1Y3Rvcnkg cGFyYWdyYXBoLCBob3dldmVyLik8YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2UgcmVmZXIgdG8gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sPGJy Pg0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBv c2l0aW9ucy48YnI+DQo8YnI+DQo8YnI+DQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIg YmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6PGJyPg0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaW1lLWRybXAvPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCkRJU0NVU1M6PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N Cjxicj4NCigxKSBHaXZlbiB0aGUgdHdvIGtleSBzZWN1cml0eSB0aHJlYXRzIGlkZW50aWZpZWQg aW4gU2VjdGlvbiAxMSAtLSB0aGF0PGJyPg0KYXV0aG9yaXplZCBub2RlcyBjYW4gaXNzdWUgcmVx dWVzdHMgd2l0aCBhcnRpZmljaWFsbHkgaGlnaCBwcmlvcml0eSBpbjxicj4NCm9yZGVyIHRvIGdl dCBiZXR0ZXIgdHJlYXRtZW50LCBhbmQgdGhhdCB1bmF1dGhvcml6ZWQgaW50ZXJtZWRpYXJpZXMg Y2FuPGJyPg0KbW9kaWZ5IHRoZSBwcmlvcml0aWVzIHRoYXQgc2VuZGVycyBzZXQgLS0gSSBkb24n dCBzZWUgaG93IGl0IGlzPGJyPg0KbGVnaXRpbWF0ZSB0byBjbGFpbSB0aGF0IGVpdGhlciA1LjEg b3IgNS4yIGFyZSBhcHByb3ByaWF0ZSB1c2UgY2FzZXMgZm9yPGJyPg0KRFJNUC4gVGhlIHNwZWMg c2VlbXMgdG8gYXNzdW1lIHRoYXQgdGhpcyBtZWNoYW5pc20gd2lsbCBvbmx5IGJlIHVzZWQgaW48 YnI+DQpzY2VuYXJpb3Mgd2hlcmUgbm9kZXMgYW5kIGFnZW50cyBoYXZlIHNvbWUgb3V0LW9mLWJh bmQgdHJ1c3QgcmVsYXRpb25zaGlwPGJyPg0KZXN0YWJsaXNoZWQgd2l0aCBlYWNoIG90aGVyICh0 aGUgc2hlcGhlcmQgd3JpdGUtdXAgdGFsa3MgYWJvdXQgYSAmcXVvdDt0cnVzdGVkPGJyPg0KZW52 aXJvbm1lbnQmcXVvdDspLCBidXQgdGhhdCBpcyBjZXJ0YWlubHkgbm90IHRoZSBjYXNlIGluIG1h bnkgZGlzYXN0ZXIgYW5kPGJyPg0KZW1lcmdlbmN5IHNjZW5hcmlvcy4gSWYgdGhhdCByZWFsbHkg aXMgYSBsaW1pdGF0aW9uIG9uIHRoZSBzY29wZSBvZjxicj4NCmFwcGxpY2FiaWxpdHkgb2YgdGhp cyBtZWNoYW5pc20sIHRoYXQgc2hvdWxkIGJlIHN0YXRlZCBpbiB0aGUgZG9jdW1lbnQsPGJyPg0K YW5kIHRob3NlIHVzZSBjYXNlcyBzaG91bGQgZWl0aGVyIGJlIHJlbW92ZWQgb3IgbW9kaWZpZWQg dG8gZXhwbGFpbiB0aGU8YnI+DQpsaW1pdGF0aW9ucyBvbiB0aGVpciBhcHBsaWNhYmlsaXR5LiZu YnNwOyA8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PltMTV0gSSB0aGluayB0 aGF0IHdoYXQgaXMgbWlzc2luZyBpcyB0aGF0IERpYW1ldGVyIGlzIG1haW5seSAoaWYgbm90IG9u bHkpIHVzZWQgaW4gbW9iaWxlIG9wZXJhdG9yIG5ldHdvcmtzLiBUaGUgdGV4dCBtYWtlcyByZWZl cmVuY2UgdG8gdGhlIFJGQzc2ODMgd2hlcmUgdGhlIG92ZXJvbG9hZCBjb250Z3JvbCBtZWNoYW5p c20gaXMgaW50cm9kdWNlZCB0byBzb2x2ZSBvdmVybG9hZCBzaXR1YXRpb25zIGluIHRlbGNvIG5l dHdvcmtzLiBUaGlzDQogYWRkaXRpb25hbCBtZWNoYW5pc20gaXMgc2VlbiBhcyBhIGNvbXBsZW1l bnQgb2YmbmJzcDt0aGlzJm5ic3A7b3ZlcmxvYWQmbmJzcDtjb250cm9sIG1lY2hhbmlzbS4gTm93 LCBpZiBpdCBpcyB1bmRlcnN0b29kIHRoYXQgaXQgaXMgYSBtZWNoYW5pc20gZGVmaW5lZCBmb3Im bmJzcDvigJx0cnVzdGVkIGVudmlyb25tZW504oCdIGkuZS4gbW9iaWxlIG5ldHdvcmtzLCB0aGUg dXNlIG9mIHByaW9yaXR5IGluZGljYXRpb25zIGluIGVtZXJnZW5jeSBhbmQgZGlzYXN0ZXIgc2Nl bmFyaW9zJm5ic3A7c2VlbXMNCiBsZWdpdGltYXRlLjwvZGl2Pg0KPGRpdj48YnI+DQooMikgU2Vj dGlvbiA2IHNheXM6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O1RoZSBtZWNo YW5pc20gZm9yIGhvdyB0aGUgYWdlbnQgZGV0ZXJtaW5lcyB3aGljaCByZXF1ZXN0cyBhcmU8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhyb3R0bGVkIGlzIGltcGxl bWVudGF0aW9uIGRlcGVuZGVudCBhbmQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2Y8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhpcyBkb2N1bWVudC4mcXVvdDs8YnI+ DQo8YnI+DQpIb3cgaXMgYSBub2RlIHN1cHBvc2VkIHRvIGRldGVybWluZSBob3cgdG8gc2V0IGl0 cyBwcmlvcml0aWVzIGlmIGVhY2g8YnI+DQphZ2VudCBtYWtlcyBpbXBsZW1lbnRhdGlvbi1zcGVj aWZpYyBkZWNpc2lvbnMgYWJvdXQgd2hhdCB0aG9zZSBwcmlvcml0aWVzPGJyPg0KbWVhbj8gSSB1 bmRlcnN0b29kIHRoZSBkb2N1bWVudCB0byBiZSBzYXlpbmcgdGhhdCBEaWFtZXRlciBhcHBsaWNh dGlvbnM8YnI+DQp3b3VsZCBoYXZlIHRvIGRlZmluZSB3aGF0IGhlIHByaW9yaXR5IGxldmVscyBt ZWFuIHdpdGhpbiB0aGVpciBvd248YnI+DQpjb250ZXh0cywgYnV0IHRoZW4gSSB3b3VsZCBoYXZl IGV4cGVjdGVkIHRoZSBpbnRlcnByZXRhdGlvbiBvZiBwcmlvcml0aWVzPGJyPg0KYW1vbmdzdCBh bGwgbm9kZXMgYW5kIGFnZW50cyBpbXBsZW1lbnRpbmcgdGhlIHNhbWUgYXBwbGljYXRpb24gdG8g YmUgdGhlPGJyPg0Kc2FtZS4gPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5b TE1dIEkgdW5kZXJzdGFuZC4gSSB0aGluayB0aGF0IHRoZSB0ZXh0IHNob3VsZCBzYXkmbmJzcDvi gJxUaGUgbWVjaGFuaXNtIGZvciBob3cgdGhlIGFnZW50IGRldGVybWluZXMgd2hpY2ggcmVxdWVz dHMgYXJlIGMoY2FuZGlkYXRlcykgdG8gYmUgdGhyb3R0bGVk4oCdLiBBbmQsIHdoZW4gdGhlcmUg YXJlIHJlcXVlc3RzIHRvIHRocm90dGxlLCZuYnNwO3RoZSBwcmlvcml0eSBpbmRpY2F0aW9uIGlz IHVzZWQgdG8gZGV0ZXJtaW5lJm5ic3A74oCcd2hpY2ggcmVxdWVzdHMgdG8NCiByb3V0ZSBmaXJz dCwgd2hpY2ggcmVxdWVzdHMgdG8gdGhyb3R0bGUgYW5kIHdoZXJlIHRoZSByZXF1ZXN0IGlzIHJv dXRlZC4mbmJzcDsgRm9yIGluc3RhbmNlLCByZXF1ZXN0cyB3aXRoIGhpZ2hlciZuYnNwOyBwcmlv cml0eSBtaWdodCBoYXZlIGEgbG93ZXIgcHJvYmFiaWxpdHkgb2YgYmVpbmcgdGhyb3R0bGVkLiDi gJ0uPC9kaXY+DQo8ZGl2Pjxicj4NCigzKSBTZWN0aW9uIDggc2F5czogPGJyPg0KPGJyPg0KJm5i c3A7JnF1b3Q7RGlhbWV0ZXIgbm9kZXMgU0hPVUxEIHVzZSB0aGUgUFJJT1JJVFlfMTAgcHJpb3Jp dHkgYXMgdGhpcyBkZWZhdWx0PGJyPg0KdmFsdWUuJnF1b3Q7PGJyPg0KJm5ic3A7Jm5ic3A7IDxi cj4NCklmIHRoZSBkZXRlcm1pbmF0aW9uIG9mIHRoZSBwcmlvcml0eSBzY2hlbWVzIGFyZSBhbGw8 YnI+DQphcHBsaWNhdGlvbi1zcGVjaWZpYywgaG93IGlzIGl0IGFwcHJvcHJpYXRlIGZvciB0aGlz IHNwZWMgdG8gZGVmaW5lIHdoYXQ8YnI+DQp0aGUgZGVmYXVsdCBwcmlvcml0eSBzaG91bGQgYmUg Zm9yIGFsbCBhcHBsaWNhdGlvbnM/IFNob3VsZG4ndDxicj4NCmFwcGxpY2F0aW9ucyBzcGVjaWZ5 IHRoZWlyIG93biBkZWZhdWx0cz88YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PltMTV0gaXQgaXMgbmVlZGVkIHRvIHRha2UgaW50byBhY2NvdW50IHRoYXQgdGhlIHVzZSBvZiBw cmlvcml0eSBpbmRpY2F0aW9uIGluIERpYW1ldGVyIHdpbGwgYmUgb3B0aW9uYWwgYW5kIHRoYXQg bGVnYWN5Jm5ic3A7aW1wbGVtZW50YXRpb24gd2lsbCBub3QgaW5jbHVkZSBhbnkgcHJpb3JpdHkg aW5kaWNhdGlvbiBpbiBEaWFtZXRlciByZXF1ZXN0cy4gQWZ0ZXIgZGlzY3Vzc2lvbiwgaXQgd2Fz IGRlY2lkZWQgdGhhdCByZXF1ZXN0cyB3aXRob3V0DQogcHJpb3JpdHkgc2hvdWxkIGJlIGhhbmRs ZWQgYXMgd2l0aCBhIHByaW9yaXR5IHNldCB0byAxMC4gVGhpcyBtYWtlcyB0aGUgZGlmZmVyZW5j ZSB3aXRoIHJlcXVlc3RzIHdpdGggYW4gZXhwbGljaXQgbG93ZXIgcHJpb3JpdGllcyBhbmQgb3Ro ZXIgd2l0aCBoaWdoZXIgcHJpb3JpdGllcy4gMTAgaXMgdXNlZCBhcyZuYnNwO+KAnGF2ZXJhZ2Xi gJ0gcHJpb3JpdHksIHdpdGggdGhlIHBvc3NpYmlsaXR5IG9mIHNwZWNpZmljIG9wZXJhdG9yIHBv bGljaWVzIHRvIHVzZQ0KIGFub3RoZXIgdmFsdWUuIDxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 YnI+DQpDT01NRU5UOjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpTZWN0aW9uIDExIHNh eXM6ICZxdW90O0RSTVAgZ2l2ZXMgRGlhbWV0ZXIgbm9kZXMgdGhlIGFiaWxpdHkgdG8gaW5mbHVl bmNlPGJyPg0Kd2hpY2ggcmVxdWVzdHMgYXJlIHRocm90dGxlZCBkdXJpbmcgb3ZlcmxvYWQgc2Nl bmFyaW9zLiZxdW90OyBCdXQgdGhlPGJyPg0KaW5mb3JtYXRpb24gaXMgbm90IGxpbWl0ZWQgdG8g dXNlIGR1cmluZyBvdmVybG9hZCBzY2VuYXJpb3MsIGFuZCB0aGUgc3BlYzxicj4NCnNwZWNpZmlj YWxseSBhbGxvd3MgaXRzIHVzZSBmb3IgcHJpb3JpdGl6ZWQgcm91dGluZyBpbiBhYnNlbmNlIG9m PGJyPg0Kb3ZlcmxvYWQuIFRoaXMgc2hvdWxkIGJlIHN0YXRlZCBoZXJlIHRvby48YnI+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PltMTV0gcmlnaHQuPGJyPg0KPGJyPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVz IG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4 cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNl IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIg ZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2Vz IGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRl Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRl Zm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVs ZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFs dGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBt b2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0K PC9odG1sPg0K --_000_6B7134B31289DC4FAF731D844122B36E01E4C8AEOPEXCLILM43corp_-- From nobody Tue May 3 19:31:27 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 8175512D0A3; Tue, 3 May 2016 19:31:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504023124.8242.52368.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 19:31:24 -0700 Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org Subject: [Dime] Ben Campbell's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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: Wed, 04 May 2016 02:31:24 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dime-drmp-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a few concerns that I think need some discussion. 1) Priority between applications: The fact that agents can apply priority for messages from multiple applications without knowledge of those applications seems dangerous. Let's say application A is a critical infrastructure application, and application B is not. But clients for application B might set requests to have a higher priority than do clients for application A. Further, application B could become a DoS vector for application A. One potential (and likely half-baked) way to mitigate this would be to say that nodes that are not "application aware" can only apply priority among messages for the same application. 2) Priority between clients of the same application: If you have multiple clients for the same application, don't they need to use the same prioritization strategy? How is this to be managed? 3) Out of order requests: The draft explicitly allows agents to re-route and even explicitly re-order messages. Is it safe to have a non-application aware node change the order of messages? 4) I am nervous about the idea that clients and servers would use a generic message priority mechanism to manage the allocation of resources that result from a requests and answers. It seems like that should be based on application specific rules and information. (Now, if the point is that these same AVPs might be used in an application according to application specific rules, that might be okay--but then you might run into issues where application-agnostic agents don't know the difference.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- General: I approached this assuming prioritization would matter only in overload scenarios. But I gather you envision using this in non-overload scenarios? (This interacts with my discuss point about the use of DRMP to prioritize resource allocation that result result from successful diameter transactions.) Use case 5.3 is a bit worrisome in this context. -6, list item 4: Are there really use cases for answer senders to set a different priority on the answer than was on the request? That seems to add quite a bit of complexity. - 6, list item 8: I'm not sure what it means for a client to prioritize answers to it's own requests. -8, "Diameter nodes SHOULD include Diameter routing message priority in the DRMP AVP in all Diameter request messages." : Does that apply to all nodes that touch a request, or just the request originator? -- "Diameter nodes MUST use the priority indicated in the DRMP AVP carried in the answer message, if it exists." The MUST seems odd, since paying attention to the priority in the initial request was only SHOULD. -- "Another is to use the Proxy-Info mechanism defined in [RFC6733].": That probably needs some elaboration. From nobody Tue May 3 23:47:53 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 720AD12D1BF for ; Tue, 3 May 2016 23:47:52 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=E+2OA9K+; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=g/gobEXA 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 8VPTooaVlLX1 for ; Tue, 3 May 2016 23:47:45 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F1D12D1BD for ; Tue, 3 May 2016 23:47:45 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 020EA20DF7 for ; Wed, 4 May 2016 02:47:44 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 04 May 2016 02:47:45 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=fet3lAla0yWDxpOGZh6RQ4wj7Bc=; b=E+2OA9 K+wDOBgyIN3e9U1vv9D6LAO/VIKlndcIJOzoFFmIJlaHQaYsISS+UpJP+Uv3sZl1 br8LlWmU/uMA6vnekJb9djqnrhqZpnogYBWZpnjolbO0+HtjrHZhGD/5nPUu7jdk xDETdUdCfqKiOvDkOquROZ4oyPL8h1mgBfR+I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=fet3lAla0yWDxpO GZh6RQ4wj7Bc=; b=g/gobEXAqHLcpygP0RD2AtGlWO1Fv+VOKPu0M/YmioJ0SEC 54qI0QrJCfFL43fJVjGIwLX1wpXvdbJ9/R1sutE8t+9B4O305hegIVvcFLPBT6tg Jx1B+y8KlD2KRAVLeMCmsUb2KGsEtxYb1j3D2qr7jx5OSsqjsmT31L9Q6Ies= X-Sasl-enc: s3WQNZhkLIhz/fFxQAGkmaizhIw6VEZ3blyxBwSqCZWI 1462344464 Received: from [192.168.0.15] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by mail.messagingengine.com (Postfix) with ESMTPA id 8CAC26801C0; Wed, 4 May 2016 02:47:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13E238) In-Reply-To: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> Date: Wed, 4 May 2016 07:52:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> To: Alissa Cooper Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 04 May 2016 06:47:52 -0000 Hi Alissa, > On 3 May 2016, at 22:31, Alissa Cooper wrote: >=20 > (3) Section 8 says:=20 >=20 > "Diameter nodes SHOULD use the PRIORITY_10 priority as this default > value." >=20 > If the determination of the priority schemes are all > application-specific, how is it appropriate for this spec to define what > the default priority should be for all applications? Shouldn't > applications specify their own defaults? I think it is perfectly acceptable for this spec to recommend a default in t= he middle of the allowed range. I read this as a requirement on application p= olicies. I think it would be bad if different applications pick different va= lues as the default, as this would be confusing to implementors and deployer= s. From nobody Wed May 4 02:36:11 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 C8F1612D0E5; Wed, 4 May 2016 02:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 c9vrlEaYfCXk; Wed, 4 May 2016 02:36:04 -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 855D812D0EF; Wed, 4 May 2016 02:36:01 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 692AA74F99E33; Wed, 4 May 2016 09:35:57 +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 u449Zv79024850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 May 2016 09:35:59 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 u449Zptl022123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 May 2016 11:35:56 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.44]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 4 May 2016 11:35:49 +0200 From: "Trottin, Jean-Jacques (Nokia - FR)" To: "lionel.morand@orange.com" , Alissa Cooper , "iesg@ietf.org" Thread-Topic: Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) Thread-Index: AQHRpZWHwzJ4iI8k3EmUiQOkFIYlMJ+ohQPQ Date: Wed, 4 May 2016 09:35:49 +0000 Message-ID: References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@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: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D29D4ED182FR712WXCHMBA12z_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-dime-drmp@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 04 May 2016 09:36:07 -0000 --_000_E194C2E18676714DACA9C3A2516265D29D4ED182FR712WXCHMBA12z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsDQoNCkkgYWxzbyBhZ3JlZSB3aXRoIExpb25lbHPigJkgY29tbWVudHMgYW5kIGNsYXJp ZmljYXRpb25zLg0KDQpCZXN0IHJlZ2FyZHMNCg0KSkphY3F1ZXMNCg0KRGUgOiBEaU1FIFttYWls dG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIGxpb25lbC5tb3JhbmRAb3Jh bmdlLmNvbQ0KRW52b3nDqSA6IG1lcmNyZWRpIDQgbWFpIDIwMTYgMDE6NDMNCsOAIDogQWxpc3Nh IENvb3BlcjsgaWVzZ0BpZXRmLm9yZw0KQ2MgOiBkcmFmdC1pZXRmLWRpbWUtZHJtcEBpZXRmLm9y ZzsgZGltZS1jaGFpcnNAaWV0Zi5vcmc7IGRpbWVAaWV0Zi5vcmcNCk9iamV0IDogUmU6IFtEaW1l XSBBbGlzc2EgQ29vcGVyJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRpbWUtZHJtcC0wNTogKHdp dGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KSGkgQWxpc3NhLA0KDQpUaGFuayB5b3UgZm9yIHlv dXIgcmV2aWV3Lg0KUGxlYXNlIGZpbmQgYmVsb3cgc29tZSBjbGFyaWZpY2F0aW9ucywgd2FpdGlu ZyBmb3IgYXV0aG9ycyBmZWViYWNrLg0KDQpSZWdhcmRzLA0KDQpMaW9uZWwNCg0KRW52b3nDqSBk ZXB1aXMgU3VyZmFjZQ0KDQpEZSA6IEFsaXNzYSBDb29wZXI8bWFpbHRvOmFsaXNzYUBjb29wZXJ3 LmluPg0KRW52b3nDqSA6IOKAjm1hcmRp4oCOIOKAjjPigI4g4oCObWFp4oCOIOKAjjIwMTYg4oCO MjPigI464oCOMzENCsOAIDogaWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4NCkNj IDogZHJhZnQtaWV0Zi1kaW1lLWRybXBAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtZGltZS1k cm1wQGlldGYub3JnPiwgTGlvbmVsIE1PUkFORDxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2Uu Y29tPiwgZGltZS1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmRpbWUtY2hhaXJzQGlldGYub3JnPiwg TGlvbmVsIE1PUkFORDxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPiwgZGltZUBpZXRm Lm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KQWxpc3NhIENvb3BlciBoYXMgZW50ZXJlZCB0 aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0LWlldGYtZGltZS1kcm1wLTA1 OiBEaXNjdXNzDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGlu ZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRo ZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCmludHJvZHVjdG9yeSBw YXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRm Lm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCmZvciBtb3JlIGluZm9y bWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0KVGhl IGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3Vu ZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaW1l LWRybXAvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpESVNDVVNTOg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoo MSkgR2l2ZW4gdGhlIHR3byBrZXkgc2VjdXJpdHkgdGhyZWF0cyBpZGVudGlmaWVkIGluIFNlY3Rp b24gMTEgLS0gdGhhdA0KYXV0aG9yaXplZCBub2RlcyBjYW4gaXNzdWUgcmVxdWVzdHMgd2l0aCBh cnRpZmljaWFsbHkgaGlnaCBwcmlvcml0eSBpbg0Kb3JkZXIgdG8gZ2V0IGJldHRlciB0cmVhdG1l bnQsIGFuZCB0aGF0IHVuYXV0aG9yaXplZCBpbnRlcm1lZGlhcmllcyBjYW4NCm1vZGlmeSB0aGUg cHJpb3JpdGllcyB0aGF0IHNlbmRlcnMgc2V0IC0tIEkgZG9uJ3Qgc2VlIGhvdyBpdCBpcw0KbGVn aXRpbWF0ZSB0byBjbGFpbSB0aGF0IGVpdGhlciA1LjEgb3IgNS4yIGFyZSBhcHByb3ByaWF0ZSB1 c2UgY2FzZXMgZm9yDQpEUk1QLiBUaGUgc3BlYyBzZWVtcyB0byBhc3N1bWUgdGhhdCB0aGlzIG1l Y2hhbmlzbSB3aWxsIG9ubHkgYmUgdXNlZCBpbg0Kc2NlbmFyaW9zIHdoZXJlIG5vZGVzIGFuZCBh Z2VudHMgaGF2ZSBzb21lIG91dC1vZi1iYW5kIHRydXN0IHJlbGF0aW9uc2hpcA0KZXN0YWJsaXNo ZWQgd2l0aCBlYWNoIG90aGVyICh0aGUgc2hlcGhlcmQgd3JpdGUtdXAgdGFsa3MgYWJvdXQgYSAi dHJ1c3RlZA0KZW52aXJvbm1lbnQiKSwgYnV0IHRoYXQgaXMgY2VydGFpbmx5IG5vdCB0aGUgY2Fz ZSBpbiBtYW55IGRpc2FzdGVyIGFuZA0KZW1lcmdlbmN5IHNjZW5hcmlvcy4gSWYgdGhhdCByZWFs bHkgaXMgYSBsaW1pdGF0aW9uIG9uIHRoZSBzY29wZSBvZg0KYXBwbGljYWJpbGl0eSBvZiB0aGlz IG1lY2hhbmlzbSwgdGhhdCBzaG91bGQgYmUgc3RhdGVkIGluIHRoZSBkb2N1bWVudCwNCmFuZCB0 aG9zZSB1c2UgY2FzZXMgc2hvdWxkIGVpdGhlciBiZSByZW1vdmVkIG9yIG1vZGlmaWVkIHRvIGV4 cGxhaW4gdGhlDQpsaW1pdGF0aW9ucyBvbiB0aGVpciBhcHBsaWNhYmlsaXR5Lg0KDQpbTE1dIEkg dGhpbmsgdGhhdCB3aGF0IGlzIG1pc3NpbmcgaXMgdGhhdCBEaWFtZXRlciBpcyBtYWlubHkgKGlm IG5vdCBvbmx5KSB1c2VkIGluIG1vYmlsZSBvcGVyYXRvciBuZXR3b3Jrcy4gVGhlIHRleHQgbWFr ZXMgcmVmZXJlbmNlIHRvIHRoZSBSRkM3NjgzIHdoZXJlIHRoZSBvdmVyb2xvYWQgY29udGdyb2wg bWVjaGFuaXNtIGlzIGludHJvZHVjZWQgdG8gc29sdmUgb3ZlcmxvYWQgc2l0dWF0aW9ucyBpbiB0 ZWxjbyBuZXR3b3Jrcy4gVGhpcyBhZGRpdGlvbmFsIG1lY2hhbmlzbSBpcyBzZWVuIGFzIGEgY29t cGxlbWVudCBvZiB0aGlzIG92ZXJsb2FkIGNvbnRyb2wgbWVjaGFuaXNtLiBOb3csIGlmIGl0IGlz IHVuZGVyc3Rvb2QgdGhhdCBpdCBpcyBhIG1lY2hhbmlzbSBkZWZpbmVkIGZvciDigJx0cnVzdGVk IGVudmlyb25tZW504oCdIGkuZS4gbW9iaWxlIG5ldHdvcmtzLCB0aGUgdXNlIG9mIHByaW9yaXR5 IGluZGljYXRpb25zIGluIGVtZXJnZW5jeSBhbmQgZGlzYXN0ZXIgc2NlbmFyaW9zIHNlZW1zIGxl Z2l0aW1hdGUuDQoNCigyKSBTZWN0aW9uIDYgc2F5czoNCg0KICAgICJUaGUgbWVjaGFuaXNtIGZv ciBob3cgdGhlIGFnZW50IGRldGVybWluZXMgd2hpY2ggcmVxdWVzdHMgYXJlDQogICAgICAgdGhy b3R0bGVkIGlzIGltcGxlbWVudGF0aW9uIGRlcGVuZGVudCBhbmQgaXMgb3V0c2lkZSB0aGUgc2Nv cGUgb2YNCiAgICAgICB0aGlzIGRvY3VtZW50LiINCg0KSG93IGlzIGEgbm9kZSBzdXBwb3NlZCB0 byBkZXRlcm1pbmUgaG93IHRvIHNldCBpdHMgcHJpb3JpdGllcyBpZiBlYWNoDQphZ2VudCBtYWtl cyBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYyBkZWNpc2lvbnMgYWJvdXQgd2hhdCB0aG9zZSBwcmlv cml0aWVzDQptZWFuPyBJIHVuZGVyc3Rvb2QgdGhlIGRvY3VtZW50IHRvIGJlIHNheWluZyB0aGF0 IERpYW1ldGVyIGFwcGxpY2F0aW9ucw0Kd291bGQgaGF2ZSB0byBkZWZpbmUgd2hhdCBoZSBwcmlv cml0eSBsZXZlbHMgbWVhbiB3aXRoaW4gdGhlaXIgb3duDQpjb250ZXh0cywgYnV0IHRoZW4gSSB3 b3VsZCBoYXZlIGV4cGVjdGVkIHRoZSBpbnRlcnByZXRhdGlvbiBvZiBwcmlvcml0aWVzDQphbW9u Z3N0IGFsbCBub2RlcyBhbmQgYWdlbnRzIGltcGxlbWVudGluZyB0aGUgc2FtZSBhcHBsaWNhdGlv biB0byBiZSB0aGUNCnNhbWUuDQoNCltMTV0gSSB1bmRlcnN0YW5kLiBJIHRoaW5rIHRoYXQgdGhl IHRleHQgc2hvdWxkIHNheSDigJxUaGUgbWVjaGFuaXNtIGZvciBob3cgdGhlIGFnZW50IGRldGVy bWluZXMgd2hpY2ggcmVxdWVzdHMgYXJlIGMoY2FuZGlkYXRlcykgdG8gYmUgdGhyb3R0bGVk4oCd LiBBbmQsIHdoZW4gdGhlcmUgYXJlIHJlcXVlc3RzIHRvIHRocm90dGxlLCB0aGUgcHJpb3JpdHkg aW5kaWNhdGlvbiBpcyB1c2VkIHRvIGRldGVybWluZSDigJx3aGljaCByZXF1ZXN0cyB0byByb3V0 ZSBmaXJzdCwgd2hpY2ggcmVxdWVzdHMgdG8gdGhyb3R0bGUgYW5kIHdoZXJlIHRoZSByZXF1ZXN0 IGlzIHJvdXRlZC4gIEZvciBpbnN0YW5jZSwgcmVxdWVzdHMgd2l0aCBoaWdoZXIgIHByaW9yaXR5 IG1pZ2h0IGhhdmUgYSBsb3dlciBwcm9iYWJpbGl0eSBvZiBiZWluZyB0aHJvdHRsZWQuIOKAnS4N Cg0KKDMpIFNlY3Rpb24gOCBzYXlzOg0KDQogIkRpYW1ldGVyIG5vZGVzIFNIT1VMRCB1c2UgdGhl IFBSSU9SSVRZXzEwIHByaW9yaXR5IGFzIHRoaXMgZGVmYXVsdA0KdmFsdWUuIg0KDQpJZiB0aGUg ZGV0ZXJtaW5hdGlvbiBvZiB0aGUgcHJpb3JpdHkgc2NoZW1lcyBhcmUgYWxsDQphcHBsaWNhdGlv bi1zcGVjaWZpYywgaG93IGlzIGl0IGFwcHJvcHJpYXRlIGZvciB0aGlzIHNwZWMgdG8gZGVmaW5l IHdoYXQNCnRoZSBkZWZhdWx0IHByaW9yaXR5IHNob3VsZCBiZSBmb3IgYWxsIGFwcGxpY2F0aW9u cz8gU2hvdWxkbid0DQphcHBsaWNhdGlvbnMgc3BlY2lmeSB0aGVpciBvd24gZGVmYXVsdHM/DQoN CltMTV0gaXQgaXMgbmVlZGVkIHRvIHRha2UgaW50byBhY2NvdW50IHRoYXQgdGhlIHVzZSBvZiBw cmlvcml0eSBpbmRpY2F0aW9uIGluIERpYW1ldGVyIHdpbGwgYmUgb3B0aW9uYWwgYW5kIHRoYXQg bGVnYWN5IGltcGxlbWVudGF0aW9uIHdpbGwgbm90IGluY2x1ZGUgYW55IHByaW9yaXR5IGluZGlj YXRpb24gaW4gRGlhbWV0ZXIgcmVxdWVzdHMuIEFmdGVyIGRpc2N1c3Npb24sIGl0IHdhcyBkZWNp ZGVkIHRoYXQgcmVxdWVzdHMgd2l0aG91dCBwcmlvcml0eSBzaG91bGQgYmUgaGFuZGxlZCBhcyB3 aXRoIGEgcHJpb3JpdHkgc2V0IHRvIDEwLiBUaGlzIG1ha2VzIHRoZSBkaWZmZXJlbmNlIHdpdGgg cmVxdWVzdHMgd2l0aCBhbiBleHBsaWNpdCBsb3dlciBwcmlvcml0aWVzIGFuZCBvdGhlciB3aXRo IGhpZ2hlciBwcmlvcml0aWVzLiAxMCBpcyB1c2VkIGFzIOKAnGF2ZXJhZ2XigJ0gcHJpb3JpdHks IHdpdGggdGhlIHBvc3NpYmlsaXR5IG9mIHNwZWNpZmljIG9wZXJhdG9yIHBvbGljaWVzIHRvIHVz ZSBhbm90aGVyIHZhbHVlLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpTZWN0aW9uIDExIHNheXM6ICJEUk1QIGdpdmVzIERpYW1ldGVyIG5vZGVzIHRoZSBhYmls aXR5IHRvIGluZmx1ZW5jZQ0Kd2hpY2ggcmVxdWVzdHMgYXJlIHRocm90dGxlZCBkdXJpbmcgb3Zl cmxvYWQgc2NlbmFyaW9zLiIgQnV0IHRoZQ0KaW5mb3JtYXRpb24gaXMgbm90IGxpbWl0ZWQgdG8g dXNlIGR1cmluZyBvdmVybG9hZCBzY2VuYXJpb3MsIGFuZCB0aGUgc3BlYw0Kc3BlY2lmaWNhbGx5 IGFsbG93cyBpdHMgdXNlIGZvciBwcmlvcml0aXplZCByb3V0aW5nIGluIGFic2VuY2Ugb2YNCm92 ZXJsb2FkLiBUaGlzIHNob3VsZCBiZSBzdGF0ZWQgaGVyZSB0b28uDQoNCltMTV0gcmlnaHQuDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz IGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0 b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBv dSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0 IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0 ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBt YXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2 ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0K --_000_E194C2E18676714DACA9C3A2516265D29D4ED182FR712WXCHMBA12z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi UHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K cC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBs aS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJp b3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4t Ym90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwLm1zb2xpc3RwYXJhZ3JhcGhjeHNwZmlyc3QsIGxpLm1zb2xpc3RwYXJhZ3JhcGhj eHNwZmlyc3QsIGRpdi5tc29saXN0cGFyYWdyYXBoY3hzcGZpcnN0DQoJe21zby1zdHlsZS1uYW1l Om1zb2xpc3RwYXJhZ3JhcGhjeHNwZmlyc3Q7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJp Z2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWxpbmUtaGVpZ2h0OjExNSU7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAubXNvbGlzdHBh cmFncmFwaGN4c3BtaWRkbGUsIGxpLm1zb2xpc3RwYXJhZ3JhcGhjeHNwbWlkZGxlLCBkaXYubXNv bGlzdHBhcmFncmFwaGN4c3BtaWRkbGUNCgl7bXNvLXN0eWxlLW5hbWU6bXNvbGlzdHBhcmFncmFw aGN4c3BtaWRkbGU7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJn aW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWxpbmUtaGVpZ2h0OjExNSU7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAubXNvbGlzdHBhcmFncmFwaGN4c3BsYXN0 LCBsaS5tc29saXN0cGFyYWdyYXBoY3hzcGxhc3QsIGRpdi5tc29saXN0cGFyYWdyYXBoY3hzcGxh c3QNCgl7bXNvLXN0eWxlLW5hbWU6bXNvbGlzdHBhcmFncmFwaGN4c3BsYXN0Ow0KCW1hcmdpbi10 b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2lu LWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglsaW5lLWhlaWdodDoxMTUl Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1h dMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLlRleHRl ZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIGFsbDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBh bHNvIGFncmVlIHdpdGggTGlvbmVsc+KAmSBjb21tZW50cyBhbmQgY2xhcmlmaWNhdGlvbnMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkpKYWNxdWVzDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGll dGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPGJy Pg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1lcmNyZWRpIDQgbWFpIDIwMTYgMDE6NDM8YnI+DQo8 Yj7DgCZuYnNwOzo8L2I+IEFsaXNzYSBDb29wZXI7IGllc2dAaWV0Zi5vcmc8YnI+DQo8Yj5DYyZu YnNwOzo8L2I+IGRyYWZ0LWlldGYtZGltZS1kcm1wQGlldGYub3JnOyBkaW1lLWNoYWlyc0BpZXRm Lm9yZzsgZGltZUBpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtEaW1lXSBB bGlzc2EgQ29vcGVyJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRpbWUtZHJtcC0wNTogKHdpdGgg RElTQ1VTUyBhbmQgQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpIEFsaXNzYSw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPlBsZWFzZSBmaW5kIGJlbG93IHNvbWUgY2xhcmlmaWNhdGlvbnMsIHdhaXRpbmcg Zm9yIGF1dGhvcnMgZmVlYmFjay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkxpb25lbDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5FbnZvecOpIGRlcHVpcyBTdXJmYWNl PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0U1RTVFNSAxLjBw dDtwYWRkaW5nOjQuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2xldHRlci1zcGFjaW5nOi4yNXB0Ij5EZSZuYnNwOzo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7bGV0dGVyLXNwYWNpbmc6LjI1cHQiPiZuYnNwOzxhIGhyZWY9Im1haWx0bzph bGlzc2FAY29vcGVydy5pbiIgdGFyZ2V0PSJfcGFyZW50Ij5BbGlzc2EgQ29vcGVyPC9hPjxicj4N CjxiPkVudm95w6kmbmJzcDs6PC9iPiZuYnNwO+KAjm1hcmRp4oCOIOKAjjPigI4g4oCObWFp4oCO IOKAjjIwMTYg4oCOMjPigI464oCOMzE8YnI+DQo8Yj7DgCA6PC9iPiZuYnNwOzxhIGhyZWY9Im1h aWx0bzppZXNnQGlldGYub3JnIiB0YXJnZXQ9Il9wYXJlbnQiPmllc2dAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+Q2MmbmJzcDs6PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWRpbWUt ZHJtcEBpZXRmLm9yZyIgdGFyZ2V0PSJfcGFyZW50Ij5kcmFmdC1pZXRmLWRpbWUtZHJtcEBpZXRm Lm9yZzwvYT4sDQo8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIiB0YXJn ZXQ9Il9wYXJlbnQiPkxpb25lbCBNT1JBTkQ8L2E+LCA8YSBocmVmPSJtYWlsdG86ZGltZS1jaGFp cnNAaWV0Zi5vcmciIHRhcmdldD0iX3BhcmVudCI+DQpkaW1lLWNoYWlyc0BpZXRmLm9yZzwvYT4s IDxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iIHRhcmdldD0iX3BhcmVu dCI+DQpMaW9uZWwgTU9SQU5EPC9hPiwgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciIHRh cmdldD0iX3BhcmVudCI+ZGltZUBpZXRmLm9yZzwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QWxpc3NhIENvb3Bl ciBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3I8YnI+DQpkcmFm dC1pZXRmLWRpbWUtZHJtcC0wNTogRGlzY3Vzczxicj4NCjxicj4NCldoZW4gcmVzcG9uZGluZywg cGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbDxicj4N CmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBm cmVlIHRvIGN1dCB0aGlzPGJyPg0KaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pPGJy Pg0KPGJyPg0KPGJyPg0KUGxlYXNlIHJlZmVyIHRvIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbCI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWw8L2E+PGJyPg0KZm9y IG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9u cy48YnI+DQo8YnI+DQo8YnI+DQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90 IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaW1lLWRybXAvIj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRpbWUtZHJtcC88L2E+PGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCkRJU0NVU1M6PGJyPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxicj4NCjxicj4NCigxKSBHaXZlbiB0aGUgdHdvIGtleSBzZWN1cml0eSB0aHJlYXRzIGlkZW50 aWZpZWQgaW4gU2VjdGlvbiAxMSAtLSB0aGF0PGJyPg0KYXV0aG9yaXplZCBub2RlcyBjYW4gaXNz dWUgcmVxdWVzdHMgd2l0aCBhcnRpZmljaWFsbHkgaGlnaCBwcmlvcml0eSBpbjxicj4NCm9yZGVy IHRvIGdldCBiZXR0ZXIgdHJlYXRtZW50LCBhbmQgdGhhdCB1bmF1dGhvcml6ZWQgaW50ZXJtZWRp YXJpZXMgY2FuPGJyPg0KbW9kaWZ5IHRoZSBwcmlvcml0aWVzIHRoYXQgc2VuZGVycyBzZXQgLS0g SSBkb24ndCBzZWUgaG93IGl0IGlzPGJyPg0KbGVnaXRpbWF0ZSB0byBjbGFpbSB0aGF0IGVpdGhl ciA1LjEgb3IgNS4yIGFyZSBhcHByb3ByaWF0ZSB1c2UgY2FzZXMgZm9yPGJyPg0KRFJNUC4gVGhl IHNwZWMgc2VlbXMgdG8gYXNzdW1lIHRoYXQgdGhpcyBtZWNoYW5pc20gd2lsbCBvbmx5IGJlIHVz ZWQgaW48YnI+DQpzY2VuYXJpb3Mgd2hlcmUgbm9kZXMgYW5kIGFnZW50cyBoYXZlIHNvbWUgb3V0 LW9mLWJhbmQgdHJ1c3QgcmVsYXRpb25zaGlwPGJyPg0KZXN0YWJsaXNoZWQgd2l0aCBlYWNoIG90 aGVyICh0aGUgc2hlcGhlcmQgd3JpdGUtdXAgdGFsa3MgYWJvdXQgYSAmcXVvdDt0cnVzdGVkPGJy Pg0KZW52aXJvbm1lbnQmcXVvdDspLCBidXQgdGhhdCBpcyBjZXJ0YWlubHkgbm90IHRoZSBjYXNl IGluIG1hbnkgZGlzYXN0ZXIgYW5kPGJyPg0KZW1lcmdlbmN5IHNjZW5hcmlvcy4gSWYgdGhhdCBy ZWFsbHkgaXMgYSBsaW1pdGF0aW9uIG9uIHRoZSBzY29wZSBvZjxicj4NCmFwcGxpY2FiaWxpdHkg b2YgdGhpcyBtZWNoYW5pc20sIHRoYXQgc2hvdWxkIGJlIHN0YXRlZCBpbiB0aGUgZG9jdW1lbnQs PGJyPg0KYW5kIHRob3NlIHVzZSBjYXNlcyBzaG91bGQgZWl0aGVyIGJlIHJlbW92ZWQgb3IgbW9k aWZpZWQgdG8gZXhwbGFpbiB0aGU8YnI+DQpsaW1pdGF0aW9ucyBvbiB0aGVpciBhcHBsaWNhYmls aXR5LiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5bTE1dIEkgdGhp bmsgdGhhdCB3aGF0IGlzIG1pc3NpbmcgaXMgdGhhdCBEaWFtZXRlciBpcyBtYWlubHkgKGlmIG5v dCBvbmx5KSB1c2VkIGluIG1vYmlsZSBvcGVyYXRvciBuZXR3b3Jrcy4gVGhlIHRleHQgbWFrZXMg cmVmZXJlbmNlIHRvIHRoZSBSRkM3NjgzIHdoZXJlIHRoZSBvdmVyb2xvYWQgY29udGdyb2wgbWVj aGFuaXNtDQogaXMgaW50cm9kdWNlZCB0byBzb2x2ZSBvdmVybG9hZCBzaXR1YXRpb25zIGluIHRl bGNvIG5ldHdvcmtzLiBUaGlzIGFkZGl0aW9uYWwgbWVjaGFuaXNtIGlzIHNlZW4gYXMgYSBjb21w bGVtZW50IG9mJm5ic3A7dGhpcyZuYnNwO292ZXJsb2FkJm5ic3A7Y29udHJvbCBtZWNoYW5pc20u IE5vdywgaWYgaXQgaXMgdW5kZXJzdG9vZCB0aGF0IGl0IGlzIGEgbWVjaGFuaXNtIGRlZmluZWQg Zm9yJm5ic3A74oCcdHJ1c3RlZCBlbnZpcm9ubWVudOKAnSBpLmUuIG1vYmlsZSBuZXR3b3Jrcywg dGhlDQogdXNlIG9mIHByaW9yaXR5IGluZGljYXRpb25zIGluIGVtZXJnZW5jeSBhbmQgZGlzYXN0 ZXIgc2NlbmFyaW9zJm5ic3A7c2VlbXMgbGVnaXRpbWF0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQoo MikgU2VjdGlvbiA2IHNheXM6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O1Ro ZSBtZWNoYW5pc20gZm9yIGhvdyB0aGUgYWdlbnQgZGV0ZXJtaW5lcyB3aGljaCByZXF1ZXN0cyBh cmU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhyb3R0bGVkIGlz IGltcGxlbWVudGF0aW9uIGRlcGVuZGVudCBhbmQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2Y8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhpcyBkb2N1bWVudC4mcXVv dDs8YnI+DQo8YnI+DQpIb3cgaXMgYSBub2RlIHN1cHBvc2VkIHRvIGRldGVybWluZSBob3cgdG8g c2V0IGl0cyBwcmlvcml0aWVzIGlmIGVhY2g8YnI+DQphZ2VudCBtYWtlcyBpbXBsZW1lbnRhdGlv bi1zcGVjaWZpYyBkZWNpc2lvbnMgYWJvdXQgd2hhdCB0aG9zZSBwcmlvcml0aWVzPGJyPg0KbWVh bj8gSSB1bmRlcnN0b29kIHRoZSBkb2N1bWVudCB0byBiZSBzYXlpbmcgdGhhdCBEaWFtZXRlciBh cHBsaWNhdGlvbnM8YnI+DQp3b3VsZCBoYXZlIHRvIGRlZmluZSB3aGF0IGhlIHByaW9yaXR5IGxl dmVscyBtZWFuIHdpdGhpbiB0aGVpciBvd248YnI+DQpjb250ZXh0cywgYnV0IHRoZW4gSSB3b3Vs ZCBoYXZlIGV4cGVjdGVkIHRoZSBpbnRlcnByZXRhdGlvbiBvZiBwcmlvcml0aWVzPGJyPg0KYW1v bmdzdCBhbGwgbm9kZXMgYW5kIGFnZW50cyBpbXBsZW1lbnRpbmcgdGhlIHNhbWUgYXBwbGljYXRp b24gdG8gYmUgdGhlPGJyPg0Kc2FtZS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+W0xNXSBJIHVuZGVyc3RhbmQuIEkgdGhpbmsgdGhhdCB0aGUgdGV4dCBzaG91bGQgc2F5Jm5i c3A74oCcVGhlIG1lY2hhbmlzbSBmb3IgaG93IHRoZSBhZ2VudCBkZXRlcm1pbmVzIHdoaWNoIHJl cXVlc3RzIGFyZSBjKGNhbmRpZGF0ZXMpIHRvIGJlIHRocm90dGxlZOKAnS4gQW5kLCB3aGVuIHRo ZXJlIGFyZSByZXF1ZXN0cyB0byB0aHJvdHRsZSwmbmJzcDt0aGUNCiBwcmlvcml0eSBpbmRpY2F0 aW9uIGlzIHVzZWQgdG8gZGV0ZXJtaW5lJm5ic3A74oCcd2hpY2ggcmVxdWVzdHMgdG8gcm91dGUg Zmlyc3QsIHdoaWNoIHJlcXVlc3RzIHRvIHRocm90dGxlIGFuZCB3aGVyZSB0aGUgcmVxdWVzdCBp cyByb3V0ZWQuJm5ic3A7IEZvciBpbnN0YW5jZSwgcmVxdWVzdHMgd2l0aCBoaWdoZXImbmJzcDsg cHJpb3JpdHkgbWlnaHQgaGF2ZSBhIGxvd2VyIHByb2JhYmlsaXR5IG9mIGJlaW5nIHRocm90dGxl ZC4g4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCigzKSBTZWN0aW9uIDggc2F5czogPGJyPg0KPGJy Pg0KJm5ic3A7JnF1b3Q7RGlhbWV0ZXIgbm9kZXMgU0hPVUxEIHVzZSB0aGUgUFJJT1JJVFlfMTAg cHJpb3JpdHkgYXMgdGhpcyBkZWZhdWx0PGJyPg0KdmFsdWUuJnF1b3Q7PGJyPg0KJm5ic3A7Jm5i c3A7IDxicj4NCklmIHRoZSBkZXRlcm1pbmF0aW9uIG9mIHRoZSBwcmlvcml0eSBzY2hlbWVzIGFy ZSBhbGw8YnI+DQphcHBsaWNhdGlvbi1zcGVjaWZpYywgaG93IGlzIGl0IGFwcHJvcHJpYXRlIGZv ciB0aGlzIHNwZWMgdG8gZGVmaW5lIHdoYXQ8YnI+DQp0aGUgZGVmYXVsdCBwcmlvcml0eSBzaG91 bGQgYmUgZm9yIGFsbCBhcHBsaWNhdGlvbnM/IFNob3VsZG4ndDxicj4NCmFwcGxpY2F0aW9ucyBz cGVjaWZ5IHRoZWlyIG93biBkZWZhdWx0cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5bTE1dIGl0IGlzIG5lZWRlZCB0byB0YWtlIGludG8gYWNjb3VudCB0aGF0IHRoZSB1c2Ug b2YgcHJpb3JpdHkgaW5kaWNhdGlvbiBpbiBEaWFtZXRlciB3aWxsIGJlIG9wdGlvbmFsIGFuZCB0 aGF0IGxlZ2FjeSZuYnNwO2ltcGxlbWVudGF0aW9uIHdpbGwgbm90IGluY2x1ZGUgYW55IHByaW9y aXR5IGluZGljYXRpb24gaW4gRGlhbWV0ZXINCiByZXF1ZXN0cy4gQWZ0ZXIgZGlzY3Vzc2lvbiwg aXQgd2FzIGRlY2lkZWQgdGhhdCByZXF1ZXN0cyB3aXRob3V0IHByaW9yaXR5IHNob3VsZCBiZSBo YW5kbGVkIGFzIHdpdGggYSBwcmlvcml0eSBzZXQgdG8gMTAuIFRoaXMgbWFrZXMgdGhlIGRpZmZl cmVuY2Ugd2l0aCByZXF1ZXN0cyB3aXRoIGFuIGV4cGxpY2l0IGxvd2VyIHByaW9yaXRpZXMgYW5k IG90aGVyIHdpdGggaGlnaGVyIHByaW9yaXRpZXMuIDEwIGlzIHVzZWQgYXMmbmJzcDvigJxhdmVy YWdl4oCdIHByaW9yaXR5LA0KIHdpdGggdGhlIHBvc3NpYmlsaXR5IG9mIHNwZWNpZmljIG9wZXJh dG9yIHBvbGljaWVzIHRvIHVzZSBhbm90aGVyIHZhbHVlLiA8YnI+DQo8YnI+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPGJyPg0KQ09NTUVOVDo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KU2VjdGlvbiAx MSBzYXlzOiAmcXVvdDtEUk1QIGdpdmVzIERpYW1ldGVyIG5vZGVzIHRoZSBhYmlsaXR5IHRvIGlu Zmx1ZW5jZTxicj4NCndoaWNoIHJlcXVlc3RzIGFyZSB0aHJvdHRsZWQgZHVyaW5nIG92ZXJsb2Fk IHNjZW5hcmlvcy4mcXVvdDsgQnV0IHRoZTxicj4NCmluZm9ybWF0aW9uIGlzIG5vdCBsaW1pdGVk IHRvIHVzZSBkdXJpbmcgb3ZlcmxvYWQgc2NlbmFyaW9zLCBhbmQgdGhlIHNwZWM8YnI+DQpzcGVj aWZpY2FsbHkgYWxsb3dzIGl0cyB1c2UgZm9yIHByaW9yaXRpemVkIHJvdXRpbmcgaW4gYWJzZW5j ZSBvZjxicj4NCm92ZXJsb2FkLiBUaGlzIHNob3VsZCBiZSBzdGF0ZWQgaGVyZSB0b28uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5bTE1dIHJpZ2h0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29u dGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0 IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnBhcyBldHJlIGRpZmZ1c2Vz LCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVj dSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPG86cD48L286cD48 L3ByZT4NCjxwcmU+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBw aWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGli bGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PcmFuZ2UgZGVjbGluZSB0 b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBv dSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmU+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv dGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BcyBlbWFpbHMgbWF5IGJlIGFs dGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBt b2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhh bmsgeW91LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E194C2E18676714DACA9C3A2516265D29D4ED182FR712WXCHMBA12z_-- From nobody Wed May 4 04:13:27 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 CC14612D0A0; Wed, 4 May 2016 04:13:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 04:13:23 -0700 Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org Subject: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Wed, 04 May 2016 11:13:24 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dime-drmp-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I fully agree with all discuss comments made by Ben and Alissa. However, the summary here might be that this information might simply be not very useful for the uses cases described. And there might be other mechanisms that do not require any trust and that can address the uses cases easier and more appropriate such a simply prioritization of a certain application in the request handler/request agent or relative priorities within one application (on sent-out). However, the one part that does actually concern me is: "When using DRMP priority information, Diameter nodes MUST use the default priority for transactions that do not have priority specified in a DRMP AVP." This part seems dangerous and I would proposed to instead basically have to different queues: one if a priority is defined and another one for requests without priority indication to make sure that requests out of the second queue will be served at some point in time and cannot be starved by other low priority requests completely. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Why do you need 15 different priority levels? Wouldn't be two enough for all or your use cases? From nobody Wed May 4 04:32:38 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 3E16B12D555 for ; Wed, 4 May 2016 04:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=LduuAgHe; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=ABWaWTbW 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 HX8pMsKFt_nV for ; Wed, 4 May 2016 04:32:34 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B184A12D538 for ; Wed, 4 May 2016 04:32:34 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2D96920986 for ; Wed, 4 May 2016 07:32:34 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Wed, 04 May 2016 07:32:34 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=mYMbSbvNbozjBIVRi/AGESR9pBA=; b=LduuAg HeDTbIlw3Qc+4weglc8gi9gtIXKppQM2kXSEHCBP8q2dRa++3lFQkQIDmfZYmULV ckP10EB/bPtxlYWhqcri5N7aAEY/3j9mVrEcKb1QO4h51SfYCCxSW/WwyxOJCvEJ Aj2GXdu+rgJpJP2+pdppij0A3wA38voieGB/I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=mYMbSbvNbozjBIV Ri/AGESR9pBA=; b=ABWaWTbWJeNJYFMd+HL4AJI7YD7HzVtOaN1Z6Ix9SQwqbiP nfZGwJHd+gHCkx0js3X1R6E1qiC/2rNn+TCkF9mtif/4ZjnWPyjm+Y/vPu3jsFG/ eKx+3fyn+NdM9K9dDno2dDF74DACXx7H7pR/wBdetC5AO+nXvFwOvdsiBVAU= X-Sasl-enc: jjNQ4kr7YbDm0z5nPWRCIsBHGDB46uYU0ixx5m9Y1/vm 1462361553 Received: from [10.241.185.144] (unknown [85.255.235.140]) by mail.messagingengine.com (Postfix) with ESMTPA id 72A0068019D; Wed, 4 May 2016 07:32:33 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13E238) In-Reply-To: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> Date: Wed, 4 May 2016 12:37:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> To: Mirja Kuehlewind Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 04 May 2016 11:32:36 -0000 Hi Mirja, > On 4 May 2016, at 12:13, Mirja Kuehlewind wrote: >=20 > However, the one part that does actually concern me is: > "When using DRMP priority information, Diameter nodes MUST use the > default priority for transactions that do not have priority specified > in a DRMP AVP." > This part seems dangerous and I would proposed to instead basically have > to different queues: one if a priority is defined and another one for > requests without priority indication to make sure that requests out of > the second queue will be served at some point in time and cannot be > starved by other low priority requests completely. I think I disagree with you: default priority handling is orthogonal to the n= umber of queues used. Some implementations would use one queue per priority,= so you are effectively suggesting that no priority is treated as its own pr= iority. I think this is an implementation detail. From nobody Wed May 4 04:46: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 EF40512B017 for ; Wed, 4 May 2016 04:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 19h6jykhtQ3S for ; Wed, 4 May 2016 04:45:59 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CADC512D0BB for ; Wed, 4 May 2016 04:45:58 -0700 (PDT) Received: (qmail 9330 invoked from network); 4 May 2016 13:45:56 +0200 Received: from p5dec2412.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.36.18) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 4 May 2016 13:45:56 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Wed, 4 May 2016 13:45:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 04 May 2016 11:46:02 -0000 Hi Alexey, > Am 04.05.2016 um 13:37 schrieb Alexey Melnikov = : >=20 > Hi Mirja, >=20 >> On 4 May 2016, at 12:13, Mirja Kuehlewind = wrote: >>=20 >> However, the one part that does actually concern me is: >> "When using DRMP priority information, Diameter nodes MUST use the >> default priority for transactions that do not have priority = specified >> in a DRMP AVP." >> This part seems dangerous and I would proposed to instead basically = have >> to different queues: one if a priority is defined and another one for >> requests without priority indication to make sure that requests out = of >> the second queue will be served at some point in time and cannot be >> starved by other low priority requests completely. >=20 > I think I disagree with you: default priority handling is orthogonal = to the number of queues used. Some implementations would use one queue = per priority, so you are effectively suggesting that no priority is = treated as its own priority. I think this is an implementation detail. >=20 >=20 Yes, queues are implementation details. That was just meant as an = illustration. My point it, I don=E2=80=99t think all requests without = priority should get an default priority assigned (and especially not a = very low priority). Further it has to be ensured that requests that = don=E2=80=99t assign a priority do not get starved (as they might be = important). Mirja From nobody Wed May 4 05:03:47 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 1ED7512D61A for ; Wed, 4 May 2016 05:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=K5tZNepY; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=F7R2oWMF 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 3Lv2lbSMLvn0 for ; Wed, 4 May 2016 05:03:30 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1167712D60E for ; Wed, 4 May 2016 05:03:17 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 586A220D44 for ; Wed, 4 May 2016 08:03:16 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute2.internal (MEProxy); Wed, 04 May 2016 08:03:16 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=/bbyS5Z9ZlsfXHUBRUpThZgrtfM=; b=K5tZNe pYy60EnFQNrzZpdvhsdZazQQVmZBQKkNRPfAoUtC6yrkt3RCg1FAkMGBFpRIhQT/ Nz+KvEnGx7BtpuFZuRkEm6R96UmHBOnQ8CB1Jn8r2Pq8PpWPefJVtz6QSZzpiy+C Fb81IRk1BBBYf9bzNwRJCcKPkpZA2x70kPRD4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=/bbyS5Z9ZlsfXHU BRUpThZgrtfM=; b=F7R2oWMFZ11X7t0+QJ4qixbYH6TvC0S+dVdQb2AO1II/V3J PNMi4u72XQt0sAiV7uXHKujOqjtu3y6dpL/CYNzfb1h5fs1+gD+d78mm7c6lGD+H qzuMEbngO7ZXUezZOTnX+TOHoPd+Jv81dhSZEX/MrGhbc6D7iG8QHH/thX6s= Received: by web5.nyi.internal (Postfix, from userid 99) id 224B4A71676; Wed, 4 May 2016 08:03:16 -0400 (EDT) Message-Id: <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> X-Sasl-Enc: ZUFeYNxg/jGoIkxxtQL8WVqG7dhxBH3gr4NxuS4G0vEn 1462363396 From: Alexey Melnikov To: Mirja Kuehlewind (IETF) MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-2227b085 Date: Wed, 04 May 2016 13:03:16 +0100 In-Reply-To: References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 04 May 2016 12:03:36 -0000 Hi Mirja, On Wed, May 4, 2016, at 12:45 PM, Mirja Kuehlewind (IETF) wrote: > Hi Alexey, >=20 >=20 > > Am 04.05.2016 um 13:37 schrieb Alexey Melnikov : > >=20 > > Hi Mirja, > >=20 > >> On 4 May 2016, at 12:13, Mirja Kuehlewind wrote: > >>=20 > >> However, the one part that does actually concern me is: > >> "When using DRMP priority information, Diameter nodes MUST use the > >> default priority for transactions that do not have priority specified > >> in a DRMP AVP." > >> This part seems dangerous and I would proposed to instead basically ha= ve > >> to different queues: one if a priority is defined and another one for > >> requests without priority indication to make sure that requests out of > >> the second queue will be served at some point in time and cannot be > >> starved by other low priority requests completely. > >=20 > > I think I disagree with you: default priority handling is orthogonal to= the number of queues used. Some implementations would use one queue per pr= iority, so you are effectively suggesting that no priority is treated as it= s own priority. I think this is an implementation detail. > >=20 > >=20 > Yes, queues are implementation details. That was just meant as an > illustration. My point it, I don=E2=80=99t think all requests without pri= ority > should get an default priority assigned Why not? Why not assigning a priority any different than assigning a unique priority? (SMTP Priority extension RFC which I edited made the same choice: https://tools.ietf.org/html/rfc6710) > (and especially not a very low > priority). True, but the default is mid range. > Further it has to be ensured that requests that don=E2=80=99t assign a > priority do not get starved (as they might be important). That I agree with. However the whole point of priorities is that higher priority messages can starve lower priority messages. Using emergency services as an example: during normal operations all messages will have default priority (no priority). During an emergency, some messages will have high priority which might starve no priority messages (regular traffic). From nobody Wed May 4 07:03: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 2913412D508 for ; Wed, 4 May 2016 07:03:18 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 WJ-2AB9zCuGo for ; Wed, 4 May 2016 07:03:14 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 2B74112D504 for ; Wed, 4 May 2016 07:03:13 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:59215 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 1axxOM-002w90-IV for dime@ietf.org; Wed, 04 May 2016 07:03:12 -0700 To: dime@ietf.org References: <20160428150420.27801.59309.idtracker@ietfa.amsl.com> From: Steve Donovan Message-ID: <572A011A.4060901@usdonovans.com> Date: Wed, 4 May 2016 09:03:06 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160428150420.27801.59309.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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] Alexey Melnikov's No Objection on draft-ietf-dime-drmp-05: (with COMMENT) 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, 04 May 2016 14:03:18 -0000 I'm responding to the comments received in the order received. Please see my responses inline. Regards, Steve On 4/28/16 10:04 AM, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-dime-drmp-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In Section 6: excuse my ignorance, but how can priority information be > conveyed to non-supporting endpoints (in 2 places)? And what is the > point,as they don't support the extension? SRD> This is to cover the case where there exists a Diameter client that does not support the DRMP mechanism originates a request. An agent that does support the mechanism can, in this case, add the DRMP AVP to the message if it has the information needed to accurately add the priority information. > > In 9.1: it would be better to just have a table, instead of copying and > modifying lots of text. SRD> That's another way of presenting the information. I think the existing approach works as well. > > It would be good to have a short sentence saying how this extension > affects non upgraded agents. SRD> I don't understand this comment. This does not impact non supporting Diameter nodes. A non supporting agent will just ignore the DRMP AVP. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed May 4 07:31:08 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 A219712D677 for ; Wed, 4 May 2016 07:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 VuacBXts0-oC for ; Wed, 4 May 2016 07:31:04 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763CF12D582 for ; Wed, 4 May 2016 07:31:04 -0700 (PDT) Received: (qmail 15709 invoked from network); 4 May 2016 16:31:02 +0200 Received: from p5dec2412.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.36.18) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 4 May 2016 16:31:01 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> Date: Wed, 4 May 2016 16:31:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 04 May 2016 14:31:07 -0000 Hi Alexey, see below. > Am 04.05.2016 um 14:03 schrieb Alexey Melnikov = : >=20 > Hi Mirja, >=20 > On Wed, May 4, 2016, at 12:45 PM, Mirja Kuehlewind (IETF) wrote: >> Hi Alexey, >>=20 >>=20 >>> Am 04.05.2016 um 13:37 schrieb Alexey Melnikov = : >>>=20 >>> Hi Mirja, >>>=20 >>>> On 4 May 2016, at 12:13, Mirja Kuehlewind = wrote: >>>>=20 >>>> However, the one part that does actually concern me is: >>>> "When using DRMP priority information, Diameter nodes MUST use the >>>> default priority for transactions that do not have priority = specified >>>> in a DRMP AVP." >>>> This part seems dangerous and I would proposed to instead basically = have >>>> to different queues: one if a priority is defined and another one = for >>>> requests without priority indication to make sure that requests out = of >>>> the second queue will be served at some point in time and cannot be >>>> starved by other low priority requests completely. >>>=20 >>> I think I disagree with you: default priority handling is orthogonal = to the number of queues used. Some implementations would use one queue = per priority, so you are effectively suggesting that no priority is = treated as its own priority. I think this is an implementation detail. >>>=20 >>>=20 >> Yes, queues are implementation details. That was just meant as an >> illustration. My point it, I don=E2=80=99t think all requests without = priority >> should get an default priority assigned >=20 > Why not? Why not assigning a priority any different than assigning a > unique priority? >=20 > (SMTP Priority extension RFC which I edited made the same choice: > https://tools.ietf.org/html/rfc6710) >=20 >> (and especially not a very low >> priority). >=20 > True, but the default is mid range. >=20 >> Further it has to be ensured that requests that don=E2=80=99t assign = a >> priority do not get starved (as they might be important). >=20 > That I agree with. However the whole point of priorities is that = higher > priority messages can starve lower priority messages. Using emergency > services as an example: during normal operations all messages will = have > default priority (no priority). During an emergency, some messages = will > have high priority which might starve no priority messages (regular > traffic). The point is, if you explicitly indicate that you have a lower priority, = you are okay to be starved. However, if you don=E2=80=99t indicate = anything (maybe just because you have not been aware that it is possible = to do so), you might have the same or even a higher priority, and in = this case it=E2=80=99s not okay to be starved. Mirja From nobody Wed May 4 08:52:03 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 2639912D730; Wed, 4 May 2016 08:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 UNcFCt7BLkqU; Wed, 4 May 2016 08:51:59 -0700 (PDT) Received: from mailport8.csra.com (mailport8.csra.com [131.131.97.26]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD7912D721; Wed, 4 May 2016 08:45:46 -0700 (PDT) Received: from csrrdu1exm021.corp.csra.com (HELO mail.csra.com) ([10.8.2.21]) by mailport8.csra.com with ESMTP/TLS/AES256-SHA; 04 May 2016 11:46:09 -0400 Received: from CSRRDU1EXM025.corp.csra.com (10.8.2.25) by CSRRDU1EXM022.corp.csra.com (10.8.2.22) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 4 May 2016 11:45:43 -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.1130.005; Wed, 4 May 2016 11:45:43 -0400 From: "Gunn, Janet P" To: "Mirja Kuehlewind (IETF)" , Alexey Melnikov Thread-Topic: =?utf-8?B?W0RpbWVdIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWll?= =?utf-8?Q?tf-dime-drmp-05:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHRpfX802HZewL1w0WTgzzKloaSGZ+o6eMAgAACTICAAATUAIAAKU2A///PyMA= Date: Wed, 4 May 2016 15:45:43 +0000 Message-ID: References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> In-Reply-To: <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-dime-drmp@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 04 May 2016 15:52:02 -0000 TXkgY29tbWVudCBiZWxvdy4NCkphbmV0DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWly amEgS3VlaGxld2luZCAoSUVURikNClNlbnQ6IFdlZG5lc2RheSwgTWF5IDA0LCAyMDE2IDEwOjMx IEFNDQpUbzogQWxleGV5IE1lbG5pa292IDxhYW1lbG5pa292QGZhc3RtYWlsLmZtPg0KQ2M6IGRy YWZ0LWlldGYtZGltZS1kcm1wQGlldGYub3JnOyBkaW1lLWNoYWlyc0BpZXRmLm9yZzsgZGltZUBp ZXRmLm9yZzsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0RpbWVdIE1p cmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZGltZS1kcm1wLTA1OiAod2l0 aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQpIaSBBbGV4ZXksDQoNCnNlZSBiZWxvdy4NCg0KVGhl IHBvaW50IGlzLCBpZiB5b3UgZXhwbGljaXRseSBpbmRpY2F0ZSB0aGF0IHlvdSBoYXZlIGEgbG93 ZXIgcHJpb3JpdHksIHlvdSBhcmUgb2theSB0byBiZSBzdGFydmVkLiBIb3dldmVyLCBpZiB5b3Ug ZG9u4oCZdCBpbmRpY2F0ZSBhbnl0aGluZyAobWF5YmUganVzdCBiZWNhdXNlIHlvdSBoYXZlIG5v dCBiZWVuIGF3YXJlIHRoYXQgaXQgaXMgcG9zc2libGUgdG8gZG8gc28pLCB5b3UgbWlnaHQgaGF2 ZSB0aGUgc2FtZSBvciBldmVuIGEgaGlnaGVyIHByaW9yaXR5LCBhbmQgaW4gdGhpcyBjYXNlIGl0 4oCZcyBub3Qgb2theSB0byBiZSBzdGFydmVkLg0KDQpNaXJqYQ0KPEpQRz4gSWYgYSBtZXNzYWdl IGNvbWVzIGluIHdpdGhvdXQgYSBwcmlvcml0eSwgaW50byBhIHN5c3RlbSB3aGljaCBzZXJ2ZXMg bWVzc2FnZXMgYmFzZWQgb24gcHJpb3JpdHkgKHJlZ2FyZGxlc3Mgb2YgdGhlIHNwZWNpZmljIG1l Y2hhbmlzbXMpeW91IGhhdmUgdHdvIG9wdGlvbnMNCjEtIERpc2NhcmQgdGhlIG1lc3NhZ2UgKE5v dCBhIGdvb2QgaWRlYSBpbiBtb3N0IHN5c3RlbXMpDQoyIC0gQXNzaWduIHRoZSBtZXNzYWdlIGFu IEFSQklUUkFSWSBwcmlvcml0eSAod2UgY2FsbCB0aGlzIGFyYml0cmFyeSB2YWx1ZSB0aGUgImRl ZmF1bHQgcHJpb3JpdHkiKQ0KDQpZb3UgY2FuIChhbmQgcHJvYmFibHkgd2lsbCkgYXJndWUgJ3Rp bCB0aGUgY293cyBjb21lIGhvbWUgb24gd2hhdCB0aGF0IGFyYml0cmFyeS9kZWZhdWx0IHZhbHVl IFNIT1VMRCBCRS4gIEFuZCBkaWZmZXJlbnQgc3l0ZW1zL2FwcGxpY2F0aW9ucyBtaWdodCBoYXZl IGRpZmZlcmVudCAiZGVmYXVsdCB2YWx1ZXMiLg0KDQpCdXQgSSBkb24ndCB0aGluayB0aGVyZSBz aG91bGQgYmUgYW55IGFyZ3VtZW50IHRoYXQsIGlmIGEgbWVzc2FnZSBjb21lcyBpbiB3aXRob3V0 IGEgcHJpb3JpdHksIHlvdSBuZWVkIHRvIGFzc2lnbiBpdCBhIHByaW9yaXR5Lg0KDQo8L0pQRz4N Cg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpE aU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kaW1lDQoNClRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIHRyYW5zbWlzc2lv biBjb250YWlucyBpbmZvcm1hdGlvbiBmcm9tIENTUkEgdGhhdCBtYXkgYmUgYXR0b3JuZXktY2xp ZW50IHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5IG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0 aW9uIGluIHRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBvbmx5IGZvciB1c2UgYnkgdGhlIGluZGl2 aWR1YWwocykgdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBiZWxpZXZlIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIGNvbnRhY3QgbWUgaW1tZWRp YXRlbHkgYW5kIGJlIGF3YXJlIHRoYXQgYW55IHVzZSwgZGlzY2xvc3VyZSwgY29weWluZyBvciBk aXN0cmlidXRpb24gb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBw cm9oaWJpdGVkLiBOT1RFOiBSZWdhcmRsZXNzIG9mIGNvbnRlbnQsIHRoaXMgZW1haWwgc2hhbGwg bm90IG9wZXJhdGUgdG8gYmluZCBDU1JBIHRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1 bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgd3JpdHRlbiBhZ3JlZW1lbnQgb3IgZ292ZXJubWVu dCBpbml0aWF0aXZlIGV4cHJlc3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2YgZW1haWwgZm9yIHN1 Y2ggcHVycG9zZS4NCg== From nobody Wed May 4 09:05: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 BBEC412DA6F for ; Wed, 4 May 2016 09:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 PnvgYl49nJKT for ; Wed, 4 May 2016 09:05:10 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE27812D8A0 for ; Wed, 4 May 2016 08:57:29 -0700 (PDT) Received: (qmail 19537 invoked from network); 4 May 2016 17:50:44 +0200 Received: from p5dec2412.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.36.18) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 4 May 2016 17:50:44 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Wed, 4 May 2016 17:50:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> To: "Gunn, Janet P" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-dime-drmp@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , The IESG , Alexey Melnikov Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 04 May 2016 16:05:11 -0000 Hi Janet, there are clearly more options than the two mention below. E.g. one option is the one explained in my initial comment: hhaving two = queues, that are both served with a certain rate. I=E2=80=99m sure there are more (and potentially more complex) solutions = to this problem as well. Assigning an arbitrary priority is not the right option from my point of = view and can actually hurt the systems. Mirja =20 > Am 04.05.2016 um 17:45 schrieb Gunn, Janet P : >=20 > My comment below. > Janet >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Mirja = Kuehlewind (IETF) > Sent: Wednesday, May 04, 2016 10:31 AM > To: Alexey Melnikov > Cc: draft-ietf-dime-drmp@ietf.org; dime-chairs@ietf.org; = dime@ietf.org; The IESG > Subject: Re: [Dime] Mirja K=C3=BChlewind's Discuss on = draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) >=20 > Hi Alexey, >=20 > see below. >=20 > The point is, if you explicitly indicate that you have a lower = priority, you are okay to be starved. However, if you don=E2=80=99t = indicate anything (maybe just because you have not been aware that it is = possible to do so), you might have the same or even a higher priority, = and in this case it=E2=80=99s not okay to be starved. >=20 > Mirja > If a message comes in without a priority, into a system which = serves messages based on priority (regardless of the specific = mechanisms)you have two options > 1- Discard the message (Not a good idea in most systems) > 2 - Assign the message an ARBITRARY priority (we call this arbitrary = value the "default priority") >=20 > You can (and probably will) argue 'til the cows come home on what that = arbitrary/default value SHOULD BE. And different sytems/applications = might have different "default values". >=20 > But I don't think there should be any argument that, if a message = comes in without a priority, you need to assign it a priority. >=20 > >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 > This electronic message transmission contains information from CSRA = that may be attorney-client privileged, proprietary or confidential. The = information 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 agreement or government initiative = expressly permitting the use of email for such purpose. From nobody Wed May 4 09:06: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 B2DB012DC8E; Wed, 4 May 2016 09:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.139 X-Spam-Level: X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 2IEYuJzFYub6; Wed, 4 May 2016 09:06:26 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 42E7512DA2E; Wed, 4 May 2016 08:58:21 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:59914 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 1axzBm-000OAl-15; Wed, 04 May 2016 08:58:20 -0700 To: lionel.morand@orange.com, Alissa Cooper , "iesg@ietf.org" References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Steve Donovan Message-ID: <572A1C14.5020907@usdonovans.com> Date: Wed, 4 May 2016 10:58:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------010506000406040901070503" X-OutGoing-Spam-Status: No, score=-0.7 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: Cc: "draft-ietf-dime-drmp@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 04 May 2016 16:06:27 -0000 This is a multi-part message in MIME format. --------------010506000406040901070503 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Responding to both Alissa's comments and Lionel's responses. Regards, Steve On 5/3/16 6:42 PM, lionel.morand@orange.com wrote: > Hi Alissa, > > Thank you for your review. > Please find below some clarifications, waiting for authors feeback. > > Regards, > > Lionel > > Envoyé depuis Surface > > *De :* Alissa Cooper > *Envoyé :* ‎mardi‎ ‎3‎ ‎mai‎ ‎2016 ‎23‎:‎31 > *À :* iesg@ietf.org > *Cc :* draft-ietf-dime-drmp@ietf.org > , Lionel MORAND > , dime-chairs@ietf.org > , Lionel MORAND > , dime@ietf.org > > Alissa Cooper has entered the following ballot position for > draft-ietf-dime-drmp-05: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > (1) Given the two key security threats identified in Section 11 -- that > authorized nodes can issue requests with artificially high priority in > order to get better treatment, and that unauthorized intermediaries can > modify the priorities that senders set -- I don't see how it is > legitimate to claim that either 5.1 or 5.2 are appropriate use cases for > DRMP. The spec seems to assume that this mechanism will only be used in > scenarios where nodes and agents have some out-of-band trust relationship > established with each other (the shepherd write-up talks about a "trusted > environment"), but that is certainly not the case in many disaster and > emergency scenarios. If that really is a limitation on the scope of > applicability of this mechanism, that should be stated in the document, > and those use cases should either be removed or modified to explain the > limitations on their applicability. > > [LM] I think that what is missing is that Diameter is mainly (if not > only) used in mobile operator networks. The text makes reference to > the RFC7683 where the overoload contgrol mechanism is introduced to > solve overload situations in telco networks. This additional mechanism > is seen as a complement of this overload control mechanism. Now, if it > is understood that it is a mechanism defined for “trusted environment†> i.e. mobile networks, the use of priority indications in emergency and > disaster scenarios seems legitimate. SRD> I would state it a little differently, but I agree that there needs to be some clarification here. We intentionally did not specify how priorities are set in this document as those priorities need to take into account application specific knowledge. This document is, instead, focused on how priority information is transported and used by nodes receiving the priority. The thing that is missing is a statement that this mechanism only works when the definition of priority values is done in a consistent manner for all applications used by a Diameter network. It is my understanding that 3GPP will be defining priorities across its set of applications and that this will make sure that one application does not improperly take advantage of the mechanism at the expense of other applications. I also expect that 3GPP will factor in the 5.1 and 5.2 use cases when doing this work. SRD> This does beg the question of whether or not we need to support interworking between multiple "DRMP priority schemes", where one Diameter network assumes priority scheme 1 and another assumes priority scheme 2 and the two priority schemes were defined completely independently. The 3GPP priority definition would be an example of a priority scheme. The mechanism, as currently defined, does not support this use case. SRD> We could fix this by using a name-space concept similar to that used by SIP. Or we could say that this mechanism only works in a trusted environment. The working group should decide which approach to take. > > (2) Section 6 says: > > "The mechanism for how the agent determines which requests are > throttled is implementation dependent and is outside the scope of > this document." > > How is a node supposed to determine how to set its priorities if each > agent makes implementation-specific decisions about what those priorities > mean? I understood the document to be saying that Diameter applications > would have to define what he priority levels mean within their own > contexts, but then I would have expected the interpretation of priorities > amongst all nodes and agents implementing the same application to be the > same. > > [LM] I understand. I think that the text should say “The mechanism for > how the agent determines which requests are c(candidates) to be > throttledâ€. And, when there are requests to throttle, the priority > indication is used to determine “which requests to route first, which > requests to throttle and where the request is routed. For instance, > requests with higher priority might have a lower probability of being > throttled. â€. SRD> I agree with Lionel's suggestion here. > > (3) Section 8 says: > > "Diameter nodes SHOULD use the PRIORITY_10 priority as this default > value." > > If the determination of the priority schemes are all > application-specific, how is it appropriate for this spec to define what > the default priority should be for all applications? Shouldn't > applications specify their own defaults? > > [LM] it is needed to take into account that the use of priority > indication in Diameter will be optional and that legacy implementation > will not include any priority indication in Diameter requests. After > discussion, it was decided that requests without priority should be > handled as with a priority set to 10. This makes the difference with > requests with an explicit lower priorities and other with higher > priorities. 10 is used as “average†priority, with the possibility of > specific operator policies to use another value. SRD> As stated by Alexey in a separate email, I don't see the issue with a default value. Alexey and Lionel have explained why, so I won't repeat. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 11 says: "DRMP gives Diameter nodes the ability to influence > which requests are throttled during overload scenarios." But the > information is not limited to use during overload scenarios, and the spec > specifically allows its use for prioritized routing in absence of > overload. This should be stated here too. > > [LM] right. SRD> This is already addressed in the paragraph following the one above: The DRMP mechanism can also be used to influence the order in which Diameter messages are handled by Diameter nodes. The above attacks have a potentially greater impact in this scenario as the priority indication impacts the handling of all requests at all times, independent of the overload status of Diameter nodes in the Diameter network. > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques 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 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 delete 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. --------------010506000406040901070503 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Responding to both Alissa's comments and Lionel's responses.

Regards,

Steve

On 5/3/16 6:42 PM, lionel.morand@orange.com wrote:
Hi Alissa,

Thank you for your review.
Please find below some clarifications, waiting for authors feeback.

Regards,

Lionel

Envoyé depuis Surface

De : Alissa Cooper
Envoyé : ‎mardi‎ ‎3‎ ‎mai‎ ‎2016 ‎23‎:‎31
À : iesg@ietf.org
Cc : draft-ietf-dime-drmp@ietf.org, Lionel MORAND, dime-chairs@ietf.org, Lionel MORAND, dime@ietf.org

Alissa Cooper has entered the following ballot position for
draft-ietf-dime-drmp-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) Given the two key security threats identified in Section 11 -- that
authorized nodes can issue requests with artificially high priority in
order to get better treatment, and that unauthorized intermediaries can
modify the priorities that senders set -- I don't see how it is
legitimate to claim that either 5.1 or 5.2 are appropriate use cases for
DRMP. The spec seems to assume that this mechanism will only be used in
scenarios where nodes and agents have some out-of-band trust relationship
established with each other (the shepherd write-up talks about a "trusted
environment"), but that is certainly not the case in many disaster and
emergency scenarios. If that really is a limitation on the scope of
applicability of this mechanism, that should be stated in the document,
and those use cases should either be removed or modified to explain the
limitations on their applicability. 

[LM] I think that what is missing is that Diameter is mainly (if not only) used in mobile operator networks. The text makes reference to the RFC7683 where the overoload contgrol mechanism is introduced to solve overload situations in telco networks. This additional mechanism is seen as a complement of this overload control mechanism. Now, if it is understood that it is a mechanism defined for “trusted environment†i.e. mobile networks, the use of priority indications in emergency and disaster scenarios seems legitimate.
SRD> I would state it a little differently, but I agree that there needs to be some clarification here.  We intentionally did not specify how priorities are set in this document as those priorities need to take into account application specific knowledge.  This document is, instead, focused on how priority information is transported and used by nodes receiving the priority.  The thing that is missing is a statement that this mechanism only works when the definition of priority values is done in a consistent manner for all applications used by a Diameter network.  It is my understanding that 3GPP will be defining priorities across its set of applications and that this will make sure that one application does not improperly take advantage of the mechanism at the expense of other applications.  I also expect that 3GPP will factor in the 5.1 and 5.2 use cases when doing this work.

SRD> This does beg the question of whether or not we need to support interworking between multiple "DRMP priority schemes", where one Diameter network assumes priority scheme 1 and another assumes priority scheme 2 and the two priority schemes were defined completely independently.  The 3GPP priority definition would be an example of a priority scheme.  The mechanism, as currently defined, does not support this use case.

SRD> We could fix this by using a name-space concept similar to that used by SIP.  Or we could say that this mechanism only works in a trusted environment.  The working group should decide which approach to take.



(2) Section 6 says:

    "The mechanism for how the agent determines which requests are
       throttled is implementation dependent and is outside the scope of
       this document."

How is a node supposed to determine how to set its priorities if each
agent makes implementation-specific decisions about what those priorities
mean? I understood the document to be saying that Diameter applications
would have to define what he priority levels mean within their own
contexts, but then I would have expected the interpretation of priorities
amongst all nodes and agents implementing the same application to be the
same.

[LM] I understand. I think that the text should say “The mechanism for how the agent determines which requests are c(candidates) to be throttledâ€. And, when there are requests to throttle, the priority indication is used to determine “which requests to route first, which requests to throttle and where the request is routed.  For instance, requests with higher  priority might have a lower probability of being throttled. â€.
SRD> I agree with Lionel's suggestion here.

(3) Section 8 says:

 "Diameter nodes SHOULD use the PRIORITY_10 priority as this default
value."
  
If the determination of the priority schemes are all
application-specific, how is it appropriate for this spec to define what
the default priority should be for all applications? Shouldn't
applications specify their own defaults?

[LM] it is needed to take into account that the use of priority indication in Diameter will be optional and that legacy implementation will not include any priority indication in Diameter requests. After discussion, it was decided that requests without priority should be handled as with a priority set to 10. This makes the difference with requests with an explicit lower priorities and other with higher priorities. 10 is used as “average†priority, with the possibility of specific operator policies to use another value.
SRD> As stated by Alexey in a separate email, I don't see the issue with a default value.  Alexey and Lionel have explained why, so I won't repeat.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 11 says: "DRMP gives Diameter nodes the ability to influence
which requests are throttled during overload scenarios." But the
information is not limited to use during overload scenarios, and the spec
specifically allows its use for prioritized routing in absence of
overload. This should be stated here too.

[LM] right.
SRD> This is already addressed in the paragraph following the one above:

   The DRMP mechanism can also be used to influence the order in which
   Diameter messages are handled by Diameter nodes.  The above attacks
   have a potentially greater impact in this scenario as the priority
   indication impacts the handling of all requests at all times,
   independent of the overload status of Diameter nodes in the Diameter
   network.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques 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 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 delete 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.

--------------010506000406040901070503-- From nobody Wed May 4 09:36: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 95C8412D10D; Wed, 4 May 2016 09:36:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 hV3TAwghXQuC; Wed, 4 May 2016 09:36:10 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 6225912DA2F; Wed, 4 May 2016 09:25:39 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:60054 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 1axzcE-000poH-NT; Wed, 04 May 2016 09:25:38 -0700 To: Ben Campbell , The IESG References: <20160504023124.8242.52368.idtracker@ietfa.amsl.com> From: Steve Donovan Message-ID: <572A227D.1040203@usdonovans.com> Date: Wed, 4 May 2016 11:25:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160504023124.8242.52368.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org Subject: Re: [Dime] Ben Campbell's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 04 May 2016 16:36:12 -0000 My comments inline. Steve On 5/3/16 9:31 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-dime-drmp-05: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have a few concerns that I think need some discussion. > > 1) Priority between applications: The fact that agents can apply priority > for messages from multiple applications without knowledge of those > applications seems dangerous. Let's say application A is a critical > infrastructure application, and application B is not. But clients for > application B might set requests to have a higher priority than do > clients for application A. Further, application B could become a DoS > vector for application A. One potential (and likely half-baked) way to > mitigate this would be to say that nodes that are not "application aware" > can only apply priority among messages for the same application. SRD> This is similar to saying that priority setting across applications need to be set in a consistent way. We might need to define the "priority scheme" or some similar concept as sketched out in my response to Alissa's DISCUSS. > > 2) Priority between clients of the same application: If you have multiple > clients for the same application, don't they need to use the same > prioritization strategy? How is this to be managed? SRD> It is not directly defined. This is back to the question of whether or not the mechanism is constrained to only work in a trusted environment. > > 3) Out of order requests: The draft explicitly allows agents to re-route > and even explicitly re-order messages. Is it safe to have a > non-application aware node change the order of messages? SRD> This mechanism doesn't change the need for Diameter nodes to handle messages arriving out of order. This exists in any protocol that has agents/proxies. > > 4) I am nervous about the idea that clients and servers would use a > generic message priority mechanism to manage the allocation of resources > that result from a requests and answers. It seems like that should be > based on application specific rules and information. (Now, if the point > is that these same AVPs might be used in an application according to > application specific rules, that might be okay--but then you might run > into issues where application-agnostic agents don't know the difference.) SRD> The definition of what different priority levels mean will reflect the application specific knowledge. Agents just route requests and with the introduction of DOIC, sometimes throttle them. The agent doesn't need anything but the priority value, as long as the priority values are defined consistently across all applications. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > General: I approached this assuming prioritization would matter only in > overload scenarios. But I gather you envision using this in non-overload > scenarios? (This interacts with my discuss point about the use of DRMP to > prioritize resource allocation that result result from successful > diameter transactions.) Use case 5.3 is a bit worrisome in this context. SRD> I don't understand the concern. > > > -6, list item 4: Are there really use cases for answer senders to set a > different priority on the answer than was on the request? That seems to > add quite a bit of complexity. SRD> This was an explicit conversation within the working group. I don't recall the specific use case off the top of my head, but this was changed to the current wording after discussions within the working group. I can go back to the email archive to refresh my memory if necessary. > > - 6, list item 8: I'm not sure what it means for a client to prioritize > answers to it's own requests. SRD> The client could choose to complete the transaction, and initiate other dependent actions, based on the priority received in the answer message. It is those dependent actions -- setting up a data channel, authorizing call completion, etc -- that would be impacted by the priorities received in the answer. > > -8, "Diameter nodes SHOULD > include Diameter routing message priority in the DRMP AVP in all > Diameter request messages." : > Does that apply to all nodes that touch a request, or just the request > originator? SRD> This statement was meant to apply to the request originator. The statement should be updated. > > -- "Diameter nodes MUST use the priority indicated in the DRMP AVP > carried in the answer message, if it exists." > The MUST seems odd, since paying attention to the priority in the initial > request was only SHOULD. SRD> The wording here is cumbersome. The full paragraph is as follows: When determining the priority to apply to answer messages, Diameter nodes MUST use the priority indicated in the DRMP AVP carried in the answer message, if it exists. Otherwise, the Diameter node MUST use the priority indicated in the DRMP AVP of the associated request message. This is meant to say that a Diameter node receiving an answer message MUST use the priority value in the answer message when processing the message. If there is no DRMP AVP in the answer message then the receiving node uses the priority that was in the request message. I'd be happy to re-craft this to be more clear. > > -- "Another is to use the Proxy-Info > mechanism defined in [RFC6733].": > That probably needs some elaboration. SRD> A reference to the document that defines Proxy-Info isn't sufficient? > > From nobody Wed May 4 09:39: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 BC3DC12D6FC; Wed, 4 May 2016 09:39:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ROyiQVvUNu8T; Wed, 4 May 2016 09:39:19 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 81C3A12DCEB; Wed, 4 May 2016 09:29:01 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:60072 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 1axzfT-000tTF-1k; Wed, 04 May 2016 09:28:59 -0700 To: Alexey Melnikov , "Mirja Kuehlewind (IETF)" References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> From: Steve Donovan Message-ID: <572A2346.5050801@usdonovans.com> Date: Wed, 4 May 2016 11:28:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-1.0 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: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 04 May 2016 16:39:21 -0000 I agree with Alexey. I don't see the issue with the default value. Alexey has done a better job of explaining why than I could. Steve On 5/4/16 7:03 AM, Alexey Melnikov wrote: > Hi Mirja, > > On Wed, May 4, 2016, at 12:45 PM, Mirja Kuehlewind (IETF) wrote: >> Hi Alexey, >> >> >>> Am 04.05.2016 um 13:37 schrieb Alexey Melnikov : >>> >>> Hi Mirja, >>> >>>> On 4 May 2016, at 12:13, Mirja Kuehlewind wrote: >>>> >>>> However, the one part that does actually concern me is: >>>> "When using DRMP priority information, Diameter nodes MUST use the >>>> default priority for transactions that do not have priority specified >>>> in a DRMP AVP." >>>> This part seems dangerous and I would proposed to instead basically have >>>> to different queues: one if a priority is defined and another one for >>>> requests without priority indication to make sure that requests out of >>>> the second queue will be served at some point in time and cannot be >>>> starved by other low priority requests completely. >>> I think I disagree with you: default priority handling is orthogonal to the number of queues used. Some implementations would use one queue per priority, so you are effectively suggesting that no priority is treated as its own priority. I think this is an implementation detail. >>> >>> >> Yes, queues are implementation details. That was just meant as an >> illustration. My point it, I don’t think all requests without priority >> should get an default priority assigned > Why not? Why not assigning a priority any different than assigning a > unique priority? > > (SMTP Priority extension RFC which I edited made the same choice: > https://tools.ietf.org/html/rfc6710) > >> (and especially not a very low >> priority). > True, but the default is mid range. > >> Further it has to be ensured that requests that don’t assign a >> priority do not get starved (as they might be important). > That I agree with. However the whole point of priorities is that higher > priority messages can starve lower priority messages. Using emergency > services as an example: during normal operations all messages will have > default priority (no priority). During an emergency, some messages will > have high priority which might starve no priority messages (regular > traffic). > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed May 4 09:44:43 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 3140112DBB0; Wed, 4 May 2016 09:44:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 o-7HmwjHpP4C; Wed, 4 May 2016 09:44:40 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 C054912D784; Wed, 4 May 2016 09:33:35 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:60093 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 1axzjv-000yiq-2w; Wed, 04 May 2016 09:33:35 -0700 To: "Mirja Kuehlewind (IETF)" , "Gunn, Janet P" References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> From: Steve Donovan Message-ID: <572A245A.8070507@usdonovans.com> Date: Wed, 4 May 2016 11:33:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: Cc: "draft-ietf-dime-drmp@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , The IESG , Alexey Melnikov Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 04 May 2016 16:44:42 -0000 Mirja, Your example of having two queues is just one way of implementing a default priority. Yes, as pointed out by Alexey, use of priority can result in starving of lower priority messages. This is by design and an explicit requirement of networks that handle emergency services. I'm not seeing the issue here. Steve On 5/4/16 10:50 AM, Mirja Kuehlewind (IETF) wrote: > Hi Janet, > > there are clearly more options than the two mention below. > > E.g. one option is the one explained in my initial comment: hhaving two queues, that are both served with a certain rate. > > I’m sure there are more (and potentially more complex) solutions to this problem as well. > > Assigning an arbitrary priority is not the right option from my point of view and can actually hurt the systems. > > Mirja > > >> Am 04.05.2016 um 17:45 schrieb Gunn, Janet P : >> >> My comment below. >> Janet >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Mirja Kuehlewind (IETF) >> Sent: Wednesday, May 04, 2016 10:31 AM >> To: Alexey Melnikov >> Cc: draft-ietf-dime-drmp@ietf.org; dime-chairs@ietf.org; dime@ietf.org; The IESG >> Subject: Re: [Dime] Mirja Kühlewind's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) >> >> Hi Alexey, >> >> see below. >> >> The point is, if you explicitly indicate that you have a lower priority, you are okay to be starved. However, if you don’t indicate anything (maybe just because you have not been aware that it is possible to do so), you might have the same or even a higher priority, and in this case it’s not okay to be starved. >> >> Mirja >> If a message comes in without a priority, into a system which serves messages based on priority (regardless of the specific mechanisms)you have two options >> 1- Discard the message (Not a good idea in most systems) >> 2 - Assign the message an ARBITRARY priority (we call this arbitrary value the "default priority") >> >> You can (and probably will) argue 'til the cows come home on what that arbitrary/default value SHOULD BE. And different sytems/applications might have different "default values". >> >> But I don't think there should be any argument that, if a message comes in without a priority, you need to assign it a priority. >> >> >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information 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 agreement or government initiative expressly permitting the use of email for such purpose. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed May 4 09:49:06 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 8755E12DBD2; Wed, 4 May 2016 09:48:59 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 8fWZbPIUISmG; Wed, 4 May 2016 09:48:58 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 802BE12D8C9; Wed, 4 May 2016 09:38:28 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:60115 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 1axzoe-0013Mq-Hd; Wed, 04 May 2016 09:38:28 -0700 To: Mirja Kuehlewind , The IESG References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> From: Steve Donovan Message-ID: <572A257F.7040408@usdonovans.com> Date: Wed, 4 May 2016 11:38:23 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 04 May 2016 16:49:00 -0000 Mirja had a question on the number or priority levels: As a starting point, most priority schemes for emergency services have at least five priority levels. If we assume, based on this, that emergency services need five values then this would be the minimum number of priority levels. We increased the number of priority values to reflect that there are multiple use cases specified. Other values would be used for the differentiated services and application specific priorities use cases. Steve On 5/4/16 6:13 AM, Mirja Kuehlewind wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Why do you need 15 different priority levels? Wouldn't be two enough for > all or your use cases? > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed May 4 09:50:56 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 8BCBA12D7BB; Wed, 4 May 2016 09:50:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 RN1JHBPn5Yzr; Wed, 4 May 2016 09:50:49 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 3B80212DCDC; Wed, 4 May 2016 09:41:28 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:60130 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 1axzrV-0016Ac-U8; Wed, 04 May 2016 09:41:28 -0700 To: dime@ietf.org, The IESG , Alexey Melnikov References: <20160428150420.27801.59309.idtracker@ietfa.amsl.com> <572A011A.4060901@usdonovans.com> From: Steve Donovan Message-ID: <572A2631.5030501@usdonovans.com> Date: Wed, 4 May 2016 11:41:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <572A011A.4060901@usdonovans.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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] Alexey Melnikov's No Objection on draft-ietf-dime-drmp-05: (with COMMENT) 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, 04 May 2016 16:50:52 -0000 I'm resending this email with the IESG mailing list included. Apologies for the added mail. Steve On 5/4/16 9:03 AM, Steve Donovan wrote: > I'm responding to the comments received in the order received. > > Please see my responses inline. > > Regards, > > Steve > > On 4/28/16 10:04 AM, Alexey Melnikov wrote: >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-dime-drmp-05: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> In Section 6: excuse my ignorance, but how can priority information be >> conveyed to non-supporting endpoints (in 2 places)? And what is the >> point,as they don't support the extension? > SRD> This is to cover the case where there exists a Diameter client > that does not support the DRMP mechanism originates a request. An > agent that does support the mechanism can, in this case, add the DRMP > AVP to the message if it has the information needed to accurately add > the priority information. >> >> In 9.1: it would be better to just have a table, instead of copying and >> modifying lots of text. > SRD> That's another way of presenting the information. I think the > existing approach works as well. >> >> It would be good to have a short sentence saying how this extension >> affects non upgraded agents. > SRD> I don't understand this comment. This does not impact non > supporting Diameter nodes. A non supporting agent will just ignore > the DRMP AVP. >> >> >> _______________________________________________ >> 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 Wed May 4 09:59:29 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 364A412D1E2; Wed, 4 May 2016 09:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 TzNQuIQWKgsJ; Wed, 4 May 2016 09:59:19 -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 D647012D9D2; Wed, 4 May 2016 09:54:11 -0700 (PDT) Received: from csrrdu1exm022.corp.csra.com (HELO mail.csra.com) ([10.8.2.22]) by mailport7.csra.com with ESMTP/TLS/AES256-SHA; 04 May 2016 12:54:34 -0400 Received: from CSRRDU1EXM025.corp.csra.com (10.8.2.25) by CSRRDU1EXM028.corp.csra.com (10.8.2.28) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 4 May 2016 12:54:09 -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.1130.005; Wed, 4 May 2016 12:54:09 -0400 From: "Gunn, Janet P" To: "Mirja Kuehlewind (IETF)" Thread-Topic: =?utf-8?B?W0RpbWVdIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWll?= =?utf-8?Q?tf-dime-drmp-05:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHRpfX802HZewL1w0WTgzzKloaSGZ+o6eMAgAACTICAAATUAIAAKU2A///PyMCAAEZ/gP//zN+A Date: Wed, 4 May 2016 16:54:09 +0000 Message-ID: References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> 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.136.2.8] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-dime-drmp@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , The IESG , Alexey Melnikov Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 04 May 2016 16:59:22 -0000 Q29uY2VwdHVhbGx5LCB0aGF0ICgyIHF1ZXVlcykgYXBwcm9hY2ggRE9FUyBjb3JyZXNwb25kIHRv IGFzc2lnbmluZyBhIGRlZmF1bHQgcHJpb3JpdHkuDQoNCkluIHRoYXQgcGFydGljdWxhciBjYXNl LCB5b3UgYXJlIGFzc2lnbmluZyB0aGUgInVua25vd24gcHJpb3JpdHkiIG1lc3NhZ2VzIHRvICBw YXJ0aWNsYXIgcHJpb3JpdHkgdmFsdWUoIGEgdmFsdWUgdGhhdCBpcyBub3QgdXNlZCBieSB0aGUg bWVzc2FnZXMgd2l0aCAia25vd24gcHJpb3JpdHkiKSBhbmQgdGhlbiBlc3RhYmxpc2hpbmcgYSBz ZXBhcmF0ZSBxdWV1ZSAgZm9yIFRIQVQgcHJpb3JpdHkgdmFsdWUuDQoNCkkgYW0gbm90IHN1cmUg d2hldGhlciBpdCBpcyBhICJnb29kIGlkZWEiIG9yIG5vdCwgYnV0IGl0IGNlcnRhaW5seSBmaXRz IHdpdGhpbiB0aGUgY29uc3RyYWludHMgb2YgYSAiZGVmYXVsdCBwcmlvcml0eSIuDQoNCkphbmV0 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNaXJqYSBLdWVobGV3aW5kIChJ RVRGKSBbbWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXRdIA0KU2VudDogV2VkbmVzZGF5LCBNYXkg MDQsIDIwMTYgMTE6NTEgQU0NClRvOiBHdW5uLCBKYW5ldCBQIDxKYW5ldC5HdW5uQGNzcmEuY29t Pg0KQ2M6IEFsZXhleSBNZWxuaWtvdiA8YWFtZWxuaWtvdkBmYXN0bWFpbC5mbT47IGRyYWZ0LWll dGYtZGltZS1kcm1wQGlldGYub3JnOyBkaW1lLWNoYWlyc0BpZXRmLm9yZzsgZGltZUBpZXRmLm9y ZzsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0RpbWVdIE1pcmphIEvD vGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZGltZS1kcm1wLTA1OiAod2l0aCBESVND VVNTIGFuZCBDT01NRU5UKQ0KDQpIaSBKYW5ldCwNCg0KdGhlcmUgYXJlIGNsZWFybHkgbW9yZSBv cHRpb25zIHRoYW4gdGhlIHR3byBtZW50aW9uIGJlbG93Lg0KDQpFLmcuIG9uZSBvcHRpb24gaXMg dGhlIG9uZSBleHBsYWluZWQgaW4gbXkgaW5pdGlhbCBjb21tZW50OiBoaGF2aW5nIHR3byBxdWV1 ZXMsIHRoYXQgYXJlIGJvdGggc2VydmVkIHdpdGggYSBjZXJ0YWluIHJhdGUuDQoNCknigJltIHN1 cmUgdGhlcmUgYXJlIG1vcmUgKGFuZCBwb3RlbnRpYWxseSBtb3JlIGNvbXBsZXgpIHNvbHV0aW9u cyB0byB0aGlzIHByb2JsZW0gYXMgd2VsbC4NCg0KQXNzaWduaW5nIGFuIGFyYml0cmFyeSBwcmlv cml0eSBpcyBub3QgdGhlIHJpZ2h0IG9wdGlvbiBmcm9tIG15IHBvaW50IG9mIHZpZXcgYW5kIGNh biBhY3R1YWxseSBodXJ0IHRoZSBzeXN0ZW1zLg0KDQpNaXJqYQ0KDQogDQo+IEFtIDA0LjA1LjIw MTYgdW0gMTc6NDUgc2NocmllYiBHdW5uLCBKYW5ldCBQIDxKYW5ldC5HdW5uQGNzcmEuY29tPjoN Cj4gDQo+IE15IGNvbW1lbnQgYmVsb3cuDQo+IEphbmV0DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgTWlyamEgS3VlaGxld2luZCAoSUVURikNCj4gU2VudDogV2VkbmVzZGF5LCBN YXkgMDQsIDIwMTYgMTA6MzEgQU0NCj4gVG86IEFsZXhleSBNZWxuaWtvdiA8YWFtZWxuaWtvdkBm YXN0bWFpbC5mbT4NCj4gQ2M6IGRyYWZ0LWlldGYtZGltZS1kcm1wQGlldGYub3JnOyBkaW1lLWNo YWlyc0BpZXRmLm9yZzsgZGltZUBpZXRmLm9yZzsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+ IFN1YmplY3Q6IFJlOiBbRGltZV0gTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQt aWV0Zi1kaW1lLWRybXAtMDU6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBIaSBB bGV4ZXksDQo+IA0KPiBzZWUgYmVsb3cuDQo+IA0KPiBUaGUgcG9pbnQgaXMsIGlmIHlvdSBleHBs aWNpdGx5IGluZGljYXRlIHRoYXQgeW91IGhhdmUgYSBsb3dlciBwcmlvcml0eSwgeW91IGFyZSBv a2F5IHRvIGJlIHN0YXJ2ZWQuIEhvd2V2ZXIsIGlmIHlvdSBkb27igJl0IGluZGljYXRlIGFueXRo aW5nIChtYXliZSBqdXN0IGJlY2F1c2UgeW91IGhhdmUgbm90IGJlZW4gYXdhcmUgdGhhdCBpdCBp cyBwb3NzaWJsZSB0byBkbyBzbyksIHlvdSBtaWdodCBoYXZlIHRoZSBzYW1lIG9yIGV2ZW4gYSBo aWdoZXIgcHJpb3JpdHksIGFuZCBpbiB0aGlzIGNhc2UgaXTigJlzIG5vdCBva2F5IHRvIGJlIHN0 YXJ2ZWQuDQo+IA0KPiBNaXJqYQ0KPiA8SlBHPiBJZiBhIG1lc3NhZ2UgY29tZXMgaW4gd2l0aG91 dCBhIHByaW9yaXR5LCBpbnRvIGEgc3lzdGVtIHdoaWNoIHNlcnZlcyBtZXNzYWdlcyBiYXNlZCBv biBwcmlvcml0eSAocmVnYXJkbGVzcyBvZiB0aGUgc3BlY2lmaWMgbWVjaGFuaXNtcyl5b3UgaGF2 ZSB0d28gb3B0aW9ucw0KPiAxLSBEaXNjYXJkIHRoZSBtZXNzYWdlIChOb3QgYSBnb29kIGlkZWEg aW4gbW9zdCBzeXN0ZW1zKQ0KPiAyIC0gQXNzaWduIHRoZSBtZXNzYWdlIGFuIEFSQklUUkFSWSBw cmlvcml0eSAod2UgY2FsbCB0aGlzIGFyYml0cmFyeSB2YWx1ZSB0aGUgImRlZmF1bHQgcHJpb3Jp dHkiKQ0KPiANCj4gWW91IGNhbiAoYW5kIHByb2JhYmx5IHdpbGwpIGFyZ3VlICd0aWwgdGhlIGNv d3MgY29tZSBob21lIG9uIHdoYXQgdGhhdCBhcmJpdHJhcnkvZGVmYXVsdCB2YWx1ZSBTSE9VTEQg QkUuICBBbmQgZGlmZmVyZW50IHN5dGVtcy9hcHBsaWNhdGlvbnMgbWlnaHQgaGF2ZSBkaWZmZXJl bnQgImRlZmF1bHQgdmFsdWVzIi4NCj4gDQo+IEJ1dCBJIGRvbid0IHRoaW5rIHRoZXJlIHNob3Vs ZCBiZSBhbnkgYXJndW1lbnQgdGhhdCwgaWYgYSBtZXNzYWdlIGNvbWVzIGluIHdpdGhvdXQgYSBw cmlvcml0eSwgeW91IG5lZWQgdG8gYXNzaWduIGl0IGEgcHJpb3JpdHkuDQo+IA0KPiA8L0pQRz4N Cj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gRGlNRSBtYWlsaW5nIGxpc3QNCj4gRGlNRUBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCj4gDQo+IFRoaXMgZWxlY3Ryb25pYyBt ZXNzYWdlIHRyYW5zbWlzc2lvbiBjb250YWlucyBpbmZvcm1hdGlvbiBmcm9tIENTUkEgdGhhdCBt YXkgYmUgYXR0b3JuZXktY2xpZW50IHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5IG9yIGNvbmZpZGVu dGlhbC4gVGhlIGluZm9ybWF0aW9uIGluIHRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBvbmx5IGZv ciB1c2UgYnkgdGhlIGluZGl2aWR1YWwocykgdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIElmIHlv dSBiZWxpZXZlIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNl IGNvbnRhY3QgbWUgaW1tZWRpYXRlbHkgYW5kIGJlIGF3YXJlIHRoYXQgYW55IHVzZSwgZGlzY2xv c3VyZSwgY29weWluZyBvciBkaXN0cmlidXRpb24gb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVz c2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBOT1RFOiBSZWdhcmRsZXNzIG9mIGNvbnRlbnQs IHRoaXMgZW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gYmluZCBDU1JBIHRvIGFueSBvcmRlciBv ciBvdGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgd3JpdHRlbiBhZ3Jl ZW1lbnQgb3IgZ292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJlc3NseSBwZXJtaXR0aW5nIHRoZSB1 c2Ugb2YgZW1haWwgZm9yIHN1Y2ggcHVycG9zZS4NCg0K From nobody Wed May 4 10:02:55 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 E17B912D924; Wed, 4 May 2016 10:02:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504170252.8246.93112.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 10:02:52 -0700 Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org Subject: [Dime] Benoit Claise's No Objection on draft-ietf-dime-drmp-05: (with COMMENT) 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: Wed, 04 May 2016 17:02:53 -0000 Benoit Claise has entered the following ballot position for draft-ietf-dime-drmp-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - OLD: This also recognizes that more work has already taken place for established sessions and, as a result, it might be more harmful if the session update and session ending requests were to be throttled. NEW: This also recognizes that more work has already taken place for established sessions and, as a result, it might be more harmful from a signaling point of view if the session update and session ending requests were to be throttled. - 1. Request sender - The sender of a request, be it a Diameter Client or a Diameter Server, determines the relative priority of the request and includes that priority information in the request. Question: what is the risk of DMRP ending up as the DSCP, i.e. Every end point changes the value to best service, and in the end, it's useless, and uniquely set by the operator. From nobody Wed May 4 10:18:59 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 91A0112D6DC; Wed, 4 May 2016 10:18:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504171855.8268.79951.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 10:18:55 -0700 Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org Subject: [Dime] Kathleen Moriarty's No Objection on draft-ietf-dime-drmp-05: (with COMMENT) 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: Wed, 04 May 2016 17:18:55 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-dime-drmp-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'd like to see text clarifying the responses to Ben & Alissa's discuss points. From nobody Wed May 4 10:45: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 F13AC12D5C2; Wed, 4 May 2016 10:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 kX6D2l4uuMvS; Wed, 4 May 2016 10:45:03 -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 E496412D598; Wed, 4 May 2016 10:45:02 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u44HiwS5018595 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 May 2016 12:44:58 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Benoit Claise" Date: Wed, 04 May 2016 12:44:57 -0500 Message-ID: <1D4B3862-3423-4618-B0ED-103B99BBC79F@nostrum.com> In-Reply-To: <20160504170252.8246.93112.idtracker@ietfa.amsl.com> References: <20160504170252.8246.93112.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] Benoit Claise's No Objection on draft-ietf-dime-drmp-05: (with COMMENT) 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, 04 May 2016 17:45:05 -0000 I will jump in on one point, since this is related to the discussion on whether nodes need a common approach to selecting/interpreting priority values: On 4 May 2016, at 12:02, Benoit Claise wrote: > > - > > 1. Request sender - The sender of a request, be it a Diameter Client > or a Diameter Server, determines the relative priority of the > request and includes that priority information in the request. > > Question: what is the risk of DMRP ending up as the DSCP, i.e. > Every end point changes the value to best service, and in the end, > it's > useless, and uniquely set by the operator. I think there's a trusted network assumption here, which would include an assumption that trusted clients do not intentionally game the system. (in contrast with _accidentally_ gaming the system by using a different scheme to set priority values.) However, I think that this sort of assumption should be explicitly mentioned. IIRC, DOIC included some guidance about crossing trust boundaries; perhaps DRMP should do the same. (And I guess that does make it a bit like DSCP ;-) ) Ben. From nobody Wed May 4 11:26:53 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 CB3E412D122 for ; Wed, 4 May 2016 11:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=fTt9E4nz; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=JEqcW4mZ 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 ehnwhuLa71y0 for ; Wed, 4 May 2016 11:26:48 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAAB212D5B0 for ; Wed, 4 May 2016 11:26:44 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 664CC20A7A for ; Wed, 4 May 2016 14:18:46 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 04 May 2016 14:18:46 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=MXcLM GxlQJGLsEp3DuGot3g/PEs=; b=fTt9E4nzDAO+Kaz27SJkYkM+dl7/FYlzsFM8l G1b0IOTWpDM3D2DD0zALPjmwrPfkZ7Cyqq502T+vROniciIdsBjrlZIzcq3uwMuq 338KuSlPmhDINlSF2Z89qOu4/4XJgQD3m7glSBx0IafdNlY3XKXudF6gqVblJ4br T/qYGo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=MXcLMGxlQJGLsEp3DuGot3g/PEs=; b=JEqcW 4mZKKAluMDvoNQXL0A6n4ewSll8CyKgqYmVnbmnz0ycB6v2a9EATcMShBXiFrZQW kJc4j0lpWAOzNL1nVEw18kbM5oN13U+OU8mBRXpznwNa3g5EfrczwVQyll6/jcuE phZV3nR2PgDlWIHX2navGvEdRok/UZj1SUyjvA= X-Sasl-enc: 8gfcBynJn6//3W2Zd0G82d0ATs7eAaVUxs2Gw24t0M7T 1462385925 Received: from dhcp-171-68-20-190.cisco.com (dhcp-171-68-20-190.cisco.com [171.68.20.190]) by mail.messagingengine.com (Postfix) with ESMTPA id 2840CC00017; Wed, 4 May 2016 14:18:45 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CBA5C409-9128-4BA6-8739-DEDA138A9A4C" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <572A1C14.5020907@usdonovans.com> Date: Wed, 4 May 2016 11:18:43 -0700 Message-Id: <74A5239A-329E-4F82-9FBF-497C9D906E89@cooperw.in> References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> <572A1C14.5020907@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-dime-drmp@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , IESG Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 04 May 2016 18:26:51 -0000 --Apple-Mail=_CBA5C409-9128-4BA6-8739-DEDA138A9A4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Responding to Steve because there is an issue here to unpack more, and = he quotes Lionel ... > On May 4, 2016, at 8:58 AM, Steve Donovan = wrote: >=20 > Responding to both Alissa's comments and Lionel's responses. >=20 > Regards, >=20 > Steve >=20 > On 5/3/16 6:42 PM, lionel.morand@orange.com = wrote: >> Hi Alissa, >>=20 >> Thank you for your review. >> Please find below some clarifications, waiting for authors feeback. >>=20 >> Regards, >>=20 >> Lionel >>=20 >> Envoy=C3=A9 depuis Surface >>=20 >> De : Alissa Cooper >> Envoy=C3=A9 : =E2=80=8Emardi=E2=80=8E =E2=80=8E3=E2=80=8E =E2=80=8Emai=E2= =80=8E =E2=80=8E2016 =E2=80=8E23=E2=80=8E:=E2=80=8E31 >> =C3=80 : iesg@ietf.org >> Cc : draft-ietf-dime-drmp@ietf.org = , Lionel MORAND = , dime-chairs@ietf.org = , Lionel MORAND = , dime@ietf.org >>=20 >> Alissa Cooper has entered the following ballot position for >> draft-ietf-dime-drmp-05: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ = >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> (1) Given the two key security threats identified in Section 11 -- = that >> authorized nodes can issue requests with artificially high priority = in >> order to get better treatment, and that unauthorized intermediaries = can >> modify the priorities that senders set -- I don't see how it is >> legitimate to claim that either 5.1 or 5.2 are appropriate use cases = for >> DRMP. The spec seems to assume that this mechanism will only be used = in >> scenarios where nodes and agents have some out-of-band trust = relationship >> established with each other (the shepherd write-up talks about a = "trusted >> environment"), but that is certainly not the case in many disaster = and >> emergency scenarios. If that really is a limitation on the scope of >> applicability of this mechanism, that should be stated in the = document, >> and those use cases should either be removed or modified to explain = the >> limitations on their applicability. =20 >>=20 >> [LM] I think that what is missing is that Diameter is mainly (if not = only) used in mobile operator networks. The text makes reference to the = RFC7683 where the overoload contgrol mechanism is introduced to solve = overload situations in telco networks. This additional mechanism is seen = as a complement of this overload control mechanism. Now, if it is = understood that it is a mechanism defined for =E2=80=9Ctrusted = environment=E2=80=9D i.e. mobile networks, the use of priority = indications in emergency and disaster scenarios seems legitimate. > SRD> I would state it a little differently, but I agree that there = needs to be some clarification here. We intentionally did not specify = how priorities are set in this document as those priorities need to take = into account application specific knowledge. This document is, instead, = focused on how priority information is transported and used by nodes = receiving the priority. The thing that is missing is a statement that = this mechanism only works when the definition of priority values is done = in a consistent manner for all applications used by a Diameter network. = It is my understanding that 3GPP will be defining priorities across its = set of applications and that this will make sure that one application = does not improperly take advantage of the mechanism at the expense of = other applications. I also expect that 3GPP will factor in the 5.1 and = 5.2 use cases when doing this work. I=E2=80=99m glad you pointed this out, because this is different from my = understanding of how DRMP is intended to be used. And I will admit to = not being super familiar with Diameter. I saw this in Section 4: "Note: There are a number of application specific definitions indicating various views of application level priority for different requests. Using these application specific priority Attribute Value Pairs (AVPs) as input to throttling and other Diameter routing decisions would require Diameter agents to understand all applications and do application specific parsing of all messages in order to determine the priority of individual messages. This is considered an unacceptable level of complexity to put on elements whose primary responsibility is to route Diameter messages.=E2=80=9D I was thinking that the implication from this is that a Diameter agent = would be scoped such that it would only receive requests from clients = all using the same application. But you say that is not the case. If an = agent is supposed to make sense of priorities received from multiple = different applications, then it seems problematic for each application = to independently define its own priority semantics with any expectation = about what those semantics are supposed to effectuate. For example, = consider if people go off and work on the EAP application and decide = that they really only need two priority levels, so they decide to use 10 = and 11. Then people go off and work on the SIP application and they = decide they really only need two priority levels, so they decide to use = 1 and 2. Should all SIP application traffic really always be prioritized = over all EAP application traffic? >=20 > SRD> This does beg the question of whether or not we need to support = interworking between multiple "DRMP priority schemes", where one = Diameter network assumes priority scheme 1 and another assumes priority = scheme 2 and the two priority schemes were defined completely = independently. The 3GPP priority definition would be an example of a = priority scheme. The mechanism, as currently defined, does not support = this use case. >=20 > SRD> We could fix this by using a name-space concept similar to that = used by SIP. Or we could say that this mechanism only works in a = trusted environment. The working group should decide which approach to = take. I agree that some sort of fix is needed here. And I=E2=80=99m not sure = that the trusted environment thing is necessarily enough, because that = doesn=E2=80=99t give guidance to those defining priority schemes about = what they need to do. I also think this is a distinct issue from the one I raised about the = use cases and inability to trust clients. Even if only a single = application ever defines a priority scheme, a network where clients = can=E2=80=99t be trusted could fall victim to an attacker who inflates = the priority of his traffic to try to prevent emergency calls/first = responders from getting priority treatment. >=20 >=20 >>=20 >> (2) Section 6 says: >>=20 >> "The mechanism for how the agent determines which requests are >> throttled is implementation dependent and is outside the scope = of >> this document." >>=20 >> How is a node supposed to determine how to set its priorities if each >> agent makes implementation-specific decisions about what those = priorities >> mean? I understood the document to be saying that Diameter = applications >> would have to define what he priority levels mean within their own >> contexts, but then I would have expected the interpretation of = priorities >> amongst all nodes and agents implementing the same application to be = the >> same.=20 >>=20 >> [LM] I understand. I think that the text should say =E2=80=9CThe = mechanism for how the agent determines which requests are c(candidates) = to be throttled=E2=80=9D. And, when there are requests to throttle, the = priority indication is used to determine =E2=80=9Cwhich requests to = route first, which requests to throttle and where the request is routed. = For instance, requests with higher priority might have a lower = probability of being throttled. =E2=80=9D. > SRD> I agree with Lionel's suggestion here. WFM >>=20 >> (3) Section 8 says:=20 >>=20 >> "Diameter nodes SHOULD use the PRIORITY_10 priority as this default >> value." >> =20 >> If the determination of the priority schemes are all >> application-specific, how is it appropriate for this spec to define = what >> the default priority should be for all applications? Shouldn't >> applications specify their own defaults? >>=20 >> [LM] it is needed to take into account that the use of priority = indication in Diameter will be optional and that legacy implementation = will not include any priority indication in Diameter requests. After = discussion, it was decided that requests without priority should be = handled as with a priority set to 10. This makes the difference with = requests with an explicit lower priorities and other with higher = priorities. 10 is used as =E2=80=9Caverage=E2=80=9D priority, with the = possibility of specific operator policies to use another value.=20 > SRD> As stated by Alexey in a separate email, I don't see the issue = with a default value. Alexey and Lionel have explained why, so I won't = repeat. This ties into my interpretation described above, where I thought agents = would be handling requests specific to one application. I see the value = of this if they are handling requests from multiple applications. >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Section 11 says: "DRMP gives Diameter nodes the ability to influence >> which requests are throttled during overload scenarios." But the >> information is not limited to use during overload scenarios, and the = spec >> specifically allows its use for prioritized routing in absence of >> overload. This should be stated here too. >>=20 >> [LM] right. > SRD> This is already addressed in the paragraph following the one = above: >=20 > The DRMP mechanism can also be used to influence the order in which > Diameter messages are handled by Diameter nodes. The above attacks > have a potentially greater impact in this scenario as the priority > indication impacts the handling of all requests at all times, > independent of the overload status of Diameter nodes in the = Diameter > network. Actually that is a bunch of paragraphs further down, in 11.1. I was = commenting on just the first sentence of 11. I know the reader can keep = reading and get to the part you quote, but I think it=E2=80=99s = important not to gloss over the other uses of this in the intro to 11 = either. Alissa >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles 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 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 delete 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 >=20 --Apple-Mail=_CBA5C409-9128-4BA6-8739-DEDA138A9A4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Responding to Steve because there is an issue = here to unpack more, and he quotes Lionel ...

On = May 4, 2016, at 8:58 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

Responding to both Alissa's comments and = Lionel's responses.

Regards,

Steve

On 5/3/16 6:42 PM, lionel.morand@orange.com wrote:
Hi Alissa,

Thank you for your review.
Please find = below some clarifications, waiting for authors feeback.

Regards,

Lionel

Envoy=C3=A9 depuis = Surface

De : Alissa Cooper
Envoy=C3=A9 : =E2=80=8Emardi=E2=80=8E =E2=80=8E3=E2= =80=8E =E2=80=8Emai=E2=80=8E =E2=80=8E2016 =E2=80=8E23=E2=80=8E:=E2=80=8E3= 1
=C3=80 : iesg@ietf.org
Cc : draft-ietf-dime-drmp@ietf.org, Lionel MORAND, dime-chairs@ietf.org, Lionel MORAND, dime@ietf.org

Alissa Cooper = has entered the following ballot position for
draft-ietf-dime-drmp-05: Discuss

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC = lines. (Feel free to cut this
introductory paragraph, = however.)


Please refer = to https:/= /www.ietf.org/iesg/statement/discuss-criteria.html
for = more information about IESG DISCUSS and COMMENT positions.


The document, along with other = ballot positions, can be found here:
https://da= tatracker.ietf.org/doc/draft-ietf-dime-drmp/



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

(1) Given the two key security = threats identified in Section 11 -- that
authorized nodes = can issue requests with artificially high priority in
order = to get better treatment, and that unauthorized intermediaries can
modify the priorities that senders set -- I don't see how it = is
legitimate to claim that either 5.1 or 5.2 are = appropriate use cases for
DRMP. The spec seems to assume = that this mechanism will only be used in
scenarios where = nodes and agents have some out-of-band trust relationship
established with each other (the shepherd write-up talks = about a "trusted
environment"), but that is certainly not = the case in many disaster and
emergency scenarios. If that = really is a limitation on the scope of
applicability of = this mechanism, that should be stated in the document,
and = those use cases should either be removed or modified to explain the
limitations on their applicability.  

[LM] I think that what = is missing is that Diameter is mainly (if not only) used in mobile = operator networks. The text makes reference to the RFC7683 where the = overoload contgrol mechanism is introduced to solve overload situations = in telco networks. This additional mechanism is seen as a complement = of this overload control mechanism. Now, if it is = understood that it is a mechanism defined for =E2=80=9Ctrusted = environment=E2=80=9D i.e. mobile networks, the use of priority = indications in emergency and disaster scenarios seems = legitimate.
SRD> I would state it a little differently, but I agree = that there needs to be some clarification here.  We intentionally = did not specify how priorities are set in this document as those = priorities need to take into account application specific = knowledge.  This document is, instead, focused on how priority = information is transported and used by nodes receiving the = priority.  The thing that is missing is a statement that this = mechanism only works when the definition of priority values is done in a = consistent manner for all applications used by a Diameter network.  = It is my understanding that 3GPP will be defining priorities across its = set of applications and that this will make sure that one application = does not improperly take advantage of the mechanism at the expense of = other applications.  I also expect that 3GPP will factor in the 5.1 = and 5.2 use cases when doing this work.

I=E2=80=99m glad you pointed this out, because = this is different from my understanding of how DRMP is intended to be = used. And I will admit to not being super familiar with Diameter. I saw = this in Section 4:

"Note: There = are a number of application specific definitions
    =   indicating various views of application level priority = for
      different requests.  Using these = application specific priority
      Attribute = Value Pairs (AVPs) as input to throttling and other
  =     Diameter routing decisions would require Diameter agents = to
      understand all applications and do = application specific parsing of
      all = messages in order to determine the priority of = individual
      messages.  This is = considered an unacceptable level of complexity
    =   to put on elements whose primary responsibility is to = route
      Diameter messages.=E2=80=9D

I was thinking that the implication from this = is that a Diameter agent would be scoped such that it would only receive = requests from clients all using the same application. But you say that = is not the case. If an agent is supposed to make sense of priorities = received from multiple different applications, then it seems problematic = for each application to independently define its own priority semantics = with any expectation about what those semantics are supposed to = effectuate. For example, consider if people go off and work on the EAP = application and decide that they really only need two priority levels, = so they decide to use 10 and 11. Then people go off and work on the SIP = application and they decide they really only need two priority levels, = so they decide to use 1 and 2. Should all SIP application traffic really = always be prioritized over all EAP application traffic?


SRD> This does beg the question of whether or = not we need to support interworking between multiple "DRMP priority = schemes", where one Diameter network assumes priority scheme 1 and = another assumes priority scheme 2 and the two priority schemes were = defined completely independently.  The 3GPP priority definition = would be an example of a priority scheme.  The mechanism, as = currently defined, does not support this use case.

SRD> We could fix this by using a name-space = concept similar to that used by SIP.  Or we could say that this = mechanism only works in a trusted environment.  The working group = should decide which approach to take.

I agree that some sort of fix is needed here. And = I=E2=80=99m not sure that the trusted environment thing is necessarily = enough, because that doesn=E2=80=99t give guidance to those defining = priority schemes about what they need to do.

I also think this is a distinct issue from the one = I raised about the use cases and inability to trust clients. Even if = only a single application ever defines a priority scheme, a network = where clients can=E2=80=99t be trusted could fall victim to an attacker = who inflates the priority of his traffic to try to prevent emergency = calls/first responders from getting priority treatment.




(2) Section 6 says:

    "The mechanism for how the = agent determines which requests are
       throttled is implementation = dependent and is outside the scope of
       this document."

How is a node supposed to determine how to set = its priorities if each
agent makes implementation-specific = decisions about what those priorities
mean? I understood = the document to be saying that Diameter applications
would = have to define what he priority levels mean within their own
contexts, but then I would have expected the interpretation = of priorities
amongst all nodes and agents implementing = the same application to be the
same. 

[LM] I understand. I = think that the text should say =E2=80=9CThe mechanism for how the = agent determines which requests are c(candidates) to be throttled=E2=80=9D= . And, when there are requests to throttle, the priority indication = is used to determine =E2=80=9Cwhich requests to route first, which = requests to throttle and where the request is routed.  For = instance, requests with higher  priority might have a lower = probability of being throttled. =E2=80=9D.
<= span style=3D"font-family: 'Color Emoji', Calibri, 'Segoe UI', Meiryo, = 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', = sans-serif; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; orphans: auto; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; = background-color: rgb(255, 255, 255); float: none; display: inline = !important;" class=3D"">SRD> I agree with Lionel's suggestion = here.

WFM


(3) Section 8 says: 

 "Diameter nodes SHOULD use the PRIORITY_10 priority as = this default
value."
   
If the = determination of the priority schemes are all
application-specific, how is it appropriate for this spec to = define what
the default priority should be for all = applications? Shouldn't
applications specify their own = defaults?

[LM] it is needed to take into account that the use of = priority indication in Diameter will be optional and that = legacy implementation will not include any priority indication in = Diameter requests. After discussion, it was decided that requests = without priority should be handled as with a priority set to 10. This = makes the difference with requests with an explicit lower priorities and = other with higher priorities. 10 is used as =E2=80=9Caverage=E2=80=9D= priority, with the possibility of specific operator policies to use = another value. 
SRD> As stated by Alexey in a separate email, I don't see = the issue with a default value.  Alexey and Lionel have explained = why, so I won't repeat.

This ties = into my interpretation described above, where I thought agents would be = handling requests specific to one application. I see the value of this = if they are handling requests from multiple applications.



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Section 11 says: "DRMP gives = Diameter nodes the ability to influence
which requests are = throttled during overload scenarios." But the
information = is not limited to use during overload scenarios, and the spec
specifically allows its use for prioritized routing in = absence of
overload. This should be stated here too.

[LM]= right.
SRD> This is already addressed in the = paragraph following the one above:

   The = DRMP mechanism can also be used to influence the order in = which
   = Diameter messages are handled by Diameter nodes.  The above = attacks
   have a = potentially greater impact in this scenario as the priority
   indication impacts the handling of = all requests at all times,
   = independent of the overload status of Diameter nodes in the = Diameter
   = network.

Actually = that is a bunch of paragraphs further down, in 11.1. I was commenting on = just the first sentence of 11. I know the reader can keep reading and = get to the part you quote, but I think it=E2=80=99s important not to = gloss over the other uses of this in the intro to 11 = either.

Alissa


_______________________________________________________________=
__________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles 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 =
electroniques 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 =
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 =
delete 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.



= --Apple-Mail=_CBA5C409-9128-4BA6-8739-DEDA138A9A4C-- From nobody Wed May 4 11:43:47 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 7211F12D0FB; Wed, 4 May 2016 11:43:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 t8VO5dw81vya; Wed, 4 May 2016 11:43:45 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 23E8C12D0AD; Wed, 4 May 2016 11:43:45 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:64066 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 1ay1lt-00361u-4x; Wed, 04 May 2016 11:43:44 -0700 To: Benoit Claise , The IESG References: <20160504170252.8246.93112.idtracker@ietfa.amsl.com> From: Steve Donovan Message-ID: <572A42DC.8040800@usdonovans.com> Date: Wed, 4 May 2016 13:43:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160504170252.8246.93112.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org Subject: Re: [Dime] Benoit Claise's No Objection on draft-ietf-dime-drmp-05: (with COMMENT) 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, 04 May 2016 18:43:46 -0000 My comments inline. Regards, Steve On 5/4/16 12:02 PM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-dime-drmp-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - OLD: > > This also recognizes that more > work has already taken place for established sessions and, as a > result, it might be more harmful if the session update and session > ending requests were to be throttled. > > > NEW: > This also recognizes that more > work has already taken place for established sessions and, as a > result, it might be more harmful from a signaling point of view > if the session update and session ending requests were to be > throttled. SRD> I'm ok with this change. > > - > > 1. Request sender - The sender of a request, be it a Diameter Client > or a Diameter Server, determines the relative priority of the > request and includes that priority information in the request. > > Question: what is the risk of DMRP ending up as the DSCP, i.e. > Every end point changes the value to best service, and in the end, it's > useless, and uniquely set by the operator. SRD> I think Ben answered this. > > From nobody Wed May 4 11:53:29 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 80D3512D1F0; Wed, 4 May 2016 11:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 ERF1OCyI5oXe; Wed, 4 May 2016 11:53:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00AF12D147; Wed, 4 May 2016 11:53:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0ECBDBE7C; Wed, 4 May 2016 19:53:23 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NttfoBr4d9XR; Wed, 4 May 2016 19:53:21 +0100 (IST) Received: from [10.87.49.100] (unknown [86.46.26.141]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D5B69BE53; Wed, 4 May 2016 19:53:20 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462388001; bh=lMc09rWlNFlzWFVC2vaRzWjlOxuIEnwrFeq1/atLUss=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=qX8eLlrZh+s6Kcm8hBxmhxqgA3vVUXOIr4fLitLkHb1fz6juu2ZtOkSPVrrOxsgF+ JjaAmSPbTmpkFZ5J/+DkMUorJhgmS3iv3Z62u9Ucg1QhGQ8v/P80e94Zpd5bLxRogE FfWvlp91RStc6punRBq0VzVNduDbm4EtllLESJiA= To: Alissa Cooper , Steve Donovan References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> <572A1C14.5020907@usdonovans.com> <74A5239A-329E-4F82-9FBF-497C9D906E89@cooperw.in> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <572A4520.5090101@cs.tcd.ie> Date: Wed, 4 May 2016 19:53:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <74A5239A-329E-4F82-9FBF-497C9D906E89@cooperw.in> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030409050800050407070400" Archived-At: Cc: "draft-ietf-dime-drmp@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , IESG Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 04 May 2016 18:53:28 -0000 This is a cryptographically signed message in MIME format. --------------ms030409050800050407070400 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Please do continue the discussion all, but just on one aspect of this... On 04/05/16 19:18, Alissa Cooper wrote: > Even if only a single application ever defines a priority scheme, a=20 > network where clients can=E2=80=99t be trusted could fall victim to an = > attacker who inflates the priority of his traffic to try to prevent=20 > emergency calls/first responders from getting priority treatment. My understanding of Diameter deployments is that they are pretty much all done so that any node can play all sorts of games and there are no protocol mechanisms other than hop-by-hop TLS or IPsec to control that. I'm not even sure how much those are deployed, even in cases where cryptographic keys are passed in Diameter messages. (And that's when the base protocol spec says you MUST use TLS in such cases. [1]) So DRMP and DOIC are by far not the most attractive target here. The DIME WG are attempting to address that via [2] but I'm not sure if we ought be hugely hopeful of that being implemented or deployed either. It might help if someone more familiar with deployments can correct or confirm the above. That doesn't affect the issue of potentially un-coordinated uses of different priorities across multiple Diameter applications, which seems like it is worth saying more about, but I'd have to say that uses of DRMP as an attack vector aren't that compelling from what I know, and the WG are attempting to at least document mechanisms that would provide relevant protocol countermeasures for the base protocol. Cheers, S. [1] https://tools.ietf.org/html/rfc6733#section-13.3 [2] https://tools.ietf.org/html/draft-ietf-dime-e2e-sec-req --------------ms030409050800050407070400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MDQx ODUzMjBaMC8GCSqGSIb3DQEJBDEiBCAlQjPGknHrtBrApEQc2PcVb1v5rU5xixPw20Ddkkm9 IzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCUFAzK4sr/Dgl9JMC7nYaYl6cG4HjFQtk+0Its4705ZS8S92bj44px DjdvArnkj4Gz3qjnXMBa5YLHNdfQTKtLgDjPXS1l6VLksjr+0J3feIl4kBN3gZLaE8AmfkNK F1baf4sxgzxj5Jf/Y0axmhVWlvWqpFiT+VhU2mfr05vGe1CqOSAL47WdoFcpzuEOPKYOW/qT /ymJLR+XFiRYN0HvSBWKgUJT9RfyTLc4jYlJ8XXw8YVz4yDzGk9Cj1iEGYenPAwOZSzImLlF MC2pPUn1JZG/yq5DQ09mA3piS6R21Tx4mbAhQX8wO+bT/GDTyd8og/FSs9/TJw1SYhuPc4Qe AAAAAAAA --------------ms030409050800050407070400-- From nobody Wed May 4 11:58: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 2F24512D52E; Wed, 4 May 2016 11:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.139 X-Spam-Level: X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 CwLQ6p-mgGcH; Wed, 4 May 2016 11:57:53 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 1F72E12D588; Wed, 4 May 2016 11:57:53 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:64205 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 1ay1zW-003JNs-HQ; Wed, 04 May 2016 11:57:52 -0700 To: Alissa Cooper References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> <572A1C14.5020907@usdonovans.com> <74A5239A-329E-4F82-9FBF-497C9D906E89@cooperw.in> From: Steve Donovan Message-ID: <572A4628.2090500@usdonovans.com> Date: Wed, 4 May 2016 13:57:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <74A5239A-329E-4F82-9FBF-497C9D906E89@cooperw.in> Content-Type: multipart/alternative; boundary="------------080103000406010403030903" X-OutGoing-Spam-Status: No, score=-0.7 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: Cc: "draft-ietf-dime-drmp@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , IESG Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 04 May 2016 18:57:56 -0000 This is a multi-part message in MIME format. --------------080103000406010403030903 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/4/16 1:18 PM, Alissa Cooper wrote: > Responding to Steve because there is an issue here to unpack more, and > he quotes Lionel ... > >> On May 4, 2016, at 8:58 AM, Steve Donovan > > wrote: >> >> Responding to both Alissa's comments and Lionel's responses. >> >> Regards, >> >> Steve >> >> On 5/3/16 6:42 PM,lionel.morand@orange.comwrote: >>> Hi Alissa, >>> >>> Thank you for your review. >>> Please find below some clarifications, waiting for authors feeback. >>> >>> Regards, >>> >>> Lionel >>> >>> Envoyé depuis Surface >>> >>> *De :* Alissa Cooper >>> *Envoyé :* ‎mardi‎ ‎3‎ ‎mai‎ ‎2016 ‎23‎:‎31 >>> *À :* iesg@ietf.org >>> *Cc :* draft-ietf-dime-drmp@ietf.org >>> ,Lionel MORAND >>> ,dime-chairs@ietf.org >>> ,Lionel MORAND >>> ,dime@ietf.org >>> >>> Alissa Cooper has entered the following ballot position for >>> draft-ietf-dime-drmp-05: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer tohttps://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> (1) Given the two key security threats identified in Section 11 -- that >>> authorized nodes can issue requests with artificially high priority in >>> order to get better treatment, and that unauthorized intermediaries can >>> modify the priorities that senders set -- I don't see how it is >>> legitimate to claim that either 5.1 or 5.2 are appropriate use cases for >>> DRMP. The spec seems to assume that this mechanism will only be used in >>> scenarios where nodes and agents have some out-of-band trust >>> relationship >>> established with each other (the shepherd write-up talks about a >>> "trusted >>> environment"), but that is certainly not the case in many disaster and >>> emergency scenarios. If that really is a limitation on the scope of >>> applicability of this mechanism, that should be stated in the document, >>> and those use cases should either be removed or modified to explain the >>> limitations on their applicability. >>> >>> [LM] I think that what is missing is that Diameter is mainly (if not >>> only) used in mobile operator networks. The text makes reference to >>> the RFC7683 where the overoload contgrol mechanism is introduced to >>> solve overload situations in telco networks. This additional >>> mechanism is seen as a complement of this overload control >>> mechanism. Now, if it is understood that it is a mechanism defined >>> for “trusted environment†i.e. mobile networks, the use of priority >>> indications in emergency and disaster scenarios seems legitimate. >> SRD> I would state it a little differently, but I agree that there >> needs to be some clarification here. We intentionally did not >> specify how priorities are set in this document as those priorities >> need to take into account application specific knowledge. This >> document is, instead, focused on how priority information is >> transported and used by nodes receiving the priority. The thing that >> is missing is a statement that this mechanism only works when the >> definition of priority values is done in a consistent manner for all >> applications used by a Diameter network. It is my understanding that >> 3GPP will be defining priorities across its set of applications and >> that this will make sure that one application does not improperly >> take advantage of the mechanism at the expense of other >> applications. I also expect that 3GPP will factor in the 5.1 and 5.2 >> use cases when doing this work. > > I’m glad you pointed this out, because this is different from my > understanding of how DRMP is intended to be used. And I will admit to > not being super familiar with Diameter. I saw this in Section 4: > > "Note: There are a number of application specific definitions > indicating various views of application level priority for > different requests. Using these application specific priority > Attribute Value Pairs (AVPs) as input to throttling and other > Diameter routing decisions would require Diameter agents to > understand all applications and do application specific parsing of > all messages in order to determine the priority of individual > messages. This is considered an unacceptable level of complexity > to put on elements whose primary responsibility is to route > Diameter messages.†> > I was thinking that the implication from this is that a Diameter agent > would be scoped such that it would only receive requests from clients > all using the same application. But you say that is not the case. If > an agent is supposed to make sense of priorities received from > multiple different applications, then it seems problematic for each > application to independently define its own priority semantics with > any expectation about what those semantics are supposed to effectuate. > For example, consider if people go off and work on the EAP application > and decide that they really only need two priority levels, so they > decide to use 10 and 11. Then people go off and work on the SIP > application and they decide they really only need two priority levels, > so they decide to use 1 and 2. Should all SIP application traffic > really always be prioritized over all EAP application traffic? SRD> This is why I talked about a "priority scheme" and applications defining priorities in a consistent fashion. > >> >> SRD> This does beg the question of whether or not we need to support >> interworking between multiple "DRMP priority schemes", where one >> Diameter network assumes priority scheme 1 and another assumes >> priority scheme 2 and the two priority schemes were defined >> completely independently. The 3GPP priority definition would be an >> example of a priority scheme. The mechanism, as currently defined, >> does not support this use case. >> >> SRD> We could fix this by using a name-space concept similar to that >> used by SIP. Or we could say that this mechanism only works in a >> trusted environment. The working group should decide which approach >> to take. > > I agree that some sort of fix is needed here. And I’m not sure that > the trusted environment thing is necessarily enough, because that > doesn’t give guidance to those defining priority schemes about what > they need to do. SRD> Agreed, its not enough to be a trusted environment. There needs to be coordinated priority definition across all of the applications used in the environment. > > I also think this is a distinct issue from the one I raised about the > use cases and inability to trust clients. Even if only a single > application ever defines a priority scheme, a network where clients > can’t be trusted could fall victim to an attacker who inflates the > priority of his traffic to try to prevent emergency calls/first > responders from getting priority treatment. SRD> This is where the trusted environment comes in. It's not an issue if all nodes are trusted. SRD> We also need to factor in what it would take to starve the well behaving clients. DRMP priority can be used to influence which messages are routed first or which messages are throttled first. A misbehaving Diameter client would need to send enough messages to consume somewhere approaching 100% of the capacity of an agent to fully starve well behaving nodes. This, to a large degree, boils down to a classical DOS attack. DRMP maybe makes it a more effective DOS attack, but normal strategies for handling DOS attacks would be effective in dealing with a DRMP flavored DOS attack. > >> >> >>> >>> (2) Section 6 says: >>> >>> "The mechanism for how the agent determines which requests are >>> throttled is implementation dependent and is outside the scope of >>> this document." >>> >>> How is a node supposed to determine how to set its priorities if each >>> agent makes implementation-specific decisions about what those >>> priorities >>> mean? I understood the document to be saying that Diameter applications >>> would have to define what he priority levels mean within their own >>> contexts, but then I would have expected the interpretation of >>> priorities >>> amongst all nodes and agents implementing the same application to be the >>> same. >>> >>> [LM] I understand. I think that the text should say “The mechanism >>> for how the agent determines which requests are c(candidates) to be >>> throttledâ€. And, when there are requests to throttle, the priority >>> indication is used to determine “which requests to route first, >>> which requests to throttle and where the request is routed. For >>> instance, requests with higher priority might have a lower >>> probability of being throttled. â€. >> SRD> I agree with Lionel's suggestion here. > > WFM > >>> >>> (3) Section 8 says: >>> >>> "Diameter nodes SHOULD use the PRIORITY_10 priority as this default >>> value." >>> >>> If the determination of the priority schemes are all >>> application-specific, how is it appropriate for this spec to define what >>> the default priority should be for all applications? Shouldn't >>> applications specify their own defaults? >>> >>> [LM] it is needed to take into account that the use of priority >>> indication in Diameter will be optional and that >>> legacy implementation will not include any priority indication in >>> Diameter requests. After discussion, it was decided that requests >>> without priority should be handled as with a priority set to 10. >>> This makes the difference with requests with an explicit lower >>> priorities and other with higher priorities. 10 is used as “average†>>> priority, with the possibility of specific operator policies to use >>> another value. >> SRD> As stated by Alexey in a separate email, I don't see the issue >> with a default value. Alexey and Lionel have explained why, so I >> won't repeat. > > This ties into my interpretation described above, where I thought > agents would be handling requests specific to one application. I see > the value of this if they are handling requests from multiple > applications. > > >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Section 11 says: "DRMP gives Diameter nodes the ability to influence >>> which requests are throttled during overload scenarios." But the >>> information is not limited to use during overload scenarios, and the >>> spec >>> specifically allows its use for prioritized routing in absence of >>> overload. This should be stated here too. >>> >>> [LM] right. >> SRD> This is already addressed in the paragraph following the one above: >> >> The DRMP mechanism can also be used to influence the order in which >> Diameter messages are handled by Diameter nodes. The above attacks >> have a potentially greater impact in this scenario as the priority >> indication impacts the handling of all requests at all times, >> independent of the overload status of Diameter nodes in the Diameter >> network. > > Actually that is a bunch of paragraphs further down, in 11.1. I was > commenting on just the first sentence of 11. I know the reader can > keep reading and get to the part you quote, but I think it’s important > not to gloss over the other uses of this in the intro to 11 either. SRD> I see it now. I have no objection to adding appropriate text to that paragraph. > > Alissa > >>> >>> _________________________________________________________________________________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques 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 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 delete 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. >> >> > --------------080103000406010403030903 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 5/4/16 1:18 PM, Alissa Cooper wrote:
Responding to Steve because there is an issue here to unpack more, and he quotes Lionel ...

On May 4, 2016, at 8:58 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

Responding to both Alissa's comments and Lionel's responses.

Regards,

Steve

On 5/3/16 6:42 PM, lionel.morand@orange.com wrote:
Hi Alissa,

Thank you for your review.
Please find below some clarifications, waiting for authors feeback.

Regards,

Lionel

Envoyé depuis Surface

De : Alissa Cooper
Envoyé : ‎mardi‎ ‎3‎ ‎mai‎ ‎2016 ‎23‎:‎31
À : iesg@ietf.org
Cc : draft-ietf-dime-drmp@ietf.org, Lionel MORAND, dime-chairs@ietf.org, Lionel MORAND, dime@ietf.org

Alissa Cooper has entered the following ballot position for
draft-ietf-dime-drmp-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) Given the two key security threats identified in Section 11 -- that
authorized nodes can issue requests with artificially high priority in
order to get better treatment, and that unauthorized intermediaries can
modify the priorities that senders set -- I don't see how it is
legitimate to claim that either 5.1 or 5.2 are appropriate use cases for
DRMP. The spec seems to assume that this mechanism will only be used in
scenarios where nodes and agents have some out-of-band trust relationship
established with each other (the shepherd write-up talks about a "trusted
environment"), but that is certainly not the case in many disaster and
emergency scenarios. If that really is a limitation on the scope of
applicability of this mechanism, that should be stated in the document,
and those use cases should either be removed or modified to explain the
limitations on their applicability.  

[LM] I think that what is missing is that Diameter is mainly (if not only) used in mobile operator networks. The text makes reference to the RFC7683 where the overoload contgrol mechanism is introduced to solve overload situations in telco networks. This additional mechanism is seen as a complement of this overload control mechanism. Now, if it is understood that it is a mechanism defined for “trusted environment†i.e. mobile networks, the use of priority indications in emergency and disaster scenarios seems legitimate.
SRD> I would state it a little differently, but I agree that there needs to be some clarification here.  We intentionally did not specify how priorities are set in this document as those priorities need to take into account application specific knowledge.  This document is, instead, focused on how priority information is transported and used by nodes receiving the priority.  The thing that is missing is a statement that this mechanism only works when the definition of priority values is done in a consistent manner for all applications used by a Diameter network.  It is my understanding that 3GPP will be defining priorities across its set of applications and that this will make sure that one application does not improperly take advantage of the mechanism at the expense of other applications.  I also expect that 3GPP will factor in the 5.1 and 5.2 use cases when doing this work.

I’m glad you pointed this out, because this is different from my understanding of how DRMP is intended to be used. And I will admit to not being super familiar with Diameter. I saw this in Section 4:

"Note: There are a number of application specific definitions
      indicating various views of application level priority for
      different requests.  Using these application specific priority
      Attribute Value Pairs (AVPs) as input to throttling and other
      Diameter routing decisions would require Diameter agents to
      understand all applications and do application specific parsing of
      all messages in order to determine the priority of individual
      messages.  This is considered an unacceptable level of complexity
      to put on elements whose primary responsibility is to route
      Diameter messages.â€

I was thinking that the implication from this is that a Diameter agent would be scoped such that it would only receive requests from clients all using the same application. But you say that is not the case. If an agent is supposed to make sense of priorities received from multiple different applications, then it seems problematic for each application to independently define its own priority semantics with any expectation about what those semantics are supposed to effectuate. For example, consider if people go off and work on the EAP application and decide that they really only need two priority levels, so they decide to use 10 and 11. Then people go off and work on the SIP application and they decide they really only need two priority levels, so they decide to use 1 and 2. Should all SIP application traffic really always be prioritized over all EAP application traffic?
SRD> This is why I talked about a "priority scheme" and applications defining priorities in a consistent fashion.


SRD> This does beg the question of whether or not we need to support interworking between multiple "DRMP priority schemes", where one Diameter network assumes priority scheme 1 and another assumes priority scheme 2 and the two priority schemes were defined completely independently.  The 3GPP priority definition would be an example of a priority scheme.  The mechanism, as currently defined, does not support this use case.

SRD> We could fix this by using a name-space concept similar to that used by SIP.  Or we could say that this mechanism only works in a trusted environment.  The working group should decide which approach to take.

I agree that some sort of fix is needed here. And I’m not sure that the trusted environment thing is necessarily enough, because that doesn’t give guidance to those defining priority schemes about what they need to do.
SRD> Agreed, its not enough to be a trusted environment.  There needs to be coordinated priority definition across all of the applications used in the environment.

I also think this is a distinct issue from the one I raised about the use cases and inability to trust clients. Even if only a single application ever defines a priority scheme, a network where clients can’t be trusted could fall victim to an attacker who inflates the priority of his traffic to try to prevent emergency calls/first responders from getting priority treatment.
SRD> This is where the trusted environment comes in.  It's not an issue if all nodes are trusted. 

SRD> We also need to factor in what it would take to starve the well behaving clients.  DRMP priority can be used to influence which messages are routed first or which messages are throttled first.  A misbehaving Diameter client would need to send enough messages to consume somewhere approaching 100% of the capacity of an agent to fully starve well behaving nodes.  This, to a large degree, boils down to a classical DOS attack.  DRMP maybe makes it a more effective DOS attack, but normal strategies for handling DOS attacks would be effective in dealing with a DRMP flavored DOS attack.




(2) Section 6 says:

    "The mechanism for how the agent determines which requests are
       throttled is implementation dependent and is outside the scope of
       this document."

How is a node supposed to determine how to set its priorities if each
agent makes implementation-specific decisions about what those priorities
mean? I understood the document to be saying that Diameter applications
would have to define what he priority levels mean within their own
contexts, but then I would have expected the interpretation of priorities
amongst all nodes and agents implementing the same application to be the
same. 

[LM] I understand. I think that the text should say “The mechanism for how the agent determines which requests are c(candidates) to be throttledâ€. And, when there are requests to throttle, the priority indication is used to determine “which requests to route first, which requests to throttle and where the request is routed.  For instance, requests with higher  priority might have a lower probability of being throttled. â€.
SRD> I agree with Lionel's suggestion here.

WFM


(3) Section 8 says: 

 "Diameter nodes SHOULD use the PRIORITY_10 priority as this default
value."
   
If the determination of the priority schemes are all
application-specific, how is it appropriate for this spec to define what
the default priority should be for all applications? Shouldn't
applications specify their own defaults?

[LM] it is needed to take into account that the use of priority indication in Diameter will be optional and that legacy implementation will not include any priority indication in Diameter requests. After discussion, it was decided that requests without priority should be handled as with a priority set to 10. This makes the difference with requests with an explicit lower priorities and other with higher priorities. 10 is used as “average†priority, with the possibility of specific operator policies to use another value. 
SRD> As stated by Alexey in a separate email, I don't see the issue with a default value.  Alexey and Lionel have explained why, so I won't repeat.

This ties into my interpretation described above, where I thought agents would be handling requests specific to one application. I see the value of this if they are handling requests from multiple applications.



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 11 says: "DRMP gives Diameter nodes the ability to influence
which requests are throttled during overload scenarios." But the
information is not limited to use during overload scenarios, and the spec
specifically allows its use for prioritized routing in absence of
overload. This should be stated here too.

[LM] right.
SRD> This is already addressed in the paragraph following the one above:

   The DRMP mechanism can also be used to influence the order in which
   Diameter messages are handled by Diameter nodes.  The above attacks
   have a potentially greater impact in this scenario as the priority
   indication impacts the handling of all requests at all times,
   independent of the overload status of Diameter nodes in the Diameter
   network.

Actually that is a bunch of paragraphs further down, in 11.1. I was commenting on just the first sentence of 11. I know the reader can keep reading and get to the part you quote, but I think it’s important not to gloss over the other uses of this in the intro to 11 either.
SRD> I see it now.  I have no objection to adding appropriate text to that paragraph.

Alissa


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques 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 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 delete 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.




--------------080103000406010403030903-- From nobody Wed May 4 17:04:56 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 563AE12D0A3; Wed, 4 May 2016 17:04:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: "Jouni Korhonen" , "Lionel Morand" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160505000454.8358.57070.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 17:04:54 -0700 Archived-At: Cc: 3GPPLiaison@etsi.org, Joel Jaeggli , Diameter Maintenance and Extensions Discussion List Subject: [Dime] New Liaison Statement, "LS to IETF for clarification on RFC 4006 for Diameter Base Protocol" 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: Thu, 05 May 2016 00:04:54 -0000 Title: LS to IETF for clarification on RFC 4006 for Diameter Base Protocol Submission Date: 2016-05-04 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1470/ Please reply by 2016-05-23 From: "Maryse Gardella" To: Jouni Korhonen ,Lionel Morand Cc: Benoit Claise ,Lionel Morand ,Joel Jaeggli ,Jouni Korhonen ,Diameter Maintenance and Extensions Discussion List , Response Contacts: 3GPPLiaison@etsi.org Technical Contacts: Purpose: For action Body: Attachments: LS to IETF for clarification on RFC 4006 for Diameter Base Protocol https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-05-04-3gpp-tsg-sa-wg5-dime-ls-to-ietf-for-clarification-on-rfc-4006-for-diameter-base-protocol-attachment-1.doc From nobody Wed May 4 20:58:10 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 5F8A212B01C; Wed, 4 May 2016 20:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 rT5paNu2kzyi; Wed, 4 May 2016 20:58:03 -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 2ADCB12B05F; Wed, 4 May 2016 20:58:03 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u453w18P061265 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 May 2016 22:58:02 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Steve Donovan" , "The IESG" Date: Wed, 04 May 2016 22:58:01 -0500 Message-ID: <45E2E5D4-091E-4311-9FDF-271B04D59D05@nostrum.com> In-Reply-To: <572A227D.1040203@usdonovans.com> References: <20160504023124.8242.52368.idtracker@ietfa.amsl.com> <572A227D.1040203@usdonovans.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, "dime-chairs@ietf.org" , dime@ietf.org Subject: Re: [Dime] Ben Campbell's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 05 May 2016 03:58:09 -0000 (oops, sent this earlier, but it just went to Steve. Resending to full list) Thanks for the quick response. Further discussion inline: Ben. On 4 May 2016, at 11:25, Steve Donovan wrote: [...] >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I have a few concerns that I think need some discussion. >> >> 1) Priority between applications: The fact that agents can apply >> priority >> for messages from multiple applications without knowledge of those >> applications seems dangerous. Let's say application A is a critical >> infrastructure application, and application B is not. But clients for >> application B might set requests to have a higher priority than do >> clients for application A. Further, application B could become a DoS >> vector for application A. One potential (and likely half-baked) way >> to >> mitigate this would be to say that nodes that are not "application >> aware" >> can only apply priority among messages for the same application. > SRD> This is similar to saying that priority setting across > applications need to be set in a consistent way. We might need to > define the "priority scheme" or some similar concept as sketched out > in my response to Alissa's DISCUSS. That would probably help. Am I correct in assuming that would require some WG discussion? It occurs to me after sleeping on it that, in congestion cases, this would leave things no worse than when a relay agent throttles requests with even less information. But it's a little more worrisome when used in non-congested circumstances, assuming they leave the possibility of throttling or otherwise rejecting requests under normal processing conditions. >> >> 2) Priority between clients of the same application: If you have >> multiple >> clients for the same application, don't they need to use the same >> prioritization strategy? How is this to be managed? > SRD> It is not directly defined. This is back to the question of > whether or not the mechanism is constrained to only work in a trusted > environment. The potential "priority scheme" might help here. But why does a trusted environment matter? Lets say you have trusted clients from vender A and from vendor B, but they select priorities differently? >> >> 3) Out of order requests: The draft explicitly allows agents to >> re-route >> and even explicitly re-order messages. Is it safe to have a >> non-application aware node change the order of messages? > SRD> This mechanism doesn't change the need for Diameter nodes to > handle messages arriving out of order. This exists in any protocol > that has agents/proxies. Okay, I will withdraw that part. (How quick one forgets...) >> >> 4) I am nervous about the idea that clients and servers would use a >> generic message priority mechanism to manage the allocation of >> resources >> that result from a requests and answers. It seems like that should be >> based on application specific rules and information. (Now, if the >> point >> is that these same AVPs might be used in an application according to >> application specific rules, that might be okay--but then you might >> run >> into issues where application-agnostic agents don't know the >> difference.) > SRD> The definition of what different priority levels mean will > reflect the application specific knowledge. Agents just route > requests and with the introduction of DOIC, sometimes throttle them. > The agent doesn't need anything but the priority value, as long as the > priority values are defined consistently across all applications. My concern was more about client and server behavior, but it may be impacted by relays. I assume that a relay agent would not be making decisions about resource allocation, at least beyond transactions state. My concern is twofold: In the case of servers, this seems to give a server leave to send a successful answer, but not allocate any necessary resources to support that success. This seems to lead to circumstances where the server thinks something failed but the client thinks it worked. (I have no problem with saying that a resource-constrained server might include priority as a factor in it's decisions about which requests to reject.) In the case of clients, I think we are talking about a client abandoning some task even though the server thinks it worked. I don't see that as a problem per se, but I would expect a server to do that based on some local knowledge of priority. It seems a stretch that it would do so based on a priority value inserted by the server. But even if that makes sense, I understand that this draft allows relay agents with no knowledge of the application semantics to insert, remove, or change priority values in answer messages. (Maybe the answer here is stricter guidance on when relay agents can change priority values, and allowing the client to ignore priority values in answers (especially success answers) >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> General: I approached this assuming prioritization would matter only >> in >> overload scenarios. But I gather you envision using this in >> non-overload >> scenarios? (This interacts with my discuss point about the use of >> DRMP to >> prioritize resource allocation that result result from successful >> diameter transactions.) Use case 5.3 is a bit worrisome in this >> context. > SRD> I don't understand the concern. I'm concerned that this could effectively induce overload for lower priority messages, when the nodes would normally be able to handle all messages. In use case 5.3, does the platinum customer buy the right to cause other customer's requests to fail? >> >> >> -6, list item 4: Are there really use cases for answer senders to set >> a >> different priority on the answer than was on the request? That seems >> to >> add quite a bit of complexity. > SRD> This was an explicit conversation within the working group. I > don't recall the specific use case off the top of my head, but this > was changed to the current wording after discussions within the > working group. I can go back to the email archive to refresh my > memory if necessary. I am willing to accede to working group consensus on this. But one question: Does this apply to answers that indicate success, as well as failure? >> >> - 6, list item 8: I'm not sure what it means for a client to >> prioritize >> answers to it's own requests. > SRD> The client could choose to complete the transaction, and initiate > other dependent actions, based on the priority received in the answer > message. It is those dependent actions -- setting up a data channel, > authorizing call completion, etc -- that would be impacted by the > priorities received in the answer. See the comments on item 4 from my discuss. >> >> -8, "Diameter nodes SHOULD >> include Diameter routing message priority in the DRMP AVP in all >> Diameter request messages." : >> Does that apply to all nodes that touch a request, or just the >> request >> originator? > SRD> This statement was meant to apply to the request originator. The > statement should be updated. Okay. >> >> -- "Diameter nodes MUST use the priority indicated in the DRMP AVP >> carried in the answer message, if it exists." >> The MUST seems odd, since paying attention to the priority in the >> initial >> request was only SHOULD. > SRD> The wording here is cumbersome. The full paragraph is as > follows: > > When determining the priority to apply to answer messages, Diameter > nodes MUST use the priority indicated in the DRMP AVP carried in > the > answer message, if it exists. Otherwise, the Diameter node MUST > use > the priority indicated in the DRMP AVP of the associated request > message. > > This is meant to say that a Diameter node receiving an answer message > MUST use the priority value in the answer message when processing the > message. If there is no DRMP AVP in the answer message then the > receiving node uses the priority that was in the request message. I'd > be happy to re-craft this to be more clear. Part of my concern is that the MUST vs SHOULD bit is different for requests and answers. statements of the form "If you use the mechanism, you MUST do X" do not mean the same as "SHOULD do X", even if the reasoning behind the SHOULD is that a node might not use the mechanism. >> >> -- "Another is to use the Proxy-Info >> mechanism defined in [RFC6733].": >> That probably needs some elaboration. > SRD> A reference to the document that defines Proxy-Info isn't > sufficient? On a re-read, it's probably good enough, although on reflection, I don't think this draft needs to tell relay agents how to manage transaction state. But it doesn't hurt either way. From nobody Wed May 4 21:36:48 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 6460912B01C for ; Wed, 4 May 2016 21:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=VYTEh53y; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=WZUOwUBS 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 4r9fQukE7onq for ; Wed, 4 May 2016 21:36:46 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5287412D0B0 for ; Wed, 4 May 2016 21:36:45 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9C59A20993 for ; Thu, 5 May 2016 00:31:30 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 05 May 2016 00:31:30 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=RCjcq/X92t7xRGAPeve3ZzV5my4=; b=VYTEh5 3yJiYtv+nGBYA9jChOhJpssFWxuL64vwXohk2ym2pxwawe6lgVG3l2gDwuNqWUa0 ToXrtlTP34/S/WEMXJmWH/Hg0PBlPxG7k/pPWv6YCyWob5M9fxMPwd9rksR34lMX SfI5dZDvR4EE5Ca9/7X6ZxOuluafLgUmwxtsw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=RCjcq/X92t7xRGA Peve3ZzV5my4=; b=WZUOwUBSAPTq5Uou2x1rGf1FvRWgo0C6Dnz9MVky8ETOl3m rX02+EsagyhQkNoNFsdtnXv1rGViEZ5kk3UvWwluu4M1eWKhou81oE3f2/lmQbSW vFx7R+2KSGihKVxPpS6U1hQvPqKO1Dv1DQNj1OwXaEeqJdYqXzumHLJ+h/h8= X-Sasl-enc: y+dioK7LX8YvSai3xunCy54dfYE+Jw//phajhvBekKXT 1462422690 Received: from sjc-alcoop-88110.cisco.com (unknown [128.107.241.175]) by mail.messagingengine.com (Postfix) with ESMTPA id 8E289C00018; Thu, 5 May 2016 00:31:29 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <572A4520.5090101@cs.tcd.ie> Date: Wed, 4 May 2016 21:31:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <90C95598-F68D-4F94-8AE3-FAFF403F560E@cooperw.in> References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> <572A1C14.5020907@usdonovans.com> <74A5239A-329E-4F82-9FBF-497C9D906E89@cooperw.in> <572A4520.5090101@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "dime-chairs@ietf.org" , "dime@ietf.org" , IESG , "draft-ietf-dime-drmp@ietf.org" Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 05 May 2016 04:36:47 -0000 > On May 4, 2016, at 11:53 AM, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > Please do continue the discussion all, but just on one aspect of > this... >=20 > On 04/05/16 19:18, Alissa Cooper wrote: >> Even if only a single application ever defines a priority scheme, a=20= >> network where clients can=E2=80=99t be trusted could fall victim to = an=20 >> attacker who inflates the priority of his traffic to try to prevent=20= >> emergency calls/first responders from getting priority treatment. >=20 > My understanding of Diameter deployments is that they are pretty > much all done so that any node can play all sorts of games and > there are no protocol mechanisms other than hop-by-hop TLS or IPsec > to control that. I'm not even sure how much those are deployed, even > in cases where cryptographic keys are passed in Diameter messages. > (And that's when the base protocol spec says you MUST use TLS in > such cases. [1]) >=20 > So DRMP and DOIC are by far not the most attractive target here. But my point was specifically about how the motivation for DRMP is tied = to the first responder and emergency use cases. When a capability is = defined specifically for those uses, people (or, say, regulators) tend = to expect it to work. So if there is a class of cases where it won=E2=80=99= t work at all =E2=80=94 even if the net effect is just that requests get = treated on a best efforts basis the same as they do today, not that some = requests get starved =E2=80=94 it=E2=80=99s worth being very explicit = about that. I=E2=80=99m sure there are other attacks that could target = these uses in the absence of DRMP, but that isn=E2=80=99t a reason to = gloss over the DRMP-specific issue in this spec. Alissa > The DIME WG are attempting to address that via [2] but I'm not > sure if we ought be hugely hopeful of that being implemented > or deployed either. >=20 > It might help if someone more familiar with deployments can > correct or confirm the above. >=20 > That doesn't affect the issue of potentially un-coordinated uses > of different priorities across multiple Diameter applications, > which seems like it is worth saying more about, but I'd have to > say that uses of DRMP as an attack vector aren't that compelling > from what I know, and the WG are attempting to at least document > mechanisms that would provide relevant protocol countermeasures > for the base protocol. >=20 > Cheers, > S. >=20 > [1] https://tools.ietf.org/html/rfc6733#section-13.3 > [2] https://tools.ietf.org/html/draft-ietf-dime-e2e-sec-req >=20 >=20 From nobody Thu May 5 01:00: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 D643612B021; Thu, 5 May 2016 01:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 rov_Vq-baxGP; Thu, 5 May 2016 01:00:36 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3E8F12D17D; Thu, 5 May 2016 01:00:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AEDC6BE50; Thu, 5 May 2016 09:00:34 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHwrMDR6giRK; Thu, 5 May 2016 09:00:30 +0100 (IST) Received: from [10.87.49.100] (unknown [86.46.26.141]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 55CFFBE38; Thu, 5 May 2016 09:00:29 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462435230; bh=Ut/Ff+TN5jtdbfl282a3yBtpBjpF88q678c9kXzgkZ8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=qX6N3z0ojhxfe0dzE4PuAw6nqAYmT2NyY0OhGC4QdNeHv5lfar2qU0RvH9BnqL8tk e7PUl9KEEWQK+wvMJPSWyb5Kzr6F7NXDnc32fAwVUfMT2scd+Dv8STRLjqdUVzEboV jzpwf6E/99aBsYI0z7YlXBF700rkJsmPzmKHaC5I= To: Alissa Cooper References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> <572A1C14.5020907@usdonovans.com> <74A5239A-329E-4F82-9FBF-497C9D906E89@cooperw.in> <572A4520.5090101@cs.tcd.ie> <90C95598-F68D-4F94-8AE3-FAFF403F560E@cooperw.in> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <572AFD9D.7010909@cs.tcd.ie> Date: Thu, 5 May 2016 09:00:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <90C95598-F68D-4F94-8AE3-FAFF403F560E@cooperw.in> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020105030904040504040103" Archived-At: Cc: "dime-chairs@ietf.org" , "dime@ietf.org" , IESG , "draft-ietf-dime-drmp@ietf.org" Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 05 May 2016 08:00:38 -0000 This is a cryptographically signed message in MIME format. --------------ms020105030904040504040103 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/05/16 05:31, Alissa Cooper wrote: >=20 >> On May 4, 2016, at 11:53 AM, Stephen Farrell >> wrote: >>=20 >>=20 >> Hiya, >>=20 >> Please do continue the discussion all, but just on one aspect of=20 >> this... >>=20 >> On 04/05/16 19:18, Alissa Cooper wrote: >>> Even if only a single application ever defines a priority scheme, >>> a network where clients can=E2=80=99t be trusted could fall victim to= an >>> attacker who inflates the priority of his traffic to try to >>> prevent emergency calls/first responders from getting priority >>> treatment. >>=20 >> My understanding of Diameter deployments is that they are pretty=20 >> much all done so that any node can play all sorts of games and=20 >> there are no protocol mechanisms other than hop-by-hop TLS or >> IPsec to control that. I'm not even sure how much those are >> deployed, even in cases where cryptographic keys are passed in >> Diameter messages. (And that's when the base protocol spec says you >> MUST use TLS in such cases. [1]) >>=20 >> So DRMP and DOIC are by far not the most attractive target here. >=20 > But my point was specifically about how the motivation for DRMP is > tied to the first responder and emergency use cases. When a > capability is defined specifically for those uses, people (or, say, > regulators) tend to expect it to work. So if there is a class of > cases where it won=E2=80=99t work at all =E2=80=94 even if the net effe= ct is just > that requests get treated on a best efforts basis the same as they do > today, not that some requests get starved =E2=80=94 it=E2=80=99s worth = being very > explicit about that. I=E2=80=99m sure there are other attacks that coul= d > target these uses in the absence of DRMP, but that isn=E2=80=99t a reas= on to > gloss over the DRMP-specific issue in this spec. Sure. But I'm not clear what's being glossed over. If what you mean is that some more text is needed in section 11 to discuss emergency use cases, that'd be fine, (and suggestions welcome) but I thought that that potential attack was covered there already, even if not explicitly called out. Cheers, S. >=20 > Alissa >=20 >> The DIME WG are attempting to address that via [2] but I'm not sure >> if we ought be hugely hopeful of that being implemented or deployed >> either. >>=20 >> It might help if someone more familiar with deployments can correct >> or confirm the above. >>=20 >> That doesn't affect the issue of potentially un-coordinated uses of >> different priorities across multiple Diameter applications, which >> seems like it is worth saying more about, but I'd have to say that >> uses of DRMP as an attack vector aren't that compelling from what I >> know, and the WG are attempting to at least document mechanisms >> that would provide relevant protocol countermeasures for the base >> protocol. >>=20 >> Cheers, S. >>=20 >> [1] https://tools.ietf.org/html/rfc6733#section-13.3 [2] >> https://tools.ietf.org/html/draft-ietf-dime-e2e-sec-req >>=20 >>=20 >=20 --------------ms020105030904040504040103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MDUw ODAwMjlaMC8GCSqGSIb3DQEJBDEiBCBBB3PF8C/4S1LZvWg1k8HtRqABaOfVgzpMsBYMP9yb 2jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQA28+GKYKPTxSpYpu28H+0FltWnBUlkUk3H/bdA6akwWOnzFkzPYY/a 5SMm5F9Zmnf7Kd1FYnM1le3bMTUi60bvrTEJi18icBBJByPZOFmmDZdhI/cs6k/hyNzNCImJ 9ZtgRUMDyriJZxZWIvOXc7UqVtrK+i9gzgEDS1qzEKhDj08E5ofCWn3kqYWDfrVtnPxKRGbq PTvrcm/9h7pWwNZY+VC2FB6Nm6rAkdhA7fULTzP0dKlif9dOtQH+5lbyLVIp34Hg7G46q86m coXQwipz9jd8qp4l9VQNob/L4Ykf//qzj60mqI/ahimh/11EZBwRNNng5P9zoft0tPQwsA/P AAAAAAAA --------------ms020105030904040504040103-- From nobody Thu May 5 05:21: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 0045812D1C1 for ; Thu, 5 May 2016 05:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=ofUnsxcp; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=AHEsTcuE 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 G5MA4idG4SFu for ; Thu, 5 May 2016 05:21:41 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC1EE12D179 for ; Thu, 5 May 2016 05:21:40 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 58E0420AA9 for ; Thu, 5 May 2016 08:21:40 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute2.internal (MEProxy); Thu, 05 May 2016 08:21:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=DZf63GGF9RGhiFH/b+5stpdcjbw=; b=ofUnsx cpCIMz/gBTNEUhVY8p+134bwO8zAP4LFVh80977W2FBHkgcWPeAyRhAdGn0KlWo7 PUX+1myWIihh5ZkN0+41N/HyTMyS+E9tXoKiSxOhpoN+JWEgLR+gmhPMlPxPfuzj nvDQv/O+mJwhjPHkzY5cORRSd5qqk7TsUpMqU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=DZf63GGF9RGhiFH /b+5stpdcjbw=; b=AHEsTcuE5LMy2Q91LvCBy8IpOMRlcjOsbWoXW7tVDg3N510 ShsPBZrp4WTXPaQuRZNXG8zLc8UJz4wwZzIGrWWmllEgid7lm40W77HLBQmh7/kS 7c+fV6DQ7Ki2CUfeOwTjD3MaVh+v2wboWuruE7fGtT/aHT+qBs1AC3koEl48= Received: by web5.nyi.internal (Postfix, from userid 99) id 2D666A79B25; Thu, 5 May 2016 08:21:40 -0400 (EDT) Message-Id: <1462450900.3145332.598951993.5A8DEFD7@webmail.messagingengine.com> X-Sasl-Enc: usCD8CO3qD7LFbTH6mv2FFhIHGfouVVD6TEUfgVEWuSw 1462450900 From: Alexey Melnikov To: "Gunn, Janet P" , Mirja Kuehlewind (IETF) MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-140377c4 In-Reply-To: References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> Date: Thu, 05 May 2016 13:21:40 +0100 Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 05 May 2016 12:21:44 -0000 On Wed, May 4, 2016, at 05:54 PM, Gunn, Janet P wrote: > Conceptually, that (2 queues) approach DOES correspond to assigning a > default priority. >=20 > In that particular case, you are assigning the "unknown priority" > messages to particlar priority value( a value that is not used by the > messages with "known priority") and then establishing a separate queue=20 > for THAT priority value. +1. > I am not sure whether it is a "good idea" or not, but it certainly fits > within the constraints of a "default priority". Mirja, I don't think you articulated your concern well. What the document suggests is what other similar system use. I never heard about any problems. Which of course doesn't mean that there are no problems ;-). > Janet >=20 > -----Original Message----- > From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net]=20 > Sent: Wednesday, May 04, 2016 11:51 AM > To: Gunn, Janet P > Cc: Alexey Melnikov ; > draft-ietf-dime-drmp@ietf.org; dime-chairs@ietf.org; dime@ietf.org; The > IESG > Subject: Re: [Dime] Mirja K=C3=BChlewind's Discuss on draft-ietf-dime-drm= p-05: > (with DISCUSS and COMMENT) >=20 > Hi Janet, >=20 > there are clearly more options than the two mention below. >=20 > E.g. one option is the one explained in my initial comment: hhaving two > queues, that are both served with a certain rate. >=20 > I=E2=80=99m sure there are more (and potentially more complex) solutions = to this > problem as well. >=20 > Assigning an arbitrary priority is not the right option from my point of > view and can actually hurt the systems. >=20 > Mirja >=20 >=20=20 > > Am 04.05.2016 um 17:45 schrieb Gunn, Janet P : > >=20 > > My comment below. > > Janet > >=20 > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Mirja Kuehlewind= (IETF) > > Sent: Wednesday, May 04, 2016 10:31 AM > > To: Alexey Melnikov > > Cc: draft-ietf-dime-drmp@ietf.org; dime-chairs@ietf.org; dime@ietf.org;= The IESG > > Subject: Re: [Dime] Mirja K=C3=BChlewind's Discuss on draft-ietf-dime-d= rmp-05: (with DISCUSS and COMMENT) > >=20 > > Hi Alexey, > >=20 > > see below. > >=20 > > The point is, if you explicitly indicate that you have a lower priority= , you are okay to be starved. However, if you don=E2=80=99t indicate anythi= ng (maybe just because you have not been aware that it is possible to do so= ), you might have the same or even a higher priority, and in this case it= =E2=80=99s not okay to be starved. > >=20 > > Mirja > > If a message comes in without a priority, into a system which ser= ves messages based on priority (regardless of the specific mechanisms)you h= ave two options > > 1- Discard the message (Not a good idea in most systems) > > 2 - Assign the message an ARBITRARY priority (we call this arbitrary va= lue the "default priority") > >=20 > > You can (and probably will) argue 'til the cows come home on what that = arbitrary/default value SHOULD BE. And different sytems/applications might= have different "default values". > >=20 > > But I don't think there should be any argument that, if a message comes= in without a priority, you need to assign it a priority. > >=20 > > > >=20 > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > >=20 > > This electronic message transmission contains information from CSRA tha= t may be attorney-client privileged, proprietary or confidential. The infor= mation in this message is intended only for use by the individual(s) to who= m it is addressed. If you believe you have received this message in error, = please contact me immediately and be aware that any use, disclosure, copyin= g or distribution of the contents of this message is strictly prohibited. N= OTE: Regardless of content, this email shall not operate to bind CSRA to an= y order or other contract unless pursuant to explicit written agreement or = government initiative expressly permitting the use of email for such purpos= e. >=20 From nobody Thu May 5 05:26:34 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 A663B12D51F for ; Thu, 5 May 2016 05:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=B9J8wjJ4; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=TZH63MEw 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 F3ZTSphOQjxn for ; Thu, 5 May 2016 05:26:30 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8469912D1C1 for ; Thu, 5 May 2016 05:26:30 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id EB17C20389 for ; Thu, 5 May 2016 08:26:29 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute1.internal (MEProxy); Thu, 05 May 2016 08:26:29 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=4KSG9IPt+6PcGWoVM5kPYukja8s=; b=B9J8wj J4lx7fBet5ruVnmOFkJgVagKGLoRoSqhXqHE1RYPnNb4vD6u70DiElzFYL9TbNLx lCxuyaSVoHbTk0NvMsAPV1yX3jzLzcDuKGQhcPjWzbhezI4h5rd+TX0YFZljFwmj qC8p15INi7SyVYs747rTR5IrXYGWs2unaB2jw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=4KSG9IPt+6PcGWo VM5kPYukja8s=; b=TZH63MEwXUTPbFMRhi0n13oo/uC/Wu3TVQg9KfpnC6xC8GT bAjWRVDqBc1OLmqGSJRfO2yq6CsMQAFgvbFNmyhhjIkl1k7HV2QN0qTcrJrEj/0K DOLipGEri45M3Al4iVyS2PTyoNXxeuIdHJVo08WY7U0TrvKSqUW0PvhAovoA= Received: by web5.nyi.internal (Postfix, from userid 99) id B98CEA7A324; Thu, 5 May 2016 08:26:29 -0400 (EDT) Message-Id: <1462451189.3146285.598954993.20876A3F@webmail.messagingengine.com> X-Sasl-Enc: 7N/ZLJcBIbCtEWe1Wc2UV+qPGTjPSMpr5cjqeC/m+DWO 1462451189 From: Alexey Melnikov To: Mirja Kuehlewind (IETF), "Gunn, Janet P" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-140377c4 In-Reply-To: References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> Date: Thu, 05 May 2016 13:26:29 +0100 Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 05 May 2016 12:26:32 -0000 Hi Mirja, On Wed, May 4, 2016, at 04:50 PM, Mirja Kuehlewind (IETF) wrote: > Hi Janet, >=20 > there are clearly more options than the two mention below. >=20 > E.g. one option is the one explained in my initial comment: hhaving two > queues, that are both served with a certain rate. >=20 > I=E2=80=99m sure there are more (and potentially more complex) solutions = to this > problem as well. >=20 > Assigning an arbitrary priority is not the right option from my point of > view and can actually hurt the systems. Can you please explain? (The default priority is not really arbitrary, so I want to understand why assigning a value in the middle of the allowed range is not Ok). Thank you, Alexey =20 > Mirja >=20 >=20=20 > > Am 04.05.2016 um 17:45 schrieb Gunn, Janet P : > >=20 > > My comment below. > > Janet > >=20 > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Mirja Kuehlewind= (IETF) > > Sent: Wednesday, May 04, 2016 10:31 AM > > To: Alexey Melnikov > > Cc: draft-ietf-dime-drmp@ietf.org; dime-chairs@ietf.org; dime@ietf.org;= The IESG > > Subject: Re: [Dime] Mirja K=C3=BChlewind's Discuss on draft-ietf-dime-d= rmp-05: (with DISCUSS and COMMENT) > >=20 > > Hi Alexey, > >=20 > > see below. > >=20 > > The point is, if you explicitly indicate that you have a lower priority= , you are okay to be starved. However, if you don=E2=80=99t indicate anythi= ng (maybe just because you have not been aware that it is possible to do so= ), you might have the same or even a higher priority, and in this case it= =E2=80=99s not okay to be starved. > >=20 > > Mirja > > If a message comes in without a priority, into a system which ser= ves messages based on priority (regardless of the specific mechanisms)you h= ave two options > > 1- Discard the message (Not a good idea in most systems) > > 2 - Assign the message an ARBITRARY priority (we call this arbitrary va= lue the "default priority") > >=20 > > You can (and probably will) argue 'til the cows come home on what that = arbitrary/default value SHOULD BE. And different sytems/applications might= have different "default values". > >=20 > > But I don't think there should be any argument that, if a message comes= in without a priority, you need to assign it a priority. > >=20 > > > >=20 > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > >=20 > > This electronic message transmission contains information from CSRA tha= t may be attorney-client privileged, proprietary or confidential. The infor= mation in this message is intended only for use by the individual(s) to who= m it is addressed. If you believe you have received this message in error, = please contact me immediately and be aware that any use, disclosure, copyin= g or distribution of the contents of this message is strictly prohibited. N= OTE: Regardless of content, this email shall not operate to bind CSRA to an= y order or other contract unless pursuant to explicit written agreement or = government initiative expressly permitting the use of email for such purpos= e. >=20 From nobody Thu May 5 05:51:48 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 6179B12D5ED for ; Thu, 5 May 2016 05:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=mDDVeqTj; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=fCiI3Una 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 TkrbNQNfG-MA for ; Thu, 5 May 2016 05:51:45 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECBE312D5EC for ; Thu, 5 May 2016 05:51:44 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id E768E2047E for ; Thu, 5 May 2016 08:32:10 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute4.internal (MEProxy); Thu, 05 May 2016 08:32:10 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=W7sxfAtUCRJDyXYgqnef3ET29DA=; b=mDDVeq TjauUMa1z/GZct/F71QmXpLfNLphryjZI2GOtg2V2sUMJIjO0s70enn2Qax6Nvss J554lcI1CFTfjIANM5HmYS80yRzKOS5MiZplub9Yj/sB5hNzfcf2W+q4fYSEjJNf ryWpX+QDMUqeJgf/+ug2Ie/6VHMCm/CAaVFSs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=W7sxfAtUCRJDyXY gqnef3ET29DA=; b=fCiI3UnaLIo4MfxPqFRVoHBhnlMZPFKOf5XzT86J2yEiCoD 0goAepFsRzD8It1ujnwH3EjTvMxhx3FZ5kCMkyliVVN1cPCaWVA4rIy9FUTLuQnU A/GTEqb0fEz8RO2Dp4UHYWS/ZHjE8Ni1hVMwuh7K/DYjrfpDdUZBWUrNpR5k= Received: by web5.nyi.internal (Postfix, from userid 99) id BE7EDA7A71E; Thu, 5 May 2016 08:32:10 -0400 (EDT) Message-Id: <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> X-Sasl-Enc: VWuUq52OyyytyY1cm7sLJcH29Esi0zOJc0HnKJAyKGZn 1462451530 From: Alexey Melnikov To: Mirja Kuehlewind (IETF), "Gunn, Janet P" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-140377c4 In-Reply-To: References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> Date: Thu, 05 May 2016 13:32:10 +0100 Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 05 May 2016 12:51:46 -0000 Hi Mirja, On Wed, May 4, 2016, at 04:50 PM, Mirja Kuehlewind (IETF) wrote: > Hi Janet, >=20 > there are clearly more options than the two mention below. >=20 > E.g. one option is the one explained in my initial comment: hhaving two > queues, that are both served with a certain rate. >=20 > I=E2=80=99m sure there are more (and potentially more complex) solutions = to this > problem as well. >=20 > Assigning an arbitrary priority is not the right option from my point of > view and can actually hurt the systems. I hope this will help to clarify things: One point of assigning default priority is that as this is an extension, there is a desire to avoid upgrading all clients on the network, as that would be effectively trying to deploy a new protocol. Consider a network where proxies and servers understand this extension and none of the clients do. Then default priority would be assigned to all traffic and the behaviour of the system is unchanged from the case when the extension is not deployed. The default priority only makes a difference if there is a mixture of clients implementing this extension and clients that don't. Best Regards, Alexey > Mirja >=20 >=20=20 > > Am 04.05.2016 um 17:45 schrieb Gunn, Janet P : > >=20 > > My comment below. > > Janet > >=20 > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Mirja Kuehlewind= (IETF) > > Sent: Wednesday, May 04, 2016 10:31 AM > > To: Alexey Melnikov > > Cc: draft-ietf-dime-drmp@ietf.org; dime-chairs@ietf.org; dime@ietf.org;= The IESG > > Subject: Re: [Dime] Mirja K=C3=BChlewind's Discuss on draft-ietf-dime-d= rmp-05: (with DISCUSS and COMMENT) > >=20 > > Hi Alexey, > >=20 > > see below. > >=20 > > The point is, if you explicitly indicate that you have a lower priority= , you are okay to be starved. However, if you don=E2=80=99t indicate anythi= ng (maybe just because you have not been aware that it is possible to do so= ), you might have the same or even a higher priority, and in this case it= =E2=80=99s not okay to be starved. > >=20 > > Mirja > > If a message comes in without a priority, into a system which ser= ves messages based on priority (regardless of the specific mechanisms)you h= ave two options > > 1- Discard the message (Not a good idea in most systems) > > 2 - Assign the message an ARBITRARY priority (we call this arbitrary va= lue the "default priority") > >=20 > > You can (and probably will) argue 'til the cows come home on what that = arbitrary/default value SHOULD BE. And different sytems/applications might= have different "default values". > >=20 > > But I don't think there should be any argument that, if a message comes= in without a priority, you need to assign it a priority. > >=20 > > > >=20 > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > >=20 > > This electronic message transmission contains information from CSRA tha= t may be attorney-client privileged, proprietary or confidential. The infor= mation in this message is intended only for use by the individual(s) to who= m it is addressed. If you believe you have received this message in error, = please contact me immediately and be aware that any use, disclosure, copyin= g or distribution of the contents of this message is strictly prohibited. N= OTE: Regardless of content, this email shall not operate to bind CSRA to an= y order or other contract unless pursuant to explicit written agreement or = government initiative expressly permitting the use of email for such purpos= e. >=20 From nobody Thu May 5 06:20:29 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 70A5A12D63D for ; Thu, 5 May 2016 06:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=eHALRAzf; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=CuzBvVsN 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 uATrtiQ3yUF1 for ; Thu, 5 May 2016 06:20:25 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B81012D65B for ; Thu, 5 May 2016 06:20:00 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7A98720950 for ; Thu, 5 May 2016 09:19:59 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 05 May 2016 09:19:59 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=XKS5JKfzSzJLWpa5bs0ECRSYMbo=; b=eHALRA zftFJEVkiw5GpXR+eovgDpKP7WK4akqEC4Cupz1tyCIJGuxcKaAimQOmBAaeJA8W GupIPmAF3EIiC8JrCx3iSBi2pliPyZfCAV7rwCGOYUOgmKRJfL/ew7u5PwJP74v5 iyNJvdEwCSm2M+KrHC8UTP+zw/pqEpWH7YYv8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=XKS5JKfzSzJLWpa 5bs0ECRSYMbo=; b=CuzBvVsN6b1uDVtw1fqJPn4eoeXSnqUuf0BGz0fnNyOwaEs K/MYw0ZZz9LGd8ndYPzHjnwFHkxTsMcBdLGIz2HsxUXM6awMZQ92OuJ50vK0CFxJ pXQxENWFqgOu9M/rv6gl2UwRs028upzmt/Qe8IO/XsKW+5QStuQGhkMC6r7k= X-Sasl-enc: mz82zKP2/xW4THpD8wXr7MOW3/HEe3egfUqJYGmRFwJF 1462454399 Received: from sjc-alcoop-88110.cisco.com (unknown [128.107.241.175]) by mail.messagingengine.com (Postfix) with ESMTPA id 8BF0EC00017; Thu, 5 May 2016 09:19:58 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <572AFD9D.7010909@cs.tcd.ie> Date: Thu, 5 May 2016 06:19:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> <572A1C14.5020907@usdonovans.com> <74A5239A-329E-4F82-9FBF-497C9D906E89@cooperw.in> <572A4520.5090101@cs.tcd.ie> <90C95598-F68D-4F94-8AE3-FAFF403F560E@cooperw.in> <572AFD9D.7010909@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "dime-chairs@ietf.org" , "dime@ietf.org" , IESG , "draft-ietf-dime-drmp@ietf.org" Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 05 May 2016 13:20:27 -0000 > On May 5, 2016, at 1:00 AM, Stephen Farrell = wrote: >=20 >=20 >=20 > On 05/05/16 05:31, Alissa Cooper wrote: >>=20 >>> On May 4, 2016, at 11:53 AM, Stephen Farrell >>> wrote: >>>=20 >>>=20 >>> Hiya, >>>=20 >>> Please do continue the discussion all, but just on one aspect of=20 >>> this... >>>=20 >>> On 04/05/16 19:18, Alissa Cooper wrote: >>>> Even if only a single application ever defines a priority scheme, >>>> a network where clients can=E2=80=99t be trusted could fall victim = to an >>>> attacker who inflates the priority of his traffic to try to >>>> prevent emergency calls/first responders from getting priority >>>> treatment. >>>=20 >>> My understanding of Diameter deployments is that they are pretty=20 >>> much all done so that any node can play all sorts of games and=20 >>> there are no protocol mechanisms other than hop-by-hop TLS or >>> IPsec to control that. I'm not even sure how much those are >>> deployed, even in cases where cryptographic keys are passed in >>> Diameter messages. (And that's when the base protocol spec says you >>> MUST use TLS in such cases. [1]) >>>=20 >>> So DRMP and DOIC are by far not the most attractive target here. >>=20 >> But my point was specifically about how the motivation for DRMP is >> tied to the first responder and emergency use cases. When a >> capability is defined specifically for those uses, people (or, say, >> regulators) tend to expect it to work. So if there is a class of >> cases where it won=E2=80=99t work at all =E2=80=94 even if the net = effect is just >> that requests get treated on a best efforts basis the same as they do >> today, not that some requests get starved =E2=80=94 it=E2=80=99s = worth being very >> explicit about that. I=E2=80=99m sure there are other attacks that = could >> target these uses in the absence of DRMP, but that isn=E2=80=99t a = reason to >> gloss over the DRMP-specific issue in this spec. >=20 > Sure. But I'm not clear what's being glossed over. If what you mean > is that some more text is needed in section 11 to discuss emergency > use cases, that'd be fine, (and suggestions welcome) but I thought > that that potential attack was covered there already, even if not > explicitly called out. I think the gap is in Section 5, where it should be noted that in order = for priority information to be reliably usable in the way that use cases = 5.1 and 5.2 call for, the Diameter nodes sending and consuming it must = have pre-established trust relationships of the sort described in = Section 11. Alissa >=20 > Cheers, > S. >=20 >>=20 >> Alissa >>=20 >>> The DIME WG are attempting to address that via [2] but I'm not sure >>> if we ought be hugely hopeful of that being implemented or deployed >>> either. >>>=20 >>> It might help if someone more familiar with deployments can correct >>> or confirm the above. >>>=20 >>> That doesn't affect the issue of potentially un-coordinated uses of >>> different priorities across multiple Diameter applications, which >>> seems like it is worth saying more about, but I'd have to say that >>> uses of DRMP as an attack vector aren't that compelling from what I >>> know, and the WG are attempting to at least document mechanisms >>> that would provide relevant protocol countermeasures for the base >>> protocol. >>>=20 >>> Cheers, S. >>>=20 >>> [1] https://tools.ietf.org/html/rfc6733#section-13.3 [2] >>> https://tools.ietf.org/html/draft-ietf-dime-e2e-sec-req >>>=20 >>>=20 >>=20 >=20 From nobody Thu May 5 06:22: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 870D512D65A; Thu, 5 May 2016 06:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 PsFYG3o30S7m; Thu, 5 May 2016 06:22:10 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0765012D61A; Thu, 5 May 2016 06:21:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7CA14BE38; Thu, 5 May 2016 14:21:18 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0LNl_Shd8Ui; Thu, 5 May 2016 14:21:18 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D43F6BE32; Thu, 5 May 2016 14:21:17 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462454478; bh=F1yJECuv9jHgv+Wkmvq/dVuoCUx7C0/o0/Cs5WIMo30=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Z4hycu3uZfUppctD27sG3m5MZr1n+fPZTiLbPgGixLPNQeAy/iV5jbWEmF9PLFn4h h/5yxSRw/GJA3Mj/0/93crfCyhbFlCo9Sggu+X7E5vJDcx8TsPaAIPl7I7jpJLEwD6 iKfzUBIAET+1MwQhj0MSTQ0FcyS4/XjbuTK1Q3Nc= To: Alissa Cooper References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> <572A1C14.5020907@usdonovans.com> <74A5239A-329E-4F82-9FBF-497C9D906E89@cooperw.in> <572A4520.5090101@cs.tcd.ie> <90C95598-F68D-4F94-8AE3-FAFF403F560E@cooperw.in> <572AFD9D.7010909@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <572B48D2.6090801@cs.tcd.ie> Date: Thu, 5 May 2016 14:21:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050308090905020009010302" Archived-At: Cc: "dime-chairs@ietf.org" , "dime@ietf.org" , IESG , "draft-ietf-dime-drmp@ietf.org" Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 05 May 2016 13:22:11 -0000 This is a cryptographically signed message in MIME format. --------------ms050308090905020009010302 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/05/16 14:19, Alissa Cooper wrote: > I think the gap is in Section 5, where it should be noted that in > order for priority information to be reliably usable in the way that > use cases 5.1 and 5.2 call for, the Diameter nodes sending and > consuming it must have pre-established trust relationships of the > sort described in Section 11. Sounds reasonable to me. Authors? S. --------------ms050308090905020009010302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MDUx MzIxMjJaMC8GCSqGSIb3DQEJBDEiBCCGsMXH+4vNhcbA1PtZPOwOoMFiCb6bh/oay3lBEwZX 9zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQACEkkBF96qGb7blgP8cCYQBtjAZHqoV9n4oa3WLlNbY0vrOyWDY8wG dJhZp4dmyY5pzne1yfq3i7T0JXwvG0dxtj9mucWj+3Kaz7nCr137fle9eNY4M2uQOksieM/8 yiy+5qwwP6u3kQCO+K7eTEWz4Dhi+mboL1+lwlBS/Hmuj3sBJpm7mZaIjFEhUZrfv6w0BrL4 cafCSzj25K0Ik7qibubh0woVaURwlOlLMiwap0lcwITtgc8k9i9UB/Gjexd9kEuwe8ZP/4a/ GJtybZ8Axcy7ii4ykuYoK9+m5q6+PqlxjflznNu+fui1Ao6LCf0iunDQ9/qLuWa15tFnNifQ AAAAAAAA --------------ms050308090905020009010302-- From nobody Thu May 5 06:52: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 C526112D72F; Thu, 5 May 2016 06:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 C3SZ8i6cUGXA; Thu, 5 May 2016 06:52:52 -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 7BCA812D7BC; Thu, 5 May 2016 06:51:02 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id C4D0A3B4701; Thu, 5 May 2016 15:51:00 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.2]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 9A8F623805E; Thu, 5 May 2016 15:51:00 +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.0294.000; Thu, 5 May 2016 15:51:00 +0200 From: To: Stephen Farrell , Alissa Cooper Thread-Topic: =?iso-8859-1?Q?RE=A0:_Re:_[Dime]_Alissa_Cooper's_Discuss_on_draft-ietf-di?= =?iso-8859-1?Q?me-drmp-05:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHRptUnEAX650Tv60KLf3sYDPxX4g== Date: Thu, 5 May 2016 13:50:59 +0000 Message-ID: <1881_1462456260_572B4FC4_1881_11748_1_6B7134B31289DC4FAF731D844122B36E01E54905@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> <572A1C14.5020907@usdonovans.com> <74A5239A-329E-4F82-9FBF-497C9D906E89@cooperw.in> <572A4520.5090101@cs.tcd.ie> <90C95598-F68D-4F94-8AE3-FAFF403F560E@cooperw.in> <572AFD9D.7010909@cs.tcd.ie> , <572B48D2.6090801@cs.tcd.ie> In-Reply-To: <572B48D2.6090801@cs.tcd.ie> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E01E54905OPEXCLILM43corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.5.131517 Archived-At: Cc: "dime-chairs@ietf.org" , "dime@ietf.org" , IESG , "draft-ietf-dime-drmp@ietf.org" Subject: [Dime] =?iso-8859-1?q?RE=A0=3A_Re=3A__Alissa_Cooper=27s_Discuss_o?= =?iso-8859-1?q?n_draft-ietf-dime-drmp-05=3A_=28with_DISCUSS_and_COMMENT?= =?iso-8859-1?q?=29?= 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, 05 May 2016 13:52:55 -0000 --_000_6B7134B31289DC4FAF731D844122B36E01E54905OPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Was also my proposal. Fine for me. Envoy=E9 de mon Orange Nura 2 Le 5 mai 2016 15:22, Stephen Farrell a =E9crit : On 05/05/16 14:19, Alissa Cooper wrote: > I think the gap is in Section 5, where it should be noted that in > order for priority information to be reliably usable in the way that > use cases 5.1 and 5.2 call for, the Diameter nodes sending and > consuming it must have pre-established trust relationships of the > sort described in Section 11. Sounds reasonable to me. Authors? S. ___________________________________________________________________________= ______________________________________________ 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. --_000_6B7134B31289DC4FAF731D844122B36E01E54905OPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Was also my proposal. Fine for me.

Envoy=E9 de mon Orange Nura 2

Le 5 mai 2016 15:22, Stephen Farrell <stephen.far= rell@cs.tcd.ie> a =E9crit :


On 05/05/16 14:19, Alissa Cooper wrote:
> I think the gap is in Section 5, where it should be noted that in
> order for priority information to be reliably usable in the way that > use cases 5.1 and 5.2 call for, the Diameter nodes sending and
> consuming it must have pre-established trust relationships of the
> sort described in Section 11.

Sounds reasonable to me. Authors?

S.

 
______________________________________________________________________=
___________________________________________________

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.
--_000_6B7134B31289DC4FAF731D844122B36E01E54905OPEXCLILM43corp_-- From nobody Thu May 5 07:36:29 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 62AC912DADD; Thu, 5 May 2016 07:36:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 qIZGIaDMz8k5; Thu, 5 May 2016 07:36:19 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 4933D12D89A; Thu, 5 May 2016 07:28:38 -0700 (PDT) Received: from 144.sub-70-196-15.myvzw.com ([70.196.15.144]:1361 helo=[100.82.228.205]) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.86_1) (envelope-from ) id 1ayKGX-001OUJ-FU; Thu, 05 May 2016 07:28:37 -0700 From: Steve Donovan To: Stephen Farrell , Alissa Cooper Date: Thu, 05 May 2016 09:25:59 -0500 Message-ID: <154814f98f0.277f.0301301ad371d4c21d5a2092e0e442f2@usdonovans.com> In-Reply-To: <572B48D2.6090801@cs.tcd.ie> References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> <572A1C14.5020907@usdonovans.com> <74A5239A-329E-4F82-9FBF-497C9D906E89@cooperw.in> <572A4520.5090101@cs.tcd.ie> <90C95598-F68D-4F94-8AE3-FAFF403F560E@cooperw.in> <572AFD9D.7010909@cs.tcd.ie> <572B48D2.6090801@cs.tcd.ie> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.7.29 (build: 21070094) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-1.0 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: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, IESG Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 05 May 2016 14:36:20 -0000 I'm okay with this addition. Steve On May 5, 2016 8:21:22 AM Stephen Farrell wrote: > > > On 05/05/16 14:19, Alissa Cooper wrote: > > I think the gap is in Section 5, where it should be noted that in > > order for priority information to be reliably usable in the way that > > use cases 5.1 and 5.2 call for, the Diameter nodes sending and > > consuming it must have pre-established trust relationships of the > > sort described in Section 11. > > Sounds reasonable to me. Authors? > > S. > From nobody Thu May 5 07:46:10 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 6760F12DBAC; Thu, 5 May 2016 07:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 qmC9mx8e13Ol; Thu, 5 May 2016 07:45:59 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D823B12DAA0; Thu, 5 May 2016 07:39:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5BB8FBE32; Thu, 5 May 2016 15:39:02 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFu2HjxVMeH2; Thu, 5 May 2016 15:39:02 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B46BCBE2D; Thu, 5 May 2016 15:39:01 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462459142; bh=6iGuWHvjY2cvHTcvpuYYSVMTsGLdCs/S+EHGDmFYYeM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=o/wJht7IB4YpgQJfLJUNuGDBjgfAP6BC+o6wbcfKxiJe7VVFg+N3Ydq6Hj6Iqvf/L feVlnqOyz1reRNME6DO9MDKT9rG3NT7MyYh76Z+jd6vq/mjf7SjrDoONn5xwyvzpoK Omxe+X2HxSTPJRwOQzuWIhqWtFDgN462Cu1wqiq0= To: Steve Donovan , Alissa Cooper References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> <572A1C14.5020907@usdonovans.com> <74A5239A-329E-4F82-9FBF-497C9D906E89@cooperw.in> <572A4520.5090101@cs.tcd.ie> <90C95598-F68D-4F94-8AE3-FAFF403F560E@cooperw.in> <572AFD9D.7010909@cs.tcd.ie> <572B48D2.6090801@cs.tcd.ie> <154814f98f0.277f.0301301ad371d4c21d5a2092e0e442f2@usdonovans.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <572B5B0D.9010001@cs.tcd.ie> Date: Thu, 5 May 2016 15:39:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <154814f98f0.277f.0301301ad371d4c21d5a2092e0e442f2@usdonovans.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020602000508070607090303" Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, IESG Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 05 May 2016 14:46:07 -0000 This is a cryptographically signed message in MIME format. --------------ms020602000508070607090303 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Great. I think we're maybe at the point where pushing out a revised I-D that has the fixes we now know we want would be a good plan and then we can go back around the discuss holders and see where we're at. Make sense? If not, then please continue the discussion to get us there. Cheers, S. On 05/05/16 15:25, Steve Donovan wrote: > I'm okay with this addition. >=20 > Steve >=20 >=20 > On May 5, 2016 8:21:22 AM Stephen Farrell > wrote: >=20 >> >> >> On 05/05/16 14:19, Alissa Cooper wrote: >> > I think the gap is in Section 5, where it should be noted that in >> > order for priority information to be reliably usable in the way that= >> > use cases 5.1 and 5.2 call for, the Diameter nodes sending and >> > consuming it must have pre-established trust relationships of the >> > sort described in Section 11. >> >> Sounds reasonable to me. Authors? >> >> S. >> >=20 >=20 --------------ms020602000508070607090303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MDUx NDM5MDlaMC8GCSqGSIb3DQEJBDEiBCDMVe5IrZTGkHXm/DSj2U7os7a9XVCJIVY4IcV/OrJi xDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCj6PDJ1Z5qN2Vq7Xc89WNdLEdFyHWQlKzqebhF5ODzE7VsyPY66qBn a/v794wxjVW3X6K0cWTx5IiSUwtf+bZ+DUQuKZBTufq/4DXD47bv4MzAkSuSAXviwMpgTI2N 7iEP/gg8QOm9lxj4e/AmW70BHFvXiSw7Ic2yYDaAITOFnwRIxQcETI+nryl1gTQP6IObfADD wPtciKM6GITxL3if+vYMm9ddZqGnOkkk+H7q1KC1SIIZzEvKwmkIo5Cy+L2ZT14++4pAtqhv 9Id/6T78FOGoL9T/HVdUUCdiTYxwU9f/bY1m8ECTjiSNVaB9Y1J02ccYs7NvRJaM43OFF1PD AAAAAAAA --------------ms020602000508070607090303-- From nobody Thu May 5 08:02: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 6443812DBBC; Thu, 5 May 2016 08:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 bzLiCHVSpgyj; Thu, 5 May 2016 08:02:07 -0700 (PDT) Received: from mailport8.csra.com (mailport8.csra.com [131.131.97.26]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5BA612DAF7; Thu, 5 May 2016 07:54:28 -0700 (PDT) Received: from csrrdu1exm030.corp.csra.com (HELO mail.csra.com) ([10.8.2.30]) by mailport8.csra.com with ESMTP/TLS/AES256-SHA; 05 May 2016 10:54:50 -0400 Received: from CSRRDU1EXM025.corp.csra.com (10.8.2.25) by CSRRDU1EXM022.corp.csra.com (10.8.2.22) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 5 May 2016 10:54:25 -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.1130.005; Thu, 5 May 2016 10:54:25 -0400 From: "Gunn, Janet P" To: Steve Donovan , Stephen Farrell , Alissa Cooper Thread-Topic: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) Thread-Index: AQHRpZWF+eHCkhdVT0iu5gobDQr6gp+pM2gAgAAnQoCAAAmsAIAAoYmAgAA6ZYCAAFlCgIAAAGUAgAASDoD//8TSEA== Date: Thu, 5 May 2016 14:54:24 +0000 Message-ID: <92d88ead4caa449797ccb84a438e7d60@CSRRDU1EXM025.corp.csra.com> References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> <572A1C14.5020907@usdonovans.com> <74A5239A-329E-4F82-9FBF-497C9D906E89@cooperw.in> <572A4520.5090101@cs.tcd.ie> <90C95598-F68D-4F94-8AE3-FAFF403F560E@cooperw.in> <572AFD9D.7010909@cs.tcd.ie> <572B48D2.6090801@cs.tcd.ie> <154814f98f0.277f.0301301ad371d4c21d5a2092e0e442f2@usdonovans.com> In-Reply-To: <154814f98f0.277f.0301301ad371d4c21d5a2092e0e442f2@usdonovans.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.8.2.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-dime-drmp@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , IESG Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 05 May 2016 15:02:14 -0000 Looks good to me. Janet -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Thursday, May 05, 2016 10:26 AM To: Stephen Farrell ; Alissa Cooper Cc: draft-ietf-dime-drmp@ietf.org; dime-chairs@ietf.org; dime@ietf.org; IES= G Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (wi= th DISCUSS and COMMENT) I'm okay with this addition. Steve On May 5, 2016 8:21:22 AM Stephen Farrell wrote= : > > > On 05/05/16 14:19, Alissa Cooper wrote: > > I think the gap is in Section 5, where it should be noted that in > > order for priority information to be reliably usable in the way that > > use cases 5.1 and 5.2 call for, the Diameter nodes sending and > > consuming it must have pre-established trust relationships of the > > sort described in Section 11. > > Sounds reasonable to me. Authors? > > S. > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime 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. From nobody Thu May 5 10:43: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 32CEE12D7E9 for ; Thu, 5 May 2016 10:43:23 -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 0UR9qtijWufz for ; Thu, 5 May 2016 10:43:16 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 4E04E12D7E3 for ; Thu, 5 May 2016 10:42:52 -0700 (PDT) Received: by mail-pa0-x22b.google.com with SMTP id r5so39260047pag.1 for ; Thu, 05 May 2016 10:42:52 -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=i+REI8bnYvfh8IGADq+4L5ZHR+p6veMaBtmXl2JnpAM=; b=F9RSKh8DU+PSoHGTtUr7Ht9k/1A/P9IlWxbWrbEL1tmOAwS968F14H5UVsKgsUGMoH e9s5lEXqAZFTy8dbl0UWjvczPxC8xV4Ei3s+IujaW+NHyOWspCEc5iDK59Yjgu+LQT7o ylZsQPsFHCVn6Kxmt2UwHITtlMpDbm81jSR0TA9I7x2i/mWXDlZ4j804H1c5whEqINIp x4Zi7d0XD4FkQiOimO6K6yDIsZNVwDmDg0jyCY2sueCZt5NjI4kjURXYSkYoRwtFevim VfL3ylfpy2FRReT1by9QrRKXGIBcsztvWXFdAmfIcAM9Ukoith10u/LhJFik+iMGgawV VVWA== 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=i+REI8bnYvfh8IGADq+4L5ZHR+p6veMaBtmXl2JnpAM=; b=erm8JHkC/l5AbbRj+yP/hyBEH/1Xw3DkFCS1UICjj/A2XFB0C940N6QUymPOav25OA Ihnk130dUH2VLtI6WwKtbqs9yM9tW/aMLFjuSyaDqjyOXCVkUDOu8DWedki35St69X28 5m3XjvWoc7Y05yzywjDQjpjPjCa7M/TFRHBlVEoIO1YUP3Px8AV6/hSjkcaYZDFWnsoj +etBzhWrgmy8Ms6f0uvs+QK9r56cpRPti48OaXQ0kXssfgVtFbOT2qF62IMMYxv53lHG vRewvKP/HYpOZqMeQqG8mgZI6vVguQTcBgvVaLi7uIihnfMoP2Ov3H738WwnzsrkbTA/ DoYQ== X-Gm-Message-State: AOPr4FWAOyu1x84oCzo2r5rqqlVRilb86vt4MHNJAZUQLBwnwMlg/Z996tX8gge7PpOWOw== X-Received: by 10.66.148.42 with SMTP id tp10mr22550670pab.159.1462470171872; Thu, 05 May 2016 10:42:51 -0700 (PDT) Received: from ?IPv6:2601:647:4205:17e0:f182:ba5f:6ca2:c10? ([2601:647:4205:17e0:f182:ba5f:6ca2:c10]) by smtp.googlemail.com with ESMTPSA id ve11sm15198688pab.21.2016.05.05.10.42.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2016 10:42:51 -0700 (PDT) References: <20160505000454.8358.57070.idtracker@ietfa.amsl.com> To: "dime@ietf.org" From: Jouni Korhonen Message-ID: <572B8619.1070405@gmail.com> Date: Thu, 5 May 2016 10:42:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160505000454.8358.57070.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Joel Jaeggli , 3GPPLiaison@etsi.org Subject: Re: [Dime] New Liaison Statement, "LS to IETF for clarification on RFC 4006 for Diameter Base Protocol" 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, 05 May 2016 17:43:23 -0000 Folks, Have a look at the LS we recently received from the 3GPP SA5. Looking at our charter and what we have discussed recently updating RFC4006 is not likely.. unless someone volunteers to take a ball on it asap. I have not read RFC4006 for a long time so my memory might serve me wrong. The immediate things to look into when responding to this LS (assuming we would only give recommendations) relate to security. RFC4006 AVPs seems to care about the AVL 'P' bit setting and 'Encr'. Since both of these are deprecated in RFC6733 we better say something about that. Another thing, which is outside the LS scope, though, is the CCA CCF. Here I am referring to the discussion in Buenos Aires on the answer message when 'E' bit is set. Any thoughts? We have about a week to prepare the reply LS. The due date is 23rd May. - Jouni 5/4/2016, 5:04 PM, Liaison Statement Management Tool kirjoitti: > Title: LS to IETF for clarification on RFC 4006 for Diameter Base Protocol > Submission Date: 2016-05-04 > URL of the IETF Web page: https://datatracker.ietf.org/liaison/1470/ > Please reply by 2016-05-23 > From: "Maryse Gardella" > To: Jouni Korhonen ,Lionel Morand > Cc: Benoit Claise ,Lionel Morand ,Joel Jaeggli ,Jouni Korhonen ,Diameter Maintenance and Extensions Discussion List , > Response Contacts: 3GPPLiaison@etsi.org > Technical Contacts: > Purpose: For action > > Body: > Attachments: > > LS to IETF for clarification on RFC 4006 for Diameter Base Protocol > https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-05-04-3gpp-tsg-sa-wg5-dime-ls-to-ietf-for-clarification-on-rfc-4006-for-diameter-base-protocol-attachment-1.doc > From nobody Fri May 6 03:14: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 CECF312D954 for ; Fri, 6 May 2016 03:14:39 -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 1Z9CNFxl9wf2 for ; Fri, 6 May 2016 03:14:37 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28C1912D955 for ; Fri, 6 May 2016 03:14:36 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-cd-572c6e8b3886 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F6.5C.27088.B8E6C275; Fri, 6 May 2016 12:14:35 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.195]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Fri, 6 May 2016 12:14:34 +0200 From: Maria Cruz Bartolome To: "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: Use of SourceID AVP in Agent Overload and Load control drafts Thread-Index: AdGcl068okSqgAUnQBa17vO+IzGcqwK6A60w Date: Fri, 6 May 2016 10:14:34 +0000 Message-ID: <087A34937E64E74E848732CFF8354B92181BA613@ESESSMB101.ericsson.se> References: <20257_1461331744_571A2720_20257_12979_1_6B7134B31289DC4FAF731D844122B36E01E43A7C@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <20257_1461331744_571A2720_20257_12979_1_6B7134B31289DC4FAF731D844122B36E01E43A7C@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7nG53nk64wfmVEhZze1ewWdzenunA 5LFkyU8mj5ZnJ9kCmKK4bFJSczLLUov07RK4MhZ2TWcqWCpXsXL+V9YGxq0SXYycHBICJhLT nu9lhbDFJC7cW8/WxcjFISRwhFHi26/PUM5iIKfrPFgVm4CdxKXTL5hAbBGBGIlZ598yg9jC Al4SXS8XQ8W9JbqmHmCFsI0kNrY2MILYLAIqEqcmt7KB2LwCvhLtk5ewQizoZJQ4se09mMMp 0MUocavnNVgHI9BN30+tAZvKLCAucevJfCaIWwUkluw5zwxhi0q8fPwPqJkDyFaSmLY1DaJc R2LB7k9sELa2xLKFr5khFgtKnJz5hGUCo+gsJFNnIWmZhaRlFpKWBYwsqxhFi1OLk3LTjYz0 Uosyk4uL8/P08lJLNjECI+Xglt8GOxhfPnc8xCjAwajEw7vgl3a4EGtiWXFl7iFGCQ5mJRFe xiydcCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtSi2CyTBycUg2M3lzz 5Zm0onZGJxnHCgnP9jk+fWFaeKy9W07qn3nWvIv+bOXriLo8Y8pfzu9fPbesvhXJePSIpfHn n5E667IrLx5KEH16frL07PrA0Iq9vsvXfp3wU8J7g9bjK6snHPVof6R57uH1NwuiTkaY97vO 22a5qLJF9brwW/ezLKK9m+QCc6dPyNfapsRSnJFoqMVcVJwIAFZf86qQAgAA Archived-At: Subject: Re: [Dime] Use of SourceID AVP in Agent Overload and Load control drafts 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, 06 May 2016 10:14:40 -0000 Hello Lionel, all, I think there is not a need to define two AVPs, when in fact the purpose of= the AVP in both case is the same, i.e. identify the Diameter node that ins= erts this AVP. Then, that diameter node is considered as the source of the = Load information (if inserted in Load AVP) or the Overload Information (if = inserted in OC-OLR AVP). If the problem you want to solve is the dependency of one draft to another,= I will propose to simply progress first the one that we consider is more r= elevant, according to last emails it seems that Load is progressing faster,= then we can simply have the definition of the SourceID AVP in the Load dra= ft. Then, this definition should be generic enough, to allow a direct appli= cability to Agent Overload draft. Would that work for you? Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: viernes, 22 de abril de 2016 15:29 To: dime@ietf.org Subject: [Dime] Use of SourceID AVP in Agent Overload and Load control draf= ts Hi, At the last IETF meeting, we have discussed the interdependence between the= load control and the Agent Overload draft regarding the use of the SourceI= D AVP. First of all, there is some inconsistency in the agent overload draft. The = AVP is sometimes named OC-SourceID AVP and sometimes OC-SourcedID. This nee= ds to be fixed. Now, if we look at the definition of the OC-SourceID in the agent overload = draft , we find: 6.3. OC-SourceID The [OC-]SourceID AVP (AVP code TBD2) is of type DiameterIdentity and is inserted by the DOIC node that either indicates support for this feature (in the OC-Supported-Features AVP) or that generates an OC- OLR AVP with a report type of peer. It contains the Diameter Identity of the inserting node. This is used by other DOIC nodes to determine if the a peer indicated support this feature or inserted the peer report. This definition is interesting and should be kept from my point of view. I = think that having an AVP identifying the source of DOIC node is a good poin= t and this should remain. I would be then in favor to define two separate AVPs, one identifying a OC = source, another identifying a Load source. I propose to keep "OC-SourceID" for the first one and "Load-SourceID" for t= he second one. Additional advantage: if this approach is agreed, there is no need to link = both drafts anymore. Does it sound acceptable? I will initiate issues aligned with this proposal. According to the conclus= ion of this discussion, they can be accepted or rejected later. Regards, Lionel ___________________________________________________________________________= ______________________________________________ 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 Fri May 6 08:50:00 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 A922012B03D for ; Fri, 6 May 2016 08:49:58 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 UXPYkRcEYanS for ; Fri, 6 May 2016 08:49:57 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 2B4FD12B019 for ; Fri, 6 May 2016 08:49:57 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:50305 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 1ayi0l-0023yD-Np for dime@ietf.org; Fri, 06 May 2016 08:49:56 -0700 To: dime@ietf.org References: <20257_1461331744_571A2720_20257_12979_1_6B7134B31289DC4FAF731D844122B36E01E43A7C@OPEXCLILM43.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B92181BA613@ESESSMB101.ericsson.se> From: Steve Donovan Message-ID: <572CBD1F.2000605@usdonovans.com> Date: Fri, 6 May 2016 10:49:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <087A34937E64E74E848732CFF8354B92181BA613@ESESSMB101.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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] Use of SourceID AVP in Agent Overload and Load control drafts 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, 06 May 2016 15:49:59 -0000 I prefer to fix the definition in the agent overload draft and progress it first or in parallel with the load draft. We need to finish all of these drafts and the agent overload draft is the oldest. This shouldn't slow the load draft if we do things in parallel. Steve On 5/6/16 5:14 AM, Maria Cruz Bartolome wrote: > Hello Lionel, all, > > I think there is not a need to define two AVPs, when in fact the purpose of the AVP in both case is the same, i.e. identify the Diameter node that inserts this AVP. Then, that diameter node is considered as the source of the Load information (if inserted in Load AVP) or the Overload Information (if inserted in OC-OLR AVP). > > If the problem you want to solve is the dependency of one draft to another, I will propose to simply progress first the one that we consider is more relevant, according to last emails it seems that Load is progressing faster, then we can simply have the definition of the SourceID AVP in the Load draft. Then, this definition should be generic enough, to allow a direct applicability to Agent Overload draft. > > Would that work for you? > Best regards > /MCruz > > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com > Sent: viernes, 22 de abril de 2016 15:29 > To: dime@ietf.org > Subject: [Dime] Use of SourceID AVP in Agent Overload and Load control drafts > > Hi, > > At the last IETF meeting, we have discussed the interdependence between the load control and the Agent Overload draft regarding the use of the SourceID AVP. > > First of all, there is some inconsistency in the agent overload draft. The AVP is sometimes named OC-SourceID AVP and sometimes OC-SourcedID. This needs to be fixed. > > Now, if we look at the definition of the OC-SourceID in the agent overload draft , we find: > > 6.3. OC-SourceID > > The [OC-]SourceID AVP (AVP code TBD2) is of type DiameterIdentity and is > inserted by the DOIC node that either indicates support for this > feature (in the OC-Supported-Features AVP) or that generates an OC- > OLR AVP with a report type of peer. > > It contains the Diameter Identity of the inserting node. This is > used by other DOIC nodes to determine if the a peer indicated support > this feature or inserted the peer report. > > This definition is interesting and should be kept from my point of view. I think that having an AVP identifying the source of DOIC node is a good point and this should remain. > I would be then in favor to define two separate AVPs, one identifying a OC source, another identifying a Load source. > I propose to keep "OC-SourceID" for the first one and "Load-SourceID" for the second one. > > Additional advantage: if this approach is agreed, there is no need to link both drafts anymore. > > Does it sound acceptable? > > I will initiate issues aligned with this proposal. According to the conclusion of this discussion, they can be accepted or rejected later. > > Regards, > > Lionel > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques 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 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 delete 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 > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Fri May 6 09:04:11 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 EA22512D505; Fri, 6 May 2016 09:04:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 8bv7eCiyo7LV; Fri, 6 May 2016 09:04:04 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 C070812D1DE; Fri, 6 May 2016 09:04:04 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:50353 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 1ayiER-002Fg5-W2; Fri, 06 May 2016 09:04:04 -0700 To: Stephen Farrell , Alissa Cooper References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> <572A1C14.5020907@usdonovans.com> <74A5239A-329E-4F82-9FBF-497C9D906E89@cooperw.in> <572A4520.5090101@cs.tcd.ie> <90C95598-F68D-4F94-8AE3-FAFF403F560E@cooperw.in> <572AFD9D.7010909@cs.tcd.ie> <572B48D2.6090801@cs.tcd.ie> <154814f98f0.277f.0301301ad371d4c21d5a2092e0e442f2@usdonovans.com> <572B5B0D.9010001@cs.tcd.ie> From: Steve Donovan Message-ID: <572CC06E.7090405@usdonovans.com> Date: Fri, 6 May 2016 11:03:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <572B5B0D.9010001@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-1.0 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: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, IESG Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 06 May 2016 16:04:06 -0000 All, I was on jury duty yesterday so I wasn't able to fully engage. I agree that we are close to resolving issues and I will produce an updated draft that addresses IESG review comments, along with one change requested by IANA. I also need to respond to Ben's last email. My proposal, modulo Ben's comments, is to add the following to the draft: - Emphasizing that the mechanism only works when one of the following is true: - Agents only handle a single DRMP application. - All Diameter applications that support DRMP used in a Diameter network must have consistent and synchronized priority definitions. I'll add some words around what is meant by consistent and synchronized. - Strengthening wording indicating that this mechanism is designed to work in trusted environments. This includes recommending stripping or modifying priority settings for requests received from untrusted sources. The determination of what is a trusted and untrusted source would be out of the scope of the DRMP draft. - Adding the other updates that have been agreed to as part of this review cycle. This leaves as future work, should there be a need, the handling multiple "priority schemes" within a single network. This is a very hard problem and not a use case that is currently needed by existing users of Diameter. I'll wait for feedback, especially from the Dime working group, before I start updating the document. Regards, Steve On 5/5/16 9:39 AM, Stephen Farrell wrote: > Great. I think we're maybe at the point where pushing out a > revised I-D that has the fixes we now know we want would be a > good plan and then we can go back around the discuss holders > and see where we're at. > > Make sense? If not, then please continue the discussion to > get us there. > > Cheers, > S. > > On 05/05/16 15:25, Steve Donovan wrote: >> I'm okay with this addition. >> >> Steve >> >> >> On May 5, 2016 8:21:22 AM Stephen Farrell >> wrote: >> >>> >>> On 05/05/16 14:19, Alissa Cooper wrote: >>>> I think the gap is in Section 5, where it should be noted that in >>>> order for priority information to be reliably usable in the way that >>>> use cases 5.1 and 5.2 call for, the Diameter nodes sending and >>>> consuming it must have pre-established trust relationships of the >>>> sort described in Section 11. >>> Sounds reasonable to me. Authors? >>> >>> S. >>> >> From nobody Fri May 6 12:48:38 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 645AF12D6B8; Fri, 6 May 2016 12:48:37 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 wdLCPbrIa2Ny; Fri, 6 May 2016 12:48:36 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 43E0812D6B7; Fri, 6 May 2016 12:48:36 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:52598 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 1ayljl-000XnZ-Hr; Fri, 06 May 2016 12:48:35 -0700 To: Ben Campbell , The IESG References: <20160504023124.8242.52368.idtracker@ietfa.amsl.com> <572A227D.1040203@usdonovans.com> <45E2E5D4-091E-4311-9FDF-271B04D59D05@nostrum.com> From: Steve Donovan Message-ID: <572CF510.20202@usdonovans.com> Date: Fri, 6 May 2016 14:48:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <45E2E5D4-091E-4311-9FDF-271B04D59D05@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Cc: draft-ietf-dime-drmp@ietf.org, "dime-chairs@ietf.org" , dime@ietf.org Subject: Re: [Dime] Ben Campbell's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 06 May 2016 19:48:37 -0000 Ben, See my comments inline. Steve On 5/4/16 10:58 PM, Ben Campbell wrote: > (oops, sent this earlier, but it just went to Steve. Resending to full > list) > > Thanks for the quick response. Further discussion inline: > > Ben. > > On 4 May 2016, at 11:25, Steve Donovan wrote: > > [...] > >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> I have a few concerns that I think need some discussion. >>> >>> 1) Priority between applications: The fact that agents can apply >>> priority >>> for messages from multiple applications without knowledge of those >>> applications seems dangerous. Let's say application A is a critical >>> infrastructure application, and application B is not. But clients for >>> application B might set requests to have a higher priority than do >>> clients for application A. Further, application B could become a DoS >>> vector for application A. One potential (and likely half-baked) way to >>> mitigate this would be to say that nodes that are not "application >>> aware" >>> can only apply priority among messages for the same application. >> SRD> This is similar to saying that priority setting across >> applications need to be set in a consistent way. We might need to >> define the "priority scheme" or some similar concept as sketched out >> in my response to Alissa's DISCUSS. > > That would probably help. Am I correct in assuming that would require > some WG discussion? > It occurs to me after sleeping on it that, in congestion cases, this > would leave things no worse than when a relay agent throttles requests > with even less information. But it's a little more worrisome when used > in non-congested circumstances, assuming they leave the possibility of > throttling or otherwise rejecting requests under normal processing > conditions. SRD> See my proposed changes to the draft sent in a separate email. I think this addresses the above concern and is currently waiting WG discussion. > >>> >>> 2) Priority between clients of the same application: If you have >>> multiple >>> clients for the same application, don't they need to use the same >>> prioritization strategy? How is this to be managed? >> SRD> It is not directly defined. This is back to the question of >> whether or not the mechanism is constrained to only work in a trusted >> environment. > > The potential "priority scheme" might help here. But why does a > trusted environment matter? Lets say you have trusted clients from > vender A and from vendor B, but they select priorities differently? SRD> They aren't trusted if they aren't using the defined standards. In addition, trusted environment generally means operated by a single entity. That operator has the job of ensuring that what you are proposing would not happen. > >>> >>> 3) Out of order requests: The draft explicitly allows agents to >>> re-route >>> and even explicitly re-order messages. Is it safe to have a >>> non-application aware node change the order of messages? >> SRD> This mechanism doesn't change the need for Diameter nodes to >> handle messages arriving out of order. This exists in any protocol >> that has agents/proxies. > > Okay, I will withdraw that part. (How quick one forgets...) > >>> >>> 4) I am nervous about the idea that clients and servers would use a >>> generic message priority mechanism to manage the allocation of >>> resources >>> that result from a requests and answers. It seems like that should be >>> based on application specific rules and information. (Now, if the point >>> is that these same AVPs might be used in an application according to >>> application specific rules, that might be okay--but then you might run >>> into issues where application-agnostic agents don't know the >>> difference.) >> SRD> The definition of what different priority levels mean will >> reflect the application specific knowledge. Agents just route >> requests and with the introduction of DOIC, sometimes throttle them. >> The agent doesn't need anything but the priority value, as long as >> the priority values are defined consistently across all applications. > > My concern was more about client and server behavior, but it may be > impacted by relays. I assume that a relay agent would not be making > decisions about resource allocation, at least beyond transactions state. > > My concern is twofold: In the case of servers, this seems to give a > server leave to send a successful answer, but not allocate any > necessary resources to support that success. This seems to lead to > circumstances where the server thinks something failed but the client > thinks it worked. (I have no problem with saying that a > resource-constrained server might include priority as a factor in it's > decisions about which requests to reject.) SRD> DRMP does not change application server behavior. It just influences the order in which requests are processed. As such, I don't see how DRMP would cause the server to falsely send a success response. > > In the case of clients, I think we are talking about a client > abandoning some task even though the server thinks it worked. I don't > see that as a problem per se, but I would expect a server to do that > based on some local knowledge of priority. It seems a stretch that it > would do so based on a priority value inserted by the server. But even > if that makes sense, I understand that this draft allows relay agents > with no knowledge of the application semantics to insert, remove, or > change priority values in answer messages. (Maybe the answer here is > stricter guidance on when relay agents can change priority values, and > allowing the client to ignore priority values in answers (especially > success answers) SRD> Clients abandoning things can happen without DRMP. It's up to the application to define the correct behavior when this happens. DRMP doesn't change anything on that front. As such, I don't see the concern. > > > >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> General: I approached this assuming prioritization would matter only in >>> overload scenarios. But I gather you envision using this in >>> non-overload >>> scenarios? (This interacts with my discuss point about the use of >>> DRMP to >>> prioritize resource allocation that result result from successful >>> diameter transactions.) Use case 5.3 is a bit worrisome in this >>> context. >> SRD> I don't understand the concern. > > I'm concerned that this could effectively induce overload for lower > priority messages, when the nodes would normally be able to handle all > messages. In use case 5.3, does the platinum customer buy the right to > cause other customer's requests to fail? SRD> It is certainly possible that higher priority messages could starve lower priority messages. The only case when this would result in a lower priority message not getting service in non congestion scenarios is if the lower priority message times out. This is a recognized side effect of priority based schemes like this. An operator offering a service like 5.3 would have to take this into consideration. I would expect that in a well thought out priority scheme the percentage of high priority messages will be significantly less than low priority messages, reducing the probability of starving the low priority messages. How this is done, however, is out side the scope of this document. > > >>> >>> >>> -6, list item 4: Are there really use cases for answer senders to set a >>> different priority on the answer than was on the request? That seems to >>> add quite a bit of complexity. >> SRD> This was an explicit conversation within the working group. I >> don't recall the specific use case off the top of my head, but this >> was changed to the current wording after discussions within the >> working group. I can go back to the email archive to refresh my >> memory if necessary. > > I am willing to accede to working group consensus on this. But one > question: Does this apply to answers that indicate success, as well as > failure? SRD> Yes. > >>> >>> - 6, list item 8: I'm not sure what it means for a client to prioritize >>> answers to it's own requests. >> SRD> The client could choose to complete the transaction, and >> initiate other dependent actions, based on the priority received in >> the answer message. It is those dependent actions -- setting up a >> data channel, authorizing call completion, etc -- that would be >> impacted by the priorities received in the answer. > > See the comments on item 4 from my discuss. SRD> See my response. Is there something else that I'm missing? > >>> >>> -8, "Diameter nodes SHOULD >>> include Diameter routing message priority in the DRMP AVP in all >>> Diameter request messages." : >>> Does that apply to all nodes that touch a request, or just the request >>> originator? >> SRD> This statement was meant to apply to the request originator. >> The statement should be updated. > > Okay. > >>> >>> -- "Diameter nodes MUST use the priority indicated in the DRMP AVP >>> carried in the answer message, if it exists." >>> The MUST seems odd, since paying attention to the priority in the >>> initial >>> request was only SHOULD. >> SRD> The wording here is cumbersome. The full paragraph is as follows: >> >> When determining the priority to apply to answer messages, Diameter >> nodes MUST use the priority indicated in the DRMP AVP carried in the >> answer message, if it exists. Otherwise, the Diameter node MUST use >> the priority indicated in the DRMP AVP of the associated request >> message. >> >> This is meant to say that a Diameter node receiving an answer message >> MUST use the priority value in the answer message when processing the >> message. If there is no DRMP AVP in the answer message then the >> receiving node uses the priority that was in the request message. >> I'd be happy to re-craft this to be more clear. > > Part of my concern is that the MUST vs SHOULD bit is different for > requests and answers. statements of the form "If you use the > mechanism, you MUST do X" do not mean the same as "SHOULD do X", even > if the reasoning behind the SHOULD is that a node might not use the > mechanism. SRD> There are no SHOULD statements in this paragraph. This requirement only applies "When determining the priority to apply to __received__ answer messages". I don't see the conflict. > >>> >>> -- "Another is to use the Proxy-Info >>> mechanism defined in [RFC6733].": >>> That probably needs some elaboration. >> SRD> A reference to the document that defines Proxy-Info isn't >> sufficient? > > On a re-read, it's probably good enough, although on reflection, I > don't think this draft needs to tell relay agents how to manage > transaction state. But it doesn't hurt either way. SRD> This draft doesn't, it lists two options. The Proxy-Info qualifier was inserted because there was a suggestion that the wording indicate the state is stored locally by the agent. From nobody Fri May 6 13:03:43 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 A245212D1A5; Fri, 6 May 2016 13:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=unavailable 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 ZjCLGlI526r3; Fri, 6 May 2016 13:03:40 -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 A39FE12B017; Fri, 6 May 2016 13:03:40 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u46K3VTI064952 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 6 May 2016 15:03:31 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Steve Donovan" Date: Fri, 06 May 2016 15:03:31 -0500 Message-ID: <2609D587-563B-4C0E-B769-FB8DC0A9D10F@nostrum.com> In-Reply-To: <572CC06E.7090405@usdonovans.com> References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> <572A1C14.5020907@usdonovans.com> <74A5239A-329E-4F82-9FBF-497C9D906E89@cooperw.in> <572A4520.5090101@cs.tcd.ie> <90C95598-F68D-4F94-8AE3-FAFF403F560E@cooperw.in> <572AFD9D.7010909@cs.tcd.ie> <572B48D2.6090801@cs.tcd.ie> <154814f98f0.277f.0301301ad371d4c21d5a2092e0e442f2@usdonovans.com> <572B5B0D.9010001@cs.tcd.ie> <572CC06E.7090405@usdonovans.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, Alissa Cooper , dime-chairs@ietf.org, dime@ietf.org, IESG Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 06 May 2016 20:03:41 -0000 I'm jumping in here because part of it also relates to some of my DISCUSS points: On 6 May 2016, at 11:03, Steve Donovan wrote: > All, > > I was on jury duty yesterday so I wasn't able to fully engage. > > I agree that we are close to resolving issues and I will produce an > updated draft that addresses IESG review comments, along with one > change requested by IANA. > > I also need to respond to Ben's last email. > > My proposal, modulo Ben's comments, is to add the following to the > draft: > > - Emphasizing that the mechanism only works when one of the following > is true: > > - Agents only handle a single DRMP application. What does that mean from a standards perspective? A "relay agent" is assumed to be application-agnostic. So in some ways, it supports all applications. Even ones that don't exist yet. A proxy, OTOH, is assumed to know application semantics--but I don't think that is what we are talking about, is it? Or do this just mean that the operator makes sure that messages from only one application traverse the agent? (There's risk that they will forget that part when adding a 2nd application down the road.) (But see next comment...) > - All Diameter applications that support DRMP used in a Diameter > network must have consistent and synchronized priority definitions. > I'll add some words around what is meant by consistent and > synchronized. Those would help, but I don't think handling a single DRMP application necessarily removes the need for consistent priority definitions. As with DOIC, you may see cases where vendors and or operators wish to apply DRMP to applications even though the specifications for that application do not define its use. (or perhaps before the owners of the standard for legacy applications get around to doing so.) I'm not sure if the intent is to allow that, but if it is, then you need consistent policies across nodes. If the expectation is that DRMP can only be used when documented in the "standard" for the application, then it would be good to include some high-level detail about what we expect to be documented. > > - Strengthening wording indicating that this mechanism is designed to > work in trusted environments. This includes recommending stripping or > modifying priority settings for requests received from untrusted > sources. The determination of what is a trusted and untrusted source > would be out of the scope of the DRMP draft. > > - Adding the other updates that have been agreed to as part of this > review cycle. > > This leaves as future work, should there be a need, the handling > multiple "priority schemes" within a single network. This is a very > hard problem and not a use case that is currently needed by existing > users of Diameter. > > I'll wait for feedback, especially from the Dime working group, before > I start updating the document. > > Regards, > > Steve > > On 5/5/16 9:39 AM, Stephen Farrell wrote: >> Great. I think we're maybe at the point where pushing out a >> revised I-D that has the fixes we now know we want would be a >> good plan and then we can go back around the discuss holders >> and see where we're at. >> >> Make sense? If not, then please continue the discussion to >> get us there. >> >> Cheers, >> S. >> >> On 05/05/16 15:25, Steve Donovan wrote: >>> I'm okay with this addition. >>> >>> Steve >>> >>> >>> On May 5, 2016 8:21:22 AM Stephen Farrell >>> >>> wrote: >>> >>>> >>>> On 05/05/16 14:19, Alissa Cooper wrote: >>>>> I think the gap is in Section 5, where it should be noted that in >>>>> order for priority information to be reliably usable in the way >>>>> that >>>>> use cases 5.1 and 5.2 call for, the Diameter nodes sending and >>>>> consuming it must have pre-established trust relationships of the >>>>> sort described in Section 11. >>>> Sounds reasonable to me. Authors? >>>> >>>> S. >>>> >>> From nobody Fri May 6 13:45: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 62AC912D13B; Fri, 6 May 2016 13:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 kiz73IGoitIE; Fri, 6 May 2016 13:45:45 -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 AC3FD128874; Fri, 6 May 2016 13:45:45 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u46KjhOP007509 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 6 May 2016 15:45:44 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Steve Donovan" Date: Fri, 06 May 2016 15:45:43 -0500 Message-ID: <7EB67D8A-B1DE-4456-B89A-6E049A6BADE5@nostrum.com> In-Reply-To: <572CF510.20202@usdonovans.com> References: <20160504023124.8242.52368.idtracker@ietfa.amsl.com> <572A227D.1040203@usdonovans.com> <45E2E5D4-091E-4311-9FDF-271B04D59D05@nostrum.com> <572CF510.20202@usdonovans.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, "dime-chairs@ietf.org" , dime@ietf.org, The IESG Subject: Re: [Dime] Ben Campbell's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 06 May 2016 20:45:47 -0000 On 6 May 2016, at 14:48, Steve Donovan wrote: [...] >> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> I have a few concerns that I think need some discussion. >>>> >>>> 1) Priority between applications: The fact that agents can apply >>>> priority >>>> for messages from multiple applications without knowledge of those >>>> applications seems dangerous. Let's say application A is a critical >>>> infrastructure application, and application B is not. But clients >>>> for >>>> application B might set requests to have a higher priority than do >>>> clients for application A. Further, application B could become a >>>> DoS >>>> vector for application A. One potential (and likely half-baked) way >>>> to >>>> mitigate this would be to say that nodes that are not "application >>>> aware" >>>> can only apply priority among messages for the same application. >>> SRD> This is similar to saying that priority setting across >>> applications need to be set in a consistent way. We might need to >>> define the "priority scheme" or some similar concept as sketched out >>> in my response to Alissa's DISCUSS. >> >> That would probably help. Am I correct in assuming that would require >> some WG discussion? >> It occurs to me after sleeping on it that, in congestion cases, this >> would leave things no worse than when a relay agent throttles >> requests with even less information. But it's a little more worrisome >> when used in non-congested circumstances, assuming they leave the >> possibility of throttling or otherwise rejecting requests under >> normal processing conditions. > SRD> See my proposed changes to the draft sent in a separate email. I > think this addresses the above concern and is currently waiting WG > discussion. See my comment in that thread. For the record, I think the proposal is on the right track, but may still need some tweaks. >> >>>> >>>> 2) Priority between clients of the same application: If you have >>>> multiple >>>> clients for the same application, don't they need to use the same >>>> prioritization strategy? How is this to be managed? >>> SRD> It is not directly defined. This is back to the question of >>> whether or not the mechanism is constrained to only work in a >>> trusted environment. >> >> The potential "priority scheme" might help here. But why does a >> trusted environment matter? Lets say you have trusted clients from >> vender A and from vendor B, but they select priorities differently? > SRD> They aren't trusted if they aren't using the defined standards. What standard? The application specification? (See my question in Alissa's thread about whether DRMP can be applied to legacy applications that don't (yet) define it's use.) > In addition, trusted environment generally means operated by a single > entity. That operator has the job of ensuring that what you are > proposing would not happen. I can accept if that is the case, but it's not a very satisfying answer. It leads to having profiles for each operator. (I realize that the primary users of Diameter have always had operator-specific profiles of standards, so maybe there's nothing to do here.) This might at least imply a requirement that priority definitions need to be configurable. [...] >> >>>> >>>> 4) I am nervous about the idea that clients and servers would use a >>>> generic message priority mechanism to manage the allocation of >>>> resources >>>> that result from a requests and answers. It seems like that should >>>> be >>>> based on application specific rules and information. (Now, if the >>>> point >>>> is that these same AVPs might be used in an application according >>>> to >>>> application specific rules, that might be okay--but then you might >>>> run >>>> into issues where application-agnostic agents don't know the >>>> difference.) >>> SRD> The definition of what different priority levels mean will >>> reflect the application specific knowledge. Agents just route >>> requests and with the introduction of DOIC, sometimes throttle them. >>> The agent doesn't need anything but the priority value, as long as >>> the priority values are defined consistently across all >>> applications. >> >> My concern was more about client and server behavior, but it may be >> impacted by relays. I assume that a relay agent would not be making >> decisions about resource allocation, at least beyond transactions >> state. >> >> My concern is twofold: In the case of servers, this seems to give a >> server leave to send a successful answer, but not allocate any >> necessary resources to support that success. This seems to lead to >> circumstances where the server thinks something failed but the client >> thinks it worked. (I have no problem with saying that a >> resource-constrained server might include priority as a factor in >> it's decisions about which requests to reject.) > SRD> DRMP does not change application server behavior. It just > influences the order in which requests are processed. As such, I > don't see how DRMP would cause the server to falsely send a success > response. I agree, but I thought the language in DRMP seemed to allow for it. Maybe, rather than saying that a server could use DRMP to decide whether the allocate resources for a request, it would be better to say the server could use DRMP to decide whether to process or fail a request. >> >> In the case of clients, I think we are talking about a client >> abandoning some task even though the server thinks it worked. I don't >> see that as a problem per se, but I would expect a server to do that >> based on some local knowledge of priority. It seems a stretch that it >> would do so based on a priority value inserted by the server. But >> even if that makes sense, I understand that this draft allows relay >> agents with no knowledge of the application semantics to insert, >> remove, or change priority values in answer messages. (Maybe the >> answer here is stricter guidance on when relay agents can change >> priority values, and allowing the client to ignore priority values in >> answers (especially success answers) > SRD> Clients abandoning things can happen without DRMP. It's up to > the application to define the correct behavior when this happens. > DRMP doesn't change anything on that front. As such, I don't see the > concern. I think that's fine if only application-aware nodes are involved (and the application defines how to use DRMP). My concern is that a relay agent is allowed to change the priority. So imagine a client sends a request with a high priority, and gets back a successful answer with a low priority. Section 8 says it MUST use the priority in the answer over it's local idea of what the priority was. How does it know a relay didn't change the priority in the answer. (Even if nothing changes the answer en route, is it really reasonable for the server's idea of priority to always override the client's?) >> >> >> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> General: I approached this assuming prioritization would matter >>>> only in >>>> overload scenarios. But I gather you envision using this in >>>> non-overload >>>> scenarios? (This interacts with my discuss point about the use of >>>> DRMP to >>>> prioritize resource allocation that result result from successful >>>> diameter transactions.) Use case 5.3 is a bit worrisome in this >>>> context. >>> SRD> I don't understand the concern. >> >> I'm concerned that this could effectively induce overload for lower >> priority messages, when the nodes would normally be able to handle >> all messages. In use case 5.3, does the platinum customer buy the >> right to cause other customer's requests to fail? > SRD> It is certainly possible that higher priority messages could > starve lower priority messages. The only case when this would result > in a lower priority message not getting service in non congestion > scenarios is if the lower priority message times out. This is a > recognized side effect of priority based schemes like this. An > operator offering a service like 5.3 would have to take this into > consideration. I would expect that in a well thought out priority > scheme the percentage of high priority messages will be significantly > less than low priority messages, reducing the probability of starving > the low priority messages. How this is done, however, is out side the > scope of this document. It's probably worth mentioning in the draft text that a naive approach to priority can introduce transaction failure in cases where all transactions might have succeeded without it, and that operators and implementers need to consider that. [...] >> >>>> >>>> -- "Diameter nodes MUST use the priority indicated in the DRMP AVP >>>> carried in the answer message, if it exists." >>>> The MUST seems odd, since paying attention to the priority in the >>>> initial >>>> request was only SHOULD. >>> SRD> The wording here is cumbersome. The full paragraph is as >>> follows: >>> >>> When determining the priority to apply to answer messages, >>> Diameter >>> nodes MUST use the priority indicated in the DRMP AVP carried in >>> the >>> answer message, if it exists. Otherwise, the Diameter node MUST >>> use >>> the priority indicated in the DRMP AVP of the associated request >>> message. >>> >>> This is meant to say that a Diameter node receiving an answer >>> message MUST use the priority value in the answer message when >>> processing the message. If there is no DRMP AVP in the answer >>> message then the receiving node uses the priority that was in the >>> request message. I'd be happy to re-craft this to be more clear. >> >> Part of my concern is that the MUST vs SHOULD bit is different for >> requests and answers. statements of the form "If you use the >> mechanism, you MUST do X" do not mean the same as "SHOULD do X", even >> if the reasoning behind the SHOULD is that a node might not use the >> mechanism. > SRD> There are no SHOULD statements in this paragraph. This > requirement only applies "When determining the priority to apply to > __received__ answer messages". I don't see the conflict. So this may be down to a nit--but the text as written says that the receiver of a _request_ "SHOULD" use the included priority, but the receiver of a response "MUST" use the priority. Now, maybe these are just different ways of encoding the idea that the node may not implement DRMP. But the former seems to allow the node to override the priority in the message if it has good reason, but the latter does not allow the same for a response. As I mention in the discussion about my last discuss point, it seems odd that a client cannot choose it's own idea of priority over the servers if it thinks it has a good reason. [...] From nobody Sun May 8 05:12:43 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 575F212B021; Sun, 8 May 2016 05:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 nnpY5AceBIrI; Sun, 8 May 2016 05:12:41 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FAE512B039; Sun, 8 May 2016 05:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2038; q=dns/txt; s=iport; t=1462709560; x=1463919160; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=wk2c6JqqCPhL221OcbLaQKsrqwlOdLRAMM5wN3ZOzF4=; b=BlmVmosuiajwPP0H4D0PaFQbCAUGdXMY/bCInWhHjuEdRzCIvJjs3BRq OuSTzHaCP0ymyar0PLCfOkHDY174Sj2uGhgTMpH4F7UwvSa4EAnkwqDMQ gKbJQWn8Vvymm7GoJSu9LmyQyE9vy9V4WnOHAhfIpo7xYx9ZVTfxDsbp2 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpBACyKy9X/xbLJq1evAWEE4YQAoFnA?= =?us-ascii?q?QEBAQEBZieEQgEBBDhAARALGAkWDwkDAgECAUUGDQgBAYgnvXMBAQEBAQEBAwE?= =?us-ascii?q?BAQEBARqGIIRMhCmFbwEEmCKOHIk/hViPO2KDbTqIawEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,595,1454976000"; d="scan'208";a="635533670" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2016 12:12:38 +0000 Received: from [10.61.225.121] ([10.61.225.121]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u48CCHnd020931; Sun, 8 May 2016 12:12:20 GMT To: Ben Campbell References: <20160504170252.8246.93112.idtracker@ietfa.amsl.com> <1D4B3862-3423-4618-B0ED-103B99BBC79F@nostrum.com> From: Benoit Claise Message-ID: <572F2C8F.9070300@cisco.com> Date: Sun, 8 May 2016 14:09:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1D4B3862-3423-4618-B0ED-103B99BBC79F@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] Benoit Claise's No Objection on draft-ietf-dime-drmp-05: (with COMMENT) 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, 08 May 2016 12:12:42 -0000 Ben, > I will jump in on one point, since this is related to the discussion > on whether nodes need a common approach to selecting/interpreting > priority values: > > On 4 May 2016, at 12:02, Benoit Claise wrote: > >> >> - >> >> 1. Request sender - The sender of a request, be it a Diameter Client >> or a Diameter Server, determines the relative priority of the >> request and includes that priority information in the request. >> >> Question: what is the risk of DMRP ending up as the DSCP, i.e. >> Every end point changes the value to best service, and in the end, it's >> useless, and uniquely set by the operator. > > I think there's a trusted network assumption here, which would include > an assumption that trusted clients do not intentionally game the > system. (in contrast with _accidentally_ gaming the system by using a > different scheme to set priority values.) > > However, I think that this sort of assumption should be explicitly > mentioned. I believe so. > IIRC, DOIC included some guidance about crossing trust boundaries; > perhaps DRMP should do the same. Yes. That makes me think. I wonder how the following two statements are interoperable? Diameter nodes MUST have a default priority to apply to transactions that do not have an explicit priority set in the DRMP AVP. Diameter nodes SHOULD use the PRIORITY_10 priority as this default value. Shouldn't the last SHOULD be a MUST? Let me explain: a Diameter node wants to send Diameter messages with priority above average, so PRIORITY = 12 (because his default is 10). Along the path (potentially crossing a boundary), a Diameter node doesn't support the DRMP AVP. The next node, which does, sets his default priority. The default priority on that node has been configured as 13. And now, my Diameter messages will be treated as below average. Do I miss anything? Regards, Benoit > > (And I guess that does make it a bit like DSCP ;-) ) > > Ben. > . > From nobody Tue May 10 06:26:56 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 3469712B077; Tue, 10 May 2016 06:26:55 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 MIe0rbZnpnI9; Tue, 10 May 2016 06:26:54 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 0BB7F12B00D; Tue, 10 May 2016 06:26:54 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:54683 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 1b07gX-001RTU-4j; Tue, 10 May 2016 06:26:53 -0700 To: Ben Campbell References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> <572A1C14.5020907@usdonovans.com> <74A5239A-329E-4F82-9FBF-497C9D906E89@cooperw.in> <572A4520.5090101@cs.tcd.ie> <90C95598-F68D-4F94-8AE3-FAFF403F560E@cooperw.in> <572AFD9D.7010909@cs.tcd.ie> <572B48D2.6090801@cs.tcd.ie> <154814f98f0.277f.0301301ad371d4c21d5a2092e0e442f2@usdonovans.com> <572B5B0D.9010001@cs.tcd.ie> <572CC06E.7090405@usdonovans.com> <2609D587-563B-4C0E-B769-FB8DC0A9D10F@nostrum.com> From: Steve Donovan Message-ID: <5731E198.6060408@usdonovans.com> Date: Tue, 10 May 2016 08:26:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <2609D587-563B-4C0E-B769-FB8DC0A9D10F@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-1.0 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: Cc: draft-ietf-dime-drmp@ietf.org, Alissa Cooper , dime-chairs@ietf.org, dime@ietf.org, IESG Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 10 May 2016 13:26:55 -0000 See inline. On 5/6/16 3:03 PM, Ben Campbell wrote: > I'm jumping in here because part of it also relates to some of my > DISCUSS points: > > On 6 May 2016, at 11:03, Steve Donovan wrote: > >> All, >> >> I was on jury duty yesterday so I wasn't able to fully engage. >> >> I agree that we are close to resolving issues and I will produce an >> updated draft that addresses IESG review comments, along with one >> change requested by IANA. >> >> I also need to respond to Ben's last email. >> >> My proposal, modulo Ben's comments, is to add the following to the >> draft: >> >> - Emphasizing that the mechanism only works when one of the following >> is true: >> >> - Agents only handle a single DRMP application. > > What does that mean from a standards perspective? A "relay agent" is > assumed to be application-agnostic. So in some ways, it supports all > applications. Even ones that don't exist yet. A proxy, OTOH, is > assumed to know application semantics--but I don't think that is what > we are talking about, is it? > > Or do this just mean that the operator makes sure that messages from > only one application traverse the agent? (There's risk that they will > forget that part when adding a 2nd application down the road.) (But > see next comment...) SRD> It means that the network is set up so the relay, be it an agent or a proxy, only handles a single application. > >> - All Diameter applications that support DRMP used in a Diameter >> network must have consistent and synchronized priority definitions. >> I'll add some words around what is meant by consistent and synchronized. > > Those would help, but I don't think handling a single DRMP application > necessarily removes the need for consistent priority definitions. > > As with DOIC, you may see cases where vendors and or operators wish to > apply DRMP to applications even though the specifications for that > application do not define its use. (or perhaps before the owners of > the standard for legacy applications get around to doing so.) I'm not > sure if the intent is to allow that, but if it is, then you need > consistent policies across nodes. SRD> The consistency mentioned above is across applications. A nodes adherence to standards or operator policy addresses consistency across nodes. > > If the expectation is that DRMP can only be used when documented in > the "standard" for the application, then it would be good to include > some high-level detail about what we expect to be documented. SRD> This is reasonable. Although its not going to be much more than documenting what priority to use in which situations. > >> >> - Strengthening wording indicating that this mechanism is designed to >> work in trusted environments. This includes recommending stripping >> or modifying priority settings for requests received from untrusted >> sources. The determination of what is a trusted and untrusted source >> would be out of the scope of the DRMP draft. >> >> - Adding the other updates that have been agreed to as part of this >> review cycle. >> >> This leaves as future work, should there be a need, the handling >> multiple "priority schemes" within a single network. This is a very >> hard problem and not a use case that is currently needed by existing >> users of Diameter. >> >> I'll wait for feedback, especially from the Dime working group, >> before I start updating the document. >> >> Regards, >> >> Steve >> >> On 5/5/16 9:39 AM, Stephen Farrell wrote: >>> Great. I think we're maybe at the point where pushing out a >>> revised I-D that has the fixes we now know we want would be a >>> good plan and then we can go back around the discuss holders >>> and see where we're at. >>> >>> Make sense? If not, then please continue the discussion to >>> get us there. >>> >>> Cheers, >>> S. >>> >>> On 05/05/16 15:25, Steve Donovan wrote: >>>> I'm okay with this addition. >>>> >>>> Steve >>>> >>>> >>>> On May 5, 2016 8:21:22 AM Stephen Farrell >>>> wrote: >>>> >>>>> >>>>> On 05/05/16 14:19, Alissa Cooper wrote: >>>>>> I think the gap is in Section 5, where it should be noted that in >>>>>> order for priority information to be reliably usable in the way that >>>>>> use cases 5.1 and 5.2 call for, the Diameter nodes sending and >>>>>> consuming it must have pre-established trust relationships of the >>>>>> sort described in Section 11. >>>>> Sounds reasonable to me. Authors? >>>>> >>>>> S. >>>>> >>>> From nobody Tue May 10 06:38: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 E35FD12D17C; Tue, 10 May 2016 06:38:55 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 J8vBq5vnHEBc; Tue, 10 May 2016 06:38:54 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 2AC2012D190; Tue, 10 May 2016 06:38:48 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:54773 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 1b07s4-001Zqk-Jj; Tue, 10 May 2016 06:38:47 -0700 To: Ben Campbell References: <20160504023124.8242.52368.idtracker@ietfa.amsl.com> <572A227D.1040203@usdonovans.com> <45E2E5D4-091E-4311-9FDF-271B04D59D05@nostrum.com> <572CF510.20202@usdonovans.com> <7EB67D8A-B1DE-4456-B89A-6E049A6BADE5@nostrum.com> From: Steve Donovan Message-ID: <5731E463.9070700@usdonovans.com> Date: Tue, 10 May 2016 08:38:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <7EB67D8A-B1DE-4456-B89A-6E049A6BADE5@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Cc: draft-ietf-dime-drmp@ietf.org, "dime-chairs@ietf.org" , dime@ietf.org, The IESG Subject: Re: [Dime] Ben Campbell's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 10 May 2016 13:38:56 -0000 See inline. On 5/6/16 3:45 PM, Ben Campbell wrote: > On 6 May 2016, at 14:48, Steve Donovan wrote: > > > [...] > >>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> DISCUSS: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> >>>>> I have a few concerns that I think need some discussion. >>>>> >>>>> 1) Priority between applications: The fact that agents can apply >>>>> priority >>>>> for messages from multiple applications without knowledge of those >>>>> applications seems dangerous. Let's say application A is a critical >>>>> infrastructure application, and application B is not. But clients for >>>>> application B might set requests to have a higher priority than do >>>>> clients for application A. Further, application B could become a DoS >>>>> vector for application A. One potential (and likely half-baked) >>>>> way to >>>>> mitigate this would be to say that nodes that are not "application >>>>> aware" >>>>> can only apply priority among messages for the same application. >>>> SRD> This is similar to saying that priority setting across >>>> applications need to be set in a consistent way. We might need to >>>> define the "priority scheme" or some similar concept as sketched >>>> out in my response to Alissa's DISCUSS. >>> >>> That would probably help. Am I correct in assuming that would >>> require some WG discussion? >>> It occurs to me after sleeping on it that, in congestion cases, this >>> would leave things no worse than when a relay agent throttles >>> requests with even less information. But it's a little more >>> worrisome when used in non-congested circumstances, assuming they >>> leave the possibility of throttling or otherwise rejecting requests >>> under normal processing conditions. >> SRD> See my proposed changes to the draft sent in a separate email. >> I think this addresses the above concern and is currently waiting WG >> discussion. > > See my comment in that thread. For the record, I think the proposal is > on the right track, but may still need some tweaks. > >>> >>>>> >>>>> 2) Priority between clients of the same application: If you have >>>>> multiple >>>>> clients for the same application, don't they need to use the same >>>>> prioritization strategy? How is this to be managed? >>>> SRD> It is not directly defined. This is back to the question of >>>> whether or not the mechanism is constrained to only work in a >>>> trusted environment. >>> >>> The potential "priority scheme" might help here. But why does a >>> trusted environment matter? Lets say you have trusted clients from >>> vender A and from vendor B, but they select priorities differently? >> SRD> They aren't trusted if they aren't using the defined standards. > > What standard? The application specification? (See my question in > Alissa's thread about whether DRMP can be applied to legacy > applications that don't (yet) define it's use.) SRD> I mean application specification or operator policy. DRMP can apply to legacy applications in two ways. First, the default priority applies if no priority is explicitly included in the message. Second, operators can define their own priority scheme. > >> In addition, trusted environment generally means operated by a single >> entity. That operator has the job of ensuring that what you are >> proposing would not happen. > > I can accept if that is the case, but it's not a very satisfying > answer. It leads to having profiles for each operator. (I realize that > the primary users of Diameter have always had operator-specific > profiles of standards, so maybe there's nothing to do here.) This > might at least imply a requirement that priority definitions need to > be configurable. SRD> I don't see that it means a profile per operator. 3GPP is likely to create a profile that spans all of its applications and could be used by all operators following the 3GPP standards. > > [...] > >>> >>>>> >>>>> 4) I am nervous about the idea that clients and servers would use a >>>>> generic message priority mechanism to manage the allocation of >>>>> resources >>>>> that result from a requests and answers. It seems like that should be >>>>> based on application specific rules and information. (Now, if the >>>>> point >>>>> is that these same AVPs might be used in an application according to >>>>> application specific rules, that might be okay--but then you might >>>>> run >>>>> into issues where application-agnostic agents don't know the >>>>> difference.) >>>> SRD> The definition of what different priority levels mean will >>>> reflect the application specific knowledge. Agents just route >>>> requests and with the introduction of DOIC, sometimes throttle >>>> them. The agent doesn't need anything but the priority value, as >>>> long as the priority values are defined consistently across all >>>> applications. >>> >>> My concern was more about client and server behavior, but it may be >>> impacted by relays. I assume that a relay agent would not be making >>> decisions about resource allocation, at least beyond transactions >>> state. >>> >>> My concern is twofold: In the case of servers, this seems to give a >>> server leave to send a successful answer, but not allocate any >>> necessary resources to support that success. This seems to lead to >>> circumstances where the server thinks something failed but the >>> client thinks it worked. (I have no problem with saying that a >>> resource-constrained server might include priority as a factor in >>> it's decisions about which requests to reject.) >> SRD> DRMP does not change application server behavior. It just >> influences the order in which requests are processed. As such, I >> don't see how DRMP would cause the server to falsely send a success >> response. > > I agree, but I thought the language in DRMP seemed to allow for it. > Maybe, rather than saying that a server could use DRMP to decide > whether the allocate resources for a request, it would be better to > say the server could use DRMP to decide whether to process or fail a > request. SRD> OK. > >>> >>> In the case of clients, I think we are talking about a client >>> abandoning some task even though the server thinks it worked. I >>> don't see that as a problem per se, but I would expect a server to >>> do that based on some local knowledge of priority. It seems a >>> stretch that it would do so based on a priority value inserted by >>> the server. But even if that makes sense, I understand that this >>> draft allows relay agents with no knowledge of the application >>> semantics to insert, remove, or change priority values in answer >>> messages. (Maybe the answer here is stricter guidance on when relay >>> agents can change priority values, and allowing the client to ignore >>> priority values in answers (especially success answers) >> SRD> Clients abandoning things can happen without DRMP. It's up to >> the application to define the correct behavior when this happens. >> DRMP doesn't change anything on that front. As such, I don't see the >> concern. > > I think that's fine if only application-aware nodes are involved (and > the application defines how to use DRMP). My concern is that a relay > agent is allowed to change the priority. So imagine a client sends a > request with a high priority, and gets back a successful answer with a > low priority. Section 8 says it MUST use the priority in the answer > over it's local idea of what the priority was. How does it know a > relay didn't change the priority in the answer. > > (Even if nothing changes the answer en route, is it really reasonable > for the server's idea of priority to always override the client's?) SRD> I don't see the negative impact of having the transaction priority changed by either the server or the agent. If it truly breaks something then we could go back to having priority applying to a transaction but I don't see what breaks. >>> >>> >>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> COMMENT: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> >>>>> General: I approached this assuming prioritization would matter >>>>> only in >>>>> overload scenarios. But I gather you envision using this in >>>>> non-overload >>>>> scenarios? (This interacts with my discuss point about the use of >>>>> DRMP to >>>>> prioritize resource allocation that result result from successful >>>>> diameter transactions.) Use case 5.3 is a bit worrisome in this >>>>> context. >>>> SRD> I don't understand the concern. >>> >>> I'm concerned that this could effectively induce overload for lower >>> priority messages, when the nodes would normally be able to handle >>> all messages. In use case 5.3, does the platinum customer buy the >>> right to cause other customer's requests to fail? >> SRD> It is certainly possible that higher priority messages could >> starve lower priority messages. The only case when this would result >> in a lower priority message not getting service in non congestion >> scenarios is if the lower priority message times out. This is a >> recognized side effect of priority based schemes like this. An >> operator offering a service like 5.3 would have to take this into >> consideration. I would expect that in a well thought out priority >> scheme the percentage of high priority messages will be significantly >> less than low priority messages, reducing the probability of starving >> the low priority messages. How this is done, however, is out side the >> scope of this document. > > It's probably worth mentioning in the draft text that a naive approach > to priority can introduce transaction failure in cases where all > transactions might have succeeded without it, and that operators and > implementers need to consider that. SRD> OK > > [...] > >>> >>>>> >>>>> -- "Diameter nodes MUST use the priority indicated in the DRMP AVP >>>>> carried in the answer message, if it exists." >>>>> The MUST seems odd, since paying attention to the priority in the >>>>> initial >>>>> request was only SHOULD. >>>> SRD> The wording here is cumbersome. The full paragraph is as >>>> follows: >>>> >>>> When determining the priority to apply to answer messages, Diameter >>>> nodes MUST use the priority indicated in the DRMP AVP carried in >>>> the >>>> answer message, if it exists. Otherwise, the Diameter node MUST >>>> use >>>> the priority indicated in the DRMP AVP of the associated request >>>> message. >>>> >>>> This is meant to say that a Diameter node receiving an answer >>>> message MUST use the priority value in the answer message when >>>> processing the message. If there is no DRMP AVP in the answer >>>> message then the receiving node uses the priority that was in the >>>> request message. I'd be happy to re-craft this to be more clear. >>> >>> Part of my concern is that the MUST vs SHOULD bit is different for >>> requests and answers. statements of the form "If you use the >>> mechanism, you MUST do X" do not mean the same as "SHOULD do X", >>> even if the reasoning behind the SHOULD is that a node might not use >>> the mechanism. >> SRD> There are no SHOULD statements in this paragraph. This >> requirement only applies "When determining the priority to apply to >> __received__ answer messages". I don't see the conflict. > > So this may be down to a nit--but the text as written says that the > receiver of a _request_ "SHOULD" use the included priority, but the > receiver of a response "MUST" use the priority. Now, maybe these are > just different ways of encoding the idea that the node may not > implement DRMP. But the former seems to allow the node to override the > priority in the message if it has good reason, but the latter does not > allow the same for a response. > > As I mention in the discussion about my last discuss point, it seems > odd that a client cannot choose it's own idea of priority over the > servers if it thinks it has a good reason. SRD> Thanks for bearing with me on this one. I see your point now and agree it should be reworded to include allowing for local policy to override what is carried in the message. > > [...] From nobody Tue May 10 07:08:04 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 218EA12D09F; Tue, 10 May 2016 07:08:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160510140801.538.20501.idtracker@ietfa.amsl.com> Date: Tue, 10 May 2016 07:08:01 -0700 Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org Subject: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 10 May 2016 14:08:01 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dime-drmp-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I fully agree with all discuss comments made by Ben and Alissa. However, the summary here might be that this information might simply be not very useful for the uses cases described. And there might be other mechanisms that do not require any trust and that can address the uses cases easier and more appropriate such a simply prioritization of a certain application in the request handler/request agent or relative priorities within one application (on sent-out). However, the one part that does actually concern me is: "When using DRMP priority information, Diameter nodes MUST use the default priority for transactions that do not have priority specified in a DRMP AVP." This part could lead to starvation of requests that do not define a priority, e.g. because there are not supporting it (yet). However these starved requests could effectively have a higher priortiy than the request that they get starved by. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Why do you need 15 different priority levels? Wouldn't be two enough for all or your use cases? From nobody Tue May 10 07:53:25 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 970A412D0E3 for ; Tue, 10 May 2016 07:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 mF5E2sa5KxRW for ; Tue, 10 May 2016 07:53:23 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5A512B008 for ; Tue, 10 May 2016 07:53:22 -0700 (PDT) Received: (qmail 24456 invoked from network); 10 May 2016 16:46:39 +0200 Received: from 70-91-193-41-busname-newengland.hfc.comcastbusiness.net (HELO ?192.168.15.199?) (70.91.193.41) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 10 May 2016 16:46:39 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> Date: Tue, 10 May 2016 10:46:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> To: Alexey Melnikov , "Gunn, Janet P" , srdonovan@usdonovans.com X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 10 May 2016 14:53:24 -0000 Hi all, sorry for my late reply. I think the part with the two queues was a little confusing. Sorry for = that as well. I originally meant to describe this to illustrate the = problem rather than describing a solution. However, using two queues = (which fully is an implementation detail) does not even match the = problem correctly that I wanted to describe=E2=80=A6 the actually point = would be about the scheduling that one would need to implement to serve = the queues. Here my thinking was that, instead of implementing a strict = priority scheduling, you could also implement a scheme that guarantees a = certain minimum serving rate for the non-priority-defined requests to = avoid full starvation. However, I don=E2=80=99t want to confuse you even = more here. So let me try to phase my concern again (I=E2=80=99ve also = edited my discuss text): I don=E2=80=99t think it is a good idea to assign a default priority to = non-priority-defined requests at all. If you have high priority traffic = that does not support this extension (yet) this traffic could be starved = by lower priority traffic when assigning a middle range priority. I = don=E2=80=99t think that is what you want to achieve. I think this point is even more true with respect to the discussion that = went on with Alissa and Ben. There, you said, you=E2=80=99d need to = define a priority scheme for a certain application before you could use = it. Given that it does not make sense to define a default priority value = to for all uses because depending of with priority range you select to = use in your scheme, the default might be a low, high, or midrange value. To make it even more clear I would like to propose the following text = change in the doc: OLD: Diameter nodes MUST have a default priority to apply to transactions that do not have an explicit priority set in the DRMP AVP. Diameter nodes SHOULD use the PRIORITY_10 priority as this default value. NEW: Diameter nodes MAY set a default priority to apply to transactions that do not have an explicit priority set in the DRMP AVP if it is known that the transactions that define a higher priority than the = default are always higher priority than the transactions that do not define=20= a priority explicitly. The default value will depend on the used = priority=20 range in a given deployment setup.=20 Diameter node SHOULD not assign a default priority if no additional information about the transaction that do not define an explicit priority is known. In this case the diameter node SHOULD provide a minimum serving rate for transaction = that do not define an explicit priority to avoid full starvation of these transactions the may or may not have a higher priority than other=20 transactions that provide information about their priority. I hope that makes sense to you. Please propose edits (if not)! Mirja=20 =20 > Am 05.05.2016 um 08:32 schrieb Alexey Melnikov = : >=20 > Hi Mirja, >=20 > On Wed, May 4, 2016, at 04:50 PM, Mirja Kuehlewind (IETF) wrote: >> Hi Janet, >>=20 >> there are clearly more options than the two mention below. >>=20 >> E.g. one option is the one explained in my initial comment: hhaving = two >> queues, that are both served with a certain rate. >>=20 >> I=E2=80=99m sure there are more (and potentially more complex) = solutions to this >> problem as well. >>=20 >> Assigning an arbitrary priority is not the right option from my point = of >> view and can actually hurt the systems. >=20 > I hope this will help to clarify things: >=20 > One point of assigning default priority is that as this is an = extension, > there is a desire to avoid upgrading all clients on the network, as = that > would be effectively trying to deploy a new protocol. Consider a = network > where proxies and servers understand this extension and none of the > clients do. Then default priority would be assigned to all traffic and > the behaviour of the system is unchanged from the case when the > extension is not deployed. The default priority only makes a = difference > if there is a mixture of clients implementing this extension and = clients > that don't. >=20 > Best Regards, > Alexey >=20 >> Mirja >>=20 >>=20 >>> Am 04.05.2016 um 17:45 schrieb Gunn, Janet P : >>>=20 >>> My comment below. >>> Janet >>>=20 >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Mirja = Kuehlewind (IETF) >>> Sent: Wednesday, May 04, 2016 10:31 AM >>> To: Alexey Melnikov >>> Cc: draft-ietf-dime-drmp@ietf.org; dime-chairs@ietf.org; = dime@ietf.org; The IESG >>> Subject: Re: [Dime] Mirja K=C3=BChlewind's Discuss on = draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) >>>=20 >>> Hi Alexey, >>>=20 >>> see below. >>>=20 >>> The point is, if you explicitly indicate that you have a lower = priority, you are okay to be starved. However, if you don=E2=80=99t = indicate anything (maybe just because you have not been aware that it is = possible to do so), you might have the same or even a higher priority, = and in this case it=E2=80=99s not okay to be starved. >>>=20 >>> Mirja >>> If a message comes in without a priority, into a system which = serves messages based on priority (regardless of the specific = mechanisms)you have two options >>> 1- Discard the message (Not a good idea in most systems) >>> 2 - Assign the message an ARBITRARY priority (we call this arbitrary = value the "default priority") >>>=20 >>> You can (and probably will) argue 'til the cows come home on what = that arbitrary/default value SHOULD BE. And different = sytems/applications might have different "default values". >>>=20 >>> But I don't think there should be any argument that, if a message = comes in without a priority, you need to assign it a priority. >>>=20 >>> >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>> This electronic message transmission contains information from CSRA = that may be attorney-client privileged, proprietary or confidential. The = information 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 agreement or government initiative = expressly permitting the use of email for such purpose. >>=20 >=20 From nobody Tue May 10 09:10: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 D085612D515; Tue, 10 May 2016 09:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=g11.org.uk 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 Ni-3bubhgKWP; Tue, 10 May 2016 09:10:20 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) (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 8CCA812D513; Tue, 10 May 2016 09:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject: Mime-Version:Content-Type:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=0ZOgFqnQ33sS435XUGMu5ui3jn2CjThSBOHcgpFub6Q=; b=OWOfCU/BB3FyMbK7/ZyEB6p/Qa i3KeCLrttEOIJuL5gVWh2U2EwH534bm5vcx92JMrZR9HUOviBldVIM8MeKyfHQHiQ3USm7eXzcqFi Ypb+vK5RuzqAS8/xEDxk1POTMd2jzAgHFSlgZ7hH40nbXJpC02xpXu2xV+r+8mm9OWQA=; Received: from [166.170.30.214] (port=51696 helo=[172.20.10.2]) by portland.eukhosting.net with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1b0AEc-002PPy-GY; Tue, 10 May 2016 17:10:15 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_004FBBB6-49DF-4723-B787-4E4A0B84033B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: ken carlberg In-Reply-To: <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> Date: Tue, 10 May 2016 12:10:08 -0400 Message-Id: <0AAC49EE-FEB8-4D94-996E-0FA4015E8C35@g11.org.uk> References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Get-Message-Sender-Via: portland.eukhosting.net: authenticated_id: carlberg@g11.org.uk X-Authenticated-Sender: portland.eukhosting.net: carlberg@g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, Alexey Melnikov , dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 10 May 2016 16:10:24 -0000 --Apple-Mail=_004FBBB6-49DF-4723-B787-4E4A0B84033B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mirja, > On May 10, 2016, at 10:46 AM, Mirja Kuehlewind (IETF) = wrote: >=20 >=20 > I don=E2=80=99t think it is a good idea to assign a default priority = to non-priority-defined requests at all. If you have high priority = traffic that does not support this extension (yet) this traffic could be = starved by lower priority traffic when assigning a middle range = priority. I don=E2=80=99t think that is what you want to achieve. I think your concern is quite valid, and my apologies if I missed = something in the thread, but I think one thing that hasn=E2=80=99t been = brought up is the notion of local policy and its separation from labels = or priority values. A number of years ago, the IETF community had some = significant back and forth on the topic in the context of Emergency = Telecommunications Service. Specifically, in RFC-3689 we stated the = following: 3) Policy Policy MUST be kept separate from label(s). This topic has generated a fair amount of debate, and so we provide additional guidance from the following: A set of labels may be defined as being related to each other. Characteristics (e.g., drop precedence) may also be attributed to these labels. [11] is an example of a related set of labels based on a specific characteristic. However, the mechanisms used to achieve a stated characteristic MUST NOT be stated in the definition of a label. Local policy determines mechanism(s) used to achieve or support a specific characteristic. This allows for the possibility of different mechanisms to achieve the same stated characteristic. The interaction between unrelated labels MUST NOT be embedded within the definition of a label. Local policy states the actions (if any) to be taken if unrelated labeled traffic merges at a node. Finally, labels may have additional characteristics added to them as a result of local policy. Hence, the local policy associated with priority(s) *may* state that a = weighted round robin in the servicing of queues *must* be used to ensure = that no queue is ever starved. Or, a more draconian position could be = taken that does allow starvation. It would be up to the = operator/manager of the service to decide on the what is the local = policy. This is the way its been implemented and deployed in a few = systems that I=E2=80=99m aware of that support prioritization. -ken (qualifier: just expressing my own personal opinion. YMMV, consult = doctor before use :-) --Apple-Mail=_004FBBB6-49DF-4723-B787-4E4A0B84033B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Mirja,

On May = 10, 2016, at 10:46 AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>= wrote:


I don=E2=80=99t = think it is a good idea to assign a default priority to = non-priority-defined requests at all. If you have high priority traffic = that does not support this extension (yet) this traffic could be = starved by lower priority traffic when assigning a middle range = priority. I don=E2=80=99t think that is what you want to achieve.

I think = your concern is quite valid, and my apologies if I missed something in = the thread, but I think one thing that hasn=E2=80=99t been brought up is = the notion of local policy and its separation from labels or priority = values.  A number of years ago, the IETF community had some = significant back and forth on the topic in the context of Emergency = Telecommunications Service.  Specifically, in RFC-3689 we stated = the following:

   3) Policy

      Policy MUST be kept separate from = label(s).  This topic has
      generated a fair amount of debate, and = so we provide additional
 =     guidance from the following:

      A set of labels may be defined as being = related to each other.
  =     Characteristics (e.g., drop precedence) may also be = attributed to
    =   these labels.  [11] is an example of a related set of labels = based
      on = a specific characteristic.

    =   However, the mechanisms used to achieve a stated = characteristic
    =   MUST NOT be stated in the definition of a label.  Local = policy
      = determines mechanism(s) used to achieve or support a = specific
      = characteristic.  This allows for the possibility of = different
    =   mechanisms to achieve the same stated = characteristic.

    =   The interaction between unrelated labels MUST NOT be = embedded
      = within the definition of a label.  Local policy states the = actions
      = (if any) to be taken if unrelated labeled traffic merges at = a
      = node.

    =   Finally, labels may have additional characteristics added to = them
      as = a result of local policy.

Hence, the local policy associated with = priority(s) *may* state that a weighted round robin in the servicing of = queues *must* be used to ensure that no queue is ever starved.  Or, = a more draconian position could be taken that does allow starvation. =  It would be up to the operator/manager of the service to decide on = the what is the local policy.  This is the way its been implemented = and deployed in a few systems that I=E2=80=99m aware of that support = prioritization.

-ken

(qualifier: just expressing my own personal opinion. =  YMMV, consult doctor before use :-)

= --Apple-Mail=_004FBBB6-49DF-4723-B787-4E4A0B84033B-- From nobody Tue May 10 09:49:54 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 EA57812D0CD; Tue, 10 May 2016 09:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 vEV4pbgVfXsQ; Tue, 10 May 2016 09:49:45 -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 1810012D76F; Tue, 10 May 2016 09:49:29 -0700 (PDT) Received: from [10.10.1.3] ([162.216.46.125]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u4AGnQL9086563 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 10 May 2016 11:49:28 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [162.216.46.125] claimed to be [10.10.1.3] From: "Ben Campbell" To: "Steve Donovan" Date: Tue, 10 May 2016 12:49:26 -0400 Message-ID: <9F7709AD-2BFF-4D1A-9734-251318B90F82@nostrum.com> In-Reply-To: <5731E463.9070700@usdonovans.com> References: <20160504023124.8242.52368.idtracker@ietfa.amsl.com> <572A227D.1040203@usdonovans.com> <45E2E5D4-091E-4311-9FDF-271B04D59D05@nostrum.com> <572CF510.20202@usdonovans.com> <7EB67D8A-B1DE-4456-B89A-6E049A6BADE5@nostrum.com> <5731E463.9070700@usdonovans.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, "dime-chairs@ietf.org" , dime@ietf.org, The IESG Subject: Re: [Dime] Ben Campbell's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 10 May 2016 16:49:48 -0000 I'm going to clear the discuss at this point--I wanted discussion to happen and it is happening. More inline: On 10 May 2016, at 9:38, Steve Donovan wrote: > See inline. > > On 5/6/16 3:45 PM, Ben Campbell wrote: >> On 6 May 2016, at 14:48, Steve Donovan wrote: >> >> [...] >>>> >>>> The potential "priority scheme" might help here. But why does a >>>> trusted environment matter? Lets say you have trusted clients from >>>> vender A and from vendor B, but they select priorities differently? >>> SRD> They aren't trusted if they aren't using the defined standards. >> >> What standard? The application specification? (See my question in >> Alissa's thread about whether DRMP can be applied to legacy >> applications that don't (yet) define it's use.) > SRD> I mean application specification or operator policy. DRMP can > apply to legacy applications in two ways. First, the default priority > applies if no priority is explicitly included in the message. Second, > operators can define their own priority scheme. Okay. That seems to imply a need for configurability, but I'll leave it to you whether that should be a standard requirement, or a market requirement. >> >>> In addition, trusted environment generally means operated by a >>> single entity. That operator has the job of ensuring that what you >>> are proposing would not happen. >> >> I can accept if that is the case, but it's not a very satisfying >> answer. It leads to having profiles for each operator. (I realize >> that the primary users of Diameter have always had operator-specific >> profiles of standards, so maybe there's nothing to do here.) This >> might at least imply a requirement that priority definitions need to >> be configurable. > SRD> I don't see that it means a profile per operator. 3GPP is likely > to create a profile that spans all of its applications and could be > used by all operators following the 3GPP standards. Sure, but it still _might_ require per-operator profiles, right? Even 3GPP networks tend to have operator specific "flavors" of protocols. But I recognize this is not unusual for most (if not all) of the environments that Diameter is used in. [...] >> So this may be down to a nit--but the text as written says that the >> receiver of a _request_ "SHOULD" use the included priority, but the >> receiver of a response "MUST" use the priority. Now, maybe these are >> just different ways of encoding the idea that the node may not >> implement DRMP. But the former seems to allow the node to override >> the priority in the message if it has good reason, but the latter >> does not allow the same for a response. >> >> As I mention in the discussion about my last discuss point, it seems >> odd that a client cannot choose it's own idea of priority over the >> servers if it thinks it has a good reason. > SRD> Thanks for bearing with me on this one. I see your point now and > agree it should be reworded to include allowing for local policy to > override what is carried in the message. >> Thanks--I realize my first round of comments obscured the point a bit :-) From nobody Tue May 10 09:53:29 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 D0B5112D52E; Tue, 10 May 2016 09:53:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160510165327.547.89600.idtracker@ietfa.amsl.com> Date: Tue, 10 May 2016 09:53:27 -0700 Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org Subject: [Dime] Ben Campbell's No Objection on draft-ietf-dime-drmp-05: (with COMMENT) 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, 10 May 2016 16:53:28 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dime-drmp-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for engaging on my previous DISCUSS points and comments. From nobody Tue May 10 14:04:55 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 282A812D5D6; Tue, 10 May 2016 14:04:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 5oeahm4NWnqS; Tue, 10 May 2016 14:04:47 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 2903912D0B4; Tue, 10 May 2016 14:04:47 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:60912 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 1b0Epd-002txy-P9; Tue, 10 May 2016 14:04:45 -0700 To: "Mirja Kuehlewind (IETF)" , Alexey Melnikov , "Gunn, Janet P" References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> From: Steve Donovan Message-ID: <57324CE8.6040109@usdonovans.com> Date: Tue, 10 May 2016 16:04:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-1.0 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: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 10 May 2016 21:04:49 -0000 Mirja, Please see my comments inline. Regards, Steve On 5/10/16 9:46 AM, Mirja Kuehlewind (IETF) wrote: > Hi all, > > sorry for my late reply. > > I think the part with the two queues was a little confusing. Sorry for that as well. I originally meant to describe this to illustrate the problem rather than describing a solution. However, using two queues (which fully is an implementation detail) does not even match the problem correctly that I wanted to describe… the actually point would be about the scheduling that one would need to implement to serve the queues. Here my thinking was that, instead of implementing a strict priority scheduling, you could also implement a scheme that guarantees a certain minimum serving rate for the non-priority-defined requests to avoid full starvation. However, I don’t want to confuse you even more here. So let me try to phase my concern again (I’ve also edited my discuss text): > > I don’t think it is a good idea to assign a default priority to non-priority-defined requests at all. If you have high priority traffic that does not support this extension (yet) this traffic could be starved by lower priority traffic when assigning a middle range priority. I don’t think that is what you want to achieve. SRD> Actually, this is what we want to achieve. It is an requirement that messages explicitly marked as high priority get treated even if it results in starving lower priority messages. The starving of lower priority messages is not an problem, it is a requirement. > > I think this point is even more true with respect to the discussion that went on with Alissa and Ben. There, you said, you’d need to define a priority scheme for a certain application before you could use it. Given that it does not make sense to define a default priority value to for all uses because depending of with priority range you select to use in your scheme, the default might be a low, high, or midrange value. SRD> I don't understand the statement that it doesn't makes sense to define a default priority value. When defining a priority scheme/profile to be used within a Diameter network, all applications will need to take the "universal" default value into consideration. That default value will then be used in the handling of requests where either the application does not yet have a defined priority scheme or when the node originating the messages does not yet support the applications priority scheme. > > To make it even more clear I would like to propose the following text change in the doc: > > OLD: > Diameter nodes MUST have a default priority to apply to transactions > that do not have an explicit priority set in the DRMP AVP. > > Diameter nodes SHOULD use the PRIORITY_10 priority as this default > value. > > NEW: > Diameter nodes MAY set a default priority to apply to transactions > that do not have an explicit priority set in the DRMP AVP if it is > known that the transactions that define a higher priority than the default > are always higher priority than the transactions that do not define > a priority explicitly. The default value will depend on the used priority > range in a given deployment setup. SRD> One of the goals of the default priority value is to keep nodes like Diameter relays from needing to understand application semantics. This requirement would break those Diameter relays as application level knowledge is required to know if a message without an explicit priority value is of a higher priority. SRD> In addition, there is only one priority range, as defined in the document. It is important that the range be the same across all applications for the mechanism to work, especially in nodes handling messages for multiple applications. > > Diameter node SHOULD not assign > a default priority if no additional information about the transaction > that do not define an explicit priority is known. In this case the > diameter node SHOULD provide a minimum serving rate for transaction that do > not define an explicit priority to avoid full starvation of these > transactions the may or may not have a higher priority than other > transactions that provide information about their priority. SRD> This is explicitly NOT a requirement. It is acceptable to starve lower priority messages. > > I hope that makes sense to you. Please propose edits (if not)! SRD> I don't yet see a reason to change the original wording. > > Mirja > > >> Am 05.05.2016 um 08:32 schrieb Alexey Melnikov : >> >> Hi Mirja, >> >> On Wed, May 4, 2016, at 04:50 PM, Mirja Kuehlewind (IETF) wrote: >>> Hi Janet, >>> >>> there are clearly more options than the two mention below. >>> >>> E.g. one option is the one explained in my initial comment: hhaving two >>> queues, that are both served with a certain rate. >>> >>> I’m sure there are more (and potentially more complex) solutions to this >>> problem as well. >>> >>> Assigning an arbitrary priority is not the right option from my point of >>> view and can actually hurt the systems. >> I hope this will help to clarify things: >> >> One point of assigning default priority is that as this is an extension, >> there is a desire to avoid upgrading all clients on the network, as that >> would be effectively trying to deploy a new protocol. Consider a network >> where proxies and servers understand this extension and none of the >> clients do. Then default priority would be assigned to all traffic and >> the behaviour of the system is unchanged from the case when the >> extension is not deployed. The default priority only makes a difference >> if there is a mixture of clients implementing this extension and clients >> that don't. >> >> Best Regards, >> Alexey >> >>> Mirja >>> >>> >>>> Am 04.05.2016 um 17:45 schrieb Gunn, Janet P : >>>> >>>> My comment below. >>>> Janet >>>> >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Mirja Kuehlewind (IETF) >>>> Sent: Wednesday, May 04, 2016 10:31 AM >>>> To: Alexey Melnikov >>>> Cc: draft-ietf-dime-drmp@ietf.org; dime-chairs@ietf.org; dime@ietf.org; The IESG >>>> Subject: Re: [Dime] Mirja Kühlewind's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) >>>> >>>> Hi Alexey, >>>> >>>> see below. >>>> >>>> The point is, if you explicitly indicate that you have a lower priority, you are okay to be starved. However, if you don’t indicate anything (maybe just because you have not been aware that it is possible to do so), you might have the same or even a higher priority, and in this case it’s not okay to be starved. >>>> >>>> Mirja >>>> If a message comes in without a priority, into a system which serves messages based on priority (regardless of the specific mechanisms)you have two options >>>> 1- Discard the message (Not a good idea in most systems) >>>> 2 - Assign the message an ARBITRARY priority (we call this arbitrary value the "default priority") >>>> >>>> You can (and probably will) argue 'til the cows come home on what that arbitrary/default value SHOULD BE. And different sytems/applications might have different "default values". >>>> >>>> But I don't think there should be any argument that, if a message comes in without a priority, you need to assign it a priority. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>>> This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information 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 agreement or government initiative expressly permitting the use of email for such purpose. From nobody Tue May 10 14:09:51 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 D0AA412D1DA; Tue, 10 May 2016 14:09:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 o_8kO3y_-AHq; Tue, 10 May 2016 14:09:43 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 722D612D154; Tue, 10 May 2016 14:09:43 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:60920 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 1b0EuT-002xX9-Vy; Tue, 10 May 2016 14:09:43 -0700 To: Ben Campbell References: <20160504023124.8242.52368.idtracker@ietfa.amsl.com> <572A227D.1040203@usdonovans.com> <45E2E5D4-091E-4311-9FDF-271B04D59D05@nostrum.com> <572CF510.20202@usdonovans.com> <7EB67D8A-B1DE-4456-B89A-6E049A6BADE5@nostrum.com> <5731E463.9070700@usdonovans.com> <9F7709AD-2BFF-4D1A-9734-251318B90F82@nostrum.com> From: Steve Donovan Message-ID: <57324E15.5000704@usdonovans.com> Date: Tue, 10 May 2016 16:09:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <9F7709AD-2BFF-4D1A-9734-251318B90F82@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-1.0 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: Cc: draft-ietf-dime-drmp@ietf.org, "dime-chairs@ietf.org" , dime@ietf.org, The IESG Subject: Re: [Dime] Ben Campbell's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) 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, 10 May 2016 21:09:45 -0000 Comments inline... Steve On 5/10/16 11:49 AM, Ben Campbell wrote: > I'm going to clear the discuss at this point--I wanted discussion to > happen and it is happening. More inline: > > On 10 May 2016, at 9:38, Steve Donovan wrote: > >> See inline. >> >> On 5/6/16 3:45 PM, Ben Campbell wrote: >>> On 6 May 2016, at 14:48, Steve Donovan wrote: >>> >>> > > [...] > >>>>> >>>>> The potential "priority scheme" might help here. But why does a >>>>> trusted environment matter? Lets say you have trusted clients from >>>>> vender A and from vendor B, but they select priorities differently? >>>> SRD> They aren't trusted if they aren't using the defined standards. >>> >>> What standard? The application specification? (See my question in >>> Alissa's thread about whether DRMP can be applied to legacy >>> applications that don't (yet) define it's use.) >> SRD> I mean application specification or operator policy. DRMP can >> apply to legacy applications in two ways. First, the default >> priority applies if no priority is explicitly included in the >> message. Second, operators can define their own priority scheme. > > Okay. That seems to imply a need for configurability, but I'll leave > it to you whether that should be a standard requirement, or a market > requirement. SRD> I don't see the need to make configurability a standards level requirement. > >>> >>>> In addition, trusted environment generally means operated by a >>>> single entity. That operator has the job of ensuring that what you >>>> are proposing would not happen. >>> >>> I can accept if that is the case, but it's not a very satisfying >>> answer. It leads to having profiles for each operator. (I realize >>> that the primary users of Diameter have always had operator-specific >>> profiles of standards, so maybe there's nothing to do here.) This >>> might at least imply a requirement that priority definitions need to >>> be configurable. >> SRD> I don't see that it means a profile per operator. 3GPP is >> likely to create a profile that spans all of its applications and >> could be used by all operators following the 3GPP standards. > > Sure, but it still _might_ require per-operator profiles, right? Even > 3GPP networks tend to have operator specific "flavors" of protocols. SRD> Per operator profiles can exist. This mechanism certainly doesn't mandate them. > > But I recognize this is not unusual for most (if not all) of the > environments that Diameter is used in. > > [...] > >>> So this may be down to a nit--but the text as written says that the >>> receiver of a _request_ "SHOULD" use the included priority, but the >>> receiver of a response "MUST" use the priority. Now, maybe these are >>> just different ways of encoding the idea that the node may not >>> implement DRMP. But the former seems to allow the node to override >>> the priority in the message if it has good reason, but the latter >>> does not allow the same for a response. >>> >>> As I mention in the discussion about my last discuss point, it seems >>> odd that a client cannot choose it's own idea of priority over the >>> servers if it thinks it has a good reason. >> SRD> Thanks for bearing with me on this one. I see your point now >> and agree it should be reworded to include allowing for local policy >> to override what is carried in the message. >>> > Thanks--I realize my first round of comments obscured the point a bit :-) From nobody Tue May 10 14:16:24 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 1D21B12D618; Tue, 10 May 2016 14:16:22 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 bVWM2aTP4ckl; Tue, 10 May 2016 14:16:21 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 0A0BA12D5FF; Tue, 10 May 2016 14:16:21 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:60936 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 1b0F0t-0032f2-51; Tue, 10 May 2016 14:16:20 -0700 To: Benoit Claise , Ben Campbell References: <20160504170252.8246.93112.idtracker@ietfa.amsl.com> <1D4B3862-3423-4618-B0ED-103B99BBC79F@nostrum.com> <572F2C8F.9070300@cisco.com> From: Steve Donovan Message-ID: <57324FA2.3030607@usdonovans.com> Date: Tue, 10 May 2016 16:16:18 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <572F2C8F.9070300@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-1.0 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: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] Benoit Claise's No Objection on draft-ietf-dime-drmp-05: (with COMMENT) 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, 10 May 2016 21:16:22 -0000 Benoit, Please see my comments inline. Regards, Steve On 5/8/16 7:09 AM, Benoit Claise wrote: > Ben, >> I will jump in on one point, since this is related to the discussion >> on whether nodes need a common approach to selecting/interpreting >> priority values: >> >> On 4 May 2016, at 12:02, Benoit Claise wrote: >> >>> >>> - >>> >>> 1. Request sender - The sender of a request, be it a Diameter Client >>> or a Diameter Server, determines the relative priority of the >>> request and includes that priority information in the request. >>> >>> Question: what is the risk of DMRP ending up as the DSCP, i.e. >>> Every end point changes the value to best service, and in the end, it's >>> useless, and uniquely set by the operator. >> >> I think there's a trusted network assumption here, which would >> include an assumption that trusted clients do not intentionally game >> the system. (in contrast with _accidentally_ gaming the system by >> using a different scheme to set priority values.) >> >> However, I think that this sort of assumption should be explicitly >> mentioned. > I believe so. >> IIRC, DOIC included some guidance about crossing trust boundaries; >> perhaps DRMP should do the same. > Yes. > That makes me think. I wonder how the following two statements are > interoperable? > > Diameter nodes MUST have a default priority to apply to transactions > that do not have an explicit priority set in the DRMP AVP. > > Diameter nodes SHOULD use the PRIORITY_10 priority as this default > value. > > > Shouldn't the last SHOULD be a MUST? SRD> The reason it is a SHOULD is to allow for an operator to define a priority scheme with a different value, much as you outline below. > > Let me explain: a Diameter node wants to send Diameter messages with > priority above average, so PRIORITY = 12 (because his default is 10). > Along the path (potentially crossing a boundary), a Diameter node > doesn't support the DRMP AVP. The next node, which does, sets his > default priority. The default priority on that node has been > configured as 13. And now, my Diameter messages will be treated as > below average. > Do I miss anything? SRD> Yes, as described, this would be an issue. This is one of the reasons that the DISCUSS threads have focused on the need to emphasize that this mechanism only works if a consistent priority scheme is applied to all messages and that it only works within a trusted environment. This implies that priority values received from other Diameter networks likely can't be trusted. SRD> It may be necessary to add a requirement that the priority value MUST be the same for all nodes within the Diameter network using a defined priority scheme. > > Regards, Benoit > >> >> (And I guess that does make it a bit like DSCP ;-) ) >> >> Ben. >> . >> > From nobody Tue May 10 15:01: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 64BB812D15C for ; Tue, 10 May 2016 15:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 Yyj9zliVa9Ql for ; Tue, 10 May 2016 15:00:59 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4A912D0BC for ; Tue, 10 May 2016 15:00:58 -0700 (PDT) Received: (qmail 12097 invoked from network); 11 May 2016 00:00:54 +0200 Received: from softdnserror (HELO ?10.189.73.149?) (192.54.222.20) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 11 May 2016 00:00:21 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <57324CE8.6040109@usdonovans.com> Date: Tue, 10 May 2016 17:59:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net> References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> <57324CE8.6040109@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, Alexey Melnikov , dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 10 May 2016 22:01:01 -0000 See below. > Am 10.05.2016 um 17:04 schrieb Steve Donovan = : >=20 > Mirja, >=20 > Please see my comments inline. >=20 > Regards, >=20 > Steve >=20 > On 5/10/16 9:46 AM, Mirja Kuehlewind (IETF) wrote: >> Hi all, >>=20 >> sorry for my late reply. >>=20 >> I think the part with the two queues was a little confusing. Sorry = for that as well. I originally meant to describe this to illustrate the = problem rather than describing a solution. However, using two queues = (which fully is an implementation detail) does not even match the = problem correctly that I wanted to describe=E2=80=A6 the actually point = would be about the scheduling that one would need to implement to serve = the queues. Here my thinking was that, instead of implementing a strict = priority scheduling, you could also implement a scheme that guarantees a = certain minimum serving rate for the non-priority-defined requests to = avoid full starvation. However, I don=E2=80=99t want to confuse you even = more here. So let me try to phase my concern again (I=E2=80=99ve also = edited my discuss text): >>=20 >> I don=E2=80=99t think it is a good idea to assign a default priority = to non-priority-defined requests at all. If you have high priority = traffic that does not support this extension (yet) this traffic could be = starved by lower priority traffic when assigning a middle range = priority. I don=E2=80=99t think that is what you want to achieve. > SRD> Actually, this is what we want to achieve. It is an requirement = that messages explicitly marked as high priority get treated even if it = results in starving lower priority messages. The starving of lower = priority messages is not an problem, it is a requirement. I think we are still talking past each other. If you explicitly assign a = priority, starvation might be okay. However, if you don=E2=80=99t have a = priority explicitly signaled, the transaction might have a very high = priority but you just don=E2=80=99t know and by assigning a random = mid-range priority this important request could get starved. Mirja >>=20 >> I think this point is even more true with respect to the discussion = that went on with Alissa and Ben. There, you said, you=E2=80=99d need to = define a priority scheme for a certain application before you could use = it. Given that it does not make sense to define a default priority value = to for all uses because depending of with priority range you select to = use in your scheme, the default might be a low, high, or midrange value. > SRD> I don't understand the statement that it doesn't makes sense to = define a default priority value. When defining a priority = scheme/profile to be used within a Diameter network, all applications = will need to take the "universal" default value into consideration. = That default value will then be used in the handling of requests where = either the application does not yet have a defined priority scheme or = when the node originating the messages does not yet support the = applications priority scheme. >>=20 >> To make it even more clear I would like to propose the following text = change in the doc: >>=20 >> OLD: >> Diameter nodes MUST have a default priority to apply to = transactions >> that do not have an explicit priority set in the DRMP AVP. >>=20 >> Diameter nodes SHOULD use the PRIORITY_10 priority as this default >> value. >>=20 >> NEW: >> Diameter nodes MAY set a default priority to apply to transactions >> that do not have an explicit priority set in the DRMP AVP if it is >> known that the transactions that define a higher priority than the = default >> are always higher priority than the transactions that do not = define >> a priority explicitly. The default value will depend on the used = priority >> range in a given deployment setup. > SRD> One of the goals of the default priority value is to keep nodes = like Diameter relays from needing to understand application semantics. = This requirement would break those Diameter relays as application level = knowledge is required to know if a message without an explicit priority = value is of a higher priority. >=20 > SRD> In addition, there is only one priority range, as defined in the = document. It is important that the range be the same across all = applications for the mechanism to work, especially in nodes handling = messages for multiple applications. >>=20 >> Diameter node SHOULD not assign >> a default priority if no additional information about the = transaction >> that do not define an explicit priority is known. In this case the >> diameter node SHOULD provide a minimum serving rate for = transaction that do >> not define an explicit priority to avoid full starvation of these >> transactions the may or may not have a higher priority than other >> transactions that provide information about their priority. > SRD> This is explicitly NOT a requirement. It is acceptable to starve = lower priority messages. >>=20 >> I hope that makes sense to you. Please propose edits (if not)! > SRD> I don't yet see a reason to change the original wording. >>=20 >> Mirja >>=20 >> =20 >>> Am 05.05.2016 um 08:32 schrieb Alexey Melnikov = : >>>=20 >>> Hi Mirja, >>>=20 >>> On Wed, May 4, 2016, at 04:50 PM, Mirja Kuehlewind (IETF) wrote: >>>> Hi Janet, >>>>=20 >>>> there are clearly more options than the two mention below. >>>>=20 >>>> E.g. one option is the one explained in my initial comment: hhaving = two >>>> queues, that are both served with a certain rate. >>>>=20 >>>> I=E2=80=99m sure there are more (and potentially more complex) = solutions to this >>>> problem as well. >>>>=20 >>>> Assigning an arbitrary priority is not the right option from my = point of >>>> view and can actually hurt the systems. >>> I hope this will help to clarify things: >>>=20 >>> One point of assigning default priority is that as this is an = extension, >>> there is a desire to avoid upgrading all clients on the network, as = that >>> would be effectively trying to deploy a new protocol. Consider a = network >>> where proxies and servers understand this extension and none of the >>> clients do. Then default priority would be assigned to all traffic = and >>> the behaviour of the system is unchanged from the case when the >>> extension is not deployed. The default priority only makes a = difference >>> if there is a mixture of clients implementing this extension and = clients >>> that don't. >>>=20 >>> Best Regards, >>> Alexey >>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>> Am 04.05.2016 um 17:45 schrieb Gunn, Janet P = : >>>>>=20 >>>>> My comment below. >>>>> Janet >>>>>=20 >>>>> -----Original Message----- >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Mirja = Kuehlewind (IETF) >>>>> Sent: Wednesday, May 04, 2016 10:31 AM >>>>> To: Alexey Melnikov >>>>> Cc: draft-ietf-dime-drmp@ietf.org; dime-chairs@ietf.org; = dime@ietf.org; The IESG >>>>> Subject: Re: [Dime] Mirja K=C3=BChlewind's Discuss on = draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) >>>>>=20 >>>>> Hi Alexey, >>>>>=20 >>>>> see below. >>>>>=20 >>>>> The point is, if you explicitly indicate that you have a lower = priority, you are okay to be starved. However, if you don=E2=80=99t = indicate anything (maybe just because you have not been aware that it is = possible to do so), you might have the same or even a higher priority, = and in this case it=E2=80=99s not okay to be starved. >>>>>=20 >>>>> Mirja >>>>> If a message comes in without a priority, into a system = which serves messages based on priority (regardless of the specific = mechanisms)you have two options >>>>> 1- Discard the message (Not a good idea in most systems) >>>>> 2 - Assign the message an ARBITRARY priority (we call this = arbitrary value the "default priority") >>>>>=20 >>>>> You can (and probably will) argue 'til the cows come home on what = that arbitrary/default value SHOULD BE. And different = sytems/applications might have different "default values". >>>>>=20 >>>>> But I don't think there should be any argument that, if a message = comes in without a priority, you need to assign it a priority. >>>>>=20 >>>>> >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>=20 >>>>> This electronic message transmission contains information from = CSRA that may be attorney-client privileged, proprietary or = confidential. The information 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 agreement or government initiative = expressly permitting the use of email for such purpose. >=20 From nobody Tue May 10 17:34:18 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 396D312B033; Tue, 10 May 2016 17:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 6F6aDEX13r8P; Tue, 10 May 2016 17:34:13 -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 3A38B12B02B; Tue, 10 May 2016 17:34:13 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 11B501803E4; Wed, 11 May 2016 02:34:12 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id CB2BA1A0078; Wed, 11 May 2016 02:34:11 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0294.000; Wed, 11 May 2016 02:34:11 +0200 From: To: "Mirja Kuehlewind (IETF)" , Steve Donovan Thread-Topic: =?utf-8?B?W0RpbWVdIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWll?= =?utf-8?Q?tf-dime-drmp-05:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHRqsu3MGSn2nqArkOEVymcyKpnwZ+yiAMAgAAPPoCAAEzT+w== Date: Wed, 11 May 2016 00:34:11 +0000 Message-ID: <10389_1462926852_57327E03_10389_3007_1_6B7134B31289DC4FAF731D844122B36E01E5F82F@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> <57324CE8.6040109@usdonovans.com>, <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net> In-Reply-To: <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E01E5F82FOPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-dime-drmp@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , "iesg@ietf.org" , Alexey Melnikov Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 11 May 2016 00:34:16 -0000 --_000_6B7134B31289DC4FAF731D844122B36E01E5F82FOPEXCLILM43corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWlyamEsDQoNCkkgdGhpbmsgdGhhdCB3ZSBuZWVkIHRvIGdvIGJhY2sgdG8gdGhlIGluaXRp YWwgcmVxdWlyZW1lbnQuDQpUb2RheSwgaXQgaXMgbm90IHBvc3NpYmxlIHRvIGdpdmUgYSBwcmlv cml0eSBoYW5kbGluZyB0byBhbnkgRGlhbWV0ZXIgbWVzc2FnZSwgZXhjZXB0IGlmIHRoZXJlIGlz IGFuIGV4cGxpY2l0IGhhbmRsaW5nIGRlZmluZWQgYnkgdGhlIGFwcGxpY2F0aW9uIHVzaW5nIHRo ZSBjb21tYW5kcyBvciBieSBvcGVyYXRvciBwb2xpY2llcyBhbmQgdGhpcyBzcGVjaWZpYyBoYW5k bGluZyBjYW4gb25seSBiZSBhcHBsaWVkIGJ5IGNsaWVudHMsIHByb3hpZXMgYW5kIHNlcnZlcnMs IG5vdCBieSByZWxheXMuDQoNCldpdGggdGhlIHByb3Bvc2VkIHNvbHV0aW9uLCBpdCBpcyBwb3Nz aWJsZSB0byBpbmNsdWRlIGEgZXhwbGljaXQgcHJpb3JpdHkgaW5kaWNhdGlvbiBpbiBEaWFtZXRl ciBtZXNzYWdlcyB0aGF0IGNhbiBiZSB1c2VkIGJ5IGFueSBub2RlLCB3aGF0ZXZlciB0aGUgdHlw ZSwgYXMgc29vbiBhcyB0aGV5IGFyZSB1cGdyYWRlZCB0byBzdXBwb3J0IHRoaXMgcHJpb3JpdHkg bWVjaGFuaXNtLg0KDQpOb3csIGluIGhldGVyZWdlbm91cyBuZXR3b3JrcywgaXQgaXMgcmVxdWly ZWQgdG8gaGFuZGxlIGFueSB0eXBlIG9mIG1lc3NhZ2UsIHdpdGggb3Igd2l0aG91dCBwcmlvcml0 eSBpbmRpY2F0aW9uLiBNZXNzYWdlcyB3aXRob3V0IHByaW9yaXR5IGluZGljYXRpb24gd2lsbCBi ZSBoYW5kbGVkIGFzIHRvZGF5LCB3aXRob3V0IGFueSBzcGVjaWZpYyBwcmlvcml0eSBoYW5kbGlu ZyBleGNlcHQgZGVmaW5lZCBvdGhlcndpc2UgKGFzIGRlc2NyaWJlZCBhYm92ZSkuDQoNCkluIHRo aXMgY29udGV4dCwgZGVmaW5pbmcgYSBkZWZhdWx0IHByaW9yaXR5IGhhbmRsaW5nIGZvciB0aGUg bWVzc2FnZXMgd2l0aG91dCBleHBsaWNpdCBwcmlvcml0eSBpbmRpY2F0aW9uIG1ha2VzIHNlbnNl LiBJZiBpdCBpcyByZXF1aXJlZCB0aGF0IHNvbWUgbWVzc2FnZXMgaGF2ZSBhIGhpZ2hlciBwcmlv cml0eSBoYW5kbGluZywgaXQgd2lsbCBiZSByZXF1aXJlZCB0byB1cGdyYWRlIHRoZSBjbGllbnRz IHRvIGVuYWJsZSB0aGVtIHRvIGluY2x1ZGUgdGhlIHByaW9yaXR5IGluZGljYXRpb24uIE90aGVy d2lzZSwgaXQgd2lsbCBiZSB1bmRlcnN0b29kIHRoYXQgdGhlc2UgbWVzc2FnZXMgY291bGQgYmUg ZGVwcmlvcml0aXplZCBjb21wYXJlZCB0byBvdGhlcnMgd2l0aCBleHBsaWNpdCBwcmlvcml0eSBp bmRpY2F0aW9uLg0KDQpNb3Jlb3ZlciwgdGhlIHByaW9yaXR5IGhhbmRsaW5nIHdpbGwgYmUgYXBw bGllZCBPTkxZIHdoZW4gbmVlZGVkLCB3aGVuIG5vdCBhbGwgdGhlIG1lc3NhZ2VzIGNhbiBiZSBo YW5kbGVkLiBTbywgaW4gbm9ybWFsIHNpdHVhdGlvbiwgbm8gZGlmZmVyZW5jZSB3aWxsIGJlIG1h ZGUgYmV0d2VlbiBtZXNzYWdlcyB3aXRoIG9yIHdpdGhvdXQgcHJpb3JpdHkgaW5kaWNhdGlvbi4g QW5kIHdoZW4gcmVxdWlyZWQgdG8gcHJpb3JpdGl6ZSB0aGUgbWVzc2FnZXMsIGl0IGlzIG5vcm1h bCB0byB0YWtlIGludG8gYWNjb3VudCDigJxpbiBwcmlvcml0eeKAnSB0aGUgcHJpb3JpdHkgaW5k aWNhdGlvbiBpbmNsdWRlZCBpbiB0aGUgbWVzc2FnZXMgd2hlbiBhdmFpbGFibGUuIE1lc3NhZ2Vz IHdpdGggcHJpb3JpdHkgaW5kaWNhdGlvbiB3aWxsIGJlIGhhbmRsZWQgd2l0aCBhIGJlc3QtZWZm b3J0IGFwcHJvYWNoIHdoZW4gbm90aGluZyBlbHNlIGlzIGRlZmluZWQgKGJ5IGFwcGxpY2F0aW9u IG9yIG9wZXJhdG9yIHBvbGljeSkuDQoNCkZvciB0aGUgcmVjb3JkLCB0aGUgdmFsdWUgMTAgaXMg bm90IOKAnGFzc2lnbmVk4oCdIHRvIG1lc3NhZ2Ugd2l0aG91dCBwcmlvcml0eSBpbmRpY2F0aW9u LiBUaGUgbm9kZSByZWNlaXZpbmcgdGhlc2UgbWVzc2FnZXMgd2lsbCBiZWhhdmUgYXMgaWYgdGhl IG1lc3NhZ2VzIGluY2x1ZGUgYSBwcmlvcml0eSBpbmRpY2F0aW9uIHNldCB0byB0aGUgdmFsdWUg MTAuDQoNClJlZ2FyZHMsDQoNCkxpb25lbA0KDQpFbnZvecOpIGRlcHVpcyBTdXJmYWNlDQoNCkRl IDogTWlyamEgS3VlaGxld2luZCAoSUVURik8bWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXQ+DQpF bnZvecOpIDog4oCObWVyY3JlZGnigI4g4oCOMTHigI4g4oCObWFp4oCOIOKAjjIwMTYg4oCOMDDi gI464oCOMDENCsOAIDogU3RldmUgRG9ub3ZhbjxtYWlsdG86c3Jkb25vdmFuQHVzZG9ub3ZhbnMu Y29tPg0KQ2MgOiBkcmFmdC1pZXRmLWRpbWUtZHJtcEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0 Zi1kaW1lLWRybXBAaWV0Zi5vcmc+LCBBbGV4ZXkgTWVsbmlrb3Y8bWFpbHRvOmFhbWVsbmlrb3ZA ZmFzdG1haWwuZm0+LCBkaW1lLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86ZGltZS1jaGFpcnNAaWV0 Zi5vcmc+LCBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPiwgaWVzZ0BpZXRmLm9y ZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4NCg0KU2VlIGJlbG93Lg0KDQo+IEFtIDEwLjA1LjIwMTYg dW0gMTc6MDQgc2NocmllYiBTdGV2ZSBEb25vdmFuIDxzcmRvbm92YW5AdXNkb25vdmFucy5jb20+ Og0KPg0KPiBNaXJqYSwNCj4NCj4gUGxlYXNlIHNlZSBteSBjb21tZW50cyBpbmxpbmUuDQo+DQo+ IFJlZ2FyZHMsDQo+DQo+IFN0ZXZlDQo+DQo+IE9uIDUvMTAvMTYgOTo0NiBBTSwgTWlyamEgS3Vl aGxld2luZCAoSUVURikgd3JvdGU6DQo+PiBIaSBhbGwsDQo+Pg0KPj4gc29ycnkgZm9yIG15IGxh dGUgcmVwbHkuDQo+Pg0KPj4gSSB0aGluayB0aGUgcGFydCB3aXRoIHRoZSB0d28gcXVldWVzIHdh cyBhIGxpdHRsZSBjb25mdXNpbmcuIFNvcnJ5IGZvciB0aGF0IGFzIHdlbGwuIEkgb3JpZ2luYWxs eSBtZWFudCB0byBkZXNjcmliZSB0aGlzIHRvIGlsbHVzdHJhdGUgdGhlIHByb2JsZW0gcmF0aGVy IHRoYW4gZGVzY3JpYmluZyBhIHNvbHV0aW9uLiBIb3dldmVyLCB1c2luZyB0d28gcXVldWVzICh3 aGljaCBmdWxseSBpcyBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwpIGRvZXMgbm90IGV2ZW4gbWF0 Y2ggdGhlIHByb2JsZW0gY29ycmVjdGx5IHRoYXQgSSB3YW50ZWQgdG8gZGVzY3JpYmXigKYgdGhl IGFjdHVhbGx5IHBvaW50IHdvdWxkIGJlIGFib3V0IHRoZSBzY2hlZHVsaW5nIHRoYXQgb25lIHdv dWxkIG5lZWQgdG8gaW1wbGVtZW50IHRvIHNlcnZlIHRoZSBxdWV1ZXMuIEhlcmUgbXkgdGhpbmtp bmcgd2FzIHRoYXQsIGluc3RlYWQgb2YgaW1wbGVtZW50aW5nIGEgc3RyaWN0IHByaW9yaXR5IHNj aGVkdWxpbmcsIHlvdSBjb3VsZCBhbHNvIGltcGxlbWVudCBhIHNjaGVtZSB0aGF0IGd1YXJhbnRl ZXMgYSBjZXJ0YWluIG1pbmltdW0gc2VydmluZyByYXRlIGZvciB0aGUgbm9uLXByaW9yaXR5LWRl ZmluZWQgcmVxdWVzdHMgdG8gYXZvaWQgZnVsbCBzdGFydmF0aW9uLiBIb3dldmVyLCBJIGRvbuKA mXQgd2FudCB0byBjb25mdXNlIHlvdSBldmVuIG1vcmUgaGVyZS4gU28gbGV0IG1lIHRyeSB0byBw aGFzZSBteSBjb25jZXJuIGFnYWluIChJ4oCZdmUgYWxzbyBlZGl0ZWQgbXkgZGlzY3VzcyB0ZXh0 KToNCj4+DQo+PiBJIGRvbuKAmXQgdGhpbmsgaXQgaXMgYSBnb29kIGlkZWEgdG8gYXNzaWduIGEg ZGVmYXVsdCBwcmlvcml0eSB0byBub24tcHJpb3JpdHktZGVmaW5lZCByZXF1ZXN0cyBhdCBhbGwu IElmIHlvdSBoYXZlIGhpZ2ggcHJpb3JpdHkgdHJhZmZpYyB0aGF0IGRvZXMgbm90IHN1cHBvcnQg dGhpcyBleHRlbnNpb24gKHlldCkgdGhpcyB0cmFmZmljIGNvdWxkIGJlIHN0YXJ2ZWQgYnkgbG93 ZXIgcHJpb3JpdHkgdHJhZmZpYyB3aGVuIGFzc2lnbmluZyBhIG1pZGRsZSByYW5nZSBwcmlvcml0 eS4gSSBkb27igJl0IHRoaW5rIHRoYXQgaXMgd2hhdCB5b3Ugd2FudCB0byBhY2hpZXZlLg0KPiBT UkQ+IEFjdHVhbGx5LCB0aGlzIGlzIHdoYXQgd2Ugd2FudCB0byBhY2hpZXZlLiAgSXQgaXMgYW4g cmVxdWlyZW1lbnQgdGhhdCBtZXNzYWdlcyBleHBsaWNpdGx5IG1hcmtlZCBhcyBoaWdoIHByaW9y aXR5IGdldCB0cmVhdGVkIGV2ZW4gaWYgaXQgcmVzdWx0cyBpbiBzdGFydmluZyBsb3dlciBwcmlv cml0eSBtZXNzYWdlcy4gIFRoZSBzdGFydmluZyBvZiBsb3dlciBwcmlvcml0eSBtZXNzYWdlcyBp cyBub3QgYW4gcHJvYmxlbSwgaXQgaXMgYSByZXF1aXJlbWVudC4NCg0KSSB0aGluayB3ZSBhcmUg c3RpbGwgdGFsa2luZyBwYXN0IGVhY2ggb3RoZXIuIElmIHlvdSBleHBsaWNpdGx5IGFzc2lnbiBh IHByaW9yaXR5LCBzdGFydmF0aW9uIG1pZ2h0IGJlIG9rYXkuIEhvd2V2ZXIsIGlmIHlvdSBkb27i gJl0IGhhdmUgYSBwcmlvcml0eSBleHBsaWNpdGx5IHNpZ25hbGVkLCB0aGUgdHJhbnNhY3Rpb24g bWlnaHQgaGF2ZSBhIHZlcnkgaGlnaCBwcmlvcml0eSBidXQgeW91IGp1c3QgZG9u4oCZdCBrbm93 IGFuZCBieSBhc3NpZ25pbmcgYSByYW5kb20gbWlkLXJhbmdlIHByaW9yaXR5IHRoaXMgaW1wb3J0 YW50IHJlcXVlc3QgY291bGQgZ2V0IHN0YXJ2ZWQuDQoNCk1pcmphDQoNCg0KPj4NCj4+IEkgdGhp bmsgdGhpcyBwb2ludCBpcyBldmVuIG1vcmUgdHJ1ZSB3aXRoIHJlc3BlY3QgdG8gdGhlIGRpc2N1 c3Npb24gdGhhdCB3ZW50IG9uIHdpdGggQWxpc3NhIGFuZCBCZW4uIFRoZXJlLCB5b3Ugc2FpZCwg eW914oCZZCBuZWVkIHRvIGRlZmluZSBhIHByaW9yaXR5IHNjaGVtZSBmb3IgYSBjZXJ0YWluIGFw cGxpY2F0aW9uIGJlZm9yZSB5b3UgY291bGQgdXNlIGl0LiBHaXZlbiB0aGF0IGl0IGRvZXMgbm90 IG1ha2Ugc2Vuc2UgdG8gZGVmaW5lIGEgZGVmYXVsdCBwcmlvcml0eSB2YWx1ZSB0byBmb3IgYWxs IHVzZXMgYmVjYXVzZSBkZXBlbmRpbmcgb2Ygd2l0aCBwcmlvcml0eSByYW5nZSB5b3Ugc2VsZWN0 IHRvIHVzZSBpbiB5b3VyIHNjaGVtZSwgdGhlIGRlZmF1bHQgbWlnaHQgYmUgYSBsb3csIGhpZ2gs IG9yIG1pZHJhbmdlIHZhbHVlLg0KPiBTUkQ+IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgc3RhdGVt ZW50IHRoYXQgaXQgZG9lc24ndCBtYWtlcyBzZW5zZSB0byBkZWZpbmUgYSBkZWZhdWx0IHByaW9y aXR5IHZhbHVlLiAgV2hlbiBkZWZpbmluZyBhIHByaW9yaXR5IHNjaGVtZS9wcm9maWxlIHRvIGJl IHVzZWQgd2l0aGluIGEgRGlhbWV0ZXIgbmV0d29yaywgYWxsIGFwcGxpY2F0aW9ucyB3aWxsIG5l ZWQgdG8gdGFrZSB0aGUgInVuaXZlcnNhbCIgZGVmYXVsdCB2YWx1ZSBpbnRvIGNvbnNpZGVyYXRp b24uICBUaGF0IGRlZmF1bHQgdmFsdWUgd2lsbCB0aGVuIGJlIHVzZWQgaW4gdGhlIGhhbmRsaW5n IG9mIHJlcXVlc3RzIHdoZXJlIGVpdGhlciB0aGUgYXBwbGljYXRpb24gZG9lcyBub3QgeWV0IGhh dmUgYSBkZWZpbmVkIHByaW9yaXR5IHNjaGVtZSBvciB3aGVuIHRoZSBub2RlIG9yaWdpbmF0aW5n IHRoZSBtZXNzYWdlcyBkb2VzIG5vdCB5ZXQgc3VwcG9ydCB0aGUgYXBwbGljYXRpb25zIHByaW9y aXR5IHNjaGVtZS4NCj4+DQo+PiBUbyBtYWtlIGl0IGV2ZW4gbW9yZSBjbGVhciBJIHdvdWxkIGxp a2UgdG8gcHJvcG9zZSB0aGUgZm9sbG93aW5nIHRleHQgY2hhbmdlIGluIHRoZSBkb2M6DQo+Pg0K Pj4gT0xEOg0KPj4gICAgRGlhbWV0ZXIgbm9kZXMgTVVTVCBoYXZlIGEgZGVmYXVsdCBwcmlvcml0 eSB0byBhcHBseSB0byB0cmFuc2FjdGlvbnMNCj4+ICAgIHRoYXQgZG8gbm90IGhhdmUgYW4gZXhw bGljaXQgcHJpb3JpdHkgc2V0IGluIHRoZSBEUk1QIEFWUC4NCj4+DQo+PiAgICBEaWFtZXRlciBu b2RlcyBTSE9VTEQgdXNlIHRoZSBQUklPUklUWV8xMCBwcmlvcml0eSBhcyB0aGlzIGRlZmF1bHQN Cj4+ICAgIHZhbHVlLg0KPj4NCj4+IE5FVzoNCj4+ICAgIERpYW1ldGVyIG5vZGVzIE1BWSBzZXQg YSBkZWZhdWx0IHByaW9yaXR5IHRvIGFwcGx5IHRvIHRyYW5zYWN0aW9ucw0KPj4gICAgdGhhdCBk byBub3QgaGF2ZSBhbiBleHBsaWNpdCBwcmlvcml0eSBzZXQgaW4gdGhlIERSTVAgQVZQIGlmIGl0 IGlzDQo+PiAgICBrbm93biB0aGF0IHRoZSB0cmFuc2FjdGlvbnMgdGhhdCBkZWZpbmUgYSBoaWdo ZXIgcHJpb3JpdHkgdGhhbiB0aGUgZGVmYXVsdA0KPj4gICAgYXJlIGFsd2F5cyBoaWdoZXIgcHJp b3JpdHkgdGhhbiB0aGUgdHJhbnNhY3Rpb25zIHRoYXQgZG8gbm90IGRlZmluZQ0KPj4gICAgYSBw cmlvcml0eSBleHBsaWNpdGx5LiBUaGUgZGVmYXVsdCB2YWx1ZSB3aWxsIGRlcGVuZCBvbiB0aGUg dXNlZCBwcmlvcml0eQ0KPj4gICAgcmFuZ2UgaW4gYSBnaXZlbiBkZXBsb3ltZW50IHNldHVwLg0K PiBTUkQ+IE9uZSBvZiB0aGUgZ29hbHMgb2YgdGhlIGRlZmF1bHQgcHJpb3JpdHkgdmFsdWUgaXMg dG8ga2VlcCBub2RlcyBsaWtlIERpYW1ldGVyIHJlbGF5cyBmcm9tIG5lZWRpbmcgdG8gdW5kZXJz dGFuZCBhcHBsaWNhdGlvbiBzZW1hbnRpY3MuICBUaGlzIHJlcXVpcmVtZW50IHdvdWxkIGJyZWFr IHRob3NlIERpYW1ldGVyIHJlbGF5cyBhcyBhcHBsaWNhdGlvbiBsZXZlbCBrbm93bGVkZ2UgaXMg cmVxdWlyZWQgdG8ga25vdyBpZiBhIG1lc3NhZ2Ugd2l0aG91dCBhbiBleHBsaWNpdCBwcmlvcml0 eSB2YWx1ZSBpcyBvZiBhIGhpZ2hlciBwcmlvcml0eS4NCj4NCj4gU1JEPiBJbiBhZGRpdGlvbiwg dGhlcmUgaXMgb25seSBvbmUgcHJpb3JpdHkgcmFuZ2UsIGFzIGRlZmluZWQgaW4gdGhlIGRvY3Vt ZW50LiAgSXQgaXMgaW1wb3J0YW50IHRoYXQgdGhlIHJhbmdlIGJlIHRoZSBzYW1lIGFjcm9zcyBh bGwgYXBwbGljYXRpb25zIGZvciB0aGUgbWVjaGFuaXNtIHRvIHdvcmssIGVzcGVjaWFsbHkgaW4g bm9kZXMgaGFuZGxpbmcgbWVzc2FnZXMgZm9yIG11bHRpcGxlIGFwcGxpY2F0aW9ucy4NCj4+DQo+ PiAgICBEaWFtZXRlciBub2RlIFNIT1VMRCBub3QgYXNzaWduDQo+PiAgICBhIGRlZmF1bHQgcHJp b3JpdHkgaWYgbm8gYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgdHJhbnNhY3Rpb24N Cj4+ICAgIHRoYXQgZG8gbm90IGRlZmluZSBhbiBleHBsaWNpdCBwcmlvcml0eSBpcyBrbm93bi4g SW4gdGhpcyBjYXNlIHRoZQ0KPj4gICAgZGlhbWV0ZXIgbm9kZSBTSE9VTEQgcHJvdmlkZSBhIG1p bmltdW0gc2VydmluZyByYXRlIGZvciB0cmFuc2FjdGlvbiB0aGF0IGRvDQo+PiAgICBub3QgZGVm aW5lIGFuIGV4cGxpY2l0IHByaW9yaXR5IHRvIGF2b2lkIGZ1bGwgc3RhcnZhdGlvbiBvZiB0aGVz ZQ0KPj4gICAgdHJhbnNhY3Rpb25zIHRoZSBtYXkgb3IgbWF5IG5vdCBoYXZlIGEgaGlnaGVyIHBy aW9yaXR5IHRoYW4gb3RoZXINCj4+ICAgIHRyYW5zYWN0aW9ucyB0aGF0IHByb3ZpZGUgaW5mb3Jt YXRpb24gYWJvdXQgdGhlaXIgcHJpb3JpdHkuDQo+IFNSRD4gVGhpcyBpcyBleHBsaWNpdGx5IE5P VCBhIHJlcXVpcmVtZW50LiAgSXQgaXMgYWNjZXB0YWJsZSB0byBzdGFydmUgbG93ZXIgcHJpb3Jp dHkgbWVzc2FnZXMuDQo+Pg0KPj4gSSBob3BlIHRoYXQgbWFrZXMgc2Vuc2UgdG8geW91LiBQbGVh c2UgcHJvcG9zZSBlZGl0cyAoaWYgbm90KSENCj4gU1JEPiBJIGRvbid0IHlldCBzZWUgYSByZWFz b24gdG8gY2hhbmdlIHRoZSBvcmlnaW5hbCB3b3JkaW5nLg0KPj4NCj4+IE1pcmphDQo+Pg0KPj4N Cj4+PiBBbSAwNS4wNS4yMDE2IHVtIDA4OjMyIHNjaHJpZWIgQWxleGV5IE1lbG5pa292IDxhYW1l bG5pa292QGZhc3RtYWlsLmZtPjoNCj4+Pg0KPj4+IEhpIE1pcmphLA0KPj4+DQo+Pj4gT24gV2Vk LCBNYXkgNCwgMjAxNiwgYXQgMDQ6NTAgUE0sIE1pcmphIEt1ZWhsZXdpbmQgKElFVEYpIHdyb3Rl Og0KPj4+PiBIaSBKYW5ldCwNCj4+Pj4NCj4+Pj4gdGhlcmUgYXJlIGNsZWFybHkgbW9yZSBvcHRp b25zIHRoYW4gdGhlIHR3byBtZW50aW9uIGJlbG93Lg0KPj4+Pg0KPj4+PiBFLmcuIG9uZSBvcHRp b24gaXMgdGhlIG9uZSBleHBsYWluZWQgaW4gbXkgaW5pdGlhbCBjb21tZW50OiBoaGF2aW5nIHR3 bw0KPj4+PiBxdWV1ZXMsIHRoYXQgYXJlIGJvdGggc2VydmVkIHdpdGggYSBjZXJ0YWluIHJhdGUu DQo+Pj4+DQo+Pj4+IEnigJltIHN1cmUgdGhlcmUgYXJlIG1vcmUgKGFuZCBwb3RlbnRpYWxseSBt b3JlIGNvbXBsZXgpIHNvbHV0aW9ucyB0byB0aGlzDQo+Pj4+IHByb2JsZW0gYXMgd2VsbC4NCj4+ Pj4NCj4+Pj4gQXNzaWduaW5nIGFuIGFyYml0cmFyeSBwcmlvcml0eSBpcyBub3QgdGhlIHJpZ2h0 IG9wdGlvbiBmcm9tIG15IHBvaW50IG9mDQo+Pj4+IHZpZXcgYW5kIGNhbiBhY3R1YWxseSBodXJ0 IHRoZSBzeXN0ZW1zLg0KPj4+IEkgaG9wZSB0aGlzIHdpbGwgaGVscCB0byBjbGFyaWZ5IHRoaW5n czoNCj4+Pg0KPj4+IE9uZSBwb2ludCBvZiBhc3NpZ25pbmcgZGVmYXVsdCBwcmlvcml0eSBpcyB0 aGF0IGFzIHRoaXMgaXMgYW4gZXh0ZW5zaW9uLA0KPj4+IHRoZXJlIGlzIGEgZGVzaXJlIHRvIGF2 b2lkIHVwZ3JhZGluZyBhbGwgY2xpZW50cyBvbiB0aGUgbmV0d29yaywgYXMgdGhhdA0KPj4+IHdv dWxkIGJlIGVmZmVjdGl2ZWx5IHRyeWluZyB0byBkZXBsb3kgYSBuZXcgcHJvdG9jb2wuIENvbnNp ZGVyIGEgbmV0d29yaw0KPj4+IHdoZXJlIHByb3hpZXMgYW5kIHNlcnZlcnMgdW5kZXJzdGFuZCB0 aGlzIGV4dGVuc2lvbiBhbmQgbm9uZSBvZiB0aGUNCj4+PiBjbGllbnRzIGRvLiBUaGVuIGRlZmF1 bHQgcHJpb3JpdHkgd291bGQgYmUgYXNzaWduZWQgdG8gYWxsIHRyYWZmaWMgYW5kDQo+Pj4gdGhl IGJlaGF2aW91ciBvZiB0aGUgc3lzdGVtIGlzIHVuY2hhbmdlZCBmcm9tIHRoZSBjYXNlIHdoZW4g dGhlDQo+Pj4gZXh0ZW5zaW9uIGlzIG5vdCBkZXBsb3llZC4gVGhlIGRlZmF1bHQgcHJpb3JpdHkg b25seSBtYWtlcyBhIGRpZmZlcmVuY2UNCj4+PiBpZiB0aGVyZSBpcyBhIG1peHR1cmUgb2YgY2xp ZW50cyBpbXBsZW1lbnRpbmcgdGhpcyBleHRlbnNpb24gYW5kIGNsaWVudHMNCj4+PiB0aGF0IGRv bid0Lg0KPj4+DQo+Pj4gQmVzdCBSZWdhcmRzLA0KPj4+IEFsZXhleQ0KPj4+DQo+Pj4+IE1pcmph DQo+Pj4+DQo+Pj4+DQo+Pj4+PiBBbSAwNC4wNS4yMDE2IHVtIDE3OjQ1IHNjaHJpZWIgR3Vubiwg SmFuZXQgUCA8SmFuZXQuR3VubkBjc3JhLmNvbT46DQo+Pj4+Pg0KPj4+Pj4gTXkgY29tbWVudCBi ZWxvdy4NCj4+Pj4+IEphbmV0DQo+Pj4+Pg0KPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+Pj4+IEZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBNaXJqYSBLdWVobGV3aW5kIChJRVRGKQ0KPj4+Pj4gU2VudDogV2VkbmVzZGF5LCBN YXkgMDQsIDIwMTYgMTA6MzEgQU0NCj4+Pj4+IFRvOiBBbGV4ZXkgTWVsbmlrb3YgPGFhbWVsbmlr b3ZAZmFzdG1haWwuZm0+DQo+Pj4+PiBDYzogZHJhZnQtaWV0Zi1kaW1lLWRybXBAaWV0Zi5vcmc7 IGRpbWUtY2hhaXJzQGlldGYub3JnOyBkaW1lQGlldGYub3JnOyBUaGUgSUVTRyA8aWVzZ0BpZXRm Lm9yZz4NCj4+Pj4+IFN1YmplY3Q6IFJlOiBbRGltZV0gTWlyamEgS8O8aGxld2luZCdzIERpc2N1 c3Mgb24gZHJhZnQtaWV0Zi1kaW1lLWRybXAtMDU6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQp DQo+Pj4+Pg0KPj4+Pj4gSGkgQWxleGV5LA0KPj4+Pj4NCj4+Pj4+IHNlZSBiZWxvdy4NCj4+Pj4+ DQo+Pj4+PiBUaGUgcG9pbnQgaXMsIGlmIHlvdSBleHBsaWNpdGx5IGluZGljYXRlIHRoYXQgeW91 IGhhdmUgYSBsb3dlciBwcmlvcml0eSwgeW91IGFyZSBva2F5IHRvIGJlIHN0YXJ2ZWQuIEhvd2V2 ZXIsIGlmIHlvdSBkb27igJl0IGluZGljYXRlIGFueXRoaW5nIChtYXliZSBqdXN0IGJlY2F1c2Ug eW91IGhhdmUgbm90IGJlZW4gYXdhcmUgdGhhdCBpdCBpcyBwb3NzaWJsZSB0byBkbyBzbyksIHlv dSBtaWdodCBoYXZlIHRoZSBzYW1lIG9yIGV2ZW4gYSBoaWdoZXIgcHJpb3JpdHksIGFuZCBpbiB0 aGlzIGNhc2UgaXTigJlzIG5vdCBva2F5IHRvIGJlIHN0YXJ2ZWQuDQo+Pj4+Pg0KPj4+Pj4gTWly amENCj4+Pj4+IDxKUEc+IElmIGEgbWVzc2FnZSBjb21lcyBpbiB3aXRob3V0IGEgcHJpb3JpdHks IGludG8gYSBzeXN0ZW0gd2hpY2ggc2VydmVzIG1lc3NhZ2VzIGJhc2VkIG9uIHByaW9yaXR5IChy ZWdhcmRsZXNzIG9mIHRoZSBzcGVjaWZpYyBtZWNoYW5pc21zKXlvdSBoYXZlIHR3byBvcHRpb25z DQo+Pj4+PiAxLSBEaXNjYXJkIHRoZSBtZXNzYWdlIChOb3QgYSBnb29kIGlkZWEgaW4gbW9zdCBz eXN0ZW1zKQ0KPj4+Pj4gMiAtIEFzc2lnbiB0aGUgbWVzc2FnZSBhbiBBUkJJVFJBUlkgcHJpb3Jp dHkgKHdlIGNhbGwgdGhpcyBhcmJpdHJhcnkgdmFsdWUgdGhlICJkZWZhdWx0IHByaW9yaXR5IikN Cj4+Pj4+DQo+Pj4+PiBZb3UgY2FuIChhbmQgcHJvYmFibHkgd2lsbCkgYXJndWUgJ3RpbCB0aGUg Y293cyBjb21lIGhvbWUgb24gd2hhdCB0aGF0IGFyYml0cmFyeS9kZWZhdWx0IHZhbHVlIFNIT1VM RCBCRS4gIEFuZCBkaWZmZXJlbnQgc3l0ZW1zL2FwcGxpY2F0aW9ucyBtaWdodCBoYXZlIGRpZmZl cmVudCAiZGVmYXVsdCB2YWx1ZXMiLg0KPj4+Pj4NCj4+Pj4+IEJ1dCBJIGRvbid0IHRoaW5rIHRo ZXJlIHNob3VsZCBiZSBhbnkgYXJndW1lbnQgdGhhdCwgaWYgYSBtZXNzYWdlIGNvbWVzIGluIHdp dGhvdXQgYSBwcmlvcml0eSwgeW91IG5lZWQgdG8gYXNzaWduIGl0IGEgcHJpb3JpdHkuDQo+Pj4+ Pg0KPj4+Pj4gPC9KUEc+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gRGlNRSBtYWlsaW5nIGxp c3QNCj4+Pj4+IERpTUVAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZGltZQ0KPj4+Pj4NCj4+Pj4+IFRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIHRy YW5zbWlzc2lvbiBjb250YWlucyBpbmZvcm1hdGlvbiBmcm9tIENTUkEgdGhhdCBtYXkgYmUgYXR0 b3JuZXktY2xpZW50IHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5IG9yIGNvbmZpZGVudGlhbC4gVGhl IGluZm9ybWF0aW9uIGluIHRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBvbmx5IGZvciB1c2UgYnkg dGhlIGluZGl2aWR1YWwocykgdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBiZWxpZXZl IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIGNvbnRhY3Qg bWUgaW1tZWRpYXRlbHkgYW5kIGJlIGF3YXJlIHRoYXQgYW55IHVzZSwgZGlzY2xvc3VyZSwgY29w eWluZyBvciBkaXN0cmlidXRpb24gb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZSBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLiBOT1RFOiBSZWdhcmRsZXNzIG9mIGNvbnRlbnQsIHRoaXMgZW1h aWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gYmluZCBDU1JBIHRvIGFueSBvcmRlciBvciBvdGhlciBj b250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgd3JpdHRlbiBhZ3JlZW1lbnQgb3Ig Z292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJlc3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2YgZW1h aWwgZm9yIHN1Y2ggcHVycG9zZS4NCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpB cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlv dS4KCg== --_000_6B7134B31289DC4FAF731D844122B36E01E5F82FOPEXCLILM43corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVu dD0iV2luZG93cyBNYWlsIDE3LjUuOTYwMC4yMDkxMSI+DQo8c3R5bGU+PCEtLQpodG1sIHsKZm9u dC1mYW1pbHk6IkNvbG9yIEVtb2ppIiwgIkNhbGlicmkiLCAiU2Vnb2UgVUkiLCAiTWVpcnlvIiwg Ik1pY3Jvc29mdCBZYUhlaSBVSSIsICJNaWNyb3NvZnQgSmhlbmdIZWkgVUkiLCAiTWFsZ3VuIEdv dGhpYyIsICJzYW5zLXNlcmlmIjsKfQotLT48L3N0eWxlPjxzdHlsZSBkYXRhLWV4dGVybmFsc3R5 bGU9InRydWUiPjwhLS0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaCB7Cm1hcmdpbi10b3A6MGluOwptYXJnaW4tcmlnaHQ6MGluOwpt YXJnaW4tYm90dG9tOjBpbjsKbWFyZ2luLWxlZnQ6LjVpbjsKbWFyZ2luLWJvdHRvbTouMDAwMXB0 Owp9CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwgewptYXJnaW46MGlu OwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KcC5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCBs aS5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJz dCwgCnAuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNw TWlkZGxlLCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIApwLk1zb0xpc3RQYXJhZ3Jh cGhDeFNwTGFzdCwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBkaXYuTXNvTGlzdFBhcmFn cmFwaEN4U3BMYXN0IHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdodDowaW47Cm1hcmdpbi1i b3R0b206MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7CmxpbmUt aGVpZ2h0OjExNSU7Cn0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxk aXYgZGF0YS1leHRlcm5hbHN0eWxlPSJmYWxzZSIgZGlyPSJsdHIiIHN0eWxlPSJmb250LWZhbWls eTogJ0NhbGlicmknLCAnU2Vnb2UgVUknLCAnTWVpcnlvJywgJ01pY3Jvc29mdCBZYUhlaSBVSScs ICdNaWNyb3NvZnQgSmhlbmdIZWkgVUknLCAnTWFsZ3VuIEdvdGhpYycsICdzYW5zLXNlcmlmJztm b250LXNpemU6MTJwdDsiPg0KPGRpdj5IaSBNaXJqYSw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PkkgdGhpbmsgdGhhdCB3ZSBuZWVkIHRvIGdvIGJhY2sgdG8gdGhlIGluaXRpYWwgcmVx dWlyZW1lbnQuPC9kaXY+DQo8ZGl2PlRvZGF5LCBpdCBpcyBub3QgcG9zc2libGUgdG8gZ2l2ZSBh IHByaW9yaXR5IGhhbmRsaW5nIHRvIGFueSBEaWFtZXRlciBtZXNzYWdlLCBleGNlcHQgaWYgdGhl cmUgaXMgYW4gZXhwbGljaXQgaGFuZGxpbmcgZGVmaW5lZCBieSB0aGUgYXBwbGljYXRpb24gdXNp bmcgdGhlIGNvbW1hbmRzIG9yIGJ5IG9wZXJhdG9yIHBvbGljaWVzIGFuZCB0aGlzIHNwZWNpZmlj IGhhbmRsaW5nIGNhbiBvbmx5IGJlIGFwcGxpZWQgYnkgY2xpZW50cywgcHJveGllcw0KIGFuZCBz ZXJ2ZXJzLCBub3QgYnkgcmVsYXlzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2l0 aCB0aGUgcHJvcG9zZWQgc29sdXRpb24sIGl0IGlzIHBvc3NpYmxlIHRvIGluY2x1ZGUgYSBleHBs aWNpdCBwcmlvcml0eSBpbmRpY2F0aW9uIGluIERpYW1ldGVyIG1lc3NhZ2VzJm5ic3A7dGhhdCBj YW4gYmUgdXNlZCBieSBhbnkgbm9kZSwgd2hhdGV2ZXIgdGhlIHR5cGUsIGFzIHNvb24gYXMgdGhl eSBhcmUgdXBncmFkZWQgdG8gc3VwcG9ydCB0aGlzIHByaW9yaXR5IG1lY2hhbmlzbS48L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk5vdywgaW4gaGV0ZXJlZ2Vub3VzIG5ldHdvcmtzLCBp dCBpcyByZXF1aXJlZCB0byBoYW5kbGUgYW55IHR5cGUgb2YgbWVzc2FnZSwgd2l0aCBvciB3aXRo b3V0IHByaW9yaXR5IGluZGljYXRpb24uIE1lc3NhZ2VzIHdpdGhvdXQgcHJpb3JpdHkgaW5kaWNh dGlvbiB3aWxsIGJlIGhhbmRsZWQgYXMgdG9kYXksIHdpdGhvdXQgYW55IHNwZWNpZmljIHByaW9y aXR5IGhhbmRsaW5nIGV4Y2VwdCBkZWZpbmVkIG90aGVyd2lzZSAoYXMgZGVzY3JpYmVkDQogYWJv dmUpLiA8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkluIHRoaXMgY29udGV4dCwgZGVm aW5pbmcgYSBkZWZhdWx0IHByaW9yaXR5IGhhbmRsaW5nIGZvciB0aGUgbWVzc2FnZXMgd2l0aG91 dCBleHBsaWNpdCBwcmlvcml0eSBpbmRpY2F0aW9uIG1ha2VzIHNlbnNlLiBJZiBpdCBpcyByZXF1 aXJlZCB0aGF0IHNvbWUgbWVzc2FnZXMgaGF2ZSBhIGhpZ2hlciBwcmlvcml0eSBoYW5kbGluZywg aXQgd2lsbCBiZSByZXF1aXJlZCB0byB1cGdyYWRlIHRoZSBjbGllbnRzIHRvIGVuYWJsZSB0aGVt IHRvDQogaW5jbHVkZSB0aGUgcHJpb3JpdHkgaW5kaWNhdGlvbi4gT3RoZXJ3aXNlLCBpdCB3aWxs IGJlIHVuZGVyc3Rvb2QgdGhhdCB0aGVzZSBtZXNzYWdlcyBjb3VsZCBiZSBkZXByaW9yaXRpemVk IGNvbXBhcmVkIHRvIG90aGVycyB3aXRoIGV4cGxpY2l0IHByaW9yaXR5IGluZGljYXRpb24uPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Nb3Jlb3ZlciwgdGhlIHByaW9yaXR5IGhhbmRs aW5nIHdpbGwgYmUgYXBwbGllZCBPTkxZIHdoZW4gbmVlZGVkLCB3aGVuIG5vdCBhbGwgdGhlIG1l c3NhZ2VzIGNhbiBiZSBoYW5kbGVkLiBTbywgaW4gbm9ybWFsIHNpdHVhdGlvbiwgbm8gZGlmZmVy ZW5jZSB3aWxsIGJlIG1hZGUgYmV0d2VlbiBtZXNzYWdlcyB3aXRoIG9yIHdpdGhvdXQgcHJpb3Jp dHkgaW5kaWNhdGlvbi4gQW5kIHdoZW4gcmVxdWlyZWQgdG8gcHJpb3JpdGl6ZSB0aGUgbWVzc2Fn ZXMsDQogaXQgaXMgbm9ybWFsIHRvIHRha2UgaW50byBhY2NvdW50Jm5ic3A74oCcaW4mbmJzcDtw cmlvcml0eeKAnSB0aGUgcHJpb3JpdHkgaW5kaWNhdGlvbiBpbmNsdWRlZCBpbiB0aGUgbWVzc2Fn ZXMgd2hlbiBhdmFpbGFibGUuIE1lc3NhZ2VzIHdpdGggcHJpb3JpdHkgaW5kaWNhdGlvbiB3aWxs IGJlIGhhbmRsZWQgd2l0aCBhIGJlc3QtZWZmb3J0IGFwcHJvYWNoIHdoZW4gbm90aGluZyBlbHNl IGlzIGRlZmluZWQgKGJ5IGFwcGxpY2F0aW9uIG9yIG9wZXJhdG9yIHBvbGljeSkuPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Gb3IgdGhlIHJlY29yZCwgdGhlIHZhbHVlIDEwIGlzIG5v dCZuYnNwO+KAnGFzc2lnbmVk4oCdIHRvIG1lc3NhZ2Ugd2l0aG91dCBwcmlvcml0eSBpbmRpY2F0 aW9uLiBUaGUgbm9kZSByZWNlaXZpbmcgdGhlc2UgbWVzc2FnZXMgd2lsbCBiZWhhdmUgYXMgaWYg dGhlIG1lc3NhZ2VzIGluY2x1ZGUgYSBwcmlvcml0eSBpbmRpY2F0aW9uIHNldCB0byB0aGUgdmFs dWUgMTAuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+TGlvbmVsPGJyPg0KPC9kaXY+DQo8ZGl2IGRhdGEtc2lnbmF0 dXJlYmxvY2s9InRydWUiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RW52b3nDqSBkZXB1aXMg U3VyZmFjZTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0icGFk ZGluZy10b3A6IDVweDsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDIyOSwgMjI5LCAyMjkpOyBib3Jk ZXItdG9wLXdpZHRoOiAxcHg7IGJvcmRlci10b3Atc3R5bGU6IHNvbGlkOyI+DQo8ZGl2Pjxmb250 IGZhY2U9IiAnQ2FsaWJyaScsICdTZWdvZSBVSScsICdNZWlyeW8nLCAnTWljcm9zb2Z0IFlhSGVp IFVJJywgJ01pY3Jvc29mdCBKaGVuZ0hlaSBVSScsICdNYWxndW4gR290aGljJywgJ3NhbnMtc2Vy aWYnIiBzdHlsZT0ibGluZS1oZWlnaHQ6IDE1cHQ7IGxldHRlci1zcGFjaW5nOiAwLjAyZW07IGZv bnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCAmcXVvdDtTZWdvZSBVSSZxdW90OywgJnF1 b3Q7TWVpcnlvJnF1b3Q7LCAmcXVvdDtNaWNyb3NvZnQgWWFIZWkgVUkmcXVvdDssICZxdW90O01p Y3Jvc29mdCBKaGVuZ0hlaSBVSSZxdW90OywgJnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywgJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMnB0OyI+PGI+RGUmbmJzcDs6PC9iPiZu YnNwOzxhIGhyZWY9Im1haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0IiB0YXJnZXQ9Il9wYXJlbnQi Pk1pcmphDQogS3VlaGxld2luZCAoSUVURik8L2E+PGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+ Jm5ic3A74oCObWVyY3JlZGnigI4g4oCOMTHigI4g4oCObWFp4oCOIOKAjjIwMTYg4oCOMDDigI46 4oCOMDE8YnI+DQo8Yj7DgCA6PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpzcmRvbm92YW5AdXNk b25vdmFucy5jb20iIHRhcmdldD0iX3BhcmVudCI+U3RldmUgRG9ub3ZhbjwvYT48YnI+DQo8Yj5D YyZuYnNwOzo8L2I+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtZGltZS1kcm1wQGll dGYub3JnIiB0YXJnZXQ9Il9wYXJlbnQiPmRyYWZ0LWlldGYtZGltZS1kcm1wQGlldGYub3JnPC9h PiwNCjxhIGhyZWY9Im1haWx0bzphYW1lbG5pa292QGZhc3RtYWlsLmZtIiB0YXJnZXQ9Il9wYXJl bnQiPkFsZXhleSBNZWxuaWtvdjwvYT4sIDxhIGhyZWY9Im1haWx0bzpkaW1lLWNoYWlyc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfcGFyZW50Ij4NCmRpbWUtY2hhaXJzQGlldGYub3JnPC9hPiwgPGEgaHJl Zj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciIHRhcmdldD0iX3BhcmVudCI+ZGltZUBpZXRmLm9yZzwv YT4sDQo8YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfcGFyZW50Ij5pZXNn QGlldGYub3JnPC9hPjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXYgZGlyPSIiPg0KPGRpdiBpZD0icmVhZGluZ1BhbmVCb2R5Q29udGVudCI+U2VlIGJlbG93Ljxi cj4NCjxicj4NCiZndDsgQW0gMTAuMDUuMjAxNiB1bSAxNzowNCBzY2hyaWViIFN0ZXZlIERvbm92 YW4gJmx0O3NyZG9ub3ZhbkB1c2Rvbm92YW5zLmNvbSZndDs6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IE1pcmphLDxicj4NCiZndDsgPGJyPg0KJmd0OyBQbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGlubGlu ZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgU3Rl dmU8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gNS8xMC8xNiA5OjQ2IEFNLCBNaXJqYSBLdWVobGV3 aW5kIChJRVRGKSB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBIaSBhbGwsPGJyPg0KJmd0OyZndDsgPGJy Pg0KJmd0OyZndDsgc29ycnkgZm9yIG15IGxhdGUgcmVwbHkuPGJyPg0KJmd0OyZndDsgPGJyPg0K Jmd0OyZndDsgSSB0aGluayB0aGUgcGFydCB3aXRoIHRoZSB0d28gcXVldWVzIHdhcyBhIGxpdHRs ZSBjb25mdXNpbmcuIFNvcnJ5IGZvciB0aGF0IGFzIHdlbGwuIEkgb3JpZ2luYWxseSBtZWFudCB0 byBkZXNjcmliZSB0aGlzIHRvIGlsbHVzdHJhdGUgdGhlIHByb2JsZW0gcmF0aGVyIHRoYW4gZGVz Y3JpYmluZyBhIHNvbHV0aW9uLiBIb3dldmVyLCB1c2luZyB0d28gcXVldWVzICh3aGljaCBmdWxs eSBpcyBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwpIGRvZXMNCiBub3QgZXZlbiBtYXRjaCB0aGUg cHJvYmxlbSBjb3JyZWN0bHkgdGhhdCBJIHdhbnRlZCB0byBkZXNjcmliZeKApiB0aGUgYWN0dWFs bHkgcG9pbnQgd291bGQgYmUgYWJvdXQgdGhlIHNjaGVkdWxpbmcgdGhhdCBvbmUgd291bGQgbmVl ZCB0byBpbXBsZW1lbnQgdG8gc2VydmUgdGhlIHF1ZXVlcy4gSGVyZSBteSB0aGlua2luZyB3YXMg dGhhdCwgaW5zdGVhZCBvZiBpbXBsZW1lbnRpbmcgYSBzdHJpY3QgcHJpb3JpdHkgc2NoZWR1bGlu ZywgeW91IGNvdWxkDQogYWxzbyBpbXBsZW1lbnQgYSBzY2hlbWUgdGhhdCBndWFyYW50ZWVzIGEg Y2VydGFpbiBtaW5pbXVtIHNlcnZpbmcgcmF0ZSBmb3IgdGhlIG5vbi1wcmlvcml0eS1kZWZpbmVk IHJlcXVlc3RzIHRvIGF2b2lkIGZ1bGwgc3RhcnZhdGlvbi4gSG93ZXZlciwgSSBkb27igJl0IHdh bnQgdG8gY29uZnVzZSB5b3UgZXZlbiBtb3JlIGhlcmUuIFNvIGxldCBtZSB0cnkgdG8gcGhhc2Ug bXkgY29uY2VybiBhZ2FpbiAoSeKAmXZlIGFsc28gZWRpdGVkIG15IGRpc2N1c3MNCiB0ZXh0KTo8 YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBJIGRvbuKAmXQgdGhpbmsgaXQgaXMgYSBnb29k IGlkZWEgdG8gYXNzaWduIGEgZGVmYXVsdCBwcmlvcml0eSB0byBub24tcHJpb3JpdHktZGVmaW5l ZCByZXF1ZXN0cyBhdCBhbGwuIElmIHlvdSBoYXZlIGhpZ2ggcHJpb3JpdHkgdHJhZmZpYyB0aGF0 IGRvZXMgbm90IHN1cHBvcnQgdGhpcyBleHRlbnNpb24gKHlldCkgdGhpcyB0cmFmZmljIGNvdWxk IGJlIHN0YXJ2ZWQgYnkgbG93ZXIgcHJpb3JpdHkgdHJhZmZpYyB3aGVuIGFzc2lnbmluZyBhIG1p ZGRsZQ0KIHJhbmdlIHByaW9yaXR5LiBJIGRvbuKAmXQgdGhpbmsgdGhhdCBpcyB3aGF0IHlvdSB3 YW50IHRvIGFjaGlldmUuPGJyPg0KJmd0OyBTUkQmZ3Q7IEFjdHVhbGx5LCB0aGlzIGlzIHdoYXQg d2Ugd2FudCB0byBhY2hpZXZlLiZuYnNwOyBJdCBpcyBhbiByZXF1aXJlbWVudCB0aGF0IG1lc3Nh Z2VzIGV4cGxpY2l0bHkgbWFya2VkIGFzIGhpZ2ggcHJpb3JpdHkgZ2V0IHRyZWF0ZWQgZXZlbiBp ZiBpdCByZXN1bHRzIGluIHN0YXJ2aW5nIGxvd2VyIHByaW9yaXR5IG1lc3NhZ2VzLiZuYnNwOyBU aGUgc3RhcnZpbmcgb2YgbG93ZXIgcHJpb3JpdHkgbWVzc2FnZXMgaXMgbm90IGFuIHByb2JsZW0s IGl0IGlzIGENCiByZXF1aXJlbWVudC48YnI+DQo8YnI+DQpJIHRoaW5rIHdlIGFyZSBzdGlsbCB0 YWxraW5nIHBhc3QgZWFjaCBvdGhlci4gSWYgeW91IGV4cGxpY2l0bHkgYXNzaWduIGEgcHJpb3Jp dHksIHN0YXJ2YXRpb24gbWlnaHQgYmUgb2theS4gSG93ZXZlciwgaWYgeW91IGRvbuKAmXQgaGF2 ZSBhIHByaW9yaXR5IGV4cGxpY2l0bHkgc2lnbmFsZWQsIHRoZSB0cmFuc2FjdGlvbiBtaWdodCBo YXZlIGEgdmVyeSBoaWdoIHByaW9yaXR5IGJ1dCB5b3UganVzdCBkb27igJl0IGtub3cgYW5kIGJ5 IGFzc2lnbmluZw0KIGEgcmFuZG9tIG1pZC1yYW5nZSBwcmlvcml0eSB0aGlzIGltcG9ydGFudCBy ZXF1ZXN0IGNvdWxkIGdldCBzdGFydmVkLjxicj4NCjxicj4NCk1pcmphPGJyPg0KPGJyPg0KPGJy Pg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgSSB0aGluayB0aGlzIHBvaW50IGlzIGV2ZW4gbW9y ZSB0cnVlIHdpdGggcmVzcGVjdCB0byB0aGUgZGlzY3Vzc2lvbiB0aGF0IHdlbnQgb24gd2l0aCBB bGlzc2EgYW5kIEJlbi4gVGhlcmUsIHlvdSBzYWlkLCB5b3XigJlkIG5lZWQgdG8gZGVmaW5lIGEg cHJpb3JpdHkgc2NoZW1lIGZvciBhIGNlcnRhaW4gYXBwbGljYXRpb24gYmVmb3JlIHlvdSBjb3Vs ZCB1c2UgaXQuIEdpdmVuIHRoYXQgaXQgZG9lcyBub3QgbWFrZSBzZW5zZSB0byBkZWZpbmUgYQ0K IGRlZmF1bHQgcHJpb3JpdHkgdmFsdWUgdG8gZm9yIGFsbCB1c2VzIGJlY2F1c2UgZGVwZW5kaW5n IG9mIHdpdGggcHJpb3JpdHkgcmFuZ2UgeW91IHNlbGVjdCB0byB1c2UgaW4geW91ciBzY2hlbWUs IHRoZSBkZWZhdWx0IG1pZ2h0IGJlIGEgbG93LCBoaWdoLCBvciBtaWRyYW5nZSB2YWx1ZS48YnI+ DQomZ3Q7IFNSRCZndDsgSSBkb24ndCB1bmRlcnN0YW5kIHRoZSBzdGF0ZW1lbnQgdGhhdCBpdCBk b2Vzbid0IG1ha2VzIHNlbnNlIHRvIGRlZmluZSBhIGRlZmF1bHQgcHJpb3JpdHkgdmFsdWUuJm5i c3A7IFdoZW4gZGVmaW5pbmcgYSBwcmlvcml0eSBzY2hlbWUvcHJvZmlsZSB0byBiZSB1c2VkIHdp dGhpbiBhIERpYW1ldGVyIG5ldHdvcmssIGFsbCBhcHBsaWNhdGlvbnMgd2lsbCBuZWVkIHRvIHRh a2UgdGhlICZxdW90O3VuaXZlcnNhbCZxdW90OyBkZWZhdWx0IHZhbHVlIGludG8gY29uc2lkZXJh dGlvbi4mbmJzcDsNCiBUaGF0IGRlZmF1bHQgdmFsdWUgd2lsbCB0aGVuIGJlIHVzZWQgaW4gdGhl IGhhbmRsaW5nIG9mIHJlcXVlc3RzIHdoZXJlIGVpdGhlciB0aGUgYXBwbGljYXRpb24gZG9lcyBu b3QgeWV0IGhhdmUgYSBkZWZpbmVkIHByaW9yaXR5IHNjaGVtZSBvciB3aGVuIHRoZSBub2RlIG9y aWdpbmF0aW5nIHRoZSBtZXNzYWdlcyBkb2VzIG5vdCB5ZXQgc3VwcG9ydCB0aGUgYXBwbGljYXRp b25zIHByaW9yaXR5IHNjaGVtZS48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBUbyBtYWtl IGl0IGV2ZW4gbW9yZSBjbGVhciBJIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSB0aGUgZm9sbG93aW5n IHRleHQgY2hhbmdlIGluIHRoZSBkb2M6PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgT0xE Ojxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERpYW1ldGVyIG5vZGVzIE1VU1QgaGF2 ZSBhIGRlZmF1bHQgcHJpb3JpdHkgdG8gYXBwbHkgdG8gdHJhbnNhY3Rpb25zPGJyPg0KJmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhhdCBkbyBub3QgaGF2ZSBhbiBleHBsaWNpdCBwcmlvcml0 eSBzZXQgaW4gdGhlIERSTVAgQVZQLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IERpYW1ldGVyIG5vZGVzIFNIT1VMRCB1c2UgdGhlIFBSSU9SSVRZXzEwIHBy aW9yaXR5IGFzIHRoaXMgZGVmYXVsdDxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHZh bHVlLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IE5FVzo8YnI+DQomZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyBEaWFtZXRlciBub2RlcyBNQVkgc2V0IGEgZGVmYXVsdCBwcmlvcml0eSB0 byBhcHBseSB0byB0cmFuc2FjdGlvbnM8YnI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB0 aGF0IGRvIG5vdCBoYXZlIGFuIGV4cGxpY2l0IHByaW9yaXR5IHNldCBpbiB0aGUgRFJNUCBBVlAg aWYgaXQgaXM8YnI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBrbm93biB0aGF0IHRoZSB0 cmFuc2FjdGlvbnMgdGhhdCBkZWZpbmUgYSBoaWdoZXIgcHJpb3JpdHkgdGhhbiB0aGUgZGVmYXVs dDxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFyZSBhbHdheXMgaGlnaGVyIHByaW9y aXR5IHRoYW4gdGhlIHRyYW5zYWN0aW9ucyB0aGF0IGRvIG5vdCBkZWZpbmU8YnI+DQomZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyBhIHByaW9yaXR5IGV4cGxpY2l0bHkuIFRoZSBkZWZhdWx0IHZh bHVlIHdpbGwgZGVwZW5kIG9uIHRoZSB1c2VkIHByaW9yaXR5PGJyPg0KJmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsgcmFuZ2UgaW4gYSBnaXZlbiBkZXBsb3ltZW50IHNldHVwLjxicj4NCiZndDsg U1JEJmd0OyBPbmUgb2YgdGhlIGdvYWxzIG9mIHRoZSBkZWZhdWx0IHByaW9yaXR5IHZhbHVlIGlz IHRvIGtlZXAgbm9kZXMgbGlrZSBEaWFtZXRlciByZWxheXMgZnJvbSBuZWVkaW5nIHRvIHVuZGVy c3RhbmQgYXBwbGljYXRpb24gc2VtYW50aWNzLiZuYnNwOyBUaGlzIHJlcXVpcmVtZW50IHdvdWxk IGJyZWFrIHRob3NlIERpYW1ldGVyIHJlbGF5cyBhcyBhcHBsaWNhdGlvbiBsZXZlbCBrbm93bGVk Z2UgaXMgcmVxdWlyZWQgdG8ga25vdyBpZiBhIG1lc3NhZ2UNCiB3aXRob3V0IGFuIGV4cGxpY2l0 IHByaW9yaXR5IHZhbHVlIGlzIG9mIGEgaGlnaGVyIHByaW9yaXR5Ljxicj4NCiZndDsgPGJyPg0K Jmd0OyBTUkQmZ3Q7IEluIGFkZGl0aW9uLCB0aGVyZSBpcyBvbmx5IG9uZSBwcmlvcml0eSByYW5n ZSwgYXMgZGVmaW5lZCBpbiB0aGUgZG9jdW1lbnQuJm5ic3A7IEl0IGlzIGltcG9ydGFudCB0aGF0 IHRoZSByYW5nZSBiZSB0aGUgc2FtZSBhY3Jvc3MgYWxsIGFwcGxpY2F0aW9ucyBmb3IgdGhlIG1l Y2hhbmlzbSB0byB3b3JrLCBlc3BlY2lhbGx5IGluIG5vZGVzIGhhbmRsaW5nIG1lc3NhZ2VzIGZv ciBtdWx0aXBsZSBhcHBsaWNhdGlvbnMuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsgRGlhbWV0ZXIgbm9kZSBTSE9VTEQgbm90IGFzc2lnbjxicj4NCiZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGEgZGVmYXVsdCBwcmlvcml0eSBpZiBubyBhZGRpdGlvbmFs IGluZm9ybWF0aW9uIGFib3V0IHRoZSB0cmFuc2FjdGlvbjxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHRoYXQgZG8gbm90IGRlZmluZSBhbiBleHBsaWNpdCBwcmlvcml0eSBpcyBrbm93 bi4gSW4gdGhpcyBjYXNlIHRoZTxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRpYW1l dGVyIG5vZGUgU0hPVUxEIHByb3ZpZGUgYSBtaW5pbXVtIHNlcnZpbmcgcmF0ZSBmb3IgdHJhbnNh Y3Rpb24gdGhhdCBkbzxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vdCBkZWZpbmUg YW4gZXhwbGljaXQgcHJpb3JpdHkgdG8gYXZvaWQgZnVsbCBzdGFydmF0aW9uIG9mIHRoZXNlPGJy Pg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgdHJhbnNhY3Rpb25zIHRoZSBtYXkgb3IgbWF5 IG5vdCBoYXZlIGEgaGlnaGVyIHByaW9yaXR5IHRoYW4gb3RoZXI8YnI+DQomZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyB0cmFuc2FjdGlvbnMgdGhhdCBwcm92aWRlIGluZm9ybWF0aW9uIGFib3V0 IHRoZWlyIHByaW9yaXR5Ljxicj4NCiZndDsgU1JEJmd0OyBUaGlzIGlzIGV4cGxpY2l0bHkgTk9U IGEgcmVxdWlyZW1lbnQuJm5ic3A7IEl0IGlzIGFjY2VwdGFibGUgdG8gc3RhcnZlIGxvd2VyIHBy aW9yaXR5IG1lc3NhZ2VzLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEkgaG9wZSB0aGF0 IG1ha2VzIHNlbnNlIHRvIHlvdS4gUGxlYXNlIHByb3Bvc2UgZWRpdHMgKGlmIG5vdCkhPGJyPg0K Jmd0OyBTUkQmZ3Q7IEkgZG9uJ3QgeWV0IHNlZSBhIHJlYXNvbiB0byBjaGFuZ2UgdGhlIG9yaWdp bmFsIHdvcmRpbmcuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgTWlyamE8YnI+DQomZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZuYnNwOyA8YnI+DQomZ3Q7Jmd0OyZndDsgQW0gMDUuMDUuMjAx NiB1bSAwODozMiBzY2hyaWViIEFsZXhleSBNZWxuaWtvdiAmbHQ7YWFtZWxuaWtvdkBmYXN0bWFp bC5mbSZndDs6PGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBIaSBNaXJqYSw8 YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IE9uIFdlZCwgTWF5IDQsIDIwMTYs IGF0IDA0OjUwIFBNLCBNaXJqYSBLdWVobGV3aW5kIChJRVRGKSB3cm90ZTo8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IEhpIEphbmV0LDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyB0aGVyZSBhcmUgY2xlYXJseSBtb3JlIG9wdGlvbnMgdGhhbiB0aGUgdHdvIG1lbnRp b24gYmVsb3cuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEUu Zy4gb25lIG9wdGlvbiBpcyB0aGUgb25lIGV4cGxhaW5lZCBpbiBteSBpbml0aWFsIGNvbW1lbnQ6 IGhoYXZpbmcgdHdvPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBxdWV1ZXMsIHRoYXQgYXJlIGJvdGgg c2VydmVkIHdpdGggYSBjZXJ0YWluIHJhdGUuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7IEnigJltIHN1cmUgdGhlcmUgYXJlIG1vcmUgKGFuZCBwb3RlbnRpYWxs eSBtb3JlIGNvbXBsZXgpIHNvbHV0aW9ucyB0byB0aGlzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBw cm9ibGVtIGFzIHdlbGwuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IEFzc2lnbmluZyBhbiBhcmJpdHJhcnkgcHJpb3JpdHkgaXMgbm90IHRoZSByaWdodCBvcHRp b24gZnJvbSBteSBwb2ludCBvZjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgdmlldyBhbmQgY2FuIGFj dHVhbGx5IGh1cnQgdGhlIHN5c3RlbXMuPGJyPg0KJmd0OyZndDsmZ3Q7IEkgaG9wZSB0aGlzIHdp bGwgaGVscCB0byBjbGFyaWZ5IHRoaW5nczo8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZn dDsmZ3Q7IE9uZSBwb2ludCBvZiBhc3NpZ25pbmcgZGVmYXVsdCBwcmlvcml0eSBpcyB0aGF0IGFz IHRoaXMgaXMgYW4gZXh0ZW5zaW9uLDxicj4NCiZndDsmZ3Q7Jmd0OyB0aGVyZSBpcyBhIGRlc2ly ZSB0byBhdm9pZCB1cGdyYWRpbmcgYWxsIGNsaWVudHMgb24gdGhlIG5ldHdvcmssIGFzIHRoYXQ8 YnI+DQomZ3Q7Jmd0OyZndDsgd291bGQgYmUgZWZmZWN0aXZlbHkgdHJ5aW5nIHRvIGRlcGxveSBh IG5ldyBwcm90b2NvbC4gQ29uc2lkZXIgYSBuZXR3b3JrPGJyPg0KJmd0OyZndDsmZ3Q7IHdoZXJl IHByb3hpZXMgYW5kIHNlcnZlcnMgdW5kZXJzdGFuZCB0aGlzIGV4dGVuc2lvbiBhbmQgbm9uZSBv ZiB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsgY2xpZW50cyBkby4gVGhlbiBkZWZhdWx0IHByaW9yaXR5 IHdvdWxkIGJlIGFzc2lnbmVkIHRvIGFsbCB0cmFmZmljIGFuZDxicj4NCiZndDsmZ3Q7Jmd0OyB0 aGUgYmVoYXZpb3VyIG9mIHRoZSBzeXN0ZW0gaXMgdW5jaGFuZ2VkIGZyb20gdGhlIGNhc2Ugd2hl biB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsgZXh0ZW5zaW9uIGlzIG5vdCBkZXBsb3llZC4gVGhlIGRl ZmF1bHQgcHJpb3JpdHkgb25seSBtYWtlcyBhIGRpZmZlcmVuY2U8YnI+DQomZ3Q7Jmd0OyZndDsg aWYgdGhlcmUgaXMgYSBtaXh0dXJlIG9mIGNsaWVudHMgaW1wbGVtZW50aW5nIHRoaXMgZXh0ZW5z aW9uIGFuZCBjbGllbnRzPGJyPg0KJmd0OyZndDsmZ3Q7IHRoYXQgZG9uJ3QuPGJyPg0KJmd0OyZn dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBCZXN0IFJlZ2FyZHMsPGJyPg0KJmd0OyZndDsmZ3Q7 IEFsZXhleTxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IE1pcmphPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEFtIDA0LjA1LjIwMTYgdW0gMTc6NDUgc2NocmllYiBHdW5uLCBKYW5ldCBQ ICZsdDtKYW5ldC5HdW5uQGNzcmEuY29tJmd0Ozo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNeSBjb21tZW50IGJlbG93Ljxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEphbmV0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgTWlyamEgS3VlaGxld2luZCAoSUVURik8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBTZW50OiBXZWRuZXNkYXksIE1heSAwNCwgMjAxNiAxMDozMSBBTTxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IFRvOiBBbGV4ZXkgTWVsbmlrb3YgJmx0O2FhbWVsbmlrb3ZAZmFzdG1haWwuZm0m Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2M6IGRyYWZ0LWlldGYtZGltZS1kcm1wQGll dGYub3JnOyBkaW1lLWNoYWlyc0BpZXRmLm9yZzsgZGltZUBpZXRmLm9yZzsgVGhlIElFU0cgJmx0 O2llc2dAaWV0Zi5vcmcmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6 IFtEaW1lXSBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRpbWUtZHJt cC0wNTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIaSBBbGV4ZXksPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VlIGJlbG93Ljxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBwb2ludCBpcywg aWYgeW91IGV4cGxpY2l0bHkgaW5kaWNhdGUgdGhhdCB5b3UgaGF2ZSBhIGxvd2VyIHByaW9yaXR5 LCB5b3UgYXJlIG9rYXkgdG8gYmUgc3RhcnZlZC4gSG93ZXZlciwgaWYgeW91IGRvbuKAmXQgaW5k aWNhdGUgYW55dGhpbmcgKG1heWJlIGp1c3QgYmVjYXVzZSB5b3UgaGF2ZSBub3QgYmVlbiBhd2Fy ZSB0aGF0IGl0IGlzIHBvc3NpYmxlIHRvIGRvIHNvKSwgeW91IG1pZ2h0IGhhdmUgdGhlIHNhbWUg b3IgZXZlbiBhIGhpZ2hlcg0KIHByaW9yaXR5LCBhbmQgaW4gdGhpcyBjYXNlIGl04oCZcyBub3Qg b2theSB0byBiZSBzdGFydmVkLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IE1pcmphPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0O0pQRyZn dDsgSWYgYSBtZXNzYWdlIGNvbWVzIGluIHdpdGhvdXQgYSBwcmlvcml0eSwgaW50byBhIHN5c3Rl bSB3aGljaCBzZXJ2ZXMgbWVzc2FnZXMgYmFzZWQgb24gcHJpb3JpdHkgKHJlZ2FyZGxlc3Mgb2Yg dGhlIHNwZWNpZmljIG1lY2hhbmlzbXMpeW91IGhhdmUgdHdvIG9wdGlvbnM8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAxLSBEaXNjYXJkIHRoZSBtZXNzYWdlIChOb3QgYSBnb29kIGlkZWEgaW4g bW9zdCBzeXN0ZW1zKTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIgLSBBc3NpZ24gdGhlIG1l c3NhZ2UgYW4gQVJCSVRSQVJZIHByaW9yaXR5ICh3ZSBjYWxsIHRoaXMgYXJiaXRyYXJ5IHZhbHVl IHRoZSAmcXVvdDtkZWZhdWx0IHByaW9yaXR5JnF1b3Q7KTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFlvdSBjYW4gKGFuZCBwcm9iYWJseSB3aWxs KSBhcmd1ZSAndGlsIHRoZSBjb3dzIGNvbWUgaG9tZSBvbiB3aGF0IHRoYXQgYXJiaXRyYXJ5L2Rl ZmF1bHQgdmFsdWUgU0hPVUxEIEJFLiZuYnNwOyBBbmQgZGlmZmVyZW50IHN5dGVtcy9hcHBsaWNh dGlvbnMgbWlnaHQgaGF2ZSBkaWZmZXJlbnQgJnF1b3Q7ZGVmYXVsdCB2YWx1ZXMmcXVvdDsuPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQnV0IEkg ZG9uJ3QgdGhpbmsgdGhlcmUgc2hvdWxkIGJlIGFueSBhcmd1bWVudCB0aGF0LCBpZiBhIG1lc3Nh Z2UgY29tZXMgaW4gd2l0aG91dCBhIHByaW9yaXR5LCB5b3UgbmVlZCB0byBhc3NpZ24gaXQgYSBw cmlvcml0eS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAmbHQ7L0pQRyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IERpTUUgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgRGlNRUBpZXRmLm9yZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZTxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoaXMgZWxlY3Ryb25pYyBtZXNz YWdlIHRyYW5zbWlzc2lvbiBjb250YWlucyBpbmZvcm1hdGlvbiBmcm9tIENTUkEgdGhhdCBtYXkg YmUgYXR0b3JuZXktY2xpZW50IHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5IG9yIGNvbmZpZGVudGlh bC4gVGhlIGluZm9ybWF0aW9uIGluIHRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBvbmx5IGZvciB1 c2UgYnkgdGhlIGluZGl2aWR1YWwocykgdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBi ZWxpZXZlDQogeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ug Y29udGFjdCBtZSBpbW1lZGlhdGVseSBhbmQgYmUgYXdhcmUgdGhhdCBhbnkgdXNlLCBkaXNjbG9z dXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNz YWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwg dGhpcyBlbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0byBiaW5kDQogQ1NSQSB0byBhbnkgb3JkZXIg b3Igb3RoZXIgY29udHJhY3QgdW5sZXNzIHB1cnN1YW50IHRvIGV4cGxpY2l0IHdyaXR0ZW4gYWdy ZWVtZW50IG9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSBleHByZXNzbHkgcGVybWl0dGluZyB0aGUg dXNlIG9mIGVtYWlsIGZvciBzdWNoIHB1cnBvc2UuPGJyPg0KJmd0OyA8YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkRpTUUgbWFp bGluZyBsaXN0PGJyPg0KRGlNRUBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZGltZTxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBk ZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p dmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBs ZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2Nl cHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRl IHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4K ClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7 CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBh dXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6B7134B31289DC4FAF731D844122B36E01E5F82FOPEXCLILM43corp_-- From nobody Tue May 10 19:55: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 2D5EF12D0BD for ; Tue, 10 May 2016 19:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 bhKjMVZSB7iU for ; Tue, 10 May 2016 19:54:59 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30EDC12B02A for ; Tue, 10 May 2016 19:54:58 -0700 (PDT) Received: (qmail 27804 invoked from network); 11 May 2016 04:47:33 +0200 Received: from 70-91-193-41-busname-newengland.hfc.comcastbusiness.net (HELO ?192.168.15.199?) (70.91.193.41) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 11 May 2016 04:47:32 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <10389_1462926852_57327E03_10389_3007_1_6B7134B31289DC4FAF731D844122B36E01E5F82F@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Tue, 10 May 2016 22:47:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> <57324CE8.6040109@usdonovans.com> <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net> <10389_1462926852_57327E03_10389_3007_1_6B7134B31289DC4FAF731D844122B36E01E5F82F@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Alexey Melnikov , "draft-ietf-dime-drmp@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , "iesg@ietf.org" Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 11 May 2016 02:55:01 -0000 Hi Lionel, all you say makes much more sense to me, however, it is not well = reflected in the doc. See further below. > Am 10.05.2016 um 20:34 schrieb lionel.morand@orange.com: >=20 > Hi Mirja, >=20 > I think that we need to go back to the initial requirement. > Today, it is not possible to give a priority handling to any Diameter = message, except if there is an explicit handling defined by the = application using the commands or by operator policies and this specific = handling can only be applied by clients, proxies and servers, not by = relays. >=20 > With the proposed solution, it is possible to include a explicit = priority indication in Diameter messages that can be used by any node, = whatever the type, as soon as they are upgraded to support this priority = mechanism. >=20 > Now, in heteregenous networks, it is required to handle any type of = message, with or without priority indication. Messages without priority = indication will be handled as today, without any specific priority = handling except defined otherwise (as described above).=20 This should be stated moe clearly in the doc. >=20 > In this context, defining a default priority handling for the messages = without explicit priority indication makes sense. If it is required that = some messages have a higher priority handling, it will be required to = upgrade the clients to enable them to include the priority indication. = Otherwise, it will be understood that these messages could be = deprioritized compared to others with explicit priority indication. Not fully sure here because if you don=E2=80=99t know that this = extension exists, how can you =E2=80=9E[understand] that these messages = could be reprioritized=E2=80=9C? >=20 > Moreover, the priority handling will be applied ONLY when needed, when = not all the messages can be handled. So, in normal situation, no = difference will be made between messages with or without priority = indication. And when required to prioritize the messages, it is normal = to take into account =E2=80=9Cin priority=E2=80=9D the priority = indication included in the messages when available. Messages with = priority indication will be handled with a best-effort approach when = nothing else is defined (by application or operator policy). Yes, you can and should take the priority indication into account but = you still should not completely starve traffic that does not have a = priority indication. >=20 > For the record, the value 10 is not =E2=80=9Cassigned=E2=80=9D to = message without priority indication. The node receiving these messages = will behave as if the messages include a priority indication set to the = value 10. Okay, that is also not stated super clearly but important. And this = still does not give an argument for specifying a random default value in = this doc=E2=80=A6 Why is it important that all nodes apply the same = default priority handling? Mirja >=20 > Regards, >=20 > Lionel >=20 > Envoy=C3=A9 depuis Surface >=20 > De : Mirja Kuehlewind (IETF) > Envoy=C3=A9 : =E2=80=8Emercredi=E2=80=8E =E2=80=8E11=E2=80=8E = =E2=80=8Emai=E2=80=8E =E2=80=8E2016 =E2=80=8E00=E2=80=8E:=E2=80=8E01 > =C3=80 : Steve Donovan > Cc : draft-ietf-dime-drmp@ietf.org, Alexey Melnikov, = dime-chairs@ietf.org, dime@ietf.org, iesg@ietf.org >=20 > See below. >=20 > > Am 10.05.2016 um 17:04 schrieb Steve Donovan = : > >=20 > > Mirja, > >=20 > > Please see my comments inline. > >=20 > > Regards, > >=20 > > Steve > >=20 > > On 5/10/16 9:46 AM, Mirja Kuehlewind (IETF) wrote: > >> Hi all, > >>=20 > >> sorry for my late reply. > >>=20 > >> I think the part with the two queues was a little confusing. Sorry = for that as well. I originally meant to describe this to illustrate the = problem rather than describing a solution. However, using two queues = (which fully is an implementation detail) does not even match the = problem correctly that I wanted to describe=E2=80=A6 the actually point = would be about the scheduling that one would need to implement to serve = the queues. Here my thinking was that, instead of implementing a strict = priority scheduling, you could also implement a scheme that guarantees a = certain minimum serving rate for the non-priority-defined requests to = avoid full starvation. However, I don=E2=80=99t want to confuse you even = more here. So let me try to phase my concern again (I=E2=80=99ve also = edited my discuss text): > >>=20 > >> I don=E2=80=99t think it is a good idea to assign a default = priority to non-priority-defined requests at all. If you have high = priority traffic that does not support this extension (yet) this traffic = could be starved by lower priority traffic when assigning a middle range = priority. I don=E2=80=99t think that is what you want to achieve. > > SRD> Actually, this is what we want to achieve. It is an = requirement that messages explicitly marked as high priority get treated = even if it results in starving lower priority messages. The starving of = lower priority messages is not an problem, it is a requirement. >=20 > I think we are still talking past each other. If you explicitly assign = a priority, starvation might be okay. However, if you don=E2=80=99t have = a priority explicitly signaled, the transaction might have a very high = priority but you just don=E2=80=99t know and by assigning a random = mid-range priority this important request could get starved. >=20 > Mirja >=20 >=20 > >>=20 > >> I think this point is even more true with respect to the discussion = that went on with Alissa and Ben. There, you said, you=E2=80=99d need to = define a priority scheme for a certain application before you could use = it. Given that it does not make sense to define a default priority value = to for all uses because depending of with priority range you select to = use in your scheme, the default might be a low, high, or midrange value. > > SRD> I don't understand the statement that it doesn't makes sense to = define a default priority value. When defining a priority = scheme/profile to be used within a Diameter network, all applications = will need to take the "universal" default value into consideration. = That default value will then be used in the handling of requests where = either the application does not yet have a defined priority scheme or = when the node originating the messages does not yet support the = applications priority scheme. > >>=20 > >> To make it even more clear I would like to propose the following = text change in the doc: > >>=20 > >> OLD: > >> Diameter nodes MUST have a default priority to apply to = transactions > >> that do not have an explicit priority set in the DRMP AVP. > >>=20 > >> Diameter nodes SHOULD use the PRIORITY_10 priority as this = default > >> value. > >>=20 > >> NEW: > >> Diameter nodes MAY set a default priority to apply to = transactions > >> that do not have an explicit priority set in the DRMP AVP if it = is > >> known that the transactions that define a higher priority than = the default > >> are always higher priority than the transactions that do not = define > >> a priority explicitly. The default value will depend on the used = priority > >> range in a given deployment setup. > > SRD> One of the goals of the default priority value is to keep nodes = like Diameter relays from needing to understand application semantics. = This requirement would break those Diameter relays as application level = knowledge is required to know if a message without an explicit priority = value is of a higher priority. > >=20 > > SRD> In addition, there is only one priority range, as defined in = the document. It is important that the range be the same across all = applications for the mechanism to work, especially in nodes handling = messages for multiple applications. > >>=20 > >> Diameter node SHOULD not assign > >> a default priority if no additional information about the = transaction > >> that do not define an explicit priority is known. In this case = the > >> diameter node SHOULD provide a minimum serving rate for = transaction that do > >> not define an explicit priority to avoid full starvation of = these > >> transactions the may or may not have a higher priority than = other > >> transactions that provide information about their priority. > > SRD> This is explicitly NOT a requirement. It is acceptable to = starve lower priority messages. > >>=20 > >> I hope that makes sense to you. Please propose edits (if not)! > > SRD> I don't yet see a reason to change the original wording. > >>=20 > >> Mirja > >>=20 > >> =20 > >>> Am 05.05.2016 um 08:32 schrieb Alexey Melnikov = : > >>>=20 > >>> Hi Mirja, > >>>=20 > >>> On Wed, May 4, 2016, at 04:50 PM, Mirja Kuehlewind (IETF) wrote: > >>>> Hi Janet, > >>>>=20 > >>>> there are clearly more options than the two mention below. > >>>>=20 > >>>> E.g. one option is the one explained in my initial comment: = hhaving two > >>>> queues, that are both served with a certain rate. > >>>>=20 > >>>> I=E2=80=99m sure there are more (and potentially more complex) = solutions to this > >>>> problem as well. > >>>>=20 > >>>> Assigning an arbitrary priority is not the right option from my = point of > >>>> view and can actually hurt the systems. > >>> I hope this will help to clarify things: > >>>=20 > >>> One point of assigning default priority is that as this is an = extension, > >>> there is a desire to avoid upgrading all clients on the network, = as that > >>> would be effectively trying to deploy a new protocol. Consider a = network > >>> where proxies and servers understand this extension and none of = the > >>> clients do. Then default priority would be assigned to all traffic = and > >>> the behaviour of the system is unchanged from the case when the > >>> extension is not deployed. The default priority only makes a = difference > >>> if there is a mixture of clients implementing this extension and = clients > >>> that don't. > >>>=20 > >>> Best Regards, > >>> Alexey > >>>=20 > >>>> Mirja > >>>>=20 > >>>>=20 > >>>>> Am 04.05.2016 um 17:45 schrieb Gunn, Janet P = : > >>>>>=20 > >>>>> My comment below. > >>>>> Janet > >>>>>=20 > >>>>> -----Original Message----- > >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Mirja = Kuehlewind (IETF) > >>>>> Sent: Wednesday, May 04, 2016 10:31 AM > >>>>> To: Alexey Melnikov > >>>>> Cc: draft-ietf-dime-drmp@ietf.org; dime-chairs@ietf.org; = dime@ietf.org; The IESG > >>>>> Subject: Re: [Dime] Mirja K=C3=BChlewind's Discuss on = draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) > >>>>>=20 > >>>>> Hi Alexey, > >>>>>=20 > >>>>> see below. > >>>>>=20 > >>>>> The point is, if you explicitly indicate that you have a lower = priority, you are okay to be starved. However, if you don=E2=80=99t = indicate anything (maybe just because you have not been aware that it is = possible to do so), you might have the same or even a higher priority, = and in this case it=E2=80=99s not okay to be starved. > >>>>>=20 > >>>>> Mirja > >>>>> If a message comes in without a priority, into a system = which serves messages based on priority (regardless of the specific = mechanisms)you have two options > >>>>> 1- Discard the message (Not a good idea in most systems) > >>>>> 2 - Assign the message an ARBITRARY priority (we call this = arbitrary value the "default priority") > >>>>>=20 > >>>>> You can (and probably will) argue 'til the cows come home on = what that arbitrary/default value SHOULD BE. And different = sytems/applications might have different "default values". > >>>>>=20 > >>>>> But I don't think there should be any argument that, if a = message comes in without a priority, you need to assign it a priority. > >>>>>=20 > >>>>> > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>> _______________________________________________ > >>>>> DiME mailing list > >>>>> DiME@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/dime > >>>>>=20 > >>>>> This electronic message transmission contains information from = CSRA that may be attorney-client privileged, proprietary or = confidential. The information 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 agreement or government initiative = expressly permitting the use of email for such purpose. > >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles 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 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 = delete 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 From nobody Wed May 11 03:51:54 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 43BC512D984 for ; Wed, 11 May 2016 03:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=PNjGzyAX; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=bKlMBYHP 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 VZ0PW4mAY2AS for ; Wed, 11 May 2016 03:51:51 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E66C12D664 for ; Wed, 11 May 2016 03:51:41 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1AE7520CA6 for ; Wed, 11 May 2016 06:46:30 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 11 May 2016 06:46:30 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=pMjHzWCbEhyVkAFTYWMiNilv6z0=; b=PNjGzy AXcBkWGWMSiaekptRj4WLZ/tyunBBR7a69tgSv1KBTvh3bYbciFYBk0nvujQgFwb PBN3dnWY464si01GNv6VYH5FRgJHIrQy2BbF5QmmdV1ySZceh9+cdqMIFGYJT49f sqBQM0P+3AJBAlF2cx/lYP3Gv7D8Mse+YMs40= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=pMjHzWCbEhyVkAF TYWMiNilv6z0=; b=bKlMBYHPAYbfA+wn3NT5vjbJUetKe5DjBY+uI2IQzvnHWj0 ctJysog5U94exigGg+U+Ujk/HrozkLscxw23lGJjfAxbP6FHN6HeRFH1ya57ZO6g RSBwzh++RmOs1dsjU0napResyZiPaQRcN9dGx3iWBK+6dcw0MhLCSvlQvDus= X-Sasl-enc: XPRs+k1qXT/Mme2Ld4DB3eNy5aF3tBKowqCpHBl0V4lP 1462963589 Received: from [10.0.0.58] (c-66-30-10-217.hsd1.ma.comcast.net [66.30.10.217]) by mail.messagingengine.com (Postfix) with ESMTPA id BE468680219; Wed, 11 May 2016 06:46:29 -0400 (EDT) Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Wed, 11 May 2016 06:52:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5F0F8E44-3B12-48F0-B0F1-00039A8F1D1F@fastmail.fm> References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> <57324CE8.6040109@usdonovans.com> <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net> <10389_1462926852_57327E03_10389_3007_1_6B7134B31289DC4FAF731D844122B36E01E5F82F@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: "Mirja Kuehlewind (IETF)" Archived-At: Cc: "draft-ietf-dime-drmp@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , "iesg@ietf.org" Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 11 May 2016 10:51:52 -0000 Hi Mirja, On 10 May 2016, at 22:47, Mirja Kuehlewind (IETF) wrot= e: >> Moreover, the priority handling will be applied ONLY when needed, when no= t all the messages can be handled. So, in normal situation, no difference wi= ll be made between messages with or without priority indication. And when re= quired to prioritize the messages, it is normal to take into account =93in p= riority=94 the priority indication included in the messages when available. M= essages with priority indication will be handled with a best-effort approach= when nothing else is defined (by application or operator policy). >=20 > Yes, you can and should take the priority indication into account but you s= till should not completely starve traffic that does not have a priority indi= cation. This can only happen where there is a flood of messages and when it does, th= is is by design. The whole point of this is that when a flood of messages ha= ppens, lower priority messages get less preferential treatment, as opposed t= o random messages (as it is now without this extension) getting less prefere= ntial treatment. >> For the record, the value 10 is not =93assigned=94 to message without pri= ority indication. The node receiving these messages will behave as if the me= ssages include a priority indication set to the value 10. >=20 > Okay, that is also not stated super clearly but important. And this still d= oes not give an argument for specifying a random default value in this doc=85= Why is it important that all nodes apply the same default priority handlin= g? Because one would want consistent behaviour across the whole system. Which l= ooks like a desired property. From nobody Wed May 11 04:02:08 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 6849512D66A for ; Wed, 11 May 2016 04:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=iGyuVGs/; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=SkcZGPi9 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 ADdlYCM7vrHA for ; Wed, 11 May 2016 04:02:06 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B36C012D9A7 for ; Wed, 11 May 2016 04:01:40 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A148B20BA5 for ; Wed, 11 May 2016 06:54:18 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 11 May 2016 06:54:18 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=+ByskY2yFz3qGlNgJcyhdHd9FV0=; b=iGyuVG s/sQvRU31TfexWV/O2ynlvN58tDrr8wXpMcfRSiPGDroOJ6zzuudUDdemUvyybWS JGMiUPHkTchcJt7DzOFJRqO/Q0IDsRryYT0BmUMn8DYJS7lo3j8pqQQgk4GpJjNZ OhxbAlHpo46d4G5MSav23TMSsTU7uNAF1lyCc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=+ByskY2yFz3qGlN gJcyhdHd9FV0=; b=SkcZGPi9dwhhtKNpzZ9tf6uHV90FTlnTzUN9BkBJ9I62oQb F/Br+CHAUHAoB/azIZW7qqdr8AlSUwcedEA0qoa3ej5eFm6a/Gx31HQxAAAn3Riu UcpAmdgOge+GhUVzT2XDg0rF3ba4JdU+RCrgauYy9OsmptLqi24wcYTrU0gw= X-Sasl-enc: H4umvkd/uPQtV4tk2q4PIOdzI2oMhTpZFnCdvxXO8XsG 1462964058 Received: from [10.0.0.58] (c-66-30-10-217.hsd1.ma.comcast.net [66.30.10.217]) by mail.messagingengine.com (Postfix) with ESMTPA id 4F81368021F; Wed, 11 May 2016 06:54:18 -0400 (EDT) Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13E238) In-Reply-To: <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net> Date: Wed, 11 May 2016 06:59:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> <57324CE8.6040109@usdonovans.com> <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net> To: "Mirja Kuehlewind (IETF)" Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 11 May 2016 11:02:07 -0000 Hi Mirja, On 10 May 2016, at 17:59, Mirja Kuehlewind (IETF) wrot= e: >>> I don=92t think it is a good idea to assign a default priority to non-pr= iority-defined requests at all. If you have high priority traffic that does n= ot support this extension (yet) this traffic could be starved by lower prior= ity traffic when assigning a middle range priority. I don=92t think that is w= hat you want to achieve. >> SRD> Actually, this is what we want to achieve. It is an requirement tha= t messages explicitly marked as high priority get treated even if it results= in starving lower priority messages. The starving of lower priority messag= es is not an problem, it is a requirement. >=20 > I think we are still talking past each other. Most definitely :-). > If you explicitly assign a priority, starvation might be okay. However, if= you don=92t have a priority explicitly signaled, the transaction might have= a very high priority So some agent in the system needs to decide that a transaction is important.= > but you just don=92t know and by assigning a random mid-range priority thi= s important request could get starved. Here I disagree with you, because the way to know that a transaction is impo= rtant is to upgrade client to explicitly assign high priority to it. So defa= ult priority is a backward compatibility mechanism, that would work for most= common cases. You seem to be suggesting that when this extension is deploye= d all clients need to be updated at the same time. This is not realistic. From nobody Wed May 11 04:07: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 DF21312D9BF for ; Wed, 11 May 2016 04:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 27NWoYz7GTbt for ; Wed, 11 May 2016 04:07:37 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 944F412D9BC for ; Wed, 11 May 2016 04:07:30 -0700 (PDT) Received: (qmail 24158 invoked from network); 11 May 2016 13:07:27 +0200 Received: from 70-91-193-41-busname-newengland.hfc.comcastbusiness.net (HELO ?192.168.15.199?) (70.91.193.41) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 11 May 2016 13:07:27 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Wed, 11 May 2016 07:07:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6EF5DC36-1BEF-47EE-BB3B-83BE5E115AE3@kuehlewind.net> References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> <57324CE8.6040109@usdonovans.com> <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net> To: Alexey Melnikov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 11 May 2016 11:07:40 -0000 Okay let me go for an example here and see if that can be a use case = that we are talking about. You have a system where some clients run a communication service for = emergency doctors as well as for firefighters and then there are also = =E2=80=9Anormal=E2=80=98 users that run some kind of communication = service. Now you actually have an emergency: some part of the system is down and = the number of request is high such that the system is overloaded. Both the emergency doctors have would have two different priority = classes, one for important message about instruction (what and where = people should do something) and one for communication between the = doctors/firefighters which has still higher priority than any other = communication of the other people (as you assume doctors and = firefighters are more responsible to not misuse this communication = channel). Now only the emergency doctors communication service was upgraded to use = this extension, but the firefighter=E2=80=99s administrations is just = too slow or they currently have not enough money because they have = specialized expensive hardware and software that is not easy to change. Is it okay in this situation that the private chat of two doctors about = their last ski-holidays starves requests to access the network to send = instructor message to the firefighters? (And how do i make sure that that all other other requests actually = select a lower priority than 10=E2=80=A6? But that=E2=80=99s a different = question=E2=80=A6) Mirja > Am 11.05.2016 um 06:59 schrieb Alexey Melnikov = : >=20 > Hi Mirja, >=20 > On 10 May 2016, at 17:59, Mirja Kuehlewind (IETF) = wrote: >=20 >>>> I don=E2=80=99t think it is a good idea to assign a default = priority to non-priority-defined requests at all. If you have high = priority traffic that does not support this extension (yet) this traffic = could be starved by lower priority traffic when assigning a middle range = priority. I don=E2=80=99t think that is what you want to achieve. >>> SRD> Actually, this is what we want to achieve. It is an = requirement that messages explicitly marked as high priority get treated = even if it results in starving lower priority messages. The starving of = lower priority messages is not an problem, it is a requirement. >>=20 >> I think we are still talking past each other. >=20 > Most definitely :-). >=20 >> If you explicitly assign a priority, starvation might be okay. = However, if you don=E2=80=99t have a priority explicitly signaled, the = transaction might have a very high priority >=20 > So some agent in the system needs to decide that a transaction is = important. >> but you just don=E2=80=99t know and by assigning a random mid-range = priority this important request could get starved. >=20 > Here I disagree with you, because the way to know that a transaction = is important is to upgrade client to explicitly assign high priority to = it. So default priority is a backward compatibility mechanism, that = would work for most common cases. You seem to be suggesting that when = this extension is deployed all clients need to be updated at the same = time. This is not realistic. >=20 >=20 From nobody Wed May 11 05:34:03 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 DB10612D680; Wed, 11 May 2016 05:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 xCkBzSbHp_LT; Wed, 11 May 2016 05:33:55 -0700 (PDT) Received: from mailport8.csra.com (mailport8.csra.com [131.131.97.26]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE6A12D17E; Wed, 11 May 2016 05:33:53 -0700 (PDT) Received: from csrrdu1exa035.corp.csra.com (HELO mail.csra.com) ([10.8.2.35]) by mailport8.csra.com with ESMTP/TLS/AES256-SHA; 11 May 2016 08:34:17 -0400 Received: from CSRRDU1EXM025.corp.csra.com (10.8.2.25) by CSRRDU1EXM028.corp.csra.com (10.8.2.28) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 11 May 2016 08:33:51 -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.1130.005; Wed, 11 May 2016 08:33:51 -0400 From: "Gunn, Janet P" To: "Mirja Kuehlewind (IETF)" , Alexey Melnikov Thread-Topic: =?utf-8?B?W0RpbWVdIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWll?= =?utf-8?Q?tf-dime-drmp-05:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHRpfX802HZewL1w0WTgzzKloaSGZ+o6eMAgAACTICAAATUAIAAKU2A///PyMCAAEZ/gIABWtQAgAgBNoCAAGSAaYAA7oIAgAACGAD//8/UMA== Date: Wed, 11 May 2016 12:33:51 +0000 Message-ID: References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> <57324CE8.6040109@usdonovans.com> <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net> <6EF5DC36-1BEF-47EE-BB3B-83BE5E115AE3@kuehlewind.net> In-Reply-To: <6EF5DC36-1BEF-47EE-BB3B-83BE5E115AE3@kuehlewind.net> 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.8.2.8] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "dime-chairs@ietf.org" , "dime@ietf.org" , The IESG , "draft-ietf-dime-drmp@ietf.org" Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 11 May 2016 12:33:58 -0000 VGhpcyBpcyBhIHZlcnkgdmFsaWQgY29uY2Vybi4gIEl0IGlzIGltcG9ydGFudCB0byByZWNvZ25p emUgdGhhdCAibm9ybWFsIiB1c2VycyBtYXkgaW5jbHVkZSBjb21tdW5pY2F0aW9ucyB0aGF0IGlz LCBpbiByZWFsaXR5LCBtb3JlIGltcHJ0YW50IHRoYXQgdGhlIGNvbW11bmljYXRpb25zIG1hcmtl ZCBhcyBoaWdoIHByaW9yaXR5Lg0KDQpCdXQgdGhhdCBpcyBhIGNvbmNlcm4gYWRkcmVzc2VkIGJ5 IHRoZSBwcmlvcml0eSBtZWNoYW5pc20gKGUuZy4sIERpYW1ldGVyIE92ZXJsb2FkIEluZGljYXRp b24gQ29udmV5YW5jZSAoRE9JQykgW1JGQzc2ODNdICBvciBEaWFtZXRlciBPdmVybG9hZCBSYXRl IENvbnRyb2wgIFtkcmFmdC1pZXRmLWRpbWUtZG9pYy1yYXRlLWNvbnRyb2xdKS4NCg0KVGhlIGNv bmNlcm4gaXMgb3J0aG9nb25hbCB0byB0aGUgdXNlIG9mIGEgZGVmYXVsdCBwcmlvcml0eS4gIFdo ZXRoZXIgeW91IHVzZSBhIGRlZmF1bHQgcHJpb3JpdHkgb3Igbm90LCBpZiB0aGUgRmlyZWZpZ2h0 ZXJzIGhhdmUgbm90IHVwZ3JhZGVkLCB0aGVyZSBpcyBubyB3YXkgZm9yIHRoZSBzeXN0ZW0gdG8g ZGlzdGluZ3Vpc2ggdGhlIGZpcmVmaWdodGVycyBjb21tdW5pY2F0aW9ucyBmcm9tICJub3JtYWwi ICBjb21tdW5pY2F0aW9ucy4gU28gdGhlIGZpcmVmaWdodGVycyB3b24ndCBiZSB0cmVhdGVkIGRp ZmZlcmVudGx5IGZyb20gdGhlICJub3JtYWwiIGNvbW11bmljYXRpb25zLg0KDQpXaGF0IGlzIGlt cG9ydGFudCBpcyB0aGF0ICB0aGUgcHJpb3JpdHkgbWVjaGFuaXNtIHByb3RlY3QgdGhlICJub3Jt YWwiIHRyYWZmaWMgZnJvbSBzdGFydmF0aW9uLg0KDQpCb3RoIERPSUMgYW5kIFJhdGUgQ29udHJv bCBhcmUgYmFzZWQgb24gZXZlcnkgbWVzc2FnZSBoYXZpbmcgYSBrbm93biBwcmlvcml0eS4gIFVu ZGVyIHRob3NlIGFwcHJhb2NoZXMsIElmIGEgbWVzc2FnZSBkb2Vzbid0IEhBVkUgYSBwcmlvcml0 eSBpdCB3b24ndCBnZXQgc2VydmVkIGF0IGFsbCAodG90YWxseSBzdGFydmVkKS4gIFRoZSJhcnJp dmluZyB1bm1hcmtlZCIgbWVzc2FnZXMgTkVFRCB0byBiZSBhc3NpZ25lZCBhIHByaW9yaXR5IGlu IG9yZGVyIHRvIGJlIHNlcnZlZC4gIEhlbmNlIHRoZSBuZWVkIGZvciBhIGRlZmF1bHQgcHJpb3Jp dHkuDQoNCk9mIGNvdXJzZSwgdGhlcmUgYXJlIG90aGVyIHBvc3NpYmxlIHByaW9yaXR5IG1lY2hh bmlzbXMuICBCdXQgc2luY2UgdGhvc2UgdHdvIGFyZSB0aGUgb25lcyB0aGF0IGhhdmUgYmVlbiBw cm9kdWNlZCBieSB0aGUgRElNRSBXRyBmb3IgdGhpcyBwdXJwb3NlLCBpdCBtYWtlcyBzZW5zZSB0 byBwdXQgdGhlIHByaW9yaXR5IG1hcmtpbmcgcHJvY2VzcyBpbiB0aGF0IGNvbnRleHQuDQoNCkph bmV0DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNaXJqYSBLdWVobGV3aW5k IChJRVRGKSBbbWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXRdDQpTZW50OiBXZWRuZXNkYXksIE1h eSAxMSwgMjAxNiA3OjA3IEFNDQpUbzogQWxleGV5IE1lbG5pa292IDxhYW1lbG5pa292QGZhc3Rt YWlsLmZtPg0KQ2M6IFN0ZXZlIERvbm92YW4gPHNyZG9ub3ZhbkB1c2Rvbm92YW5zLmNvbT47IGRy YWZ0LWlldGYtZGltZS1kcm1wQGlldGYub3JnOyBkaW1lLWNoYWlyc0BpZXRmLm9yZzsgZGltZUBp ZXRmLm9yZzsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBHdW5uLCBKYW5ldCBQIDxKYW5ldC5H dW5uQGNzcmEuY29tPg0KU3ViamVjdDogUmU6IFtEaW1lXSBNaXJqYSBLw7xobGV3aW5kJ3MgRGlz Y3VzcyBvbiBkcmFmdC1pZXRmLWRpbWUtZHJtcC0wNTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVO VCkNCg0KT2theSBsZXQgbWUgZ28gZm9yIGFuIGV4YW1wbGUgaGVyZSBhbmQgc2VlIGlmIHRoYXQg Y2FuIGJlIGEgdXNlIGNhc2UgdGhhdCB3ZSBhcmUgdGFsa2luZyBhYm91dC4NCg0KWW91IGhhdmUg YSBzeXN0ZW0gd2hlcmUgc29tZSBjbGllbnRzIHJ1biBhIGNvbW11bmljYXRpb24gc2VydmljZSBm b3IgZW1lcmdlbmN5IGRvY3RvcnMgYXMgd2VsbCBhcyBmb3IgZmlyZWZpZ2h0ZXJzIGFuZCB0aGVu IHRoZXJlIGFyZSBhbHNvIOKAmm5vcm1hbOKAmCB1c2VycyB0aGF0IHJ1biBzb21lIGtpbmQgb2Yg Y29tbXVuaWNhdGlvbiBzZXJ2aWNlLg0KDQpOb3cgeW91IGFjdHVhbGx5IGhhdmUgYW4gZW1lcmdl bmN5OiBzb21lIHBhcnQgb2YgdGhlIHN5c3RlbSBpcyBkb3duIGFuZCB0aGUgbnVtYmVyIG9mIHJl cXVlc3QgaXMgaGlnaCBzdWNoIHRoYXQgdGhlIHN5c3RlbSBpcyBvdmVybG9hZGVkLg0KDQpCb3Ro IHRoZSBlbWVyZ2VuY3kgZG9jdG9ycyBoYXZlIHdvdWxkIGhhdmUgdHdvIGRpZmZlcmVudCBwcmlv cml0eSBjbGFzc2VzLCBvbmUgZm9yIGltcG9ydGFudCBtZXNzYWdlIGFib3V0IGluc3RydWN0aW9u ICh3aGF0IGFuZCB3aGVyZSBwZW9wbGUgc2hvdWxkIGRvIHNvbWV0aGluZykgYW5kIG9uZSBmb3Ig Y29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBkb2N0b3JzL2ZpcmVmaWdodGVycyB3aGljaCBoYXMg c3RpbGwgaGlnaGVyIHByaW9yaXR5IHRoYW4gYW55IG90aGVyIGNvbW11bmljYXRpb24gb2YgdGhl IG90aGVyIHBlb3BsZSAoYXMgeW91IGFzc3VtZSBkb2N0b3JzIGFuZCBmaXJlZmlnaHRlcnMgYXJl IG1vcmUgcmVzcG9uc2libGUgdG8gbm90IG1pc3VzZSB0aGlzIGNvbW11bmljYXRpb24gY2hhbm5l bCkuDQoNCk5vdyBvbmx5IHRoZSBlbWVyZ2VuY3kgZG9jdG9ycyBjb21tdW5pY2F0aW9uIHNlcnZp Y2Ugd2FzIHVwZ3JhZGVkIHRvIHVzZSB0aGlzIGV4dGVuc2lvbiwgYnV0IHRoZSBmaXJlZmlnaHRl cuKAmXMgYWRtaW5pc3RyYXRpb25zIGlzIGp1c3QgdG9vIHNsb3cgb3IgdGhleSBjdXJyZW50bHkg aGF2ZSBub3QgZW5vdWdoIG1vbmV5IGJlY2F1c2UgdGhleSBoYXZlIHNwZWNpYWxpemVkIGV4cGVu c2l2ZSBoYXJkd2FyZSBhbmQgc29mdHdhcmUgdGhhdCBpcyBub3QgZWFzeSB0byBjaGFuZ2UuDQoN CklzIGl0IG9rYXkgaW4gdGhpcyBzaXR1YXRpb24gdGhhdCB0aGUgcHJpdmF0ZSBjaGF0IG9mIHR3 byBkb2N0b3JzIGFib3V0IHRoZWlyIGxhc3Qgc2tpLWhvbGlkYXlzIHN0YXJ2ZXMgcmVxdWVzdHMg dG8gYWNjZXNzIHRoZSBuZXR3b3JrIHRvIHNlbmQgaW5zdHJ1Y3RvciBtZXNzYWdlIHRvIHRoZSBm aXJlZmlnaHRlcnM/DQoNCihBbmQgaG93IGRvIGkgbWFrZSBzdXJlIHRoYXQgdGhhdCBhbGwgb3Ro ZXIgb3RoZXIgcmVxdWVzdHMgYWN0dWFsbHkgc2VsZWN0IGEgbG93ZXIgcHJpb3JpdHkgdGhhbiAx MOKApj8gQnV0IHRoYXTigJlzIGEgZGlmZmVyZW50IHF1ZXN0aW9u4oCmKQ0KDQpNaXJqYQ0KDQoN Cj4gQW0gMTEuMDUuMjAxNiB1bSAwNjo1OSBzY2hyaWViIEFsZXhleSBNZWxuaWtvdiA8YWFtZWxu aWtvdkBmYXN0bWFpbC5mbT46DQo+DQo+IEhpIE1pcmphLA0KPg0KPiBPbiAxMCBNYXkgMjAxNiwg YXQgMTc6NTksIE1pcmphIEt1ZWhsZXdpbmQgKElFVEYpIDxpZXRmQGt1ZWhsZXdpbmQubmV0PiB3 cm90ZToNCj4NCj4+Pj4gSSBkb27igJl0IHRoaW5rIGl0IGlzIGEgZ29vZCBpZGVhIHRvIGFzc2ln biBhIGRlZmF1bHQgcHJpb3JpdHkgdG8gbm9uLXByaW9yaXR5LWRlZmluZWQgcmVxdWVzdHMgYXQg YWxsLiBJZiB5b3UgaGF2ZSBoaWdoIHByaW9yaXR5IHRyYWZmaWMgdGhhdCBkb2VzIG5vdCBzdXBw b3J0IHRoaXMgZXh0ZW5zaW9uICh5ZXQpIHRoaXMgdHJhZmZpYyBjb3VsZCBiZSBzdGFydmVkIGJ5 IGxvd2VyIHByaW9yaXR5IHRyYWZmaWMgd2hlbiBhc3NpZ25pbmcgYSBtaWRkbGUgcmFuZ2UgcHJp b3JpdHkuIEkgZG9u4oCZdCB0aGluayB0aGF0IGlzIHdoYXQgeW91IHdhbnQgdG8gYWNoaWV2ZS4N Cj4+PiBTUkQ+IEFjdHVhbGx5LCB0aGlzIGlzIHdoYXQgd2Ugd2FudCB0byBhY2hpZXZlLiAgSXQg aXMgYW4gcmVxdWlyZW1lbnQgdGhhdCBtZXNzYWdlcyBleHBsaWNpdGx5IG1hcmtlZCBhcyBoaWdo IHByaW9yaXR5IGdldCB0cmVhdGVkIGV2ZW4gaWYgaXQgcmVzdWx0cyBpbiBzdGFydmluZyBsb3dl ciBwcmlvcml0eSBtZXNzYWdlcy4gIFRoZSBzdGFydmluZyBvZiBsb3dlciBwcmlvcml0eSBtZXNz YWdlcyBpcyBub3QgYW4gcHJvYmxlbSwgaXQgaXMgYSByZXF1aXJlbWVudC4NCj4+DQo+PiBJIHRo aW5rIHdlIGFyZSBzdGlsbCB0YWxraW5nIHBhc3QgZWFjaCBvdGhlci4NCj4NCj4gTW9zdCBkZWZp bml0ZWx5IDotKS4NCj4NCj4+IElmIHlvdSBleHBsaWNpdGx5IGFzc2lnbiBhIHByaW9yaXR5LCBz dGFydmF0aW9uIG1pZ2h0IGJlIG9rYXkuIEhvd2V2ZXIsIGlmIHlvdSBkb27igJl0IGhhdmUgYSBw cmlvcml0eSBleHBsaWNpdGx5IHNpZ25hbGVkLCB0aGUgdHJhbnNhY3Rpb24gbWlnaHQgaGF2ZSBh IHZlcnkgaGlnaCBwcmlvcml0eQ0KPg0KPiBTbyBzb21lIGFnZW50IGluIHRoZSBzeXN0ZW0gbmVl ZHMgdG8gZGVjaWRlIHRoYXQgYSB0cmFuc2FjdGlvbiBpcyBpbXBvcnRhbnQuDQo+PiBidXQgeW91 IGp1c3QgZG9u4oCZdCBrbm93IGFuZCBieSBhc3NpZ25pbmcgYSByYW5kb20gbWlkLXJhbmdlIHBy aW9yaXR5IHRoaXMgaW1wb3J0YW50IHJlcXVlc3QgY291bGQgZ2V0IHN0YXJ2ZWQuDQo+DQo+IEhl cmUgSSBkaXNhZ3JlZSB3aXRoIHlvdSwgYmVjYXVzZSB0aGUgd2F5IHRvIGtub3cgdGhhdCBhIHRy YW5zYWN0aW9uIGlzIGltcG9ydGFudCBpcyB0byB1cGdyYWRlIGNsaWVudCB0byBleHBsaWNpdGx5 IGFzc2lnbiBoaWdoIHByaW9yaXR5IHRvIGl0LiBTbyBkZWZhdWx0IHByaW9yaXR5IGlzIGEgYmFj a3dhcmQgY29tcGF0aWJpbGl0eSBtZWNoYW5pc20sIHRoYXQgd291bGQgd29yayBmb3IgbW9zdCBj b21tb24gY2FzZXMuIFlvdSBzZWVtIHRvIGJlIHN1Z2dlc3RpbmcgdGhhdCB3aGVuIHRoaXMgZXh0 ZW5zaW9uIGlzIGRlcGxveWVkIGFsbCBjbGllbnRzIG5lZWQgdG8gYmUgdXBkYXRlZCBhdCB0aGUg c2FtZSB0aW1lLiBUaGlzIGlzIG5vdCByZWFsaXN0aWMuDQo+DQo+DQoNCg0KVGhpcyBlbGVjdHJv bmljIG1lc3NhZ2UgdHJhbnNtaXNzaW9uIGNvbnRhaW5zIGluZm9ybWF0aW9uIGZyb20gQ1NSQSB0 aGF0IG1heSBiZSBhdHRvcm5leS1jbGllbnQgcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnkgb3IgY29u ZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaW4gdGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIG9u bHkgZm9yIHVzZSBieSB0aGUgaW5kaXZpZHVhbChzKSB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4g SWYgeW91IGJlbGlldmUgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBw bGVhc2UgY29udGFjdCBtZSBpbW1lZGlhdGVseSBhbmQgYmUgYXdhcmUgdGhhdCBhbnkgdXNlLCBk aXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGUgY29udGVudHMgb2YgdGhp cyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29u dGVudCwgdGhpcyBlbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0byBiaW5kIENTUkEgdG8gYW55IG9y ZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNpdCB3cml0dGVu IGFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhwcmVzc2x5IHBlcm1pdHRpbmcg dGhlIHVzZSBvZiBlbWFpbCBmb3Igc3VjaCBwdXJwb3NlLg0K From nobody Wed May 11 06:03:07 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 A09C312DAA6; Wed, 11 May 2016 06:03:00 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 VIQyodcx2_q1; Wed, 11 May 2016 06:02:58 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 4D90612D69B; Wed, 11 May 2016 06:02:51 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:62344 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 1b0Tmn-000pQL-B9; Wed, 11 May 2016 06:02:49 -0700 To: "Mirja Kuehlewind (IETF)" , lionel.morand@orange.com References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> <57324CE8.6040109@usdonovans.com> <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net> <10389_1462926852_57327E03_10389_3007_1_6B7134B31289DC4FAF731D844122B36E01E5F82F@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Steve Donovan Message-ID: <57332D73.6090308@usdonovans.com> Date: Wed, 11 May 2016 08:02:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: Cc: "draft-ietf-dime-drmp@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , "iesg@ietf.org" , Alexey Melnikov Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 11 May 2016 13:03:01 -0000 Mirja, See my comments inline. Steve On 5/10/16 9:47 PM, Mirja Kuehlewind (IETF) wrote: > Hi Lionel, > > all you say makes much more sense to me, however, it is not well reflected in the doc. See further below. > >> Am 10.05.2016 um 20:34 schrieb lionel.morand@orange.com: >> >> Hi Mirja, >> >> I think that we need to go back to the initial requirement. >> Today, it is not possible to give a priority handling to any Diameter message, except if there is an explicit handling defined by the application using the commands or by operator policies and this specific handling can only be applied by clients, proxies and servers, not by relays. >> >> With the proposed solution, it is possible to include a explicit priority indication in Diameter messages that can be used by any node, whatever the type, as soon as they are upgraded to support this priority mechanism. >> >> Now, in heteregenous networks, it is required to handle any type of message, with or without priority indication. Messages without priority indication will be handled as today, without any specific priority handling except defined otherwise (as described above). > This should be stated moe clearly in the doc. SRD> This is normal Diameter behavior. A node that doesn't recognize an AVP ignores it but, in the case of agents (relays and proxies) leaves the AVP in the message when it passes the message on to the next node. SRD> I can add a reminder to the document that normal Diameter behavior applies to this AVP, this just didn't seem needed. > >> In this context, defining a default priority handling for the messages without explicit priority indication makes sense. If it is required that some messages have a higher priority handling, it will be required to upgrade the clients to enable them to include the priority indication. Otherwise, it will be understood that these messages could be deprioritized compared to others with explicit priority indication. > Not fully sure here because if you don’t know that this extension exists, how can you „[understand] that these messages could be reprioritized“? SRD> It is understood by the operator of the network that is adding DRMP to some but not all clients. That operator will need to determine which nodes get upgraded to support DRMP and in what order. It is reasonable to think that the operator not upgrade a set of clients if they are never involved in emergency traffic. The operator can then know that traffic from those clients will get default priority. If the operator wants messages from that client to have a different priority then the client must be upgraded to support DRMP. > >> Moreover, the priority handling will be applied ONLY when needed, when not all the messages can be handled. So, in normal situation, no difference will be made between messages with or without priority indication. And when required to prioritize the messages, it is normal to take into account “in priority†the priority indication included in the messages when available. Messages with priority indication will be handled with a best-effort approach when nothing else is defined (by application or operator policy). > Yes, you can and should take the priority indication into account but you still should not completely starve traffic that does not have a priority indication. SRD> Under normal loads starving won't happen. Under heavy loads starving can happen. Not only can it happen, it should happen if there is enough high priority traffic. Having the default priority allows the operator to put a priority scheme in place that will starve a set of messages that the operator considers lower priority than default, giving that operator more control. > >> For the record, the value 10 is not “assigned†to message without priority indication. The node receiving these messages will behave as if the messages include a priority indication set to the value 10. > Okay, that is also not stated super clearly but important. And this still does not give an argument for specifying a random default value in this doc… Why is it important that all nodes apply the same default priority handling? SRD> I'll add clarification to this point. > > Mirja > > >> Regards, >> >> Lionel >> >> Envoyé depuis Surface >> >> De : Mirja Kuehlewind (IETF) >> Envoyé : ‎mercredi‎ ‎11‎ ‎mai‎ ‎2016 ‎00‎:‎01 >> À : Steve Donovan >> Cc : draft-ietf-dime-drmp@ietf.org, Alexey Melnikov, dime-chairs@ietf.org, dime@ietf.org, iesg@ietf.org >> >> See below. >> >>> Am 10.05.2016 um 17:04 schrieb Steve Donovan : >>> >>> Mirja, >>> >>> Please see my comments inline. >>> >>> Regards, >>> >>> Steve >>> >>> On 5/10/16 9:46 AM, Mirja Kuehlewind (IETF) wrote: >>>> Hi all, >>>> >>>> sorry for my late reply. >>>> >>>> I think the part with the two queues was a little confusing. Sorry for that as well. I originally meant to describe this to illustrate the problem rather than describing a solution. However, using two queues (which fully is an implementation detail) does not even match the problem correctly that I wanted to describe… the actually point would be about the scheduling that one would need to implement to serve the queues. Here my thinking was that, instead of implementing a strict priority scheduling, you could also implement a scheme that guarantees a certain minimum serving rate for the non-priority-defined requests to avoid full starvation. However, I don’t want to confuse you even more here. So let me try to phase my concern again (I’ve also edited my discuss text): >>>> >>>> I don’t think it is a good idea to assign a default priority to non-priority-defined requests at all. If you have high priority traffic that does not support this extension (yet) this traffic could be starved by lower priority traffic when assigning a middle range priority. I don’t think that is what you want to achieve. >>> SRD> Actually, this is what we want to achieve. It is an requirement that messages explicitly marked as high priority get treated even if it results in starving lower priority messages. The starving of lower priority messages is not an problem, it is a requirement. >> I think we are still talking past each other. If you explicitly assign a priority, starvation might be okay. However, if you don’t have a priority explicitly signaled, the transaction might have a very high priority but you just don’t know and by assigning a random mid-range priority this important request could get starved. >> >> Mirja >> >> >>>> I think this point is even more true with respect to the discussion that went on with Alissa and Ben. There, you said, you’d need to define a priority scheme for a certain application before you could use it. Given that it does not make sense to define a default priority value to for all uses because depending of with priority range you select to use in your scheme, the default might be a low, high, or midrange value. >>> SRD> I don't understand the statement that it doesn't makes sense to define a default priority value. When defining a priority scheme/profile to be used within a Diameter network, all applications will need to take the "universal" default value into consideration. That default value will then be used in the handling of requests where either the application does not yet have a defined priority scheme or when the node originating the messages does not yet support the applications priority scheme. >>>> To make it even more clear I would like to propose the following text change in the doc: >>>> >>>> OLD: >>>> Diameter nodes MUST have a default priority to apply to transactions >>>> that do not have an explicit priority set in the DRMP AVP. >>>> >>>> Diameter nodes SHOULD use the PRIORITY_10 priority as this default >>>> value. >>>> >>>> NEW: >>>> Diameter nodes MAY set a default priority to apply to transactions >>>> that do not have an explicit priority set in the DRMP AVP if it is >>>> known that the transactions that define a higher priority than the default >>>> are always higher priority than the transactions that do not define >>>> a priority explicitly. The default value will depend on the used priority >>>> range in a given deployment setup. >>> SRD> One of the goals of the default priority value is to keep nodes like Diameter relays from needing to understand application semantics. This requirement would break those Diameter relays as application level knowledge is required to know if a message without an explicit priority value is of a higher priority. >>> >>> SRD> In addition, there is only one priority range, as defined in the document. It is important that the range be the same across all applications for the mechanism to work, especially in nodes handling messages for multiple applications. >>>> Diameter node SHOULD not assign >>>> a default priority if no additional information about the transaction >>>> that do not define an explicit priority is known. In this case the >>>> diameter node SHOULD provide a minimum serving rate for transaction that do >>>> not define an explicit priority to avoid full starvation of these >>>> transactions the may or may not have a higher priority than other >>>> transactions that provide information about their priority. >>> SRD> This is explicitly NOT a requirement. It is acceptable to starve lower priority messages. >>>> I hope that makes sense to you. Please propose edits (if not)! >>> SRD> I don't yet see a reason to change the original wording. >>>> Mirja >>>> >>>> >>>>> Am 05.05.2016 um 08:32 schrieb Alexey Melnikov : >>>>> >>>>> Hi Mirja, >>>>> >>>>> On Wed, May 4, 2016, at 04:50 PM, Mirja Kuehlewind (IETF) wrote: >>>>>> Hi Janet, >>>>>> >>>>>> there are clearly more options than the two mention below. >>>>>> >>>>>> E.g. one option is the one explained in my initial comment: hhaving two >>>>>> queues, that are both served with a certain rate. >>>>>> >>>>>> I’m sure there are more (and potentially more complex) solutions to this >>>>>> problem as well. >>>>>> >>>>>> Assigning an arbitrary priority is not the right option from my point of >>>>>> view and can actually hurt the systems. >>>>> I hope this will help to clarify things: >>>>> >>>>> One point of assigning default priority is that as this is an extension, >>>>> there is a desire to avoid upgrading all clients on the network, as that >>>>> would be effectively trying to deploy a new protocol. Consider a network >>>>> where proxies and servers understand this extension and none of the >>>>> clients do. Then default priority would be assigned to all traffic and >>>>> the behaviour of the system is unchanged from the case when the >>>>> extension is not deployed. The default priority only makes a difference >>>>> if there is a mixture of clients implementing this extension and clients >>>>> that don't. >>>>> >>>>> Best Regards, >>>>> Alexey >>>>> >>>>>> Mirja >>>>>> >>>>>> >>>>>>> Am 04.05.2016 um 17:45 schrieb Gunn, Janet P : >>>>>>> >>>>>>> My comment below. >>>>>>> Janet >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Mirja Kuehlewind (IETF) >>>>>>> Sent: Wednesday, May 04, 2016 10:31 AM >>>>>>> To: Alexey Melnikov >>>>>>> Cc: draft-ietf-dime-drmp@ietf.org; dime-chairs@ietf.org; dime@ietf.org; The IESG >>>>>>> Subject: Re: [Dime] Mirja Kühlewind's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) >>>>>>> >>>>>>> Hi Alexey, >>>>>>> >>>>>>> see below. >>>>>>> >>>>>>> The point is, if you explicitly indicate that you have a lower priority, you are okay to be starved. However, if you don’t indicate anything (maybe just because you have not been aware that it is possible to do so), you might have the same or even a higher priority, and in this case it’s not okay to be starved. >>>>>>> >>>>>>> Mirja >>>>>>> If a message comes in without a priority, into a system which serves messages based on priority (regardless of the specific mechanisms)you have two options >>>>>>> 1- Discard the message (Not a good idea in most systems) >>>>>>> 2 - Assign the message an ARBITRARY priority (we call this arbitrary value the "default priority") >>>>>>> >>>>>>> You can (and probably will) argue 'til the cows come home on what that arbitrary/default value SHOULD BE. And different sytems/applications might have different "default values". >>>>>>> >>>>>>> But I don't think there should be any argument that, if a message comes in without a priority, you need to assign it a priority. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>> >>>>>>> This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information 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 agreement or government initiative expressly permitting the use of email for such purpose. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> _________________________________________________________________________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques 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 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 delete 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 May 11 06:06: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 910FC12DAAC; Wed, 11 May 2016 06:05:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 TmCRzR3Sj_-f; Wed, 11 May 2016 06:05:55 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 975F512DAB3; Wed, 11 May 2016 06:05:51 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:62347 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 1b0Tpi-000rVF-Ju; Wed, 11 May 2016 06:05:50 -0700 To: "Mirja Kuehlewind (IETF)" References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> <57324CE8.6040109@usdonovans.com> <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net> From: Steve Donovan Message-ID: <57332E29.7000002@usdonovans.com> Date: Wed, 11 May 2016 08:05:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-1.0 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: Cc: draft-ietf-dime-drmp@ietf.org, Alexey Melnikov , dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 11 May 2016 13:05:57 -0000 Please see my comments inline. Steve On 5/10/16 4:59 PM, Mirja Kuehlewind (IETF) wrote: > See below. > >> Am 10.05.2016 um 17:04 schrieb Steve Donovan : >> >> Mirja, >> >> Please see my comments inline. >> >> Regards, >> >> Steve >> >> On 5/10/16 9:46 AM, Mirja Kuehlewind (IETF) wrote: >>> Hi all, >>> >>> sorry for my late reply. >>> >>> I think the part with the two queues was a little confusing. Sorry for that as well. I originally meant to describe this to illustrate the problem rather than describing a solution. However, using two queues (which fully is an implementation detail) does not even match the problem correctly that I wanted to describe… the actually point would be about the scheduling that one would need to implement to serve the queues. Here my thinking was that, instead of implementing a strict priority scheduling, you could also implement a scheme that guarantees a certain minimum serving rate for the non-priority-defined requests to avoid full starvation. However, I don’t want to confuse you even more here. So let me try to phase my concern again (I’ve also edited my discuss text): >>> >>> I don’t think it is a good idea to assign a default priority to non-priority-defined requests at all. If you have high priority traffic that does not support this extension (yet) this traffic could be starved by lower priority traffic when assigning a middle range priority. I don’t think that is what you want to achieve. >> SRD> Actually, this is what we want to achieve. It is an requirement that messages explicitly marked as high priority get treated even if it results in starving lower priority messages. The starving of lower priority messages is not an problem, it is a requirement. > I think we are still talking past each other. If you explicitly assign a priority, starvation might be okay. However, if you don’t have a priority explicitly signaled, the transaction might have a very high priority but you just don’t know and by assigning a random mid-range priority this important request could get starved. SRD> And if this is why DRMP is needed. The only method to insure these messages get higher priority treatment, including avoiding getting starved, is to mark the messages with a priority. > > Mirja > > >>> I think this point is even more true with respect to the discussion that went on with Alissa and Ben. There, you said, you’d need to define a priority scheme for a certain application before you could use it. Given that it does not make sense to define a default priority value to for all uses because depending of with priority range you select to use in your scheme, the default might be a low, high, or midrange value. >> SRD> I don't understand the statement that it doesn't makes sense to define a default priority value. When defining a priority scheme/profile to be used within a Diameter network, all applications will need to take the "universal" default value into consideration. That default value will then be used in the handling of requests where either the application does not yet have a defined priority scheme or when the node originating the messages does not yet support the applications priority scheme. >>> To make it even more clear I would like to propose the following text change in the doc: >>> >>> OLD: >>> Diameter nodes MUST have a default priority to apply to transactions >>> that do not have an explicit priority set in the DRMP AVP. >>> >>> Diameter nodes SHOULD use the PRIORITY_10 priority as this default >>> value. >>> >>> NEW: >>> Diameter nodes MAY set a default priority to apply to transactions >>> that do not have an explicit priority set in the DRMP AVP if it is >>> known that the transactions that define a higher priority than the default >>> are always higher priority than the transactions that do not define >>> a priority explicitly. The default value will depend on the used priority >>> range in a given deployment setup. >> SRD> One of the goals of the default priority value is to keep nodes like Diameter relays from needing to understand application semantics. This requirement would break those Diameter relays as application level knowledge is required to know if a message without an explicit priority value is of a higher priority. >> >> SRD> In addition, there is only one priority range, as defined in the document. It is important that the range be the same across all applications for the mechanism to work, especially in nodes handling messages for multiple applications. >>> Diameter node SHOULD not assign >>> a default priority if no additional information about the transaction >>> that do not define an explicit priority is known. In this case the >>> diameter node SHOULD provide a minimum serving rate for transaction that do >>> not define an explicit priority to avoid full starvation of these >>> transactions the may or may not have a higher priority than other >>> transactions that provide information about their priority. >> SRD> This is explicitly NOT a requirement. It is acceptable to starve lower priority messages. >>> I hope that makes sense to you. Please propose edits (if not)! >> SRD> I don't yet see a reason to change the original wording. >>> Mirja >>> >>> >>>> Am 05.05.2016 um 08:32 schrieb Alexey Melnikov : >>>> >>>> Hi Mirja, >>>> >>>> On Wed, May 4, 2016, at 04:50 PM, Mirja Kuehlewind (IETF) wrote: >>>>> Hi Janet, >>>>> >>>>> there are clearly more options than the two mention below. >>>>> >>>>> E.g. one option is the one explained in my initial comment: hhaving two >>>>> queues, that are both served with a certain rate. >>>>> >>>>> I’m sure there are more (and potentially more complex) solutions to this >>>>> problem as well. >>>>> >>>>> Assigning an arbitrary priority is not the right option from my point of >>>>> view and can actually hurt the systems. >>>> I hope this will help to clarify things: >>>> >>>> One point of assigning default priority is that as this is an extension, >>>> there is a desire to avoid upgrading all clients on the network, as that >>>> would be effectively trying to deploy a new protocol. Consider a network >>>> where proxies and servers understand this extension and none of the >>>> clients do. Then default priority would be assigned to all traffic and >>>> the behaviour of the system is unchanged from the case when the >>>> extension is not deployed. The default priority only makes a difference >>>> if there is a mixture of clients implementing this extension and clients >>>> that don't. >>>> >>>> Best Regards, >>>> Alexey >>>> >>>>> Mirja >>>>> >>>>> >>>>>> Am 04.05.2016 um 17:45 schrieb Gunn, Janet P : >>>>>> >>>>>> My comment below. >>>>>> Janet >>>>>> >>>>>> -----Original Message----- >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Mirja Kuehlewind (IETF) >>>>>> Sent: Wednesday, May 04, 2016 10:31 AM >>>>>> To: Alexey Melnikov >>>>>> Cc: draft-ietf-dime-drmp@ietf.org; dime-chairs@ietf.org; dime@ietf.org; The IESG >>>>>> Subject: Re: [Dime] Mirja Kühlewind's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT) >>>>>> >>>>>> Hi Alexey, >>>>>> >>>>>> see below. >>>>>> >>>>>> The point is, if you explicitly indicate that you have a lower priority, you are okay to be starved. However, if you don’t indicate anything (maybe just because you have not been aware that it is possible to do so), you might have the same or even a higher priority, and in this case it’s not okay to be starved. >>>>>> >>>>>> Mirja >>>>>> If a message comes in without a priority, into a system which serves messages based on priority (regardless of the specific mechanisms)you have two options >>>>>> 1- Discard the message (Not a good idea in most systems) >>>>>> 2 - Assign the message an ARBITRARY priority (we call this arbitrary value the "default priority") >>>>>> >>>>>> You can (and probably will) argue 'til the cows come home on what that arbitrary/default value SHOULD BE. And different sytems/applications might have different "default values". >>>>>> >>>>>> But I don't think there should be any argument that, if a message comes in without a priority, you need to assign it a priority. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >>>>>> This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information 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 agreement or government initiative expressly permitting the use of email for such purpose. From nobody Wed May 11 06:07:03 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 2632212DABF; Wed, 11 May 2016 06:06:58 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 wZuxpf4L-t7F; Wed, 11 May 2016 06:06:52 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 7AFE412DAB0; Wed, 11 May 2016 06:06:47 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:62349 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 1b0Tqc-000sDZ-8P; Wed, 11 May 2016 06:06:47 -0700 To: Alexey Melnikov , "Mirja Kuehlewind (IETF)" References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> <57324CE8.6040109@usdonovans.com> <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net> <10389_1462926852_57327E03_10389_3007_1_6B7134B31289DC4FAF731D844122B36E01E5F82F@OPEXCLILM43.corporate.adroot.infra.ftgroup> <5F0F8E44-3B12-48F0-B0F1-00039A8F1D1F@fastmail.fm> From: Steve Donovan Message-ID: <57332E60.2000505@usdonovans.com> Date: Wed, 11 May 2016 08:06:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5F0F8E44-3B12-48F0-B0F1-00039A8F1D1F@fastmail.fm> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-1.0 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: Cc: "draft-ietf-dime-drmp@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , "iesg@ietf.org" Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 11 May 2016 13:06:58 -0000 Inline... On 5/11/16 5:52 AM, Alexey Melnikov wrote: > Hi Mirja, > > On 10 May 2016, at 22:47, Mirja Kuehlewind (IETF) wrote: > >>> Moreover, the priority handling will be applied ONLY when needed, when not all the messages can be handled. So, in normal situation, no difference will be made between messages with or without priority indication. And when required to prioritize the messages, it is normal to take into account “in priority” the priority indication included in the messages when available. Messages with priority indication will be handled with a best-effort approach when nothing else is defined (by application or operator policy). >> Yes, you can and should take the priority indication into account but you still should not completely starve traffic that does not have a priority indication. > This can only happen where there is a flood of messages and when it does, this is by design. The whole point of this is that when a flood of messages happens, lower priority messages get less preferential treatment, as opposed to random messages (as it is now without this extension) getting less preferential treatment. > >>> For the record, the value 10 is not “assigned” to message without priority indication. The node receiving these messages will behave as if the messages include a priority indication set to the value 10. >> Okay, that is also not stated super clearly but important. And this still does not give an argument for specifying a random default value in this doc… Why is it important that all nodes apply the same default priority handling? > Because one would want consistent behaviour across the whole system. Which looks like a desired property. SRD> +1 > > From nobody Wed May 11 06:21:51 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 BBBC712DABD; Wed, 11 May 2016 06:21:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 AkmEq90a55Og; Wed, 11 May 2016 06:21:43 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 ED06C12D642; Wed, 11 May 2016 06:21:42 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:62396 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 1b0U53-0011v7-Gw; Wed, 11 May 2016 06:21:42 -0700 To: "Mirja Kuehlewind (IETF)" , Alexey Melnikov References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> <57324CE8.6040109@usdonovans.com> <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net> <6EF5DC36-1BEF-47EE-BB3B-83BE5E115AE3@kuehlewind.net> From: Steve Donovan Message-ID: <573331DF.2090504@usdonovans.com> Date: Wed, 11 May 2016 08:21:35 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <6EF5DC36-1BEF-47EE-BB3B-83BE5E115AE3@kuehlewind.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-1.0 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: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 11 May 2016 13:21:46 -0000 Mirja, Today, without DRMP, all of the traffic is treated the same by relays as relays do not, by design, have application level knowledge. In many cases, servers do not have enough context to determine the priority of a message. In general, the Diameter client is the only one who has that knowledge. You are correct that if the firefighters traffic does not get priority marked then the firefighters traffic is thrown into the default bucket with all of the other non emergency traffic. The only way to avoid this is to upgrade the firefighters system. There is no way, without a client marking a requests priority, for an agent to understand the priority of a message. Agents don't have application level knowledge. Your proposal of having Diameter nodes understand the intrinsic priority of a message without an implicit priority marking is not possible in Diameter. This is why the working group decided on the DRMP mechanism. Steve On 5/11/16 6:07 AM, Mirja Kuehlewind (IETF) wrote: > Okay let me go for an example here and see if that can be a use case that we are talking about. > > You have a system where some clients run a communication service for emergency doctors as well as for firefighters and then there are also ‚normal‘ users that run some kind of communication service. > > Now you actually have an emergency: some part of the system is down and the number of request is high such that the system is overloaded. > > Both the emergency doctors have would have two different priority classes, one for important message about instruction (what and where people should do something) and one for communication between the doctors/firefighters which has still higher priority than any other communication of the other people (as you assume doctors and firefighters are more responsible to not misuse this communication channel). > > Now only the emergency doctors communication service was upgraded to use this extension, but the firefighter’s administrations is just too slow or they currently have not enough money because they have specialized expensive hardware and software that is not easy to change. > > Is it okay in this situation that the private chat of two doctors about their last ski-holidays starves requests to access the network to send instructor message to the firefighters? > > (And how do i make sure that that all other other requests actually select a lower priority than 10…? But that’s a different question…) > > Mirja > > >> Am 11.05.2016 um 06:59 schrieb Alexey Melnikov : >> >> Hi Mirja, >> >> On 10 May 2016, at 17:59, Mirja Kuehlewind (IETF) wrote: >> >>>>> I don’t think it is a good idea to assign a default priority to non-priority-defined requests at all. If you have high priority traffic that does not support this extension (yet) this traffic could be starved by lower priority traffic when assigning a middle range priority. I don’t think that is what you want to achieve. >>>> SRD> Actually, this is what we want to achieve. It is an requirement that messages explicitly marked as high priority get treated even if it results in starving lower priority messages. The starving of lower priority messages is not an problem, it is a requirement. >>> I think we are still talking past each other. >> Most definitely :-). >> >>> If you explicitly assign a priority, starvation might be okay. However, if you don’t have a priority explicitly signaled, the transaction might have a very high priority >> So some agent in the system needs to decide that a transaction is important. >>> but you just don’t know and by assigning a random mid-range priority this important request could get starved. >> Here I disagree with you, because the way to know that a transaction is important is to upgrade client to explicitly assign high priority to it. So default priority is a backward compatibility mechanism, that would work for most common cases. You seem to be suggesting that when this extension is deployed all clients need to be updated at the same time. This is not realistic. >> >> From nobody Wed May 11 08:29: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 9A84712D722; Wed, 11 May 2016 08:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 37Y62Ur4iClV; Wed, 11 May 2016 08:29:17 -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 28FEC12D70C; Wed, 11 May 2016 08:29:17 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id B9B20C0611; Wed, 11 May 2016 17:29:15 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 689E74008F; Wed, 11 May 2016 17:29:15 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0294.000; Wed, 11 May 2016 17:29:15 +0200 From: To: "Mirja Kuehlewind (IETF)" Thread-Topic: =?utf-8?B?W0RpbWVdIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWll?= =?utf-8?Q?tf-dime-drmp-05:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHRqsu3MGSn2nqArkOEVymcyKpnwZ+yiAMAgAAPPoCAAEzT+4AAA7kAgADXmlA= Date: Wed, 11 May 2016 15:29:14 +0000 Message-ID: <9074_1462980555_57334FCB_9074_8739_4_6B7134B31289DC4FAF731D844122B36E01E605A1@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> <57324CE8.6040109@usdonovans.com> <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net> <10389_1462926852_57327E03_10389_3007_1_6B7134B31289DC4FAF731D844122B36E01E5F82F@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Alexey Melnikov , "draft-ietf-dime-drmp@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , "iesg@ietf.org" Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 11 May 2016 15:29:21 -0000 SGkgTWlyamEsDQoNClRoYW5rIHlvdSBmb3IgeW91ciBmZWRiYWNrLg0KDQpQbGVhc2Ugc2VlIGJl bG93Lg0KDQpSZWdhcmRzLA0KDQpMaW9uZWwNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS0NCj4gRGXCoDogTWlyamEgS3VlaGxld2luZCAoSUVURikgW21haWx0bzppZXRmQGt1ZWhsZXdp bmQubmV0XQ0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDExIG1haSAyMDE2IDA0OjQ4DQo+IMOAwqA6 IE1PUkFORCBMaW9uZWwgSU1UL09MTg0KPiBDY8KgOiBTdGV2ZSBEb25vdmFuOyBkcmFmdC1pZXRm LWRpbWUtZHJtcEBpZXRmLm9yZzsgZGltZS1jaGFpcnNAaWV0Zi5vcmc7DQo+IGRpbWVAaWV0Zi5v cmc7IGllc2dAaWV0Zi5vcmc7IEFsZXhleSBNZWxuaWtvdg0KPiBPYmpldMKgOiBSZTogW0RpbWVd IE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZGltZS1kcm1wLTA1Og0K PiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gSGkgTGlvbmVsLA0KPiANCj4gYWxs IHlvdSBzYXkgbWFrZXMgbXVjaCBtb3JlIHNlbnNlIHRvIG1lLCBob3dldmVyLCBpdCBpcyBub3Qg d2VsbCByZWZsZWN0ZWQgaW4NCj4gdGhlIGRvYy4gU2VlIGZ1cnRoZXIgYmVsb3cuDQo+IA0KW0xN XSBJIHNlZSB0aGF0IGF0IGxlYXN0IHNvbWUgY2xhcmlmaWNhdGlvbnMgYXJlIHJlcXVpcmVkIDop DQoNCj4gPiBBbSAxMC4wNS4yMDE2IHVtIDIwOjM0IHNjaHJpZWIgbGlvbmVsLm1vcmFuZEBvcmFu Z2UuY29tOg0KPiA+DQo+ID4gSGkgTWlyamEsDQo+ID4NCj4gPiBJIHRoaW5rIHRoYXQgd2UgbmVl ZCB0byBnbyBiYWNrIHRvIHRoZSBpbml0aWFsIHJlcXVpcmVtZW50Lg0KPiA+IFRvZGF5LCBpdCBp cyBub3QgcG9zc2libGUgdG8gZ2l2ZSBhIHByaW9yaXR5IGhhbmRsaW5nIHRvIGFueSBEaWFtZXRl ciBtZXNzYWdlLA0KPiBleGNlcHQgaWYgdGhlcmUgaXMgYW4gZXhwbGljaXQgaGFuZGxpbmcgZGVm aW5lZCBieSB0aGUgYXBwbGljYXRpb24gdXNpbmcgdGhlDQo+IGNvbW1hbmRzIG9yIGJ5IG9wZXJh dG9yIHBvbGljaWVzIGFuZCB0aGlzIHNwZWNpZmljIGhhbmRsaW5nIGNhbiBvbmx5IGJlDQo+IGFw cGxpZWQgYnkgY2xpZW50cywgcHJveGllcyBhbmQgc2VydmVycywgbm90IGJ5IHJlbGF5cy4NCj4g Pg0KPiA+IFdpdGggdGhlIHByb3Bvc2VkIHNvbHV0aW9uLCBpdCBpcyBwb3NzaWJsZSB0byBpbmNs dWRlIGEgZXhwbGljaXQgcHJpb3JpdHkNCj4gaW5kaWNhdGlvbiBpbiBEaWFtZXRlciBtZXNzYWdl cyB0aGF0IGNhbiBiZSB1c2VkIGJ5IGFueSBub2RlLCB3aGF0ZXZlciB0aGUNCj4gdHlwZSwgYXMg c29vbiBhcyB0aGV5IGFyZSB1cGdyYWRlZCB0byBzdXBwb3J0IHRoaXMgcHJpb3JpdHkgbWVjaGFu aXNtLg0KPiA+DQo+ID4gTm93LCBpbiBoZXRlcmVnZW5vdXMgbmV0d29ya3MsIGl0IGlzIHJlcXVp cmVkIHRvIGhhbmRsZSBhbnkgdHlwZSBvZg0KPiBtZXNzYWdlLCB3aXRoIG9yIHdpdGhvdXQgcHJp b3JpdHkgaW5kaWNhdGlvbi4gTWVzc2FnZXMgd2l0aG91dCBwcmlvcml0eQ0KPiBpbmRpY2F0aW9u IHdpbGwgYmUgaGFuZGxlZCBhcyB0b2RheSwgd2l0aG91dCBhbnkgc3BlY2lmaWMgcHJpb3JpdHkg aGFuZGxpbmcNCj4gZXhjZXB0IGRlZmluZWQgb3RoZXJ3aXNlIChhcyBkZXNjcmliZWQgYWJvdmUp Lg0KPiANCj4gVGhpcyBzaG91bGQgYmUgc3RhdGVkIG1vZSBjbGVhcmx5IGluIHRoZSBkb2MuDQoN CltMTV0gQXMgSSBzYWlkIGluIGEgcHJldmlvdXMgbWFpbCwgb25lICJwb3NzaWJsZSIgcmVwcm9h Y2ggb2YgdGhpcyBkb2N1bWVudCBpcyB0aGF0IGl0IHJlbGllcyBvbiByZXF1aXJlbWVudHMgYW5k IHByZXJlcXVpc2l0ZXMgZGV0YWlsZWQgaW4gdGhlIG92ZXJsb2FkIGRvY3VtZW50cyBnaXZlbiBp biByZWZlcmVuY2UuDQpJdCBpcyBhbHNvIGFzc3VtZWQgdGhhdCByZWFkZXJzIGFyZSBmYW1pbGlh cnMgd2l0aCBEaWFtZXRlciBhbmQgRGlhbWV0ZXItYmFzZWQgbmV0d29ya3Mgc3VjaCAzR1BQIG5l dHdvcmtzLiBCdXQgaXQgaXMgdHJ1ZSBmb3Igb3RoZXIgZG9jdW1lbnRzIChtYXliZSBub3QgYW4g ZXhjdXNlKS4NCg0KPiANCj4gPg0KPiA+IEluIHRoaXMgY29udGV4dCwgZGVmaW5pbmcgYSBkZWZh dWx0IHByaW9yaXR5IGhhbmRsaW5nIGZvciB0aGUgbWVzc2FnZXMNCj4gd2l0aG91dCBleHBsaWNp dCBwcmlvcml0eSBpbmRpY2F0aW9uIG1ha2VzIHNlbnNlLiBJZiBpdCBpcyByZXF1aXJlZCB0aGF0 IHNvbWUNCj4gbWVzc2FnZXMgaGF2ZSBhIGhpZ2hlciBwcmlvcml0eSBoYW5kbGluZywgaXQgd2ls bCBiZSByZXF1aXJlZCB0byB1cGdyYWRlIHRoZQ0KPiBjbGllbnRzIHRvIGVuYWJsZSB0aGVtIHRv IGluY2x1ZGUgdGhlIHByaW9yaXR5IGluZGljYXRpb24uIE90aGVyd2lzZSwgaXQgd2lsbCBiZQ0K PiB1bmRlcnN0b29kIHRoYXQgdGhlc2UgbWVzc2FnZXMgY291bGQgYmUgZGVwcmlvcml0aXplZCBj b21wYXJlZCB0byBvdGhlcnMNCj4gd2l0aCBleHBsaWNpdCBwcmlvcml0eSBpbmRpY2F0aW9uLg0K PiANCj4gTm90IGZ1bGx5IHN1cmUgaGVyZSBiZWNhdXNlIGlmIHlvdSBkb27igJl0IGtub3cgdGhh dCB0aGlzIGV4dGVuc2lvbiBleGlzdHMsIGhvdw0KPiBjYW4geW91IOKAnlt1bmRlcnN0YW5kXSB0 aGF0IHRoZXNlIG1lc3NhZ2VzIGNvdWxkIGJlIHJlcHJpb3JpdGl6ZWTigJw/DQoNCltMTV0gTm90 IHN1cmUgdG8gdW5kZXJzdGFuZC4gSWYgeW91IGFyZSBub3Qgc3VwcG9ydGluZyB0aGlzIG5ldyBE aWFtZXRlciBleHRlbnNpb24sIHRoZXJlIGlzIG5vIHN0YW5kYXJkaXplZCByZS9kZXByaW9yaXRp emF0aW9uIG1lY2hhbmlzbSBkZWZpbmVkIGFueXdheS4gTWVzc2FnZXMgd2l0aCBwcmlvcml0eSBp bmRpY2F0aW9uIHdpbGwgYmUgaGFuZGxlZCBhcyBhbnkgb3RoZXIgbWVzc2FnZXMsIGFzIHRvZGF5 Lg0KSXQgaXMgb25seSBmb3Igbm9kZXMgc3VwcG9ydGluZyB0aGUgbmV3IG1lY2hhbmlzbSB0aGF0 IGl0IGlzIGltcG9ydGFudCB0byBkZWZpbmUgYSBzdGFuZGFyZCBiZWhhdmlvciBmb3Igd2hlbiBy ZWNlaXZpbmcgbWVzc2FnZXMgd2l0aG91dCBwcmlvcml0eSBpbmRpY2F0aW9uIHNlbnQgYnkgbm9u LXN1cHBvcnRpbmcgbm9kZXMuDQoNCj4gDQo+ID4NCj4gPiBNb3Jlb3ZlciwgdGhlIHByaW9yaXR5 IGhhbmRsaW5nIHdpbGwgYmUgYXBwbGllZCBPTkxZIHdoZW4gbmVlZGVkLCB3aGVuDQo+IG5vdCBh bGwgdGhlIG1lc3NhZ2VzIGNhbiBiZSBoYW5kbGVkLiBTbywgaW4gbm9ybWFsIHNpdHVhdGlvbiwg bm8gZGlmZmVyZW5jZQ0KPiB3aWxsIGJlIG1hZGUgYmV0d2VlbiBtZXNzYWdlcyB3aXRoIG9yIHdp dGhvdXQgcHJpb3JpdHkgaW5kaWNhdGlvbi4gQW5kDQo+IHdoZW4gcmVxdWlyZWQgdG8gcHJpb3Jp dGl6ZSB0aGUgbWVzc2FnZXMsIGl0IGlzIG5vcm1hbCB0byB0YWtlIGludG8gYWNjb3VudCDigJxp bg0KPiBwcmlvcml0eeKAnSB0aGUgcHJpb3JpdHkgaW5kaWNhdGlvbiBpbmNsdWRlZCBpbiB0aGUg bWVzc2FnZXMgd2hlbiBhdmFpbGFibGUuDQo+IE1lc3NhZ2VzIHdpdGggcHJpb3JpdHkgaW5kaWNh dGlvbiB3aWxsIGJlIGhhbmRsZWQgd2l0aCBhIGJlc3QtZWZmb3J0IGFwcHJvYWNoDQo+IHdoZW4g bm90aGluZyBlbHNlIGlzIGRlZmluZWQgKGJ5IGFwcGxpY2F0aW9uIG9yIG9wZXJhdG9yIHBvbGlj eSkuDQo+IA0KPiBZZXMsIHlvdSBjYW4gYW5kIHNob3VsZCB0YWtlIHRoZSBwcmlvcml0eSBpbmRp Y2F0aW9uIGludG8gYWNjb3VudCBidXQgeW91IHN0aWxsDQo+IHNob3VsZCBub3QgY29tcGxldGVs eSBzdGFydmUgdHJhZmZpYyB0aGF0IGRvZXMgbm90IGhhdmUgYSBwcmlvcml0eSBpbmRpY2F0aW9u Lg0KDQpbTE1dIEluIGEgc3lzdGVtIHdoZXJlIHRoZSBwcmlvcml0eSBtZWNoYW5pc20gaXMgaW50 cm9kdWNlZCwgdGhlIGlkZWEgaXMgYWN0dWFsbHkgdG8gZ2l2ZSBoaWdoZXIgcHJpb3JpdHkgdG8g bWVzc2FnZXMgaW5kaWNhdGluZyBoaWdoZXIgcHJpb3JpdHkuDQpOZXR3b3JrcyB0aGF0IHdpbGwg aGF2ZSB0byBzdXBwb3J0IHByaW9yaXR5IGhhbmRsaW5nIChsb3cgb3IgaGlnaCkgd2lsbCBiZSB1 cGdyYWRlZCB0byBzdXBwb3J0IHRoaXMgbWVjaGFuaXNtLiBOb3csIHdoZW4geW91IGhhdmUgdG8g aW50ZXJ3b3JrIHdpdGggc3lzdGVtcyBub3QgdXBncmFkZWQsIG1lc3NhZ2VzIHJlY2VpdmVkIGZy b20gdGhlc2Ugc3lzdGVtcyB3aXRob3V0IHByaW9yaXR5IGluZGljYXRpb24gbWF5IGJlIGhhbmRs ZWQgd2l0aCBhIGxvd2VyIHByaW9yaXR5IHRoYW4gb3RoZXIgbWVzc2FnZXMuIFRoYXQncyBhIGZh Y3QuIEJ1dCBmaXJzdCwgSSB0aGluayB0aGF0IHRoZSBtYWluIHVzZSBvZiB0aGUgcHJpb3JpdHkg bWVjaGFuaXNtIGlzIGluIGludHJhLWRvbWFpbiBhbmQgaXQgaXMgbWFuYWdlYWJsZSB0byB1cGdy YWRlIGhvbW9nZW5lb3VzbHkgYSBnaXZlbiBuZXR3b3JrIHRvIHN1cHBvcnQgdGhpcyBuZXcgbWVj aGFuaXNtLiBOb3cgaWYgYW4gYXBwbGljYXRpb24gaXMgaW50ZXItZG9tYWluIGFuZCBhIHNwZWNp ZmljIHByaW9yaXR5IGhhbmRsaW5nIGlzIHJlcXVpcmVkLCB0aGUgYXBwbGljYXRpb24gY2FuIGJl IGVpdGhlciBlbmhhbmNlZCB0byBzdXBwb3J0IHRoZSBwcmlvcml0eSBpbmRpY2F0aW9uIChhcyBm b3IgM0dQUCBpbnRlci1kb21haW4gaW50ZXJmYWNlcykgb3IgaXQgaXMgcG9zc2libGUgdG8gZGVm aW5lIHNwZWNpZmljIG9wZXJhdG9yIHBvbGljaWVzIHBlciBpbnRlcmZhY2UuDQoNCj4gDQo+ID4N Cj4gPiBGb3IgdGhlIHJlY29yZCwgdGhlIHZhbHVlIDEwIGlzIG5vdCDigJxhc3NpZ25lZOKAnSB0 byBtZXNzYWdlIHdpdGhvdXQgcHJpb3JpdHkNCj4gaW5kaWNhdGlvbi4gVGhlIG5vZGUgcmVjZWl2 aW5nIHRoZXNlIG1lc3NhZ2VzIHdpbGwgYmVoYXZlIGFzIGlmIHRoZSBtZXNzYWdlcw0KPiBpbmNs dWRlIGEgcHJpb3JpdHkgaW5kaWNhdGlvbiBzZXQgdG8gdGhlIHZhbHVlIDEwLg0KPiANCj4gT2th eSwgdGhhdCBpcyBhbHNvIG5vdCBzdGF0ZWQgc3VwZXIgY2xlYXJseSBidXQgaW1wb3J0YW50LiBB bmQgdGhpcyBzdGlsbCBkb2VzDQo+IG5vdCBnaXZlIGFuIGFyZ3VtZW50IGZvciBzcGVjaWZ5aW5n IGEgcmFuZG9tIGRlZmF1bHQgdmFsdWUgaW4gdGhpcyBkb2PigKYgV2h5DQo+IGlzIGl0IGltcG9y dGFudCB0aGF0IGFsbCBub2RlcyBhcHBseSB0aGUgc2FtZSAgZGVmYXVsdCBwcmlvcml0eSBoYW5k bGluZz8NCg0KW0xNXSBpdCBpcyBhIHJlY29tbWVuZGF0aW9uIHRvIGluc3VyZSBjb25zaXN0ZW50 IGhhbmRsaW5nIG9mIHByaW9yaXR5IG1hbmFnZW1lbnQgYWNyb3NzIGhldGVyb2dlbmVvdXMgbmV0 d29ya3MuIEl0IGlzIG1vcmUgYW4gaW1wbGVtZW50YXRpb24gZ3VpZGVsaW5lcyBmb3IgdmVuZG9y cyB0aGFuIGFuIG9wZXJhdGlvbmFsIHJlcXVpcmVtZW50Lg0KVGhlICJTSE9VTEQiIGlzIGFjdHVh bGx5IHVzZSB0byBzYXkgIlVzZSAxMCBleGNlcHQgb3RoZXJ3aXNlIHN0YXRlZC9jb25maWd1cmVk Ii4NCg0KPiANCj4gTWlyamENCj4gDQo+IA0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPg0KPiA+IExp b25lbA0KPiA+DQo+ID4gRW52b3nDqSBkZXB1aXMgU3VyZmFjZQ0KPiA+DQo+ID4gRGUgOiBNaXJq YSBLdWVobGV3aW5kIChJRVRGKQ0KPiA+IEVudm95w6kgOiDigI5tZXJjcmVkaeKAjiDigI4xMeKA jiDigI5tYWnigI4g4oCOMjAxNiDigI4wMOKAjjrigI4wMSDDgCA6IFN0ZXZlIERvbm92YW4gQ2Mg Og0KPiA+IGRyYWZ0LWlldGYtZGltZS1kcm1wQGlldGYub3JnLCBBbGV4ZXkgTWVsbmlrb3YsIGRp bWUtY2hhaXJzQGlldGYub3JnLA0KPiA+IGRpbWVAaWV0Zi5vcmcsIGllc2dAaWV0Zi5vcmcNCj4g Pg0KPiA+IFNlZSBiZWxvdy4NCj4gPg0KPiA+ID4gQW0gMTAuMDUuMjAxNiB1bSAxNzowNCBzY2hy aWViIFN0ZXZlIERvbm92YW4NCj4gPHNyZG9ub3ZhbkB1c2Rvbm92YW5zLmNvbT46DQo+ID4gPg0K PiA+ID4gTWlyamEsDQo+ID4gPg0KPiA+ID4gUGxlYXNlIHNlZSBteSBjb21tZW50cyBpbmxpbmUu DQo+ID4gPg0KPiA+ID4gUmVnYXJkcywNCj4gPiA+DQo+ID4gPiBTdGV2ZQ0KPiA+ID4NCj4gPiA+ IE9uIDUvMTAvMTYgOTo0NiBBTSwgTWlyamEgS3VlaGxld2luZCAoSUVURikgd3JvdGU6DQo+ID4g Pj4gSGkgYWxsLA0KPiA+ID4+DQo+ID4gPj4gc29ycnkgZm9yIG15IGxhdGUgcmVwbHkuDQo+ID4g Pj4NCj4gPiA+PiBJIHRoaW5rIHRoZSBwYXJ0IHdpdGggdGhlIHR3byBxdWV1ZXMgd2FzIGEgbGl0 dGxlIGNvbmZ1c2luZy4gU29ycnkgZm9yIHRoYXQNCj4gYXMgd2VsbC4gSSBvcmlnaW5hbGx5IG1l YW50IHRvIGRlc2NyaWJlIHRoaXMgdG8gaWxsdXN0cmF0ZSB0aGUgcHJvYmxlbSByYXRoZXINCj4g dGhhbiBkZXNjcmliaW5nIGEgc29sdXRpb24uIEhvd2V2ZXIsIHVzaW5nIHR3byBxdWV1ZXMgKHdo aWNoIGZ1bGx5IGlzIGFuDQo+IGltcGxlbWVudGF0aW9uIGRldGFpbCkgZG9lcyBub3QgZXZlbiBt YXRjaCB0aGUgcHJvYmxlbSBjb3JyZWN0bHkgdGhhdCBJDQo+IHdhbnRlZCB0byBkZXNjcmliZeKA piB0aGUgYWN0dWFsbHkgcG9pbnQgd291bGQgYmUgYWJvdXQgdGhlIHNjaGVkdWxpbmcgdGhhdA0K PiBvbmUgd291bGQgbmVlZCB0byBpbXBsZW1lbnQgdG8gc2VydmUgdGhlIHF1ZXVlcy4gSGVyZSBt eSB0aGlua2luZyB3YXMNCj4gdGhhdCwgaW5zdGVhZCBvZiBpbXBsZW1lbnRpbmcgYSBzdHJpY3Qg cHJpb3JpdHkgc2NoZWR1bGluZywgeW91IGNvdWxkIGFsc28NCj4gaW1wbGVtZW50IGEgc2NoZW1l IHRoYXQgZ3VhcmFudGVlcyBhIGNlcnRhaW4gbWluaW11bSBzZXJ2aW5nIHJhdGUgZm9yIHRoZQ0K PiBub24tcHJpb3JpdHktZGVmaW5lZCByZXF1ZXN0cyB0byBhdm9pZCBmdWxsIHN0YXJ2YXRpb24u IEhvd2V2ZXIsIEkgZG9u4oCZdCB3YW50DQo+IHRvIGNvbmZ1c2UgeW91IGV2ZW4gbW9yZSBoZXJl LiBTbyBsZXQgbWUgdHJ5IHRvIHBoYXNlIG15IGNvbmNlcm4gYWdhaW4NCj4gKEnigJl2ZSBhbHNv IGVkaXRlZCBteSBkaXNjdXNzIHRleHQpOg0KPiA+ID4+DQo+ID4gPj4gSSBkb27igJl0IHRoaW5r IGl0IGlzIGEgZ29vZCBpZGVhIHRvIGFzc2lnbiBhIGRlZmF1bHQgcHJpb3JpdHkgdG8gbm9uLXBy aW9yaXR5LQ0KPiBkZWZpbmVkIHJlcXVlc3RzIGF0IGFsbC4gSWYgeW91IGhhdmUgaGlnaCBwcmlv cml0eSB0cmFmZmljIHRoYXQgZG9lcyBub3Qgc3VwcG9ydA0KPiB0aGlzIGV4dGVuc2lvbiAoeWV0 KSB0aGlzIHRyYWZmaWMgY291bGQgYmUgc3RhcnZlZCBieSBsb3dlciBwcmlvcml0eSB0cmFmZmlj IHdoZW4NCj4gYXNzaWduaW5nIGEgbWlkZGxlIHJhbmdlIHByaW9yaXR5LiBJIGRvbuKAmXQgdGhp bmsgdGhhdCBpcyB3aGF0IHlvdSB3YW50IHRvDQo+IGFjaGlldmUuDQo+ID4gPiBTUkQ+IEFjdHVh bGx5LCB0aGlzIGlzIHdoYXQgd2Ugd2FudCB0byBhY2hpZXZlLiAgSXQgaXMgYW4gcmVxdWlyZW1l bnQgdGhhdA0KPiBtZXNzYWdlcyBleHBsaWNpdGx5IG1hcmtlZCBhcyBoaWdoIHByaW9yaXR5IGdl dCB0cmVhdGVkIGV2ZW4gaWYgaXQgcmVzdWx0cyBpbg0KPiBzdGFydmluZyBsb3dlciBwcmlvcml0 eSBtZXNzYWdlcy4gIFRoZSBzdGFydmluZyBvZiBsb3dlciBwcmlvcml0eSBtZXNzYWdlcyBpcw0K PiBub3QgYW4gcHJvYmxlbSwgaXQgaXMgYSByZXF1aXJlbWVudC4NCj4gPg0KPiA+IEkgdGhpbmsg d2UgYXJlIHN0aWxsIHRhbGtpbmcgcGFzdCBlYWNoIG90aGVyLiBJZiB5b3UgZXhwbGljaXRseSBh c3NpZ24gYSBwcmlvcml0eSwNCj4gc3RhcnZhdGlvbiBtaWdodCBiZSBva2F5LiBIb3dldmVyLCBp ZiB5b3UgZG9u4oCZdCBoYXZlIGEgcHJpb3JpdHkgZXhwbGljaXRseQ0KPiBzaWduYWxlZCwgdGhl IHRyYW5zYWN0aW9uIG1pZ2h0IGhhdmUgYSB2ZXJ5IGhpZ2ggcHJpb3JpdHkgYnV0IHlvdSBqdXN0 IGRvbuKAmXQNCj4ga25vdyBhbmQgYnkgYXNzaWduaW5nIGEgcmFuZG9tIG1pZC1yYW5nZSBwcmlv cml0eSB0aGlzIGltcG9ydGFudCByZXF1ZXN0DQo+IGNvdWxkIGdldCBzdGFydmVkLg0KPiA+DQo+ ID4gTWlyamENCj4gPg0KPiA+DQo+ID4gPj4NCj4gPiA+PiBJIHRoaW5rIHRoaXMgcG9pbnQgaXMg ZXZlbiBtb3JlIHRydWUgd2l0aCByZXNwZWN0IHRvIHRoZSBkaXNjdXNzaW9uIHRoYXQNCj4gd2Vu dCBvbiB3aXRoIEFsaXNzYSBhbmQgQmVuLiBUaGVyZSwgeW91IHNhaWQsIHlvdeKAmWQgbmVlZCB0 byBkZWZpbmUgYSBwcmlvcml0eQ0KPiBzY2hlbWUgZm9yIGEgY2VydGFpbiBhcHBsaWNhdGlvbiBi ZWZvcmUgeW91IGNvdWxkIHVzZSBpdC4gR2l2ZW4gdGhhdCBpdCBkb2VzDQo+IG5vdCBtYWtlIHNl bnNlIHRvIGRlZmluZSBhIGRlZmF1bHQgcHJpb3JpdHkgdmFsdWUgdG8gZm9yIGFsbCB1c2VzIGJl Y2F1c2UNCj4gZGVwZW5kaW5nIG9mIHdpdGggcHJpb3JpdHkgcmFuZ2UgeW91IHNlbGVjdCB0byB1 c2UgaW4geW91ciBzY2hlbWUsIHRoZQ0KPiBkZWZhdWx0IG1pZ2h0IGJlIGEgbG93LCBoaWdoLCBv ciBtaWRyYW5nZSB2YWx1ZS4NCj4gPiA+IFNSRD4gSSBkb24ndCB1bmRlcnN0YW5kIHRoZSBzdGF0 ZW1lbnQgdGhhdCBpdCBkb2Vzbid0IG1ha2VzIHNlbnNlIHRvDQo+IGRlZmluZSBhIGRlZmF1bHQg cHJpb3JpdHkgdmFsdWUuICBXaGVuIGRlZmluaW5nIGEgcHJpb3JpdHkgc2NoZW1lL3Byb2ZpbGUg dG8gYmUNCj4gdXNlZCB3aXRoaW4gYSBEaWFtZXRlciBuZXR3b3JrLCBhbGwgYXBwbGljYXRpb25z IHdpbGwgbmVlZCB0byB0YWtlIHRoZQ0KPiAidW5pdmVyc2FsIiBkZWZhdWx0IHZhbHVlIGludG8g Y29uc2lkZXJhdGlvbi4gIFRoYXQgZGVmYXVsdCB2YWx1ZSB3aWxsIHRoZW4gYmUNCj4gdXNlZCBp biB0aGUgaGFuZGxpbmcgb2YgcmVxdWVzdHMgd2hlcmUgZWl0aGVyIHRoZSBhcHBsaWNhdGlvbiBk b2VzIG5vdCB5ZXQNCj4gaGF2ZSBhIGRlZmluZWQgcHJpb3JpdHkgc2NoZW1lIG9yIHdoZW4gdGhl IG5vZGUgb3JpZ2luYXRpbmcgdGhlIG1lc3NhZ2VzDQo+IGRvZXMgbm90IHlldCBzdXBwb3J0IHRo ZSBhcHBsaWNhdGlvbnMgcHJpb3JpdHkgc2NoZW1lLg0KPiA+ID4+DQo+ID4gPj4gVG8gbWFrZSBp dCBldmVuIG1vcmUgY2xlYXIgSSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0 ZXh0DQo+IGNoYW5nZSBpbiB0aGUgZG9jOg0KPiA+ID4+DQo+ID4gPj4gT0xEOg0KPiA+ID4+ICAg IERpYW1ldGVyIG5vZGVzIE1VU1QgaGF2ZSBhIGRlZmF1bHQgcHJpb3JpdHkgdG8gYXBwbHkgdG8g dHJhbnNhY3Rpb25zDQo+ID4gPj4gICAgdGhhdCBkbyBub3QgaGF2ZSBhbiBleHBsaWNpdCBwcmlv cml0eSBzZXQgaW4gdGhlIERSTVAgQVZQLg0KPiA+ID4+DQo+ID4gPj4gICAgRGlhbWV0ZXIgbm9k ZXMgU0hPVUxEIHVzZSB0aGUgUFJJT1JJVFlfMTAgcHJpb3JpdHkgYXMgdGhpcyBkZWZhdWx0DQo+ ID4gPj4gICAgdmFsdWUuDQo+ID4gPj4NCj4gPiA+PiBORVc6DQo+ID4gPj4gICAgRGlhbWV0ZXIg bm9kZXMgTUFZIHNldCBhIGRlZmF1bHQgcHJpb3JpdHkgdG8gYXBwbHkgdG8gdHJhbnNhY3Rpb25z DQo+ID4gPj4gICAgdGhhdCBkbyBub3QgaGF2ZSBhbiBleHBsaWNpdCBwcmlvcml0eSBzZXQgaW4g dGhlIERSTVAgQVZQIGlmIGl0IGlzDQo+ID4gPj4gICAga25vd24gdGhhdCB0aGUgdHJhbnNhY3Rp b25zIHRoYXQgZGVmaW5lIGEgaGlnaGVyIHByaW9yaXR5IHRoYW4gdGhlDQo+IGRlZmF1bHQNCj4g PiA+PiAgICBhcmUgYWx3YXlzIGhpZ2hlciBwcmlvcml0eSB0aGFuIHRoZSB0cmFuc2FjdGlvbnMg dGhhdCBkbyBub3QgZGVmaW5lDQo+ID4gPj4gICAgYSBwcmlvcml0eSBleHBsaWNpdGx5LiBUaGUg ZGVmYXVsdCB2YWx1ZSB3aWxsIGRlcGVuZCBvbiB0aGUgdXNlZCBwcmlvcml0eQ0KPiA+ID4+ICAg IHJhbmdlIGluIGEgZ2l2ZW4gZGVwbG95bWVudCBzZXR1cC4NCj4gPiA+IFNSRD4gT25lIG9mIHRo ZSBnb2FscyBvZiB0aGUgZGVmYXVsdCBwcmlvcml0eSB2YWx1ZSBpcyB0byBrZWVwIG5vZGVzIGxp a2UNCj4gRGlhbWV0ZXIgcmVsYXlzIGZyb20gbmVlZGluZyB0byB1bmRlcnN0YW5kIGFwcGxpY2F0 aW9uIHNlbWFudGljcy4gIFRoaXMNCj4gcmVxdWlyZW1lbnQgd291bGQgYnJlYWsgdGhvc2UgRGlh bWV0ZXIgcmVsYXlzIGFzIGFwcGxpY2F0aW9uIGxldmVsDQo+IGtub3dsZWRnZSBpcyByZXF1aXJl ZCB0byBrbm93IGlmIGEgbWVzc2FnZSB3aXRob3V0IGFuIGV4cGxpY2l0IHByaW9yaXR5IHZhbHVl DQo+IGlzIG9mIGEgaGlnaGVyIHByaW9yaXR5Lg0KPiA+ID4NCj4gPiA+IFNSRD4gSW4gYWRkaXRp b24sIHRoZXJlIGlzIG9ubHkgb25lIHByaW9yaXR5IHJhbmdlLCBhcyBkZWZpbmVkIGluIHRoZQ0K PiBkb2N1bWVudC4gIEl0IGlzIGltcG9ydGFudCB0aGF0IHRoZSByYW5nZSBiZSB0aGUgc2FtZSBh Y3Jvc3MgYWxsIGFwcGxpY2F0aW9ucw0KPiBmb3IgdGhlIG1lY2hhbmlzbSB0byB3b3JrLCBlc3Bl Y2lhbGx5IGluIG5vZGVzIGhhbmRsaW5nIG1lc3NhZ2VzIGZvcg0KPiBtdWx0aXBsZSBhcHBsaWNh dGlvbnMuDQo+ID4gPj4NCj4gPiA+PiAgICBEaWFtZXRlciBub2RlIFNIT1VMRCBub3QgYXNzaWdu DQo+ID4gPj4gICAgYSBkZWZhdWx0IHByaW9yaXR5IGlmIG5vIGFkZGl0aW9uYWwgaW5mb3JtYXRp b24gYWJvdXQgdGhlIHRyYW5zYWN0aW9uDQo+ID4gPj4gICAgdGhhdCBkbyBub3QgZGVmaW5lIGFu IGV4cGxpY2l0IHByaW9yaXR5IGlzIGtub3duLiBJbiB0aGlzIGNhc2UgdGhlDQo+ID4gPj4gICAg ZGlhbWV0ZXIgbm9kZSBTSE9VTEQgcHJvdmlkZSBhIG1pbmltdW0gc2VydmluZyByYXRlIGZvcg0K PiB0cmFuc2FjdGlvbiB0aGF0IGRvDQo+ID4gPj4gICAgbm90IGRlZmluZSBhbiBleHBsaWNpdCBw cmlvcml0eSB0byBhdm9pZCBmdWxsIHN0YXJ2YXRpb24gb2YgdGhlc2UNCj4gPiA+PiAgICB0cmFu c2FjdGlvbnMgdGhlIG1heSBvciBtYXkgbm90IGhhdmUgYSBoaWdoZXIgcHJpb3JpdHkgdGhhbiBv dGhlcg0KPiA+ID4+ICAgIHRyYW5zYWN0aW9ucyB0aGF0IHByb3ZpZGUgaW5mb3JtYXRpb24gYWJv dXQgdGhlaXIgcHJpb3JpdHkuDQo+ID4gPiBTUkQ+IFRoaXMgaXMgZXhwbGljaXRseSBOT1QgYSBy ZXF1aXJlbWVudC4gIEl0IGlzIGFjY2VwdGFibGUgdG8gc3RhcnZlIGxvd2VyDQo+IHByaW9yaXR5 IG1lc3NhZ2VzLg0KPiA+ID4+DQo+ID4gPj4gSSBob3BlIHRoYXQgbWFrZXMgc2Vuc2UgdG8geW91 LiBQbGVhc2UgcHJvcG9zZSBlZGl0cyAoaWYgbm90KSENCj4gPiA+IFNSRD4gSSBkb24ndCB5ZXQg c2VlIGEgcmVhc29uIHRvIGNoYW5nZSB0aGUgb3JpZ2luYWwgd29yZGluZy4NCj4gPiA+Pg0KPiA+ ID4+IE1pcmphDQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+PiBBbSAwNS4wNS4yMDE2IHVtIDA4OjMy IHNjaHJpZWIgQWxleGV5IE1lbG5pa292DQo+IDxhYW1lbG5pa292QGZhc3RtYWlsLmZtPjoNCj4g PiA+Pj4NCj4gPiA+Pj4gSGkgTWlyamEsDQo+ID4gPj4+DQo+ID4gPj4+IE9uIFdlZCwgTWF5IDQs IDIwMTYsIGF0IDA0OjUwIFBNLCBNaXJqYSBLdWVobGV3aW5kIChJRVRGKSB3cm90ZToNCj4gPiA+ Pj4+IEhpIEphbmV0LA0KPiA+ID4+Pj4NCj4gPiA+Pj4+IHRoZXJlIGFyZSBjbGVhcmx5IG1vcmUg b3B0aW9ucyB0aGFuIHRoZSB0d28gbWVudGlvbiBiZWxvdy4NCj4gPiA+Pj4+DQo+ID4gPj4+PiBF LmcuIG9uZSBvcHRpb24gaXMgdGhlIG9uZSBleHBsYWluZWQgaW4gbXkgaW5pdGlhbCBjb21tZW50 Og0KPiA+ID4+Pj4gaGhhdmluZyB0d28gcXVldWVzLCB0aGF0IGFyZSBib3RoIHNlcnZlZCB3aXRo IGEgY2VydGFpbiByYXRlLg0KPiA+ID4+Pj4NCj4gPiA+Pj4+IEnigJltIHN1cmUgdGhlcmUgYXJl IG1vcmUgKGFuZCBwb3RlbnRpYWxseSBtb3JlIGNvbXBsZXgpIHNvbHV0aW9ucw0KPiA+ID4+Pj4g dG8gdGhpcyBwcm9ibGVtIGFzIHdlbGwuDQo+ID4gPj4+Pg0KPiA+ID4+Pj4gQXNzaWduaW5nIGFu IGFyYml0cmFyeSBwcmlvcml0eSBpcyBub3QgdGhlIHJpZ2h0IG9wdGlvbiBmcm9tIG15DQo+ID4g Pj4+PiBwb2ludCBvZiB2aWV3IGFuZCBjYW4gYWN0dWFsbHkgaHVydCB0aGUgc3lzdGVtcy4NCj4g PiA+Pj4gSSBob3BlIHRoaXMgd2lsbCBoZWxwIHRvIGNsYXJpZnkgdGhpbmdzOg0KPiA+ID4+Pg0K PiA+ID4+PiBPbmUgcG9pbnQgb2YgYXNzaWduaW5nIGRlZmF1bHQgcHJpb3JpdHkgaXMgdGhhdCBh cyB0aGlzIGlzIGFuDQo+ID4gPj4+IGV4dGVuc2lvbiwgdGhlcmUgaXMgYSBkZXNpcmUgdG8gYXZv aWQgdXBncmFkaW5nIGFsbCBjbGllbnRzIG9uIHRoZQ0KPiA+ID4+PiBuZXR3b3JrLCBhcyB0aGF0 IHdvdWxkIGJlIGVmZmVjdGl2ZWx5IHRyeWluZyB0byBkZXBsb3kgYSBuZXcNCj4gPiA+Pj4gcHJv dG9jb2wuIENvbnNpZGVyIGEgbmV0d29yayB3aGVyZSBwcm94aWVzIGFuZCBzZXJ2ZXJzIHVuZGVy c3RhbmQNCj4gPiA+Pj4gdGhpcyBleHRlbnNpb24gYW5kIG5vbmUgb2YgdGhlIGNsaWVudHMgZG8u IFRoZW4gZGVmYXVsdCBwcmlvcml0eQ0KPiA+ID4+PiB3b3VsZCBiZSBhc3NpZ25lZCB0byBhbGwg dHJhZmZpYyBhbmQgdGhlIGJlaGF2aW91ciBvZiB0aGUgc3lzdGVtDQo+ID4gPj4+IGlzIHVuY2hh bmdlZCBmcm9tIHRoZSBjYXNlIHdoZW4gdGhlIGV4dGVuc2lvbiBpcyBub3QgZGVwbG95ZWQuIFRo ZQ0KPiA+ID4+PiBkZWZhdWx0IHByaW9yaXR5IG9ubHkgbWFrZXMgYSBkaWZmZXJlbmNlIGlmIHRo ZXJlIGlzIGEgbWl4dHVyZSBvZg0KPiA+ID4+PiBjbGllbnRzIGltcGxlbWVudGluZyB0aGlzIGV4 dGVuc2lvbiBhbmQgY2xpZW50cyB0aGF0IGRvbid0Lg0KPiA+ID4+Pg0KPiA+ID4+PiBCZXN0IFJl Z2FyZHMsDQo+ID4gPj4+IEFsZXhleQ0KPiA+ID4+Pg0KPiA+ID4+Pj4gTWlyamENCj4gPiA+Pj4+ DQo+ID4gPj4+Pg0KPiA+ID4+Pj4+IEFtIDA0LjA1LjIwMTYgdW0gMTc6NDUgc2NocmllYiBHdW5u LCBKYW5ldCBQDQo+IDxKYW5ldC5HdW5uQGNzcmEuY29tPjoNCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+ IE15IGNvbW1lbnQgYmVsb3cuDQo+ID4gPj4+Pj4gSmFuZXQNCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPj4+Pj4gRnJvbTogRGlNRSBbbWFpbHRv OmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pcmphDQo+ID4gPj4+Pj4gS3Vl aGxld2luZCAoSUVURikNCj4gPiA+Pj4+PiBTZW50OiBXZWRuZXNkYXksIE1heSAwNCwgMjAxNiAx MDozMSBBTQ0KPiA+ID4+Pj4+IFRvOiBBbGV4ZXkgTWVsbmlrb3YgPGFhbWVsbmlrb3ZAZmFzdG1h aWwuZm0+DQo+ID4gPj4+Pj4gQ2M6IGRyYWZ0LWlldGYtZGltZS1kcm1wQGlldGYub3JnOyBkaW1l LWNoYWlyc0BpZXRmLm9yZzsNCj4gPiA+Pj4+PiBkaW1lQGlldGYub3JnOyBUaGUgSUVTRyA8aWVz Z0BpZXRmLm9yZz4NCj4gPiA+Pj4+PiBTdWJqZWN0OiBSZTogW0RpbWVdIE1pcmphIEvDvGhsZXdp bmQncyBEaXNjdXNzIG9uDQo+ID4gPj4+Pj4gZHJhZnQtaWV0Zi1kaW1lLWRybXAtMDU6ICh3aXRo IERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBIaSBBbGV4ZXksDQo+ ID4gPj4+Pj4NCj4gPiA+Pj4+PiBzZWUgYmVsb3cuDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBUaGUg cG9pbnQgaXMsIGlmIHlvdSBleHBsaWNpdGx5IGluZGljYXRlIHRoYXQgeW91IGhhdmUgYSBsb3dl ciBwcmlvcml0eSwNCj4geW91IGFyZSBva2F5IHRvIGJlIHN0YXJ2ZWQuIEhvd2V2ZXIsIGlmIHlv dSBkb27igJl0IGluZGljYXRlIGFueXRoaW5nIChtYXliZQ0KPiBqdXN0IGJlY2F1c2UgeW91IGhh dmUgbm90IGJlZW4gYXdhcmUgdGhhdCBpdCBpcyBwb3NzaWJsZSB0byBkbyBzbyksIHlvdSBtaWdo dA0KPiBoYXZlIHRoZSBzYW1lIG9yIGV2ZW4gYSBoaWdoZXIgcHJpb3JpdHksIGFuZCBpbiB0aGlz IGNhc2UgaXTigJlzIG5vdCBva2F5IHRvIGJlDQo+IHN0YXJ2ZWQuDQo+ID4gPj4+Pj4NCj4gPiA+ Pj4+PiBNaXJqYQ0KPiA+ID4+Pj4+IDxKUEc+IElmIGEgbWVzc2FnZSBjb21lcyBpbiB3aXRob3V0 IGEgcHJpb3JpdHksIGludG8gYSBzeXN0ZW0NCj4gPiA+Pj4+PiB3aGljaCBzZXJ2ZXMgbWVzc2Fn ZXMgYmFzZWQgb24gcHJpb3JpdHkgKHJlZ2FyZGxlc3Mgb2YgdGhlDQo+ID4gPj4+Pj4gc3BlY2lm aWMgbWVjaGFuaXNtcyl5b3UgaGF2ZSB0d28gb3B0aW9ucw0KPiA+ID4+Pj4+IDEtIERpc2NhcmQg dGhlIG1lc3NhZ2UgKE5vdCBhIGdvb2QgaWRlYSBpbiBtb3N0IHN5c3RlbXMpDQo+ID4gPj4+Pj4g MiAtIEFzc2lnbiB0aGUgbWVzc2FnZSBhbiBBUkJJVFJBUlkgcHJpb3JpdHkgKHdlIGNhbGwgdGhp cw0KPiA+ID4+Pj4+IGFyYml0cmFyeSB2YWx1ZSB0aGUgImRlZmF1bHQgcHJpb3JpdHkiKQ0KPiA+ ID4+Pj4+DQo+ID4gPj4+Pj4gWW91IGNhbiAoYW5kIHByb2JhYmx5IHdpbGwpIGFyZ3VlICd0aWwg dGhlIGNvd3MgY29tZSBob21lIG9uIHdoYXQNCj4gdGhhdCBhcmJpdHJhcnkvZGVmYXVsdCB2YWx1 ZSBTSE9VTEQgQkUuICBBbmQgZGlmZmVyZW50IHN5dGVtcy9hcHBsaWNhdGlvbnMNCj4gbWlnaHQg aGF2ZSBkaWZmZXJlbnQgImRlZmF1bHQgdmFsdWVzIi4NCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+IEJ1 dCBJIGRvbid0IHRoaW5rIHRoZXJlIHNob3VsZCBiZSBhbnkgYXJndW1lbnQgdGhhdCwgaWYgYSBt ZXNzYWdlDQo+IGNvbWVzIGluIHdpdGhvdXQgYSBwcmlvcml0eSwgeW91IG5lZWQgdG8gYXNzaWdu IGl0IGEgcHJpb3JpdHkuDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiA8L0pQRz4NCj4gPiA+Pj4+Pg0K PiA+ID4+Pj4+DQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4+Pj4+IERpTUUgbWFpbGluZyBsaXN0DQo+ID4g Pj4+Pj4gRGlNRUBpZXRmLm9yZw0KPiA+ID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZGltZQ0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gVGhpcyBlbGVjdHJvbmljIG1l c3NhZ2UgdHJhbnNtaXNzaW9uIGNvbnRhaW5zIGluZm9ybWF0aW9uIGZyb20NCj4gQ1NSQSB0aGF0 IG1heSBiZSBhdHRvcm5leS1jbGllbnQgcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnkgb3IgY29uZmlk ZW50aWFsLiBUaGUNCj4gaW5mb3JtYXRpb24gaW4gdGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIG9u bHkgZm9yIHVzZSBieSB0aGUgaW5kaXZpZHVhbChzKSB0bw0KPiB3aG9tIGl0IGlzIGFkZHJlc3Nl ZC4gSWYgeW91IGJlbGlldmUgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9y LA0KPiBwbGVhc2UgY29udGFjdCBtZSBpbW1lZGlhdGVseSBhbmQgYmUgYXdhcmUgdGhhdCBhbnkg dXNlLCBkaXNjbG9zdXJlLA0KPiBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGUgY29udGVu dHMgb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuDQo+IE5PVEU6IFJlZ2Fy ZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0byBiaW5kIENT UkEgdG8gYW55DQo+IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBl eHBsaWNpdCB3cml0dGVuIGFncmVlbWVudCBvcg0KPiBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhw cmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBlbWFpbCBmb3Igc3VjaCBwdXJwb3NlLg0KPiA+ ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gRGlNRSBtYWlsaW5nIGxpc3QNCj4gPiBEaU1FQGlldGYub3JnDQo+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo+ID4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19fX19f X19fX18NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPg0KPiA+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPiA+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLA0KPiA+IGV4cGxvaXRl cyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3Nh Z2UNCj4gPiBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzDQo+IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KPiBPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdQ0KPiBmYWxzaWZpZS4gTWVyY2kuDQo+ID4NCj4gPiBUaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3INCj4gPiBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hv dWxkIG5vdCBiZQ0KPiBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp c2F0aW9uLg0KPiA+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlDQo+IHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLg0KPiA+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuDQo+IG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4NCj4gPiBUaGFuayB5b3UuDQo+ID4NCg0KCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl cgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4K SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91 LgoK From nobody Wed May 11 09:07: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 9E13F12D1C9; Wed, 11 May 2016 09:07:25 -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 MmGwEqSmD4TK; Wed, 11 May 2016 09:07:18 -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 3794712B008; Wed, 11 May 2016 09:07:18 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 8D6A2264265; Wed, 11 May 2016 18:07:16 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.21]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 62B844C063; Wed, 11 May 2016 18:07:16 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0294.000; Wed, 11 May 2016 18:07:16 +0200 From: To: Steve Donovan , "Mirja Kuehlewind (IETF)" , Alexey Melnikov Thread-Topic: =?utf-8?B?W0RpbWVdIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWll?= =?utf-8?Q?tf-dime-drmp-05:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHRqsu3MGSn2nqArkOEVymcyKpnwZ+yiAMAgAAPPoCAANohAIAAAhkAgAAle4CAAEbHgA== Date: Wed, 11 May 2016 16:07:15 +0000 Message-ID: <3226_1462982836_573358B4_3226_13576_1_6B7134B31289DC4FAF731D844122B36E01E60643@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> <57324CE8.6040109@usdonovans.com> <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net> <6EF5DC36-1BEF-47EE-BB3B-83BE5E115AE3@kuehlewind.net> <573331DF.2090504@usdonovans.com> In-Reply-To: <573331DF.2090504@usdonovans.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.11.150616 Archived-At: Cc: "draft-ietf-dime-drmp@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 11 May 2016 16:07:25 -0000 SGksDQoNCkkgdGhpbmsgdGhhdCBpdCBpcyBpbXBvcnRhbnQgdG8gcmVtaW5kIHRoYXQgIkRpYW1l dGVyIGFwcGxpY2F0aW9ucyIgYXJlIHNwZWNpZmljIGFwcGxpY2F0aW9ucyBvZiB0aGUgRGlhbWV0 ZXIgcHJvdG9jb2wgaW4gdGhlIEFBQSBuZXR3b3JrLCBpbiB0aGUgY29yZSBuZXR3b3JrL2JhY2st ZW5kIGluZnJhc3RydWN0dXJlIG1hbmFnZWQgYnkgYW4gb3BlcmF0b3IgbmV0d29yay4NCkluIHRo ZSBleGFtcGxlIGJlbG93LCB0aGUga2V5IHBvaW50IGlzIHRvIGNoYXJhY3Rlcml6ZSB0aGUgdHJh ZmZpYyBhdCB0aGUgZW50cnkgb2YgdGhlIGNvcmUgbmV0d29yayBieSBhIEFBQSBjbGllbnQgaW4g ZnJvbnQgb2YgYSBub24tRGlhbWV0ZXIgYmFzZWQgbmV0d29yay4gRXhhbXBsZXMgb2Ygc3VjaCBB QUEgY2xpZW50IGFyZSBOZXR3b3JrIGFjY2VzcyBzZXJ2ZXJzIG9yIElQIGdhdGV3YXkgaW4gbW9i aWxlIG5ldHdvcmtzLg0KDQpBIEFBQSBjbGllbnQgc3VwcG9ydGluZyB0aGUgbmV3IGV4dGVuc2lv biB3aWxsIGhhdmUgYSBzZXQgb2YgY3JpdGVyaWEgdG8gZGV0ZXJtaW5lIHRoZSBwcmlvcml0eSB2 YWx1ZSB0byBpbmNsdWRlIGluIGV2ZXJ5IGluaXRpYXRlZCBEaWFtZXRlciBtZXNzYWdlLiANClRo ZXkgd2lsbCBiZSB0aGVuIGFibGUgdG8gbWFrZSB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBwcmlv cml0eSByZXF1aXJlbWVudHMgZm9yIGVhY2ggInNlcnZpY2UiIChlLmcuIGVtZXJnZW5jeSBkb2N0 b3JzL2ZpcmVmaWdodGVycy92b2ljZSBzZXJ2aWNlcyBldGMuKS4NClRoZSBkZXRlcm1pbmF0aW9u IG1lY2hhbmlzbSBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBkb2N1bWVudCBidXQgYW4gZXhhbXBs ZSBjb3VsZCBiZSB0byByZWx5IG9uIGFub3RoZXIgcHJpb3JpdHkgaW5kaWNhdGlvbiBjb252ZXll ZCBpbiBzaWduYWxpbmcgcGxhbmVzIHVzZWQgaW4gdGhlIGZyb250LWVuZCBuZXR3b3JrLCBleC4g aW4gU0lQIG9yIGRpcmVjdGx5IGF0IHRoZSBJUCBsYXllci4NCg0KSWYgdGhlIEFBQSBjbGllbnQg YXJlIG5vdCB1cGdyYWRlZCB0byBzdXBwb3J0IHRoZSBuZXcgZXh0ZW5zaW9uLCB0aGVyZSBpcyBu byB3YXkgZm9yIHRoZSBBQUEgY2xpZW50IHRvIGluZGljYXRlIHRoZSBwcmlvcml0eSB0byBhcHBs eSBtZXNzYWdlIHBlciBtZXNzYWdlLiBJdCB3aWxsIGp1c3Qgc2VuZCB0aGUgRGlhbWV0ZXIgbWVz c2FnZXMgdG8gb3RoZXIgRGlhbWV0ZXIgcGVlcnMgYXMgZG9uZSB0b2RheS4NClRoZSBvdGhlciBw ZWVycyBjYW4gYmUgYSBEaWFtZXRlciBzZXJ2ZXIgb3IgYSByZWxheS9wcm94eS4gQW5kIHRoZXNl IHBlZXJzIGNhbiBiZSB1cGdyYWRlZCBvciBub3QuIElmIHRoZXkgYXJlIHVwZ3JhZGVkLCB0aGV5 IHdpbGwgaGF2ZSB0byBjb3BlIHdpdGggbWVzc2FnZXMgd2l0aCBvciB3aXRob3V0IHByaW9yaXR5 IGluZGljYXRpb24uIEFuZCBpbiBzdWNoIGEgY2FzZSwgdGhlIHJlY29tbWVuZGF0aW9uIGlzIHRv IGhhbmRsZSB1bm1hcmtlZCBEaWFtZXRlciBtZXNzYWdlcyBhcyBpZiB0aGV5IHdlcmUgaW5jbHVk ZWQgdGhlIHZhbHVlIDEwIHdoZW4gbm8gb3RoZXIgaW5mb3JtYXRpb24gaXMgYXZhaWxhYmxlLiAN Cg0KTm93LCBpZiB5b3UgY2FuIGlkZW50aWZ5IHRoYXQgdGhlIHVubWFya2VkIG1lc3NhZ2VzIG11 c3QgYmUgaGFuZGxlZCB3aXRoIGEgaGlnaGVyIHByaW9yaXR5IGV2ZW4gaWYgbm90IG1hcmtlZCwg eW91IGNhbiBzdGlsbCBkbyBpdCwgdXNpbmcgb3BlcmF0b3IgZGVmaW5lZCBwb2xpY2llcyBvciBh cHBsaWNhdGlvbi1zcGVjaWZpYyBoYW5kbGluZy4gVGhpcyBjYW4gYmUgZG9uZSBwZXIgaW50ZXJm YWNlIG9yIGF0IHRoZSBEaWFtZXRlciBhcHBsaWNhdGlvbiBsZXZlbCwgc2F5aW5nIG1lc3NhZ2Ug eCBmcm9tIGFwcGxpY2F0aW9uIFkgaGFzIGhpZ2hlciBwcmlvcml0eSB0aGFuIG1lc3NhZ2UgQSBm cm9tIGFwcGxpY2F0aW9uIEIuIEJ1dCB0aGUgbGFzdCBleGFtcGxlIChoYW5kbGluZyBhdCB0aGUg RGlhbWV0ZXIgbGV2ZWwpIGlsbHVzdHJhdGVzIHRoYXQgdGhlIG5vZGVzIGhhbmRsaW5nIHRoZSBt ZXNzYWdlIHdpdGhvdXQgcHJpb3JpdHkgbmVlZCB0byBiZSBhcHBsaWNhdGlvbi1hd2FyZSwgaS5l LiBhYmxlIHRvIHVuZGVyc3RhbmQgdGhlIHNlbWFudGljIG9mIHRoZSByZWNlaXZlZCBtZXNzYWdl cywgYW5kIHRoZXkgaGF2ZSB0byBiZSBlaXRoZXIgYSBEaWFtZXRlciBwcm94eSBvciBhIERpYW1l dGVyIHNlcnZlciAoYXMgZGVmaW5lZCBpbiB0aGUgUkZDIDY3MzMpLCB3aGljaCBleGNsdWRlIERp YW1ldGVyIHJlbGF5cyB0aGF0IGFyZSBhcHBsaWNhdGlvbi1hZ25vc3RpYy4NCg0KVGhlIHdob2xl IHB1cnBvc2Ugb2YgdGhpcyBzb2x1dGlvbiBpcyB0byBkZWZpbmUgYSBtZWNoYW5pc20gdGhhdCBj YW4gd29yayB3aXRoIGFwcGxpY2F0aW9uLWFnbm9zdGljIG5vZGVzIChpbmNsdWRpbmcgcmVsYXlz KSBhbmQgd2l0aG91dCB0aGUgcmVzb3J0IHRvIHNwZWNpZmljIG9wZXJhdG9yIHBvbGljaWVzLiBB ZCB0aGlzIGluY2x1ZGVzIHRoZSBuZWVkIGZvciBhIHJlY29tbWVuZGVkIGRlZmF1bHQgaGFuZGxp bmcgb2YgdW5tYXJrZWQgbWVzc2FnZXMuDQoNCkkgaG9wZSB0aGF0IGl0IGhlbHBzIHRvIGNsYXJp ZnkgdGhlIGRpc2N1c3Npb24uDQoNCkFuZCBJIGFncmVlIHdpdGggdGhlIHJlc3BvbnNlcyBwcm92 aWRlZCBieSBTdGV2ZSwgSmFuZXQgYW5kIEFsZXhleS4NCg0KUmVnYXJkcywNCg0KTGlvbmVsDQoN Cj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IFN0ZXZlIERvbm92YW4gW21h aWx0bzpzcmRvbm92YW5AdXNkb25vdmFucy5jb21dDQo+IEVudm95w6nCoDogbWVyY3JlZGkgMTEg bWFpIDIwMTYgMTU6MjINCj4gw4DCoDogTWlyamEgS3VlaGxld2luZCAoSUVURik7IEFsZXhleSBN ZWxuaWtvdg0KPiBDY8KgOiBkcmFmdC1pZXRmLWRpbWUtZHJtcEBpZXRmLm9yZzsgZGltZS1jaGFp cnNAaWV0Zi5vcmc7IGRpbWVAaWV0Zi5vcmc7DQo+IFRoZSBJRVNHOyBHdW5uLCBKYW5ldCBQDQo+ IE9iamV0wqA6IFJlOiBbRGltZV0gTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQt aWV0Zi1kaW1lLWRybXAtMDU6DQo+ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBN aXJqYSwNCj4gDQo+IFRvZGF5LCB3aXRob3V0IERSTVAsIGFsbCBvZiB0aGUgdHJhZmZpYyBpcyB0 cmVhdGVkIHRoZSBzYW1lIGJ5IHJlbGF5cyBhcyByZWxheXMNCj4gZG8gbm90LCBieSBkZXNpZ24s IGhhdmUgYXBwbGljYXRpb24gbGV2ZWwga25vd2xlZGdlLiAgSW4gbWFueSBjYXNlcywgc2VydmVy cw0KPiBkbyBub3QgaGF2ZSBlbm91Z2ggY29udGV4dCB0byBkZXRlcm1pbmUgdGhlIHByaW9yaXR5 IG9mIGEgbWVzc2FnZS4gIEluDQo+IGdlbmVyYWwsIHRoZSBEaWFtZXRlciBjbGllbnQgaXMgdGhl IG9ubHkgb25lIHdobyBoYXMgdGhhdCBrbm93bGVkZ2UuDQo+IA0KPiBZb3UgYXJlIGNvcnJlY3Qg dGhhdCBpZiB0aGUgZmlyZWZpZ2h0ZXJzIHRyYWZmaWMgZG9lcyBub3QgZ2V0IHByaW9yaXR5IG1h cmtlZA0KPiB0aGVuIHRoZSBmaXJlZmlnaHRlcnMgdHJhZmZpYyBpcyB0aHJvd24gaW50byB0aGUg ZGVmYXVsdCBidWNrZXQgd2l0aCBhbGwgb2YgdGhlDQo+IG90aGVyIG5vbiBlbWVyZ2VuY3kgdHJh ZmZpYy4NCj4gDQo+IFRoZSBvbmx5IHdheSB0byBhdm9pZCB0aGlzIGlzIHRvIHVwZ3JhZGUgdGhl IGZpcmVmaWdodGVycyBzeXN0ZW0uIFRoZXJlIGlzIG5vDQo+IHdheSwgd2l0aG91dCBhIGNsaWVu dCBtYXJraW5nIGEgcmVxdWVzdHMgcHJpb3JpdHksIGZvciBhbiBhZ2VudCB0byB1bmRlcnN0YW5k DQo+IHRoZSBwcmlvcml0eSBvZiBhIG1lc3NhZ2UuICBBZ2VudHMgZG9uJ3QgaGF2ZSBhcHBsaWNh dGlvbiBsZXZlbCBrbm93bGVkZ2UuDQo+IFlvdXIgcHJvcG9zYWwgb2YgaGF2aW5nIERpYW1ldGVy IG5vZGVzIHVuZGVyc3RhbmQgdGhlIGludHJpbnNpYyBwcmlvcml0eSBvZiBhDQo+IG1lc3NhZ2Ug d2l0aG91dCBhbiBpbXBsaWNpdCBwcmlvcml0eSBtYXJraW5nIGlzIG5vdCBwb3NzaWJsZSBpbiBE aWFtZXRlci4gIFRoaXMNCj4gaXMgd2h5IHRoZSB3b3JraW5nIGdyb3VwIGRlY2lkZWQgb24gdGhl IERSTVAgbWVjaGFuaXNtLg0KPiANCj4gU3RldmUNCj4gDQo+IE9uIDUvMTEvMTYgNjowNyBBTSwg TWlyamEgS3VlaGxld2luZCAoSUVURikgd3JvdGU6DQo+ID4gT2theSBsZXQgbWUgZ28gZm9yIGFu IGV4YW1wbGUgaGVyZSBhbmQgc2VlIGlmIHRoYXQgY2FuIGJlIGEgdXNlIGNhc2UgdGhhdA0KPiB3 ZSBhcmUgdGFsa2luZyBhYm91dC4NCj4gPg0KPiA+IFlvdSBoYXZlIGEgc3lzdGVtIHdoZXJlIHNv bWUgY2xpZW50cyBydW4gYSBjb21tdW5pY2F0aW9uIHNlcnZpY2UgZm9yDQo+IGVtZXJnZW5jeSBk b2N0b3JzIGFzIHdlbGwgYXMgZm9yIGZpcmVmaWdodGVycyBhbmQgdGhlbiB0aGVyZSBhcmUgYWxz byDigJpub3JtYWzigJgNCj4gdXNlcnMgdGhhdCBydW4gc29tZSBraW5kIG9mIGNvbW11bmljYXRp b24gc2VydmljZS4NCj4gPg0KPiA+IE5vdyB5b3UgYWN0dWFsbHkgaGF2ZSBhbiBlbWVyZ2VuY3k6 IHNvbWUgcGFydCBvZiB0aGUgc3lzdGVtIGlzIGRvd24gYW5kDQo+IHRoZSBudW1iZXIgb2YgcmVx dWVzdCBpcyBoaWdoIHN1Y2ggdGhhdCB0aGUgc3lzdGVtIGlzIG92ZXJsb2FkZWQuDQo+ID4NCj4g PiBCb3RoIHRoZSBlbWVyZ2VuY3kgZG9jdG9ycyBoYXZlIHdvdWxkIGhhdmUgdHdvIGRpZmZlcmVu dCBwcmlvcml0eQ0KPiBjbGFzc2VzLCBvbmUgZm9yIGltcG9ydGFudCBtZXNzYWdlIGFib3V0IGlu c3RydWN0aW9uICh3aGF0IGFuZCB3aGVyZQ0KPiBwZW9wbGUgc2hvdWxkIGRvIHNvbWV0aGluZykg YW5kIG9uZSBmb3IgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZQ0KPiBkb2N0b3JzL2ZpcmVmaWdo dGVycyB3aGljaCBoYXMgc3RpbGwgaGlnaGVyIHByaW9yaXR5IHRoYW4gYW55IG90aGVyDQo+IGNv bW11bmljYXRpb24gb2YgdGhlIG90aGVyIHBlb3BsZSAoYXMgeW91IGFzc3VtZSBkb2N0b3JzIGFu ZCBmaXJlZmlnaHRlcnMNCj4gYXJlIG1vcmUgcmVzcG9uc2libGUgdG8gbm90IG1pc3VzZSB0aGlz IGNvbW11bmljYXRpb24gY2hhbm5lbCkuDQo+ID4NCj4gPiBOb3cgb25seSB0aGUgZW1lcmdlbmN5 IGRvY3RvcnMgY29tbXVuaWNhdGlvbiBzZXJ2aWNlIHdhcyB1cGdyYWRlZCB0bw0KPiB1c2UgdGhp cyBleHRlbnNpb24sIGJ1dCB0aGUgZmlyZWZpZ2h0ZXLigJlzIGFkbWluaXN0cmF0aW9ucyBpcyBq dXN0IHRvbyBzbG93IG9yDQo+IHRoZXkgY3VycmVudGx5IGhhdmUgbm90IGVub3VnaCBtb25leSBi ZWNhdXNlIHRoZXkgaGF2ZSBzcGVjaWFsaXplZA0KPiBleHBlbnNpdmUgaGFyZHdhcmUgYW5kIHNv ZnR3YXJlIHRoYXQgaXMgbm90IGVhc3kgdG8gY2hhbmdlLg0KPiA+DQo+ID4gSXMgaXQgb2theSBp biB0aGlzIHNpdHVhdGlvbiB0aGF0IHRoZSBwcml2YXRlIGNoYXQgb2YgdHdvIGRvY3RvcnMgYWJv dXQgdGhlaXINCj4gbGFzdCBza2ktaG9saWRheXMgc3RhcnZlcyByZXF1ZXN0cyB0byBhY2Nlc3Mg dGhlIG5ldHdvcmsgdG8gc2VuZCBpbnN0cnVjdG9yDQo+IG1lc3NhZ2UgdG8gdGhlIGZpcmVmaWdo dGVycz8NCj4gPg0KPiA+IChBbmQgaG93IGRvIGkgbWFrZSBzdXJlIHRoYXQgdGhhdCBhbGwgb3Ro ZXIgb3RoZXIgcmVxdWVzdHMgYWN0dWFsbHkgc2VsZWN0IGENCj4gbG93ZXIgcHJpb3JpdHkgdGhh biAxMOKApj8gQnV0IHRoYXTigJlzIGEgZGlmZmVyZW50IHF1ZXN0aW9u4oCmKQ0KPiA+DQo+ID4g TWlyamENCj4gPg0KPiA+DQo+ID4+IEFtIDExLjA1LjIwMTYgdW0gMDY6NTkgc2NocmllYiBBbGV4 ZXkgTWVsbmlrb3YNCj4gPGFhbWVsbmlrb3ZAZmFzdG1haWwuZm0+Og0KPiA+Pg0KPiA+PiBIaSBN aXJqYSwNCj4gPj4NCj4gPj4gT24gMTAgTWF5IDIwMTYsIGF0IDE3OjU5LCBNaXJqYSBLdWVobGV3 aW5kIChJRVRGKQ0KPiA8aWV0ZkBrdWVobGV3aW5kLm5ldD4gd3JvdGU6DQo+ID4+DQo+ID4+Pj4+ IEkgZG9u4oCZdCB0aGluayBpdCBpcyBhIGdvb2QgaWRlYSB0byBhc3NpZ24gYSBkZWZhdWx0IHBy aW9yaXR5IHRvIG5vbi1wcmlvcml0eS0NCj4gZGVmaW5lZCByZXF1ZXN0cyBhdCBhbGwuIElmIHlv dSBoYXZlIGhpZ2ggcHJpb3JpdHkgdHJhZmZpYyB0aGF0IGRvZXMgbm90IHN1cHBvcnQNCj4gdGhp cyBleHRlbnNpb24gKHlldCkgdGhpcyB0cmFmZmljIGNvdWxkIGJlIHN0YXJ2ZWQgYnkgbG93ZXIg cHJpb3JpdHkgdHJhZmZpYyB3aGVuDQo+IGFzc2lnbmluZyBhIG1pZGRsZSByYW5nZSBwcmlvcml0 eS4gSSBkb27igJl0IHRoaW5rIHRoYXQgaXMgd2hhdCB5b3Ugd2FudCB0bw0KPiBhY2hpZXZlLg0K PiA+Pj4+IFNSRD4gQWN0dWFsbHksIHRoaXMgaXMgd2hhdCB3ZSB3YW50IHRvIGFjaGlldmUuICBJ dCBpcyBhbiByZXF1aXJlbWVudA0KPiB0aGF0IG1lc3NhZ2VzIGV4cGxpY2l0bHkgbWFya2VkIGFz IGhpZ2ggcHJpb3JpdHkgZ2V0IHRyZWF0ZWQgZXZlbiBpZiBpdCByZXN1bHRzDQo+IGluIHN0YXJ2 aW5nIGxvd2VyIHByaW9yaXR5IG1lc3NhZ2VzLiAgVGhlIHN0YXJ2aW5nIG9mIGxvd2VyIHByaW9y aXR5IG1lc3NhZ2VzIGlzDQo+IG5vdCBhbiBwcm9ibGVtLCBpdCBpcyBhIHJlcXVpcmVtZW50Lg0K PiA+Pj4gSSB0aGluayB3ZSBhcmUgc3RpbGwgdGFsa2luZyBwYXN0IGVhY2ggb3RoZXIuDQo+ID4+ IE1vc3QgZGVmaW5pdGVseSA6LSkuDQo+ID4+DQo+ID4+PiBJZiB5b3UgZXhwbGljaXRseSBhc3Np Z24gYSBwcmlvcml0eSwgc3RhcnZhdGlvbiBtaWdodCBiZSBva2F5LiBIb3dldmVyLCBpZg0KPiB5 b3UgZG9u4oCZdCBoYXZlIGEgcHJpb3JpdHkgZXhwbGljaXRseSBzaWduYWxlZCwgdGhlIHRyYW5z YWN0aW9uIG1pZ2h0IGhhdmUgYSB2ZXJ5DQo+IGhpZ2ggcHJpb3JpdHkNCj4gPj4gU28gc29tZSBh Z2VudCBpbiB0aGUgc3lzdGVtIG5lZWRzIHRvIGRlY2lkZSB0aGF0IGEgdHJhbnNhY3Rpb24gaXMN Cj4gaW1wb3J0YW50Lg0KPiA+Pj4gYnV0IHlvdSBqdXN0IGRvbuKAmXQga25vdyBhbmQgYnkgYXNz aWduaW5nIGEgcmFuZG9tIG1pZC1yYW5nZSBwcmlvcml0eQ0KPiB0aGlzIGltcG9ydGFudCByZXF1 ZXN0IGNvdWxkIGdldCBzdGFydmVkLg0KPiA+PiBIZXJlIEkgZGlzYWdyZWUgd2l0aCB5b3UsIGJl Y2F1c2UgdGhlIHdheSB0byBrbm93IHRoYXQgYSB0cmFuc2FjdGlvbiBpcw0KPiBpbXBvcnRhbnQg aXMgdG8gdXBncmFkZSBjbGllbnQgdG8gZXhwbGljaXRseSBhc3NpZ24gaGlnaCBwcmlvcml0eSB0 byBpdC4gU28gZGVmYXVsdA0KPiBwcmlvcml0eSBpcyBhIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkg bWVjaGFuaXNtLCB0aGF0IHdvdWxkIHdvcmsgZm9yIG1vc3QNCj4gY29tbW9uIGNhc2VzLiBZb3Ug c2VlbSB0byBiZSBzdWdnZXN0aW5nIHRoYXQgd2hlbiB0aGlzIGV4dGVuc2lvbiBpcw0KPiBkZXBs b3llZCBhbGwgY2xpZW50cyBuZWVkIHRvIGJlIHVwZGF0ZWQgYXQgdGhlIHNhbWUgdGltZS4gVGhp cyBpcyBub3QgcmVhbGlzdGljLg0KPiA+Pg0KPiA+Pg0KDQoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEg bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu IExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp b24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1h aWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhh dCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Wed May 11 09:53: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 3AFEE12D507; Wed, 11 May 2016 09:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 6IKOpSfVA2_K; Wed, 11 May 2016 09:53:08 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17DB12D0C3; Wed, 11 May 2016 09:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3172; q=dns/txt; s=iport; t=1462985587; x=1464195187; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=aMdKAMFK5omEItNMuwXeg2cmKcblYH1GpJyl/H/N1y8=; b=jk3lhV3gqcJKoMlLwZ6I4wggoZuzpirylgqxrMf+vPAQqNKDU/Ia0M/E EHoxXuJVKGjTcVZ4QXCwJgEHC62AfBSJzg5muzN+7DQB9iKAMtUwIzh0a sKWWau3xUqY32FF2rMTp3FJNz2hK7PbVHEVH9CRoFeIos58qriXwcIXL4 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgCSYjNX/40NJK1egzi4c4IPAQ2Bd?= =?us-ascii?q?oYUAoE6OBQBAQEBAQEBZSeEQwEBBDhAARALDgoJFg8JAwIBAgFFBgEMCAEBiCu?= =?us-ascii?q?6GAEBAQEBAQEBAQEBAQEBAQEBGYYghEyEKYVvAQSYJ44egWmET4MHhVqPQR4BA?= =?us-ascii?q?UKCNoFRIIk8AQEB?= X-IronPort-AV: E=Sophos;i="5.24,608,1454976000"; d="scan'208";a="101488562" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2016 16:53:06 +0000 Received: from [10.86.255.17] ([10.86.255.17]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u4BGr5xB012590; Wed, 11 May 2016 16:53:06 GMT To: Steve Donovan , Ben Campbell References: <20160504170252.8246.93112.idtracker@ietfa.amsl.com> <1D4B3862-3423-4618-B0ED-103B99BBC79F@nostrum.com> <572F2C8F.9070300@cisco.com> <57324FA2.3030607@usdonovans.com> From: Benoit Claise Message-ID: <57336371.2090103@cisco.com> Date: Wed, 11 May 2016 12:53:05 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <57324FA2.3030607@usdonovans.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] Benoit Claise's No Objection on draft-ietf-dime-drmp-05: (with COMMENT) 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, 11 May 2016 16:53:09 -0000 On 5/10/2016 5:16 PM, Steve Donovan wrote: > Benoit, > > Please see my comments inline. > > Regards, > > Steve > > On 5/8/16 7:09 AM, Benoit Claise wrote: >> Ben, >>> I will jump in on one point, since this is related to the discussion >>> on whether nodes need a common approach to selecting/interpreting >>> priority values: >>> >>> On 4 May 2016, at 12:02, Benoit Claise wrote: >>> >>>> >>>> - >>>> >>>> 1. Request sender - The sender of a request, be it a Diameter Client >>>> or a Diameter Server, determines the relative priority of the >>>> request and includes that priority information in the request. >>>> >>>> Question: what is the risk of DMRP ending up as the DSCP, i.e. >>>> Every end point changes the value to best service, and in the end, >>>> it's >>>> useless, and uniquely set by the operator. >>> >>> I think there's a trusted network assumption here, which would >>> include an assumption that trusted clients do not intentionally game >>> the system. (in contrast with _accidentally_ gaming the system by >>> using a different scheme to set priority values.) >>> >>> However, I think that this sort of assumption should be explicitly >>> mentioned. >> I believe so. >>> IIRC, DOIC included some guidance about crossing trust boundaries; >>> perhaps DRMP should do the same. >> Yes. >> That makes me think. I wonder how the following two statements are >> interoperable? >> >> Diameter nodes MUST have a default priority to apply to transactions >> that do not have an explicit priority set in the DRMP AVP. >> >> Diameter nodes SHOULD use the PRIORITY_10 priority as this default >> value. >> >> >> Shouldn't the last SHOULD be a MUST? > SRD> The reason it is a SHOULD is to allow for an operator to define a > priority scheme with a different value, much as you outline below. >> >> Let me explain: a Diameter node wants to send Diameter messages with >> priority above average, so PRIORITY = 12 (because his default is 10). >> Along the path (potentially crossing a boundary), a Diameter node >> doesn't support the DRMP AVP. The next node, which does, sets his >> default priority. The default priority on that node has been >> configured as 13. And now, my Diameter messages will be treated as >> below average. >> Do I miss anything? > SRD> Yes, as described, this would be an issue. This is one of the > reasons that the DISCUSS threads have focused on the need to emphasize > that this mechanism only works if a consistent priority scheme is > applied to all messages and that it only works within a trusted > environment. BC> This assumption should be spelled out. > This implies that priority values received from other Diameter > networks likely can't be trusted. > > SRD> It may be necessary to add a requirement that the priority value > MUST be the same for all nodes within the Diameter network using a > defined priority scheme. BC> That would help yes. regards, B. >> >> Regards, Benoit >> >>> >>> (And I guess that does make it a bit like DSCP ;-) ) >>> >>> Ben. >>> . >>> >> > > . > From nobody Wed May 11 10:11:50 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 1CC1512B01F for ; Wed, 11 May 2016 10:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=ThrGrASp; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=X6DmfpvR 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 tuuQ5fs8zT3m for ; Wed, 11 May 2016 10:11:41 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE0312B03F for ; Wed, 11 May 2016 10:11:40 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 20B0521069 for ; Wed, 11 May 2016 13:05:47 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 11 May 2016 13:05:47 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=8T8o514658riwxaaQAXp8H+G5uw=; b=ThrGrA SpH+8uSsNGecYdoSrTRI5L2l0X1baaDN73ExABD3YPaR8EU2aHRTClORSYUY2vhY gqG6xYPAxR683TDH0Hy5MZnwKrj0lGw1pjP24N5Jp0g0zn4lErefeNv8oqXaa+hi y2JxJdawEQal4bL6fLTOO/RgfGOQq16z2ZdRc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=8T8o514658riwxa aQAXp8H+G5uw=; b=X6DmfpvR9GoQPQUbJI2LswUi51xFjY93Vx/M/50Y+RZqNi6 ZBCyuxtMLU9J1pqUINn/TWrXZqMpEF+LKbucDmLfKmvTCqLSxonrZe14HcuSjDme NVSjUzMz4q3nVpjOMVRoo/6hl2pA33DMixpecKISwe58sGbJlx5T0vtDgbHI= X-Sasl-enc: nxb1D0O4FYxde5idrHX9hkCi/l4E6fO0Zclp7FMoTDpB 1462986346 Received: from [10.251.90.40] (hop-nat-137.emc.com [168.159.213.137]) by mail.messagingengine.com (Postfix) with ESMTPA id B93B168026B; Wed, 11 May 2016 13:05:46 -0400 (EDT) Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (1.0) From: Alexe Melnikov X-Mailer: iPad Mail (13E238) In-Reply-To: <6EF5DC36-1BEF-47EE-BB3B-83BE5E115AE3@kuehlewind.net> Date: Wed, 11 May 2016 13:13:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <993A9C1D-1B91-4A6D-B7DA-F5E829763E17@fastmail.fm> References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> <57324CE8.6040109@usdonovans.com> <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net> <6EF5DC36-1BEF-47EE-BB3B-83BE5E115AE3@kuehlewind.net> To: "Mirja Kuehlewind (IETF)" Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 11 May 2016 17:11:47 -0000 Hi Mirja, > On 11 May 2016, at 07:07, Mirja Kuehlewind (IETF) wr= ote: >=20 > Okay let me go for an example here and see if that can be a use case that w= e are talking about. Yes, this is helpful. >=20 > You have a system where some clients run a communication service for emerg= ency doctors as well as for firefighters and then there are also =82normal=91= users that run some kind of communication service. >=20 > Now you actually have an emergency: some part of the system is down and th= e number of request is high such that the system is overloaded. >=20 > Both the emergency doctors have would have two different priority classes,= one for important message about instruction (what and where people should d= o something) and one for communication between the doctors/firefighters whic= h has still higher priority than any other communication of the other people= (as you assume doctors and firefighters are more responsible to not misuse t= his communication channel). >=20 > Now only the emergency doctors communication service was upgraded to use t= his extension, but the firefighter=92s administrations is just too slow or t= hey currently have not enough money because they have specialized expensive h= ardware and software that is not easy to change. "Doctor, it hurts when I do that..." - "Don't do that!" I don't think this would be a common deployment case. I agree that there is an issue in the scenario you specified. Default priori= ty helps with a single application + normal (unupgraded) traffic. I do think= it helps with the most common case. So instead of having lots of SHOULDs an= d MAYs, I suggest we add text describing possible issues and when multiple D= IAMETER applications are deployed we either recommend that all clients are u= pgraded to support this extension at the same time or at least deployments s= pecify compatible policies for different applications. I can suggest some text. > Is it okay in this situation that the private chat of two doctors about th= eir last ski-holidays starves requests to access the network to send instruc= tor message to the firefighters? We can't prevent all problems like this, as the above is really a social pro= blem combined with misconfiguration. But we can warn about it. >=20 > (And how do i make sure that that all other other requests actually select= a lower priority than 10=85? But that=92s a different question=85) >=20 > Mirja >=20 >=20 >> Am 11.05.2016 um 06:59 schrieb Alexey Melnikov : >>=20 >> Hi Mirja, >>=20 >> On 10 May 2016, at 17:59, Mirja Kuehlewind (IETF) w= rote: >>=20 >>>>> I don=92t think it is a good idea to assign a default priority to non-= priority-defined requests at all. If you have high priority traffic that doe= s not support this extension (yet) this traffic could be starved by lower pr= iority traffic when assigning a middle range priority. I don=92t think that i= s what you want to achieve. >>>> SRD> Actually, this is what we want to achieve. It is an requirement t= hat messages explicitly marked as high priority get treated even if it resul= ts in starving lower priority messages. The starving of lower priority mess= ages is not an problem, it is a requirement. >>>=20 >>> I think we are still talking past each other. >>=20 >> Most definitely :-). >>=20 >>> If you explicitly assign a priority, starvation might be okay. However, i= f you don=92t have a priority explicitly signaled, the transaction might hav= e a very high priority >>=20 >> So some agent in the system needs to decide that a transaction is importa= nt. >>> but you just don=92t know and by assigning a random mid-range priority t= his important request could get starved. >>=20 >> Here I disagree with you, because the way to know that a transaction is i= mportant is to upgrade client to explicitly assign high priority to it. So d= efault priority is a backward compatibility mechanism, that would work for m= ost common cases. You seem to be suggesting that when this extension is depl= oyed all clients need to be updated at the same time. This is not realistic.= >=20 From nobody Wed May 11 10:34:26 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 42BFD12D0F7; Wed, 11 May 2016 10:34:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160511173425.15223.72665.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2016 10:34:25 -0700 Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org Subject: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-dime-drmp-05=3A_=28with_COMMENT=29?= 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: Wed, 11 May 2016 17:34:25 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dime-drmp-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I still think this part needs further clarification mostly regarding applicability and maybe a warning as it could lead to starvation of requests that do not define a priority, e.g. because there are not supporting it (yet) while effectively having a higher priortiy than the requests that they get starved by: "When using DRMP priority information, Diameter nodes MUST use the default priority for transactions that do not have priority specified in a DRMP AVP." From nobody Wed May 11 10:46:33 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 355C712D106 for ; Wed, 11 May 2016 10:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 rZqWXqUcRLXB for ; Wed, 11 May 2016 10:46:29 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219D212B01F for ; Wed, 11 May 2016 10:46:28 -0700 (PDT) Received: (qmail 12255 invoked from network); 11 May 2016 19:39:46 +0200 Received: from softdnserror (HELO ?10.189.47.22?) (192.54.222.12) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 11 May 2016 19:39:45 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <993A9C1D-1B91-4A6D-B7DA-F5E829763E17@fastmail.fm> Date: Wed, 11 May 2016 13:39:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> <57324CE8.6040109@usdonovans.com> <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net> <6EF5DC36-1BEF-47EE-BB3B-83BE5E115AE3@kuehlewind.net> <993A9C1D-1B91-4A6D-B7DA-F5E829763E17@fastmail.fm> To: Alexe Melnikov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 11 May 2016 17:46:31 -0000 Hi Alexey, yes, please provide some text and maybe a warning. I=E2=80=99ve cleared my discuss as no actual changes to the spec are = needed based on the common understand we have now, however, I would = still like to see further text in the doc about points that came up in = this discussion. Thanks! Mirja > Am 11.05.2016 um 13:13 schrieb Alexe Melnikov = : >=20 > Hi Mirja, >=20 >> On 11 May 2016, at 07:07, Mirja Kuehlewind (IETF) = wrote: >>=20 >> Okay let me go for an example here and see if that can be a use case = that we are talking about. >=20 > Yes, this is helpful. >>=20 >> You have a system where some clients run a communication service for = emergency doctors as well as for firefighters and then there are also = =E2=80=9Anormal=E2=80=98 users that run some kind of communication = service. >>=20 >> Now you actually have an emergency: some part of the system is down = and the number of request is high such that the system is overloaded. >>=20 >> Both the emergency doctors have would have two different priority = classes, one for important message about instruction (what and where = people should do something) and one for communication between the = doctors/firefighters which has still higher priority than any other = communication of the other people (as you assume doctors and = firefighters are more responsible to not misuse this communication = channel). >>=20 >> Now only the emergency doctors communication service was upgraded to = use this extension, but the firefighter=E2=80=99s administrations is = just too slow or they currently have not enough money because they have = specialized expensive hardware and software that is not easy to change. >=20 > "Doctor, it hurts when I do that..." - "Don't do that!" >=20 > I don't think this would be a common deployment case. >=20 > I agree that there is an issue in the scenario you specified. Default = priority helps with a single application + normal (unupgraded) traffic. = I do think it helps with the most common case. So instead of having lots = of SHOULDs and MAYs, I suggest we add text describing possible issues = and when multiple DIAMETER applications are deployed we either recommend = that all clients are upgraded to support this extension at the same time = or at least deployments specify compatible policies for different = applications. >=20 > I can suggest some text. >=20 >> Is it okay in this situation that the private chat of two doctors = about their last ski-holidays starves requests to access the network to = send instructor message to the firefighters? >=20 > We can't prevent all problems like this, as the above is really a = social problem combined with misconfiguration. But we can warn about it. >>=20 >> (And how do i make sure that that all other other requests actually = select a lower priority than 10=E2=80=A6? But that=E2=80=99s a different = question=E2=80=A6) >>=20 >> Mirja >>=20 >>=20 >>> Am 11.05.2016 um 06:59 schrieb Alexey Melnikov = : >>>=20 >>> Hi Mirja, >>>=20 >>> On 10 May 2016, at 17:59, Mirja Kuehlewind (IETF) = wrote: >>>=20 >>>>>> I don=E2=80=99t think it is a good idea to assign a default = priority to non-priority-defined requests at all. If you have high = priority traffic that does not support this extension (yet) this traffic = could be starved by lower priority traffic when assigning a middle range = priority. I don=E2=80=99t think that is what you want to achieve. >>>>> SRD> Actually, this is what we want to achieve. It is an = requirement that messages explicitly marked as high priority get treated = even if it results in starving lower priority messages. The starving of = lower priority messages is not an problem, it is a requirement. >>>>=20 >>>> I think we are still talking past each other. >>>=20 >>> Most definitely :-). >>>=20 >>>> If you explicitly assign a priority, starvation might be okay. = However, if you don=E2=80=99t have a priority explicitly signaled, the = transaction might have a very high priority >>>=20 >>> So some agent in the system needs to decide that a transaction is = important. >>>> but you just don=E2=80=99t know and by assigning a random mid-range = priority this important request could get starved. >>>=20 >>> Here I disagree with you, because the way to know that a transaction = is important is to upgrade client to explicitly assign high priority to = it. So default priority is a backward compatibility mechanism, that = would work for most common cases. You seem to be suggesting that when = this extension is deployed all clients need to be updated at the same = time. This is not realistic. >>=20 >=20 From nobody Wed May 11 10:49: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 4AD0D12D13D; Wed, 11 May 2016 10:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 bEXNcMP_yu2R; Wed, 11 May 2016 10:49:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BABA612D106; Wed, 11 May 2016 10:49:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1DAC5BE2D; Wed, 11 May 2016 18:49:38 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fIZB3Qfc5NK; Wed, 11 May 2016 18:49:36 +0100 (IST) Received: from [172.20.10.8] (unknown [172.56.3.38]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B04CBBE29; Wed, 11 May 2016 18:49:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462988976; bh=JmcsTDCsq24MXEclUyJpQAS4Mb4JrVFs/xIvWR+f/y8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=td1hf43B3o5lbc1WtlhAwov3+/C+lAH7C0p30+ZBvYtUr2Mep4s/27oo7PitxLRO1 VdpNsjMCzkQpnKyvSAVaCa9T6ApJ17SjL0lGGqcZkuTgoobj4L4auh1liuuu4oR3SM BhWWWJPpH658vL44YPjZhuA4A8LTvG37Ge+fs5aM= To: Mirja Kuehlewind , The IESG References: <20160511173425.15223.72665.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <573370AC.9050408@cs.tcd.ie> Date: Wed, 11 May 2016 18:49:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160511173425.15223.72665.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060908070409020205020708" Archived-At: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-dime-drmp-05=3A_=28with_COMMENT=29?= 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, 11 May 2016 17:49:43 -0000 This is a cryptographically signed message in MIME format. --------------ms060908070409020205020708 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Mirja and all for the discussion. Authors - if you're ready, please do go ahead now and update the draft based on all the discussion to date and we can then check back with the various ADs who've commented. (I think Alexey said he'd suggest a bit of text to address Mirja's concern, so please do check with him as you prepare the revision.) Cheers, S. On 11/05/16 18:34, Mirja Kuehlewind wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-dime-drmp-05: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I still think this part needs further clarification mostly regarding > applicability and maybe a warning as it could lead to starvation of > requests that do not define a priority, e.g. because there are not > supporting it (yet) while effectively having a higher priortiy than the= > requests that they get starved by: > "When using DRMP priority information, Diameter nodes MUST use the > default priority for transactions that do not have priority specifie= d > in a DRMP AVP." >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 --------------ms060908070409020205020708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTEx NzQ5MzJaMC8GCSqGSIb3DQEJBDEiBCCz4tzFfjtlgTlwNYZf6qoqHBk5p+CcDfV6R/6QM7dX qzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBGb8NdvRK1MYSD5gP37sLRSYv7Cz7vky3+Ob0lsqeY/Kv8lIA1zT1f 4nUNehxZC9I/SkDy8LoqjzweTwZxpEil3QoDm91iz66AHSgyu63MdTBWjCT3DDGqDTa2hOSY M5h/ScpuqBvY8Ru9J7TlE7dRttqrbG/njrFPwuD728UiNzTU4WNt65oYZasVfAZIzN52N8xY uRNV9PtuZU0QlER7kSqPwoWWn6Yue4E4HDaKoluxx1Z2hqeQZLxd6bTSfe2G9vIB5qB8ihQG 3akzC4JZnn/FhhjNHWa3pk5OUPWfwi00QOTpLORm1sk6Pe5t3i4/FEBG1TN35iLjH5fJku3M AAAAAAAA --------------ms060908070409020205020708-- From nobody Wed May 11 11:23: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 0A56912D54C; Wed, 11 May 2016 11:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 mnQ1yDSKavY8; Wed, 11 May 2016 11:23:27 -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 0712C12D548; Wed, 11 May 2016 11:23:24 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 7924C22CA73; Wed, 11 May 2016 20:23:22 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 4DF0535C048; Wed, 11 May 2016 20:23:22 +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; Wed, 11 May 2016 20:23:22 +0200 From: To: Alexe Melnikov , "Mirja Kuehlewind (IETF)" Thread-Topic: =?utf-8?B?UkXCoDogUmU6IFtEaW1lXSBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBv?= =?utf-8?B?biBkcmFmdC1pZXRmLWRpbWUtZHJtcC0wNTogKHdpdGggRElTQ1VTUyBhbmQg?= =?utf-8?Q?COMMENT)?= Thread-Index: AdGrsjK2GN4LgpxFStGm1aLx7sVJYQ== Date: Wed, 11 May 2016 18:23:21 +0000 Message-ID: <13750_1462991002_5733789A_13750_8627_1_6B7134B31289DC4FAF731D844122B36E01E60871@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E01E60871OPEXCLILM43corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.11.172717 Archived-At: Cc: "draft-ietf-dime-drmp@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , The IESG Subject: [Dime] =?utf-8?b?UkXCoDogUmU6ICBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3Vz?= =?utf-8?q?s_on_draft-ietf-dime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 11 May 2016 18:23:29 -0000 --_000_6B7134B31289DC4FAF731D844122B36E01E60871OPEXCLILM43corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdGlsbCBkb24ndCBnZXQgdGhlIGlzc3VlIHdpdGggbXVsdGlwbGUgYXBwbGljYXRpb25zIHdo ZW4gZGVmaW5pbmcgYSBzb2x1dGlvbiB0aGF0IGlzIGFjdHVhbGx5IGFwcGxpY2F0aW9uLWFnbm9z dGljICh3aXRoIHRoZSBjbGFyaWZpY2F0aW9uIGdpdmVuIGluIG15IHByZXZpb3VzIG1haWwpDQoN CkkgdGhpbmsgaXQgaXMgY2xlYXIgdGhhdCBzb21lIHRleHQgaXMgcmVxdWlyZWQgdG8gY2xhcmlm eSB0aGUgbmVlZCBmb3IgdGhlIGRlZmF1bHQgaGFuZGxpbmcgYW5kIHRoZSByZWFzb24gZm9yIHRo ZSAic2hvdWxkIiB3aXRoIHRoZSBhbHRlcm5hdGl2ZSAib3BlcmF0b3IgcG9saWNpZXMvYXBwbGlj YXRpb24gZ3VpZGVsaW5lcyIuDQoNCkJ1dCBJIHdpbGwgc2VlIHRoZSBhZGRpdGlvbmFsIHRleHQg dGhhdCB3aWxsIHByb3ZpZGUgaW4gdGhlIHVwZGF0ZWQgZHJhZnQuDQoNClRoeCBhbGwgdGhlIGNv bnN0cnVjdGl2ZSBkaXNjdXNzaW9uLg0KDQpMaW9uZWwNCg0KTm90IHNlbnQgZnJvbSBhbiBJUGhv bmUuDQoNCkxlIDExIG1haSAyMDE2IDE5OjExLCBBbGV4ZSBNZWxuaWtvdiA8YWFtZWxuaWtvdkBm YXN0bWFpbC5mbT4gYSDDqWNyaXQgOg0KDQpIaSBNaXJqYSwNCg0KPiBPbiAxMSBNYXkgMjAxNiwg YXQgMDc6MDcsIE1pcmphIEt1ZWhsZXdpbmQgKElFVEYpIDxpZXRmQGt1ZWhsZXdpbmQubmV0PiB3 cm90ZToNCj4NCj4gT2theSBsZXQgbWUgZ28gZm9yIGFuIGV4YW1wbGUgaGVyZSBhbmQgc2VlIGlm IHRoYXQgY2FuIGJlIGEgdXNlIGNhc2UgdGhhdCB3ZSBhcmUgdGFsa2luZyBhYm91dC4NCg0KWWVz LCB0aGlzIGlzIGhlbHBmdWwuDQo+DQo+IFlvdSBoYXZlIGEgc3lzdGVtIHdoZXJlIHNvbWUgY2xp ZW50cyBydW4gYSBjb21tdW5pY2F0aW9uIHNlcnZpY2UgZm9yIGVtZXJnZW5jeSBkb2N0b3JzIGFz IHdlbGwgYXMgZm9yIGZpcmVmaWdodGVycyBhbmQgdGhlbiB0aGVyZSBhcmUgYWxzbyDigJpub3Jt YWzigJggdXNlcnMgdGhhdCBydW4gc29tZSBraW5kIG9mIGNvbW11bmljYXRpb24gc2VydmljZS4N Cj4NCj4gTm93IHlvdSBhY3R1YWxseSBoYXZlIGFuIGVtZXJnZW5jeTogc29tZSBwYXJ0IG9mIHRo ZSBzeXN0ZW0gaXMgZG93biBhbmQgdGhlIG51bWJlciBvZiByZXF1ZXN0IGlzIGhpZ2ggc3VjaCB0 aGF0IHRoZSBzeXN0ZW0gaXMgb3ZlcmxvYWRlZC4NCj4NCj4gQm90aCB0aGUgZW1lcmdlbmN5IGRv Y3RvcnMgaGF2ZSB3b3VsZCBoYXZlIHR3byBkaWZmZXJlbnQgcHJpb3JpdHkgY2xhc3Nlcywgb25l IGZvciBpbXBvcnRhbnQgbWVzc2FnZSBhYm91dCBpbnN0cnVjdGlvbiAod2hhdCBhbmQgd2hlcmUg cGVvcGxlIHNob3VsZCBkbyBzb21ldGhpbmcpIGFuZCBvbmUgZm9yIGNvbW11bmljYXRpb24gYmV0 d2VlbiB0aGUgZG9jdG9ycy9maXJlZmlnaHRlcnMgd2hpY2ggaGFzIHN0aWxsIGhpZ2hlciBwcmlv cml0eSB0aGFuIGFueSBvdGhlciBjb21tdW5pY2F0aW9uIG9mIHRoZSBvdGhlciBwZW9wbGUgKGFz IHlvdSBhc3N1bWUgZG9jdG9ycyBhbmQgZmlyZWZpZ2h0ZXJzIGFyZSBtb3JlIHJlc3BvbnNpYmxl IHRvIG5vdCBtaXN1c2UgdGhpcyBjb21tdW5pY2F0aW9uIGNoYW5uZWwpLg0KPg0KPiBOb3cgb25s eSB0aGUgZW1lcmdlbmN5IGRvY3RvcnMgY29tbXVuaWNhdGlvbiBzZXJ2aWNlIHdhcyB1cGdyYWRl ZCB0byB1c2UgdGhpcyBleHRlbnNpb24sIGJ1dCB0aGUgZmlyZWZpZ2h0ZXLigJlzIGFkbWluaXN0 cmF0aW9ucyBpcyBqdXN0IHRvbyBzbG93IG9yIHRoZXkgY3VycmVudGx5IGhhdmUgbm90IGVub3Vn aCBtb25leSBiZWNhdXNlIHRoZXkgaGF2ZSBzcGVjaWFsaXplZCBleHBlbnNpdmUgaGFyZHdhcmUg YW5kIHNvZnR3YXJlIHRoYXQgaXMgbm90IGVhc3kgdG8gY2hhbmdlLg0KDQoiRG9jdG9yLCBpdCBo dXJ0cyB3aGVuIEkgZG8gdGhhdC4uLiIgLSAiRG9uJ3QgZG8gdGhhdCEiDQoNCkkgZG9uJ3QgdGhp bmsgdGhpcyB3b3VsZCBiZSBhIGNvbW1vbiBkZXBsb3ltZW50IGNhc2UuDQoNCkkgYWdyZWUgdGhh dCB0aGVyZSBpcyBhbiBpc3N1ZSBpbiB0aGUgc2NlbmFyaW8geW91IHNwZWNpZmllZC4gRGVmYXVs dCBwcmlvcml0eSBoZWxwcyB3aXRoIGEgc2luZ2xlIGFwcGxpY2F0aW9uICsgbm9ybWFsICh1bnVw Z3JhZGVkKSB0cmFmZmljLiBJIGRvIHRoaW5rIGl0IGhlbHBzIHdpdGggdGhlIG1vc3QgY29tbW9u IGNhc2UuIFNvIGluc3RlYWQgb2YgaGF2aW5nIGxvdHMgb2YgU0hPVUxEcyBhbmQgTUFZcywgSSBz dWdnZXN0IHdlIGFkZCB0ZXh0IGRlc2NyaWJpbmcgcG9zc2libGUgaXNzdWVzIGFuZCB3aGVuIG11 bHRpcGxlIERJQU1FVEVSIGFwcGxpY2F0aW9ucyBhcmUgZGVwbG95ZWQgd2UgZWl0aGVyIHJlY29t bWVuZCB0aGF0IGFsbCBjbGllbnRzIGFyZSB1cGdyYWRlZCB0byBzdXBwb3J0IHRoaXMgZXh0ZW5z aW9uIGF0IHRoZSBzYW1lIHRpbWUgb3IgYXQgbGVhc3QgZGVwbG95bWVudHMgc3BlY2lmeSBjb21w YXRpYmxlIHBvbGljaWVzIGZvciBkaWZmZXJlbnQgYXBwbGljYXRpb25zLg0KDQpJIGNhbiBzdWdn ZXN0IHNvbWUgdGV4dC4NCg0KPiBJcyBpdCBva2F5IGluIHRoaXMgc2l0dWF0aW9uIHRoYXQgdGhl IHByaXZhdGUgY2hhdCBvZiB0d28gZG9jdG9ycyBhYm91dCB0aGVpciBsYXN0IHNraS1ob2xpZGF5 cyBzdGFydmVzIHJlcXVlc3RzIHRvIGFjY2VzcyB0aGUgbmV0d29yayB0byBzZW5kIGluc3RydWN0 b3IgbWVzc2FnZSB0byB0aGUgZmlyZWZpZ2h0ZXJzPw0KDQpXZSBjYW4ndCBwcmV2ZW50IGFsbCBw cm9ibGVtcyBsaWtlIHRoaXMsIGFzIHRoZSBhYm92ZSBpcyByZWFsbHkgYSBzb2NpYWwgcHJvYmxl bSBjb21iaW5lZCB3aXRoIG1pc2NvbmZpZ3VyYXRpb24uIEJ1dCB3ZSBjYW4gd2FybiBhYm91dCBp dC4NCj4NCj4gKEFuZCBob3cgZG8gaSBtYWtlIHN1cmUgdGhhdCB0aGF0IGFsbCBvdGhlciBvdGhl ciByZXF1ZXN0cyBhY3R1YWxseSBzZWxlY3QgYSBsb3dlciBwcmlvcml0eSB0aGFuIDEw4oCmPyBC dXQgdGhhdOKAmXMgYSBkaWZmZXJlbnQgcXVlc3Rpb27igKYpDQo+DQo+IE1pcmphDQo+DQo+DQo+ PiBBbSAxMS4wNS4yMDE2IHVtIDA2OjU5IHNjaHJpZWIgQWxleGV5IE1lbG5pa292IDxhYW1lbG5p a292QGZhc3RtYWlsLmZtPjoNCj4+DQo+PiBIaSBNaXJqYSwNCj4+DQo+PiBPbiAxMCBNYXkgMjAx NiwgYXQgMTc6NTksIE1pcmphIEt1ZWhsZXdpbmQgKElFVEYpIDxpZXRmQGt1ZWhsZXdpbmQubmV0 PiB3cm90ZToNCj4+DQo+Pj4+PiBJIGRvbuKAmXQgdGhpbmsgaXQgaXMgYSBnb29kIGlkZWEgdG8g YXNzaWduIGEgZGVmYXVsdCBwcmlvcml0eSB0byBub24tcHJpb3JpdHktZGVmaW5lZCByZXF1ZXN0 cyBhdCBhbGwuIElmIHlvdSBoYXZlIGhpZ2ggcHJpb3JpdHkgdHJhZmZpYyB0aGF0IGRvZXMgbm90 IHN1cHBvcnQgdGhpcyBleHRlbnNpb24gKHlldCkgdGhpcyB0cmFmZmljIGNvdWxkIGJlIHN0YXJ2 ZWQgYnkgbG93ZXIgcHJpb3JpdHkgdHJhZmZpYyB3aGVuIGFzc2lnbmluZyBhIG1pZGRsZSByYW5n ZSBwcmlvcml0eS4gSSBkb27igJl0IHRoaW5rIHRoYXQgaXMgd2hhdCB5b3Ugd2FudCB0byBhY2hp ZXZlLg0KPj4+PiBTUkQ+IEFjdHVhbGx5LCB0aGlzIGlzIHdoYXQgd2Ugd2FudCB0byBhY2hpZXZl LiAgSXQgaXMgYW4gcmVxdWlyZW1lbnQgdGhhdCBtZXNzYWdlcyBleHBsaWNpdGx5IG1hcmtlZCBh cyBoaWdoIHByaW9yaXR5IGdldCB0cmVhdGVkIGV2ZW4gaWYgaXQgcmVzdWx0cyBpbiBzdGFydmlu ZyBsb3dlciBwcmlvcml0eSBtZXNzYWdlcy4gIFRoZSBzdGFydmluZyBvZiBsb3dlciBwcmlvcml0 eSBtZXNzYWdlcyBpcyBub3QgYW4gcHJvYmxlbSwgaXQgaXMgYSByZXF1aXJlbWVudC4NCj4+Pg0K Pj4+IEkgdGhpbmsgd2UgYXJlIHN0aWxsIHRhbGtpbmcgcGFzdCBlYWNoIG90aGVyLg0KPj4NCj4+ IE1vc3QgZGVmaW5pdGVseSA6LSkuDQo+Pg0KPj4+IElmIHlvdSBleHBsaWNpdGx5IGFzc2lnbiBh IHByaW9yaXR5LCBzdGFydmF0aW9uIG1pZ2h0IGJlIG9rYXkuIEhvd2V2ZXIsIGlmIHlvdSBkb27i gJl0IGhhdmUgYSBwcmlvcml0eSBleHBsaWNpdGx5IHNpZ25hbGVkLCB0aGUgdHJhbnNhY3Rpb24g bWlnaHQgaGF2ZSBhIHZlcnkgaGlnaCBwcmlvcml0eQ0KPj4NCj4+IFNvIHNvbWUgYWdlbnQgaW4g dGhlIHN5c3RlbSBuZWVkcyB0byBkZWNpZGUgdGhhdCBhIHRyYW5zYWN0aW9uIGlzIGltcG9ydGFu dC4NCj4+PiBidXQgeW91IGp1c3QgZG9u4oCZdCBrbm93IGFuZCBieSBhc3NpZ25pbmcgYSByYW5k b20gbWlkLXJhbmdlIHByaW9yaXR5IHRoaXMgaW1wb3J0YW50IHJlcXVlc3QgY291bGQgZ2V0IHN0 YXJ2ZWQuDQo+Pg0KPj4gSGVyZSBJIGRpc2FncmVlIHdpdGggeW91LCBiZWNhdXNlIHRoZSB3YXkg dG8ga25vdyB0aGF0IGEgdHJhbnNhY3Rpb24gaXMgaW1wb3J0YW50IGlzIHRvIHVwZ3JhZGUgY2xp ZW50IHRvIGV4cGxpY2l0bHkgYXNzaWduIGhpZ2ggcHJpb3JpdHkgdG8gaXQuIFNvIGRlZmF1bHQg cHJpb3JpdHkgaXMgYSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IG1lY2hhbmlzbSwgdGhhdCB3b3Vs ZCB3b3JrIGZvciBtb3N0IGNvbW1vbiBjYXNlcy4gWW91IHNlZW0gdG8gYmUgc3VnZ2VzdGluZyB0 aGF0IHdoZW4gdGhpcyBleHRlbnNpb24gaXMgZGVwbG95ZWQgYWxsIGNsaWVudHMgbmVlZCB0byBi ZSB1cGRhdGVkIGF0IHRoZSBzYW1lIHRpbWUuIFRoaXMgaXMgbm90IHJlYWxpc3RpYy4NCj4NCg0K Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVu aXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5l IGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBx dWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBz dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJp bGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVy Y2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg bGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv dXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBs aWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZh bHNpZmllZC4KVGhhbmsgeW91LgoK --_000_6B7134B31289DC4FAF731D844122B36E01E60871OPEXCLILM43corp_ Content-Type: text/html; charset="utf-8" Content-ID: <1391A426E453C040915D5027164C79C3@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pkkgc3RpbGwgZG9uJ3QgZ2V0IHRoZSBpc3N1ZSB3aXRoIG11bHRpcGxlIGFwcGxpY2F0aW9ucyB3 aGVuIGRlZmluaW5nIGEgc29sdXRpb24gdGhhdCBpcyBhY3R1YWxseSBhcHBsaWNhdGlvbi1hZ25v c3RpYyAod2l0aCB0aGUgY2xhcmlmaWNhdGlvbiBnaXZlbiBpbiBteSBwcmV2aW91cyBtYWlsKQ0K PGJyPg0KPGJyPg0KSSB0aGluayBpdCBpcyBjbGVhciB0aGF0IHNvbWUgdGV4dCBpcyByZXF1aXJl ZCB0byBjbGFyaWZ5IHRoZSBuZWVkIGZvciB0aGUgZGVmYXVsdCBoYW5kbGluZyBhbmQgdGhlIHJl YXNvbiBmb3IgdGhlICZxdW90O3Nob3VsZCZxdW90OyB3aXRoIHRoZSBhbHRlcm5hdGl2ZSAmcXVv dDtvcGVyYXRvciBwb2xpY2llcy9hcHBsaWNhdGlvbiBndWlkZWxpbmVzJnF1b3Q7Lg0KPGJyPg0K PGJyPg0KQnV0IEkgd2lsbCBzZWUgdGhlIGFkZGl0aW9uYWwgdGV4dCB0aGF0IHdpbGwgcHJvdmlk ZSBpbiB0aGUgdXBkYXRlZCBkcmFmdC4gPGJyPg0KPGJyPg0KVGh4IGFsbCB0aGUgY29uc3RydWN0 aXZlIGRpc2N1c3Npb24uIDxicj4NCjxicj4NCkxpb25lbCA8YnI+DQo8YnI+DQpOb3Qgc2VudCBm cm9tIGFuIElQaG9uZS4gPGJyPg0KPGJyPg0KTGUgMTEgbWFpIDIwMTYgMTk6MTEsIEFsZXhlIE1l bG5pa292ICZsdDthYW1lbG5pa292QGZhc3RtYWlsLmZtJmd0OyBhIMOpY3JpdCA6IDxicj4NCjxi cj4NCkhpIE1pcmphLCA8YnI+DQo8YnI+DQomZ3Q7IE9uIDExIE1heSAyMDE2LCBhdCAwNzowNywg TWlyamEgS3VlaGxld2luZCAoSUVURikgJmx0O2lldGZAa3VlaGxld2luZC5uZXQmZ3Q7IHdyb3Rl OiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgT2theSBsZXQgbWUgZ28gZm9yIGFuIGV4YW1wbGUgaGVy ZSBhbmQgc2VlIGlmIHRoYXQgY2FuIGJlIGEgdXNlIGNhc2UgdGhhdCB3ZSBhcmUgdGFsa2luZyBh Ym91dC4NCjxicj4NCjxicj4NClllcywgdGhpcyBpcyBoZWxwZnVsLiA8YnI+DQomZ3Q7IDxicj4N CiZndDsgWW91IGhhdmUgYSBzeXN0ZW0gd2hlcmUgc29tZSBjbGllbnRzIHJ1biBhIGNvbW11bmlj YXRpb24gc2VydmljZSBmb3IgZW1lcmdlbmN5IGRvY3RvcnMgYXMgd2VsbCBhcyBmb3IgZmlyZWZp Z2h0ZXJzIGFuZCB0aGVuIHRoZXJlIGFyZSBhbHNvIOKAmm5vcm1hbOKAmCB1c2VycyB0aGF0IHJ1 biBzb21lIGtpbmQgb2YgY29tbXVuaWNhdGlvbiBzZXJ2aWNlLg0KPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IE5vdyB5b3UgYWN0dWFsbHkgaGF2ZSBhbiBlbWVyZ2VuY3k6IHNvbWUgcGFydCBvZiB0aGUg c3lzdGVtIGlzIGRvd24gYW5kIHRoZSBudW1iZXIgb2YgcmVxdWVzdCBpcyBoaWdoIHN1Y2ggdGhh dCB0aGUgc3lzdGVtIGlzIG92ZXJsb2FkZWQuDQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgQm90aCB0 aGUgZW1lcmdlbmN5IGRvY3RvcnMgaGF2ZSB3b3VsZCBoYXZlIHR3byBkaWZmZXJlbnQgcHJpb3Jp dHkgY2xhc3Nlcywgb25lIGZvciBpbXBvcnRhbnQgbWVzc2FnZSBhYm91dCBpbnN0cnVjdGlvbiAo d2hhdCBhbmQgd2hlcmUgcGVvcGxlIHNob3VsZCBkbyBzb21ldGhpbmcpIGFuZCBvbmUgZm9yIGNv bW11bmljYXRpb24gYmV0d2VlbiB0aGUgZG9jdG9ycy9maXJlZmlnaHRlcnMgd2hpY2ggaGFzIHN0 aWxsIGhpZ2hlciBwcmlvcml0eSB0aGFuDQogYW55IG90aGVyIGNvbW11bmljYXRpb24gb2YgdGhl IG90aGVyIHBlb3BsZSAoYXMgeW91IGFzc3VtZSBkb2N0b3JzIGFuZCBmaXJlZmlnaHRlcnMgYXJl IG1vcmUgcmVzcG9uc2libGUgdG8gbm90IG1pc3VzZSB0aGlzIGNvbW11bmljYXRpb24gY2hhbm5l bCkuDQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgTm93IG9ubHkgdGhlIGVtZXJnZW5jeSBkb2N0b3Jz IGNvbW11bmljYXRpb24gc2VydmljZSB3YXMgdXBncmFkZWQgdG8gdXNlIHRoaXMgZXh0ZW5zaW9u LCBidXQgdGhlIGZpcmVmaWdodGVy4oCZcyBhZG1pbmlzdHJhdGlvbnMgaXMganVzdCB0b28gc2xv dyBvciB0aGV5IGN1cnJlbnRseSBoYXZlIG5vdCBlbm91Z2ggbW9uZXkgYmVjYXVzZSB0aGV5IGhh dmUgc3BlY2lhbGl6ZWQgZXhwZW5zaXZlIGhhcmR3YXJlIGFuZCBzb2Z0d2FyZSB0aGF0IGlzIG5v dA0KIGVhc3kgdG8gY2hhbmdlLiA8YnI+DQo8YnI+DQomcXVvdDtEb2N0b3IsIGl0IGh1cnRzIHdo ZW4gSSBkbyB0aGF0Li4uJnF1b3Q7IC0gJnF1b3Q7RG9uJ3QgZG8gdGhhdCEmcXVvdDsgPGJyPg0K PGJyPg0KSSBkb24ndCB0aGluayB0aGlzIHdvdWxkIGJlIGEgY29tbW9uIGRlcGxveW1lbnQgY2Fz ZS4gPGJyPg0KPGJyPg0KSSBhZ3JlZSB0aGF0IHRoZXJlIGlzIGFuIGlzc3VlIGluIHRoZSBzY2Vu YXJpbyB5b3Ugc3BlY2lmaWVkLiBEZWZhdWx0IHByaW9yaXR5IGhlbHBzIHdpdGggYSBzaW5nbGUg YXBwbGljYXRpb24gJiM0Mzsgbm9ybWFsICh1bnVwZ3JhZGVkKSB0cmFmZmljLiBJIGRvIHRoaW5r IGl0IGhlbHBzIHdpdGggdGhlIG1vc3QgY29tbW9uIGNhc2UuIFNvIGluc3RlYWQgb2YgaGF2aW5n IGxvdHMgb2YgU0hPVUxEcyBhbmQgTUFZcywgSSBzdWdnZXN0IHdlIGFkZCB0ZXh0DQogZGVzY3Jp YmluZyBwb3NzaWJsZSBpc3N1ZXMgYW5kIHdoZW4gbXVsdGlwbGUgRElBTUVURVIgYXBwbGljYXRp b25zIGFyZSBkZXBsb3llZCB3ZSBlaXRoZXIgcmVjb21tZW5kIHRoYXQgYWxsIGNsaWVudHMgYXJl IHVwZ3JhZGVkIHRvIHN1cHBvcnQgdGhpcyBleHRlbnNpb24gYXQgdGhlIHNhbWUgdGltZSBvciBh dCBsZWFzdCBkZXBsb3ltZW50cyBzcGVjaWZ5IGNvbXBhdGlibGUgcG9saWNpZXMgZm9yIGRpZmZl cmVudCBhcHBsaWNhdGlvbnMuDQo8YnI+DQo8YnI+DQpJIGNhbiBzdWdnZXN0IHNvbWUgdGV4dC4g PGJyPg0KPGJyPg0KJmd0OyBJcyBpdCBva2F5IGluIHRoaXMgc2l0dWF0aW9uIHRoYXQgdGhlIHBy aXZhdGUgY2hhdCBvZiB0d28gZG9jdG9ycyBhYm91dCB0aGVpciBsYXN0IHNraS1ob2xpZGF5cyBz dGFydmVzIHJlcXVlc3RzIHRvIGFjY2VzcyB0aGUgbmV0d29yayB0byBzZW5kIGluc3RydWN0b3Ig bWVzc2FnZSB0byB0aGUgZmlyZWZpZ2h0ZXJzPw0KPGJyPg0KPGJyPg0KV2UgY2FuJ3QgcHJldmVu dCBhbGwgcHJvYmxlbXMgbGlrZSB0aGlzLCBhcyB0aGUgYWJvdmUgaXMgcmVhbGx5IGEgc29jaWFs IHByb2JsZW0gY29tYmluZWQgd2l0aCBtaXNjb25maWd1cmF0aW9uLiBCdXQgd2UgY2FuIHdhcm4g YWJvdXQgaXQuDQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgKEFuZCBob3cgZG8gaSBtYWtlIHN1cmUg dGhhdCB0aGF0IGFsbCBvdGhlciBvdGhlciByZXF1ZXN0cyBhY3R1YWxseSBzZWxlY3QgYSBsb3dl ciBwcmlvcml0eSB0aGFuIDEw4oCmPyBCdXQgdGhhdOKAmXMgYSBkaWZmZXJlbnQgcXVlc3Rpb27i gKYpDQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgTWlyamEgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi cj4NCiZndDsmZ3Q7IEFtIDExLjA1LjIwMTYgdW0gMDY6NTkgc2NocmllYiBBbGV4ZXkgTWVsbmlr b3YgJmx0O2FhbWVsbmlrb3ZAZmFzdG1haWwuZm0mZ3Q7OiA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQom Z3Q7Jmd0OyBIaSBNaXJqYSwgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgT24gMTAgTWF5 IDIwMTYsIGF0IDE3OjU5LCBNaXJqYSBLdWVobGV3aW5kIChJRVRGKSAmbHQ7aWV0ZkBrdWVobGV3 aW5kLm5ldCZndDsgd3JvdGU6DQo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBJIGRvbuKAmXQgdGhpbmsgaXQgaXMgYSBnb29kIGlkZWEgdG8gYXNzaWduIGEgZGVmYXVs dCBwcmlvcml0eSB0byBub24tcHJpb3JpdHktZGVmaW5lZCByZXF1ZXN0cyBhdCBhbGwuIElmIHlv dSBoYXZlIGhpZ2ggcHJpb3JpdHkgdHJhZmZpYyB0aGF0IGRvZXMgbm90IHN1cHBvcnQgdGhpcyBl eHRlbnNpb24gKHlldCkgdGhpcyB0cmFmZmljIGNvdWxkIGJlIHN0YXJ2ZWQgYnkgbG93ZXIgcHJp b3JpdHkgdHJhZmZpYyB3aGVuIGFzc2lnbmluZyBhDQogbWlkZGxlIHJhbmdlIHByaW9yaXR5LiBJ IGRvbuKAmXQgdGhpbmsgdGhhdCBpcyB3aGF0IHlvdSB3YW50IHRvIGFjaGlldmUuIDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgU1JEJmd0OyBBY3R1YWxseSwgdGhpcyBpcyB3aGF0IHdlIHdhbnQgdG8g YWNoaWV2ZS4mbmJzcDsgSXQgaXMgYW4gcmVxdWlyZW1lbnQgdGhhdCBtZXNzYWdlcyBleHBsaWNp dGx5IG1hcmtlZCBhcyBoaWdoIHByaW9yaXR5IGdldCB0cmVhdGVkIGV2ZW4gaWYgaXQgcmVzdWx0 cyBpbiBzdGFydmluZyBsb3dlciBwcmlvcml0eSBtZXNzYWdlcy4mbmJzcDsgVGhlIHN0YXJ2aW5n IG9mIGxvd2VyIHByaW9yaXR5IG1lc3NhZ2VzIGlzIG5vdCBhbiBwcm9ibGVtLCBpdCBpcw0KIGEg cmVxdWlyZW1lbnQuIDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgSSB0aGlu ayB3ZSBhcmUgc3RpbGwgdGFsa2luZyBwYXN0IGVhY2ggb3RoZXIuIDxicj4NCiZndDsmZ3Q7IDxi cj4NCiZndDsmZ3Q7IE1vc3QgZGVmaW5pdGVseSA6LSkuIDxicj4NCiZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7Jmd0OyBJZiB5b3UgZXhwbGljaXRseSBhc3NpZ24gYSBwcmlvcml0eSwgc3RhcnZhdGlv biBtaWdodCBiZSBva2F5LiBIb3dldmVyLCBpZiB5b3UgZG9u4oCZdCBoYXZlIGEgcHJpb3JpdHkg ZXhwbGljaXRseSBzaWduYWxlZCwgdGhlIHRyYW5zYWN0aW9uIG1pZ2h0IGhhdmUgYSB2ZXJ5IGhp Z2ggcHJpb3JpdHkNCjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFNvIHNvbWUgYWdlbnQg aW4gdGhlIHN5c3RlbSBuZWVkcyB0byBkZWNpZGUgdGhhdCBhIHRyYW5zYWN0aW9uIGlzIGltcG9y dGFudC4gPGJyPg0KJmd0OyZndDsmZ3Q7IGJ1dCB5b3UganVzdCBkb27igJl0IGtub3cgYW5kIGJ5 IGFzc2lnbmluZyBhIHJhbmRvbSBtaWQtcmFuZ2UgcHJpb3JpdHkgdGhpcyBpbXBvcnRhbnQgcmVx dWVzdCBjb3VsZCBnZXQgc3RhcnZlZC4NCjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEhl cmUgSSBkaXNhZ3JlZSB3aXRoIHlvdSwgYmVjYXVzZSB0aGUgd2F5IHRvIGtub3cgdGhhdCBhIHRy YW5zYWN0aW9uIGlzIGltcG9ydGFudCBpcyB0byB1cGdyYWRlIGNsaWVudCB0byBleHBsaWNpdGx5 IGFzc2lnbiBoaWdoIHByaW9yaXR5IHRvIGl0LiBTbyBkZWZhdWx0IHByaW9yaXR5IGlzIGEgYmFj a3dhcmQgY29tcGF0aWJpbGl0eSBtZWNoYW5pc20sIHRoYXQgd291bGQgd29yayBmb3IgbW9zdCBj b21tb24gY2FzZXMuIFlvdSBzZWVtIHRvDQogYmUgc3VnZ2VzdGluZyB0aGF0IHdoZW4gdGhpcyBl eHRlbnNpb24gaXMgZGVwbG95ZWQgYWxsIGNsaWVudHMgbmVlZCB0byBiZSB1cGRhdGVkIGF0IHRo ZSBzYW1lIHRpbWUuIFRoaXMgaXMgbm90IHJlYWxpc3RpYy4NCjxicj4NCiZndDsgPGJyPg0KPGJy Pg0KPC9wPg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBv dSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2Ug cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_6B7134B31289DC4FAF731D844122B36E01E60871OPEXCLILM43corp_-- From nobody Wed May 11 15:04: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 8F88712D796; Wed, 11 May 2016 15:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 EvOi_D2LVP3U; Wed, 11 May 2016 15:03:58 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 EF7B712D793; Wed, 11 May 2016 15:03:57 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:49372 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 1b0cEQ-002uUh-MT; Wed, 11 May 2016 15:03:55 -0700 To: Stephen Farrell , Mirja Kuehlewind , The IESG References: <20160511173425.15223.72665.idtracker@ietfa.amsl.com> <573370AC.9050408@cs.tcd.ie> From: Steve Donovan Message-ID: <5733AC45.8060309@usdonovans.com> Date: Wed, 11 May 2016 17:03:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <573370AC.9050408@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------020206070607040503000807" X-OutGoing-Spam-Status: No, score=-1.0 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: Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-dime-drmp-05=3A_=28with_COMMENT=29?= 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, 11 May 2016 22:03:59 -0000 This is a multi-part message in MIME format. --------------020206070607040503000807 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I am in the process of updating the draft. I hope to have a new version for review early next week. Regards, Steve On 5/11/16 12:49 PM, Stephen Farrell wrote: > Thanks Mirja and all for the discussion. > > Authors - if you're ready, please do go ahead now and update > the draft based on all the discussion to date and we can then > check back with the various ADs who've commented. (I think > Alexey said he'd suggest a bit of text to address Mirja's > concern, so please do check with him as you prepare the > revision.) > > Cheers, > S. > > On 11/05/16 18:34, Mirja Kuehlewind wrote: >> Mirja Kühlewind has entered the following ballot position for >> draft-ietf-dime-drmp-05: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I still think this part needs further clarification mostly regarding >> applicability and maybe a warning as it could lead to starvation of >> requests that do not define a priority, e.g. because there are not >> supporting it (yet) while effectively having a higher priortiy than the >> requests that they get starved by: >> "When using DRMP priority information, Diameter nodes MUST use the >> default priority for transactions that do not have priority specified >> in a DRMP AVP." >> >> >> _______________________________________________ >> 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 --------------020206070607040503000807 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I am in the process of updating the draft.  I hope to have a new version for review early next week.

Regards,

Steve

On 5/11/16 12:49 PM, Stephen Farrell wrote:
Thanks Mirja and all for the discussion.

Authors - if you're ready, please do go ahead now and update
the draft based on all the discussion to date and we can then
check back with the various ADs who've commented. (I think
Alexey said he'd suggest a bit of text to address Mirja's
concern, so please do check with him as you prepare the
revision.)

Cheers,
S.

On 11/05/16 18:34, Mirja Kuehlewind wrote:

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dime-drmp-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this 
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I still think this part needs further clarification mostly regarding
applicability and maybe a warning as it could lead to starvation of
requests that do not define a priority, e.g. because there are not
supporting it (yet) while effectively having a higher priortiy than the
requests that they get starved by:
"When using DRMP priority information, Diameter nodes MUST use the
   default priority for transactions that do not have priority specified
   in a DRMP AVP."


_______________________________________________
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


    

    

  


--------------020206070607040503000807--


From nobody Thu May 12 05:20: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 5F71212D9A5; Thu, 12 May 2016 05:20:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.297
X-Spam-Level: 
X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 syeV-IdlVQeA; Thu, 12 May 2016 05:20:26 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1E412D9A6; Thu, 12 May 2016 05:20:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EC518BE4D; Thu, 12 May 2016 13:20:21 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ab0wmsbFvN3x; Thu, 12 May 2016 13:20:20 +0100 (IST)
Received: from [192.168.2.145] (70-91-193-41-BusName-NewEngland.hfc.comcastbusiness.net [70.91.193.41]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3C978BE51; Thu, 12 May 2016 13:20:15 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463055616; bh=RbJKHbb7VUH7V9QLpPcTv80GbsfxCoUHhf6BSZYcvlM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=CMT5nciGmuf249U2BOBTHpYD4uUjITo3f8oOSLJsueCFkz6VLkhjCXAUNWrJcPMTq UT7KhDpAmmSFFuO2odZZvDQJBbGrNhfFc9tpVS/1wGR3GQNm7Ae30PLy6EeNuCdY0a YF4eX9c303P57iUaHbH7HHa7pL4VD5R3B+AH0ErY=
To: Steve Donovan , Mirja Kuehlewind , The IESG 
References: <20160511173425.15223.72665.idtracker@ietfa.amsl.com> <573370AC.9050408@cs.tcd.ie> <5733AC45.8060309@usdonovans.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <573474FD.20705@cs.tcd.ie>
Date: Thu, 12 May 2016 13:20:13 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <5733AC45.8060309@usdonovans.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090305040905010904050704"
Archived-At: 
Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org
Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-dime-drmp-05=3A_=28with_COMMENT=29?=
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, 12 May 2016 12:20:29 -0000

This is a cryptographically signed message in MIME format.

--------------ms090305040905010904050704
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 11/05/16 23:03, Steve Donovan wrote:
> I am in the process of updating the draft.  I hope to have a new versio=
n
> for review early next week.

Great,
S

>=20
> Regards,
>=20
> Steve
>=20
> On 5/11/16 12:49 PM, Stephen Farrell wrote:
>> Thanks Mirja and all for the discussion.
>>
>> Authors - if you're ready, please do go ahead now and update
>> the draft based on all the discussion to date and we can then
>> check back with the various ADs who've commented. (I think
>> Alexey said he'd suggest a bit of text to address Mirja's
>> concern, so please do check with him as you prepare the
>> revision.)
>>
>> Cheers,
>> S.
>>
>> On 11/05/16 18:34, Mirja Kuehlewind wrote:
>>> Mirja K=C3=BChlewind has entered the following ballot position for
>>> draft-ietf-dime-drmp-05: No Objection
>>>
>>> When responding, please keep the subject line intact and reply to all=

>>> email addresses included in the To and CC lines. (Feel free to cut th=
is
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/
>>>
>>>
>>>
>>> ---------------------------------------------------------------------=
-
>>> COMMENT:
>>> ---------------------------------------------------------------------=
-
>>>
>>> I still think this part needs further clarification mostly regarding
>>> applicability and maybe a warning as it could lead to starvation of
>>> requests that do not define a priority, e.g. because there are not
>>> supporting it (yet) while effectively having a higher priortiy than t=
he
>>> requests that they get starved by:
>>> "When using DRMP priority information, Diameter nodes MUST use the
>>>     default priority for transactions that do not have priority
>>> specified
>>>     in a DRMP AVP."
>>>
>>>
>>> _______________________________________________
>>> 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


--------------ms090305040905010904050704
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTIx
MjIwMTNaMC8GCSqGSIb3DQEJBDEiBCA4ymh3d/lDAVlQ6Hb6slBtuq/GQieru2w9J0BWkPs2
UTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQAIopsEZFwlAcmeFUuN6YlrlCVV3blgZPDGYlEc5aCK53tmZaOsFXOP
xxDMyn6nKmn0qx632NRHkzwTLYsFtpIX/J9xS4qG0E1uPcrnc/nZUIUFOw1mpZcBp74YMLmP
iYnCSWFmAJ79TG5dQcp+h0OA3ek9cbgbOrQ1Vyi6jckl0HjnI0iqlBIZyF+3B2MyYjghwHuE
RPkL0WGnXaU7D2jjd467WHDklVW+w8/a1LEjgX1hj6o9J/oNdW3eKsaiKjPH9Viv3PUCSpo6
xSdYHWdgfuha4DAxdxKI86OVA8wyDzN5zx0/HGJjR2vJ7HI6sJB5v4ksUl3fMRMThjf5FLDw
AAAAAAAA
--------------ms090305040905010904050704--


From nobody Mon May 16 11:37:54 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 27E9A12D927 for ; Mon, 16 May 2016 11:37:52 -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 ENlCH5rZUfj6 for ; Mon, 16 May 2016 11:37:49 -0700 (PDT)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 A14F612D92B for ; Mon, 16 May 2016 11:37:49 -0700 (PDT)
Received: by mail-pa0-x22e.google.com with SMTP id xk12so67716303pac.0 for ; Mon, 16 May 2016 11:37:49 -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=T1kwYO66mozoOFh9LaNsb2qaHUNatzNN2Qzo/jt5tww=; b=Gf7Ks81A6cvMBKahnLF0mBvAXu70UZptGm4VvDc2YdZnBRARndFjk6eHAvvpkCS/g9 jaUq7BXHM9TuMIJ6RWS11apJThHnxE+kOULQqxtWr1deficitp6TrtVIx+fAMt60SYT7 7+exptX4peauxAkL8It/dQxOATmn8PAwiGOiIvIptqZYMndNbWj1KP775g34VMgd9CxT xB7rEXhs0/rWwDklj4Df8hOT5vpXMzwcGHfA8k1OOJq2gOImv3VAEiMQwVidyATnisfR pNyGPduS7WtmlyIWoeMwr0hZ5L/H6xAefqWAiyVLfrpt2r2TgbvpRHEXYrbl0k05/0zN m30A==
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=T1kwYO66mozoOFh9LaNsb2qaHUNatzNN2Qzo/jt5tww=; b=Crx9dGlyOOkx7x2eg20LDkcykSjr6oE3OAdTBaxInTaQeLqKJUptOl8IWLhCW4iQ+d tNgWUL3PmT4p186FC0Wy5GEFZ1r2Yk1DKs1vhRw99S9rl7uAp57Q/f90JHpxE9VUn8dT byNwcksQr6M2HhniB3273C2elNm0zg7+cBB4I2H6OsTSeAPOu2sBAF7kqB64E37dvHJ/ GRH1lW4cWvrAT7ZUF8ff1iEmXEDpxGzmvHeNv4yk3ufIxdJiGqKo3m2vkHqhYAOoPGFr HTZXSxDk+FfKkG5jiKewDEf/AvG2OEkttIJatY//QHksoqBskasWymcWrL6c4NBWy3xA OcmA==
X-Gm-Message-State: AOPr4FXENnII1689OcsG5ej0NwzUL512lRpo4jqANO2KgEVVz1iUHUlX9nhGGN61JgTCHg==
X-Received: by 10.66.43.241 with SMTP id z17mr48072952pal.18.1463423869236; Mon, 16 May 2016 11:37:49 -0700 (PDT)
Received: from [10.16.75.74] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id 1sm48989936pah.7.2016.05.16.11.37.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 May 2016 11:37:48 -0700 (PDT)
To: "dime@ietf.org" , Hannes Tschofenig 
From: Jouni Korhonen 
Message-ID: <573A1375.4020003@gmail.com>
Date: Mon, 16 May 2016 11:37:41 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Dime] end to end security solution..
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, 16 May 2016 18:37:52 -0000

Folks,

In IETF95 we visited graveyard and reincarnated the discussion on e2e 
security. We do have one proposal on table: 
https://tools.ietf.org/html/draft-korhonen-dime-e2e-security-03

Putting aside the JSON vs. CBOR/COSE topic (i.e., forget the encoding 
method), I'd like to have the discussion whether the framework presented 
in the draft is actually acceptable and could serve as a starting point 
for the WG solution. Yes, this means you actually need to read the draft.

Regards,
	Jouni


From nobody Tue May 17 01:38: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 BF10A12B056; Tue, 17 May 2016 01:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.328
X-Spam-Level: 
X-Spam-Status: No, score=-108.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 kjQoe77eOZeS; Tue, 17 May 2016 01:38:15 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A71212B033; Tue, 17 May 2016 01:38:15 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 62BF4180004; Tue, 17 May 2016 01:38:06 -0700 (PDT)
To: lionel.morand@orange.com, vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20160517083806.62BF4180004@rfc-editor.org>
Date: Tue, 17 May 2016 01:38:06 -0700 (PDT)
Archived-At: 
Cc: dime@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org
Subject: [Dime] [Errata Verified] RFC6733 (4615)
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, 17 May 2016 08:38:17 -0000

The following errata report has been verified for RFC6733,
"Diameter Base Protocol". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4615

--------------------------------------
Status: Verified
Type: Technical

Reported by: Lionel Morand 
Date Reported: 2016-02-05
Verified by: Benoit Claise (IESG)

Section: 7.1.5

Original Text
-------------
   DIAMETER_AVP_UNSUPPORTED 5001

      The peer received a message that contained an AVP that is not
      recognized or supported and was marked with the 'M' (Mandatory)
      bit.  A Diameter message with this error MUST contain one or more
      Failed-AVP AVPs containing the AVPs that caused the failure.

Corrected Text
--------------
   DIAMETER_AVP_UNSUPPORTED 5001

      The peer received a message that contained an AVP that is not
      recognized or supported and was marked with the 'M' (Mandatory)
      bit.  A Diameter message with this error MUST contain one 
      Failed-AVP AVP containing the AVPs that caused the failure.

Notes
-----
The RFC6733 has clarified that only one instance of Failed-AVP AVP can be present in the command answer. One Failed-AVP AVP is enough because this AVP is defined as Grouped AVP that can contain multiple AVPs. In the present case, each of the nested AVPs in the Failed-AVP AVP are the AVPs that caused the failure.

--------------------------------------
RFC6733 (draft-ietf-dime-rfc3588bis-33)
--------------------------------------
Title               : Diameter Base Protocol
Publication Date    : October 2012
Author(s)           : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.
Category            : PROPOSED STANDARD
Source              : Diameter Maintenance and Extensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


From nobody Tue May 17 03:06: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 ED78112B048 for ; Tue, 17 May 2016 01:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level: 
X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 xbCeMXtkvlbc for ; Tue, 17 May 2016 01:27:26 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A808812B041 for ; Tue, 17 May 2016 01:27:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3624; q=dns/txt; s=iport; t=1463473645; x=1464683245; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=8kEAdLSVTXK1OmzJZmva+SxUzP96u5og52akW1si6zY=; b=OEocDtM9Df3bs6Wrp8BDLLoA8X4boinMCCY23Ar80JcJaOM8N/tgvc5l XBbOStFsaqeGCWDuac1RsWYVvtn6X4R2a4pzM2ybnXmZyLwYoBiogQFnp nbg8cRTyj/uIMHQJcHytjqR0x6AG5hGlReblxnP5pgfXyMh6EUsK1Kq9R k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsBABm1TpX/xbLJq1DGoQMfq4PjWoih?= =?us-ascii?q?W8CggABAQEBAQFmJ4RDAQEEMgEFQAEQCyEWCAcJAwIBAgEPJREGAQwGAgEBiBE?= =?us-ascii?q?DFw4svigNhCcBAQEBAQEBAQEBAQEBAQEBAQEBAQEchiWETYE5gQqBThEBhXUBB?= =?us-ascii?q?Id+CocJiGcxjCaBeYFphE+DB4Vahi6BL4dlYoIGDQ6BTToyAROGPYE1AQEB?=
X-IronPort-AV: E=Sophos;i="5.26,324,1459814400"; d="scan'208";a="637502816"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 May 2016 08:27:23 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u4H8RMfM010457; Tue, 17 May 2016 08:27:22 GMT
To: lionel.morand@orange.com, RFC Errata System , "jouni.nospam@gmail.com" , "srdonovan@usdonovans.com" , "ben@nostrum.com" , "joelja@bogus.com" 
References: <20151201175847.12786181B3D@rfc-editor.org> <24274_1449136067_56600FC3_24274_506_1_6B7134B31289DC4FAF731D844122B36E01D7CF60@OPEXCLILM43.corporate.adroot.infra.ftgroup>
From: Benoit Claise 
Message-ID: <573AD5EA.6050108@cisco.com>
Date: Tue, 17 May 2016 10:27:22 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <24274_1449136067_56600FC3_24274_506_1_6B7134B31289DC4FAF731D844122B36E01D7CF60@OPEXCLILM43.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-Mailman-Approved-At: Tue, 17 May 2016 03:06:38 -0700
Cc: "jkayser@netnumber.com" , "dime@ietf.org" 
Subject: Re: [Dime] [Technical Errata Reported] RFC7683 (4549)
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, 17 May 2016 08:27:28 -0000

Dear all,

Can someone update the justification, so that this errata can be verified.
Alternatively, send me the correct justification text.

Regards, B.
> The errata is correct but not the justification. The overloaded realm is obviously the one identified as source of the command, whatever the type (request or answer). So it must be the Origin-Realm of the command.
>
> Regards,
>
> Lionel
>
> -----Message d'origine-----
> De : RFC Errata System [mailto:rfc-editor@rfc-editor.org]
> Envoyé : mardi 1 décembre 2015 18:59
> À : jouni.nospam@gmail.com; srdonovan@usdonovans.com; ben@nostrum.com; MORAND Lionel IMT/OLN; bclaise@cisco.com; joelja@bogus.com; jouni.nospam@gmail.com; MORAND Lionel IMT/OLN
> Cc : jkayser@netnumber.com; dime@ietf.org; rfc-editor@rfc-editor.org
> Objet : [Technical Errata Reported] RFC7683 (4549)
>
> The following errata report has been submitted for RFC7683, "Diameter Overload Indication Conveyance".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=7683&eid=4549
>
> --------------------------------------
> Type: Technical
> Reported by: Jan Kayser 
>
> Section: 4.3
>
> Original Text
> -------------
> The overloaded realm is identified by the Destination-Realm AVP of the message containing the OLR.
>
> Corrected Text
> --------------
> The overloaded realm is identified by the Origin-Realm AVP of the message containing the OLR.
>
> Notes
> -----
> OLRs (OC-OLR AVPs) are sent exclusively in answer messages and not in requests. Therefore, the OLR message (answer) does not include a Destination-Realm AVP, but only a Origin-Realm AVP.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC7683 (draft-ietf-dime-ovli-10)
> --------------------------------------
> Title               : Diameter Overload Indication Conveyance
> Publication Date    : October 2015
> Author(s)           : J. Korhonen, Ed., S. Donovan, Ed., B. Campbell, L. Morand
> Category            : PROPOSED STANDARD
> Source              : Diameter Maintenance and Extensions
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci
>
> 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 authorization.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
> Thank you.
>
> .
>


From nobody Tue May 17 03:06: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 50A9212B05D for ; Tue, 17 May 2016 03:05:44 -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 Ee6x0Wk1qlvM for ; Tue, 17 May 2016 03:05:40 -0700 (PDT)
Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4F012B030 for ; Tue, 17 May 2016 03:05:40 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 77E53C08D5; Tue, 17 May 2016 12:05:38 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 196101A005E; Tue, 17 May 2016 12:05:38 +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, 17 May 2016 12:05:37 +0200
From: 
To: Benoit Claise , RFC Errata System , "jouni.nospam@gmail.com" , "srdonovan@usdonovans.com" , "ben@nostrum.com" , "joelja@bogus.com" 
Thread-Topic: [Technical Errata Reported] RFC7683 (4549)
Thread-Index: AQHRsBXwo+Ag62eyc0qNLHaJgF0B9Z+85g1Q
Date: Tue, 17 May 2016 10:05:37 +0000
Message-ID: <22162_1463479538_573AECF2_22162_1631_1_6B7134B31289DC4FAF731D844122B36E01E66E22@OPEXCLILM43.corporate.adroot.infra.ftgroup>
References: <20151201175847.12786181B3D@rfc-editor.org> <24274_1449136067_56600FC3_24274_506_1_6B7134B31289DC4FAF731D844122B36E01D7CF60@OPEXCLILM43.corporate.adroot.infra.ftgroup> <573AD5EA.6050108@cisco.com>
In-Reply-To: <573AD5EA.6050108@cisco.com>
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
Archived-At: 
X-Mailman-Approved-At: Tue, 17 May 2016 03:06:38 -0700
Cc: "jkayser@netnumber.com" , "dime@ietf.org" 
Subject: Re: [Dime] [Technical Errata Reported] RFC7683 (4549)
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, 17 May 2016 10:05:44 -0000

Hi Benoit,

I think that the note could just say:=20

"When the overload report is of type "REALM_REPORT", the overloaded realm i=
s identified by the Origin-Realm AVP of the Diameter command i.e. the realm=
 of the originator of the Diameter command with the overload report."

Is it OK for you, Jan?

Regards,

Lionel

> -----Message d'origine-----
> De=A0: Benoit Claise [mailto:bclaise@cisco.com]
> Envoy=E9=A0: mardi 17 mai 2016 10:27
> =C0=A0: MORAND Lionel IMT/OLN; RFC Errata System; jouni.nospam@gmail.com;
> srdonovan@usdonovans.com; ben@nostrum.com; joelja@bogus.com
> Cc=A0: jkayser@netnumber.com; dime@ietf.org; Kathleen Moriarty; Stephen
> Farrell
> Objet=A0: Re: [Technical Errata Reported] RFC7683 (4549)
>=20
> Dear all,
>=20
> Can someone update the justification, so that this errata can be verified.
> Alternatively, send me the correct justification text.
>=20
> Regards, B.
> > The errata is correct but not the justification. The overloaded realm is
> obviously the one identified as source of the command, whatever the type
> (request or answer). So it must be the Origin-Realm of the command.
> >
> > Regards,
> >
> > Lionel
> >
> > -----Message d'origine-----
> > De : RFC Errata System [mailto:rfc-editor@rfc-editor.org]
> > Envoy=E9 : mardi 1 d=E9cembre 2015 18:59
> > =C0 : jouni.nospam@gmail.com; srdonovan@usdonovans.com;
> ben@nostrum.com;
> > MORAND Lionel IMT/OLN; bclaise@cisco.com; joelja@bogus.com;
> > jouni.nospam@gmail.com; MORAND Lionel IMT/OLN Cc :
> > jkayser@netnumber.com; dime@ietf.org; rfc-editor@rfc-editor.org Objet
> > : [Technical Errata Reported] RFC7683 (4549)
> >
> > The following errata report has been submitted for RFC7683, "Diameter
> Overload Indication Conveyance".
> >
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata_search.php?rfc=3D7683&eid=3D4549
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Jan Kayser 
> >
> > Section: 4.3
> >
> > Original Text
> > -------------
> > The overloaded realm is identified by the Destination-Realm AVP of the
> message containing the OLR.
> >
> > Corrected Text
> > --------------
> > The overloaded realm is identified by the Origin-Realm AVP of the messa=
ge
> containing the OLR.
> >
> > Notes
> > -----
> > OLRs (OC-OLR AVPs) are sent exclusively in answer messages and not in
> requests. Therefore, the OLR message (answer) does not include a
> Destination-Realm AVP, but only a Origin-Realm AVP.
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please use
> "Reply All" to discuss whether it should be verified or rejected. When a
> decision is reached, the verifying party (IESG) can log in to change the =
status
> and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC7683 (draft-ietf-dime-ovli-10)
> > --------------------------------------
> > Title               : Diameter Overload Indication Conveyance
> > Publication Date    : October 2015
> > Author(s)           : J. Korhonen, Ed., S. Donovan, Ed., B. Campbell, L=
. Morand
> > Category            : PROPOSED STANDARD
> > Source              : Diameter Maintenance and Extensions
> > Area                : Operations and Management
> > Stream              : IETF
> > Verifying Party     : IESG
> >
> >
> >
> __________________________________________________________
> ____________
> > ___________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles 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 electroniques etant susceptibles
> > d'alteration, France Telecom - Orange decline toute responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci
> >
> > 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 authorization.
> > If you have received this email in error, please notify the sender and =
delete
> this message and its attachments.
> > As emails may be altered, France Telecom - Orange shall not be liable i=
f this
> message was modified, changed or falsified.
> > Thank you.
> >
> > .
> >


___________________________________________________________________________=
______________________________________________

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 jkayser@netnumber.com  Tue May 17 03:23: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 92A5312D74A for ; Tue, 17 May 2016 03:23:44 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netnum.onmicrosoft.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 xJ-nFhHk3tqQ for ; Tue, 17 May 2016 03:23:40 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0793.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:793]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4E112D745 for ; Tue, 17 May 2016 03:23:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netnum.onmicrosoft.com; s=selector1-netnumber-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=O8miYh590LYtI2PZY5Rg91exBPg5XlelGbuuIeCFXuI=; b=eRE7PR4tayo5jGaBULW+gWYSAa6W3z0RH1LrHetU/dcgl6tqZJtjvxHRKilaLB8/gEzW5VixGrN8Se8wR9G4uEHy4mA2mBaQifjbq3q07MuosGNZ1wZxaYgHIMhucnn1FJmc2unmwLX4VUyGi9kvt9YqPGdYGEoTkEGuAPRlPHM=
Received: from BY1PR01MB1369.prod.exchangelabs.com (10.162.211.143) by BY1PR01MB1369.prod.exchangelabs.com (10.162.211.143) with Microsoft SMTP Server (TLS) id 15.1.497.12; Tue, 17 May 2016 10:23:22 +0000
Received: from BY1PR01MB1369.prod.exchangelabs.com ([10.162.211.143]) by BY1PR01MB1369.prod.exchangelabs.com ([10.162.211.143]) with mapi id 15.01.0497.019; Tue, 17 May 2016 10:23:22 +0000
From: Jan Kayser 
To: "lionel.morand@orange.com" , Benoit Claise , RFC Errata System , "jouni.nospam@gmail.com" , "srdonovan@usdonovans.com" , "ben@nostrum.com" , "joelja@bogus.com" 
Thread-Topic: [Technical Errata Reported] RFC7683 (4549)
Thread-Index: AQHRLGIsRRHrV5YbikmOwpI5LDVnxJ65Bo8AgQTMigCAABtzgIAABPZA
Date: Tue, 17 May 2016 10:23:22 +0000
Message-ID: 
References: <20151201175847.12786181B3D@rfc-editor.org> <24274_1449136067_56600FC3_24274_506_1_6B7134B31289DC4FAF731D844122B36E01D7CF60@OPEXCLILM43.corporate.adroot.infra.ftgroup> <573AD5EA.6050108@cisco.com>, <22162_1463479538_573AECF2_22162_1631_1_6B7134B31289DC4FAF731D844122B36E01E66E22@OPEXCLILM43.corporate.adroot.infra.ftgroup>
In-Reply-To: <22162_1463479538_573AECF2_22162_1631_1_6B7134B31289DC4FAF731D844122B36E01E66E22@OPEXCLILM43.corporate.adroot.infra.ftgroup>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=netnumber.com;
x-originating-ip: [176.4.34.202]
x-ms-office365-filtering-correlation-id: 3bd93ded-628a-483c-bfff-08d37e3d462f
x-microsoft-exchange-diagnostics: 1; BY1PR01MB1369; 5:yFDTFeubJ435CK8N/dXHrhKa1miP+asoix6pW7f1KsTr1zOChzmO2E82GYk/gu/Gmw9WpU/7Zh0Rgm97sOoipNzSKSWLbpjWho1WvEh38ydTU53kwdkE8d5AoO7akUmW3k9gqIoTBhpM35SYSvo0iQ==; 24:hOxsqXEmUQVF0bh+WBn6bMBOHdx/1j3HI8CO11PR83317LVifUnSKIRQheTI4JHRe9pZoh0DkzfAAWRxIHq1vhoEdqKCqtuGa3o+avo49ro=; 7:QmWUJArmpRHC0WQaCW6PctVimrwIqdHtKfzVwpfhiUgEkhp9JFbfdQ0o7R++M/5ypSCIPZrkz4T2rsaNzzWVjxVUqTXU2hBHQbhmpE3VFCXPKx7nRDjtMCYwg0vk+p0avmggKHpCKgPb6sVgxWh0/QICIQLA/cLZqtHlJ/nPWg8373pE79jOY/qhF2UVS0c8
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR01MB1369;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BY1PR01MB1369; BCL:0; PCL:0; RULEID:; SRVR:BY1PR01MB1369; 
x-forefront-prvs: 0945B0CC72
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51444003)(252514010)(10400500002)(9686002)(77096005)(81166006)(8676002)(19617315012)(15975445007)(3280700002)(189998001)(229853001)(586003)(19580405001)(15188155005)(66066001)(19580395003)(92566002)(3660700001)(16799955002)(2950100001)(2900100001)(5008740100001)(2906002)(106116001)(102836003)(6116002)(3846002)(4326007)(93886004)(5003600100002)(1220700001)(19625215002)(122556002)(86362001)(74316001)(2201001)(5001770100001)(5890100001)(2501003)(8936002)(5002640100001)(50986999)(87936001)(33656002)(16236675004)(11100500001)(54356999)(76176999)(5004730100002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR01MB1369; H:BY1PR01MB1369.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY1PR01MB13695F867D1BB3797F00844BB4480BY1PR01MB1369prod_"
MIME-Version: 1.0
X-OriginatorOrg: netnumber.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2016 10:23:22.2823 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 07ef59fc-9c49-430e-922e-28c86c69c13b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR01MB1369
Archived-At: 
X-Mailman-Approved-At: Tue, 17 May 2016 03:35:54 -0700
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [Technical Errata Reported] RFC7683 (4549)
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, 17 May 2016 10:35:20 -0000

--_000_BY1PR01MB13695F867D1BB3797F00844BB4480BY1PR01MB1369prod_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Lionel,



yes, that=92s perfectly fine with ne.



Best regards,
Jan Kayser

Product Manager
NetNumber, Inc.

Email: JKayser@netnumber.com
Mobile: +49 171 410 18 16



Von: lionel.morand@orange.com
Gesendet: Dienstag, 17. Mai 2016 12:05
An: Benoit Claise; RFC Errata System; jouni.nospam@gmail.com; srdonovan@usdonovans.com; ben@nostrum.c=
om; joelja@bogus.com
Cc: Jan Kayser; dime@ietf.org; Kathleen Moriarty; Stephen=
 Farrell
Betreff: RE: [Technical Errata Reported] RFC7683 (4549)



Hi Benoit,

I think that the note could just say:

"When the overload report is of type "REALM_REPORT", the overloaded realm i=
s identified by the Origin-Realm AVP of the Diameter command i.e. the realm=
 of the originator of the Diameter command with the overload report."

Is it OK for you, Jan?

Regards,

Lionel

> -----Message d'origine-----
> De : Benoit Claise [mailto:bclaise@cisco.com]
> Envoy=E9 : mardi 17 mai 2016 10:27
> =C0 : MORAND Lionel IMT/OLN; RFC Errata System; jouni.nospam@gmail.com;
> srdonovan@usdonovans.com; ben@nostrum.com; joelja@bogus.com
> Cc : jkayser@netnumber.com; dime@ietf.org; Kathleen Moriarty; Stephen
> Farrell
> Objet : Re: [Technical Errata Reported] RFC7683 (4549)
>
> Dear all,
>
> Can someone update the justification, so that this errata can be verified=
.
> Alternatively, send me the correct justification text.
>
> Regards, B.
> > The errata is correct but not the justification. The overloaded realm i=
s
> obviously the one identified as source of the command, whatever the type
> (request or answer). So it must be the Origin-Realm of the command.
> >
> > Regards,
> >
> > Lionel
> >
> > -----Message d'origine-----
> > De : RFC Errata System [mailto:rfc-editor@rfc-editor.org]
> > Envoy=E9 : mardi 1 d=E9cembre 2015 18:59
> > =C0 : jouni.nospam@gmail.com; srdonovan@usdonovans.com;
> ben@nostrum.com;
> > MORAND Lionel IMT/OLN; bclaise@cisco.com; joelja@bogus.com;
> > jouni.nospam@gmail.com; MORAND Lionel IMT/OLN Cc :
> > jkayser@netnumber.com; dime@ietf.org; rfc-editor@rfc-editor.org Objet
> > : [Technical Errata Reported] RFC7683 (4549)
> >
> > The following errata report has been submitted for RFC7683, "Diameter
> Overload Indication Conveyance".
> >
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata_search.php?rfc=3D7683&eid=3D4549
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Jan Kayser 
> >
> > Section: 4.3
> >
> > Original Text
> > -------------
> > The overloaded realm is identified by the Destination-Realm AVP of the
> message containing the OLR.
> >
> > Corrected Text
> > --------------
> > The overloaded realm is identified by the Origin-Realm AVP of the messa=
ge
> containing the OLR.
> >
> > Notes
> > -----
> > OLRs (OC-OLR AVPs) are sent exclusively in answer messages and not in
> requests. Therefore, the OLR message (answer) does not include a
> Destination-Realm AVP, but only a Origin-Realm AVP.
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please us=
e
> "Reply All" to discuss whether it should be verified or rejected. When a
> decision is reached, the verifying party (IESG) can log in to change the =
status
> and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC7683 (draft-ietf-dime-ovli-10)
> > --------------------------------------
> > Title               : Diameter Overload Indication Conveyance
> > Publication Date    : October 2015
> > Author(s)           : J. Korhonen, Ed., S. Donovan, Ed., B. Campbell, L=
. Morand
> > Category            : PROPOSED STANDARD
> > Source              : Diameter Maintenance and Extensions
> > Area                : Operations and Management
> > Stream              : IETF
> > Verifying Party     : IESG
> >
> >
> >
> __________________________________________________________
> ____________
> > ___________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles 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 electroniques etant susceptibles
> > d'alteration, France Telecom - Orange decline toute responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci
> >
> > 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 authorization.
> > If you have received this email in error, please notify the sender and =
delete
> this message and its attachments.
> > As emails may be altered, France Telecom - Orange shall not be liable i=
f this
> message was modified, changed or falsified.
> > Thank you.
> >
> > .
> >


___________________________________________________________________________=
______________________________________________

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.


--_000_BY1PR01MB13695F867D1BB3797F00844BB4480BY1PR01MB1369prod_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable















Hi Lionel,


 


yes, that=92s perfectly fine =
with ne.


 


Best regards,

Jan Kayser



Product Manager

NetNumber, Inc.



Email: JKayser@netnumber.com

Mobile: +49 171 410 18 16


 




Von: lionel.morand@orange.com

Gesendet: Dienstag, 17. Mai 2016 12:05

An: Benoit Claise; 
RFC Errata System; jouni.nosp=
am@gmail.com;
srdonovan@usdonovans.com; <=
a href=3D"mailto:ben@nostrum.com">
ben@nostrum.com; joelja@bogus.com

Cc: Jan Kayser; 
dime@ietf.org; Kath=
leen Moriarty;
Stephen Farrell

Betreff: RE: [Technical Errata Reported] RFC7683 (4549)




 







Hi Benoit,



I think that the note could just say: 



"When the overload report is of type "REALM_REPORT", the ove=
rloaded realm is identified by the Origin-Realm AVP of the Diameter command=
 i.e. the realm of the originator of the Diameter command with the overload=
 report."



Is it OK for you, Jan?



Regards,



Lionel



> -----Message d'origine-----

> De : Benoit Claise [mailto:b=
claise@cisco.com]

> Envoy=E9 : mardi 17 mai 2016 10:27

> =C0 : MORAND Lionel IMT/OLN; RFC Errata System; jouni.nospam@gmai=
l.com;

> srdonovan@usdonovans.com; ben@nostrum.com; joelja@bogus.com

> Cc : jkayser@netnumber.com; dime@ietf.org; Kathleen Moriarty; Ste=
phen

> Farrell

> Objet : Re: [Technical Errata Reported] RFC7683 (4549)

> 

> Dear all,

> 

> Can someone update the justification, so that this errata can be verif=
ied.

> Alternatively, send me the correct justification text.

> 

> Regards, B.

> > The errata is correct but not the justification. The overloaded r=
ealm is

> obviously the one identified as source of the command, whatever the ty=
pe

> (request or answer). So it must be the Origin-Realm of the command.
> >

> > Regards,

> >

> > Lionel

> >

> > -----Message d'origine-----

> > De : RFC Errata System [mailto:rfc-editor@rfc-editor.org]

> > Envoy=E9 : mardi 1 d=E9cembre 2015 18:59

> > =C0 : jouni.nospam@gmail.com; srdonovan@usdonovans.com;

> ben@nostrum.com;

> > MORAND Lionel IMT/OLN; bclaise@cisco.com; joelja@bogus.com;

> > jouni.nospam@gmail.com; MORAND Lionel IMT/OLN Cc :

> > jkayser@netnumber.com; dime@ietf.org; rfc-editor@rfc-editor.org O=
bjet

> > : [Technical Errata Reported] RFC7683 (4549)

> >

> > The following errata report has been submitted for RFC7683, "=
;Diameter

> Overload Indication Conveyance".

> >

> > --------------------------------------

> > You may review the report below and at:

> > http://www.rfc-editor.org/errata_search.php?rfc=3D7683&=
;eid=3D4549

> >

> > --------------------------------------

> > Type: Technical

> > Reported by: Jan Kayser <jkayser@netnumber.com>

> >

> > Section: 4.3

> >

> > Original Text

> > -------------

> > The overloaded realm is identified by the Destination-Realm AVP o=
f the

> message containing the OLR.

> >

> > Corrected Text

> > --------------

> > The overloaded realm is identified by the Origin-Realm AVP of the=
 message

> containing the OLR.

> >

> > Notes

> > -----

> > OLRs (OC-OLR AVPs) are sent exclusively in answer messages and no=
t in

> requests. Therefore, the OLR message (answer) does not include a

> Destination-Realm AVP, but only a Origin-Realm AVP.

> >

> > Instructions:

> > -------------

> > This erratum is currently posted as "Reported". If nece=
ssary, please use

> "Reply All" to discuss whether it should be verified or reje=
cted. When a

> decision is reached, the verifying party (IESG) can log in to change t=
he status

> and edit the report, if necessary.

> >

> > --------------------------------------

> > RFC7683 (draft-ietf-dime-ovli-10)

> > --------------------------------------

> > Title          =
     : Diameter Overload Indication Conveyance

> > Publication Date    : October 2015

> > Author(s)         &n=
bsp; : J. Korhonen, Ed., S. Donovan, Ed., B. Campbell, L. Morand

> > Category         &nb=
sp;  : PROPOSED STANDARD

> > Source          =
;    : Diameter Maintenance and Extensions

> > Area          &=
nbsp;     : Operations and Management

> > Stream          =
;    : IETF

> > Verifying Party     : IESG

> >

> >

> >

> __________________________________________________________

> ____________

> > ___________________________________________________

> >

> > Ce message et ses pieces jointes peuvent contenir des information=
s

> > confidentielles ou privilegiees et ne doivent donc pas etre diffu=
ses,

> > exploites ou copies sans autorisation. Si vous avez recu ce messa=
ge

> > par erreur, veuillez le signaler a l'expediteur et le detruire ai=
nsi

> > que les pieces jointes. Les messages electroniques etant suscepti=
bles

> > d'alteration, France Telecom - Orange decline toute responsabilit=
e si

> > ce message a ete altere, deforme ou falsifie. Merci

> >

> > 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 authorization.

> > If you have received this email in error, please notify the sende=
r and delete

> this message and its attachments.

> > As emails may be altered, France Telecom - Orange shall not be li=
able if this

> message was modified, changed or falsified.

> > Thank you.

> >

> > .

> >





___________________________________________________________________________=
______________________________________________



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.









--_000_BY1PR01MB13695F867D1BB3797F00844BB4480BY1PR01MB1369prod_--


From nobody Tue May 17 05:04: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 C139812D8A2; Tue, 17 May 2016 05:04:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.328
X-Spam-Level: 
X-Spam-Status: No, score=-108.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 wEbRphGa1eji; Tue, 17 May 2016 05:04:34 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E6E512D89E; Tue, 17 May 2016 05:04:29 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id C9E50180005; Tue, 17 May 2016 05:04:18 -0700 (PDT)
To: jkayser@netnumber.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com, ben@nostrum.com, lionel.morand@orange.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20160517120418.C9E50180005@rfc-editor.org>
Date: Tue, 17 May 2016 05:04:18 -0700 (PDT)
Archived-At: 
Cc: dime@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org
Subject: [Dime] [Errata Verified] RFC7683 (4549)
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, 17 May 2016 12:04:36 -0000

The following errata report has been verified for RFC7683,
"Diameter Overload Indication Conveyance". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7683&eid=4549

--------------------------------------
Status: Verified
Type: Technical

Reported by: Jan Kayser 
Date Reported: 2015-12-01
Verified by: Benoit Claise (IESG)

Section: 4.3

Original Text
-------------
The overloaded realm is identified by the Destination-Realm AVP 
of the message containing the OLR.

Corrected Text
--------------
The overloaded realm is identified by the Origin-Realm AVP
of the message containing the OLR.

Notes
-----
When the overload report is of type "REALM_REPORT", the overloaded realm is identified by the Origin-Realm AVP of the Diameter command i.e. the realm of the originator of the Diameter command with the overload report.

--------------------------------------
RFC7683 (draft-ietf-dime-ovli-10)
--------------------------------------
Title               : Diameter Overload Indication Conveyance
Publication Date    : October 2015
Author(s)           : J. Korhonen, Ed., S. Donovan, Ed., B. Campbell, L. Morand
Category            : PROPOSED STANDARD
Source              : Diameter Maintenance and Extensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


From nobody Wed May 18 11:31:33 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 0E1BD12D62C; Wed, 18 May 2016 11:31:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160518183130.14661.48115.idtracker@ietfa.amsl.com>
Date: Wed, 18 May 2016 11:31:30 -0700
Archived-At: 
Cc: dime@ietf.org
Subject: [Dime] I-D Action: draft-ietf-dime-drmp-06.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: Wed, 18 May 2016 18:31:30 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Diameter Maintenance and Extensions of the IETF.

        Title           : Diameter Routing Message Priority
        Author          : Steve Donovan
	Filename        : draft-ietf-dime-drmp-06.txt
	Pages           : 17
	Date            : 2016-05-18

Abstract:
   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.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dime-drmp-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-drmp-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed May 18 11:37:00 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 C990412D0F1 for ; Wed, 18 May 2016 11:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level: 
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 e-wLhjacw3pv for ; Wed, 18 May 2016 11:36:05 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 74ADC128B44 for ; Wed, 18 May 2016 11:36:05 -0700 (PDT)
Received: from [108.62.165.147] (port=61728 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 1b36K7-000UAm-Pq for dime@ietf.org; Wed, 18 May 2016 11:36:05 -0700
To: "dime@ietf.org" 
From: Steve Donovan 
Message-ID: 
Date: Wed, 18 May 2016 13:35:58 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------4B478905A350D4EB3DF41D03"
X-OutGoing-Spam-Status: No, score=2.5
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: 
X-Mailman-Approved-At: Wed, 18 May 2016 11:36:58 -0700
Subject: [Dime] New version of DRMP draft
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, 18 May 2016 18:36:08 -0000

This is a multi-part message in MIME format.
--------------4B478905A350D4EB3DF41D03
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

All,

I've posted the updated version of the DRMP draft, reflecting changes 
agreed to resulting from the IESG review of the document.

I've attached a diff file that shows the changes made between version 
-05 and version -06.

Regards,

Steve


--------------4B478905A350D4EB3DF41D03
Content-Type: text/html; charset=UTF-8;
 name="Diff_ draft-ietf-dime-drmp-05.txt - draft-ietf-dime-drmp-06.txt.html"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename*0="Diff_ draft-ietf-dime-drmp-05.txt - draft-ietf-dime-drmp-06.";
 filename*1="txt.html"

CjwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRp
b25hbC8vRU4iICJodHRwOi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFu
c2l0aW9uYWwuZHRkIj4gCjwhLS0gR2VuZXJhdGVkIGJ5IHJmY2RpZmYgMS40NTogcmZjZGlm
ZiAgLS0+IAo8IS0tIDwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgSFRNTCA0
LjAxIFRyYW5zaXRpb25hbCIgPiAtLT4KPCEtLSBTeXN0ZW06IExpbnV4IHppbmZhbmRlbCAz
LjIuMC00LWFtZDY0ICMxIFNNUCBEZWJpYW4gMy4yLjY4LTErZGViN3UyIHg4Nl82NCBHTlUv
TGludXggLS0+IAo8IS0tIFVzaW5nIGF3azogL3Vzci9iaW4vZ2F3azogR05VIEF3ayA0LjAu
MSAtLT4gCjwhLS0gVXNpbmcgZGlmZjogL3Vzci9iaW4vZGlmZjogZGlmZiAoR05VIGRpZmZ1
dGlscykgMy4yIC0tPiAKPCEtLSBVc2luZyB3ZGlmZjogL3Vzci9iaW4vd2RpZmY6IHdkaWZm
IChHTlUgd2RpZmYpIDEuMS4yIC0tPiAKPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3Jn
LzE5OTkveGh0bWwiPiAKPGhlYWQ+IAogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlw
ZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVURi04IiAvPiAKICA8bWV0YSBodHRw
LWVxdWl2PSJDb250ZW50LVN0eWxlLVR5cGUiIGNvbnRlbnQ9InRleHQvY3NzIiAvPiAKICA8
dGl0bGU+RGlmZjogZHJhZnQtaWV0Zi1kaW1lLWRybXAtMDUudHh0IC0gZHJhZnQtaWV0Zi1k
aW1lLWRybXAtMDYudHh0PC90aXRsZT4gCiAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4gCiAg
ICBib2R5ICAgIHsgbWFyZ2luOiAwLjRleDsgbWFyZ2luLXJpZ2h0OiBhdXRvOyB9IAogICAg
dHIgICAgICB7IH0gCiAgICB0ZCAgICAgIHsgd2hpdGUtc3BhY2U6IHByZTsgZm9udC1mYW1p
bHk6IG1vbm9zcGFjZTsgdmVydGljYWwtYWxpZ246IHRvcDsgZm9udC1zaXplOiAwLjg2ZW07
fSAKICAgIHRoICAgICAgeyBmb250LXNpemU6IDAuODZlbTsgfSAKICAgIC5zbWFsbCAgeyBm
b250LXNpemU6IDAuNmVtOyBmb250LXN0eWxlOiBpdGFsaWM7IGZvbnQtZmFtaWx5OiBWZXJk
YW5hLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IH0gCiAgICAubGVmdCAgIHsgYmFja2dyb3Vu
ZC1jb2xvcjogI0VFRTsgfSAKICAgIC5yaWdodCAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZG
OyB9IAogICAgLmRpZmYgICB7IGJhY2tncm91bmQtY29sb3I6ICNDQ0Y7IH0gCiAgICAubGJs
b2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0JGQjsgfSAKICAgIC5yYmxvY2sgeyBiYWNrZ3Jv
dW5kLWNvbG9yOiAjRkY4OyB9IAogICAgLmluc2VydCB7IGJhY2tncm91bmQtY29sb3I6ICM4
RkY7IH0gCiAgICAuZGVsZXRlIHsgYmFja2dyb3VuZC1jb2xvcjogI0FDRjsgfSAKICAgIC52
b2lkICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZCOyB9IAogICAgLmNvbnQgICB7IGJhY2tn
cm91bmQtY29sb3I6ICNFRUU7IH0gCiAgICAubGluZWJyIHsgYmFja2dyb3VuZC1jb2xvcjog
I0FBQTsgfSAKICAgIC5saW5lbm8geyBjb2xvcjogcmVkOyBiYWNrZ3JvdW5kLWNvbG9yOiAj
RkZGOyBmb250LXNpemU6IDAuN2VtOyB0ZXh0LWFsaWduOiByaWdodDsgcGFkZGluZzogMCAy
cHg7IH0gCiAgICAuZWxpcHNpc3sgYmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSAKICAgIC5s
ZWZ0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0RERDsgfSAKICAgIC5yaWdodCAuY29u
dCB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IH0gCiAgICAubGJsb2NrIC5jb250IHsgYmFj
a2dyb3VuZC1jb2xvcjogIzlEOTsgfSAKICAgIC5yYmxvY2sgLmNvbnQgeyBiYWNrZ3JvdW5k
LWNvbG9yOiAjREQ2OyB9IAogICAgLmluc2VydCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6
ICMwREQ7IH0gCiAgICAuZGVsZXRlIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogIzhBRDsg
fSAKICAgIC5zdGF0cywgLnN0YXRzIHRkLCAuc3RhdHMgdGggeyBiYWNrZ3JvdW5kLWNvbG9y
OiAjRUVFOyBwYWRkaW5nOiAycHggMDsgfSAKICAgIHNwYW4uaGlkZSB7IGRpc3BsYXk6IG5v
bmU7IGNvbG9yOiAjYWFhO30gICAgYTpob3ZlciBzcGFuIHsgZGlzcGxheTogaW5saW5lOyB9
ICAgIHRyLmNoYW5nZSB7IGJhY2tncm91bmQtY29sb3I6IGdyYXk7IH0gCiAgICB0ci5jaGFu
Z2UgYSB7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgY29sb3I6IGJsYWNrIH0gCiAgPC9zdHls
ZT4gCiAgICAgPHNjcmlwdD4KdmFyIGNodW5rX2luZGV4ID0gMDsKdmFyIG9sZF9jaHVuayA9
IG51bGw7CgpmdW5jdGlvbiBmb3JtYXRfY2h1bmsoaW5kZXgpIHsKICAgIHZhciBwcmVmaXgg
PSAiZGlmZiI7CiAgICB2YXIgc3RyID0gaW5kZXgudG9TdHJpbmcoKTsKICAgIGZvciAoeD0w
OyB4PCg0LXN0ci5sZW5ndGgpOyArK3gpIHsKICAgICAgICBwcmVmaXgrPScwJzsKICAgIH0K
ICAgIHJldHVybiBwcmVmaXggKyBzdHI7Cn0KCmZ1bmN0aW9uIGZpbmRfY2h1bmsobil7CiAg
ICByZXR1cm4gZG9jdW1lbnQucXVlcnlTZWxlY3RvcigndHJbaWQkPSInICsgbiArICciXScp
Owp9CgpmdW5jdGlvbiBjaGFuZ2VfY2h1bmsob2Zmc2V0KSB7CiAgICB2YXIgaW5kZXggPSBj
aHVua19pbmRleCArIG9mZnNldDsKICAgIHZhciBuZXdfc3RyOwogICAgdmFyIG5ld19jaHVu
azsKCiAgICBuZXdfc3RyID0gZm9ybWF0X2NodW5rKGluZGV4KTsKICAgIG5ld19jaHVuayA9
IGZpbmRfY2h1bmsobmV3X3N0cik7CiAgICBpZiAoIW5ld19jaHVuaykgewogICAgICAgIHJl
dHVybjsKICAgIH0KICAgIGlmIChvbGRfY2h1bmspIHsKICAgICAgICBvbGRfY2h1bmsuc3R5
bGUub3V0bGluZSA9ICIiOwogICAgfQogICAgb2xkX2NodW5rID0gbmV3X2NodW5rOwogICAg
b2xkX2NodW5rLnN0eWxlLm91dGxpbmUgPSAiMXB4IHNvbGlkIHJlZCI7CiAgICB3aW5kb3cu
bG9jYXRpb24uaGFzaCA9ICIjIiArIG5ld19zdHI7CiAgICB3aW5kb3cuc2Nyb2xsQnkoMCwt
MTAwKTsKICAgIGNodW5rX2luZGV4ID0gaW5kZXg7Cn0KCmRvY3VtZW50Lm9ua2V5ZG93biA9
IGZ1bmN0aW9uKGUpIHsKICAgIHN3aXRjaCAoZS5rZXlDb2RlKSB7CiAgICBjYXNlIDc4Ogog
ICAgICAgIGNoYW5nZV9jaHVuaygxKTsKICAgICAgICBicmVhazsKICAgIGNhc2UgODA6CiAg
ICAgICAgY2hhbmdlX2NodW5rKC0xKTsKICAgICAgICBicmVhazsKICAgIH0KfTsKICAgPC9z
Y3JpcHQ+IAo8L2hlYWQ+IAo8Ym9keSA+IAogIDx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRk
aW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+IAogIDx0ciBpZD0icGFydC0xIiBiZ2NvbG9yPSJv
cmFuZ2UiPjx0aD48L3RoPjx0aD48YSBocmVmPSIvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYt
ZGltZS1kcm1wLTA1LnR4dCIgc3R5bGU9ImNvbG9yOiMwMDg7IHRleHQtZGVjb3JhdGlvbjpu
b25lOyI+Jmx0OzwvYT4mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtaWV0Zi1kaW1lLWRybXAtMDUudHh0IiBzdHlsZT0iY29sb3I6IzAwOCI+ZHJh
ZnQtaWV0Zi1kaW1lLWRybXAtMDUudHh0PC9hPiZuYnNwOzwvdGg+PHRoPiA8L3RoPjx0aD4m
bmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1k
aW1lLWRybXAtMDYudHh0IiBzdHlsZT0iY29sb3I6IzAwOCI+ZHJhZnQtaWV0Zi1kaW1lLWRy
bXAtMDYudHh0PC9hPiZuYnNwOzxhIGhyZWY9Ii9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1k
aW1lLWRybXAtMDYudHh0IiBzdHlsZT0iY29sb3I6IzAwODsgdGV4dC1kZWNvcmF0aW9uOm5v
bmU7Ij4mZ3Q7PC9hPjwvdGg+PHRoPjwvdGg+PC90cj4gCiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+RGlhbWV0ZXIgTWFp
bnRlbmFuY2UgYW5kIEV4dGVuc2lvbnMgKERJTUUpICAgICAgICAgICAgICAgICAgICBTLiBE
b25vdmFuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+RGlhbWV0ZXIgTWFpbnRl
bmFuY2UgYW5kIEV4dGVuc2lvbnMgKERJTUUpICAgICAgICAgICAgICAgICAgICBTLiBEb25v
dmFuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5JbnRlcm5ldC1EcmFmdCAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPcmFjbGU8
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5JbnRlcm5ldC1EcmFmdCAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPcmFjbGU8L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDEi
Pjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxibG9jayI+SW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAg
ICAgICAgICAgICAgICAgICAgICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5BcHJpbCA1LDwvc3Bh
bj4gMjAxNjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj5JbnRlbmRlZCBzdGF0
dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3BhbiBj
bGFzcz0iaW5zZXJ0Ij5NYXkgMTgsPC9zcGFuPiAyMDE2PC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsYmxvY2siPkV4cGlyZXM6IDxzcGFuIGNsYXNzPSJkZWxldGUiPk9jdG9iZXIgNyw8
L3NwYW4+IDIwMTY8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+RXhwaXJlczog
PHNwYW4gY2xhc3M9Imluc2VydCI+Tm92ZW1iZXIgMTksPC9zcGFuPiAyMDE2PC90ZD48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICBE
aWFtZXRlciBSb3V0aW5nIE1lc3NhZ2UgUHJpb3JpdHk8L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgRGlhbWV0ZXIgUm91dGluZyBNZXNzYWdl
IFByaW9yaXR5PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIg
aWQ9ImRpZmYwMDAyIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICBkcmFm
dC1pZXRmLWRpbWUtZHJtcC0wPHNwYW4gY2xhc3M9ImRlbGV0ZSI+NTwvc3Bhbj4udHh0PC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICBk
cmFmdC1pZXRmLWRpbWUtZHJtcC0wPHNwYW4gY2xhc3M9Imluc2VydCI+Njwvc3Bhbj4udHh0
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkFic3RyYWN0PC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+QWJzdHJhY3Q8L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgV2hlbiBtYWtpbmcgcm91dGluZyBhbmQg
cmVzb3VyY2UgYWxsb2NhdGlvbiBkZWNpc2lvbnMsIERpYW1ldGVyIG5vZGVzPC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgV2hlbiBtYWtpbmcgcm91dGluZyBhbmQgcmVz
b3VyY2UgYWxsb2NhdGlvbiBkZWNpc2lvbnMsIERpYW1ldGVyIG5vZGVzPC90ZD48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjdXJyZW50bHkgaGF2ZSBubyBnZW5lcmljIG1lY2hh
bmlzbSB0byBkZXRlcm1pbmUgdGhlIHJlbGF0aXZlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyaWdodCI+ICAgY3VycmVudGx5IGhhdmUgbm8gZ2VuZXJpYyBtZWNoYW5pc20gdG8gZGV0
ZXJtaW5lIHRoZSByZWxhdGl2ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K
ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg
cHJpb3JpdHkgb2YgRGlhbWV0ZXIgbWVzc2FnZXMuICBUaGlzIGRvY3VtZW50IGFkZHJlc3Nl
cyB0aGlzIGJ5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHJpb3JpdHkg
b2YgRGlhbWV0ZXIgbWVzc2FnZXMuICBUaGlzIGRvY3VtZW50IGFkZHJlc3NlcyB0aGlzIGJ5
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZWZpbmluZyBhIG1lY2hhbmlz
bSB0byBhbGxvdyBEaWFtZXRlciBlbmRwb2ludHMgdG8gaW5kaWNhdGUgdGhlPC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGVmaW5pbmcgYSBtZWNoYW5pc20gdG8gYWxs
b3cgRGlhbWV0ZXIgZW5kcG9pbnRzIHRvIGluZGljYXRlIHRoZTwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+ICAgcmVsYXRpdmUgcHJpb3JpdHkgb2YgRGlhbWV0ZXIgdHJhbnNh
Y3Rpb25zLiAgV2l0aCB0aGlzIGluZm9ybWF0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyaWdodCI+ICAgcmVsYXRpdmUgcHJpb3JpdHkgb2YgRGlhbWV0ZXIgdHJhbnNhY3Rpb25z
LiAgV2l0aCB0aGlzIGluZm9ybWF0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0
Ij4gICBEaWFtZXRlciBub2RlcyBjYW4gZmFjdG9yIHRoYXQgcHJpb3JpdHkgaW50byByb3V0
aW5nLCByZXNvdXJjZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERpYW1l
dGVyIG5vZGVzIGNhbiBmYWN0b3IgdGhhdCBwcmlvcml0eSBpbnRvIHJvdXRpbmcsIHJlc291
cmNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhbGxvY2F0aW9uIGFuZCBv
dmVybG9hZCBhYmF0ZW1lbnQgZGVjaXNpb25zLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPiAgIGFsbG9jYXRpb24gYW5kIG92ZXJsb2FkIGFiYXRlbWVudCBkZWNpc2lvbnMu
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
ciBpZD0icGFydC0yIiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lw
cGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTIiPjxlbT4gcGFnZSAx
LCBsaW5lIDM2PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90
aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxh
IGhyZWY9IiNwYXJ0LTIiPjxlbT4gcGFnZSAxLCBsaW5lIDM2PHNwYW4gY2xhc3M9ImhpZGUi
PiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbnRlcm5ldC1E
cmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmlu
ZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEludGVybmV0LURyYWZ0cyBh
cmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nPC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUg
dGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZTwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmlnaHQiPiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVy
IGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs
ZWZ0Ij4gICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlz
dCBvZiBjdXJyZW50IEludGVybmV0LTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9m
IGN1cnJlbnQgSW50ZXJuZXQtPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBE
cmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50
Ly48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBEcmFmdHMgaXMgYXQgaHR0
cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBk
cmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzPC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm
dCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzPC90ZD48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk
LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueTwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9y
IG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55PC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij4gICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50
ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFm
dHMgYXMgcmVmZXJlbmNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg
ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtYXRl
cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4i
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbWF0ZXJpYWwgb3IgdG8gY2l0
ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIjwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90
ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDAz
Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsYmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24g
PHNwYW4gY2xhc3M9ImRlbGV0ZSI+T2N0b2JlciA3PC9zcGFuPiwgMjAxNi48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4
cGlyZSBvbiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5Ob3ZlbWJlciAxOTwvc3Bhbj4sIDIwMTYu
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkNvcHlyaWdodCBO
b3RpY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5Db3B5cmlnaHQgTm90aWNl
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENvcHlyaWdo
dCAoYykgMjAxNiBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRo
ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENvcHlyaWdodCAoYykgMjAx
NiBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZTwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdo
dHMgcmVzZXJ2ZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZG9jdW1l
bnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBC
Q1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0
aGUgSUVURiBUcnVzdCdzIExlZ2FsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g
ICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzPC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3Vt
ZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKGh0dHA6Ly90cnVzdGVl
LmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3Jn
L2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij4gICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxl
YXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij4gICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0
aGVzZSBkb2N1bWVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNhcmVm
dWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdp
dGggcmVzcGVjdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNhcmVmdWxs
eSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGgg
cmVzcGVjdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdG8gdGhpcyBkb2N1
bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11
c3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0byB0aGlzIGRvY3VtZW50
LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdDwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJT
RCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mPC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNl
bnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mPC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJl
IHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij4gICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVk
IHdpdGhvdXQgd2FycmFudHkgYXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg
IGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS48L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNE
IExpY2Vuc2UuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPlRh
YmxlIG9mIENvbnRlbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+VGFibGUg
b2YgQ29udGVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+
ICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gICAyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg
MS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gICAyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg
ICA8dHIgaWQ9ImRpZmYwMDA0Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDIuICBUZXJtaW5vbG9neSBh
bmQgQWJicmV2aWF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgPHNw
YW4gY2xhc3M9ImRlbGV0ZSI+Mzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi
bG9jayI+ICAgICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xLjEuICBBcHBsaWNhYmlsaXR5IC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzPC9zcGFuPjwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJibG9jayI+ICAgMi4gIFRlcm1pbm9sb2d5IGFuZCBBYmJyZXZpYXRpb25zIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij40PC9z
cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMy4gIENvbnZlbnRpb25z
IFVzZWQgaW4gVGhpcyBEb2N1bWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMy4gIENvbnZlbnRpb25zIFVz
ZWQgaW4gVGhpcyBEb2N1bWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0PC90
ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA1
Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsYmxvY2siPiAgIDQuICBQcm9ibGVtIFN0YXRlbWVudCAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+
NDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgNC4gIFByb2Js
ZW0gU3RhdGVtZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij41PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj
bGFzcz0ibGJsb2NrIj4gICA1LiAgVXNlIENhc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPjU8
L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDUuICBVc2UgQ2Fz
ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+Njwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxibG9jayI+ICAgICA1LjEuICBGaXJzdCBSZXNwb25kZXIgUmVsYXRlZCBTaWduYWxp
bmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj41PC9z
cGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDUuMS4gIEZpcnN0
IFJlc3BvbmRlciBSZWxhdGVkIFNpZ25hbGluZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg
IDxzcGFuIGNsYXNzPSJpbnNlcnQiPjY8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz
PSJsYmxvY2siPiAgICAgNS4yLiAgRW1lcmdlbmN5IENhbGwgUmVsYXRlZCBTaWduYWxpbmcg
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+NTwvc3Bh
bj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICA1LjIuICBFbWVyZ2Vu
Y3kgQ2FsbCBSZWxhdGVkIFNpZ25hbGluZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8
c3BhbiBjbGFzcz0iaW5zZXJ0Ij42PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i
bGVmdCI+ICAgICA1LjMuICBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo
dCI+ICAgICA1LjMuICBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gICA2PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHIgaWQ9ImRpZmYwMDA2Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgNS40LiAgQXBw
bGljYXRpb24gU3BlY2lmaWMgUHJpb3JpdGllcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Njwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJibG9jayI+ICAgICA1LjQuICBBcHBsaWNhdGlvbiBTcGVjaWZpYyBQcmlvcml0aWVz
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij43PC9z
cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA2LiAgVGhlb3J5IG9m
IE9wZXJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg
IDxzcGFuIGNsYXNzPSJkZWxldGUiPjc8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyYmxvY2siPiAgIDYuICBUaGVvcnkgb2YgT3BlcmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9Imluc2VydCI+ODwvc3Bh
bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgNy4gIEV4dGVuc2liaWxp
dHkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8
c3BhbiBjbGFzcz0iZGVsZXRlIj44PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmJsb2NrIj4gICA3LiAgRXh0ZW5zaWJpbGl0eSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjk8L3NwYW4+
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDguICBOb3JtYXRpdmUgQmVo
YXZpb3IgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgPHNw
YW4gY2xhc3M9ImRlbGV0ZSI+OTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi
bG9jayI+ICAgOC4gIE5vcm1hdGl2ZSBCZWhhdmlvciAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjEwPC9zcGFuPjwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA5LiAgQXR0cmlidXRlIFZhbHVl
IFBhaXJzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4g
Y2xhc3M9ImRlbGV0ZSI+MTE8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv
Y2siPiAgIDkuICBBdHRyaWJ1dGUgVmFsdWUgUGFpcnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xMjwvc3Bhbj48L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICA5LjEuICBEUk1QIEFWUCAgLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNs
YXNzPSJkZWxldGUiPjExPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr
Ij4gICAgIDkuMS4gIERSTVAgQVZQICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+MTI8L3NwYW4+PC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgOS4yLiAgQXR0cmlidXRlIFZhbHVl
IFBhaXIgZmxhZyBydWxlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFz
cz0iZGVsZXRlIj4xMjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+
ICAgICA5LjIuICBBdHRyaWJ1dGUgVmFsdWUgUGFpciBmbGFnIHJ1bGVzIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjEzPC9zcGFuPjwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAxMC4gSUFOQSBDb25zaWRlcmF0aW9ucyAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9
ImRlbGV0ZSI+MTI8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg
IDEwLiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5Db25zaWRlcmF0aW9ucyBXaGVuIERlZmluaW5n
IEFwcGxpY2F0aW9uIFByaW9yaXRpZXMgLiAuIC4gLiAuICAxMzwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAxMC4x
Ljwvc3Bhbj4gIEFWUCBjb2RlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xMjwvc3Bhbj48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgMTEuPC9z
cGFuPiBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xNDwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAxMC4y
Ljwvc3Bhbj4gIE5ldyByZWdpc3RyaWVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xMjwvc3Bhbj48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAxMS4x
Ljwvc3Bhbj4gIEFWUCBjb2RlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xNDwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgMTEuPC9z
cGFuPiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xMjwvc3Bhbj48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAxMS4y
Ljwvc3Bhbj4gIE5ldyByZWdpc3RyaWVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xNTwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAxMS4x
Ljwvc3Bhbj4gIFBvdGVudGlhbCBUaHJlYXQgTW9kZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xMzwvc3Bhbj48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgMTIuPC9z
cGFuPiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xNTwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAxMS4y
Ljwvc3Bhbj4gIERlbmlhbCBvZiBTZXJ2aWNlIEF0dGFja3MgIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xNDwvc3Bhbj48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAxMi4x
Ljwvc3Bhbj4gIFBvdGVudGlhbCBUaHJlYXQgTW9kZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xNTwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAxMS4z
Ljwvc3Bhbj4gIEVuZC10byBFbmQtU2VjdXJpdHkgSXNzdWVzIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xNDwvc3Bhbj48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAxMi4y
Ljwvc3Bhbj4gIERlbmlhbCBvZiBTZXJ2aWNlIEF0dGFja3MgIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xNjwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgMTIuPC9z
cGFuPiBDb250cmlidXRvcnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xNDwvc3Bhbj48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAxMi4z
Ljwvc3Bhbj4gIEVuZC10byBFbmQtU2VjdXJpdHkgSXNzdWVzIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xNjwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgMTMuPC9z
cGFuPiBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xNTwvc3Bhbj48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgMTMuPC9z
cGFuPiBDb250cmlidXRvcnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xNzwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAxMy4x
Ljwvc3Bhbj4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xNTwvc3Bhbj48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgMTQuPC9z
cGFuPiBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xNzwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAxMy4y
Ljwvc3Bhbj4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xNTwvc3Bhbj48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAxNC4x
Ljwvc3Bhbj4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xNzwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgQXV0aG9yJ3MgQWRkcmVzcyAgLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJk
ZWxldGUiPjE1PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh
biBjbGFzcz0iaW5zZXJ0Ij4gICAgIDE0LjIuPC9zcGFuPiAgSW5mb3JtYXRpdmUgUmVmZXJl
bmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJp
bnNlcnQiPjE3PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgQXV0aG9yJ3MgQWRkcmVzcyAgLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNs
YXNzPSJpbnNlcnQiPjE3PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij4xLiAgSW50cm9kdWN0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
aWdodCI+MS4gIEludHJvZHVjdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij4gICBUaGUgRGlhbWV0ZXIgT3ZlcmxvYWQgSW5kaWNhdGlvbiBDb252ZXlh
bmNlIChET0lDKSBzb2x1dGlvbiBbUkZDNzY4M108L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij4gICBUaGUgRGlhbWV0ZXIgT3ZlcmxvYWQgSW5kaWNhdGlvbiBDb252ZXlhbmNl
IChET0lDKSBzb2x1dGlvbiBbUkZDNzY4M108L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPiAgIGZvciBEaWFtZXRlciBvdmVybG9hZCBjb250cm9sIGludHJvZHVjZXMgc2NlbmFy
aW9zIHdoZXJlIERpYW1ldGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg
Zm9yIERpYW1ldGVyIG92ZXJsb2FkIGNvbnRyb2wgaW50cm9kdWNlcyBzY2VuYXJpb3Mgd2hl
cmUgRGlhbWV0ZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJvdXRpbmcg
ZGVjaXNpb25zIG1hZGUgYnkgRGlhbWV0ZXIgbm9kZXMgY2FuIGJlIGluZmx1ZW5jZWQgYnkg
dGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcm91dGluZyBkZWNpc2lv
bnMgbWFkZSBieSBEaWFtZXRlciBub2RlcyBjYW4gYmUgaW5mbHVlbmNlZCBieSB0aGU8L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG92ZXJsb2FkIHN0YXRlIG9mIG90aGVy
IERpYW1ldGVyIG5vZGVzLiAgVGhpcyBpbmNsdWRlcyB0aGUgc2NlbmFyaW9zPC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb3ZlcmxvYWQgc3RhdGUgb2Ygb3RoZXIgRGlh
bWV0ZXIgbm9kZXMuICBUaGlzIGluY2x1ZGVzIHRoZSBzY2VuYXJpb3M8L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHdoZXJlIERpYW1ldGVyIGVuZHBvaW50cyBhbmQgRGlh
bWV0ZXIgYWdlbnRzIGNhbiB0aHJvdHRsZSByZXF1ZXN0cyBhczwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmlnaHQiPiAgIHdoZXJlIERpYW1ldGVyIGVuZHBvaW50cyBhbmQgRGlhbWV0
ZXIgYWdlbnRzIGNhbiB0aHJvdHRsZSByZXF1ZXN0cyBhczwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj
bGFzcz0ibGVmdCI+ICAgYSByZXN1bHQgb2YgdGhlIHRhcmdldCBmb3IgdGhlIHJlcXVlc3Qg
YmVpbmcgb3ZlcmxvYWRlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBh
IHJlc3VsdCBvZiB0aGUgdGFyZ2V0IGZvciB0aGUgcmVxdWVzdCBiZWluZyBvdmVybG9hZGVk
LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv
dHI+CiAgICAgIDx0ciBpZD0icGFydC0zIiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+PHRo
PjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTMi
PjxlbT4gcGFnZSAzLCBsaW5lIDE2PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+
PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2Ug
YXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTMiPjxlbT4gcGFnZSAzLCBsaW5lIDE4PHNwYW4g
Y2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g
ICBpc3N1ZXMuICBGb3IgaW5zdGFuY2UsIGl0IG1pZ2h0IGJlIGNvbnNpZGVyZWQgaW1wb3J0
YW50IHRvIHJlZHVjZSB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBp
c3N1ZXMuICBGb3IgaW5zdGFuY2UsIGl0IG1pZ2h0IGJlIGNvbnNpZGVyZWQgaW1wb3J0YW50
IHRvIHJlZHVjZSB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHByb2Jh
YmlsaXR5IG9mIHRyYW5zYWN0aW9ucyBpbnZvbHZpbmcgZmlyc3QgcmVzcG9uZGVycyBiZWlu
ZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHByb2JhYmlsaXR5IG9mIHRy
YW5zYWN0aW9ucyBpbnZvbHZpbmcgZmlyc3QgcmVzcG9uZGVycyBiZWluZzwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhyb3R0bGVkIGR1cmluZyBvdmVybG9hZCBzY2Vu
YXJpb3MgY2F1c2VkLCBmb3IgZXhhbXBsZSwgYnkgYSBwZXJpb2Q8L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJpZ2h0Ij4gICB0aHJvdHRsZWQgZHVyaW5nIG92ZXJsb2FkIHNjZW5hcmlv
cyBjYXVzZWQsIGZvciBleGFtcGxlLCBieSBhIHBlcmlvZDwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj
bGFzcz0ibGVmdCI+ICAgb2YgaGVhdnkgc2lnbmFsaW5nIHJlc3VsdGluZyBmcm9tIGEgbmF0
dXJhbCBkaXNhc3Rlci48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvZiBo
ZWF2eSBzaWduYWxpbmcgcmVzdWx0aW5nIGZyb20gYSBuYXR1cmFsIGRpc2FzdGVyLjwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGRvY3VtZW50
IGRlZmluZXMgYSBtZWNoYW5pc20gdGhhdCBhbGxvd3MgRGlhbWV0ZXIgbm9kZXMgdG88L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IGRlZmluZXMg
YSBtZWNoYW5pc20gdGhhdCBhbGxvd3MgRGlhbWV0ZXIgbm9kZXMgdG88L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGluZGljYXRlIHRoZSByZWxhdGl2ZSBwcmlvcml0eSBv
ZiBEaWFtZXRlciB0cmFuc2FjdGlvbnMuICBXaXRoIHRoaXM8L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJpZ2h0Ij4gICBpbmRpY2F0ZSB0aGUgcmVsYXRpdmUgcHJpb3JpdHkgb2YgRGlh
bWV0ZXIgdHJhbnNhY3Rpb25zLiAgV2l0aCB0aGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz
PSJsZWZ0Ij4gICBpbmZvcm1hdGlvbiBvdGhlciBEaWFtZXRlciBub2RlcyBjYW4gZmFjdG9y
IHRoZSByZWxhdGl2ZSBwcmlvcml0eSBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPiAgIGluZm9ybWF0aW9uIG90aGVyIERpYW1ldGVyIG5vZGVzIGNhbiBmYWN0b3IgdGhl
IHJlbGF0aXZlIHByaW9yaXR5IG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g
ICByZXF1ZXN0cyBpbnRvIHJvdXRpbmcgYW5kIHRocm90dGxpbmcgZGVjaXNpb25zLjwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHJlcXVlc3RzIGludG8gcm91dGluZyBh
bmQgdGhyb3R0bGluZyBkZWNpc2lvbnMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0
Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDciPjx0ZD48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi
PjEuMS4gIEFwcGxpY2FiaWxpdHk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs
YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i
aW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg
ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBU
aGVyZSBhcmUgdHdvIHByaW1hcnkgY29uc2lkZXJhdGlvbnMgdGhhdCBtdXN0IGJlIGFkZHJl
c3NlZCBmb3IgdGhlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K
ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+
ICAgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IHRvIHdvcmsgZWZmZWN0
aXZlbHkuICBUaGUgZmlyc3Q8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv
Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z
ZXJ0Ij4gICB0YWtlcyBpbnRvIGNvbnNpZGVyYXRpb24gdGhhdCB0aGUgRGlhbWV0ZXIgYmFz
ZSBwcm90b2NvbCBkZWZpbmVkIGluPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i
bGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9
Imluc2VydCI+ICAgW1JGQzY3MzNdICBpcyBkZXNpZ25lZCB0byB0cmFuc3BvcnQgbXVsdGlw
bGUgRGlhbWV0ZXIgYXBwbGljYXRpb25zPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz
cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh
c3M9Imluc2VydCI+ICAgYW5kIHRoYXQgRGlhbWV0ZXIgbm9kZXMgY2FuIGJlIGltcGxlbWVu
dGVkIHRoYXQgc3VwcG9ydCBtdWx0aXBsZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs
YXNzPSJpbnNlcnQiPiAgIGFwcGxpY2F0aW9ucy4gIEluIG9yZGVyIGZvciB0aGUgRFJNUCBt
ZWNoYW5pc20gdG8gd29yaywgdGhlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i
bGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9
Imluc2VydCI+ICAgcHJpb3JpdGllcyBkZWZpbmVkIGZvciBhbGwgbWVzc2FnZXMgYWNyb3Nz
IGFsbCBhcHBsaWNhdGlvbnMgdXNlZCBpbiBhPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj
bGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4g
Y2xhc3M9Imluc2VydCI+ICAgRGlhbWV0ZXIgYWRtaW5pc3RyYXRpdmUgZG9tYWluIG11c3Qg
YmUgZGVmaW5lZCBpbiBhIGNvbnNpc3RlbnQgYW5kPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0
ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw
YW4gY2xhc3M9Imluc2VydCI+ICAgY29vcmRpbmF0ZWQgZmFzaGlvbi4gIFNlZSBTZWN0aW9u
IDEwIGZvciBhIGRpc2N1c3Npb24gb2Ygc29tZSBvZiB0aGU8L3NwYW4+PC90ZD48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr
Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBjb25zaWRlcmF0aW9ucyB0aGF0IG5lZWQgdG8g
YmUgZmFjdG9yZWQgaW50byB0aGUgc2V0dGluZyBvZiBEUk1QPC9zcGFuPjwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j
ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgcHJpb3JpdGllcyB1c2VkIGJ5IERpYW1ldGVy
IGFwcGxpY2F0aW9ucy48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si
PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0
Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBOb3Rl
IHRoYXQgdGhpcyBjb25zaWRlcmF0aW9uIGRvZXMgbm90IGFwcGx5IHRvIERpYW1ldGVyIG5l
dHdvcmtzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg
PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0
ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAg
d2hlcmUgYWxsIERpYW1ldGVyIG5vZGVzIG9ubHkgc3VwcG9ydCBhIHNpbmdsZSBhcHBsaWNh
dGlvbi48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBXaXRob3V0IHRoaXMgY3Jv
c3MgYXBwbGljYXRpb24gcHJpb3JpdHkgZGVzaWduIHRha2VuIGludG88L3NwYW4+PC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBjb25zaWRlcmF0aW9uIGl0IGlzIHBv
c3NpYmxlIGZvciBtZXNzYWdlcyBmb3Igb25lIGFwcGxpY2F0aW9uIHRvIGdhaW48L3NwYW4+
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB1bndhcnJhbnRlZCBwcmVm
ZXJlbnRpYWwgdHJlYXRtZW50IG92ZXIgbWVzc2FnZXMgZm9yIG90aGVyPC9zcGFuPjwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgYXBwbGljYXRpb25zLjwvc3Bhbj48
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si
PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFRoaXMgbWVjaGFuaXNtIGFsc28gZGVwZW5kcyBv
biBhbGwgb2YgdGhlIG1lc3NhZ2VzIHRoYXQgY2FycnkgdGhlPC9zcGFuPjwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j
ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgRFJNUCBBVlAgYXJlIGluc2VydGVkIGludG8g
RGlhbWV0ZXIgbWVzc2FnZXMgYnkgdHJ1c3RlZCBub2RlcyB3aXRoaW48L3NwYW4+PC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB0aGUgRGlhbWV0ZXIgYWRtaW5pc3Ry
YXRpdmUgZG9tYWluLiAgQXMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gMTIsPC9zcGFuPjwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgbWlzYmVoYXZpbmcgbm9kZXMgaGF2
ZSB0aGUgYWJpbGl0eSB0byB1c2UgdGhlIERSTVAgbWVjaGFuaXNtIHRvIGdhaW48L3NwYW4+
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB1bndhcnJhbnRlZCBwcmVm
ZXJlbnRpYWwgdHJlYXRtZW50Ljwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi
bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp
bnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFdo
ZW4gbWVzc2FnZXMgY3Jvc3MgRGlhbWV0ZXIgYWRtaW5pc3RyYXRpdmUgYm91bmRhcmllcywg
Y2FyZSBzaG91bGQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g
ICBiZSB0YWtlbiB0byBlaXRoZXIgc3RyaXAgb3IgbW9kaWZ5IHRoZSBEUk1QIHByaW9yaXR5
IHZhbHVlcyBpbiB0aGVzZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j
ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl
cnQiPiAgIG1lc3NhZ2VzLiAgSWYgdGhlIHByaW9yaXR5IGRlZmluaXRpb25zIHZhcnkgYmV0
d2VlbiB0aGUgdHdvIERpYW1ldGVyPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i
bGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9
Imluc2VydCI+ICAgYWRtaW5pc3RyYXRpdmUgZG9tYWlucyB0aGVuIGl0IGlzIHBvc3NpYmxl
IGZvciBtZXNzYWdlcyBmcm9tIGE8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs
YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i
aW5zZXJ0Ij4gICBmb3JlaWduIGRvbWFpbiB0byBnYWluIHVud2FycmFudGVkIHByZWZlcmVu
dGlhbCB0cmVhdG1lbnQuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr
Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Mi4gIFRlcm1pbm9sb2d5IGFuZCBB
YmJyZXZpYXRpb25zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Mi4gIFRlcm1p
bm9sb2d5IGFuZCBBYmJyZXZpYXRpb25zPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0
Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxlZnQiPiAgIERpdmVyc2lvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPiAgIERpdmVyc2lvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs
ZWZ0Ij4gICAgICBBcyBkZWZpbmVkIGluIFtSRkM3NjgzXS4gIEFuIG92ZXJsb2FkIGFiYXRl
bWVudCB0cmVhdG1lbnQgd2hlcmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g
ICAgICBBcyBkZWZpbmVkIGluIFtSRkM3NjgzXS4gIEFuIG92ZXJsb2FkIGFiYXRlbWVudCB0
cmVhdG1lbnQgd2hlcmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHRo
ZSByZWFjdGluZyBub2RlIHNlbGVjdHMgYWx0ZXJuYXRlIGRlc3RpbmF0aW9ucyBvciBwYXRo
cyBmb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICB0aGUgcmVhY3Rp
bmcgbm9kZSBzZWxlY3RzIGFsdGVybmF0ZSBkZXN0aW5hdGlvbnMgb3IgcGF0aHMgZm9yPC90
ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICByZXF1ZXN0cy48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICByZXF1ZXN0cy48L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRE9JQzwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmlnaHQiPiAgIERPSUM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz
cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9InBhcnQtNCIgY2xhc3M9ImNo
YW5nZSIgPjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFs
bD48YSBocmVmPSIjcGFydC00Ij48ZW0+IHBhZ2UgNCwgbGluZSA0NzxzcGFuIGNsYXNzPSJo
aWRlIj4gJnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+
c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC00Ij48ZW0+IHBh
Z2UgNSwgbGluZSAzODxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwvZW0+PC9h
PjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgV2hpbGUgdGhlIHByaW1hcnkgdXNhZ2Ugb2YgRFJNUCBk
ZWZpbmVkIHByaW9yaXRpZXMgaXMgZm9yIGlucHV0IHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyaWdodCI+ICAgV2hpbGUgdGhlIHByaW1hcnkgdXNhZ2Ugb2YgRFJNUCBkZWZpbmVk
IHByaW9yaXRpZXMgaXMgZm9yIGlucHV0IHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs
ZWZ0Ij4gICBEaWFtZXRlciBvdmVybG9hZCBjb250cm9sIHJlbGF0ZWQgdGhyb3R0bGluZyBk
ZWNpc2lvbnMsIGl0IGlzIGFsc288L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g
ICBEaWFtZXRlciBvdmVybG9hZCBjb250cm9sIHJlbGF0ZWQgdGhyb3R0bGluZyBkZWNpc2lv
bnMsIGl0IGlzIGFsc288L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGV4cGVj
dGVkIHRoYXQgdGhlIHByaW9yaXR5IGluZm9ybWF0aW9uIGNvdWxkIGFsc28gYmUgdXNlZCBm
b3Igb3RoZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBleHBlY3RlZCB0
aGF0IHRoZSBwcmlvcml0eSBpbmZvcm1hdGlvbiBjb3VsZCBhbHNvIGJlIHVzZWQgZm9yIG90
aGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByb3V0aW5nIHJlbGF0ZWQg
ZnVuY3Rpb25hbGl0eS4gIFRoaXMgbWlnaHQgaW5jbHVkZSBnaXZpbmcgaGlnaGVyPC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcm91dGluZyByZWxhdGVkIGZ1bmN0aW9u
YWxpdHkuICBUaGlzIG1pZ2h0IGluY2x1ZGUgZ2l2aW5nIGhpZ2hlcjwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHJpb3JpdHkgdHJhbnNhY3Rpb25zIHByZWZlcmVudGlh
bCB0cmVhdG1lbnQgd2hlbiBzZWxlY3Rpbmcgcm91dGVzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmlnaHQiPiAgIHByaW9yaXR5IHRyYW5zYWN0aW9ucyBwcmVmZXJlbnRpYWwgdHJl
YXRtZW50IHdoZW4gc2VsZWN0aW5nIHJvdXRlcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9
ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgSXQgaXMgYWxzbyBlbnZpc2lvbmVkIHRoYXQgRFJNUCBw
cmlvcml0eSBpbmZvcm1hdGlvbiBjb3VsZCBiZSB1c2VkIGJ5PC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+ICAgSXQgaXMgYWxzbyBlbnZpc2lvbmVkIHRoYXQgRFJNUCBwcmlv
cml0eSBpbmZvcm1hdGlvbiBjb3VsZCBiZSB1c2VkIGJ5PC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij4gICBEaWFtZXRlciBlbmRwb2ludHMgdG8gbWFrZSByZXNvdXJjZSBhbGxv
Y2F0aW9uIGRlY2lzaW9ucy4gIEZvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PiAgIERpYW1ldGVyIGVuZHBvaW50cyB0byBtYWtlIHJlc291cmNlIGFsbG9jYXRpb24gZGVj
aXNpb25zLiAgRm9yPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbnN0YW5j
ZSwgYSBEaWFtZXRlciBTZXJ2ZXIgbWlnaHQgY2hvb3NlIHRvIHVzZSB0aGUgcHJpb3JpdHk8
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbnN0YW5jZSwgYSBEaWFtZXRl
ciBTZXJ2ZXIgbWlnaHQgY2hvb3NlIHRvIHVzZSB0aGUgcHJpb3JpdHk8L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGluZm9ybWF0aW9uIHRvIHRyZWF0IGhpZ2hlciBwcmlv
cml0eSByZXF1ZXN0cyBhaGVhZCBvZiBsb3dlciBwcmlvcml0eTwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmlnaHQiPiAgIGluZm9ybWF0aW9uIHRvIHRyZWF0IGhpZ2hlciBwcmlvcml0
eSByZXF1ZXN0cyBhaGVhZCBvZiBsb3dlciBwcmlvcml0eTwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwOCI+PHRkPjwvdGQ+PC90cj4K
ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g
ICByZXF1ZXN0cy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgcmVxdWVz
dHMuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5JdCBtaWdodCBhbHNvIHVzZSB0aGUgcHJpb3Jp
dHkgaW5mb3JtYXRpb24gdG8gYXMgYSByZWFzb248L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh
biBjbGFzcz0iaW5zZXJ0Ij4gICB0byBmYWlsIGEgcmVxdWVzdCBhcyBhIHJlc3VsdCBvZiBp
bnN1ZmZpY2llbnQgcmVzb3VyY2VzLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9
ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgTm90ZTogVGhlcmUgYXJlIGEgbnVtYmVyIG9mIGFw
cGxpY2F0aW9uIHNwZWNpZmljIGRlZmluaXRpb25zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyaWdodCI+ICAgICAgTm90ZTogVGhlcmUgYXJlIGEgbnVtYmVyIG9mIGFwcGxpY2F0aW9u
IHNwZWNpZmljIGRlZmluaXRpb25zPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g
ICAgICBpbmRpY2F0aW5nIHZhcmlvdXMgdmlld3Mgb2YgYXBwbGljYXRpb24gbGV2ZWwgcHJp
b3JpdHkgZm9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgaW5kaWNh
dGluZyB2YXJpb3VzIHZpZXdzIG9mIGFwcGxpY2F0aW9uIGxldmVsIHByaW9yaXR5IGZvcjwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgZGlmZmVyZW50IHJlcXVlc3Rz
LiAgVXNpbmcgdGhlc2UgYXBwbGljYXRpb24gc3BlY2lmaWMgcHJpb3JpdHk8L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBkaWZmZXJlbnQgcmVxdWVzdHMuICBVc2lu
ZyB0aGVzZSBhcHBsaWNhdGlvbiBzcGVjaWZpYyBwcmlvcml0eTwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+ICAgICAgQXR0cmlidXRlIFZhbHVlIFBhaXJzIChBVlBzKSBhcyBp
bnB1dCB0byB0aHJvdHRsaW5nIGFuZCBvdGhlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPiAgICAgIEF0dHJpYnV0ZSBWYWx1ZSBQYWlycyAoQVZQcykgYXMgaW5wdXQgdG8g
dGhyb3R0bGluZyBhbmQgb3RoZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg
ICAgIERpYW1ldGVyIHJvdXRpbmcgZGVjaXNpb25zIHdvdWxkIHJlcXVpcmUgRGlhbWV0ZXIg
YWdlbnRzIHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgRGlhbWV0
ZXIgcm91dGluZyBkZWNpc2lvbnMgd291bGQgcmVxdWlyZSBEaWFtZXRlciBhZ2VudHMgdG88
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHVuZGVyc3RhbmQgYWxsIGFw
cGxpY2F0aW9ucyBhbmQgZG8gYXBwbGljYXRpb24gc3BlY2lmaWMgcGFyc2luZyBvZjwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIHVuZGVyc3RhbmQgYWxsIGFwcGxp
Y2F0aW9ucyBhbmQgZG8gYXBwbGljYXRpb24gc3BlY2lmaWMgcGFyc2luZyBvZjwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgYWxsIG1lc3NhZ2VzIGluIG9yZGVyIHRv
IGRldGVybWluZSB0aGUgcHJpb3JpdHkgb2YgaW5kaXZpZHVhbDwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmlnaHQiPiAgICAgIGFsbCBtZXNzYWdlcyBpbiBvcmRlciB0byBkZXRlcm1p
bmUgdGhlIHByaW9yaXR5IG9mIGluZGl2aWR1YWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9
ImxlZnQiPiAgICAgIG1lc3NhZ2VzLiAgVGhpcyBpcyBjb25zaWRlcmVkIGFuIHVuYWNjZXB0
YWJsZSBsZXZlbCBvZiBjb21wbGV4aXR5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo
dCI+ICAgICAgbWVzc2FnZXMuICBUaGlzIGlzIGNvbnNpZGVyZWQgYW4gdW5hY2NlcHRhYmxl
IGxldmVsIG9mIGNvbXBsZXhpdHk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg
ICAgIHRvIHB1dCBvbiBlbGVtZW50cyB3aG9zZSBwcmltYXJ5IHJlc3BvbnNpYmlsaXR5IGlz
IHRvIHJvdXRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgdG8gcHV0
IG9uIGVsZW1lbnRzIHdob3NlIHByaW1hcnkgcmVzcG9uc2liaWxpdHkgaXMgdG8gcm91dGU8
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIERpYW1ldGVyIG1lc3NhZ2Vz
LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIERpYW1ldGVyIG1lc3Nh
Z2VzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg
ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij41LiAgVXNl
IENhc2VzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NS4gIFVzZSBDYXNlczwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIHNlY3Rp
b24gZGlzY3Vzc2VzIHZhcmlvdXMgc2NlbmFyaW9zIHdoZXJlIERpYW1ldGVyIHRyYW5zYWN0
aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgc2VjdGlvbiBk
aXNjdXNzZXMgdmFyaW91cyBzY2VuYXJpb3Mgd2hlcmUgRGlhbWV0ZXIgdHJhbnNhY3Rpb25z
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjYW4gYmVuZWZpdCBmcm9tIHRo
ZSB1c2Ugb2YgcHJpb3JpdHkgaW5mb3JtYXRpb24uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyaWdodCI+ICAgY2FuIGJlbmVmaXQgZnJvbSB0aGUgdXNlIG9mIHByaW9yaXR5IGluZm9y
bWF0aW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHIgaWQ9ImRpZmYwMDA5Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5JdCBpcyBpbXBvcnRh
bnQgdG8gbm90ZSB0aGF0IGZvciBwcmlvcml0eSBpbmZvcm1hdGlvbiB0byBiZSByZWxpYWJs
eTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHVzYWJsZSwg
dGhlIERpYW1ldGVyIG5vZGVzIHNlbmRpbmcgYW5kIGNvbnN1bWluZyBEUk1QIEFWUHMgbXVz
dCBoYXZlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg
PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0
ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgcHJl
LWVzdGFibGlzaGVkIHRydXN0IHJlbGF0aW9uc2hpcHMgb2YgdGhlIHNvcnQgZGVzY3JpYmVk
IGluPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgU2VjdGlv
biAxMi48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij41LjEuICBGaXJzdCBSZXNwb25kZXIgUmVsYXRlZCBT
aWduYWxpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij41LjEuICBGaXJzdCBS
ZXNwb25kZXIgUmVsYXRlZCBTaWduYWxpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+ICAgTmF0dXJhbCBkaXNhc3RlcnMgY2FuIHJlc3VsdCBpbiBhIGNv
bnNpZGVyYWJsZSBpbmNyZWFzZSBpbiB1c2FnZSBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPiAgIE5hdHVyYWwgZGlzYXN0ZXJzIGNhbiByZXN1bHQgaW4gYSBjb25zaWRl
cmFibGUgaW5jcmVhc2UgaW4gdXNhZ2Ugb2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPiAgIG5ldHdvcmsgcmVzb3VyY2VzLiAgVGhpcyBjYW4gYmUgbWFkZSB3b3JzZSBpZiB0
aGUgZGlzYXN0ZXIgcmVzdWx0cyBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PiAgIG5ldHdvcmsgcmVzb3VyY2VzLiAgVGhpcyBjYW4gYmUgbWFkZSB3b3JzZSBpZiB0aGUg
ZGlzYXN0ZXIgcmVzdWx0cyBpbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K
ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg
YSBsb3NzIG9mIG5ldHdvcmsgY2FwYWNpdHkuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
aWdodCI+ICAgYSBsb3NzIG9mIG5ldHdvcmsgY2FwYWNpdHkuPC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBjb21iaW5hdGlvbiBvZiBhZGRlZCBs
b2FkIGFuZCByZWR1Y2VkIGNhcGFjaXR5IGNhbiBsZWFkIHRvPC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+ICAgVGhlIGNvbWJpbmF0aW9uIG9mIGFkZGVkIGxvYWQgYW5kIHJl
ZHVjZWQgY2FwYWNpdHkgY2FuIGxlYWQgdG88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPiAgIERpYW1ldGVyIG5vZGVzIGJlY29taW5nIG92ZXJsb2FkZWQgYW5kLCBhcyBhIHJl
c3VsdCwgdGhlIHVzZSBvZiBET0lDPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+
ICAgRGlhbWV0ZXIgbm9kZXMgYmVjb21pbmcgb3ZlcmxvYWRlZCBhbmQsIGFzIGEgcmVzdWx0
LCB0aGUgdXNlIG9mIERPSUM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1l
Y2hhbmlzbXMgdG8gcmVxdWVzdCBhIHJlZHVjdGlvbiBpbiB0cmFmZmljLiAgVGhpcyBpbiB0
dXJuIHJlc3VsdHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBtZWNoYW5p
c21zIHRvIHJlcXVlc3QgYSByZWR1Y3Rpb24gaW4gdHJhZmZpYy4gIFRoaXMgaW4gdHVybiBy
ZXN1bHRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbiByZXF1ZXN0cyBi
ZWluZyB0aHJvdHRsZWQgaW4gYW4gYXR0ZW1wdCB0byBjb250cm9sIHRoZSBvdmVybG9hZDwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGluIHJlcXVlc3RzIGJlaW5nIHRo
cm90dGxlZCBpbiBhbiBhdHRlbXB0IHRvIGNvbnRyb2wgdGhlIG92ZXJsb2FkPC90ZD48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0icGFy
dC01IiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBj
aGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTUiPjxlbT4gcGFnZSA2LCBsaW5lIDM2
PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwv
dGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNw
YXJ0LTUiPjxlbT4gcGFnZSA3LCBsaW5lIDMxPHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8
L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGFuIHRob3NlIHRoYXQgb2Nj
dXIgZWFybHkgaW4gdGhlIHNlcmllcy4gIFRoaXMgd291bGQgcmVjb2duaXplIHRoYXQ8L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGFuIHRob3NlIHRoYXQgb2NjdXIg
ZWFybHkgaW4gdGhlIHNlcmllcy4gIFRoaXMgd291bGQgcmVjb2duaXplIHRoYXQ8L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZXJlIHdhcyBwb3RlbnRpYWxseSBzaWdu
aWZpY2FudCB3b3JrIGRvbmUgYnkgdGhlIG5ldHdvcmsgYWxyZWFkeTwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZXJlIHdhcyBwb3RlbnRpYWxseSBzaWduaWZpY2Fu
dCB3b3JrIGRvbmUgYnkgdGhlIG5ldHdvcmsgYWxyZWFkeTwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj
bGFzcz0ibGVmdCI+ICAgdGhhdCB3b3VsZCBiZSBsb3N0IGlmIHRob3NlIGxhdGVyIHRyYW5z
YWN0aW9ucyB3ZXJlIHRocm90dGxlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij4gICB0aGF0IHdvdWxkIGJlIGxvc3QgaWYgdGhvc2UgbGF0ZXIgdHJhbnNhY3Rpb25zIHdl
cmUgdGhyb3R0bGVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg
PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0
Ij4gICBUaGVyZSBhcmUgYWxzbyBzY2VuYXJpb3Mgd2hlcmUgYW4gYWdlbnQgY2Fubm90IGVh
c2lseSBkaWZmZXJlbnRpYXRlIGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g
ICBUaGVyZSBhcmUgYWxzbyBzY2VuYXJpb3Mgd2hlcmUgYW4gYWdlbnQgY2Fubm90IGVhc2ls
eSBkaWZmZXJlbnRpYXRlIGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJl
cXVlc3QgdGhhdCBzdGFydHMgYSBzZXNzaW9uIGZyb20gcmVxdWVzdHMgdGhhdCB1cGRhdGUg
b3IgZW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVxdWVzdCB0aGF0
IHN0YXJ0cyBhIHNlc3Npb24gZnJvbSByZXF1ZXN0cyB0aGF0IHVwZGF0ZSBvciBlbmQ8L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNlc3Npb25zLiAgSW4gdGhlc2Ugc2Nl
bmFyaW9zIGl0IG1pZ2h0IGJlIGFwcHJvcHJpYXRlIHRvIG1hcmsgdGhlPC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc2Vzc2lvbnMuICBJbiB0aGVzZSBzY2VuYXJpb3Mg
aXQgbWlnaHQgYmUgYXBwcm9wcmlhdGUgdG8gbWFyayB0aGU8L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxlZnQiPiAgIHJlcXVlc3RzIHRoYXQgZXN0YWJsaXNoIG5ldyBzZXNzaW9ucyB3
aXRoIGEgbG93ZXIgcHJpb3JpdHkgdGhhbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPiAgIHJlcXVlc3RzIHRoYXQgZXN0YWJsaXNoIG5ldyBzZXNzaW9ucyB3aXRoIGEgbG93
ZXIgcHJpb3JpdHkgdGhhbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdXBk
YXRlcyBhbmQgc2Vzc2lvbiBlbmRpbmcgcmVxdWVzdHMuICBUaGlzIGFsc28gcmVjb2duaXpl
cyB0aGF0IG1vcmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB1cGRhdGVz
IGFuZCBzZXNzaW9uIGVuZGluZyByZXF1ZXN0cy4gIFRoaXMgYWxzbyByZWNvZ25pemVzIHRo
YXQgbW9yZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgd29yayBoYXMgYWxy
ZWFkeSB0YWtlbiBwbGFjZSBmb3IgZXN0YWJsaXNoZWQgc2Vzc2lvbnMgYW5kLCBhcyBhPC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgd29yayBoYXMgYWxyZWFkeSB0YWtl
biBwbGFjZSBmb3IgZXN0YWJsaXNoZWQgc2Vzc2lvbnMgYW5kLCBhcyBhPC90ZD48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDEwIj48dGQ+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs
YmxvY2siPiAgIHJlc3VsdCwgaXQgbWlnaHQgYmUgbW9yZSBoYXJtZnVsIGlmIHRoZSBzZXNz
aW9uIHVwZGF0ZSBhbmQgc2Vzc2lvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr
Ij4gICByZXN1bHQsIGl0IG1pZ2h0IGJlIG1vcmUgaGFybWZ1bCA8c3BhbiBjbGFzcz0iaW5z
ZXJ0Ij5mcm9tIGEgc2lnbmFsaW5nIHBvaW50IG9mIHZpZXc8L3NwYW4+IGlmPC90ZD48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGVuZGluZyByZXF1ZXN0cyB3ZXJlIHRvIGJl
IHRocm90dGxlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgdGhlIHNl
c3Npb24gdXBkYXRlIGFuZCBzZXNzaW9uIGVuZGluZyByZXF1ZXN0cyB3ZXJlIHRvIGJlIHRo
cm90dGxlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K
ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg
VGhlcmUgYXJlIGFsc28gc2NlbmFyaW9zIHdoZXJlIHRoZSBwcmlvcml0eSBvZiByZXF1ZXN0
cyBmb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGVyZSBhcmUgYWxz
byBzY2VuYXJpb3Mgd2hlcmUgdGhlIHByaW9yaXR5IG9mIHJlcXVlc3RzIGZvcjwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW5kaXZpZHVhbCBjb21tYW5kIGNvZGVzIHdp
dGhpbiBhbiBhcHBsaWNhdGlvbiBkZXBlbmRzIG9uIHRoZSBjb250ZXh0PC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaW5kaXZpZHVhbCBjb21tYW5kIGNvZGVzIHdpdGhp
biBhbiBhcHBsaWNhdGlvbiBkZXBlbmRzIG9uIHRoZSBjb250ZXh0PC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGF0IGV4aXN0cyB3aGVuIHRoZSByZXF1ZXN0IGlzIHNl
bnQuICBUaGVyZSBpc24ndCBhbHdheXMgaW5mb3JtYXRpb248L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJpZ2h0Ij4gICB0aGF0IGV4aXN0cyB3aGVuIHRoZSByZXF1ZXN0IGlzIHNlbnQu
ICBUaGVyZSBpc24ndCBhbHdheXMgaW5mb3JtYXRpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPiAgIGluIHRoZSBtZXNzYWdlIGZyb20gd2hpY2ggdGhpcyBjb250ZXh0IGNh
biBiZSBkZXRlcm1pbmVkIGJ5IERpYW1ldGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
aWdodCI+ICAgaW4gdGhlIG1lc3NhZ2UgZnJvbSB3aGljaCB0aGlzIGNvbnRleHQgY2FuIGJl
IGRldGVybWluZWQgYnkgRGlhbWV0ZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi
PiAgIG5vZGVzIG90aGVyIHRoYW4gdGhlIG5vZGUgdGhhdCBvcmlnaW5hdGVzIHRoZSByZXF1
ZXN0LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG5vZGVzIG90aGVyIHRo
YW4gdGhlIG5vZGUgdGhhdCBvcmlnaW5hdGVzIHRoZSByZXF1ZXN0LjwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90
ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGlzIHNpbWlsYXIgdG8gdGhl
IHNjZW5hcmlvIHdoZXJlIGEgc2VyaWVzIG9mIHJlcXVlc3RzIGFyZSBuZWVkZWQ8L3RkPjx0
ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGlzIHNpbWlsYXIgdG8gdGhlIHNj
ZW5hcmlvIHdoZXJlIGEgc2VyaWVzIG9mIHJlcXVlc3RzIGFyZSBuZWVkZWQ8L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRvIGFjY2VzcyBhIG5ldHdvcmsgc2VydmljZS4g
IEl0IGlzIGRpZmZlcmVudCBpbiB0aGF0IHRoZSBzZXJpZXMgb2Y8L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJpZ2h0Ij4gICB0byBhY2Nlc3MgYSBuZXR3b3JrIHNlcnZpY2UuICBJdCBp
cyBkaWZmZXJlbnQgaW4gdGhhdCB0aGUgc2VyaWVzIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij4gICByZXF1ZXN0cyBpbnZvbHZlIGRpZmZlcmVudCBhcHBsaWNhdGlvbiBj
b21tYW5kIGNvZGVzLiAgSW4gdGhpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PiAgIHJlcXVlc3RzIGludm9sdmUgZGlmZmVyZW50IGFwcGxpY2F0aW9uIGNvbW1hbmQgY29k
ZXMuICBJbiB0aGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv
dHI+CiAgICAgIDx0ciBpZD0icGFydC02IiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+PHRo
PjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTYi
PjxlbT4gcGFnZSA3LCBsaW5lIDMzPHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+
PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2Ug
YXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTYiPjxlbT4gcGFnZSA4LCBsaW5lIDMwPHNwYW4g
Y2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g
ICAgICAgcmVxdWVzdCBzZW5kZXIgYWxzbyBzYXZlcyB0aGUgcHJpb3JpdHkgaW5mb3JtYXRp
b24gd2l0aCB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgcmVx
dWVzdCBzZW5kZXIgYWxzbyBzYXZlcyB0aGUgcHJpb3JpdHkgaW5mb3JtYXRpb24gd2l0aCB0
aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICB0cmFuc2FjdGlvbiBz
dGF0ZS4gIFRoaXMgd2lsbCBiZSB1c2VkIHdoZW4gaGFuZGxpbmcgdGhlIGFuc3dlcjwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICB0cmFuc2FjdGlvbiBzdGF0ZS4g
IFRoaXMgd2lsbCBiZSB1c2VkIHdoZW4gaGFuZGxpbmcgdGhlIGFuc3dlcjwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIG1lc3NhZ2VzLjwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmlnaHQiPiAgICAgICBtZXNzYWdlcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMi4gIEFnZW50cyBoYW5kbGluZyB0aGUgcmVxdWVz
dCAtIEFnZW50cyB1c2UgdGhlIHByaW9yaXR5IGluZm9ybWF0aW9uPC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+ICAgMi4gIEFnZW50cyBoYW5kbGluZyB0aGUgcmVxdWVzdCAt
IEFnZW50cyB1c2UgdGhlIHByaW9yaXR5IGluZm9ybWF0aW9uPC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij4gICAgICAgd2hlbiBtYWtpbmcgcm91dGluZyBkZWNpc2lvbnMuICBU
aGlzIGNhbiBpbmNsdWRlIGRldGVybWluaW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
aWdodCI+ICAgICAgIHdoZW4gbWFraW5nIHJvdXRpbmcgZGVjaXNpb25zLiAgVGhpcyBjYW4g
aW5jbHVkZSBkZXRlcm1pbmluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K
ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg
ICAgIHdoaWNoIHJlcXVlc3RzIHRvIHJvdXRlIGZpcnN0LCB3aGljaCByZXF1ZXN0cyB0byB0
aHJvdHRsZSBhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgd2hp
Y2ggcmVxdWVzdHMgdG8gcm91dGUgZmlyc3QsIHdoaWNoIHJlcXVlc3RzIHRvIHRocm90dGxl
IGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIHdoZXJlIHRoZSBy
ZXF1ZXN0IGlzIHJvdXRlZC4gIEZvciBpbnN0YW5jZSwgcmVxdWVzdHMgd2l0aCBoaWdoZXI8
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgd2hlcmUgdGhlIHJlcXVl
c3QgaXMgcm91dGVkLiAgRm9yIGluc3RhbmNlLCByZXF1ZXN0cyB3aXRoIGhpZ2hlcjwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIHByaW9yaXR5IG1pZ2h0IGhhdmUg
YSBsb3dlciBwcm9iYWJpbGl0eSBvZiBiZWluZyB0aHJvdHRsZWQuICBUaGU8L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgcHJpb3JpdHkgbWlnaHQgaGF2ZSBhIGxv
d2VyIHByb2JhYmlsaXR5IG9mIGJlaW5nIHRocm90dGxlZC4gIFRoZTwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIG1lY2hhbmlzbSBmb3IgaG93IHRoZSBhZ2VudCBk
ZXRlcm1pbmVzIHdoaWNoIHJlcXVlc3RzIGFyZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPiAgICAgICBtZWNoYW5pc20gZm9yIGhvdyB0aGUgYWdlbnQgZGV0ZXJtaW5lcyB3
aGljaCByZXF1ZXN0cyBhcmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0ciBpZD0iZGlmZjAwMTEiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgIHRocm90dGxlZCBp
cyBpbXBsZW1lbnRhdGlvbiBkZXBlbmRlbnQgYW5kIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9m
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICA8c3BhbiBjbGFzcz0i
aW5zZXJ0Ij5jYW5kaWRhdGVzIHRvIGJlPC9zcGFuPiB0aHJvdHRsZWQgaXMgaW1wbGVtZW50
YXRpb24gZGVwZW5kZW50IGFuZCBpczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr
Ij4gICAgICAgdGhpcyBkb2N1bWVudC4gIEJlZm9yZSBmb3J3YXJkaW5nIHJlcXVlc3QgbWVz
c2FnZXMsIGFnZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAg
b3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gIEJlZm9yZSBmb3J3YXJkaW5n
IHJlcXVlc3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgIGdlbmVy
YWxseSBkbyBub3QgbW9kaWZ5IHRoZSBwcmlvcml0eSBpbmZvcm1hdGlvbiBwcmVzZW50IGlu
IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgbWVzc2FnZXMs
IGFnZW50cyBnZW5lcmFsbHkgZG8gbm90IG1vZGlmeSB0aGUgcHJpb3JpdHkgaW5mb3JtYXRp
b248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgIHJlY2VpdmVkIHJl
cXVlc3QgbWVzc2FnZSBub3IgaW5jbHVkZSB0aGUgcHJpb3JpdHkgaW5mb3JtYXRpb248L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgIHByZXNlbnQgaW4gdGhlIHJl
Y2VpdmVkIHJlcXVlc3QgbWVzc2FnZSBub3IgaW5jbHVkZSB0aGUgcHJpb3JpdHk8L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgIHdoZW4gYWJzZW50IGluIHRoZSBy
ZWNlaXZlZCByZXF1ZXN0IG1lc3NhZ2UuICBIb3dldmVyLCBpbiBzb21lPC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICBpbmZvcm1hdGlvbiB3aGVuIGFic2VudCBp
biB0aGUgcmVjZWl2ZWQgcmVxdWVzdCBtZXNzYWdlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz
cz0ibGJsb2NrIj4gICAgICAgc2NlbmFyaW9zLCBhZ2VudHMgY2FuIG1vZGlmeSB0aGUgcHJp
b3JpdHkgaW5mb3JtYXRpb24sIGZvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr
Ij4gICAgICAgSG93ZXZlciwgaW4gc29tZSBzY2VuYXJpb3MsIGFnZW50cyBjYW4gbW9kaWZ5
IHRoZSBwcmlvcml0eTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg
PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAg
ZXhhbXBsZSwgZWRnZSBhZ2VudHMgbW9kaWZ5aW5nIHRoZSBwcmlvcml0eSB2YWx1ZXMgc2V0
IGJ5IGFuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICBpbmZvcm1h
dGlvbiwgZm9yIGV4YW1wbGUsIGVkZ2UgYWdlbnRzIG1vZGlmeWluZyB0aGUgcHJpb3JpdHk8
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgIGFkamFjZW50IG9wZXJh
dG9yLiAgVGhlcmUgbWlnaHQgYmUgb3RoZXIgc2NlbmFyaW9zIHdoZXJlIGE8L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgIHZhbHVlcyBzZXQgYnkgYW4gYWRqYWNl
bnQgb3BlcmF0b3IuICBUaGVyZSBtaWdodCBiZSBvdGhlcjwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj
bGFzcz0ibGJsb2NrIj4gICAgICAgRGlhbWV0ZXIgZW5kcG9pbnQgZG9lcyBub3Qgc3VwcG9y
dCB0aGUgRFJNUCBtZWNoYW5pc20gYW5kIGFnZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmJsb2NrIj4gICAgICAgc2NlbmFyaW9zIHdoZXJlIGEgRGlhbWV0ZXIgZW5kcG9pbnQg
ZG9lcyBub3Qgc3VwcG9ydCB0aGUgRFJNUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs
b2NrIj4gICAgICAgaW5zZXJ0IHRoZSBwcmlvcml0eSBpbmZvcm1hdGlvbiBpbiB0aGUgcmVx
dWVzdCBtZXNzYWdlcyBmb3IgdGhhdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr
Ij4gICAgICAgbWVjaGFuaXNtIGFuZCBhZ2VudHMgaW5zZXJ0IHRoZSBwcmlvcml0eSBpbmZv
cm1hdGlvbiBpbiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAg
IG5vbiBzdXBwb3J0aW5nIGVuZHBvaW50LiAgV2hlbiBmb3J3YXJkaW5nIHRoZSByZXF1ZXN0
IG1lc3NhZ2VzLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgcmVx
dWVzdCBtZXNzYWdlcyBmb3IgdGhhdCBub24gc3VwcG9ydGluZyBlbmRwb2ludC4gIFdoZW48
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgIHRoZSBhZ2VudCBhbHNv
IHNhdmVzIHRoZSB0cmFuc2FjdGlvbiBwcmlvcml0eSBpbiB0aGUgdHJhbnNhY3Rpb248L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgIGZvcndhcmRpbmcgdGhlIHJl
cXVlc3QgbWVzc2FnZXMsIHRoZSBhZ2VudCBhbHNvIHNhdmVzIHRoZTwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgc3RhdGUsIGVpdGhlciBhcyBsb2NhbGx5IG1h
bmFnZWQgc3RhdGUgb3IgdXNpbmcgdGhlIFByb3h5LUluZm88L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJibG9jayI+ICAgICAgIHRyYW5zYWN0aW9uIHByaW9yaXR5IGluIHRoZSB0cmFu
c2FjdGlvbiBzdGF0ZSwgZWl0aGVyIGFzIGxvY2FsbHk8L3RkPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxibG9jayI+ICAgICAgIG1lY2hhbmlzbSBkZWZpbmVkIGluIFtSRkM2NzMzXS4gIFRo
aXMgd2lsbCBiZSB1c2VkIHdoZW4gaGFuZGxpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJibG9jayI+ICAgICAgIG1hbmFnZWQgc3RhdGUgb3IgdXNpbmcgdGhlIFByb3h5LUluZm8g
bWVjaGFuaXNtIGRlZmluZWQgaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+
ICAgICAgIHRoZSBhc3NvY2lhdGVkIGFuc3dlciBtZXNzYWdlIGZvciB0aGUgdHJhbnNhY3Rp
b24uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICBbUkZDNjczM10u
ICBUaGlzIHdpbGwgYmUgdXNlZCB3aGVuIGhhbmRsaW5nIHRoZSBhc3NvY2lhdGVkIGFuc3dl
cjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJibG9jayI+ICAgICAgIG1lc3NhZ2UgZm9yIHRoZSB0cmFuc2FjdGlvbi48L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMy4gIFJlcXVlc3Qg
aGFuZGxlciAtIFRoZSBoYW5kbGVyIG9mIHRoZSByZXF1ZXN0LCBiZSBpdCBhIERpYW1ldGVy
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMy4gIFJlcXVlc3QgaGFuZGxl
ciAtIFRoZSBoYW5kbGVyIG9mIHRoZSByZXF1ZXN0LCBiZSBpdCBhIERpYW1ldGVyPC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgU2VydmVyIG9yIGEgRGlhbWV0ZXIg
Q2xpZW50LCBjYW4gdXNlIHRoZSBwcmlvcml0eSBpbmZvcm1hdGlvbiB0bzwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICBTZXJ2ZXIgb3IgYSBEaWFtZXRlciBDbGll
bnQsIGNhbiB1c2UgdGhlIHByaW9yaXR5IGluZm9ybWF0aW9uIHRvPC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgZGV0ZXJtaW5lIGhvdyB0byBoYW5kbGUgdGhlIHJl
cXVlc3QuICBUaGlzIGNvdWxkIGluY2x1ZGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij4gICAgICAgZGV0ZXJtaW5lIGhvdyB0byBoYW5kbGUgdGhlIHJlcXVlc3QuICBUaGlz
IGNvdWxkIGluY2x1ZGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICBk
ZXRlcm1pbmluZyB0aGUgb3JkZXIgaW4gd2hpY2ggcmVxdWVzdHMgYXJlIGhhbmRsZWQgYW5k
IHJlc291cmNlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICBkZXRl
cm1pbmluZyB0aGUgb3JkZXIgaW4gd2hpY2ggcmVxdWVzdHMgYXJlIGhhbmRsZWQgYW5kIHJl
c291cmNlczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIHRoYXQgYXJl
IGFwcGxpZWQgdG8gaGFuZGxpbmcgb2YgdGhlIHJlcXVlc3QuPC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+ICAgICAgIHRoYXQgYXJlIGFwcGxpZWQgdG8gaGFuZGxpbmcgb2Yg
dGhlIHJlcXVlc3QuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi
PiAgIDQuICBBbnN3ZXIgc2VuZGVyIC0gVGhlIGhhbmRsZXIgb2YgdGhlIHJlcXVlc3QgaXMg
YWxzbyB0aGUgc2VuZGVyIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg
NC4gIEFuc3dlciBzZW5kZXIgLSBUaGUgaGFuZGxlciBvZiB0aGUgcmVxdWVzdCBpcyBhbHNv
IHRoZSBzZW5kZXIgb2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICB0
aGUgYW5zd2VyLiAgVGhlIGFuc3dlciBzZW5kZXIgdXNlcyB0aGUgcHJpb3JpdHkgaW5mb3Jt
YXRpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgdGhlIGFuc3dl
ci4gIFRoZSBhbnN3ZXIgc2VuZGVyIHVzZXMgdGhlIHByaW9yaXR5IGluZm9ybWF0aW9uPC90
ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgcmVjZWl2ZWQgaW4gdGhlIHJl
cXVlc3QgbWVzc2FnZSB3aGVuIHNlbmRpbmcgdGhlIGFuc3dlci4gIFRoaXM8L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgcmVjZWl2ZWQgaW4gdGhlIHJlcXVlc3Qg
bWVzc2FnZSB3aGVuIHNlbmRpbmcgdGhlIGFuc3dlci4gIFRoaXM8L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTciIGNs
YXNzPSJjaGFuZ2UiID48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBh
dDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtNyI+PGVtPiBwYWdlIDEwLCBsaW5lIDE1PHNwYW4g
Y2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRo
PjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTci
PjxlbT4gcGFnZSAxMSwgbGluZSAxNTxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFu
PjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRGlhbWV0ZXIgZW5kcG9pbnRzIE1BWSB1
c2Ugcm91dGluZyBwcmlvcml0eSBpbmZvcm1hdGlvbiBpbmNsdWRlZCBpbjwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERpYW1ldGVyIGVuZHBvaW50cyBNQVkgdXNlIHJv
dXRpbmcgcHJpb3JpdHkgaW5mb3JtYXRpb24gaW5jbHVkZWQgaW48L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSBEUk1QIEFWUCB3aGVuIG1ha2luZyByZXNvdXJjZSBh
bGxvY2F0aW9uIGRlY2lzaW9ucyBmb3IgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
aWdodCI+ICAgdGhlIERSTVAgQVZQIHdoZW4gbWFraW5nIHJlc291cmNlIGFsbG9jYXRpb24g
ZGVjaXNpb25zIGZvciB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRy
YW5zYWN0aW9uIGFzc29jaWF0ZWQgd2l0aCB0aGUgYW5zd2VyIG1lc3NhZ2VzIHVzaW5nIHRo
ZSBEUk1QPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdHJhbnNhY3Rpb24g
YXNzb2NpYXRlZCB3aXRoIHRoZSBhbnN3ZXIgbWVzc2FnZXMgdXNpbmcgdGhlIERSTVA8L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGluZm9ybWF0aW9uIGFzc29jaWF0ZWQg
d2l0aCB0aGUgdHJhbnNhY3Rpb24uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+
ICAgaW5mb3JtYXRpb24gYXNzb2NpYXRlZCB3aXRoIHRoZSB0cmFuc2FjdGlvbi48L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRGlhbWV0ZXIgZW5kcG9p
bnRzIE1BWSBpbmNsdWRlIHRoZSBEUk1QIEFWUCBpbiBhbnN3ZXIgbWVzc2FnZXMuICBUaGlz
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRGlhbWV0ZXIgZW5kcG9pbnRz
IE1BWSBpbmNsdWRlIHRoZSBEUk1QIEFWUCBpbiBhbnN3ZXIgbWVzc2FnZXMuICBUaGlzPC90
ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpcyBkb25lIHdoZW4gdGhlIHByaW9y
aXR5IGZvciB0aGUgYW5zd2VyIG1lc3NhZ2UgbmVlZHMgdG8gaGF2ZSBhPC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaXMgZG9uZSB3aGVuIHRoZSBwcmlvcml0eSBmb3Ig
dGhlIGFuc3dlciBtZXNzYWdlIG5lZWRzIHRvIGhhdmUgYTwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj
bGFzcz0ibGVmdCI+ICAgZGlmZmVyZW50IHByaW9yaXR5IHRoYW4gdGhlIHByaW9yaXR5IGNh
cnJpZWQgaW4gdGhlIHJlcXVlc3QgbWVzc2FnZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij4gICBkaWZmZXJlbnQgcHJpb3JpdHkgdGhhbiB0aGUgcHJpb3JpdHkgY2Fycmll
ZCBpbiB0aGUgcmVxdWVzdCBtZXNzYWdlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm
dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij4gICBXaGVuIGRldGVybWluaW5nIHRoZSBwcmlvcml0eSB0byBhcHBs
eSB0byBhbnN3ZXIgbWVzc2FnZXMsIERpYW1ldGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyaWdodCI+ICAgV2hlbiBkZXRlcm1pbmluZyB0aGUgcHJpb3JpdHkgdG8gYXBwbHkgdG8g
YW5zd2VyIG1lc3NhZ2VzLCBEaWFtZXRlcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxMiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBub2RlcyA8
c3BhbiBjbGFzcz0iZGVsZXRlIj5NVVNUPC9zcGFuPiB1c2UgdGhlIHByaW9yaXR5IGluZGlj
YXRlZCBpbiB0aGUgRFJNUCBBVlAgY2FycmllZCBpbiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJibG9jayI+ICAgbm9kZXMgPHNwYW4gY2xhc3M9Imluc2VydCI+U0hPVUxEPC9z
cGFuPiB1c2UgdGhlIHByaW9yaXR5IGluZGljYXRlZCBpbiB0aGUgRFJNUCBBVlAgY2Fycmll
ZCBpbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBhbnN3ZXIgbWVzc2Fn
ZSwgaWYgaXQgZXhpc3RzLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+T3RoZXJ3aXNlLDwvc3Bh
bj4gdGhlIERpYW1ldGVyIG5vZGUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+TVVTVDwvc3Bhbj4g
dXNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHRoZSBhbnN3ZXIgbWVz
c2FnZSwgaWYgaXQgZXhpc3RzLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+SWYgdGhlcmUgaXMg
bm90IERSTVAgQVZQIGluIHRoZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi
bG9jayI+ICAgdGhlIHByaW9yaXR5IGluZGljYXRlZCBpbiB0aGUgRFJNUCBBVlAgb2YgdGhl
IGFzc29jaWF0ZWQgcmVxdWVzdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48
c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBhbnN3ZXIgbWVzc2FnZSB0aGVuPC9zcGFuPiB0aGUg
RGlhbWV0ZXIgbm9kZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5TSE9VTEQ8L3NwYW4+IHVzZSB0
aGUgcHJpb3JpdHk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgbWVzc2Fn
ZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgaW5kaWNhdGVkIGluIHRo
ZSBEUk1QIEFWUCBvZiB0aGUgYXNzb2NpYXRlZCByZXF1ZXN0IG1lc3NhZ2UuPC90ZD48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIE5vdGU6IE9uZSBtZXRo
b2QgdG8gZGV0ZXJtaW5lIHdoYXQgcHJpb3JpdHkgdG8gYXBwbHkgdG8gYW4gYW5zd2VyPC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgTm90ZTogT25lIG1ldGhvZCB0
byBkZXRlcm1pbmUgd2hhdCBwcmlvcml0eSB0byBhcHBseSB0byBhbiBhbnN3ZXI8L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHdoZW4gdGhlcmUgaXMgbm8gRFJNUCBB
VlAgaW4gdGhlIGFuc3dlciBtZXNzYWdlIGlzIHRvIHNhdmUgdGhlPC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgd2hlbiB0aGVyZSBpcyBubyBEUk1QIEFWUCBpbiB0
aGUgYW5zd2VyIG1lc3NhZ2UgaXMgdG8gc2F2ZSB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPiAgICAgIHByaW9yaXR5IGluY2x1ZGVkIGluIHRoZSByZXF1ZXN0IG1lc3Nh
Z2UgaW4gc3RhdGUgYXNzb2NpYXRlZCB3aXRoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
aWdodCI+ICAgICAgcHJpb3JpdHkgaW5jbHVkZWQgaW4gdGhlIHJlcXVlc3QgbWVzc2FnZSBp
biBzdGF0ZSBhc3NvY2lhdGVkIHdpdGg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi
PiAgICAgIHRoZSBEaWFtZXRlciB0cmFuc2FjdGlvbi4gIEFub3RoZXIgaXMgdG8gdXNlIHRo
ZSBQcm94eS1JbmZvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgdGhl
IERpYW1ldGVyIHRyYW5zYWN0aW9uLiAgQW5vdGhlciBpcyB0byB1c2UgdGhlIFByb3h5LUlu
Zm88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIG1lY2hhbmlzbSBkZWZp
bmVkIGluIFtSRkM2NzMzXS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg
ICBtZWNoYW5pc20gZGVmaW5lZCBpbiBbUkZDNjczM10uPC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIERpYW1ldGVyIG5vZGVzIE1VU1QgaGF2ZSBhIGRl
ZmF1bHQgcHJpb3JpdHkgdG8gYXBwbHkgdG8gdHJhbnNhY3Rpb25zPC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+ICAgRGlhbWV0ZXIgbm9kZXMgTVVTVCBoYXZlIGEgZGVmYXVs
dCBwcmlvcml0eSB0byBhcHBseSB0byB0cmFuc2FjdGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxlZnQiPiAgIHRoYXQgZG8gbm90IGhhdmUgYW4gZXhwbGljaXQgcHJpb3JpdHkg
c2V0IGluIHRoZSBEUk1QIEFWUC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g
ICB0aGF0IGRvIG5vdCBoYXZlIGFuIGV4cGxpY2l0IHByaW9yaXR5IHNldCBpbiB0aGUgRFJN
UCBBVlAuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIERp
YW1ldGVyIG5vZGVzIFNIT1VMRCB1c2UgdGhlIFBSSU9SSVRZXzEwIHByaW9yaXR5IGFzIHRo
aXMgZGVmYXVsdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERpYW1ldGVy
IG5vZGVzIFNIT1VMRCB1c2UgdGhlIFBSSU9SSVRZXzEwIHByaW9yaXR5IGFzIHRoaXMgZGVm
YXVsdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdmFsdWUuPC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdmFsdWUuPC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTMiPjx0ZD48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9
ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIDxzcGFu
IGNsYXNzPSJpbnNlcnQiPk5vdGU6IFRoaXMgZG9lcyBub3QgaW1wbHkgdGhhdCBhIERSTVAg
QVZQIGlzIGFkZGVkIHRvIHRoZSBtZXNzYWdlLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu
IGNsYXNzPSJpbnNlcnQiPiAgICAgIFJhdGhlciwgdGhlIG1lc3NhZ2UgaXMgdHJlYXRlZCB0
aGUgc2FtZSBhcyBhIG1lc3NhZ2UgdGhhdCBoYXMgYTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz
cGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIERSTVAgQVZQIHdpdGggcHJpb3JpdHkgdmFsdWUg
b2YgUFJJT1JJVFlfMTAuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr
Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRGlhbWV0ZXIgbm9kZXMgTVVT
VCBzdXBwb3J0IHRoZSBhYmlsaXR5IGZvciB0aGUgZGVmYXVsdCBwcmlvcml0eSB0bzwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERpYW1ldGVyIG5vZGVzIE1VU1Qgc3Vw
cG9ydCB0aGUgYWJpbGl0eSBmb3IgdGhlIGRlZmF1bHQgcHJpb3JpdHkgdG88L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGJlIG1vZGlmaWVkIHRocm91Z2ggbG9jYWwgY29u
ZmlndXJhdGlvbiBpbnRlcmZhY2VzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PiAgIGJlIG1vZGlmaWVkIHRocm91Z2ggbG9jYWwgY29uZmlndXJhdGlvbiBpbnRlcmZhY2Vz
LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBOb3Rl
OiBUaGVyZSBhcmUgc2NlbmFyaW9zIHdoZXJlIG9wZXJhdG9ycyBtaWdodCB3YW50IHRvIHNw
ZWNpZnkgYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIE5vdGU6IFRo
ZXJlIGFyZSBzY2VuYXJpb3Mgd2hlcmUgb3BlcmF0b3JzIG1pZ2h0IHdhbnQgdG8gc3BlY2lm
eSBhPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBkaWZmZXJlbnQgZGVm
YXVsdCB2YWx1ZSBmb3IgdHJhbnNhY3Rpb25zIHRoYXQgZG8gbm90IGhhdmUgYW48L3RkPjx0
ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBkaWZmZXJlbnQgZGVmYXVsdCB2YWx1
ZSBmb3IgdHJhbnNhY3Rpb25zIHRoYXQgZG8gbm90IGhhdmUgYW48L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPiAgICAgIGV4cGxpY2l0IHByaW9yaXR5LiAgSW4gdGhpcyBjYXNl
LCB0aGUgb3BlcmF0b3IgZGVmaW5lZCBsb2NhbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPiAgICAgIGV4cGxpY2l0IHByaW9yaXR5LiAgSW4gdGhpcyBjYXNlLCB0aGUgb3Bl
cmF0b3IgZGVmaW5lZCBsb2NhbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K
ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg
ICAgcG9saWN5IHdvdWxkIG92ZXJyaWRlIHRoZSB1c2Ugb2YgUFJJT1JJVFlfMTAgYXMgdGhl
IGRlZmF1bHQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBwb2xpY3kg
d291bGQgb3ZlcnJpZGUgdGhlIHVzZSBvZiBQUklPUklUWV8xMCBhcyB0aGUgZGVmYXVsdDwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgcHJpb3JpdHkuPC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgcHJpb3JpdHkuPC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFdoZW4gdXNpbmcgRFJNUCBwcmlvcml0
eSBpbmZvcm1hdGlvbiwgRGlhbWV0ZXIgbm9kZXMgTVVTVCB1c2UgdGhlPC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgV2hlbiB1c2luZyBEUk1QIHByaW9yaXR5IGluZm9y
bWF0aW9uLCBEaWFtZXRlciBub2RlcyBNVVNUIHVzZSB0aGU8L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTgiIGNsYXNz
PSJjaGFuZ2UiID48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwv
c21hbGw+PGEgaHJlZj0iI3BhcnQtOCI+PGVtPiBwYWdlIDExLCBsaW5lIDEzPHNwYW4gY2xh
c3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxz
bWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTgiPjxl
bT4gcGFnZSAxMiwgbGluZSAxNTxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwv
ZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgbm90IGluc2VydCBhIERSTVAgQVZQIHdp
dGggYSBwcmlvcml0eSB2YWx1ZSBvZiAxMC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij4gICAgICBub3QgaW5zZXJ0IGEgRFJNUCBBVlAgd2l0aCBhIHByaW9yaXR5IHZhbHVl
IG9mIDEwLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBX
aGVuIHNldHRpbmcgYW5kIHVzaW5nIHByaW9yaXRpZXMsIGZvciBhbGwgaW50ZWdlcnMgeCx5
IGluIFswLDE1XTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFdoZW4gc2V0
dGluZyBhbmQgdXNpbmcgcHJpb3JpdGllcywgZm9yIGFsbCBpbnRlZ2VycyB4LHkgaW4gWzAs
MTVdPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0cmVhdCBQUklPUklUWV8m
bHQ7eCZndDsgYXMgbG93ZXIgcHJpb3JpdHkgdGhhbiBQUklPSVJUWV8mbHQ7eSZndDsgd2hl
biB5Jmx0O3guPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdHJlYXQgUFJJ
T1JJVFlfJmx0O3gmZ3Q7IGFzIGxvd2VyIHByaW9yaXR5IHRoYW4gUFJJT0lSVFlfJmx0O3km
Z3Q7IHdoZW4geSZsdDt4LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs
ZWZ0Ij4gICAgICBOb3RlOiBBcyBhIHJlc3VsdCBQUklPUklUWV8wIGlzIHRoZSBoaWdoZXN0
IHByaW9yaXR5LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIE5vdGU6
IEFzIGEgcmVzdWx0IFBSSU9SSVRZXzAgaXMgdGhlIGhpZ2hlc3QgcHJpb3JpdHkuPC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjkuICBBdHRyaWJ1dGUgVmFs
dWUgUGFpcnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij45LiAgQXR0cmlidXRl
IFZhbHVlIFBhaXJzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi
PiAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgdGhlIGVuY29kaW5nIGFuZCBzZW1hbnRpY3Mg
b2YgdGhlIERpYW1ldGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhp
cyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgZW5jb2RpbmcgYW5kIHNlbWFudGljcyBvZiB0aGUg
RGlhbWV0ZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBp
ZD0iZGlmZjAwMTQiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgT3ZlcmxvYWQgSW5kaWNhdGlvbiBBdHRy
aWJ1dGUgVmFsdWUgUGFpcjxzcGFuIGNsYXNzPSJkZWxldGUiPnMgKEFWUHM8L3NwYW4+KSBk
ZWZpbmVkIGluIHRoaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgT3Zl
cmxvYWQgSW5kaWNhdGlvbiBBdHRyaWJ1dGUgVmFsdWUgUGFpcjxzcGFuIGNsYXNzPSJpbnNl
cnQiPiAoQVZQPC9zcGFuPikgZGVmaW5lZCBpbiB0aGlzPC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij4gICBkb2N1bWVudC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij4gICBkb2N1bWVudC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm
dCI+OS4xLiAgRFJNUCBBVlA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij45LjEu
ICBEUk1QIEFWUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g
ICBUaGUgRFJNUCAoQVZQIGNvZGUgVEJEMSkgaXMgb2YgdHlwZSBFbnVtZXJhdGVkLiAgVGhl
IHZhbHVlIG9mIHRoZSBBVlA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBU
aGUgRFJNUCAoQVZQIGNvZGUgVEJEMSkgaXMgb2YgdHlwZSBFbnVtZXJhdGVkLiAgVGhlIHZh
bHVlIG9mIHRoZSBBVlA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGluZGlj
YXRlcyB0aGUgcm91dGluZyBtZXNzYWdlIHByaW9yaXR5IGZvciB0aGUgdHJhbnNhY3Rpb24u
ICBUaGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbmRpY2F0ZXMgdGhl
IHJvdXRpbmcgbWVzc2FnZSBwcmlvcml0eSBmb3IgdGhlIHRyYW5zYWN0aW9uLiAgVGhlPC90
ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBmb2xsb3dpbmcgdmFsdWVzIGFyZSBk
ZWZpbmVkOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGZvbGxvd2luZyB2
YWx1ZXMgYXJlIGRlZmluZWQ6PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9
ImxlZnQiPiAgIFBSSU9SSVRZXzE1IDE1ICBQUklPUklUWV8xNSBpcyB0aGUgbG93ZXN0IHBy
aW9yaXR5LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFBSSU9SSVRZXzE1
IDE1ICBQUklPUklUWV8xNSBpcyB0aGUgbG93ZXN0IHByaW9yaXR5LjwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90
ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBp
ZD0icGFydC05IiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGlu
ZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTkiPjxlbT4gcGFnZSAxMiwg
bGluZSAzMTxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+
PHRoPiA8L3RoPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBo
cmVmPSIjcGFydC05Ij48ZW0+IHBhZ2UgMTMsIGxpbmUgMzQ8c3BhbiBjbGFzcz0iaGlkZSI+
ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0r
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLSs8L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxBVlAgZmxhZyB8PC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgfEFWUCBmbGFnIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHxydWxlcyAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo
dCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfHJ1bGVzICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICst
LS0tKy0tLS0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0rLS0t
LSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIEFWUCAgIFNlY3Rpb24gICAgICAgICAgICAgIHwgICAgfE1VU1R8PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgQVZQICAgU2VjdGlvbiAgICAgICAgICAgICAgfCAgICB8TVVTVHw8L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICBBdHRyaWJ1dGUgTmFtZSAgICAgICAgIENvZGUg
IERlZmluZWQgIFZhbHVlIFR5cGUgIHxNVVNUfCBOT1R8PC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyaWdodCI+ICAgICAgIEF0dHJpYnV0ZSBOYW1lICAgICAgICAgQ29kZSAgRGVmaW5l
ZCAgVmFsdWUgVHlwZSAgfE1VU1R8IE5PVHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPiAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLSstLS0tKy0tLS0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg
ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
Ky0tLS0rLS0tLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHxEUk1Q
ICAgICAgICAgICAgICAgICAgIFRCRDEgIHgueCAgICAgIEVudW1lcmF0ZWQgIHwgICAgfCBW
ICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgfERSTVAgICAgICAg
ICAgICAgICAgICAgVEJEMSAgeC54ICAgICAgRW51bWVyYXRlZCAgfCAgICB8IFYgIHw8L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tKy0tLS0rPC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0rLS0tLSs8L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxNSI+PHRk
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz
cz0ibGJsb2NrIj4xMC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPklBTkEgQ29uc2lkZXJhdGlv
bjwvc3Bhbj5zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjEwLiAgPHNwYW4g
Y2xhc3M9Imluc2VydCI+Q29uc2lkZXJhdGlvbnMgV2hlbiBEZWZpbmluZyBBcHBsaWNhdGlv
biBQcmlvcml0aWU8L3NwYW4+czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K
ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDE2Ij48dGQ+PC90ZD48L3RyPgogICAg
ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFu
IGNsYXNzPSJkZWxldGUiPjEwLjEuICBBVlAgY29kZXM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkFzIGRpc2N1c3Nl
ZCBpbiBTZWN0aW9uIDEuMSwgaXQgaXMgaW1wb3J0YW50IHRoYXQgdGhlIGRlZmluaXRpb24g
b2Y8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBwcmlvcml0
eSB2YWx1ZXMgdXNlZCBieSBhbGwgYXBwbGljYXRpb25zIHdpdGhpbiBhIHNpbmdsZSBEaWFt
ZXRlcjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGFkbWlu
aXN0cmF0aXZlIGRvbWFpbiBiZSBkb25lIGluIGEgY29uc2lzdGVudCBhbmQgY29vcmRpbmF0
ZWQgbWFubmVyLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxNyI+PHRkPjwvdGQ+PC90cj4KICAgICAg
PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3Bh
biBjbGFzcz0iZGVsZXRlIj5OZXcgQVZQcyBkZWZpbmVkIGJ5IHRoaXMgc3BlY2lmaWNhdGlv
bjwvc3Bhbj4gYXJlIDxzcGFuIGNsYXNzPSJkZWxldGUiPmxpc3RlZCBpbiBTZWN0aW9uIDku
ICBBbGw8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFu
IGNsYXNzPSJpbnNlcnQiPlRoZSBmb2xsb3dpbmc8L3NwYW4+IGFyZSA8c3BhbiBjbGFzcz0i
aW5zZXJ0Ij5zb21lIHRoaW5ncyB0byBiZSBjb25zaWRlcmVkIHdoZW4gZGVmaW5pbmc8L3Nw
YW4+IHRoZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5EUk1QPC9zcGFuPjwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBBVlAgY29kZXMg
YXJlIGFsbG9jYXRlZCBmcm9tPC9zcGFuPiB0aGUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+J0F1
dGhlbnRpY2F0aW9uLCBBdXRob3JpemF0aW9uLCBhbmQ8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHByaW9yaXRpZXMg
dG8gYmUgdXNlZCBpbiBEaWFtZXRlciBuZXR3b3JrcyB3aGljaCBzdXBwb3J0IERpYW1ldGVy
PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0i
ZGVsZXRlIj4gICBBY2NvdW50aW5nIChBQUEpIFBhcmFtZXRlcnMnIEFWUCBDb2RlcyByZWdp
c3RyeS48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs
YXNzPSJpbnNlcnQiPiAgIG5vZGVzIGhhbmRsaW5nIG11bHRpcGxlIGFwcGxpY2F0aW9ucy48
L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0ciBpZD0iZGlmZjAwMTgiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0
ZSI+MTAuMi48L3NwYW4+ICBOZXcgcmVnaXN0cmllczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xLiAgQXMgd2l0aCBhbnkgcHJp
b3JpdGl6YXRpb24gc2NoZW1lLCBpdCBpcyBwb3NzaWJsZSBmb3IgaGlnaGVyPC9zcGFuPjwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgIHByaW9yaXR5IG1lc3Nh
Z2VzIHRvIGJsb2NrIGxvd2VyIHByaW9yaXR5IG1lc3NhZ2VzIGZyb20gZXZlcjwvc3Bhbj48
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICBiZWluZyBoYW5kbGVk
LiAgSW4gYSBEaWFtZXRlciBuZXR3b3JrIHRoaXMgd2lsbCBvZnRlbiByZXN1bHQgaW48L3Nw
YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgdGhvc2UgRGlh
bWV0ZXIgdHJhbnNhY3Rpb25zIGJlaW5nIHJldHJpZWQuICBUaGlzIGNhbiByZXN1bHQgaW48
L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgbW9yZSB0
cmFmZmljIHRoYW4gdGhlIG5ldHdvcmsgd291bGQgaGF2ZSBoYW5kbGVkIHdpdGhvdXQgdXNl
IG9mPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgIHRo
ZSBEUk1QIG1lY2hhbmlzbS48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv
Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z
ZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAg
T25lIHBvdGVudGlhbCBndWlkZWxpbmUgdG8gcHJldmVudCB1bndhbnRlZCBzdGFydmluZyBv
ZiBsb3dlcjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAg
ICBwcmlvcml0eSBtZXNzYWdlcyBpcyB0byBoYXZlIGhpZ2hlciBwcmlvcml0eSBtZXNzYWdl
cyByZXByZXNlbnQgYTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi
PiAgICAgICByZWxhdGl2ZWx5IHNtYWxsIHBvcnRpb24gb2YgbWVzc2FnZXMgaGFuZGxlZCBi
eSB0aGUgRGlhbWV0ZXI8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si
PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0
Ij4gICAgICAgbmV0d29yayB1bmRlciBub3JtYWwgc2NlbmFyaW9zLjwvc3Bhbj48L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
YmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu
IGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICBOb3RlIHRoYXQgdGhlcmUgYXJlIHNjZW5hcmlv
cywgc3VjaCBhcyBmaXJzdCByZXNwb25kZXI8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj
bGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgbWVzc2FnZXMsIHdoZXJlIHRoZSBibG9ja2luZyBv
ZiBsb3dlciBwcmlvcml0eSBtZXNzYWdlcyBpcyBhPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0
ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw
YW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgIHJlcXVpcmVtZW50Ljwvc3Bhbj48L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
YmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu
IGNsYXNzPSJpbnNlcnQiPiAgIDIuICBXaGVuIHNldHRpbmcgcHJpb3JpdGllcyBmb3IgYW55
IG9mIHRoZSB1c2UgY2FzZXMgb3V0bGluZWQgaW48L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh
biBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgU2VjdGlvbiA1IGl0IGlzIGltcG9ydGFudCB0byB1
c2UgdGhlIHNhbWUgcHJpb3JpdHkgdmFsdWVzIGFjcm9zczwvc3Bhbj48L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si
PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICBhcHBsaWNhdGlvbnMuICBGb3IgaW5zdGFu
Y2UsIHdoZW4gZGVmaW5pbmcgcHJpb3JpdHkgZm9yIHRoZSBGaXJzdDwvc3Bhbj48L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
YmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICBSZXNwb25kZXIgdXNlIGNhc2Ug
ZGlzY3Vzc2VkIGluIFNlY3Rpb24gNS4xIGFuZCB0aGUgRW1lcmdlbmN5PC9zcGFuPjwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgIGNhbGwgdXNlIGNhc2UgZGlz
Y3Vzc2VkIGluIFNlY3Rpb24gNS4yIHVzZSBjYXNlcywgb25lIGhpZ2g8L3NwYW4+PC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgcHJpb3JpdHkgdmFsdWUgbWln
aHQgYmUgdXNlZCBmb3IgYWxsIGZpcnN0IHJlc3BvbmRlciBtZXNzYWdlcyw8L3NwYW4+PC90
ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgc2F5IFBSSU9SSVRZXzIs
IGFuZCBhIHNsaWdodGx5IGxvd2VyIHByaW9yaXR5IHZhbHVlLCBzYXk8L3NwYW4+PC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgUFJJT1JJVFlfMywgbWlnaHQg
YmUgdXNlZCBmb3IgZW1lcmdlbmN5IGNhbGwgcmVsYXRlZCBtZXNzYWdlcy48L3NwYW4+PC90
ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgVGhlc2UgdmFsdWVzIHNo
b3VsZCBiZSBzcGVjaWZpZWQgZm9yIHRoZXNlIHVzZSBjYXNlcyBhY3Jvc3MgYWxsPC9zcGFu
PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgIGFwcGxpY2F0aW9u
cyB1c2VkIHdpdGhpbiB0aGUgRGlhbWV0ZXIgYWRtaW5pc3RyYXRpdmUgZG9tYWluLjwvc3Bh
bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv
Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICBOb3RlIHRoYXQgdGhlIHZhbHVl
cyBtZW50aW9uZWQgaGVyZSBhcmUgc3RyaWN0bHkgZm9yPC9zcGFuPjwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+
PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgIGlsbHVzdHJhdGl2ZSBwdXJwb3Nlcy4g
IFRoZSBhY3R1YWwgdmFsdWVzIHVzZWQgZm9yIHRoZXNlIHVzZTwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv
Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICBjYXNlcyBhcmUgbGlrZWx5IHRv
IGJlIGRpZmZlcmVudC48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si
PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0
Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAzLiAgTWVz
c2FnZXMgd2l0aG91dCB0aGUgRFJNUCBBVlAgd2lsbCBiZSBnaXZlbiBkZWZhdWx0IHByaW9y
aXR5PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgIHZh
bHVlIHRocmVhdG1lbnQuICBUaGlzIHdpbGwgaW5jbHVkZSBtZXNzYWdlcyBmcm9tIERpYW1l
dGVyPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgIENs
aWVudHMgdGhhdCBoYXZlIG5vdCBiZWVuIHVwZGF0ZWQgdG8gc3VwcG9ydCB0aGUgRFJNUCBt
ZWNoYW5pc20uPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAg
ICAgIEl0IG1pZ2h0IGFsc28gaW5jbHVkZSBtZXNzYWdlcyBmcm9tIGZvcmVpZ24gYWRtaW5p
c3RyYXRpdmU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg
ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAg
ICAgZG9tYWlucyBpZiB0aGUgRFJNUCBBVlBzIGFyZSBzdHJpcHBlZCBmcm9tIG1lc3NhZ2Vz
IGNyb3NzaW5nIHRoZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi
PiAgICAgICBEaWFtZXRlciBhZG1pbmlzdHJhdGl2ZSBkb21haW5zLjwvc3Bhbj48L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
YmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu
IGNsYXNzPSJpbnNlcnQiPiAgIDQuICBUaGUgcHJvY2VzcyB1c2VkIHRvIGludHJvZHVjZSB0
aGUgRFJNUCBtZWNoYW5pc20gaW50byBhIERpYW1ldGVyPC9zcGFuPjwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+
PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgIG5ldHdvcmsgc2hvdWxkIGFsc28gYmUgdGFr
ZW4gaW50byBjb25zaWRlcmF0aW9uLiAgTWVzc2FnZXMgb2YgdGhlPC9zcGFuPjwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi
bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgIHNhbWUgdHlwZSB3aXRoaW4gdGhl
IHNhbWUgYXBwbGljYXRpb24gbWlnaHQgZ2V0IGRpZmZlcmVudDwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv
Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICB0cmVhdG1lbnQgZGVwZW5kaW5nIG9u
IHdoZXRoZXIgdGhvc2UgbWVzc2FnZXMgYXJlIHNlbnQgZnJvbSBub2Rlczwvc3Bhbj48L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICB0aGF0IGFyZSB1cGdyYWRl
ZCB0byBzdXBwb3J0IHRoZSBEUk1QIG1lY2hhbmlzbSB2ZXJzdXMgbm9kZXMgdGhhdDwvc3Bh
bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICBoYXZlIG5vdCB5
ZXQgYmVlbiB1cGdyYWRlZCB0byBzdXBwb3J0IHRoZSBEUk1QIG1lY2hhbmlzbS48L3NwYW4+
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr
Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xMS4gIElBTkEgQ29uc2lkZXJhdGlvbnM8L3NwYW4+
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr
Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xMS4xLiAgQVZQIGNvZGVzPC9zcGFuPjwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi
bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj
bGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4g
Y2xhc3M9Imluc2VydCI+ICAgVGhlIG5ldyBBVlAgZGVmaW5lZCBieSB0aGlzIHNwZWNpZmlj
YXRpb24gaXMgbGlzdGVkIGluIFNlY3Rpb24gOS48L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh
biBjbGFzcz0iaW5zZXJ0Ij4gICBBbGwgQVZQIGNvZGVzIGFyZSBhbGxvY2F0ZWQgZnJvbSB0
aGUgJ0F1dGhlbnRpY2F0aW9uLCBBdXRob3JpemF0aW9uLDwvc3Bhbj48L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si
PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGFuZCBBY2NvdW50aW5nIChBQUEpIFBhcmFtZXRl
cnMnIEFWUCBDb2RlcyByZWdpc3RyeS48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz
PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz
cz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4x
MS4yLjwvc3Bhbj4gIE5ldyByZWdpc3RyaWVzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs
ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPiAgIFRoZXJlIGFyZSBubyBuZXcgSUFOQSByZWdpc3RyaWVzIGlu
dHJvZHVjZWQgYnkgdGhpcyBkb2N1bWVudC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij4gICBUaGVyZSBhcmUgbm8gbmV3IElBTkEgcmVnaXN0cmllcyBpbnRyb2R1Y2VkIGJ5
IHRoaXMgZG9jdW1lbnQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg
ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0
ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTkiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+MTxzcGFuIGNs
YXNzPSJkZWxldGUiPjE8L3NwYW4+LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L3RkPjx0
ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+MTxzcGFuIGNsYXNzPSJpbnNlcnQiPjI8L3Nw
YW4+LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9
ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgRFJNUCBnaXZlcyBEaWFtZXRlciBub2RlcyB0aGUgYWJp
bGl0eSB0byBpbmZsdWVuY2Ugd2hpY2ggcmVxdWVzdHMgYXJlPC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+ICAgRFJNUCBnaXZlcyBEaWFtZXRlciBub2RlcyB0aGUgYWJpbGl0
eSB0byBpbmZsdWVuY2Ugd2hpY2ggcmVxdWVzdHMgYXJlPC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDIwIj48dGQ+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg
IHRocm90dGxlZCBkdXJpbmcgb3ZlcmxvYWQgc2NlbmFyaW9zLiAgSW1wcm9wZXIgdXNlIG9m
IHRoZSBEUk1QPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHRocm90dGxl
ZCBkdXJpbmcgb3ZlcmxvYWQgc2NlbmFyaW9zLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+SW4g
YWRkaXRpb24sIERSTVAgY2FuIGJlIHVzZWQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsYmxvY2siPiAgIG1lY2hhbmlzbSBjb3VsZCByZXN1bHQgaW4gdGhlIG1hbGljaW91
cyBEaWFtZXRlciBub2RlIGdhaW5pbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j
ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgaW4gZGV0ZXJtaW5pbmcgdGhlIHJvdXRpbmcg
ZGVjaXNpb25zIGZvciByZXF1ZXN0IG1lc3NhZ2VzLjwvc3Bhbj4gIEltcHJvcGVyPC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHByZWZlcmVudGlhbCB0cmVhdG1lbnQs
IGJ5IHJlZHVjaW5nIHRoZSBwcm9iYWJpbGl0eSBvZiBpdHMgcmVxdWVzdHM8L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgdXNlIG9mIHRoZSBEUk1QIG1lY2hhbmlzbSBj
b3VsZCByZXN1bHQgaW4gdGhlIG1hbGljaW91cyBEaWFtZXRlciBub2RlPC90ZD48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGJlaW5nIHRocm90dGxlZCwgb3ZlciBvdGhlciBE
aWFtZXRlciBub2Rlcy4gIFRoaXMgd291bGQgYmUgYWNoaWV2ZWQ8L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJibG9jayI+ICAgZ2FpbmluZyBwcmVmZXJlbnRpYWwgdHJlYXRtZW50LCBi
eSByZWR1Y2luZyB0aGUgcHJvYmFiaWxpdHkgb2YgaXRzPC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsYmxvY2siPiAgIGJ5IHRoZSBtYWxpY2lvdXMgbm9kZSBpbnNlcnRpbmcgYXJ0aWZp
Y2lhbGx5IGhpZ2ggcHJpb3JpdHkgdmFsdWVzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmJsb2NrIj4gICByZXF1ZXN0cyBiZWluZyB0aHJvdHRsZWQsIG92ZXIgb3RoZXIgRGlhbWV0
ZXIgbm9kZXMuICBUaGlzIHdvdWxkIGJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv
Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBhY2hpZXZlZCBieSB0
aGUgbWFsaWNpb3VzIG5vZGUgaW5zZXJ0aW5nIGFydGlmaWNpYWxseSBoaWdoIHByaW9yaXR5
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmJsb2NrIj4gICB2YWx1ZXMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0
Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxlZnQiPiAgIERpYW1ldGVyIGRvZXMgbm90IGluY2x1ZGUgZmVhdHVyZXMgdG8g
cHJvdmlkZSBlbmQtdG8tZW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg
RGlhbWV0ZXIgZG9lcyBub3QgaW5jbHVkZSBmZWF0dXJlcyB0byBwcm92aWRlIGVuZC10by1l
bmQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGF1dGhlbnRpY2F0aW9uLCBp
bnRlZ3JpdHkgcHJvdGVjdGlvbiwgb3IgY29uZmlkZW50aWFsaXR5LiAgVGhpcyBvcGVuczwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGF1dGhlbnRpY2F0aW9uLCBpbnRl
Z3JpdHkgcHJvdGVjdGlvbiwgb3IgY29uZmlkZW50aWFsaXR5LiAgVGhpcyBvcGVuczwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIHBvc3NpYmlsaXR5IHRoYXQgbWFs
aWNpb3VzIG9yIGNvbXByb21pc2VkIGFnZW50cyBpbiB0aGUgcGF0aCBvZiBhPC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhlIHBvc3NpYmlsaXR5IHRoYXQgbWFsaWNp
b3VzIG9yIGNvbXByb21pc2VkIGFnZW50cyBpbiB0aGUgcGF0aCBvZiBhPC90ZD48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZXF1ZXN0IGNvdWxkIG1vZGlmeSB0aGUgRFJNUCBB
VlAgdG8gcmVmbGVjdCBhIHByaW9yaXR5IGRpZmZlcmVudDwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmlnaHQiPiAgIHJlcXVlc3QgY291bGQgbW9kaWZ5IHRoZSBEUk1QIEFWUCB0byBy
ZWZsZWN0IGEgcHJpb3JpdHkgZGlmZmVyZW50PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs
ZWZ0Ij4gICB0aGFuIHRoYXQgYXNzZXJ0ZWQgYnkgdGhlIHNlbmRlciBvZiB0aGUgcmVxdWVz
dC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGFuIHRoYXQgYXNzZXJ0
ZWQgYnkgdGhlIHNlbmRlciBvZiB0aGUgcmVxdWVzdC48L3RkPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyMSI+PHRkPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i
bGJsb2NrIj4xPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTwvc3Bhbj4uMS4gIFBvdGVudGlhbCBU
aHJlYXQgTW9kZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+MTxzcGFuIGNs
YXNzPSJpbnNlcnQiPjI8L3NwYW4+LjEuICBQb3RlbnRpYWwgVGhyZWF0IE1vZGVzPC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBEaWFtZXRlciBw
cm90b2NvbCBpbnZvbHZlcyB0cmFuc2FjdGlvbnMgaW4gdGhlIGZvcm0gb2YgcmVxdWVzdHM8
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgRGlhbWV0ZXIgcHJvdG9j
b2wgaW52b2x2ZXMgdHJhbnNhY3Rpb25zIGluIHRoZSBmb3JtIG9mIHJlcXVlc3RzPC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhbmQgYW5zd2VycyBleGNoYW5nZWQgYmV0
d2VlbiBjbGllbnRzIGFuZCBzZXJ2ZXJzLiAgVGhlc2UgY2xpZW50cyBhbmQ8L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbmQgYW5zd2VycyBleGNoYW5nZWQgYmV0d2Vl
biBjbGllbnRzIGFuZCBzZXJ2ZXJzLiAgVGhlc2UgY2xpZW50cyBhbmQ8L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNlcnZlcnMgbWF5IGJlIHBlZXJzLCB0aGF0IGlzLCB0
aGV5IG1heSBzaGFyZSBhIGRpcmVjdCB0cmFuc3BvcnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij4gICBzZXJ2ZXJzIG1heSBiZSBwZWVycywgdGhhdCBpcywgdGhleSBtYXkg
c2hhcmUgYSBkaXJlY3QgdHJhbnNwb3J0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0
Ij4gICAoZS5nLiwgVHJhbnNtaXNzaW9uIENvbnRyb2wgUHJvdG9jb2wgKFRDUCkgb3IgU3Ry
ZWFtIENvbnRyb2w8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAoZS5nLiwg
VHJhbnNtaXNzaW9uIENvbnRyb2wgUHJvdG9jb2wgKFRDUCkgb3IgU3RyZWFtIENvbnRyb2w8
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRyYW5zbWlzc2lvbiBQcm90b2Nv
bCAoU0NUUCkpIGNvbm5lY3Rpb24sIG9yIHRoZSBtZXNzYWdlcyBtYXk8L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUcmFuc21pc3Npb24gUHJvdG9jb2wgKFNDVFApKSBj
b25uZWN0aW9uLCBvciB0aGUgbWVzc2FnZXMgbWF5PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz
PSJsZWZ0Ij4gICB0cmF2ZXJzZSBvbmUgb3IgbW9yZSBpbnRlcm1lZGlhcmllcywga25vd24g
YXMgRGlhbWV0ZXIgQWdlbnRzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg
IHRyYXZlcnNlIG9uZSBvciBtb3JlIGludGVybWVkaWFyaWVzLCBrbm93biBhcyBEaWFtZXRl
ciBBZ2VudHMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBEaWFtZXRlciBu
b2RlcyB1c2UgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpLCBEYXRhZ3JhbSBUcmFu
c3BvcnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBEaWFtZXRlciBub2Rl
cyB1c2UgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpLCBEYXRhZ3JhbSBUcmFuc3Bv
cnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIExheWVyIFNlY3VyaXR5IChE
VExTKSwgb3IgSVBzZWMgdG8gYXV0aGVudGljYXRlIHBlZXJzLCBhbmQgdG8gcHJvdmlkZTwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIExheWVyIFNlY3VyaXR5IChEVExT
KSwgb3IgSVBzZWMgdG8gYXV0aGVudGljYXRlIHBlZXJzLCBhbmQgdG8gcHJvdmlkZTwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29uZmlkZW50aWFsaXR5IGFuZCBpbnRl
Z3JpdHkgcHJvdGVjdGlvbiBvZiB0cmFmZmljIGJldHdlZW4gcGVlcnMuPC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkg
cHJvdGVjdGlvbiBvZiB0cmFmZmljIGJldHdlZW4gcGVlcnMuPC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC0xMCIgY2xh
c3M9ImNoYW5nZSIgPjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0
PC9zbWFsbD48YSBocmVmPSIjcGFydC0xMCI+PGVtPiBwYWdlIDE0LCBsaW5lIDc8c3BhbiBj
bGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+
PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtMTAi
PjxlbT4gcGFnZSAxNiwgbGluZSAyMTxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFu
PjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW4gc2NvcGUgdG8gd2hlbiBvbmUgb3Ig
bW9yZSBEaWFtZXRlciBub2RlcyBhcmUgaW4gYW4gb3ZlcmxvYWRlZDwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIGluIHNjb3BlIHRvIHdoZW4gb25lIG9yIG1vcmUgRGlh
bWV0ZXIgbm9kZXMgYXJlIGluIGFuIG92ZXJsb2FkZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPiAgIHN0YXRlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg
IHN0YXRlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBU
aGUgRFJNUCBtZWNoYW5pc20gY2FuIGFsc28gYmUgdXNlZCB0byBpbmZsdWVuY2UgdGhlIG9y
ZGVyIGluIHdoaWNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIERS
TVAgbWVjaGFuaXNtIGNhbiBhbHNvIGJlIHVzZWQgdG8gaW5mbHVlbmNlIHRoZSBvcmRlciBp
biB3aGljaDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRGlhbWV0ZXIgbWVz
c2FnZXMgYXJlIGhhbmRsZWQgYnkgRGlhbWV0ZXIgbm9kZXMuICBUaGUgYWJvdmUgYXR0YWNr
czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERpYW1ldGVyIG1lc3NhZ2Vz
IGFyZSBoYW5kbGVkIGJ5IERpYW1ldGVyIG5vZGVzLiAgVGhlIGFib3ZlIGF0dGFja3M8L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGhhdmUgYSBwb3RlbnRpYWxseSBncmVh
dGVyIGltcGFjdCBpbiB0aGlzIHNjZW5hcmlvIGFzIHRoZSBwcmlvcml0eTwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGhhdmUgYSBwb3RlbnRpYWxseSBncmVhdGVyIGlt
cGFjdCBpbiB0aGlzIHNjZW5hcmlvIGFzIHRoZSBwcmlvcml0eTwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+ICAgaW5kaWNhdGlvbiBpbXBhY3RzIHRoZSBoYW5kbGluZyBvZiBh
bGwgcmVxdWVzdHMgYXQgYWxsIHRpbWVzLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPiAgIGluZGljYXRpb24gaW1wYWN0cyB0aGUgaGFuZGxpbmcgb2YgYWxsIHJlcXVlc3Rz
IGF0IGFsbCB0aW1lcyw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGluZGVw
ZW5kZW50IG9mIHRoZSBvdmVybG9hZCBzdGF0dXMgb2YgRGlhbWV0ZXIgbm9kZXMgaW4gdGhl
IERpYW1ldGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaW5kZXBlbmRl
bnQgb2YgdGhlIG92ZXJsb2FkIHN0YXR1cyBvZiBEaWFtZXRlciBub2RlcyBpbiB0aGUgRGlh
bWV0ZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG5ldHdvcmsuPC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbmV0d29yay48L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyMiI+
PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj
bGFzcz0ibGJsb2NrIj4xPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTwvc3Bhbj4uMi4gIERlbmlh
bCBvZiBTZXJ2aWNlIEF0dGFja3M8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+
MTxzcGFuIGNsYXNzPSJpbnNlcnQiPjI8L3NwYW4+LjIuICBEZW5pYWwgb2YgU2VydmljZSBB
dHRhY2tzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRo
ZSBEUk1QIG1lY2hhbmlzbSBkb2VzIG5vdCBvcGVuIGRpcmVjdCBkZW5pYWwgb2Ygc2Vydmlj
ZSBhdHRhY2s8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgRFJNUCBt
ZWNoYW5pc20gZG9lcyBub3Qgb3BlbiBkaXJlY3QgZGVuaWFsIG9mIHNlcnZpY2UgYXR0YWNr
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB2ZWN0b3JzLiAgUmF0aGVyLCBp
dCBpbnRyb2R1Y2VzIGEgbWVjaGFuaXNtIHdoZXJlIGEgbm9kZSBjYW4gZ2FpbjwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHZlY3RvcnMuICBSYXRoZXIsIGl0IGludHJv
ZHVjZXMgYSBtZWNoYW5pc20gd2hlcmUgYSBub2RlIGNhbiBnYWluPC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij4gICB1bndhcnJhbnRlZCBwcmVmZXJlbnRpYWwgdHJlYXRtZW50
LiAgSXQgYWxzbyBpbnRyb2R1Y2VzIGEgbWVjaGFuaXNtPC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyaWdodCI+ICAgdW53YXJyYW50ZWQgcHJlZmVyZW50aWFsIHRyZWF0bWVudC4gIEl0
IGFsc28gaW50cm9kdWNlcyBhIG1lY2hhbmlzbTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i
bGVmdCI+ICAgd2hlcmUgYSBub2RlIGNhbiBnZXQgZGVncmFkZWQgc2VydmljZSBpbiB0aGUg
c2NlbmFyaW8gd2hlcmUgYSByb2d1ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PiAgIHdoZXJlIGEgbm9kZSBjYW4gZ2V0IGRlZ3JhZGVkIHNlcnZpY2UgaW4gdGhlIHNjZW5h
cmlvIHdoZXJlIGEgcm9ndWU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFn
ZW50IGNoYW5nZXMgdGhlIHByaW9yaXR5IHZhbHVlIGluY2x1ZGVkIGluIG1lc3NhZ2VzLjwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFnZW50IGNoYW5nZXMgdGhlIHBy
aW9yaXR5IHZhbHVlIGluY2x1ZGVkIGluIG1lc3NhZ2VzLjwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj
bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDIzIj48dGQ+
PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz
PSJsYmxvY2siPjE8c3BhbiBjbGFzcz0iZGVsZXRlIj4xPC9zcGFuPi4zLiAgRW5kLXRvIEVu
ZC1TZWN1cml0eSBJc3N1ZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+MTxz
cGFuIGNsYXNzPSJpbnNlcnQiPjI8L3NwYW4+LjMuICBFbmQtdG8gRW5kLVNlY3VyaXR5IElz
c3VlczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg
ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUg
bGFjayBvZiBlbmQtdG8tZW5kIGludGVncml0eSBmZWF0dXJlcyBpbiBEaWFtZXRlciBbUkZD
NjczM10gbWFrZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgbGFj
ayBvZiBlbmQtdG8tZW5kIGludGVncml0eSBmZWF0dXJlcyBpbiBEaWFtZXRlciBbUkZDNjcz
M10gbWFrZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGl0IGRpZmZpY3Vs
dCB0byBlc3RhYmxpc2ggdHJ1c3QgaW4gRFJNUCBBVlBzIHJlY2VpdmVkIGZyb20gbm9uLTwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGl0IGRpZmZpY3VsdCB0byBlc3Rh
Ymxpc2ggdHJ1c3QgaW4gRFJNUCBBVlBzIHJlY2VpdmVkIGZyb20gbm9uLTwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYWRqYWNlbnQgbm9kZXMuICBBbnkgYWdlbnRzIGlu
IHRoZSBtZXNzYWdlIHBhdGggbWF5IGluc2VydCBvciBtb2RpZnk8L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJpZ2h0Ij4gICBhZGphY2VudCBub2Rlcy4gIEFueSBhZ2VudHMgaW4gdGhl
IG1lc3NhZ2UgcGF0aCBtYXkgaW5zZXJ0IG9yIG1vZGlmeTwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj
bGFzcz0ibGVmdCI+ICAgRFJNUCBBVlBzLiAgTm9kZXMgbXVzdCB0cnVzdCB0aGF0IHRoZWly
IGFkamFjZW50IHBlZXJzIHBlcmZvcm0gcHJvcGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyaWdodCI+ICAgRFJNUCBBVlBzLiAgTm9kZXMgbXVzdCB0cnVzdCB0aGF0IHRoZWlyIGFk
amFjZW50IHBlZXJzIHBlcmZvcm0gcHJvcGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs
ZWZ0Ij4gICBjaGVja3Mgb24gb3ZlcmxvYWQgcmVwb3J0cyBmcm9tIHRoZWlyIHBlZXJzLCBh
bmQgc28gb24sIGNyZWF0aW5nIGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g
ICBjaGVja3Mgb24gb3ZlcmxvYWQgcmVwb3J0cyBmcm9tIHRoZWlyIHBlZXJzLCBhbmQgc28g
b24sIGNyZWF0aW5nIGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRyYW5z
aXRpdmUtdHJ1c3QgcmVxdWlyZW1lbnQgZXh0ZW5kaW5nIGZvciBwb3RlbnRpYWxseSBsb25n
IGNoYWlucyBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRyYW5zaXRp
dmUtdHJ1c3QgcmVxdWlyZW1lbnQgZXh0ZW5kaW5nIGZvciBwb3RlbnRpYWxseSBsb25nIGNo
YWlucyBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbm9kZXMuICBOZXR3
b3JrIG9wZXJhdG9ycyBtdXN0IGRldGVybWluZSBpZiB0aGlzIHRyYW5zaXRpdmUgdHJ1c3Q8
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBub2Rlcy4gIE5ldHdvcmsgb3Bl
cmF0b3JzIG11c3QgZGV0ZXJtaW5lIGlmIHRoaXMgdHJhbnNpdGl2ZSB0cnVzdDwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcmVxdWlyZW1lbnQgaXMgYWNjZXB0YWJsZSBm
b3IgdGhlaXIgZGVwbG95bWVudHMuICBOb2RlcyBzdXBwb3J0aW5nPC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVxdWlyZW1lbnQgaXMgYWNjZXB0YWJsZSBmb3IgdGhl
aXIgZGVwbG95bWVudHMuICBOb2RlcyBzdXBwb3J0aW5nPC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij4gICBEUk1QIE1VU1QgZ2l2ZSBvcGVyYXRvcnMgdGhlIGFiaWxpdHkgdG8g
c2VsZWN0IHdoaWNoIHBlZXJzIGFyZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PiAgIERSTVAgTVVTVCBnaXZlIG9wZXJhdG9ycyB0aGUgYWJpbGl0eSB0byBzZWxlY3Qgd2hp
Y2ggcGVlcnMgYXJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv
dHI+CiAgICAgIDx0ciBpZD0icGFydC0xMSIgY2xhc3M9ImNoYW5nZSIgPjx0ZD48L3RkPjx0
aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC0x
MSI+PGVtPiBwYWdlIDE0LCBsaW5lIDQxPHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3Nw
YW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFu
Z2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTExIj48ZW0+IHBhZ2UgMTcsIGxpbmUgNzxz
cGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm
dCI+ICAgSXQgaXMgZXhwZWN0ZWQgdGhhdCB3b3JrIG9uIGVuZC10by1lbmQgRGlhbWV0ZXIg
c2VjdXJpdHkgbWlnaHQgbWFrZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg
IEl0IGlzIGV4cGVjdGVkIHRoYXQgd29yayBvbiBlbmQtdG8tZW5kIERpYW1ldGVyIHNlY3Vy
aXR5IG1pZ2h0IG1ha2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGl0IGVh
c2llciB0byBlc3RhYmxpc2ggdHJ1c3QgaW4gbm9uLWFkamFjZW50IG5vZGVzIGZvciBEUk1Q
IHB1cnBvc2VzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGl0IGVhc2ll
ciB0byBlc3RhYmxpc2ggdHJ1c3QgaW4gbm9uLWFkamFjZW50IG5vZGVzIGZvciBEUk1QIHB1
cnBvc2VzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUmVhZGVycyBzaG91
bGQgYmUgcmVtaW5kZWQsIGhvd2V2ZXIsIHRoYXQgdGhlIERSTVAgbWVjaGFuaXNtIGFsbG93
czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFJlYWRlcnMgc2hvdWxkIGJl
IHJlbWluZGVkLCBob3dldmVyLCB0aGF0IHRoZSBEUk1QIG1lY2hhbmlzbSBhbGxvd3M8L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIERpYW1ldGVyIGFnZW50cyB0byBtb2Rp
ZnkgQVZQcyBpbiBleGlzdGluZyBtZXNzYWdlcyB0aGF0IGFyZTwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmlnaHQiPiAgIERpYW1ldGVyIGFnZW50cyB0byBtb2RpZnkgQVZQcyBpbiBl
eGlzdGluZyBtZXNzYWdlcyB0aGF0IGFyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm
dCI+ICAgb3JpZ2luYXRlZCBieSBvdGhlciBub2Rlcy4gIElmIGVuZC10by1lbmQgc2VjdXJp
dHkgaXMgZW5hYmxlZCwgdGhlcmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g
ICBvcmlnaW5hdGVkIGJ5IG90aGVyIG5vZGVzLiAgSWYgZW5kLXRvLWVuZCBzZWN1cml0eSBp
cyBlbmFibGVkLCB0aGVyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaXMg
YSByaXNrIHRoYXQgc3VjaCBtb2RpZmljYXRpb24gY291bGQgdmlvbGF0ZSBpbnRlZ3JpdHkg
cHJvdGVjdGlvbi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpcyBhIHJp
c2sgdGhhdCBzdWNoIG1vZGlmaWNhdGlvbiBjb3VsZCB2aW9sYXRlIGludGVncml0eSBwcm90
ZWN0aW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGRldGFpbHMg
b2YgdXNpbmcgYW55IGZ1dHVyZSBEaWFtZXRlciBlbmQtdG8tZW5kIHNlY3VyaXR5PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGRldGFpbHMgb2YgdXNpbmcgYW55
IGZ1dHVyZSBEaWFtZXRlciBlbmQtdG8tZW5kIHNlY3VyaXR5PC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij4gICBtZWNoYW5pc20gd2l0aCBEUk1QIHdpbGwgcmVxdWlyZSBjYXJl
ZnVsIGNvbnNpZGVyYXRpb24sIGFuZCBhcmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij4gICBtZWNoYW5pc20gd2l0aCBEUk1QIHdpbGwgcmVxdWlyZSBjYXJlZnVsIGNvbnNp
ZGVyYXRpb24sIGFuZCBhcmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGJl
eW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC48L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij4gICBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuPC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0i
ZGlmZjAwMjQiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxibG9jayI+MTxzcGFuIGNsYXNzPSJkZWxldGUiPjI8L3NwYW4+
LiAgQ29udHJpYnV0b3JzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjE8c3Bh
biBjbGFzcz0iaW5zZXJ0Ij4zPC9zcGFuPi4gIENvbnRyaWJ1dG9yczwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90
ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgZm9sbG93aW5nIHBlb3BsZSBj
b250cmlidXRlZCBzdWJzdGFudGlhbCBpZGVhcywgZmVlZGJhY2ssIGFuZDwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBmb2xsb3dpbmcgcGVvcGxlIGNvbnRyaWJ1
dGVkIHN1YnN0YW50aWFsIGlkZWFzLCBmZWVkYmFjaywgYW5kPC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij4gICBkaXNjdXNzaW9uIHRvIHRoaXMgZG9jdW1lbnQ6PC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGlzY3Vzc2lvbiB0byB0aGlzIGRvY3VtZW50
OjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICBKYW5l
dCBQLiAgR3VubjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIEphbmV0
IFAuICBHdW5uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+
CiAgICAgIDx0ciBpZD0iZGlmZjAwMjUiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+MTxzcGFuIGNsYXNzPSJk
ZWxldGUiPjM8L3NwYW4+LiAgUmVmZXJlbmNlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmJsb2NrIj4xPHNwYW4gY2xhc3M9Imluc2VydCI+NDwvc3Bhbj4uICBSZWZlcmVuY2VzPC90
ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBp
ZD0iZGlmZjAwMjYiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+MTxzcGFuIGNsYXNzPSJkZWxldGUiPjM8L3Nw
YW4+LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmJsb2NrIj4xPHNwYW4gY2xhc3M9Imluc2VydCI+NDwvc3Bhbj4uMS4gIE5vcm1hdGl2ZSBS
ZWZlcmVuY2VzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg
IFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRv
IEluZGljYXRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW1JGQzIxMTld
ICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGU8
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgUmVxdWlyZW1l
bnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij4gICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZD
IDIxMTksPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIERP
SSAxMC4xNzQ4Ny9SRkMyMTE5LCBNYXJjaCAxOTk3LDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzIxMTksIE1hcmNoIDE5
OTcsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICZsdDto
dHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjMjExOSZndDsuPC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAmbHQ7aHR0cDovL3d3dy5yZmMt
ZWRpdG9yLm9yZy9pbmZvL3JmYzIxMTkmZ3Q7LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i
bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij4gICBbUkZDNjczM10gIEZhamFyZG8sIFYuLCBFZC4sIEFya2tv
LCBKLiwgTG91Z2huZXksIEouLCBhbmQgRy4gWm9ybiw8L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij4gICBbUkZDNjczM10gIEZhamFyZG8sIFYuLCBFZC4sIEFya2tvLCBKLiwg
TG91Z2huZXksIEouLCBhbmQgRy4gWm9ybiw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPiAgICAgICAgICAgICAgRWQuLCAiRGlhbWV0ZXIgQmFzZSBQcm90b2NvbCIsIFJGQyA2
NzMzLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgRWQu
LCAiRGlhbWV0ZXIgQmFzZSBQcm90b2NvbCIsIFJGQyA2NzMzLDwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDNjczMywgT2N0
b2JlciAyMDEyLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg
ICAgRE9JIDEwLjE3NDg3L1JGQzY3MzMsIE9jdG9iZXIgMjAxMiw8L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgJmx0O2h0dHA6Ly93d3cucmZjLWVkaXRv
ci5vcmcvaW5mby9yZmM2NzMzJmd0Oy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij4gICAgICAgICAgICAgICZsdDtodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZj
NjczMyZndDsuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+
CiAgICAgIDx0ciBpZD0iZGlmZjAwMjciPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+MTxzcGFuIGNsYXNzPSJk
ZWxldGUiPjM8L3NwYW4+LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzPC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjE8c3BhbiBjbGFzcz0iaW5zZXJ0Ij40PC9zcGFuPi4y
LiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm
dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij4gICBbUkZDNzY4M10gIEtvcmhvbmVuLCBKLiwgRWQuLCBEb25vdmFu
LCBTLiwgRWQuLCBDYW1wYmVsbCwgQi4sIGFuZCBMLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPiAgIFtSRkM3NjgzXSAgS29yaG9uZW4sIEouLCBFZC4sIERvbm92YW4sIFMu
LCBFZC4sIENhbXBiZWxsLCBCLiwgYW5kIEwuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs
ZWZ0Ij4gICAgICAgICAgICAgIE1vcmFuZCwgIkRpYW1ldGVyIE92ZXJsb2FkIEluZGljYXRp
b24gQ29udmV5YW5jZSIsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg
ICAgICAgICBNb3JhbmQsICJEaWFtZXRlciBPdmVybG9hZCBJbmRpY2F0aW9uIENvbnZleWFu
Y2UiLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBSRkMg
NzY4MywgRE9JIDEwLjE3NDg3L1JGQzc2ODMsIE9jdG9iZXIgMjAxNSw8L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIFJGQyA3NjgzLCBET0kgMTAuMTc0
ODcvUkZDNzY4MywgT2N0b2JlciAyMDE1LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm
dCI+ICAgICAgICAgICAgICAmbHQ7aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3Jm
Yzc2ODMmZ3Q7LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg
ICAgJmx0O2h0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3NjgzJmd0Oy48L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1M2YV0gICAgICAz
R1BQLCAiRXZvbHZlZCBQYWNrZXQgU3lzdGVtIChFUFMpOyBNb2JpbGl0eSBNYW5hZ2VtZW50
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW1M2YV0gICAgICAzR1BQLCAi
RXZvbHZlZCBQYWNrZXQgU3lzdGVtIChFUFMpOyBNb2JpbGl0eSBNYW5hZ2VtZW50PC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIEVudGl0eSAoTU1FKSBh
bmQgU2VydmluZyBHUFJTIFN1cHBvcnQgTm9kZSAoU0dTTikgcmVsYXRlZDwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgRW50aXR5IChNTUUpIGFuZCBT
ZXJ2aW5nIEdQUlMgU3VwcG9ydCBOb2RlIChTR1NOKSByZWxhdGVkPC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIGludGVyZmFjZXMgYmFzZWQgb24gRGlh
bWV0ZXIgcHJvdG9jb2wiLCAzR1BQIFRTIDI5LjI3MjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPiAgICAgICAgICAgICAgaW50ZXJmYWNlcyBiYXNlZCBvbiBEaWFtZXRlciBw
cm90b2NvbCIsIDNHUFAgVFMgMjkuMjcyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0
Ij4gICAgICAgICAgICAgIDEwLjguMCwgSnVuZSAyMDEzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgMTAuOC4wLCBKdW5lIDIwMTMuPC90ZD48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgoKICAgICA8dHI+PHRkPjwvdGQ+PHRkIGNsYXNz
PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZD48L3Rk
PjwvdHI+CiAgICAgPHRyIGlkPSJlbmQiIGJnY29sb3I9ImdyYXkiPjx0aCBjb2xzcGFuPSI1
IiBhbGlnbj0iY2VudGVyIj4mbmJzcDtFbmQgb2YgY2hhbmdlcy4gMjcgY2hhbmdlIGJsb2Nr
cy4mbmJzcDs8L3RoPjwvdHI+CiAgICAgPHRyIGNsYXNzPSJzdGF0cyI+PHRkPjwvdGQ+PHRo
PjxpPjcwIGxpbmVzIGNoYW5nZWQgb3IgZGVsZXRlZDwvaT48L3RoPjx0aD48aT4gPC9pPjwv
dGg+PHRoPjxpPjE3NCBsaW5lcyBjaGFuZ2VkIG9yIGFkZGVkPC9pPjwvdGg+PHRkPjwvdGQ+
PC90cj4KICAgICA8dHI+PHRkIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiIGNsYXNzPSJz
bWFsbCI+PGJyLz5UaGlzIGh0bWwgZGlmZiB3YXMgcHJvZHVjZWQgYnkgcmZjZGlmZiAxLjQ1
LiBUaGUgbGF0ZXN0IHZlcnNpb24gaXMgYXZhaWxhYmxlIGZyb20gPGEgaHJlZj0iaHR0cDov
L3d3dy50b29scy5pZXRmLm9yZy90b29scy9yZmNkaWZmLyIgPmh0dHA6Ly90b29scy5pZXRm
Lm9yZy90b29scy9yZmNkaWZmLzwvYT4gPC90ZD48L3RyPgogICA8L3RhYmxlPgogICA8L2Jv
ZHk+CiAgIDwvaHRtbD4K
--------------4B478905A350D4EB3DF41D03--


From nobody Thu May 19 08:55:26 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 5EFC612D530; Thu, 19 May 2016 08:55:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160519155522.17424.94047.idtracker@ietfa.amsl.com>
Date: Thu, 19 May 2016 08:55:22 -0700
Archived-At: 
Cc: dime@ietf.org
Subject: [Dime] I-D Action: draft-ietf-dime-agent-overload-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: Thu, 19 May 2016 15:55:22 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Diameter Maintenance and Extensions of the IETF.

        Title           : Diameter Agent Overload and the Peer Overload Report
        Author          : Steve Donovan
	Filename        : draft-ietf-dime-agent-overload-05.txt
	Pages           : 18
	Date            : 2016-05-19

Abstract:
   This specification documents an extension to the Diameter Overload
   Indication Conveyance (DOIC) [RFC7683] base solution.  The extension
   defines the Peer overload report type.  The initial use case for the
   Peer report is the handling of occurrences of overload of a Diameter
   agent.

Requirements

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dime-agent-overload-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-agent-overload-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu May 19 08:58: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 75C6512D570 for ; Thu, 19 May 2016 08:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level: 
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 F7lPg1f8dfmd for ; Thu, 19 May 2016 08:58:45 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 4927F12D17D for ; Thu, 19 May 2016 08:58:45 -0700 (PDT)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:53655 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 1b3QLQ-0022zm-FU for dime@ietf.org; Thu, 19 May 2016 08:58:45 -0700
To: "dime@ietf.org" 
From: Steve Donovan 
Message-ID: <4f052cc5-34a8-8cf9-87e5-7fb05078ffbd@usdonovans.com>
Date: Thu, 19 May 2016 10:58:39 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------7E952F8A3BCFA22B2B8CB750"
X-OutGoing-Spam-Status: No, score=-1.0
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: [Dime] New version of Agent Overload (Peer report) I-D
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, 19 May 2016 15:58:48 -0000

This is a multi-part message in MIME format.
--------------7E952F8A3BCFA22B2B8CB750
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

All,

I have posted version -05 of the Agent Overload draft.  The only change 
is to clean up the SourceID AVP name and description.

I have attached a diff file to this email.

This should make the draft ready for WGLC.

Regards,

Steve


--------------7E952F8A3BCFA22B2B8CB750
Content-Type: text/html; charset=UTF-8;
 name="Diff_ draft-ietf-dime-agent-overload-04.txt -
 draft-ietf-dime-agent-overload-05.txt.html"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename*0="Diff_ draft-ietf-dime-agent-overload-04.txt - draft-ietf-dim";
 filename*1="e-agent-overload-05.txt.html"

CjwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRp
b25hbC8vRU4iICJodHRwOi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFu
c2l0aW9uYWwuZHRkIj4gCjwhLS0gR2VuZXJhdGVkIGJ5IHJmY2RpZmYgMS40NTogcmZjZGlm
ZiAgLS0+IAo8IS0tIDwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgSFRNTCA0
LjAxIFRyYW5zaXRpb25hbCIgPiAtLT4KPCEtLSBTeXN0ZW06IExpbnV4IHppbmZhbmRlbCAz
LjIuMC00LWFtZDY0ICMxIFNNUCBEZWJpYW4gMy4yLjY4LTErZGViN3UyIHg4Nl82NCBHTlUv
TGludXggLS0+IAo8IS0tIFVzaW5nIGF3azogL3Vzci9iaW4vZ2F3azogR05VIEF3ayA0LjAu
MSAtLT4gCjwhLS0gVXNpbmcgZGlmZjogL3Vzci9iaW4vZGlmZjogZGlmZiAoR05VIGRpZmZ1
dGlscykgMy4yIC0tPiAKPCEtLSBVc2luZyB3ZGlmZjogL3Vzci9iaW4vd2RpZmY6IHdkaWZm
IChHTlUgd2RpZmYpIDEuMS4yIC0tPiAKPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3Jn
LzE5OTkveGh0bWwiPiAKPGhlYWQ+IAogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlw
ZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVURi04IiAvPiAKICA8bWV0YSBodHRw
LWVxdWl2PSJDb250ZW50LVN0eWxlLVR5cGUiIGNvbnRlbnQ9InRleHQvY3NzIiAvPiAKICA8
dGl0bGU+RGlmZjogZHJhZnQtaWV0Zi1kaW1lLWFnZW50LW92ZXJsb2FkLTA0LnR4dCAtIGRy
YWZ0LWlldGYtZGltZS1hZ2VudC1vdmVybG9hZC0wNS50eHQ8L3RpdGxlPiAKICA8c3R5bGUg
dHlwZT0idGV4dC9jc3MiPiAKICAgIGJvZHkgICAgeyBtYXJnaW46IDAuNGV4OyBtYXJnaW4t
cmlnaHQ6IGF1dG87IH0gCiAgICB0ciAgICAgIHsgfSAKICAgIHRkICAgICAgeyB3aGl0ZS1z
cGFjZTogcHJlOyBmb250LWZhbWlseTogbW9ub3NwYWNlOyB2ZXJ0aWNhbC1hbGlnbjogdG9w
OyBmb250LXNpemU6IDAuODZlbTt9IAogICAgdGggICAgICB7IGZvbnQtc2l6ZTogMC44NmVt
OyB9IAogICAgLnNtYWxsICB7IGZvbnQtc2l6ZTogMC42ZW07IGZvbnQtc3R5bGU6IGl0YWxp
YzsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgfSAKICAg
IC5sZWZ0ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLnJpZ2h0ICB7IGJh
Y2tncm91bmQtY29sb3I6ICNGRkY7IH0gCiAgICAuZGlmZiAgIHsgYmFja2dyb3VuZC1jb2xv
cjogI0NDRjsgfSAKICAgIC5sYmxvY2sgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQkZCOyB9IAog
ICAgLnJibG9jayB7IGJhY2tncm91bmQtY29sb3I6ICNGRjg7IH0gCiAgICAuaW5zZXJ0IHsg
YmFja2dyb3VuZC1jb2xvcjogIzhGRjsgfSAKICAgIC5kZWxldGUgeyBiYWNrZ3JvdW5kLWNv
bG9yOiAjQUNGOyB9IAogICAgLnZvaWQgICB7IGJhY2tncm91bmQtY29sb3I6ICNGRkI7IH0g
CiAgICAuY29udCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5saW5lYnIg
eyBiYWNrZ3JvdW5kLWNvbG9yOiAjQUFBOyB9IAogICAgLmxpbmVubyB7IGNvbG9yOiByZWQ7
IGJhY2tncm91bmQtY29sb3I6ICNGRkY7IGZvbnQtc2l6ZTogMC43ZW07IHRleHQtYWxpZ246
IHJpZ2h0OyBwYWRkaW5nOiAwIDJweDsgfSAKICAgIC5lbGlwc2lzeyBiYWNrZ3JvdW5kLWNv
bG9yOiAjQUFBOyB9IAogICAgLmxlZnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRERE
OyB9IAogICAgLnJpZ2h0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAg
IC5sYmxvY2sgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOUQ5OyB9IAogICAgLnJibG9j
ayAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNERDY7IH0gCiAgICAuaW5zZXJ0IC5jb250
IHsgYmFja2dyb3VuZC1jb2xvcjogIzBERDsgfSAKICAgIC5kZWxldGUgLmNvbnQgeyBiYWNr
Z3JvdW5kLWNvbG9yOiAjOEFEOyB9IAogICAgLnN0YXRzLCAuc3RhdHMgdGQsIC5zdGF0cyB0
aCB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IHBhZGRpbmc6IDJweCAwOyB9IAogICAgc3Bh
bi5oaWRlIHsgZGlzcGxheTogbm9uZTsgY29sb3I6ICNhYWE7fSAgICBhOmhvdmVyIHNwYW4g
eyBkaXNwbGF5OiBpbmxpbmU7IH0gICAgdHIuY2hhbmdlIHsgYmFja2dyb3VuZC1jb2xvcjog
Z3JheTsgfSAKICAgIHRyLmNoYW5nZSBhIHsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBjb2xv
cjogYmxhY2sgfSAKICA8L3N0eWxlPiAKICAgICA8c2NyaXB0Pgp2YXIgY2h1bmtfaW5kZXgg
PSAwOwp2YXIgb2xkX2NodW5rID0gbnVsbDsKCmZ1bmN0aW9uIGZvcm1hdF9jaHVuayhpbmRl
eCkgewogICAgdmFyIHByZWZpeCA9ICJkaWZmIjsKICAgIHZhciBzdHIgPSBpbmRleC50b1N0
cmluZygpOwogICAgZm9yICh4PTA7IHg8KDQtc3RyLmxlbmd0aCk7ICsreCkgewogICAgICAg
IHByZWZpeCs9JzAnOwogICAgfQogICAgcmV0dXJuIHByZWZpeCArIHN0cjsKfQoKZnVuY3Rp
b24gZmluZF9jaHVuayhuKXsKICAgIHJldHVybiBkb2N1bWVudC5xdWVyeVNlbGVjdG9yKCd0
cltpZCQ9IicgKyBuICsgJyJdJyk7Cn0KCmZ1bmN0aW9uIGNoYW5nZV9jaHVuayhvZmZzZXQp
IHsKICAgIHZhciBpbmRleCA9IGNodW5rX2luZGV4ICsgb2Zmc2V0OwogICAgdmFyIG5ld19z
dHI7CiAgICB2YXIgbmV3X2NodW5rOwoKICAgIG5ld19zdHIgPSBmb3JtYXRfY2h1bmsoaW5k
ZXgpOwogICAgbmV3X2NodW5rID0gZmluZF9jaHVuayhuZXdfc3RyKTsKICAgIGlmICghbmV3
X2NodW5rKSB7CiAgICAgICAgcmV0dXJuOwogICAgfQogICAgaWYgKG9sZF9jaHVuaykgewog
ICAgICAgIG9sZF9jaHVuay5zdHlsZS5vdXRsaW5lID0gIiI7CiAgICB9CiAgICBvbGRfY2h1
bmsgPSBuZXdfY2h1bms7CiAgICBvbGRfY2h1bmsuc3R5bGUub3V0bGluZSA9ICIxcHggc29s
aWQgcmVkIjsKICAgIHdpbmRvdy5sb2NhdGlvbi5oYXNoID0gIiMiICsgbmV3X3N0cjsKICAg
IHdpbmRvdy5zY3JvbGxCeSgwLC0xMDApOwogICAgY2h1bmtfaW5kZXggPSBpbmRleDsKfQoK
ZG9jdW1lbnQub25rZXlkb3duID0gZnVuY3Rpb24oZSkgewogICAgc3dpdGNoIChlLmtleUNv
ZGUpIHsKICAgIGNhc2UgNzg6CiAgICAgICAgY2hhbmdlX2NodW5rKDEpOwogICAgICAgIGJy
ZWFrOwogICAgY2FzZSA4MDoKICAgICAgICBjaGFuZ2VfY2h1bmsoLTEpOwogICAgICAgIGJy
ZWFrOwogICAgfQp9OwogICA8L3NjcmlwdD4gCjwvaGVhZD4gCjxib2R5ID4gCiAgPHRhYmxl
IGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj4gCiAgPHRyIGlk
PSJwYXJ0LTEiIGJnY29sb3I9Im9yYW5nZSI+PHRoPjwvdGg+PHRoPjxhIGhyZWY9Ii9yZmNk
aWZmP3VybDI9ZHJhZnQtaWV0Zi1kaW1lLWFnZW50LW92ZXJsb2FkLTA0LnR4dCIgc3R5bGU9
ImNvbG9yOiMwMDg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Jmx0OzwvYT4mbmJzcDs8YSBo
cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kaW1lLWFnZW50
LW92ZXJsb2FkLTA0LnR4dCIgc3R5bGU9ImNvbG9yOiMwMDgiPmRyYWZ0LWlldGYtZGltZS1h
Z2VudC1vdmVybG9hZC0wNC50eHQ8L2E+Jm5ic3A7PC90aD48dGg+IDwvdGg+PHRoPiZuYnNw
OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRpbWUt
YWdlbnQtb3ZlcmxvYWQtMDUudHh0IiBzdHlsZT0iY29sb3I6IzAwOCI+ZHJhZnQtaWV0Zi1k
aW1lLWFnZW50LW92ZXJsb2FkLTA1LnR4dDwvYT4mbmJzcDs8YSBocmVmPSIvcmZjZGlmZj91
cmwxPWRyYWZ0LWlldGYtZGltZS1hZ2VudC1vdmVybG9hZC0wNS50eHQiIHN0eWxlPSJjb2xv
cjojMDA4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPiZndDs8L2E+PC90aD48dGg+PC90aD48
L3RyPiAKICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm
dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij5EaWFtZXRlciBNYWludGVuYW5jZSBhbmQgRXh0ZW5zaW9ucyAoRElN
RSkgICAgICAgICAgICAgICAgICAgIFMuIERvbm92YW48L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij5EaWFtZXRlciBNYWludGVuYW5jZSBhbmQgRXh0ZW5zaW9ucyAoRElNRSkg
ICAgICAgICAgICAgICAgICAgIFMuIERvbm92YW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9
ImxlZnQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIE9yYWNsZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIE9yYWNsZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90
cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwMSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj5JbnRlbmRlZCBzdGF0
dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgPHNwYW4gY2xh
c3M9ImRlbGV0ZSI+TWFyY2ggMTgsPC9zcGFuPiAyMDE2PC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyYmxvY2siPkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPk1heSAxOSw8L3NwYW4+
IDIwMTY8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+RXhwaXJlczogPHNwYW4g
Y2xhc3M9ImRlbGV0ZSI+U2VwdGVtYmVyIDE5LDwvc3Bhbj4gMjAxNjwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmJsb2NrIj5FeHBpcmVzOiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5Ob3Zl
bWJlciAyMCw8L3NwYW4+IDIwMTY8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz
cz0ibGVmdCI+ICAgICAgICAgIERpYW1ldGVyIEFnZW50IE92ZXJsb2FkIGFuZCB0aGUgUGVl
ciBPdmVybG9hZCBSZXBvcnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg
ICAgICAgRGlhbWV0ZXIgQWdlbnQgT3ZlcmxvYWQgYW5kIHRoZSBQZWVyIE92ZXJsb2FkIFJl
cG9ydDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJk
aWZmMDAwMiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtZGlt
ZS1hZ2VudC1vdmVybG9hZC0wPHNwYW4gY2xhc3M9ImRlbGV0ZSI+NDwvc3Bhbj4udHh0PC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgZHJhZnQt
aWV0Zi1kaW1lLWFnZW50LW92ZXJsb2FkLTA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij41PC9zcGFu
Pi50eHQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QWJzdHJh
Y3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5BYnN0cmFjdDwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIHNwZWNpZmljYXRpb24g
ZG9jdW1lbnRzIGFuIGV4dGVuc2lvbiB0byB0aGUgRGlhbWV0ZXIgT3ZlcmxvYWQ8L3RkPjx0
ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIHNwZWNpZmljYXRpb24gZG9jdW1l
bnRzIGFuIGV4dGVuc2lvbiB0byB0aGUgRGlhbWV0ZXIgT3ZlcmxvYWQ8L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEluZGljYXRpb24gQ29udmV5YW5jZSAoRE9JQykgW1JG
Qzc2ODNdIGJhc2Ugc29sdXRpb24uICBUaGUgZXh0ZW5zaW9uPC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+ICAgSW5kaWNhdGlvbiBDb252ZXlhbmNlIChET0lDKSBbUkZDNzY4
M10gYmFzZSBzb2x1dGlvbi4gIFRoZSBleHRlbnNpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPiAgIGRlZmluZXMgdGhlIFBlZXIgb3ZlcmxvYWQgcmVwb3J0IHR5cGUuICBU
aGUgaW5pdGlhbCB1c2UgY2FzZSBmb3IgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
aWdodCI+ICAgZGVmaW5lcyB0aGUgUGVlciBvdmVybG9hZCByZXBvcnQgdHlwZS4gIFRoZSBp
bml0aWFsIHVzZSBjYXNlIGZvciB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi
PiAgIFBlZXIgcmVwb3J0IGlzIHRoZSBoYW5kbGluZyBvZiBvY2N1cnJlbmNlcyBvZiBvdmVy
bG9hZCBvZiBhIERpYW1ldGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg
UGVlciByZXBvcnQgaXMgdGhlIGhhbmRsaW5nIG9mIG9jY3VycmVuY2VzIG9mIG92ZXJsb2Fk
IG9mIGEgRGlhbWV0ZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFnZW50
LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFnZW50LjwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5SZXF1aXJlbWVudHM8L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5SZXF1aXJlbWVudHM8L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTIiIGNsYXNz
PSJjaGFuZ2UiID48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwv
c21hbGw+PGEgaHJlZj0iI3BhcnQtMiI+PGVtPiBwYWdlIDEsIGxpbmUgNDA8c3BhbiBjbGFz
cz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNt
YWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtMiI+PGVt
PiBwYWdlIDEsIGxpbmUgNDA8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2Vt
PjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBk
b2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nPC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50
cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9
ImxlZnQiPiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBt
YXkgYWxzbyBkaXN0cmlidXRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg
VGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRp
c3RyaWJ1dGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHdvcmtpbmcgZG9j
dW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJu
ZXQtPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgd29ya2luZyBkb2N1bWVu
dHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC08
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIERyYWZ0cyBpcyBhdCBodHRwOi8v
ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLjwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmlnaHQiPiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxp
ZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBm
b3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBv
dGhlciBkb2N1bWVudHMgYXQgYW55PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+
ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVy
IGRvY3VtZW50cyBhdCBhbnk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRp
bWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVm
ZXJlbmNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGltZS4gIEl0IGlz
IGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2U8L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhl
bSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiI8L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJpZ2h0Ij4gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBh
cyAid29yayBpbiBwcm9ncmVzcy4iPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDMiPjx0ZD48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg
VGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiA8c3BhbiBjbGFzcz0iZGVsZXRl
Ij5TZXB0ZW1iZXIgMTk8L3NwYW4+LCAyMDE2LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmJsb2NrIj4gICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIDxzcGFuIGNs
YXNzPSJpbnNlcnQiPk5vdmVtYmVyIDIwPC9zcGFuPiwgMjAxNi48L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Q29weXJpZ2h0IE5vdGljZTwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkNvcHlyaWdodCBOb3RpY2U8L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ29weXJpZ2h0IChjKSAyMDE2IElFVEYg
VHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+ICAgQ29weXJpZ2h0IChjKSAyMDE2IElFVEYgVHJ1c3QgYW5k
IHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz
PSJsZWZ0Ij4gICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC48L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkb2N1bWVudCBhdXRob3JzLiAgQWxs
IHJpZ2h0cyByZXNlcnZlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i
bGVmdCI+ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElF
VEYgVHJ1c3QncyBMZWdhbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRo
aXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3Mg
TGVnYWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFByb3Zpc2lvbnMgUmVs
YXRpbmcgdG8gSUVURiBEb2N1bWVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij4gICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzPC90ZD48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5z
ZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij4gICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBp
biBlZmZlY3Qgb24gdGhlIGRhdGUgb2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi
PiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNl
IGRvY3VtZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHB1YmxpY2F0
aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50czwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIg
aWQ9InBhcnQtMyIgY2xhc3M9ImNoYW5nZSIgPjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBp
bmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC0zIj48ZW0+IHBhZ2UgMiwg
bGluZSAzOTxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+
PHRoPiA8L3RoPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBo
cmVmPSIjcGFydC0zIj48ZW0+IHBhZ2UgMiwgbGluZSAzOTxzcGFuIGNsYXNzPSJoaWRlIj4g
JnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIDUuMi4yLiAg
UmVwb3J0aW5nIE5vZGUgTWFpbnRlbmFuY2Ugb2YgUGVlciBSZXBvcnQgT0NTIC4gLiAuIC4g
IDExPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgIDUuMi4yLiAgUmVw
b3J0aW5nIE5vZGUgTWFpbnRlbmFuY2Ugb2YgUGVlciBSZXBvcnQgT0NTIC4gLiAuIC4gIDEx
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgNS4yLjMuICBSZWFjdGlu
ZyBOb2RlIE1haW50ZW5hbmNlIG9mIFBlZXIgUmVwb3J0IE9DUyAgLiAuIC4gLiAgMTE8L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgNS4yLjMuICBSZWFjdGluZyBO
b2RlIE1haW50ZW5hbmNlIG9mIFBlZXIgUmVwb3J0IE9DUyAgLiAuIC4gLiAgMTE8L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICA1LjIuNC4gIFBlZXIgUmVwb3J0IFJl
cG9ydGluZyBOb2RlIEJlaGF2aW9yIC4gLiAuIC4gLiAuIC4gLiAuICAxMzwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICA1LjIuNC4gIFBlZXIgUmVwb3J0IFJlcG9y
dGluZyBOb2RlIEJlaGF2aW9yIC4gLiAuIC4gLiAuIC4gLiAuICAxMzwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIDUuMi41LiAgUGVlciBSZXBvcnQgUmVhY3Rpbmcg
Tm9kZSBCZWhhdmlvciAgLiAuIC4gLiAuIC4gLiAuIC4gIDEzPC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+ICAgICAgIDUuMi41LiAgUGVlciBSZXBvcnQgUmVhY3RpbmcgTm9k
ZSBCZWhhdmlvciAgLiAuIC4gLiAuIC4gLiAuIC4gIDEzPC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij4gICA2LiAgUGVlciBSZXBvcnQgQVZQcyAgLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij4gICA2LiAgUGVlciBSZXBvcnQgQVZQcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPiAgICAgNi4xLiAgT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuICAxNDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PiAgICAgNi4xLiAgT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuICAxNDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K
ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg
ICAgIDYuMS4xLiAgT0MtRmVhdHVyZS1WZWN0b3IgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gIDE0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg
IDYuMS4xLiAgT0MtRmVhdHVyZS1WZWN0b3IgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gIDE0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgNi4x
LjIuICBPQy1QZWVyLUFsZ28gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAgMTU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgNi4xLjIu
ICBPQy1QZWVyLUFsZ28gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAgMTU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgNi4yLiAgT0MtT0xS
IEFWUCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx
NTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgNi4yLiAgT0MtT0xSIEFW
UCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNTwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIDYuMi4xLiAgT0MtUmVwb3J0
LVR5cGUgQVZQICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE1PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgIDYuMi4xLiAgT0MtUmVwb3J0LVR5
cGUgQVZQICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE1PC90ZD48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA0Ij48dGQ+
PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz
PSJsYmxvY2siPiAgICAgNi4zLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+T0MtU291cmNlSUQ8
L3NwYW4+IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg
MTY8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICA2LjMuICA8c3BhbiBj
bGFzcz0iaW5zZXJ0Ij5Tb3VyY2VJRCAgLjwvc3Bhbj4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i
bGVmdCI+ICAgICA2LjQuICBBdHRyaWJ1dGUgVmFsdWUgUGFpciBmbGFnIHJ1bGVzIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE2PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo
dCI+ICAgICA2LjQuICBBdHRyaWJ1dGUgVmFsdWUgUGFpciBmbGFnIHJ1bGVzIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gIDE2PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g
ICA3LiAgSUFOQSAgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAgMTY8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA3
LiAgSUFOQSAgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAgMTY8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgNy4x
LiAgQVZQIGNvZGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuICAxNjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgNy4xLiAg
QVZQIGNvZGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuICAxNjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICA3LjIuICBOZXcg
cmVnaXN0cmllcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
IDE2PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICA3LjIuICBOZXcgcmVn
aXN0cmllcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE2
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA4LiAgU2VjdXJpdHkgQ29uc2lk
ZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTc8L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA4LiAgU2VjdXJpdHkgQ29uc2lkZXJh
dGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTc8L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDkuICBBY2tub3dsZWRnZW1lbnRzICAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNzwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDkuICBBY2tub3dsZWRnZW1lbnRzICAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNzwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgMTAuIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE3PC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+ICAgMTAuIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE3PC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij4gICBBdXRob3IncyBBZGRyZXNzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij4gICBBdXRob3IncyBBZGRyZXNzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+MS4gIEludHJvZHVjdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPjEuICBJbnRyb2R1Y3Rpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTQiIGNsYXNzPSJjaGFuZ2Ui
ID48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEg
aHJlZj0iI3BhcnQtNCI+PGVtPiBwYWdlIDgsIGxpbmUgMzY8c3BhbiBjbGFzcz0iaGlkZSI+
ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBw
aW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtNCI+PGVtPiBwYWdlIDgs
IGxpbmUgMzY8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3Ro
Pjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxlZnQiPiAgIGFuIE9DLUZlYXR1cmUtVmVjdG9yIEFWUCB3aXRoIHRoZSBPQ19Q
RUVSX1JFUE9SVCBiaXQgc2V0LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg
IGFuIE9DLUZlYXR1cmUtVmVjdG9yIEFWUCB3aXRoIHRoZSBPQ19QRUVSX1JFUE9SVCBiaXQg
c2V0LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg
ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBO
b3RlOiBUaGUgc2VuZGVyIG9mIGEgcmVxdWVzdCBjYW4gYmUgYSBEaWFtZXRlciBDbGllbnQg
b3IgRGlhbWV0ZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBOb3Rl
OiBUaGUgc2VuZGVyIG9mIGEgcmVxdWVzdCBjYW4gYmUgYSBEaWFtZXRlciBDbGllbnQgb3Ig
RGlhbWV0ZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIFNlcnZlciB0
aGF0IG9yaWdpbmF0ZXMgdGhlIERpYW10ZXIgcmVxdWVzdCBvciBhIERpYW1ldGVyIEFnZW50
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgU2VydmVyIHRoYXQgb3Jp
Z2luYXRlcyB0aGUgRGlhbXRlciByZXF1ZXN0IG9yIGEgRGlhbWV0ZXIgQWdlbnQ8L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHRoYXQgcmVsYXlzIHRoZSByZXF1ZXN0
LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIHRoYXQgcmVsYXlzIHRo
ZSByZXF1ZXN0LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g
ICBTdXBwb3J0IGZvciB0aGUgT0NfUEVFUl9SRVBPUlQgZmVhdHVyZSBkb2VzIG5vdCBpbXBh
Y3QgdGhlIGxvZ2ljIGZvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFN1
cHBvcnQgZm9yIHRoZSBPQ19QRUVSX1JFUE9SVCBmZWF0dXJlIGRvZXMgbm90IGltcGFjdCB0
aGUgbG9naWMgZm9yPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzZXR0aW5n
IG9mIG90aGVyIGZlYXR1cmUgYml0cyBpbiB0aGUgT0MtRmVhdHVyZS1WZWN0b3IgQVZQLjwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNldHRpbmcgb2Ygb3RoZXIgZmVh
dHVyZSBiaXRzIGluIHRoZSBPQy1GZWF0dXJlLVZlY3RvciBBVlAuPC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFdoZW4gc2VuZGluZyBhIHJlcXVlc3Qg
YSBET0lDIG5vZGUgdGhhdCBzdXBwb3J0cyB0aGUgT0NfUEVFUl9SRVBPUlQ8L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBXaGVuIHNlbmRpbmcgYSByZXF1ZXN0IGEgRE9J
QyBub2RlIHRoYXQgc3VwcG9ydHMgdGhlIE9DX1BFRVJfUkVQT1JUPC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA1Ij48dGQ+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv
Y2siPiAgIGZlYXR1cmUgTVVTVCBpbmNsdWRlIDxzcGFuIGNsYXNzPSJkZWxldGUiPmFuIE9D
LVNvdXJjZUlEPC9zcGFuPiBBVlAgaW4gdGhlIE9DLVN1cHBvcnRlZC1GZWF0dXJlczwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBmZWF0dXJlIE1VU1QgaW5jbHVkZSA8
c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hIFNvdXJjZUlEPC9zcGFuPiBBVlAgaW4gdGhlIE9DLVN1
cHBvcnRlZC1GZWF0dXJlcyBBVlA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+
ICAgQVZQIHdpdGggaXRzIG93biBEaWFtZXRlcklkZW50aXR5LjwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmJsb2NrIj4gICB3aXRoIGl0cyBvd24gRGlhbWV0ZXJJZGVudGl0eS48L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgTm90ZTogVGhp
cyBhbGxvd3MgdGhlIERPSUMgbm9kZXMgaW4gdGhlIHBhdGggb2YgdGhlIHJlcXVlc3QgdG88
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBOb3RlOiBUaGlzIGFsbG93
cyB0aGUgRE9JQyBub2RlcyBpbiB0aGUgcGF0aCBvZiB0aGUgcmVxdWVzdCB0bzwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgZGV0ZXJtaW5lIGlmIHRoZSBpbmRpY2F0
aW9uIG9mIHN1cHBvcnQgY2FtZSBmcm9tIGEgRGlhbWV0ZXIgcGVlcjwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGRldGVybWluZSBpZiB0aGUgaW5kaWNhdGlvbiBv
ZiBzdXBwb3J0IGNhbWUgZnJvbSBhIERpYW1ldGVyIHBlZXI8L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxlZnQiPiAgICAgIG9yIGlmIHRoZSByZXF1ZXN0IHRyYXZlcnNlZCBhIG5vZGUg
dGhhdCBkb2VzIG5vdCBzdXBwb3J0IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPiAgICAgIG9yIGlmIHRoZSByZXF1ZXN0IHRyYXZlcnNlZCBhIG5vZGUgdGhhdCBkb2Vz
IG5vdCBzdXBwb3J0IHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg
T0NfUEVFUl9SRVBPUlQgZmVhdHVyZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij4gICAgICBPQ19QRUVSX1JFUE9SVCBmZWF0dXJlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz
cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA2Ij48dGQ+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs
YmxvY2siPiAgIFdoZW4gcmVsYXlpbmcgYSByZXF1ZXN0IHRoYXQgaW5jbHVkZXMgYTxzcGFu
IGNsYXNzPSJkZWxldGUiPm4gT0MtPC9zcGFuPlNvdXJjZUlEIEFWUCBpbiB0aGUgT0MtPC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFdoZW4gcmVsYXlpbmcgYSByZXF1
ZXN0IHRoYXQgaW5jbHVkZXMgYTxzcGFuIGNsYXNzPSJpbnNlcnQiPiA8L3NwYW4+U291cmNl
SUQgQVZQIGluIHRoZSBPQy08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFN1
cHBvcnRlZC1GZWF0dXJlcyBBVlAsIGEgRE9JQyBub2RlIHRoYXQgc3VwdXBvcnRzIHRoZSBP
Q19QRUVSX1JFUE9SVDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFN1cHBv
cnRlZC1GZWF0dXJlcyBBVlAsIGEgRE9JQyBub2RlIHRoYXQgc3VwdXBvcnRzIHRoZSBPQ19Q
RUVSX1JFUE9SVDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy
IGlkPSJkaWZmMDAwNyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBmZWF0dXJlIG11c3QgcmVtb3ZlIHRo
ZSByZWNlaXZlZCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5PQy1Tb3VyY2VJRDwvc3Bhbj4gQVZQ
IGFuZCByZXBsYWNlIGl0IHdpdGg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+
ICAgZmVhdHVyZSBtdXN0IHJlbW92ZSB0aGUgcmVjZWl2ZWQgPHNwYW4gY2xhc3M9Imluc2Vy
dCI+U291cmNlSUQ8L3NwYW4+IEFWUCBhbmQgcmVwbGFjZSBpdCB3aXRoIDxzcGFuIGNsYXNz
PSJpbnNlcnQiPmE8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg
IDxzcGFuIGNsYXNzPSJkZWxldGUiPmFuIE9DLVNvdXJjZUlEPC9zcGFuPiBBVlAgY29udGFp
bmluZyBpdHMgb3duIERpYW1ldGVyIGlkZW50aXR5LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBTb3VyY2VJRDwvc3Bhbj4gQVZQ
IGNvbnRhaW5pbmcgaXRzIG93biBEaWFtZXRlciBpZGVudGl0eS48L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+NS4xLjIuICBSZXBvcnRpbmcgTm9kZSBCZWhh
dmlvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjUuMS4yLiAgUmVwb3J0aW5n
IE5vZGUgQmVoYXZpb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm
dCI+ICAgV2hlbiByZWNlaXZpbmcgYSByZXF1ZXN0IGEgRE9JQyBub2RlIHRoYXQgc3VwcG9y
dHMgdGhlIE9DX1BFRVJfUkVQT1JUPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+
ICAgV2hlbiByZWNlaXZpbmcgYSByZXF1ZXN0IGEgRE9JQyBub2RlIHRoYXQgc3VwcG9ydHMg
dGhlIE9DX1BFRVJfUkVQT1JUPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBm
ZWF0dXJlIE1VU1QgdXBkYXRlIHRyYW5zYWN0aW9uIHN0YXRlIHdpdGggYW4gaW5kaWNhdGlv
biBvZiB3aGV0aGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZmVhdHVy
ZSBNVVNUIHVwZGF0ZSB0cmFuc2FjdGlvbiBzdGF0ZSB3aXRoIGFuIGluZGljYXRpb24gb2Yg
d2hldGhlcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb3Igbm90IHRoZSBw
ZWVyIGZyb20gd2hpY2ggdGhlIHJlcXVlc3Qgd2FzIHJlY2VpdmVkIHN1cHBvcnRzIHRoZTwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9yIG5vdCB0aGUgcGVlciBmcm9t
IHdoaWNoIHRoZSByZXF1ZXN0IHdhcyByZWNlaXZlZCBzdXBwb3J0cyB0aGU8L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE9DX1BFRVJfUkVQT1JUIGZlYXR1cmUuPC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgT0NfUEVFUl9SRVBPUlQgZmVhdHVyZS48
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgTm90ZTog
VGhlIHRyYW5zYWN0aW9uIHN0YXRlIGlzIHVzZWQgd2hlbiB0aGUgRE9JQyBub2RlIGlzIGFj
dGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIE5vdGU6IFRoZSB0
cmFuc2FjdGlvbiBzdGF0ZSBpcyB1c2VkIHdoZW4gdGhlIERPSUMgbm9kZSBpcyBhY3Rpbmc8
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGFzIGEgcGVlci1yZXBvcnQg
cmVwb3J0aW5nIG5vZGUgYW5kIG5lZWRzIHNlbmQgT0MtT0xSIHJlcG9ydHMgb2Y8L3RkPjx0
ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBhcyBhIHBlZXItcmVwb3J0IHJlcG9y
dGluZyBub2RlIGFuZCBuZWVkcyBzZW5kIE9DLU9MUiByZXBvcnRzIG9mPC90ZD48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC01
IiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFu
Z2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTUiPjxlbT4gcGFnZSA5LCBsaW5lIDMxPHNw
YW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+
PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0
LTUiPjxlbT4gcGFnZSA5LCBsaW5lIDMxPHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3Nw
YW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBUaGUgcmVxdWVzdCBkb2VzIG5v
dCBjb250YWluIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAuPC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgVGhlIHJlcXVlc3QgZG9lcyBub3QgY29udGFpbiBh
biBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i
bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBUaGUgcmVjZWl2ZWQgcmVxdWVzdCBjb250YWlucyBh
biBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIHdpdGggbm88L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJpZ2h0Ij4gICAgICBUaGUgcmVjZWl2ZWQgcmVxdWVzdCBjb250YWlucyBhbiBP
Qy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIHdpdGggbm88L3RkPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPiAgICAgIE9DLUZlYXR1cmUtVmVjdG9yLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmlnaHQiPiAgICAgIE9DLUZlYXR1cmUtVmVjdG9yLjwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBUaGUgcmVjZWl2ZWQgcmVxdWVzdCBj
b250YWlucyBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIHdpdGggYTwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIFRoZSByZWNlaXZlZCByZXF1ZXN0IGNvbnRh
aW5zIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAgd2l0aCBhPC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBPQy1GZWF0dXJlLVZlY3RvciB3aXRoIHRoZSBPQ19Q
RUVSX1JFUE9SVCBmZWF0dXJlIGJpdCBjbGVhcmVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPiAgICAgIE9DLUZlYXR1cmUtVmVjdG9yIHdpdGggdGhlIE9DX1BFRVJfUkVQ
T1JUIGZlYXR1cmUgYml0IGNsZWFyZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0
Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxlZnQiPiAgICAgIFRoZSByZWNlaXZlZCByZXF1ZXN0IGNvbnRhaW5zIGFuIE9D
LVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAgd2l0aCBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyaWdodCI+ICAgICAgVGhlIHJlY2VpdmVkIHJlcXVlc3QgY29udGFpbnMgYW4gT0MtU3Vw
cG9ydGVkLUZlYXR1cmVzIEFWUCB3aXRoIGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPiAgICAgIE9DLUZlYXR1cmUtVmVjdG9yIHdpdGggdGhlIE9DX1BFRVJfUkVQT1JUIGZl
YXR1cmUgYml0IHNldCBidXQgd2l0aDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PiAgICAgIE9DLUZlYXR1cmUtVmVjdG9yIHdpdGggdGhlIE9DX1BFRVJfUkVQT1JUIGZlYXR1
cmUgYml0IHNldCBidXQgd2l0aDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K
ICAgICAgPHRyIGlkPSJkaWZmMDAwOCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICBhPHNwYW4gY2xh
c3M9ImRlbGV0ZSI+biBPQy08L3NwYW4+U291cmNlSUQgQVZQIHdpdGggYSBEaWFtZXRlcklk
ZW50aXR5IHRoYXQgZG9lcyBub3QgbWF0Y2ggdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyYmxvY2siPiAgICAgIGE8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gPC9zcGFuPlNvdXJjZUlE
IEFWUCB3aXRoIGEgRGlhbWV0ZXJJZGVudGl0eSB0aGF0IGRvZXMgbm90IG1hdGNoIHRoZTwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgRGlhbWV0ZXJJZGVudGl0eSBv
ZiB0aGUgcGVlciBmcm9tIHdoaWNoIHRoZSByZXF1ZXN0IHdhcyByZWNlaXZlZC48L3RkPjx0
ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBEaWFtZXRlcklkZW50aXR5IG9mIHRo
ZSBwZWVyIGZyb20gd2hpY2ggdGhlIHJlcXVlc3Qgd2FzIHJlY2VpdmVkLjwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgcGVlciBzdXBwb3J0cyB0
aGUgT0NfUEVFUl9SRVBPUlQgZmVhdHVyZSBpZiB0aGUgcmVjZWl2ZWQgcmVxdWVzdDwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBwZWVyIHN1cHBvcnRzIHRoZSBP
Q19QRUVSX1JFUE9SVCBmZWF0dXJlIGlmIHRoZSByZWNlaXZlZCByZXF1ZXN0PC90ZD48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjb250YWlucyBhbiBPQy1TdXBwb3J0ZWQtRmVh
dHVyZXMgQVZQIHdpdGggdGhlIE9DLUZlYXR1cmUtVmVjdG9yIHdpdGg8L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjb250YWlucyBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVy
ZXMgQVZQIHdpdGggdGhlIE9DLUZlYXR1cmUtVmVjdG9yIHdpdGg8L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDkiPjx0ZD48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j
ayI+ICAgdGhlIE9DX1BFRVJfUkVQT1JUIGZlYXR1cmUgYml0IHNldCBhbmQgd2l0aCBhPHNw
YW4gY2xhc3M9ImRlbGV0ZSI+biBPQy08L3NwYW4+U291cmNlSUQgQVZQIHdpdGggYTwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICB0aGUgT0NfUEVFUl9SRVBPUlQgZmVh
dHVyZSBiaXQgc2V0IGFuZCB3aXRoIGE8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gPC9zcGFuPlNv
dXJjZUlEIEFWUCB3aXRoIGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIERp
YW1ldGVyIElEIHRoYXQgbWF0Y2hlcyB0aGUgRGlhbWV0ZXJJZGVudGl0eSBvZiB0aGUgcGVl
ciBmcm9tIHdoaWNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRGlhbWV0
ZXIgSUQgdGhhdCBtYXRjaGVzIHRoZSBEaWFtZXRlcklkZW50aXR5IG9mIHRoZSBwZWVyIGZy
b20gd2hpY2g8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSByZXF1ZXN0
IHdhcyByZWNlaXZlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGUg
cmVxdWVzdCB3YXMgcmVjZWl2ZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPiAgIFdoZW4gcmVsYXlpbmcgYW4gYW5zd2VyIG1lc3NhZ2UsIGEgcmVwb3J0
aW5nIG5vZGUgdGhhdCBzdXBwb3J0cyB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij4gICBXaGVuIHJlbGF5aW5nIGFuIGFuc3dlciBtZXNzYWdlLCBhIHJlcG9ydGluZyBu
b2RlIHRoYXQgc3VwcG9ydHMgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g
ICBPQ19QRUVSX1JFUE9SVCBmZWF0dXJlIE1VU1Qgc3RyaXAgYW55IFNvdXJjZUlEIEFWUCBm
cm9tIHRoZSBPQy08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBPQ19QRUVS
X1JFUE9SVCBmZWF0dXJlIE1VU1Qgc3RyaXAgYW55IFNvdXJjZUlEIEFWUCBmcm9tIHRoZSBP
Qy08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFN1cHBvcnRlZC1GZWF0dXJl
cyBBVlAuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgU3VwcG9ydGVkLUZl
YXR1cmVzIEFWUC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+
ICAgV2hlbiBzZW5kaW5nIGFuIGFuc3dlciBtZXNzYWdlLCBhIHJlcG9ydGluZyBub2RlIHRo
YXQgc3VwcG9ydHMgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgV2hl
biBzZW5kaW5nIGFuIGFuc3dlciBtZXNzYWdlLCBhIHJlcG9ydGluZyBub2RlIHRoYXQgc3Vw
cG9ydHMgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBPQ19QRUVSX1JF
UE9SVCBmZWF0dXJlIE1VU1QgZGV0ZXJtaW5lIGlmIHRoZSBwZWVyIHRvIHdoaWNoIHRoZSBh
bnN3ZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBPQ19QRUVSX1JFUE9S
VCBmZWF0dXJlIE1VU1QgZGV0ZXJtaW5lIGlmIHRoZSBwZWVyIHRvIHdoaWNoIHRoZSBhbnN3
ZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGlzIHRvIGJlIHNlbnQgc3Vw
cG9ydHMgdGhlIE9DX1BFRVJfUkVQT1JUIGZlYXR1cmUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyaWdodCI+ICAgaXMgdG8gYmUgc2VudCBzdXBwb3J0cyB0aGUgT0NfUEVFUl9SRVBP
UlQgZmVhdHVyZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+
ICAgSWYgdGhlIHBlZXIgc3VwcG9ydHMgdGhlIE9DX1BFRVJfUkVQT1JUIGZlYXR1cmUgdGhl
biB0aGUgcmVwb3J0aW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSWYg
dGhlIHBlZXIgc3VwcG9ydHMgdGhlIE9DX1BFRVJfUkVQT1JUIGZlYXR1cmUgdGhlbiB0aGUg
cmVwb3J0aW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBub2RlIE1VU1Qg
aW5kaWNhdGUgc3VwcG9ydCBmb3IgdGhlIGZlYXR1cmUgaW4gdGhlIFN1cHBvcnRlZC1GZWF0
dXJlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG5vZGUgTVVTVCBpbmRp
Y2F0ZSBzdXBwb3J0IGZvciB0aGUgZmVhdHVyZSBpbiB0aGUgU3VwcG9ydGVkLUZlYXR1cmVz
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBVlAuPC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+ICAgQVZQLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm
dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij4gICBJZiB0aGUgcGVlciBzdXBwb3J0cyB0aGUgT0NfUEVFUl9SRVBP
UlQgZmVhdHVyZSB0aGVuIHRoZSByZXBvcnRpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij4gICBJZiB0aGUgcGVlciBzdXBwb3J0cyB0aGUgT0NfUEVFUl9SRVBPUlQgZmVh
dHVyZSB0aGVuIHRoZSByZXBvcnRpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv
dHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTAiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgbm9kZSBNVVNU
IGluc2VydCB0aGUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+T0MtU291cmNlSUQ8L3NwYW4+IEFW
UCBpbiB0aGUgT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUDwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmJsb2NrIj4gICBub2RlIE1VU1QgaW5zZXJ0IHRoZSA8c3BhbiBjbGFzcz0iaW5z
ZXJ0Ij5Tb3VyY2VJRDwvc3Bhbj4gQVZQIGluIHRoZSBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMg
QVZQIGluPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGluIHRoZSBhbnN3
ZXIgbWVzc2FnZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgdGhlIGFu
c3dlciBtZXNzYWdlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg
PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0
Ij4gICBJZiB0aGUgcGVlciBzdXBwb3J0cyB0aGUgT0NfUEVFUl9SRVBPUlQgZmVhdHVyZSB0
aGVuIHRoZSByZXBvcnRpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJ
ZiB0aGUgcGVlciBzdXBwb3J0cyB0aGUgT0NfUEVFUl9SRVBPUlQgZmVhdHVyZSB0aGVuIHRo
ZSByZXBvcnRpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG5vZGUgTVVT
VCBpbnNlcnQgdGhlIE9DLVBlZXItQWxnbyBBVlAgaW4gdGhlIE9DLVN1cHBvcnRlZC1GZWF0
dXJlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG5vZGUgTVVTVCBpbnNl
cnQgdGhlIE9DLVBlZXItQWxnbyBBVlAgaW4gdGhlIE9DLVN1cHBvcnRlZC1GZWF0dXJlczwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQVZQLiAgVGhlIE9DLVBlZXItQWxn
byBBVlAgTVVTVCBpbmRpY2F0ZSB0aGUgb3ZlcmxvYWQgYWJhdGVtZW50PC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQVZQLiAgVGhlIE9DLVBlZXItQWxnbyBBVlAgTVVT
VCBpbmRpY2F0ZSB0aGUgb3ZlcmxvYWQgYWJhdGVtZW50PC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij4gICBhbGdvcml0aG0gdGhhdCB0aGUgcmVwb3J0aW5nIG5vZGUgd2FudHMg
dGhlIHJlYWN0aW5nIG5vZGVzIHRvIHVzZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPiAgIGFsZ29yaXRobSB0aGF0IHRoZSByZXBvcnRpbmcgbm9kZSB3YW50cyB0aGUgcmVh
Y3Rpbmcgbm9kZXMgdG8gdXNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBz
aG91bGQgdGhlIHJlcG9ydGluZyBub2RlIHNlbmQgYSBwZWVyIG92ZXJsb2FkIHJlcG9ydCBh
cyBhIHJlc3VsdCBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNob3Vs
ZCB0aGUgcmVwb3J0aW5nIG5vZGUgc2VuZCBhIHBlZXIgb3ZlcmxvYWQgcmVwb3J0IGFzIGEg
cmVzdWx0IG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBiZWNvbWluZyBv
dmVybG9hZGVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGJlY29taW5n
IG92ZXJsb2FkZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi
PjUuMi4gIFBlZXIgUmVwb3J0IE92ZXJsb2FkIFJlcG9ydCBIYW5kbGluZzwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjUuMi4gIFBlZXIgUmVwb3J0IE92ZXJsb2FkIFJlcG9y
dCBIYW5kbGluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC02IiBjbGFzcz0iY2hhbmdlIiA+PHRk
PjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9
IiNwYXJ0LTYiPjxlbT4gcGFnZSAxMiwgbGluZSA5PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFy
YTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0
byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTYiPjxlbT4gcGFnZSAxMiwgbGlu
ZSA5PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+
PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz
PSJsZWZ0Ij41LjIuMy4gIFJlYWN0aW5nIE5vZGUgTWFpbnRlbmFuY2Ugb2YgUGVlciBSZXBv
cnQgT0NTPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NS4yLjMuICBSZWFjdGlu
ZyBOb2RlIE1haW50ZW5hbmNlIG9mIFBlZXIgUmVwb3J0IE9DUzwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBXaGVuIGEgcmVhY3Rpbmcgbm9kZSByZWNl
aXZlcyBhbiBPQy1PTFIgQVZQIHdpdGggYSByZXBvcnQgdHlwZSBvZjwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFdoZW4gYSByZWFjdGluZyBub2RlIHJlY2VpdmVzIGFu
IE9DLU9MUiBBVlAgd2l0aCBhIHJlcG9ydCB0eXBlIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij4gICBwZWVyIGl0IE1VU1QgZGV0ZXJtaW5lIGlmIHRoZSByZXBvcnQgd2Fz
IGdlbmVyYXRlZCBieSB0aGUgRGlhbWV0ZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij4gICBwZWVyIGl0IE1VU1QgZGV0ZXJtaW5lIGlmIHRoZSByZXBvcnQgd2FzIGdlbmVy
YXRlZCBieSB0aGUgRGlhbWV0ZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg
IHBlZXIgZnJvbSB3aGljaCB0aGUgcmVwb3J0IHdhcyByZWNlaXZlZC48L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwZWVyIGZyb20gd2hpY2ggdGhlIHJlcG9ydCB3YXMg
cmVjZWl2ZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg
IElmIHRoZSBEaWFtZXRlcklEIGluIHRoZSBTb3VyY2VJRCBjb250YWluZWQgaW4gdGhlIE9M
UiBtYXRjaGVzIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIElmIHRo
ZSBEaWFtZXRlcklEIGluIHRoZSBTb3VyY2VJRCBjb250YWluZWQgaW4gdGhlIE9MUiBtYXRj
aGVzIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRGlhbWV0ZXJJZGVu
dGl0eSBvZiB0aGUgcGVlciBmcm9tIHdoaWNoIHRoZSByZXF1ZXN0IHdhcyByZWNlaXZlZCB0
aGVuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRGlhbWV0ZXJJZGVudGl0
eSBvZiB0aGUgcGVlciBmcm9tIHdoaWNoIHRoZSByZXF1ZXN0IHdhcyByZWNlaXZlZCB0aGVu
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGUgcmVwb3J0IHdhcyByZWNl
aXZlZCBmcm9tIGEgRGlhbWV0ZXIgcGVlci48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij4gICB0aGUgcmVwb3J0IHdhcyByZWNlaXZlZCBmcm9tIGEgRGlhbWV0ZXIgcGVlci48
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy
IGlkPSJkaWZmMDAxMSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBJZiBhIHJlYWN0aW5nIG5vZGUgcmVj
ZWl2ZXMgYW4gT0MtT0xSIEFWUCBvZiB0eXBlIHBlZXIgYW5kIHRoZTxzcGFuIGNsYXNzPSJk
ZWxldGUiPiBPQy08L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg
IElmIGEgcmVhY3Rpbmcgbm9kZSByZWNlaXZlcyBhbiBPQy1PTFIgQVZQIG9mIHR5cGUgcGVl
ciBhbmQgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBTb3VyY2VJRCBk
b2VzIG5vdCBtYXRjaCB0aGUgSUQgb2YgdGhlIERpYW1ldGVyIHBlZXIgZnJvbSB3aGljaCB0
aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBTb3VyY2VJRCBkb2VzIG5v
dCBtYXRjaCB0aGUgSUQgb2YgdGhlIERpYW1ldGVyIHBlZXIgZnJvbSB3aGljaCB0aGU8L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJlcXVlc3Qgd2FzIHJlY2VpdmVkIHRo
ZW4gdGhlIHJlYWN0aW5nIG5vZGUgTVVTVCBpZ25vcmUgdGhlIG92ZXJsb2FkPC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVxdWVzdCB3YXMgcmVjZWl2ZWQgdGhlbiB0
aGUgcmVhY3Rpbmcgbm9kZSBNVVNUIGlnbm9yZSB0aGUgb3ZlcmxvYWQ8L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJlcG9ydC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij4gICByZXBvcnQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9
ImxlZnQiPiAgIEluIGFsbCBjYXNlcywgaWYgdGhlIHJlYWN0aW5nIG5vZGUgaXMgYSByZWxh
eSB0aGVuIGl0IE1VU1Qgc3RyaXAgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo
dCI+ICAgSW4gYWxsIGNhc2VzLCBpZiB0aGUgcmVhY3Rpbmcgbm9kZSBpcyBhIHJlbGF5IHRo
ZW4gaXQgTVVTVCBzdHJpcCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg
IE9DLU9MUiBBVlAgZnJvbSB0aGUgbWVzc2FnZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij4gICBPQy1PTFIgQVZQIGZyb20gdGhlIG1lc3NhZ2UuPC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIElmIHRoZSBQZWVyIFJlcG9ydCBPTFIg
d2FzIHJlY2VpdmVkIGZyb20gYSBEaWFtZXRlciBwZWVyIHRoZW4gdGhlPC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSWYgdGhlIFBlZXIgUmVwb3J0IE9MUiB3YXMgcmVj
ZWl2ZWQgZnJvbSBhIERpYW1ldGVyIHBlZXIgdGhlbiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxlZnQiPiAgIHJlYWN0aW5nIG5vZGUgTVVTVCBkZXRlcm1pbmUgaWYgaXQgaXMg
Zm9yIGFuIGV4aXN0aW5nIG9yIG5ldyBvdmVybG9hZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPiAgIHJlYWN0aW5nIG5vZGUgTVVTVCBkZXRlcm1pbmUgaWYgaXQgaXMgZm9y
IGFuIGV4aXN0aW5nIG9yIG5ldyBvdmVybG9hZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i
bGVmdCI+ICAgY29uZGl0aW9uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg
IGNvbmRpdGlvbi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90
cj4KICAgICAgPHRyIGlkPSJwYXJ0LTciIGNsYXNzPSJjaGFuZ2UiID48dGQ+PC90ZD48dGg+
PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtNyI+
PGVtPiBwYWdlIDEzLCBsaW5lIDIwPHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+
PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2Ug
YXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTciPjxlbT4gcGFnZSAxMywgbGluZSAyMDxzcGFu
IGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+
ICAgV2hlbiB0aGVyZSBpcyBhbiBleGlzdGluZyByZXBvcnRpbmcgbm9kZSBwZWVyIHJlcG9y
dCBPQ1MgZW50cnksIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFdo
ZW4gdGhlcmUgaXMgYW4gZXhpc3RpbmcgcmVwb3J0aW5nIG5vZGUgcGVlciByZXBvcnQgT0NT
IGVudHJ5LCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJlcG9ydGlu
ZyBub2RlIE1VU1QgaW5jbHVkZSBhbiBPQy1PTFIgQVZQIHdpdGggYSByZXBvcnQgdHlwZSBv
ZiBwZWVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVwb3J0aW5nIG5v
ZGUgTVVTVCBpbmNsdWRlIGFuIE9DLU9MUiBBVlAgd2l0aCBhIHJlcG9ydCB0eXBlIG9mIHBl
ZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHVzaW5nIHRoZSBjb250ZW50
cyBvZiB0aGUgcmVwb3J0aW5nIG5vZGUgcGVlciByZXBvcnQgT0NTIGVudHJ5IGluIGFsbDwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHVzaW5nIHRoZSBjb250ZW50cyBv
ZiB0aGUgcmVwb3J0aW5nIG5vZGUgcGVlciByZXBvcnQgT0NTIGVudHJ5IGluIGFsbDwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW5zd2VyIG1lc3NhZ2VzIHNlbnQgYnkg
dGhlIHJlcG9ydGluZyBub2RlIHRvIHBlZXJzIHRoYXQgc3VwcG9ydCB0aGU8L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbnN3ZXIgbWVzc2FnZXMgc2VudCBieSB0aGUg
cmVwb3J0aW5nIG5vZGUgdG8gcGVlcnMgdGhhdCBzdXBwb3J0IHRoZTwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgT0NfUEVFUl9SRVBPUlQgZmVhdHVyZS48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBPQ19QRUVSX1JFUE9SVCBmZWF0dXJlLjwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBUaGUgcmVwb3J0
aW5nIG5vZGUgZGV0ZXJtaW5lcyBpZiBhIHBlZXIgc3VwcG9ydHMgdGhlPC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgVGhlIHJlcG9ydGluZyBub2RlIGRldGVybWlu
ZXMgaWYgYSBwZWVyIHN1cHBvcnRzIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm
dCI+ICAgICAgT0NfUEVFUl9SRVBPUlQgZmVhdHVyZSBiYXNlZCBvbiB0aGUgaW5kaWNhdGlv
biByZWNvcmRlZCBpbiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg
ICBPQ19QRUVSX1JFUE9SVCBmZWF0dXJlIGJhc2VkIG9uIHRoZSBpbmRpY2F0aW9uIHJlY29y
ZGVkIGluIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgcmVwb3J0
aW5nIG5vZGVzIHRyYW5zYWN0aW9uIHN0YXRlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPiAgICAgIHJlcG9ydGluZyBub2RlcyB0cmFuc2FjdGlvbiBzdGF0ZS48L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJk
aWZmMDAxMiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUaGUgcmVwb3J0aW5nIG5vZGUgTVVTVCBpbmNs
dWRlIGl0cyBEaWFtZXRlcklkZW50aXR5IGluIHRoZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5P
Qy08L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFRoZSByZXBv
cnRpbmcgbm9kZSBNVVNUIGluY2x1ZGUgaXRzIERpYW1ldGVySWRlbnRpdHkgaW4gdGhlIFNv
dXJjZUlEPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFNvdXJjZUlEIEFW
UCBpbiB0aGUgT0MtT0xSIEFWUC4gIFRoaXMgaXMgdXNlZCBieSBET0lDIG5vZGVzIHRoYXQ8
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgQVZQIGluIHRoZSBPQy1PTFIg
QVZQLiAgVGhpcyBpcyB1c2VkIGJ5IERPSUMgbm9kZXMgdGhhdCBzdXBwb3J0IHRoZTwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBzdXBwb3J0IHRoZSBPQ19QRUVSX1JF
UE9SVCBmZWF0dXJlIHRvIGRldGVybWluZSBpZiB0aGUgcmVwb3J0IHdhczwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBPQ19QRUVSX1JFUE9SVCBmZWF0dXJlIHRvIGRl
dGVybWluZSBpZiB0aGUgcmVwb3J0IHdhcyByZWNlaXZlZCBmcm9tIGE8L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgcmVjZWl2ZWQgZnJvbSBhIERpYW1ldGVyIHBlZXIu
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIERpYW1ldGVyIHBlZXIuPC90
ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSByZXBvcnRp
bmcgYWdlbnQgbXVzdCBmb2xsb3cgYWxsIG90aGVyIG92ZXJsb2FkIHJlcG9ydGluZyBub2Rl
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIHJlcG9ydGluZyBhZ2Vu
dCBtdXN0IGZvbGxvdyBhbGwgb3RoZXIgb3ZlcmxvYWQgcmVwb3J0aW5nIG5vZGU8L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGJlaGF2aW9ycyBvdXRsaW5lZCBpbiB0aGUg
RE9JQyBzcGVjaWZpY2F0aW9uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg
IGJlaGF2aW9ycyBvdXRsaW5lZCBpbiB0aGUgRE9JQyBzcGVjaWZpY2F0aW9uLjwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo
dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij41LjIuNS4gIFBlZXIgUmVwb3J0
IFJlYWN0aW5nIE5vZGUgQmVoYXZpb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij41LjIuNS4gIFBlZXIgUmVwb3J0IFJlYWN0aW5nIE5vZGUgQmVoYXZpb3I8L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQSByZWFjdGluZyBub2RlIHN1
cHBvcnRpbmcgdGhpcyBleHRlbnNpb24gTVVTVCBzdXBwb3J0IHRoZSByZWNlaXB0IG9mPC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQSByZWFjdGluZyBub2RlIHN1cHBv
cnRpbmcgdGhpcyBleHRlbnNpb24gTVVTVCBzdXBwb3J0IHRoZSByZWNlaXB0IG9mPC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtdWx0aXBsZSBvdmVybG9hZCByZXBvcnRz
IGluIGEgc2luZ2xlIG1lc3NhZ2UuICBUaGUgbWVzc2FnZSBtaWdodDwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIG11bHRpcGxlIG92ZXJsb2FkIHJlcG9ydHMgaW4gYSBz
aW5nbGUgbWVzc2FnZS4gIFRoZSBtZXNzYWdlIG1pZ2h0PC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij4gICBpbmNsdWRlIGEgaG9zdCBvdmVybG9hZCByZXBvcnQsIGEgcmVhbG0g
b3ZlcmxvYWQgcmVwb3J0IGFuZC9vciBhIHBlZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij4gICBpbmNsdWRlIGEgaG9zdCBvdmVybG9hZCByZXBvcnQsIGEgcmVhbG0gb3Zl
cmxvYWQgcmVwb3J0IGFuZC9vciBhIHBlZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPiAgIG92ZXJsb2FkIHJlcG9ydC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij4gICBvdmVybG9hZCByZXBvcnQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC04IiBjbGFzcz0iY2hhbmdlIiA+PHRk
PjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9
IiNwYXJ0LTgiPjxlbT4gcGFnZSAxNCwgbGluZSAyMDxzcGFuIGNsYXNzPSJoaWRlIj4gJnBh
cmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tpcHBpbmcg
dG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC04Ij48ZW0+IHBhZ2UgMTQsIGxp
bmUgMjA8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0
ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Ni4gIFBlZXIgUmVwb3J0IEFWUHM8L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij42LiAgUGVlciBSZXBvcnQgQVZQczwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90
ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij42LjEuICBPQy1TdXBwb3J0ZWQtRmVhdHVy
ZXMgQVZQPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Ni4xLiAgT0MtU3VwcG9y
dGVkLUZlYXR1cmVzIEFWUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs
ZWZ0Ij4gICBUaGlzIGV4dGVuc2lvbiBhZGRzIGEgbmV3IGZlYXR1cmUgdG8gdGhlIE9DLUZl
YXR1cmUtVmVjdG9yIEFWUC4gIFRoaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij4gICBUaGlzIGV4dGVuc2lvbiBhZGRzIGEgbmV3IGZlYXR1cmUgdG8gdGhlIE9DLUZlYXR1
cmUtVmVjdG9yIEFWUC4gIFRoaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg
IGZlYXR1cmUgaW5kaWNhdGlvbiBzaG93cyBzdXBwb3J0IGZvciBoYW5kbGluZyBvZiBwZWVy
IG92ZXJsb2FkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZmVhdHVyZSBp
bmRpY2F0aW9uIHNob3dzIHN1cHBvcnQgZm9yIGhhbmRsaW5nIG9mIHBlZXIgb3ZlcmxvYWQ8
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJlcG9ydHMuICBQZWVyIG92ZXJs
b2FkIHJlcG9ydHMgYXJlIHVzZWQgYnkgYWdlbnRzIHRvIGluZGljYXRlIHRoZTwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHJlcG9ydHMuICBQZWVyIG92ZXJsb2FkIHJl
cG9ydHMgYXJlIHVzZWQgYnkgYWdlbnRzIHRvIGluZGljYXRlIHRoZTwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgbmVlZCBmb3Igb3ZlcmxvYWQgYWJhdGVtZW50IGhhbmRs
aW5nIGJ5IHRoZSBhZ2VudHMgcGVlci48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij4gICBuZWVkIGZvciBvdmVybG9hZCBhYmF0ZW1lbnQgaGFuZGxpbmcgYnkgdGhlIGFnZW50
cyBwZWVyLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHIgaWQ9ImRpZmYwMDEzIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIEEgc3VwcG9ydGluZyBu
b2RlIG11c3QgYWxzbyBpbmNsdWRlIHRoZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5PQy08L3Nw
YW4+U291cmNlSUQgQVZQIGluIHRoZSBPQy08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi
bG9jayI+ICAgQSBzdXBwb3J0aW5nIG5vZGUgbXVzdCBhbHNvIGluY2x1ZGUgdGhlIFNvdXJj
ZUlEIEFWUCBpbiB0aGUgT0MtPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBT
dXBwb3J0ZWQtRmVhdHVyZXMgY2FwYWJpbGl0eSBBVlAuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyaWdodCI+ICAgU3VwcG9ydGVkLUZlYXR1cmVzIGNhcGFiaWxpdHkgQVZQLjwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIEFWUCBjb250
YWlucyB0aGUgRGlhbWV0ZXIgSWRlbnRpdHkgb2YgdGhlIG5vZGUgdGhhdCBzdXBwb3J0cyB0
aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIEFWUCBjb250YWlu
cyB0aGUgRGlhbWV0ZXIgSWRlbnRpdHkgb2YgdGhlIG5vZGUgdGhhdCBzdXBwb3J0cyB0aGU8
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE9DX1BFRVJfUkVQT1JUIGZlYXR1
cmUuICBUaGlzIEFWUCBpcyB1c2VkIHRvIGRldGVybWluZSBpZiBzdXBwb3J0IGZvcjwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIE9DX1BFRVJfUkVQT1JUIGZlYXR1cmUu
ICBUaGlzIEFWUCBpcyB1c2VkIHRvIGRldGVybWluZSBpZiBzdXBwb3J0IGZvcjwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIHBlZXIgb3ZlcmxvYWQgcmVwb3J0IGlz
IGluIGFuIGFkamFjZW50IG5vZGUuICBUaGUgdmFsdWUgb2YgdGhpczwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSBwZWVyIG92ZXJsb2FkIHJlcG9ydCBpcyBpbiBh
biBhZGphY2VudCBub2RlLiAgVGhlIHZhbHVlIG9mIHRoaXM8L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxlZnQiPiAgIEFWUCBzaG91bGQgYmUgdGhlIHNhbWUgRGlhbWV0ZXIgaWRlbnRp
dHkgdXNlZCBhcyBwYXJ0IG9mIHRoZSBDRVIvQ0VBPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyaWdodCI+ICAgQVZQIHNob3VsZCBiZSB0aGUgc2FtZSBEaWFtZXRlciBpZGVudGl0eSB1
c2VkIGFzIHBhcnQgb2YgdGhlIENFUi9DRUE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPiAgIGJhc2UgRGlhbWV0ZXIgY2FwYWJpbGl0aWVzIGV4Y2hhbmdlLjwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGJhc2UgRGlhbWV0ZXIgY2FwYWJpbGl0aWVzIGV4
Y2hhbmdlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBU
aGlzIGV4dGVuc2lvbiBhbHNvIGFkZHMgdGhlIE9DLVBlZXItQWxnbyBBVlAgdG8gdGhlIE9D
LVN1cHBvcnRlZC08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGV4
dGVuc2lvbiBhbHNvIGFkZHMgdGhlIE9DLVBlZXItQWxnbyBBVlAgdG8gdGhlIE9DLVN1cHBv
cnRlZC08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEZlYXR1cmVzIEFWUC4g
IFRoaXMgQVZQIGlzIHVzZWQgYnkgYSByZXBvcnRpbmcgbm9kZSB0byBpbmRpY2F0ZSB0aGU8
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBGZWF0dXJlcyBBVlAuICBUaGlz
IEFWUCBpcyB1c2VkIGJ5IGEgcmVwb3J0aW5nIG5vZGUgdG8gaW5kaWNhdGUgdGhlPC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhYmF0ZW1lbnQgYWxnb3JpdGhtIGl0IHdp
bGwgdXNlIGZvciBwZWVyIG92ZXJsb2FkIHJlcG9ydHMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyaWdodCI+ICAgYWJhdGVtZW50IGFsZ29yaXRobSBpdCB3aWxsIHVzZSBmb3IgcGVl
ciBvdmVybG9hZCByZXBvcnRzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K
ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz
PSJsZWZ0Ij4gICAgT0MtU3VwcG9ydGVkLUZlYXR1cmVzIDo6PSAmbHQ7IEFWUCBIZWFkZXI6
IFRCRDEgJmd0OzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICBPQy1TdXBw
b3J0ZWQtRmVhdHVyZXMgOjo9ICZsdDsgQVZQIEhlYWRlcjogVEJEMSAmZ3Q7PC90ZD48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICBb
IE9DLUZlYXR1cmUtVmVjdG9yIF08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbIE9DLUZlYXR1cmUtVmVjdG9yIF08L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTQi
Pjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWyA8c3BhbiBj
bGFzcz0iZGVsZXRlIj5PQy08L3NwYW4+U291cmNlSUQgXTwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbIFNvdXJjZUlE
IF08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIFsgT0MtUGVlci1BbGdvXTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFsgT0MtUGVlci1BbGdvXTwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICogWyBBVlAgXTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAqIFsgQVZQIF08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+Ni4xLjEuICBPQy1GZWF0dXJlLVZlY3RvcjwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPjYuMS4xLiAgT0MtRmVhdHVyZS1WZWN0b3I8L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIHBlZXIgcmVwb3J0IGZl
YXR1cmUgZGVmaW5lcyBhIG5ldyBmZWF0dXJlIGJpdCBpcyBhZGRlZCBmb3IgdGhlPC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIHBlZXIgcmVwb3J0IGZlYXR1cmUg
ZGVmaW5lcyBhIG5ldyBmZWF0dXJlIGJpdCBpcyBhZGRlZCBmb3IgdGhlPC90ZD48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBPQy1GZWF0dXJlLVZlY3RvciBBVlAuPC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgT0MtRmVhdHVyZS1WZWN0b3IgQVZQLjwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBPQ19QRUVSX1JFUE9S
VCAoMHgwMDAwMDAwMDAwMDAwMDEwKTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PiAgIE9DX1BFRVJfUkVQT1JUICgweDAwMDAwMDAwMDAwMDAwMTApPC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlk
PSJwYXJ0LTkiIGNsYXNzPSJjaGFuZ2UiID48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5n
IHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtOSI+PGVtPiBwYWdlIDE1LCBs
aW5lIDM0PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48
dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhy
ZWY9IiNwYXJ0LTkiPjxlbT4gcGFnZSAxNSwgbGluZSAzNDxzcGFuIGNsYXNzPSJoaWRlIj4g
JnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBU
aGUgb3ZlcmxvYWQgcmVwb3J0IG11c3QgYWxzbyBpbmNsdWRlIHRoZSBEaWFtZXRlciBpZGVu
dGl0eSBvZiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgb3Zl
cmxvYWQgcmVwb3J0IG11c3QgYWxzbyBpbmNsdWRlIHRoZSBEaWFtZXRlciBpZGVudGl0eSBv
ZiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFnZW50IHRoYXQgZ2Vu
ZXJhdGVkIHRoZSByZXBvcnQuICBUaGlzIGlzIG5lY2Vzc2FyeSB0byBoYW5kbGUgdGhlPC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYWdlbnQgdGhhdCBnZW5lcmF0ZWQg
dGhlIHJlcG9ydC4gIFRoaXMgaXMgbmVjZXNzYXJ5IHRvIGhhbmRsZSB0aGU8L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNhc2Ugd2hlcmUgdGhlcmUgaXMgYSBub24gc3Vw
cG9ydGluZyBhZ2VudCBiZXR3ZWVuIHRoZSByZXBvcnRpbmcgbm9kZTwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNhc2Ugd2hlcmUgdGhlcmUgaXMgYSBub24gc3VwcG9y
dGluZyBhZ2VudCBiZXR3ZWVuIHRoZSByZXBvcnRpbmcgbm9kZTwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+ICAgYW5kIHRoZSByZWFjdGluZyBub2RlLiAgV2l0aG91dCB0aGUg
aW5kaWNhdGlvbiBvZiB0aGUgYWdlbnQgdGhhdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPiAgIGFuZCB0aGUgcmVhY3Rpbmcgbm9kZS4gIFdpdGhvdXQgdGhlIGluZGljYXRp
b24gb2YgdGhlIGFnZW50IHRoYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg
IGdlbmVyYXRlZCB0aGUgb3ZlcmxvYWQgcmVxdWVzdCwgdGhlIHJlYWN0aW5nIG5vZGUgY291
bGQgZXJyb25lb3VzbHk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBnZW5l
cmF0ZWQgdGhlIG92ZXJsb2FkIHJlcXVlc3QsIHRoZSByZWFjdGluZyBub2RlIGNvdWxkIGVy
cm9uZW91c2x5PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhc3N1bWUgdGhh
dCB0aGUgcmVwb3J0IGFwcGxpZWQgdG8gdGhlIG5vbiBzdXBwb3J0aW5nIG5vZGUuICBUaGlz
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYXNzdW1lIHRoYXQgdGhlIHJl
cG9ydCBhcHBsaWVkIHRvIHRoZSBub24gc3VwcG9ydGluZyBub2RlLiAgVGhpczwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY291bGQsIGluIHR1cm4sIHJlc3VsdCBpbiB1
bm5lY2Vzc2FyeSB0cmFmZmljIGJlaW5nIGVpdGhlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPiAgIGNvdWxkLCBpbiB0dXJuLCByZXN1bHQgaW4gdW5uZWNlc3NhcnkgdHJh
ZmZpYyBiZWluZyBlaXRoZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJl
ZGlzdHJpYnV0ZWQgb3IgdGhyb3R0bGVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPiAgIHJlZGlzdHJpYnV0ZWQgb3IgdGhyb3R0bGVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj
bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDE1Ij48dGQ+
PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz
PSJsYmxvY2siPiAgIFRoZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5PQy08L3NwYW4+U291cmNl
SUQgQVZQIGlzIHVzZWQgaW4gdGhlIE9DLU9MUiBBVlAgdG8gY2FycnkgdGhpczwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBUaGUgU291cmNlSUQgQVZQIGlzIHVzZWQg
aW4gdGhlIE9DLU9MUiBBVlAgdG8gY2FycnkgdGhpczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz
cz0ibGVmdCI+ICAgRGlhbWV0ZXJJZGVudGl0eS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij4gICBEaWFtZXRlcklkZW50aXR5LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i
bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBPQy1PTFIgOjo9ICZsdDsgQVZQIEhlYWRlcjogVEJE
MiAmZ3Q7PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgT0MtT0xSIDo6
PSAmbHQ7IEFWUCBIZWFkZXI6IFRCRDIgJmd0OzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i
bGVmdCI+ICAgICAgICAgICAgICAgICAmbHQ7IE9DLVNlcXVlbmNlLU51bWJlciAmZ3Q7PC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAmbHQ7IE9D
LVNlcXVlbmNlLU51bWJlciAmZ3Q7PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g
ICAgICAgICAgICAgICAgICZsdDsgT0MtUmVwb3J0LVR5cGUgJmd0OzwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgJmx0OyBPQy1SZXBvcnQtVHlw
ZSAmZ3Q7PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAg
IFsgT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgXTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPiAgICAgICAgICAgICAgICAgWyBPQy1SZWR1Y3Rpb24tUGVyY2VudGFnZSBdPC90
ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgIFsgT0MtVmFs
aWRpdHktRHVyYXRpb24gXTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg
ICAgICAgICAgICAgWyBPQy1WYWxpZGl0eS1EdXJhdGlvbiBdPC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDE2Ij48dGQ+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si
PiAgICAgICAgICAgICAgICAgWyA8c3BhbiBjbGFzcz0iZGVsZXRlIj5PQy1Tb3VyY2UtPC9z
cGFuPklEIF08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAg
ICAgICBbIDxzcGFuIGNsYXNzPSJpbnNlcnQiPlNvdXJjZTwvc3Bhbj5JRCBdPC90ZD48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAqIFsgQVZQIF08L3RkPjx0
ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAqIFsgQVZQIF08L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Ni4yLjEuICBPQy1SZXBv
cnQtVHlwZSBBVlA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij42LjIuMS4gIE9D
LVJlcG9ydC1UeXBlIEFWUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs
ZWZ0Ij4gICBUaGUgZm9sbG93aW5nIG5ldyByZXBvcnQgdHlwZSBpcyBkZWZpbmVkIGZvciB0
aGUgT0MtUmVwb3J0LVR5cGUgQVZQLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PiAgIFRoZSBmb2xsb3dpbmcgbmV3IHJlcG9ydCB0eXBlIGlzIGRlZmluZWQgZm9yIHRoZSBP
Qy1SZXBvcnQtVHlwZSBBVlAuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9
ImxlZnQiPiAgIFBFRVJfUkVQT1JUIDIgICBUaGUgb3ZlcmxvYWQgdHJlYXRtZW50IHNob3Vs
ZCBhcHBseSB0byBhbGwgcmVxdWVzdHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij4gICBQRUVSX1JFUE9SVCAyICAgVGhlIG92ZXJsb2FkIHRyZWF0bWVudCBzaG91bGQgYXBw
bHkgdG8gYWxsIHJlcXVlc3RzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg
ICBib3VuZCBmb3IgdGhlIHBlZXIgaWRlbnRpZmllZCBpbiB0aGUgb3ZlcmxvYWQgcmVwb3J0
LiAgSWYgdGhlIHBlZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBi
b3VuZCBmb3IgdGhlIHBlZXIgaWRlbnRpZmllZCBpbiB0aGUgb3ZlcmxvYWQgcmVwb3J0LiAg
SWYgdGhlIHBlZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGlkZW50
aWZpZWQgaW4gdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBub3QgYSBwZWVyIHRvIHRoZSByZWFj
dGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGlkZW50aWZpZWQg
aW4gdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBub3QgYSBwZWVyIHRvIHRoZSByZWFjdGluZzwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgZW5kcG9pbnQgdGhlbiB0aGUg
b3ZlcmxvYWQgcmVwb3J0IHNob3VsZCBiZSBzdHJpcHBlZCBhbmQgbm90IGFjdGVkPC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgZW5kcG9pbnQgdGhlbiB0aGUgb3Zl
cmxvYWQgcmVwb3J0IHNob3VsZCBiZSBzdHJpcHBlZCBhbmQgbm90IGFjdGVkPC90ZD48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB1cG9uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmlnaHQiPiAgICAgIHVwb24uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0
Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTciPjx0ZD48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+
Ni4zLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+T0MtPC9zcGFuPlNvdXJjZUlEPC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjYuMy4gIFNvdXJjZUlEPC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBTb3VyY2VJRCBBVlAgKEFWUCBj
b2RlIFRCRDIpIGlzIG9mIHR5cGUgRGlhbWV0ZXJJZGVudGl0eSBhbmQgaXM8L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgU291cmNlSUQgQVZQIChBVlAgY29kZSBU
QkQyKSBpcyBvZiB0eXBlIERpYW1ldGVySWRlbnRpdHkgYW5kIGlzPC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDE4Ij48dGQ+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv
Y2siPiAgIGluc2VydGVkIGJ5IDxzcGFuIGNsYXNzPSJkZWxldGUiPnRoZSBET0lDPC9zcGFu
PiBub2RlIDxzcGFuIGNsYXNzPSJkZWxldGUiPnRoYXQgZWl0aGVyIGluZGljYXRlcyBzdXBw
b3J0IGZvciB0aGlzPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g
ICBpbnNlcnRlZCBieSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hIERpYW1ldGVyPC9zcGFuPiBu
b2RlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnRvIGluZGljYXRlIHRoZSBzb3VyY2Ugb2Y8L3Nw
YW4+IHRoZSBBVlAgPHNwYW4gY2xhc3M9Imluc2VydCI+aW48L3NwYW4+PC90ZD48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIGZlYXR1cmUg
KGluPC9zcGFuPiB0aGUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+T0MtU3VwcG9ydGVkLUZlYXR1
cmVzIEFWUCkgb3IgdGhhdCBnZW5lcmF0ZXMgYW4gT0MtPC9zcGFuPjwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB3aGljaCBpdCBp
czwvc3Bhbj4gYSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5wYXJ0Ljwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgT0xSPC9z
cGFuPiBBVlAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+d2l0aDwvc3Bhbj4gYSA8c3BhbiBjbGFz
cz0iZGVsZXRlIj5yZXBvcnQgdHlwZSBvZiBwZWVyLjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTkiPjx0ZD48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgSXQg
Y29udGFpbnMgdGhlIDxzcGFuIGNsYXNzPSJkZWxldGUiPkRpYW1ldGVyIElkZW50aXR5PC9z
cGFuPiBvZiB0aGUgaW5zZXJ0aW5nIG5vZGUuICBUaGlzIGlzPC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkluIHRoZSBjYXNlIG9m
IHBlZXIgcmVwb3J0cywgdGhlIFNvdXJjZUlEIEFWUCBpbmRpY2F0ZXMgdGhlIG5vZGUgdGhh
dDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgdXNlZCBieSBv
dGhlciA8c3BhbiBjbGFzcz0iZGVsZXRlIj5ET0lDPC9zcGFuPiBub2RlcyB0byBkZXRlcm1p
bmUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+aWY8L3NwYW4+IHRoZSA8c3BhbiBjbGFzcz0iZGVs
ZXRlIj5hIHBlZXIgaW5kaWNhdGVkIHN1cHBvcnQ8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHN1cHBvcnQgZm9yIHRo
aXMgZmVhdHVyZSAoaW4gdGhlIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlApIG9yIHRoZTwv
c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRl
bGV0ZSI+ICAgdGhpcyBmZWF0dXJlIG9yPC9zcGFuPiBpbnNlcnRlZCB0aGUgPHNwYW4gY2xh
c3M9ImRlbGV0ZSI+cGVlciByZXBvcnQuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBub2RlIHRoYXQgZ2VuZXJhdGVz
IGFuIG92ZXJsb2FkIHdpdGggYSByZXBvcnQgdHlwZSBvZiBwZWVyIChpbiB0aGU8L3NwYW4+
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBPQy1PTFIgQVZQKS48L3Nw
YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBJ
dCBjb250YWlucyB0aGUgPHNwYW4gY2xhc3M9Imluc2VydCI+RGlhbWV0ZXJJZGVudGl0eTwv
c3Bhbj4gb2YgdGhlIGluc2VydGluZyBub2RlLiAgVGhpcyBpcyB1c2VkPC90ZD48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr
Ij4gICBieSBvdGhlciA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5EaWFtZXRlcjwvc3Bhbj4gbm9k
ZXMgdG8gZGV0ZXJtaW5lIHRoZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5ub2RlIHRoYXQ8L3Nw
YW4+IGluc2VydGVkIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+
ZW5jbG9zaW5nIEFWUCB0aGF0IGNvbnRhaW5zIHRoZSBTb3VyY2VJRCBBVlAuPC9zcGFuPjwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij42LjQuICBBdHRyaWJ1
dGUgVmFsdWUgUGFpciBmbGFnIHJ1bGVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo
dCI+Ni40LiAgQXR0cmlidXRlIFZhbHVlIFBhaXIgZmxhZyBydWxlczwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90
ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLSs8L3RkPjx0
ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLSs8L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8QVZQIGZsYWcgfDwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB8QVZQIGZsYWcgfDwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHxydWxlcyAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHxydWxlcyAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz
PSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgKy0tLS0rLS0tLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgKy0tLS0rLS0tLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi
PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQVZQICAgU2VjdGlvbiAgICAgICAgICAg
ICAgICAgICB8ICAgIHxNVVNUfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgQVZQICAgU2VjdGlvbiAgICAgICAgICAgICAg
ICAgICB8ICAgIHxNVVNUfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICBB
dHRyaWJ1dGUgTmFtZSAgICAgICAgICBDb2RlICBEZWZpbmVkIFZhbHVlIFR5cGUgICAgICAg
IHxNVVNUfCBOT1R8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICBBdHRy
aWJ1dGUgTmFtZSAgICAgICAgICBDb2RlICBEZWZpbmVkIFZhbHVlIFR5cGUgICAgICAgIHxN
VVNUfCBOT1R8PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgKy0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0r
LS0tLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgKy0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0rLS0t
LSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlm
ZjAwMjAiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgIHw8c3BhbiBjbGFzcz0iZGVsZXRlIj5PQy1Tb3Vy
Y2VJRDwvc3Bhbj4gICAgICAgICAgICAgVEJEMSAgICB4LnggICBEaWFtZXRlcklkZW50aXR5
ICB8ICAgIHwgViAgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgfDxz
cGFuIGNsYXNzPSJpbnNlcnQiPlNvdXJjZUlEICAgPC9zcGFuPiAgICAgICAgICAgICBUQkQx
ICAgIHgueCAgIERpYW1ldGVySWRlbnRpdHkgIHwgICAgfCBWICB8PC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij4gICAgfE9DLVBlZXItQWxnbyAgICAgICAgICAgIFRCRDIgICAg
eC54ICAgVW5zaWduZWQ2NCAgICAgICAgfCAgICB8IFYgIHw8L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJpZ2h0Ij4gICAgfE9DLVBlZXItQWxnbyAgICAgICAgICAgIFRCRDIgICAgeC54
ICAgVW5zaWduZWQ2NCAgICAgICAgfCAgICB8IFYgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPiAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPiAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm
dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij43LiAgSUFOQSBDb25zaWRlcmF0aW9uczwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmlnaHQiPjcuICBJQU5BIENvbnNpZGVyYXRpb25zPC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjcuMS4gIEFWUCBjb2RlczwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjcuMS4gIEFWUCBjb2RlczwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBOZXcgQVZQcyBkZWZpbmVkIGJ5IHRoaXMg
c3BlY2lmaWNhdGlvbiBhcmUgbGlzdGVkIGluIFNlY3Rpb24gNi4gIEFsbDwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIE5ldyBBVlBzIGRlZmluZWQgYnkgdGhpcyBzcGVj
aWZpY2F0aW9uIGFyZSBsaXN0ZWQgaW4gU2VjdGlvbiA2LiAgQWxsPC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij4gICBBVlAgY29kZXMgYXJlIGFsbG9jYXRlZCBmcm9tIHRoZSAn
QXV0aGVudGljYXRpb24sIEF1dGhvcml6YXRpb24sIGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmlnaHQiPiAgIEFWUCBjb2RlcyBhcmUgYWxsb2NhdGVkIGZyb20gdGhlICdBdXRo
ZW50aWNhdGlvbiwgQXV0aG9yaXphdGlvbiwgYW5kPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz
PSJsZWZ0Ij4gICBBY2NvdW50aW5nIChBQUEpIFBhcmFtZXRlcnMnIEFWUCBDb2RlcyByZWdp
c3RyeS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBY2NvdW50aW5nIChB
QUEpIFBhcmFtZXRlcnMnIEFWUCBDb2RlcyByZWdpc3RyeS48L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CgogICAgIDx0cj48dGQ+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkPjwvdGQ+PC90cj4KICAg
ICA8dHIgaWQ9ImVuZCIgYmdjb2xvcj0iZ3JheSI+PHRoIGNvbHNwYW49IjUiIGFsaWduPSJj
ZW50ZXIiPiZuYnNwO0VuZCBvZiBjaGFuZ2VzLiAyMCBjaGFuZ2UgYmxvY2tzLiZuYnNwOzwv
dGg+PC90cj4KICAgICA8dHIgY2xhc3M9InN0YXRzIj48dGQ+PC90ZD48dGg+PGk+MzEgbGlu
ZXMgY2hhbmdlZCBvciBkZWxldGVkPC9pPjwvdGg+PHRoPjxpPiA8L2k+PC90aD48dGg+PGk+
MzUgbGluZXMgY2hhbmdlZCBvciBhZGRlZDwvaT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAg
PHRyPjx0ZCBjb2xzcGFuPSI1IiBhbGlnbj0iY2VudGVyIiBjbGFzcz0ic21hbGwiPjxici8+
VGhpcyBodG1sIGRpZmYgd2FzIHByb2R1Y2VkIGJ5IHJmY2RpZmYgMS40NS4gVGhlIGxhdGVz
dCB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBmcm9tIDxhIGhyZWY9Imh0dHA6Ly93d3cudG9vbHMu
aWV0Zi5vcmcvdG9vbHMvcmZjZGlmZi8iID5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMv
cmZjZGlmZi88L2E+IDwvdGQ+PC90cj4KICAgPC90YWJsZT4KICAgPC9ib2R5PgogICA8L2h0
bWw+Cg==
--------------7E952F8A3BCFA22B2B8CB750--


From nobody Thu May 19 10:08:03 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 8321B12DB2D for ; Thu, 19 May 2016 10:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JKq94ovQWQpH for ; Thu, 19 May 2016 10:07:59 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0106.outbound.protection.outlook.com [65.55.169.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9AC12DB32 for ; Thu, 19 May 2016 10:07:37 -0700 (PDT)
Received: from BL2FFO11FD027.protection.gbl (10.173.160.31) by BL2FFO11HUB021.protection.gbl (10.173.161.45) with Microsoft SMTP Server (TLS) id 15.1.492.8; Thu, 19 May 2016 17:07:35 +0000
Authentication-Results: spf=pass (sender IP is 144.230.32.82) smtp.mailfrom=sprint.com; etsi.org; dkim=none (message not signed) header.d=none;etsi.org; dmarc=bestguesspass action=none header.from=sprint.com;
Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.82 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.82; helo=preapdm3.corp.sprint.com;
Received: from preapdm3.corp.sprint.com (144.230.32.82) by BL2FFO11FD027.mail.protection.outlook.com (10.173.161.106) with Microsoft SMTP Server (TLS) id 15.1.497.8 via Frontend Transport; Thu, 19 May 2016 17:07:35 +0000
Received: from pps.filterd (preapdm3.corp.sprint.com [127.0.0.1]) by preapdm3.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u4JGxmVV001962;  Thu, 19 May 2016 13:07:35 -0400
Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by preapdm3.corp.sprint.com with ESMTP id 231h5fr6g6-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 May 2016 13:07:35 -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.1156.6; Thu, 19 May 2016 13:07:33 -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.1156.000; Thu, 19 May 2016 12:07:33 -0500
From: "Bertz, Lyle T [CTO]" 
To: "jouni.nospam@gmail.com" , "dime@ietf.org" 
Thread-Topic: [Dime] New Liaison Statement, "LS to IETF for clarification on RFC 4006 for Diameter Base Protocol"
Thread-Index: AQHRpmHFQ0BA2lLgP0u3NrLQCgc42J+q8iKAgBVg41A=
Date: Thu, 19 May 2016 17:07:32 +0000
Message-ID: 
References: <20160505000454.8358.57070.idtracker@ietfa.amsl.com> <572B8619.1070405@gmail.com>
In-Reply-To: <572B8619.1070405@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.35]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:144.230.32.82; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(377454003)(377424004)(189002)(199003)(9170700003)(8676002)(87936001)(4326007)(8936002)(2906002)(8746002)(97756001)(189998001)(81166006)(106466001)(15395725005)(102836003)(6806005)(108616004)(3846002)(5001770100001)(92566002)(23726003)(33646002)(6116002)(11100500001)(5008740100001)(86362001)(15975445007)(19580405001)(2950100001)(19580395003)(2900100001)(586003)(5890100001)(5003600100002)(50986999)(54356999)(46406003)(5004730100002)(1220700001)(50466002)(2501003)(47776003)(76176999)(5250100002)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB021; H:preapdm3.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD027; 1:gYUKgxzMSFgKe8qwoX5tnoXnf0AOYyYSYMnQ2tCVmqxTYKCYW0gcACxmX1CDwIn496yQO2ZeGHomse1P8vkwoGhgKv1Z2jCZzqBNKGjNZ/esulbvFxGky0+8P6to2Jys7WnMCsbGjIs1Rf66VVTVjTXkXcXVJPDyURZEjXEKQDBpWI2/BlzYEz9SLCZl/b1ek/M1lTcuyjMrkP2X1KDa+/ah/5WHSjhc9PP4y31CIimYyGVjsrCa65NFHkNYEGY6phYLhrKiqRL0SYbG/4mrT0KrbsaHvTYSDMCOiZPaDTfXqtB163mATdKtyiXaQZ4De/MjfMDOruH48tTNN/XlZon0C7+Nres+DgcLW2LaGVLJ5Csg8j/BvOxTF+gjFudOTw/90nGywWLSaLOOefGhjkjUGoYKpyJ9Pes8iG93PFf6/TaQRIiioWZXGUTShV4GreMPXXFcbWBPctbcQQ2oIHY5oMUTvbfGmwGzE/0Y5zo0lJazuI/FFkrGtdW5mwPs
X-MS-Office365-Filtering-Correlation-Id: 6d81f5ff-6f79-4d68-8246-08d380081320
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB021; 2:O/kHxLYN5csHb/lUT4FC17e0H6u4gaVb8Kzjpp0IEndWgkbrO9QchO9x0YQZu7niBNYZ28dMr+It74Irp3KwQ4SGYpgGvEPMpYttkyEu8oS4ZUasgMIztEkLESm8UKrjU12NGx5CmFDuDOXgPQnq7qZ1ugVqP6oLgEx2RFDqD+ToUAyswYANCwUzEsBecpfT; 3:YOQ0+oMgLIQwlcl+noVPZAYZwIcRXCDpFGoi16mPXA46eJk+75JmlqAa1bkqmEstp/HJrcOOXZDY7kSnEvBJszQn0PlGTsdgLi1Y29a88t8MmRnyVvJv/zWtAUX/SJPTpn6Nw7VT9N5MI7T42Ti9qqLO9K8KkCil7PO/UTu2qcjt5WA8ASkYNujUxNfUH3e92eFngoB9jj78mg+J4e8PTJ6+6TNqIX1NBBYsH8vnYDlmcihmibMXHulGuriVcx1WxJUqbv3utn1o2icclaSXBw==; 25:9ZlBdNVFzt9Bez8M2jG7RtHTOnIjJDU/PaokTb6id8iLdFC1VL0NRnnNhvhsCOd1+mdoaSgg5cb6wn9rnhOgG4v2lCXfyQ0Hfjdlrrga4MNqjFQoQqPfdQF+1X1I+BeLgx4hGpsgXh1aPodJpN8dIwxEQbxYXq4tI/Kyan+AzE8SmJnKN/XjF96N34K3PWkeGL7jHTzNFzLH27SKcDr7uJdO+CDZ19S2oNDZvEmGmM3ID/7m0S/x3coPNSlByCLc7Lb/rFy68gZWltN+R/Boj0f7DCZkd2LrPHWyWKLNXhreCiiM7PdKr2tMcKu8YZTVC+ryWTbkBYAdCUkXt+NB0OBATxG6vlboeUHbAAiBi/6sVijkqVzOl/Rh3Jcn625xrfzYKcbSjFaK2T3VtplpBDJZKted1dleahxHwLdP9fg=
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BL2FFO11HUB021; 
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB021; 20:Qmq7oWh05MTZsNyWILwI3RgaEXJFN79iFtinHtJmNF4FrcGCT7gLO+QHdMNII9OB9hKRWJKmJp05zYeuUwbgvEKqU3H4fFJ3heuXQswB1VbHdFzRuBqRJxsDnRMW2BN17PU2+gkr8AUEVXXJD8UWUheqCqc+OGU5bvSUud3ynvDbDL1n34ilmVOMcDQ4n7uUfA6UlHzuNQI/XFS86Yt2TlL5ElnamZlgBDck/QWInpcgW3AraGhbiehliINLeLNKpGdGUeRKdeEh8YcXsECC0PL/qs+WgBfThK9Z4St0jyqR1JNSgvgDynFRQ1nLEzUyji2sS1SSxwLn+Sa+rKWN4r1J4N5akpsxS8CNofTvFuRLg18xHc/7jM9XU1zJmcP4IfYciUEoBJR1+xpTKAAoYBkgL7s0mWbn+JdoYNxEtU0=; 4:bX2XTDXw5zSRDRl/w6Q+9xQ7r/qpHf6FoP0auu8nVHGqLCbDawNQF0zp4EVozamEq5jhsceM3ZwmfvYK6uGeUOljKDUsgLQIBwkCidHdw5SrQEPHKdGuBrTkiT9fFVGYb2BeX4WEyQdgJZ8VaM32zLthNkxqXmyPm0jg1hq43r26sk48/qgMWhzx6JVOyegOHZevt3BXAEWAmHtKldh6aOsfgFAQXMhXvhaerTsJfRGxDmHYd9REmX6NzF8YmfR9VgI5T/JBshU+KLb+dMZr9SVxUokzRMOwes5Z6wNmcn7juHi2nSg1VqDlUEDNmPXaWK/W6P2gOnjxXcemLkbet8qSnucoIv2nPmbncYtIxawCO/vKyBMtqd5k2+t6kv6i/LLAoBgqkD6fbSaErbHKF1AdCioTYl1U9JKOJ+nCkvQuzGE9lD9UCpG9ktEmiKyCSFSLlQQF8Jg32mX0hr2PgDBB77UUhQXrekU3QDxTwWD7MosKs75kPF+V5MEbK4pRw57oroBYzdSJDfDsa/aTyA==
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(95692535739014);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13024025)(5005006)(13023025)(8121501046)(13015025)(13017025)(13018025)(3002001)(10201501046)(6055026); SRVR:BL2FFO11HUB021; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB021; 
X-Forefront-PRVS: 094700CA91
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB021; 23:8a0U3U8ODPwjwO4we38ETB7SWzk73WKDyZlo3Sek?= =?us-ascii?Q?mgu10/QI8qZGR2kQnrO8A15FrgHH3fkCZWBWGY25Pkvw18otFP+W2aI1bLWW?= =?us-ascii?Q?VJngqpy96Js9NzggofP3Qbg2IqQ4LA7QgBrWX56uMAzhtW+FYzb/cLimaFPR?= =?us-ascii?Q?ynYoix9U27GgIH16t1Px5kBr0+V+0Bx0krjsa9GIvvTDfFUWTCAIzs1lJO66?= =?us-ascii?Q?X7e8btCpTwSQl5qha7bkYrpFMcGc649eIcn2OH1qZUmkhqxfothp3KJxBJUQ?= =?us-ascii?Q?2jSXOj6ikCAB475cYg5ZPL3qyvu/Qo4AXFQ+GS8oFFN/h7z9NfmFkVabILlf?= =?us-ascii?Q?yGyXMWbuY7EAPZXXDUUqfBM4dWEJFpidfccxlYWiCaBr1ddnxhcXbSraOR9O?= =?us-ascii?Q?X1g29mcyr1QX4MYJtpYnTv44+jTg0sFsrpO75JS1jtXwZR9aF12KKouQkylk?= =?us-ascii?Q?l9uZXkfRIWdboAx0ti+YEhHnp+1uuwuafs2iUPp/zKLi2jXtha3ZJp3und4m?= =?us-ascii?Q?pvBFi0jc0HxPTK52C6rRBHIZyMIN5nkstWYXM945GkyEswaEnWM5rc3c23CK?= =?us-ascii?Q?0WLUEiT71vxE3EM6uvSdbwWFXOaV4mX3FZqT/85nAFj5vuoJisA2wp0FwXTi?= =?us-ascii?Q?Jd17NmXkXi9dfHa4L1GbIYmMa+bYZF1TdTwJuGqeabFOBpEkdRzAV7GcnZ9Q?= =?us-ascii?Q?RHJk/xVM4DIbxA6F/Yb9R5bViZ/dl63e0M1hkCUaSHRqMMCQm7YT+rGvEv8m?= =?us-ascii?Q?BhuQnnJkfciermAnSeyPvSfPqfuUicQYQGwl/dImZ6JnJ1LO/yIypKBvFmPp?= =?us-ascii?Q?R4QR2kSxFaxv624ap6U5zh9ps0pR/mJeuahLmcptZK1OGiP6fsDaQ2HYMTmB?= =?us-ascii?Q?Q6WRr73rBLq9LJHumtmE0g1OlJCcDHnwIOGnbN3BdNwikI0Sbc1HMP4lE0++?= =?us-ascii?Q?/y84KzRA9sAuKCfVIWCImfrNwObGWLI23lxYUwW7iJ8kJxWqXY9nBnIPUfLi?= =?us-ascii?Q?EPVKL7+JSfzgoZDNRLGcj2oUtryfdwwV3O420fT4xQx5UGTcDQ/fzXW7R8ak?= =?us-ascii?Q?lL/+31RrFLKBm4lb3I0VuXZCkpNfT5rL0nFbWfSr/YoPDYvW5ez/DQJ3o2hY?= =?us-ascii?Q?eg3xrnJGc3QbxW17WpHLCFTUebcqXWn6HjxBiiLsUdQpvGacBU/hDDIfaagq?= =?us-ascii?Q?2Ga4WYJwXxqUn9EaEaO24tZrRuDtx2jtzSbVlwJi1hCYVpSOmO3ej9hjUjH/?= =?us-ascii?Q?j5tNojfpv+4jBNWOXYe/LtpqIxiAAX/VdM2fiIPnJIT7D4nzCZDJSCbVu6lG?= =?us-ascii?Q?bSv/RAblwz/lk7/NOtthJdg=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB021; 5:VL4fRq0KO/Ry3Sexfsfj89J7o4QGHormTlIaBrbjs3XX7d8IWJ26wdibcrolCdhnJvMO0mY0Xb7mkTKP86VifKXxxujZuJ1AayPQNTOKh/pPfEQWH03rQhZocouh0c0Ag3sfd1chLkBSQXBWpvnL5A==; 24:3LAAp/nGmi2p1KN/TaeBbjAqVBgAzl84JW9jB8GPwehDOBwzpgHQbR7OsWFVPWG8d08NVGKUgDXgCZ/u5RQxol/+Clag21A3bObTbwqaIRs=; 7:ImY4dXD6dlh5mDqv6H+VzEBDAkr148VglglGhrkenM7BZZrWJsRZVINPlSVhb3wNd6+U95IdbFWn2Yt41kLiKwTsNH06vGFgAsXMS/A/KVjiJd/aJEYwSNPZBZATy3yaFdeDN/EdHEo4I2dsUNO3fVH8xCkZEPnc+3jU52202NupYotcRYdKnNKvi1bTbtnU
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: sprint.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 May 2016 17:07:35.5555 (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.82];  Helo=[preapdm3.corp.sprint.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB021
Archived-At: 
Cc: Joel Jaeggli , "3GPPLiaison@etsi.org" <3GPPLiaison@etsi.org>
Subject: Re: [Dime] New Liaison Statement, "LS to IETF for clarification on RFC 4006 for Diameter Base Protocol"
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, 19 May 2016 17:08:01 -0000

Jouni,

I'll take the ball on 4006.

Lyle

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Thursday, May 05, 2016 12:43 PM
To: dime@ietf.org
Cc: Joel Jaeggli ; 3GPPLiaison@etsi.org
Subject: Re: [Dime] New Liaison Statement, "LS to IETF for clarification on=
 RFC 4006 for Diameter Base Protocol"

Folks,

Have a look at the LS we recently received from the 3GPP SA5. Looking at ou=
r charter and what we have discussed recently updating RFC4006 is not likel=
y.. unless someone volunteers to take a ball on it asap.

I have not read RFC4006 for a long time so my memory might serve me wrong. =
The immediate things to look into when responding to this LS (assuming we w=
ould only give recommendations) relate to security.
RFC4006 AVPs seems to care about the AVL 'P' bit setting and 'Encr'.
Since both of these are deprecated in RFC6733 we better say something about=
 that.

Another thing, which is outside the LS scope, though, is the CCA CCF.
Here I am referring to the discussion in Buenos Aires on the answer message=
 when 'E' bit is set.

Any thoughts? We have about a week to prepare the reply LS. The due date is=
 23rd May.

- Jouni


5/4/2016, 5:04 PM, Liaison Statement Management Tool kirjoitti:
> Title: LS to IETF for clarification on RFC 4006 for Diameter Base
> Protocol Submission Date: 2016-05-04 URL of the IETF Web page:
> https://datatracker.ietf.org/liaison/1470/
> Please reply by 2016-05-23
> From: "Maryse Gardella" 
> To: Jouni Korhonen ,Lionel Morand
> 
> Cc: Benoit Claise ,Lionel Morand
> ,Joel Jaeggli ,Jouni
> Korhonen ,Diameter Maintenance and Extensions Dis=
cussion List , Response Contacts: 3GPPLiaison@etsi.org Techn=
ical Contacts:
> Purpose: For action
>
> Body:
> Attachments:
>
>      LS to IETF for clarification on RFC 4006 for Diameter Base Protocol
>
> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-05-04-3gpp-
> tsg-sa-wg5-dime-ls-to-ietf-for-clarification-on-rfc-4006-for-diameter-
> base-protocol-attachment-1.doc
>

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

________________________________
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 Fri May 20 16:02: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 7080D12D662 for ; Fri, 20 May 2016 16:02:41 -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 4j28QoP78PY5 for ; Fri, 20 May 2016 16:02:39 -0700 (PDT)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 2845A12D65E for ; Fri, 20 May 2016 16:02:39 -0700 (PDT)
Received: by mail-pa0-x232.google.com with SMTP id tb2so26529318pac.2 for ; Fri, 20 May 2016 16:02:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:reply-to:references:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=cEMzV6JyLwo3gmyyONRPxb2xwHVjoe/R3RCX8sHGmRU=; b=ShQEsecLDqxp0iAU9YTxHi4QR6r/nzDxCsGn6e5UHewovEVSW2rVfaJjWwaTNuXp2i XWuiOeEX7k39/KwGlADQqX/ca10H4IetX8WMTWy5Cy2ENrQ4D4vMF5PN+naEmJxH+cVx owdsJUpHvzJVr3168gfDdaxyR0K1G0c6nuKBlJGYwuVI3RWoykAmOcrUE0QoaVsT/ulg DYMd8O81G5YCD9hluJ2h6ecMZk3dq1TVCNQMSBrMUs1fAayq7ErZffcAvfwdTB9RMldp IDpaQaO/kXDIg5UtZCEh8e8ZJRZg/x7UFv6h7UP2HX4vDOOl1mRcTA1echz4z1aHRzIB 6rhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:reply-to:references:to:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cEMzV6JyLwo3gmyyONRPxb2xwHVjoe/R3RCX8sHGmRU=; b=LlD8AKFw5AAvu89YP/tH8PGk0bdgBkkFmblhfXWT8WSMJiS1DE/Yl59YJFUk+iEmWY 4VN3WyLtPYeWSfxqgv6t1jo01e5AMdlVE77b9+1cOXAWjOeR6PRdy5zTz07AP87/0ECh v23QovLFW3VZbq18LWmVUxr+F+KPXItnawABRIxYrtyNT4BJjNIIU90E/tIn8fKKqFoo IMku1HKLA5pIabR1v/rL+4KuRguX2cR4gA4h13oBNWhmaFSq3LERnIF1f0ymSC0vLKRq up6fs01YBRMzNGSmzfd6LPpTYmZOWRTWc8kz88HqL6JqPtAgFzEiTwGtj/2+TE0iG1Up 63vg==
X-Gm-Message-State: AOPr4FWTBnFZfajmP//HsaWgxRyH2bl+hwJ0FUWNMmZzUCYsVOtZxOf6YzMHlvLIbO22eA==
X-Received: by 10.66.73.193 with SMTP id n1mr8431379pav.70.1463785358541; Fri, 20 May 2016 16:02:38 -0700 (PDT)
Received: from [10.16.75.74] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id x89sm29496568pfa.87.2016.05.20.16.02.37 for  (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 May 2016 16:02:37 -0700 (PDT)
References: <20160519190342.15488.2118.idtracker@ietfa.amsl.com>
To: "dime@ietf.org" 
From: Jouni Korhonen 
X-Forwarded-Message-Id: <20160519190342.15488.2118.idtracker@ietfa.amsl.com>
Message-ID: 
Date: Fri, 20 May 2016 16:02:33 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <20160519190342.15488.2118.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [Dime] Fwd: NomCom 2016-2017 Call for Volunteers
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: Fri, 20 May 2016 23:02:41 -0000

FYI


-------- Välitetty viesti / Fwd.Msg --------
Aihe: NomCom 2016-2017 Call for Volunteers
Päiväys: Thu, 19 May 2016 12:03:42 -0700
Lähettäjä: NomCom Chair 2016 
Vastausosoite: ietf@ietf.org
Vastaanottaja: IETF Announcement List 

Subject: NomCom 2016-2017 Call for Volunteers

The IETF nomcom appoints folks to fill the open slots on the IAOC, the 
IAB, and the IESG.

Ten voting members for the nomcom are selected in a verifiably random 
way from a pool of volunteers. The more volunteers, the better chance we 
have of choosing
a random yet representative cross section of the IETF population.

The details of the operation of the nomcom can be found in RFC 7437, and 
BCP10/RFC3797 details the selection algorithm.

Volunteers must have attended 3 of the past 5 IETF meetings.  As 
specified in RFC 7437, that means three out of the five past meetings up 
to the time this email announcement goes out to start the solicitation 
of volunteers. The five meetings out of which you must have attended 
*three* are:

IETF = 91 (Honolulu)      \
        92 (Dallas)         \
        93 (Prague)          -*** ANY THREE!
        94 (Yokohama)       /
        95 (Buenos Aires)  /


If you qualify, please volunteer. Before you decide to volunteer, please 
remember that anyone appointed to this Nomcom will not be considered as 
a candidate for any of the positions that the 2016 - 2017 Nomcom is 
responsible for filling.

Some 229 people have already volunteered by ticking the box on the IETF 
95 registration form. 131 of these have been verified as eligible. I 
will contact all of these shortly. Thank you for volunteering!

The list of people and posts whose terms end with the March 2017 IETF 
meeting, and thus the positions for which this nomcom is responsible, are

IAOC:

     Lou Berger

IAB:

     Ralph Droms
     Russ Housley
     Robert Sparks
     Andrew Sullivan
     Dave Thaler
     Suzanne Woolf

IESG:

     Jari Arkko (GEN)
     Deborah Brungard (RTG)
     Ben Campbell (ART)
     Spencer Dawkins (TSV)
     Stephen Farrell (SEC)
     Joel Jaeggli (OPS)     Terry Manderson (INT)
     Alvaro Retana (RTG)


All appointments are for 2 years. The ART and Routing areas have 3 ADs 
and the General area has 1; all other areas have 2 ADs. Thus, all areas 
(with the exception of GEN) have at least one continuing AD.

The primary activity for this nomcom will begin in July 2016 and should 
be completed in January 2017.   The nomcom will have regularly scheduled 
conference calls to ensure progress. There will be activities to collect 
requirements from the community, review candidate questionnaires, review 
feedback from community members about candidates, and talk to candidates.

While being a nomcom member does require some time commitment it is also 
a very rewarding experience.

As a member of the nomcom it is very important that you be able to 
attend IETF97
(Seoul) to conduct interviews. Being at IETF96 (Berlin) is useful for 
orientation.  Being at IETF98 is not essential.

Please volunteer by sending me an email before 23:59 UTC June 20, 2016, 
as follows:

To: nomcom-chair-2016@ietf.org
Subject: Nomcom 2016-17 Volunteer

Please include the following information in the email body:

Your Full Name: __________
     // as you write it on the IETF registration form
Current Primary Affiliation:
     // Typically what goes in the Company field
     // in the IETF Registration Form
Emails: _______________
    // All email addresses used to register for the past 5 IETF meetings
    // Preferred email address first
Telephone: _______________________
     // For confirmation if selected

You should expect an email response from me within 5 business days 
stating whether or not you are qualified.  If you don't receive this 
response, please re-send your email with the tag "RESEND"" added to the 
subject line.

If you are not yet sure if you would like to volunteer, please consider 
that nomcom members play a very important role in shaping the leadership 
of the IETF.
Questions by email or voice are welcome. Volunteering for the nomcom is 
a great way to contribute to the IETF!

You can find a detailed timeline on the nomcom web site at:
     https://datatracker.ietf.org/nomcom/2016/

I will be publishing a more detailed target timetable, as well as 
details of the randomness seeds to be used for the RFC 3797 selection 
process, within the next few weeks.

Thank you!

Lucy Lynch
llynch@civil-tongue.net
nomcom-chair-2016@ietf.org


From nobody Sat May 21 06:29: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 3B85A12D583 for ; Sat, 21 May 2016 06:29:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.647
X-Spam-Level: 
X-Spam-Status: No, score=-5.647 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, RP_MATCHES_RCVD=-1.426, 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 XBDSSk3nohxx for ; Sat, 21 May 2016 06:29:11 -0700 (PDT)
Received: from TELEDG001RM001.telecomitalia.it (teledg001rm001.telecomitalia.it [217.169.121.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47E512D0AA for ; Sat, 21 May 2016 06:29:10 -0700 (PDT)
Received: from TELMBXB04RM001.telecomitalia.local (10.14.252.31) by TELEDG001RM001.telecomitalia.it (10.19.3.111) with Microsoft SMTP Server (TLS) id 14.3.266.1; Sat, 21 May 2016 15:29:07 +0200
Received: from TELMBXA05RM001.telecomitalia.local (10.14.252.32) by TELMBXB04RM001.telecomitalia.local (10.14.252.31) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 21 May 2016 15:29:07 +0200
Received: from TELMBXA05RM001.telecomitalia.local ([fe80::cce8:4f15:2cf1:376]) by TELMBXA05RM001.telecomitalia.local ([fe80::cce8:4f15:2cf1:376%19]) with mapi id 15.00.1178.000; Sat, 21 May 2016 15:29:07 +0200
From: D'Alessandro Rosalia 
To: "dime@ietf.org" 
Thread-Topic: handling of unexpected direction of the messages  
Thread-Index: AdGycTKgUsA9NH7WQA+Ug64kPPGAgwA83xsy
Date: Sat, 21 May 2016 13:29:07 +0000
Message-ID: 
References: <7dbb33b925b34d25956c4a9d100c53b3@TELMBXA05RM001.telecomitalia.local>
In-Reply-To: <7dbb33b925b34d25956c4a9d100c53b3@TELMBXA05RM001.telecomitalia.local>
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.14.252.240]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [Dime] FW: handling of unexpected direction of the messages
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, 21 May 2016 13:29:13 -0000

Dear All,
TIM would like to submit a question on how to handle the conditions when a =
Diameter node receives an unexpected message from another Diameter peer ent=
ity.
The specific scenario we are addressing is when a node named A gets a Diame=
ter message which is correct from the protocol viewpoint but shall not be s=
ent to this node A because this node A is not expected to receive the messa=
ge but to send it from the application viewpoint. As an example this happen=
s when the receiving node A is the legitimate sender of the message. Conseq=
uently this node A should expect an answer for this message and not a reque=
st.

In our opinion, if an entity receives a request that it should not receive =
because, in the protocol, it should send the request and wait for the answe=
r, this is clearly an error case. The request should not be processed and t=
he result-code to use could be "DIAMETER_COMMAND_UNSUPPORTED"  (command cod=
e not supported by the receiver) or alternatively, DIAMETER_UNABLE_TO_COMPL=
Y.

It seems that in the current version of the RFC 6733 this condition is not =
clearly addressed and we would like to include this case.
What is your opinion?

Looking forward to your reply,

Rosalia d=92Alessandro

------------------------------------------------------------------
Telecom Italia Information Technology
Rosalia d=92Alessandro
Technical Security.SecurityLab
G.Reiss Romoli, 274, 10148 Torino
+39 011 228 8217
+39 3316001152



From nobody Mon May 23 09:31:03 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 282F512D9CF; Mon, 23 May 2016 09:31:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Meeting Session Request Tool\"" 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160523163101.20979.37924.idtracker@ietfa.amsl.com>
Date: Mon, 23 May 2016 09:31:01 -0700
Archived-At: 
Cc: dime-chairs@ietf.org, dime@ietf.org, jounikor@gmail.com
Subject: [Dime] dime - New Meeting Session Request for IETF 96
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: Mon, 23 May 2016 16:31:02 -0000

A new meeting session request has just been submitted by Jouni Korhonen, a Chair of the dime working group.


---------------------------------------------------------
Working Group Name: Diameter Maintenance and Extensions
Area Name: Operations and Management Area
Session Requester: Jouni Korhonen

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 35
Conflicts to Avoid: 
 First Priority: stir abfab v6ops 6man oauth radext dmm detnet




Special Requests:
  
---------------------------------------------------------


From nobody Mon May 23 12:13: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 A660612DAB6 for ; Mon, 23 May 2016 12:13:02 -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 9iaCnChBr3iM for ; Mon, 23 May 2016 12:13:01 -0700 (PDT)
Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 AAED212DAB3 for ; Mon, 23 May 2016 12:12:59 -0700 (PDT)
Received: by mail-pa0-x234.google.com with SMTP id bt5so64868057pac.3 for ; Mon, 23 May 2016 12:12:59 -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=Sb9FCvlHqzrlNhreppYrAxKqgb4ibp71rla/fBAUxSw=; b=sG4AA/LjTnDfP28sELVjcysiuZsfeDFg6hA/5rgaWl1DFrA+ekKJRZmh4owBtpfhLx PkS/xgDbQ2UaNPGWR/zNMmVizn3/28Ji99qsDxA2ejkg1mr109DWWnbBXg7HgLxnSnon q4K0u6/+ZNycp6SY2Ql+Ddq8YWqIJvx8g/nt903s/IdzT0n9YJVCDg2aNLYvU+K9SfDu 6RBMXaQPc5NsCnE3ERo6cbe/NvJB1knCezeuYY7k8Wd4G7ZcEoEORu07Dk1G1Wb6fVpM CVHrYRa9Qr18Qw/5KluVUc52UfyNmfzd3RecG1IpAhkMdCQ0B9Mi1FQsD6O4d69kv4QE j4QA==
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=Sb9FCvlHqzrlNhreppYrAxKqgb4ibp71rla/fBAUxSw=; b=MArXskfXPRdlDixytqNmdFuej2CZoocQ2B12fFNhs1I/5cfj/UCjZ1SmXciSdQHH6t 03es7AWhzWJ905br5/8eDHp9PfISVWGvD2YXUTZROUah1ED8Ad3lkcr3n1V0O3hW6icN cJ2FRP/PTSF/M/2tTcncIbdKkWulQOc8YlTH/VKtfv+D5fcCbdO49HVm8sQH6n+hGDFn YpwlH0v1Q5sclfy0/+i21ZAyfHeDFScfBfrLJeDVg6FySi0SjyklfnD5wnREnPGc7otH uoOe77rupRST6dnnyA996itaFKRix+VZn3C4jQpCtpPYkX0pbC7uuZqBtYoq/omG66sn hFMg==
X-Gm-Message-State: ALyK8tK6wBDMDdXu/0jOo6Tyyhtwsr2Nvy5ASSmEL00Ldiu+jMGmgmqC329oCge60YbeBg==
X-Received: by 10.66.6.98 with SMTP id z2mr587473paz.95.1464030779213; Mon, 23 May 2016 12:12:59 -0700 (PDT)
Received: from [10.16.65.166] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id 74sm13917762pfv.8.2016.05.23.12.12.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2016 12:12:58 -0700 (PDT)
To: "dime@ietf.org" , Jouni , "Lionel.morand@orange.com" 
From: Jouni Korhonen 
Message-ID: <5bba2470-8921-f7db-0f1b-aad280eae684@gmail.com>
Date: Mon, 23 May 2016 12:12:55 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05
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, 23 May 2016 19:13:02 -0000

Folks,

This email starts the WGLC #1 for draft-ietf-dime-agent-overload-05. 
Please, review the document, post your comments to the mailing list and 
also insert them into the Issue Tracker with your proposed resolution.

WGLC starts: 5/23/2016
        ends: 6/6/2016 EOB PDT

- Jouni & Lionel


From nobody Tue May 24 08:30: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 DCCC512D0C4 for ; Tue, 24 May 2016 08:30:33 -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 tTVTxj6BDV-o for ; Tue, 24 May 2016 08:30:32 -0700 (PDT)
Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 8FAEB12D887 for ; Tue, 24 May 2016 08:30:32 -0700 (PDT)
Received: by mail-pf0-x244.google.com with SMTP id 145so2528614pfz.1 for ; Tue, 24 May 2016 08:30:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=reply-to:to:cc:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=XIwoKDa6oR5b65/kNwnpspmYZ57W/y5Mt0k378olQcc=; b=znxZTQ6D3B1mzXilGod7de8nj8hGpQr/KtHAN8VsCsjuv+BuKveobjGLG09kaLeBND oGwn51lWc3JwDIkNZFAX0fzNOQj74Rlo6a7RwvMt8/ktmAF6XMkg2qerA4ypkSIQKevS O2ZJPAbTFfQcokO/NK/rPRZVt6SxUkmBh5H1ugZAU/m0XriQ9bVGjMe9w7sEzeOgPC/N MKLOTxM/fwOFoB16/y5H+i+QWjVJ2gO5hVMpml6f/DZQ5mxTWP1yEV+spu6kk+tUf01w VkICcUypBLowLfPYrOg1zpD9DD5l1IFpDFpuLCQfKAC/P1m5AuQ7UuA784tVMtwDGBS7 2xIQ==
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:cc:from:subject:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=XIwoKDa6oR5b65/kNwnpspmYZ57W/y5Mt0k378olQcc=; b=T3SSGGdkGi8zYydOCK/bnNFpmL7AL/w0N2SsI74UyRjVOhkJZ/lHD9XlNSWNpcKwcZ 56VSnHFrVSH9e1f1piEhoZ4KuplheGZa0lKV5pxKctjDXLqwiU1yrSBLUn/boqds9g7M X2Sc4ysr/G6j1w2XuX7fpwVcB4MIoWQa3CB9tGotTb+87pDrj1Ir3o8oMpLNSgn7FGnC 8gw1kn9OKJLB93pmzYfWjhwCEspWFwQHe1ilN4VLNRMVPYi6kCztMFnx7UeITOfRdYDe PxLd9Cadgn0B5D68tmjg+0zVH5NA6YSFohHSc0qf8kIlKU/DXo5ZPLa63bZrCQPWZzQx 6avQ==
X-Gm-Message-State: ALyK8tLJIkHOYgKBbcP9IPChX/4Yp1Om85N9VHNegckZavGdEsCCOBC5mh11tTNbCM2PiQ==
X-Received: by 10.98.10.19 with SMTP id s19mr3635448pfi.71.1464103832165; Tue, 24 May 2016 08:30:32 -0700 (PDT)
Received: from [10.16.65.166] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id ez6sm6161664pab.12.2016.05.24.08.30.30 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2016 08:30:31 -0700 (PDT)
To: "dime@ietf.org" 
From: Jouni Korhonen 
Message-ID: <5b31616d-efa3-ac03-8f1c-bd8883a35d65@gmail.com>
Date: Tue, 24 May 2016 08:30:27 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Dime] WGLC #1 for draft-ietf-dime-load-02
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, 24 May 2016 15:30:34 -0000

Folks,

This email starts the WGLC #1 for draft-ietf-dime-load-02. Please, 
review the document, post your comments to the mailing list and also 
insert them into the Issue Tracker with your proposed resolution.

WGLC starts: 5/24/2016
        ends: 6/7/2016 EOB PDT

- Jouni & Lionel


From nobody Wed May 25 10:43:50 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 3E7CE12D887 for ; Wed, 25 May 2016 10:43:48 -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 QcVnFJU7IOfQ for ; Wed, 25 May 2016 10:43:47 -0700 (PDT)
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (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 24C7412D8A0 for ; Wed, 25 May 2016 10:43:47 -0700 (PDT)
Received: by mail-pa0-x236.google.com with SMTP id qo8so19784392pab.1 for ; Wed, 25 May 2016 10:43:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=reply-to:to:cc:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=jybHMssT6bVFHnVRWk3T7yKXKkcQ8moSGPrihtmvklk=; b=RH+ajWc4MSHHYOmAIN5arwAg0HNZzB8VsBRg4JRKo3wX6rZ+ANJ5Ocv5rojqSc+6G1 PXGq70GltR8J81aKWOxIcqXXo27EE8uqjH2aYK3A3rFHG5U0fD3PfEhxX69LVq344iXz cPttQ4wq9/iakxYuN46aSlPGClhnMh326iaGwfTYoNXEz126SJP13UO3k0OPFQABKwn7 M8bkeuV4REAuStL4wz+cVjKK4PsIdYiEerUj0XiEm+rsCmmj36jZojtwEGq0Xa7JosVW iBwLJnBoquVOKVZqpTpCHEFNGWMU8nW39gMBkY3EH5s+73aUTzTX68bSN6g2TU+6l+V0 yIhw==
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:cc:from:subject:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=jybHMssT6bVFHnVRWk3T7yKXKkcQ8moSGPrihtmvklk=; b=VkZbfcvOq8na/V7vdoV3yJtCmLeTz8oAMQfzGSUiD71d/g3EjGzGQ7hFok4demB0R7 Z9cMcYch/eYv8wgRiVl4ctxlFJ1QtnCRq9Zg+abMeo+LOP2IJ4GjYccULA5lWckN2Gmd sJlSav85qKsx0fBnb3/DrzAKkdyNArbaRrjmb6001KIpui+MD21HZDZhY2eeGzjWfrL2 y0jG9w3Ea5nGeAU+V3GxV7DuvS1uZHVQYAezasyaY1fDC8TZMjh0PFpth+AKF2D6drWN VqwKeBAmezdI3b6XN3Vnx+awA4K6UNXDYWX3qk3Q2J3Ja9jPniTyZjEio/xLa5323yvK 1Eog==
X-Gm-Message-State: ALyK8tJXc/uh4cF+EUIo3EEuMFg+T/2fOVO57b3PUUXX6Bg9r01yyYSv8ysC8KDWSknggA==
X-Received: by 10.66.66.42 with SMTP id c10mr7571776pat.119.1464198226561; Wed, 25 May 2016 10:43:46 -0700 (PDT)
Received: from [10.16.65.166] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id i6sm63347941pfc.65.2016.05.25.10.43.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2016 10:43:45 -0700 (PDT)
To: "dime@ietf.org" 
From: Jouni Korhonen 
Message-ID: 
Date: Wed, 25 May 2016 10:43:43 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Dime] WGLC #1 draft-ietf-dime-doic-rate-control-03
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: Wed, 25 May 2016 17:43:48 -0000

Folks,

This email starts the WGLC #1 for draft-ietf-dime-doic-rate-control-03. 
Please, review the document, post your comments to the mailing list and 
also insert them into the Issue Tracker with your proposed resolution.

WGLC starts: 5/25/2016
        ends: 6/8/2016 EOB PDT

- Jouni & Lionel


From nobody Fri May 27 05:30: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 8D76812D5C9 for ; Fri, 27 May 2016 05:30:38 -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 M-80iLCF8rIM for ; Fri, 27 May 2016 05:30:35 -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 8345612D572 for ; Fri, 27 May 2016 05:30:20 -0700 (PDT)
X-AuditID: c1b4fb2d-f79936d0000030e4-97-57483ddaebbb
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F4.79.12516.ADD38475; Fri, 27 May 2016 14:30:18 +0200 (CEST)
Received: from ESESSMB101.ericsson.se ([169.254.1.45]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0294.000; Fri, 27 May 2016 14:30:18 +0200
From: Maria Cruz Bartolome 
To: "jouni.nospam@gmail.com" , "dime@ietf.org" , "Lionel.morand@orange.com" 
Thread-Topic: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05
Thread-Index: AQHRtScjgLxS0Hs/VUWoFFfQd/sxcp/Kx0Eg
Date: Fri, 27 May 2016 12:30:17 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92181E2DAF@ESESSMB101.ericsson.se>
References: <5bba2470-8921-f7db-0f1b-aad280eae684@gmail.com>
In-Reply-To: <5bba2470-8921-f7db-0f1b-aad280eae684@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbE9SveWrUe4QdNnS4u5vSvYLPava2Cy uL0904HZY+esu+weS5b8ZPJoeXaSLYA5issmJTUnsyy1SN8ugSvj2Ld5bAWdbhUbD5U3MO42 62Lk5JAQMJHYvHA1E4QtJnHh3nq2LkYuDiGBI4wSXZ+ms0M4ixklth35yQZSxSZgJ3Hp9Asm kISIQD+jxOwLE8ESwgKOEmu3z2AEsUUEnCS+HXjICmEbSUy6eQxsBYuAqsTNz9vA6nkFfCWm noQYKiRgI9G09jFYDaeArcS6P/vB4oxAJ30/tQYsziwgLnHryXyoUwUkluw5zwxhi0q8fPyP FcJWklh7eDsLRL2OxILdn9ggbG2JZQtfM0PsFZQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlW MYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgTGzsEtv3V3MK5+7XiIUYCDUYmH90Ghe7gQa2JZ cWXuIUYJDmYlEd51Nh7hQrwpiZVVqUX58UWlOanFhxilOViUxHn9XyqGCwmkJ5akZqemFqQW wWSZODilGhg9Ck0imtP0vyw7W7nsaprVTweh2uRPW/U/t+vm2Yo3rWCudLObGtJpWaDN6XI1 9OTGeuOVzgcntfol5S1eodbWt2nFp8pHmh8Xnai/47F+lYHdbekdMc71VXeicyQdD6/RLbjy sLBPZtIh/fqvFdGHY1T+F588sfKeTEQiy/f4FRnRGv8PMSixFGckGmoxFxUnAgCNWTHTmQIA AA==
Archived-At: 
Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05
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, 27 May 2016 12:30:38 -0000

Hello all,

I would like to provide some questions, proposed changes and typos, see in =
different sections to ease reading.
Best regards
/MCruz


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D  SOME QUESTIONS =3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D:

1. Clause 2
Why for the definition of Diameter Node and Endpoint there is an specific m=
ention of the RFC6733?

2. Clause 5.2.3
  "In all cases, if the reacting node is a relay then it MUST strip the
   OC-OLR AVP from the message."

   But, will the relay react against the overload report received? i.e. is =
it a "reacting node" or it is just relaying the message?



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PROPOSED CHANGES =3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D:

1. Clause 2:
   Reacting Node
      A DOIC Node that receives and acts on a Diameter overload report.

  Proposed:
      A DOIC Node that receives and acts on a DOIC overload report.
 =20
2. Clause 3:

Now:
   This section outlines representative use cases for the peer report
   used to communicate agent overload.
   There are two primary classes of use cases currently identified,
   those involving the overload of agents and those involving overload
   of Diameter endpoints (Diameter Clients and Diameter Servers) that
   wish to use an overload algorithm suited controlling traffic sent
   from a peer.

Proposed:
   This section outlines representative use cases for the peer report
   used.
   There are two primary classes of use cases currently identified,
   those involving the overload of agents and those involving overload
   of Diameter endpoints that
   wish to use an overload algorithm that requires controlling traffic sent
   towards peers.

Reasoning:
  For the second use case considered the peer report does not communicate a=
gent overload, but Diameter server overload.
  Diameter Endpoint is already defined.
 Last sentence as it is, it is a bit difficult to understand.

3. Clause 3.1.1

Now:
This will result in the throtting of the abated traffic
   that would have been sent to the agent, as there is no alternative
   route, with the appropriate indication given to the service request
   that resulted in the need for the Diameter transaction.

Proposed:
  This will result in the queuing (temporally at least) and/or the throttli=
ng of the abated traffic
   that would have been sent to the agent, as there is no alternative
   route.

Reasoning:
   Traffic could be queued, at least temporally, before being throttled.
   I do not think it is required to inform about what is sent back to the o=
riginator of the initial request.=20


4. Clause 3.1.2

Now:
The second case, in Figure 4, illustrates the case where the
   connections to the agents are both actively used.  In this case, the
   client will have local distribution policy to determine the
   percentage of the traffic sent through each client.

Proposed:
The second case, in Figure 4, illustrates the case where the
   connections to the agents are both actively used.  In this case, the
   client will have local distribution policy to determine the
   traffic sent through each client.

Reasoning:
Avoid using "percentage of traffic" since it seems to imply that the "selec=
tion" of each agent is based in an algorithm that bases the distribution in=
 traffic percentages, what is just a particular case.


5. Clause 3.1.2

"In the case where one of the agents in the above scenarios become
   overloaded, the client should reduce the amount of traffic sent to
   the overloaded agent by the amount requested. "

This paragraph only applies to Figure 4, it does not apply to the Active/St=
andby case.=20


6. Clause 3.1.2

   In the case where both agents are reporting overload, the client may
   need to start decreasing the total traffic sent to the agents.  This
   would be done in a similar fashion as discussed in section *3.1.*

   *3.1* should be *3.1.1*

7. Clause 3.1.3

"Another example of this type of
   deployment is when there are multiple sets of servers, each
   supporting a subset of the Diameter traffic."

  This example does not include an "agent chain", since for each Client-Ser=
ver connection there is only one single Agent in the chain, right?


8. Clause 4

"Any messages that survive throttling due
   to host or realm reports should then go through abatement for the
   peer overload report."

  There is an interaction between PEER and HOST reports. The reduction of t=
raffic towards a HOST reduces as well the traffic through the agents in the=
 path. This should be taken into account when applying reduction for that p=
articular PEER. However, depending on the routing schema it may not be stra=
ight forward to identify what is the reduction for each agent path when red=
ucing traffic towards a HOST.


9. Clause 5.1.2
 Now: =20
 The following are indications that the peer does not support the
   OC_PEER_REPORT feature:

      The request does not contain an OC-Supported-Features AVP.

      The received request contains an OC-Supported-Features AVP with no
      OC-Feature-Vector.

      The received request contains an OC-Supported-Features AVP with a
      OC-Feature-Vector with the OC_PEER_REPORT feature bit cleared.

      The received request contains an OC-Supported-Features AVP with a
      OC-Feature-Vector with the OC_PEER_REPORT feature bit set but with
      a SourceID AVP with a DiameterIdentity that does not match the
      DiameterIdentity of the peer from which the request was received.

Proposal
	(remove)

Reasoning
   This explanation is not required, this is covered by the following parag=
raph:
   "The peer supports the OC_PEER_REPORT feature if the received request
   contains an OC-Supported-Features AVP with the OC-Feature-Vector with
   the OC_PEER_REPORT feature bit set and with a SourceID AVP with a
   Diameter ID that matches the DiameterIdentity of the peer from which
   the request was received."


10. Clause 5.2

  Now
	5.2.  Peer Report Overload Report Handling

Proposed:
	5.2.  Peer Overload Report Handling


11. Clause 5.2.1.1
Now:
   If different abatement specific contents are sent to each peer then
   the reporting node MUST maintain a separate *peer* node peer report OCS
   entry per peer to which a peer overload report is sent.

Proposed:
   If different abatement specific contents are sent to each peer then
   the reporting node MUST maintain a separate *reporting* node peer report=
 OCS
   entry per peer to which a peer overload report is sent.


12. Clause 5.2.1.2
Is any reason why "Validity Duration" is not included as possible informati=
on?

13. Clause 5.2.2
Now:  =20
A reporting node SHOULD create a new Reporting Node Peer Report OCS
   entry Section 5.2.1.1 in an overload condition *and* sending a peer
   overload report to a peer for the first time.

Proposed:=20
   A reporting node SHOULD create a new Reporting Node Peer Report OCS
   entry Section 5.2.1.1 in an overload condition *when* sending a peer
   overload report to a peer for the first time.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TYPOS=3D=3D=3D=3D=3D=3D=3D=3D:
1. Clause 2:
Reporting Node
      A DOIC Node that sends *and* overload report in a Diameter answer
      message.
   =20
    *and* should be *an*  =20

2. Clause 2:
*DIOC* Node
*DIOC* should be *DOIC*

3. Clause 3.1.1
This will result in the *throtting* of the abated traffic

4. Clause 3.1.3
   The handling of peer overload reports is similar to that discussed in
   section *2.2*. =20
  *2.2* is incorrect, not sure though which is the right section.

5. Clause 5.1.1
      Note: The sender of a request can be a Diameter Client or Diameter
      Server that originates the *Diamter* request or a Diameter Agent
      that relays the request.

6. Clause 5.1.1
    Supported-Features AVP, a DOIC node that *supuports* the OC_PEER_REPORT

7. Clause 5.2.5
If the request matches *and* active OCS then

8. Clause 5.2.5
meaning that *it* the reporting node

9. Clause 6.3
In the case of peer reports, the SourceID AVP indicates the node that
   support *for* this feature



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: lunes, 23 de mayo de 2016 21:13
To: dime@ietf.org; Jouni; Lionel.morand@orange.com
Subject: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05

Folks,

This email starts the WGLC #1 for draft-ietf-dime-agent-overload-05.=20
Please, review the document, post your comments to the mailing list and als=
o insert them into the Issue Tracker with your proposed resolution.

WGLC starts: 5/23/2016
        ends: 6/6/2016 EOB PDT

- Jouni & Lionel

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Fri May 27 13:42:24 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 58F2412D0F5; Fri, 27 May 2016 13:42:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Kathleen Moriarty" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160527204220.11055.32993.idtracker@ietfa.amsl.com>
Date: Fri, 27 May 2016 13:42:20 -0700
Archived-At: 
Cc: draft-ietf-dime-e2e-sec-req@ietf.org, dime@ietf.org, dime-chairs@ietf.org
Subject: [Dime] Kathleen Moriarty's No Objection on draft-ietf-dime-e2e-sec-req-04: (with COMMENT)
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, 27 May 2016 20:42:20 -0000

Kathleen Moriarty has entered the following ballot position for
draft-ietf-dime-e2e-sec-req-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-e2e-sec-req/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Radia raised some very good questions in her SecDir review and I don't
see a response yet, so I'm guessing you didn't see her message.
https://www.ietf.org/mail-archive/web/secdir/current/msg06573.html

I'd like to see her questions addressed.

Is her second question the result of a typo or does air interface refer
to a wireless interface or diameter term?

I'll switch to a yes after these are addressed.  thanks.



From nobody Sun May 29 05:28: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 07A2012D1DD; Sun, 29 May 2016 05:28:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level: 
X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=ALz8ujLb; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=aTEyf212
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 g5QdXMQKmJgW; Sun, 29 May 2016 05:28:28 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F21AE12D1D6; Sun, 29 May 2016 05:28:27 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 527CB205AA; Sun, 29 May 2016 08:28:27 -0400 (EDT)
Received: from web6 ([10.202.2.216]) by compute7.internal (MEProxy); Sun, 29 May 2016 08:28:27 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=gUHLSPCYnWt3YW0SWkTjLhjORCI=; b=ALz8uj LbvUQBZ4PQ6Wxhm1b30yD4BzyU17k8RnIyVmwA5CRExDRFJwWyvLcUDNFrp5GSTc jq3IdfwL0eW+agZrr6rz73u32A6ekvxBVOuqazfzD6LdiA/G5ELxy6MbwIrHYp3+ nugZ9nGkiCnqiFTBYd3b9hyeJogsE3i3uRdIU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=gUHLSPCYnWt3YW0 SWkTjLhjORCI=; b=aTEyf2122gZBI82gcfOFxkOb/e0D9FhSn86L/gGkH1AEa5B IRhtPj48RUunMABoWH+7WNfu0TskQwQ3jitJHr8u5Pk2SVi8LMIj08Zm1eUqq8Cr 9LjRoSEvghTc1sNoIoX5PZtedqKNkeaaetN9YuVVKbJWmNpqnCDhzBinWAKQ=
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 106D51E38D; Sun, 29 May 2016 08:28:27 -0400 (EDT)
Message-Id: <1464524906.507204.621875065.5A6A91A2@webmail.messagingengine.com>
X-Sasl-Enc: H/uUejNiLKzjd40sBAhFEimcVLiTfh8Rk5M5MTriF0r7 1464524906
From: Alexey Melnikov 
To: Mirja Kuehlewind  (IETF)
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-b882aaad
Date: Sun, 29 May 2016 13:28:26 +0100
In-Reply-To: 
References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com>   <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net>   <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> <57324CE8.6040109@usdonovans.com> <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net>  <6EF5DC36-1BEF-47EE-BB3B-83BE5E115AE3@kuehlewind.net> <993A9C1D-1B91-4A6D-B7DA-F5E829763E17@fastmail.fm> 
Archived-At: 
Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG 
Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?=
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, 29 May 2016 12:28:30 -0000

Hi,
Finally getting back to this.

I think authors did a good job in the latest version by adding sections
1.1 (Applicability) and 10 (Considerations When Defining Application
Priorities).

I would like to suggest the following clarification:

In Section 8:

Unchanged:
   Diameter nodes MUST have a default priority to apply to transactions
   that do not have an explicit priority set in the DRMP AVP.

OLD:
   Diameter nodes SHOULD use the PRIORITY_10 priority as this default
   value.

NEW:
   In order to guaranty consistent handling of messages from nonupgraded
   Diameter clients,
   Diameter nodes SHOULD use the PRIORITY_10 priority as this default
   priority value. PRIORITY_10 is a mid range priority that corresponds
   to "normal" traffic and thus would be a suitable default for most
   deployments,
   while still allowing different Diameter applications to designate
   other
   priorities for lower and higher priority traffic.

Best Regards,
Alexey

On Wed, May 11, 2016, at 06:39 PM, Mirja Kuehlewind (IETF) wrote:
> Hi Alexey,
>=20
> yes, please provide some text and maybe a warning.
>=20
> I=E2=80=99ve cleared my discuss as no actual changes to the spec are need=
ed based
> on the common understand we have now, however, I would still like to see
> further text in the doc about points that came up in this discussion.
>=20
> Thanks!
> Mirja
>=20
>=20
> > Am 11.05.2016 um 13:13 schrieb Alexe Melnikov :
> >=20
> > Hi Mirja,
> >=20
> >> On 11 May 2016, at 07:07, Mirja Kuehlewind (IETF)  wrote:
> >>=20
> >> Okay let me go for an example here and see if that can be a use case t=
hat we are talking about.
> >=20
> > Yes, this is helpful.
> >>=20
> >> You have a system where some clients run a communication service for e=
mergency doctors as well as for firefighters and then there are also =E2=80=
=9Anormal=E2=80=98 users that run some kind of communication service.
> >>=20
> >> Now you actually have an emergency: some part of the system is down an=
d the number of request is high such that the system is overloaded.
> >>=20
> >> Both the emergency doctors have would have two different priority clas=
ses, one for important message about instruction (what and where people sho=
uld do something) and one for communication between the doctors/firefighter=
s which has still higher priority than any other communication of the other=
 people (as you assume doctors and firefighters are more responsible to not=
 misuse this communication channel).
> >>=20
> >> Now only the emergency doctors communication service was upgraded to u=
se this extension, but the firefighter=E2=80=99s administrations is just to=
o slow or they currently have not enough money because they have specialize=
d expensive hardware and software that is not easy to change.
> >=20
> > "Doctor, it hurts when I do that..." - "Don't do that!"
> >=20
> > I don't think this would be a common deployment case.
> >=20
> > I agree that there is an issue in the scenario you specified. Default p=
riority helps with a single application + normal (unupgraded) traffic. I do=
 think it helps with the most common case. So instead of having lots of SHO=
ULDs and MAYs, I suggest we add text describing possible issues and when mu=
ltiple DIAMETER applications are deployed we either recommend that all clie=
nts are upgraded to support this extension at the same time or at least dep=
loyments specify compatible policies for different applications.
> >=20
> > I can suggest some text.
> >=20
> >> Is it okay in this situation that the private chat of two doctors abou=
t their last ski-holidays starves requests to access the network to send in=
structor message to the firefighters?
> >=20
> > We can't prevent all problems like this, as the above is really a socia=
l problem combined with misconfiguration. But we can warn about it.
> >>=20
> >> (And how do i make sure that that all other other requests actually se=
lect a lower priority than 10=E2=80=A6? But that=E2=80=99s a different ques=
tion=E2=80=A6)
> >>=20
> >> Mirja
> >>=20
> >>=20
> >>> Am 11.05.2016 um 06:59 schrieb Alexey Melnikov :
> >>>=20
> >>> Hi Mirja,
> >>>=20
> >>> On 10 May 2016, at 17:59, Mirja Kuehlewind (IETF)  wrote:
> >>>=20
> >>>>>> I don=E2=80=99t think it is a good idea to assign a default priori=
ty to non-priority-defined requests at all. If you have high priority traff=
ic that does not support this extension (yet) this traffic could be starved=
 by lower priority traffic when assigning a middle range priority. I don=E2=
=80=99t think that is what you want to achieve.
> >>>>> SRD> Actually, this is what we want to achieve.  It is an requireme=
nt that messages explicitly marked as high priority get treated even if it =
results in starving lower priority messages.  The starving of lower priorit=
y messages is not an problem, it is a requirement.
> >>>>=20
> >>>> I think we are still talking past each other.
> >>>=20
> >>> Most definitely :-).
> >>>=20
> >>>> If you explicitly assign a priority, starvation might be okay. Howev=
er, if you don=E2=80=99t have a priority explicitly signaled, the transacti=
on might have a very high priority
> >>>=20
> >>> So some agent in the system needs to decide that a transaction is imp=
ortant.
> >>>> but you just don=E2=80=99t know and by assigning a random mid-range =
priority this important request could get starved.
> >>>=20
> >>> Here I disagree with you, because the way to know that a transaction =
is important is to upgrade client to explicitly assign high priority to it.=
 So default priority is a backward compatibility mechanism, that would work=
 for most common cases. You seem to be suggesting that when this extension =
is deployed all clients need to be updated at the same time. This is not re=
alistic.
> >>=20
> >=20
>=20


From nobody Mon May 30 04:34:11 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 567AD12D5B4 for ; Mon, 30 May 2016 04:34:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.328
X-Spam-Level: 
X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 CfLHwnpe6ets for ; Mon, 30 May 2016 04:34:06 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6EB612D52A for ; Mon, 30 May 2016 04:34:05 -0700 (PDT)
Received: (qmail 5568 invoked from network); 30 May 2016 13:34:02 +0200
Received: from p5dec239a.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.35.154) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated);  30 May 2016 13:34:02 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Mirja Kuehlewind (IETF)" 
In-Reply-To: <1464524906.507204.621875065.5A6A91A2@webmail.messagingengine.com>
Date: Mon, 30 May 2016 13:34:05 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2BA6D8B1-7212-41E5-8FD6-7BD7391440BE@kuehlewind.net>
References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com>   <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net>   <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> <57324CE8.6040109@usdonovans.com> <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net>  <6EF5DC36-1BEF-47EE-BB3B-83BE5E115AE3@kuehlewind.net> <993A9C1D-1B91-4A6D-B7DA-F5E829763E17@fastmail.fm>  <1464524906.507204.621875065.5A6A91A2@webmail.messagingengine.com>
To: Alexey Melnikov 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG 
Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?=
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, 30 May 2016 11:34:09 -0000

Hi all,

thanks for adding the Applicability and later Considerations sections! =
That makes things much more clear to me.

May I propose one tiny edit for the Applicability section, just do make =
it super clear. If you don=E2=80=99t think this is useful, please =
withdraw.

OLD:
In order for the DRMP mechanism to work, the=09
priorities defined for all messages across all applications used in a=09
Diameter administrative domain must be defined in a consistent and=09
coordinated fashion.

NEW:
In order for the DRMP mechanism to work, the=09
priorities defined for all messages across all applications used in a=09
Diameter administrative domain must be defined in a consistent and=09
coordinated fashion, taking the default priority into account.

Thanks,
Mirja


> Am 29.05.2016 um 14:28 schrieb Alexey Melnikov =
:
>=20
> Hi,
> Finally getting back to this.
>=20
> I think authors did a good job in the latest version by adding =
sections
> 1.1 (Applicability) and 10 (Considerations When Defining Application
> Priorities).
>=20
> I would like to suggest the following clarification:
>=20
> In Section 8:
>=20
> Unchanged:
>   Diameter nodes MUST have a default priority to apply to transactions
>   that do not have an explicit priority set in the DRMP AVP.
>=20
> OLD:
>   Diameter nodes SHOULD use the PRIORITY_10 priority as this default
>   value.
>=20
> NEW:
>   In order to guaranty consistent handling of messages from =
nonupgraded
>   Diameter clients,
>   Diameter nodes SHOULD use the PRIORITY_10 priority as this default
>   priority value. PRIORITY_10 is a mid range priority that corresponds
>   to "normal" traffic and thus would be a suitable default for most
>   deployments,
>   while still allowing different Diameter applications to designate
>   other
>   priorities for lower and higher priority traffic.
>=20
> Best Regards,
> Alexey
>=20
> On Wed, May 11, 2016, at 06:39 PM, Mirja Kuehlewind (IETF) wrote:
>> Hi Alexey,
>>=20
>> yes, please provide some text and maybe a warning.
>>=20
>> I=E2=80=99ve cleared my discuss as no actual changes to the spec are =
needed based
>> on the common understand we have now, however, I would still like to =
see
>> further text in the doc about points that came up in this discussion.
>>=20
>> Thanks!
>> Mirja
>>=20
>>=20
>>> Am 11.05.2016 um 13:13 schrieb Alexe Melnikov =
:
>>>=20
>>> Hi Mirja,
>>>=20
>>>> On 11 May 2016, at 07:07, Mirja Kuehlewind (IETF) =
 wrote:
>>>>=20
>>>> Okay let me go for an example here and see if that can be a use =
case that we are talking about.
>>>=20
>>> Yes, this is helpful.
>>>>=20
>>>> You have a system where some clients run a communication service =
for emergency doctors as well as for firefighters and then there are =
also =E2=80=9Anormal=E2=80=98 users that run some kind of communication =
service.
>>>>=20
>>>> Now you actually have an emergency: some part of the system is down =
and the number of request is high such that the system is overloaded.
>>>>=20
>>>> Both the emergency doctors have would have two different priority =
classes, one for important message about instruction (what and where =
people should do something) and one for communication between the =
doctors/firefighters which has still higher priority than any other =
communication of the other people (as you assume doctors and =
firefighters are more responsible to not misuse this communication =
channel).
>>>>=20
>>>> Now only the emergency doctors communication service was upgraded =
to use this extension, but the firefighter=E2=80=99s administrations is =
just too slow or they currently have not enough money because they have =
specialized expensive hardware and software that is not easy to change.
>>>=20
>>> "Doctor, it hurts when I do that..." - "Don't do that!"
>>>=20
>>> I don't think this would be a common deployment case.
>>>=20
>>> I agree that there is an issue in the scenario you specified. =
Default priority helps with a single application + normal (unupgraded) =
traffic. I do think it helps with the most common case. So instead of =
having lots of SHOULDs and MAYs, I suggest we add text describing =
possible issues and when multiple DIAMETER applications are deployed we =
either recommend that all clients are upgraded to support this extension =
at the same time or at least deployments specify compatible policies for =
different applications.
>>>=20
>>> I can suggest some text.
>>>=20
>>>> Is it okay in this situation that the private chat of two doctors =
about their last ski-holidays starves requests to access the network to =
send instructor message to the firefighters?
>>>=20
>>> We can't prevent all problems like this, as the above is really a =
social problem combined with misconfiguration. But we can warn about it.
>>>>=20
>>>> (And how do i make sure that that all other other requests actually =
select a lower priority than 10=E2=80=A6? But that=E2=80=99s a different =
question=E2=80=A6)
>>>>=20
>>>> Mirja
>>>>=20
>>>>=20
>>>>> Am 11.05.2016 um 06:59 schrieb Alexey Melnikov =
:
>>>>>=20
>>>>> Hi Mirja,
>>>>>=20
>>>>> On 10 May 2016, at 17:59, Mirja Kuehlewind (IETF) =
 wrote:
>>>>>=20
>>>>>>>> I don=E2=80=99t think it is a good idea to assign a default =
priority to non-priority-defined requests at all. If you have high =
priority traffic that does not support this extension (yet) this traffic =
could be starved by lower priority traffic when assigning a middle range =
priority. I don=E2=80=99t think that is what you want to achieve.
>>>>>>> SRD> Actually, this is what we want to achieve.  It is an =
requirement that messages explicitly marked as high priority get treated =
even if it results in starving lower priority messages.  The starving of =
lower priority messages is not an problem, it is a requirement.
>>>>>>=20
>>>>>> I think we are still talking past each other.
>>>>>=20
>>>>> Most definitely :-).
>>>>>=20
>>>>>> If you explicitly assign a priority, starvation might be okay. =
However, if you don=E2=80=99t have a priority explicitly signaled, the =
transaction might have a very high priority
>>>>>=20
>>>>> So some agent in the system needs to decide that a transaction is =
important.
>>>>>> but you just don=E2=80=99t know and by assigning a random =
mid-range priority this important request could get starved.
>>>>>=20
>>>>> Here I disagree with you, because the way to know that a =
transaction is important is to upgrade client to explicitly assign high =
priority to it. So default priority is a backward compatibility =
mechanism, that would work for most common cases. You seem to be =
suggesting that when this extension is deployed all clients need to be =
updated at the same time. This is not realistic.
>>>>=20
>>>=20
>>=20
>=20


From nobody Mon May 30 07:54:00 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 0F15A12D613; Mon, 30 May 2016 07:53:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level: 
X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=G5pAVDKh; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=dpxBfOVG
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 haIIL5VWgArd; Mon, 30 May 2016 07:53:50 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E706512D5D7; Mon, 30 May 2016 07:53:49 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 09D5F20CD2; Mon, 30 May 2016 10:53:49 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 30 May 2016 10:53:49 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=h/tiI9aZttYt7HE+1IbGTITxg+0=; b=G5pAVD Kh4E2WkT6jRD1xzFeiLH9/MTLqDYOALViCSnxbwuWxLfBvOqr/GZdwFugmXBYxmc xfMXcpafzW1foLJ2+cdnyDN8Z5nfjDVn3k6zpBaEbav3AKo4oaxUyUHnKS4/vria 2v3eS21+ZN47oPLVGmh10GWiNOyVFBUPoczTA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=h/tiI9aZttYt7HE +1IbGTITxg+0=; b=dpxBfOVGrdZqVRHAaOf0/gqwsFOXrPjSAnYcVKN/CEscrDJ BTj7Orlp0CivY7EopudUagw69XxxiG4Zpxh8flLGqX2WHLan/KHPp1rgDxhOBKoD q+JaGejoApdN7HyedJ115NgDD9vKbLIDTLhNpQ0Yq7huy37tT6bIp8+KLR0g=
X-Sasl-enc: 6vS6AFqjrm63ObRldMvzl4m+Og1RErVBd7Auj691Qbgd 1464620028
Received: from [10.9.74.152] (unknown [85.255.232.19]) by mail.messagingengine.com (Postfix) with ESMTPA id 6D718CCDAD; Mon, 30 May 2016 10:53:48 -0400 (EDT)
Content-Type: text/plain; charset=windows-1251
Mime-Version: 1.0 (1.0)
From: Alexey Melnikov 
X-Mailer: iPhone Mail (13E238)
In-Reply-To: <2BA6D8B1-7212-41E5-8FD6-7BD7391440BE@kuehlewind.net>
Date: Mon, 30 May 2016 16:00:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com>   <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net>   <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> <57324CE8.6040109@usdonovans.com> <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net>  <6EF5DC36-1BEF-47EE-BB3B-83BE5E115AE3@kuehlewind.net> <993A9C1D-1B91-4A6D-B7DA-F5E829763E17@fastmail.fm>  <1464524906.507204.621875065.5A6A91A2@webmail.messagingengine.com> <2BA6D8B1-7212-41E5-8FD6-7BD7391440BE@kuehlewind.net>
To: "Mirja Kuehlewind (IETF)" 
Archived-At: 
Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG 
Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?=
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, 30 May 2016 14:53:52 -0000

Hi Mirja,

> On 30 May 2016, at 12:34, Mirja Kuehlewind (IETF)  wr=
ote:
>=20
> Hi all,
>=20
> thanks for adding the Applicability and later Considerations sections! Tha=
t makes things much more clear to me.
>=20
> May I propose one tiny edit for the Applicability section, just do make it=
 super clear. If you don=92t think this is useful, please withdraw.
>=20
> OLD:
> In order for the DRMP mechanism to work, the   =20
> priorities defined for all messages across all applications used in a   =20=

> Diameter administrative domain must be defined in a consistent and   =20
> coordinated fashion.
>=20
> NEW:
> In order for the DRMP mechanism to work, the   =20
> priorities defined for all messages across all applications used in a   =20=

> Diameter administrative domain must be defined in a consistent and   =20
> coordinated fashion, taking the default priority into account.

I think something like this is a good idea.

> Thanks,
> Mirja
>=20
>=20
>> Am 29.05.2016 um 14:28 schrieb Alexey Melnikov :
>>=20
>> Hi,
>> Finally getting back to this.
>>=20
>> I think authors did a good job in the latest version by adding sections
>> 1.1 (Applicability) and 10 (Considerations When Defining Application
>> Priorities).
>>=20
>> I would like to suggest the following clarification:
>>=20
>> In Section 8:
>>=20
>> Unchanged:
>>  Diameter nodes MUST have a default priority to apply to transactions
>>  that do not have an explicit priority set in the DRMP AVP.
>>=20
>> OLD:
>>  Diameter nodes SHOULD use the PRIORITY_10 priority as this default
>>  value.
>>=20
>> NEW:
>>  In order to guaranty consistent handling of messages from nonupgraded
>>  Diameter clients,
>>  Diameter nodes SHOULD use the PRIORITY_10 priority as this default
>>  priority value. PRIORITY_10 is a mid range priority that corresponds
>>  to "normal" traffic and thus would be a suitable default for most
>>  deployments,
>>  while still allowing different Diameter applications to designate
>>  other
>>  priorities for lower and higher priority traffic.
>>=20
>> Best Regards,
>> Alexey
>>=20
>>> On Wed, May 11, 2016, at 06:39 PM, Mirja Kuehlewind (IETF) wrote:
>>> Hi Alexey,
>>>=20
>>> yes, please provide some text and maybe a warning.
>>>=20
>>> I=92ve cleared my discuss as no actual changes to the spec are needed ba=
sed
>>> on the common understand we have now, however, I would still like to see=

>>> further text in the doc about points that came up in this discussion.
>>>=20
>>> Thanks!
>>> Mirja
>>>=20
>>>=20
>>>> Am 11.05.2016 um 13:13 schrieb Alexe Melnikov :=

>>>>=20
>>>> Hi Mirja,
>>>>=20
>>>>> On 11 May 2016, at 07:07, Mirja Kuehlewind (IETF)  wrote:
>>>>>=20
>>>>> Okay let me go for an example here and see if that can be a use case t=
hat we are talking about.
>>>>=20
>>>> Yes, this is helpful.
>>>>>=20
>>>>> You have a system where some clients run a communication service for e=
mergency doctors as well as for firefighters and then there are also =82norm=
al=91 users that run some kind of communication service.
>>>>>=20
>>>>> Now you actually have an emergency: some part of the system is down an=
d the number of request is high such that the system is overloaded.
>>>>>=20
>>>>> Both the emergency doctors have would have two different priority clas=
ses, one for important message about instruction (what and where people shou=
ld do something) and one for communication between the doctors/firefighters w=
hich has still higher priority than any other communication of the other peo=
ple (as you assume doctors and firefighters are more responsible to not misu=
se this communication channel).
>>>>>=20
>>>>> Now only the emergency doctors communication service was upgraded to u=
se this extension, but the firefighter=92s administrations is just too slow o=
r they currently have not enough money because they have specialized expensi=
ve hardware and software that is not easy to change.
>>>>=20
>>>> "Doctor, it hurts when I do that..." - "Don't do that!"
>>>>=20
>>>> I don't think this would be a common deployment case.
>>>>=20
>>>> I agree that there is an issue in the scenario you specified. Default p=
riority helps with a single application + normal (unupgraded) traffic. I do t=
hink it helps with the most common case. So instead of having lots of SHOULD=
s and MAYs, I suggest we add text describing possible issues and when multip=
le DIAMETER applications are deployed we either recommend that all clients a=
re upgraded to support this extension at the same time or at least deploymen=
ts specify compatible policies for different applications.
>>>>=20
>>>> I can suggest some text.
>>>>=20
>>>>> Is it okay in this situation that the private chat of two doctors abou=
t their last ski-holidays starves requests to access the network to send ins=
tructor message to the firefighters?
>>>>=20
>>>> We can't prevent all problems like this, as the above is really a socia=
l problem combined with misconfiguration. But we can warn about it.
>>>>>=20
>>>>> (And how do i make sure that that all other other requests actually se=
lect a lower priority than 10=85? But that=92s a different question=85)
>>>>>=20
>>>>> Mirja
>>>>>=20
>>>>>=20
>>>>>> Am 11.05.2016 um 06:59 schrieb Alexey Melnikov :
>>>>>>=20
>>>>>> Hi Mirja,
>>>>>>=20
>>>>>> On 10 May 2016, at 17:59, Mirja Kuehlewind (IETF)  wrote:
>>>>>>=20
>>>>>>>>> I don=92t think it is a good idea to assign a default priority to n=
on-priority-defined requests at all. If you have high priority traffic that d=
oes not support this extension (yet) this traffic could be starved by lower p=
riority traffic when assigning a middle range priority. I don=92t think that=
 is what you want to achieve.
>>>>>>>> SRD> Actually, this is what we want to achieve.  It is an requireme=
nt that messages explicitly marked as high priority get treated even if it r=
esults in starving lower priority messages.  The starving of lower priority m=
essages is not an problem, it is a requirement.
>>>>>>>=20
>>>>>>> I think we are still talking past each other.
>>>>>>=20
>>>>>> Most definitely :-).
>>>>>>=20
>>>>>>> If you explicitly assign a priority, starvation might be okay. Howev=
er, if you don=92t have a priority explicitly signaled, the transaction migh=
t have a very high priority
>>>>>>=20
>>>>>> So some agent in the system needs to decide that a transaction is imp=
ortant.
>>>>>>> but you just don=92t know and by assigning a random mid-range priori=
ty this important request could get starved.
>>>>>>=20
>>>>>> Here I disagree with you, because the way to know that a transaction i=
s important is to upgrade client to explicitly assign high priority to it. S=
o default priority is a backward compatibility mechanism, that would work fo=
r most common cases. You seem to be suggesting that when this extension is d=
eployed all clients need to be updated at the same time. This is not realist=
ic.
>=20


From nobody Mon May 30 14:40: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 241E912D675 for ; Mon, 30 May 2016 14:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, 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 VknFDAZbaKRf for ; Mon, 30 May 2016 14:40:11 -0700 (PDT)
Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8D52D12D0A1 for ; Mon, 30 May 2016 14:40:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id D73CB3FB55; Mon, 30 May 2016 23:40:06 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon21.um.es
Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Y7pYVmRq9dqk; Mon, 30 May 2016 23:40:06 +0200 (CEST)
Received: from [192.168.1.200] (unknown [89.33.188.231]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dan.garcia@um.es) by xenon21.um.es (Postfix) with ESMTPSA id 1E7F13F991; Mon, 30 May 2016 23:40:04 +0200 (CEST)
From: =?utf-8?Q?Dan_Garc=C3=ADa_Carrillo?= 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 30 May 2016 23:40:03 +0200
Message-Id: <9C7E1690-8ED0-46E8-A92C-75581BEAC1E0@um.es>
To: dime@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: [Dime] Diameter LoRaWAN Application
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, 30 May 2016 21:40:14 -0000

Dear all,

We have uploaded a draft to show an initiative towards the integration =
of AAA infrastructures into LP-WAN. This document show an example of how =
the LoRaWAN join procedure can be used with Diameter.

Comments are welcome.=20

https://datatracker.ietf.org/doc/draft-garcia-dime-diameter-lorawan/


Best Regards,
Dan.


From nobody Tue May 31 20:37:47 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 550BC12D0BD; Tue, 31 May 2016 20:37:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Alissa Cooper" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160601033743.20264.46992.idtracker@ietfa.amsl.com>
Date: Tue, 31 May 2016 20:37:43 -0700
Archived-At: 
Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org
Subject: [Dime] Alissa Cooper's No Objection on draft-ietf-dime-drmp-06: (with COMMENT)
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: Wed, 01 Jun 2016 03:37:43 -0000

Alissa Cooper has entered the following ballot position for
draft-ietf-dime-drmp-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for resolving the issues I raised.