From nobody Fri Jun 1 09:36:06 2018 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B1A12D95A; Fri, 1 Jun 2018 09:36:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-yang-14.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152787096504.15240.3903059178554924393@ietfa.amsl.com> Date: Fri, 01 Jun 2018 09:36:05 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 16:36:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection WG of the IETF. Title : YANG Data Model for Bidirectional Forwarding Detection (BFD) Authors : Reshad Rahman Lianshu Zheng Mahesh Jethanandani Santosh Pallagatti Greg Mirsky Filename : draft-ietf-bfd-yang-14.txt Pages : 74 Date : 2018-06-01 Abstract: This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-yang-14 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-yang-14 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 Fri Jun 1 09:56:44 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DD412D965; Fri, 1 Jun 2018 09:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 EPSBs-MDwf5J; Fri, 1 Jun 2018 09:56:40 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A6C12D963; Fri, 1 Jun 2018 09:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23601; q=dns/txt; s=iport; t=1527872200; x=1529081800; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oxbAfn66ueXH5NlZ5GOy0vTFGVoks7jjyff7SuH21mQ=; b=Gy02p7ySUyDs1OYsaMpIq+xUyhOU2qT5sLkcuf8g+QrLgNmdosiaTm8q Buw8njQHNhPqjHe3Qu8ubdx5L6OHhu8ok0zXHAIfH2GyDBzUIb3qvSrvR JeS7haEHjHFUJ+9/ZeetZ+946vazf6ykFwEPGKuTDYwi8r9TC3LZ8HHlq M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2AQBlehFb/4YNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMVLmJ/KAqDbYgEjGeBeZRMgXgLIwmEQAIXgW4hNBgBAgE?= =?us-ascii?q?BAQEBAQJsHAyFKAEBAQMBI0sLDAQCAQgSAwElBwICAjAUAw4CBAENBQ6DFAK?= =?us-ascii?q?BdwgPpwmCHIg/gVkPiD+BVD+BDySCaYMRAQECAQEWgTkkJ4JCMIIkAphsCQK?= =?us-ascii?q?DRYIliHWBPECDN4diiXOGfwIREwGBJB04JoEscBUaSwGCCAEPCYI/iEiFPm+?= =?us-ascii?q?BFYwQgSwBgRgBAQ?= X-IronPort-AV: E=Sophos;i="5.49,467,1520899200"; d="scan'208";a="123563702" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2018 16:56:29 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w51GuSRT031074 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2018 16:56:28 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 1 Jun 2018 11:56:27 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1320.000; Fri, 1 Jun 2018 11:56:27 -0500 From: "Reshad Rahman (rrahman)" To: "tom p." , "ietf@ietf.org" CC: "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "bfd-chairs@ietf.org" Subject: Re: Last Call: (YANG Data Model for Bidirectional Forwarding Detection (BFD)) to Proposed Standard Thread-Topic: Last Call: (YANG Data Model for Bidirectional Forwarding Detection (BFD)) to Proposed Standard Thread-Index: AQHT9Cv61vh7ba7JDkyK/ePx55YBV6RB4eESgABN9oCACYuKgA== Date: Fri, 1 Jun 2018 16:56:27 +0000 Message-ID: <087AACB4-5F00-4A13-B5C9-8D50B7C40C06@cisco.com> References: <152725478007.13001.4823972789715702212.idtracker@ietfa.amsl.com> <008e01d3f4e4$dba327a0$4001a8c0@gateway.2wire.net> <609C9D00-FF77-4D36-AAE3-9D0A7B074594@cisco.com> In-Reply-To: <609C9D00-FF77-4D36-AAE3-9D0A7B074594@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.72] Content-Type: multipart/mixed; boundary="_002_087AACB45F004A13B5C98D50B7C40C06ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 16:56:43 -0000 --_002_087AACB45F004A13B5C98D50B7C40C06ciscocom_ Content-Type: text/plain; charset="utf-8" Content-ID: <2CCED6BCF8EF984CAC0C6EAB6A282817@emea.cisco.com> Content-Transfer-Encoding: base64 SGksDQoNCldlIGp1c3QgdXBsb2FkZWQgcmV2MTQgd2hpY2ggKEkgYmVsaWV2ZSkgYWRkcmVzc2Vz IHlvdXIgY29tbWVudHM6IHdlIGFkZGVkIHRoZSBtaXNzaW5nIHJlZmVyZW5jZSBzdGF0ZW1lbnRz IGFuZCBhbHNvIGZpeGVkIGFuIGluY29ycmVjdCByZWZlcmVuY2UuIFRoZSBkaWZmcyBhbHNvIGlu Y2x1ZGUgc29tZSBzbWFsbCB0cmVlIGRpYWdyYW0gY2hhbmdlcyAoSSB1cGdyYWRlZCBmcm9tIHB5 YW5nIDEuNy4zIHRvIDEuNy41KS4NCg0KUmVnYXJkcywNClJlc2hhZC4NCg0K77u/T24gMjAxOC0w NS0yNiwgMTE6MTAgQU0sICJSZXNoYWQgUmFobWFuIChycmFobWFuKSIgPHJyYWhtYW5AY2lzY28u Y29tPiB3cm90ZToNCg0KICAgIEhpIFRvbSwNCiAgICANCiAgICBUaGFua3MgZm9yIHRoZSByZXZp ZXcuIEkgd2lsbCBhZGQgdGhlIG1pc3NpbmcgcmVmZXJlbmNlIHN0YXRlbWVudHMsIEkgYmVsaWV2 ZSB0aGlzIHdhcyBqdXN0IGFuIG92ZXJzaWdodCBiZWNhdXNlIHRoZXJlIGFyZS93ZXJlIG5vIFJG QyBudW1iZXJzIGZvciB0aGVzZSBpbXBvcnRlZCBtb2R1bGVzICh0aGVyZSBpcyBub3cgZm9yIGll dGYtcm91dGluZykuICBTbyBJIHdpbGwgYWRkIHRoZSB1c3VhbCBSRkMgWFhYIHdpdGggYSBub3Rl IGZvciB0aGUgUkZDIEVkaXRvci4NCiAgICANCiAgICBSZWdhcmRzLA0KICAgIFJlc2hhZC4NCiAg ICANCiAgICANCiAgICBPbiAyMDE4LTA1LTI2LCA3OjMxIEFNLCAidG9tIHAuIiA8ZGFlZHVsdXNA YnRjb25uZWN0LmNvbT4gd3JvdGU6DQogICAgDQogICAgICAgIFRoaXMgSS1EIGhhcyBhIG51bWJl ciBvZiBpbXBvcnQgc3RhdGVtZW50cyBmcm9tIG90aGVyIFlBTkcgbW9kdWxlcyBmb3INCiAgICAg ICAgd2hpY2ggdGhlcmUgaXMgbm8gUmVmZXJlbmNlIHN0YXRlbWVudCB3aGVyZSBJIGJlbGlldmUg dGhhdCB0aGVyZSBzaG91bGQNCiAgICAgICAgYmUsIHN0YXRlbWVudHMgc3VjaCBhcyAuDQogICAg ICAgIA0KICAgICAgICAgIGltcG9ydCBpYW5hLWJmZC10eXBlcw0KICAgICAgICAgIGltcG9ydCBp ZXRmLWJmZA0KICAgICAgICAgIGltcG9ydCBpZXRmLWJmZC1tcGxzDQogICAgICAgICAgaW1wb3J0 IGlldGYtdGUNCiAgICAgICAgICBpbXBvcnQgaWV0Zi1yb3V0aW5nDQogICAgICAgIA0KICAgICAg ICBJbiB0aGUgZmlyc3QgdGhyZWUgY2FzZXMsIGl0IG1heSBiZSB0aGF0IHRoZSBlZGl0b3JzIG9m IHRoaXMgSS1EDQogICAgICAgIGNvbnNpZGVyIHRoYXQgc3VjaCBhIHJlZmVyZW5jZSBpcyBub3Qg bmVlZGVkIGJlY2F1c2UgdGhlIHJlbGV2YW50DQogICAgICAgIG1vZHVsZXMgYXJlIGluIHRoZSBz YW1lIEktRCBidXQgc3VjaCB0aGlua2luZyBpcyBlcnJvbmVvdXMuICBUaGVzZSBhcmUNCiAgICAg ICAgc2VwYXJhdGUgbW9kdWxlcyB3aGljaCB3aWxsIGxlYWQgaW5kZXBlbmRlbnQgZXhpc3RlbmNl cyBpbiB0aGUgd2lsZCBzbw0KICAgICAgICB0aGF0IHRoZXJlIHdpbGwgYmUgbm90aGluZyB0byB0 ZWxsIGEgdXNlciBvZiBlLmcuICBtb2R1bGUNCiAgICAgICAgaWV0Zi1iZmQtbXBscy10ZQ0KICAg ICAgICB3aGVyZSB0byBsb29rIGZvcg0KICAgICAgICBpZXRmLWJmZC10eXBlcywgaWV0Zi1iZmQs ICBpZXRmLWJmZC1tcGxzDQogICAgICAgIA0KICAgICAgICBUaGVzZSBuZWVkICByZWZlcmVuY2Ug c3RhdGVtZW50IHN1Y2ggYXMNCiAgICAgICAgDQogICAgICAgICAgcmVmZXJlbmNlICJSRkMgWFhY WDogICBZQU5HIERhdGEgTW9kZWwgZm9yIEJGRCI7DQogICAgICAgIA0KICAgICAgICBUb20gUGV0 Y2gNCiAgICAgICAgDQogICAgICAgIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCiAgICAg ICAgRnJvbTogIlRoZSBJRVNHIiA8aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc+DQogICAgICAgIFRv OiAiSUVURi1Bbm5vdW5jZSIgPGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+DQogICAgICAgIENjOiA8 cnRnLWJmZEBpZXRmLm9yZz47IDxkcmFmdC1pZXRmLWJmZC15YW5nQGlldGYub3JnPjsNCiAgICAg ICAgPGJmZC1jaGFpcnNAaWV0Zi5vcmc+DQogICAgICAgIFNlbnQ6IEZyaWRheSwgTWF5IDI1LCAy MDE4IDI6MjYgUE0NCiAgICAgICAgDQogICAgICAgID4gVGhlIElFU0cgaGFzIHJlY2VpdmVkIGEg cmVxdWVzdCBmcm9tIHRoZSBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcNCiAgICAgICAgRGV0ZWN0 aW9uDQogICAgICAgID4gV0cgKGJmZCkgdG8gY29uc2lkZXIgdGhlIGZvbGxvd2luZyBkb2N1bWVu dDogLSAnWUFORyBEYXRhIE1vZGVsIGZvcg0KICAgICAgICA+IEJpZGlyZWN0aW9uYWwgRm9yd2Fy ZGluZyBEZXRlY3Rpb24gKEJGRCknDQogICAgICAgID4gICA8ZHJhZnQtaWV0Zi1iZmQteWFuZy0x My50eHQ+IGFzIFByb3Bvc2VkIFN0YW5kYXJkDQogICAgICAgID4NCiAgICAgICAgPiBUaGUgSUVT RyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQgc29s aWNpdHMNCiAgICAgICAgZmluYWwNCiAgICAgICAgPiBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4g UGxlYXNlIHNlbmQgc3Vic3RhbnRpdmUgY29tbWVudHMgdG8gdGhlDQogICAgICAgID4gaWV0ZkBp ZXRmLm9yZyBtYWlsaW5nIGxpc3RzIGJ5IDIwMTgtMDYtMDguIEV4Y2VwdGlvbmFsbHksIGNvbW1l bnRzIG1heQ0KICAgICAgICBiZQ0KICAgICAgICA+IHNlbnQgdG8gaWVzZ0BpZXRmLm9yZyBpbnN0 ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxlYXNlIHJldGFpbiB0aGUNCiAgICAgICAgYmVnaW5uaW5n IG9mDQogICAgICAgID4gdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQgc29ydGlu Zy4NCiAgICAgICAgPg0KICAgICAgICA+IEFic3RyYWN0DQogICAgICAgID4NCiAgICAgICAgPg0K ICAgICAgICA+ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCB0aGF0 IGNhbiBiZSB1c2VkIHRvDQogICAgICAgIGNvbmZpZ3VyZQ0KICAgICAgICA+ICAgIGFuZCBtYW5h Z2UgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKS4NCiAgICAgICAgPg0K ICAgICAgICA+ICAgIFRoZSBZQU5HIG1vZHVsZXMgaW4gdGhpcyBkb2N1bWVudCBjb25mb3JtIHRv IHRoZSBOZXR3b3JrIE1hbmFnZW1lbnQNCiAgICAgICAgPiAgICBEYXRhc3RvcmUgQXJjaGl0ZWN0 dXJlIChOTURBKS4NCiAgICAgICAgPg0KICAgICAgICA+DQogICAgICAgID4NCiAgICAgICAgPg0K ICAgICAgICA+IFRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWENCiAgICAgICAgPiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWJmZC15YW5nLw0KICAgICAgICA+ DQogICAgICAgID4gSUVTRyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYQ0KICAgICAgICA+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYmZkLXlhbmcvYmFs bG90Lw0KICAgICAgICA+DQogICAgICAgID4NCiAgICAgICAgPiBObyBJUFIgZGVjbGFyYXRpb25z IGhhdmUgYmVlbiBzdWJtaXR0ZWQgZGlyZWN0bHkgb24gdGhpcyBJLUQuDQogICAgICAgID4NCiAg ICAgICAgPg0KICAgICAgICA+IFRoZSBkb2N1bWVudCBjb250YWlucyB0aGVzZSBub3JtYXRpdmUg ZG93bndhcmQgcmVmZXJlbmNlcy4NCiAgICAgICAgPiBTZWUgUkZDIDM5NjcgZm9yIGFkZGl0aW9u YWwgaW5mb3JtYXRpb246DQogICAgICAgID4gICAgIGRyYWZ0LWlldGYtdGVhcy15YW5nLXRlOiBB IFlBTkcgRGF0YSBNb2RlbCBmb3IgVHJhZmZpYyBFbmdpbmVlcmluZw0KICAgICAgICBUdW5uZWxz IGFuZCBJbnRlcmZhY2VzIChOb25lIC0gSUVURiBzdHJlYW0pDQogICAgICAgID4gICAgIGRyYWZ0 LWlldGYtbXBscy1iYXNlLXlhbmc6IEEgWUFORyBEYXRhIE1vZGVsIGZvciBNUExTIEJhc2UgKE5v bmUgLQ0KICAgICAgICBJRVRGIHN0cmVhbSkNCiAgICAgICAgPg0KICAgICAgICA+DQogICAgICAg ID4NCiAgICAgICAgDQogICAgICAgIA0KICAgIA0KICAgIA0KDQo= --_002_087AACB45F004A13B5C98D50B7C40C06ciscocom_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Fri, 01 Jun 2018 16:56:27 GMT"; modification-date="Fri, 01 Jun 2018 16:56:27 GMT" Content-ID: Received: from xch-rtp-001.cisco.com (64.101.220.141) by xch-rcd-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Mailbox Transport; Fri, 1 Jun 2018 11:53:36 -0500 Received: from xch-rtp-007.cisco.com (64.101.220.147) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 1 Jun 2018 12:53:35 -0400 Received: from xch-rtp-014.cisco.com (64.101.220.154) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 1 Jun 2018 12:53:34 -0400 Received: from alln-iport-7.cisco.com (173.37.142.94) by mail.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Fri, 1 Jun 2018 12:53:32 -0400 Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2018 16:36:17 +0000 Received: from alln-inbound-f.cisco.com (alln-inbound-f.cisco.com [173.37.147.236]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w51GaD6x014626 (version=TLSv1/SSLv3 cipher=DHE-RSA-SEED-SHA bits=128 verify=OK); Fri, 1 Jun 2018 16:36:13 GMT Received-SPF: Pass (alln-inbound-f.cisco.com: domain of rtg-bfd-bounces@ietf.org designates 4.31.198.44 as permitted sender) identity=mailfrom; client-ip=4.31.198.44; receiver=alln-inbound-f.cisco.com; envelope-from="rtg-bfd-bounces@ietf.org"; x-sender="rtg-bfd-bounces@ietf.org"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:12.22.58.0/24 ip4:64.170.98.0/24 ip4:4.31.198.32/27 ip4:209.208.19.192/27 ip4:72.167.123.204 ip6:2001:1890:123a::/56 ip6:2001:1890:126c::/56 ip6:2001:1900:3001:0011::0/64 ip6:2607:f170:8000:1500::0/64 -all" Received-SPF: None (alln-inbound-f.cisco.com: no sender authenticity information available from domain of postmaster@mail.ietf.org) identity=helo; client-ip=4.31.198.44; receiver=alln-inbound-f.cisco.com; envelope-from="rtg-bfd-bounces@ietf.org"; x-sender="postmaster@mail.ietf.org"; x-conformance=spf_only Authentication-Results: alln-inbound-f.cisco.com; spf=Pass smtp.mailfrom=rtg-bfd-bounces@ietf.org; spf=None smtp.helo=postmaster@mail.ietf.org; dkim=pass (signature verified) header.i=@ietf.org; dmarc=pass (p=none dis=none) d=ietf.org X-from-outside-Cisco: 4.31.198.44 IronPort-PHdr: =?us-ascii?q?9a23=3AgMZNIxF5WZkhnr0AX6uNIJ1GYnF86YWxBRYc79?= =?us-ascii?q?8ds5kLTJ74psu5bnLW6fgltlLVR4KTs6sC17KL9fi4EUU7or+5+EgYd5JNUx?= =?us-ascii?q?JXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQ?= =?us-ascii?q?viPgRpOOv1BpTSj8Oq3Oyu5pHfeQpFiCa9bL9oMBm6sRjau9ULj4dlNqs/0A?= =?us-ascii?q?bCrGFSe+RRy2NoJFaTkAj568yt4pNt8Dletuw4+cJYXqr0Y6o3TbpDDDQ7KG?= =?us-ascii?q?81/9HktQPCTQSU+HQRVHgdnwdSDAjE6BH6WYrxsjf/u+Fg1iSWIdH6QLYpUj?= =?us-ascii?q?mk8qxlSgLniD0fOjE27G7Zhcx+grxGrhK5pBJxzYzZboOaOfZjcK7RYc0VRX?= =?us-ascii?q?FaU8ZNVSFNHp+wY5cTA+cDO+tTsonzp0EJrRu7HQSsBeXvyiNWiX/s2601zf?= =?us-ascii?q?ghHRjb0ww6Bd0OvmjUrM7uOacTT++10KfIwS/Eb/NM1jfw7pXDfB4mofGJR7?= =?us-ascii?q?1wcMzRxFEuFwzbklWQp5bpPzSP1uQCtWWQ8uluVfq3hmMosQ18rCWjyt0xho?= =?us-ascii?q?TNhY8Z0F/J+Cp/zY0oP9O3UlR7bsShEJZItyGVKY92QsQ6TmFtoik6y7kGtY?= =?us-ascii?q?S6fCcU1JQnyQTTa/udc4iH+h7jVeCRLilkhH99d7+znRi//VW6xuHhUsS500?= =?us-ascii?q?xGoyVKn9XUs3ACzR3T6syJSvtn+Ueh3C6C1xrP6uFLOEw7jqTbJIM4zrErkZ?= =?us-ascii?q?oTrELDETPol0Xtl6KWd1sr+vSm6+j9ZbXmvJCcO5duig7iKqQuhtC/AeMgPw?= =?us-ascii?q?cURGeb9uW826Dt/ELjRrVHleE5kqjCsJ/GIsQXvLK2AwhQ0ow78RawEy+m0M?= =?us-ascii?q?gEnXkANF9KYg6IgJb3NFzVPP/4DOy/jEirkDtx2//GObjhCI3XLnffiLfhYa?= =?us-ascii?q?p960lExQUpztBf5ohbB6odL/LyQU/+qNvYAgUlPAyzxubtEM992Z8GWWKTHq?= =?us-ascii?q?+ZN7vfvkWN5uIyPuaMYpUauCznJPU++/HujGQ5lkMafaWzwZQXb3W4FOx8I0?= =?us-ascii?q?qFeXrsnssBEWASswUkSuzllEeNUD9IanmuXqI8/S00CIW8AYjfQYCthaSL3D?= =?us-ascii?q?2nEZ1OemBGFleMHG/0eIWcWvcMZySSLdV9kjMeTrWuV44h1Qqyuw/90bZoMu?= =?us-ascii?q?3U+igAv5L5yNd1//HTlQ019TFsEsud3WCNT3p0nmwTWj82xrtyrlB8yleYza?= =?us-ascii?q?d4hOZUGsBU5/NMSg06L4LTz/RmC9DuXQLMZsqGSFO4TdWiHTExSdQxzsQSbE?= =?us-ascii?q?Z8ANWtkhfD0zC2DL8SkryBHIY0/b7E33jtO8Z9zG7L27cnj1klXMRAKW2mib?= =?us-ascii?q?B59wXIG4HJkl6ZmLqtdagGwCHN82KDx3KUvE5ESA5wTbnFXXcHa0vZrdT2/E?= =?us-ascii?q?fCTrG0BrQ8MwtM0tKNKqpRatL1ilVKXuvsONPbY2ipgWe/GQ6Ixq+QbIrtY2?= =?us-ascii?q?gd0yTdCE4fkw8I43mGLwc+Czy9rGLfFzxhCVXvb1nw/ul5rXOxVlU0wB2Sb0?= =?us-ascii?q?19y7q1/QYYhfOdS/MJxL0EtychpC9qHFumw93WCsGAqBZmfKlGfdw951JH33?= =?us-ascii?q?rDtwNhJpygM7xihlkGfgR3pUzuzBB3CoRckcUxsHwqzRFyJr6f0F9bazyY2p?= =?us-ascii?q?XwMKXNKmbu5BCvd7LW2lbG3daW/acP9e81pEnivAGyCkUi9G9r3MVS03uZ/p?= =?us-ascii?q?/KFhYdUYrtUkYr8Bh3v7HaYjM854PIyX1jL7O0vyTe1NIoH+sq1hGgc81DP6?= =?us-ascii?q?ODEQ/4C9caCNS2KOw2h1ipaQoJPOJI+643JcymbeeG2K6qPOt7gD2mjH9H75?= =?us-ascii?q?x60k6W6yV8TevI1Y4fw/6ExguHSyv8jFC5v8D1gYBEeyofEXa+ySj/GIFRYb?= =?us-ascii?q?d+cpoMCWerO8e33Mlxh4bxW35E816uH1AG19WteRuSdVP92wxQ1V4MrHO7mC?= =?us-ascii?q?u41CB7kzYzoqWD2yzOxvzodAAbNW5TWGlikVDsLJC3j98EXEioaA4plBS+6E?= =?us-ascii?q?nmxqhbv7hwL27JTUhUeCj2KnloUrGsubqaf85P9JQovD1UUOuifVCVULj9ow?= =?us-ascii?q?cB3iz/Hmte3yw0dzawtprlmBx6jXqXLGxvo3rBZcFw2RDf6cTZRfFKxDUGSy?= =?us-ascii?q?14iT7TBleiJNSm4dSUl4zfveC5TW6uSppTcSzzx4OaqCS7/XFqAQG4n/2rn9?= =?us-ascii?q?3nEA060TL/19luVCXIqg3xbZXq16ShLe1neVNkC0P768p/Aot+iJc/hIkM2X?= =?us-ascii?q?gGgZWY5X8HkWLuMdpG2KL+Y30NRTgQztHJ4Qjlw1FsLnWTy43lUXWdx9NrZ8?= =?us-ascii?q?OmbWMOxiI988dKBb+R7LxfnCt1vEC3oBnNbvh8hTcS1fwu5GQGjOEOvQon1j?= =?us-ascii?q?+dDawKHUlEISzskAyF79ako6VWZ2avbL2w21Bknd26EL6CoxpcV2r+eps4AS?= =?us-ascii?q?Bw6cB/OkrW0HLv8oHkZMXQbdULux2SiRjAju1VKJM3lvoFnidoJWP9vWY5xO?= =?us-ascii?q?48lxBhwZa6vI2fIWV34K25GgJYNiHyZ84L/DHil7hekdyQ34+1BJVuAC4GU4?= =?us-ascii?q?fpTfKzDD0Ssu7rOBqJED05sn2bA6bQHReD6Ed6qHLCC5arN22NK3ka09ptWQ?= =?us-ascii?q?OSKVdDjwAVRzU1gpk5Ghq2y8zmdUdz/ioR6ULgqhtQ1uJoMAHyUmHDpAaocD?= =?us-ascii?q?g0R5mfIQFK4QFD/EfaLcue4vhvECFf+52rtBaNJXCDZwRUEWEJXVSJB0j5Mb?= =?us-ascii?q?mo5tnA8uyYC/GiIPvPerWBteteW+2UypKo14ts5yyMOdmXPnl+E/073VJOXW?= =?us-ascii?q?hjFMTBgTUPSjAYmDzWYsGHpRe84TF4rsel/Pv3XwLv4JOFC6FOPtV35xC2na?= =?us-ascii?q?CDOvaIhClnLDZY0YkMxWXPyLkRx1MdlyBudyKxHrQHryLCUKXQmqpPBR4Bdy?= =?us-ascii?q?xzLNdI77473gRVIc7bi9H12aRjgf4xDFdFU0fsld2oZcwRP269M0nLC1qMNL?= =?us-ascii?q?SDPTfL2d34YbugSb1Mi+VZrwewtiyZE0D9IDuDkSPmVxG0PO5QjSGbJwBRuI?= =?us-ascii?q?anfhlxDmjjScrsagenP99vkT023bo0i2vQNW4bLTd8aURNr7OO4i5Dnvp/Gn?= =?us-ascii?q?dB4WZiLeWehymZ6OzYII4MsfR3GiR0i/5a4HMixrtP9iFLXvx1mC7Iod5ouF?= =?us-ascii?q?ypjuiPyiF7XxpJsDpEmIWLvUB6M6XD6pZAQWrE/A4K7WiIEBQFvcdlCsf1tK?= =?us-ascii?q?BS0NfPjrn+JytD89LP4cQcANLYJ96AMHokKRDpAiLbDBMZTT63MmHSn1ddn+?= =?us-ascii?q?qV9n2Ispg6sJ/smIEVR7BHVVw1De8VCkN/ENMeJ5d3WysukaSHg84Q+Xq+sB?= =?us-ascii?q?7RSd1BvpDHSvKSGujvJyqZjblFfBYH3bL4LZ8POY38wUBtdl56nIHSEUrKQd?= =?us-ascii?q?9NujFhbhMzoEhV63h+S3c821n+agyz+3IcCf+0ngUqhQt5e+gi6DDs41IvLF?= =?us-ascii?q?rQuCQwiFUxmcnigT2Jaz7xNL2wUp9ICyr1qkcxM4j2TBp0bQ2pgUNkMy3ISK?= =?us-ascii?q?5Wj7tlbWprkhPTuYNTGf5ASq1JeAQQxeuWZ/Uoy1tcsCSnyFRb6uvEEpttiA?= =?us-ascii?q?wqfYSwoHJH3gJpdMQ1KrDIJKpV0lhQgbqDvjSm1+8rxA8eI0EN8W2JdSEUuU?= =?us-ascii?q?wILaUpJy2y8uNw7gyCniNJeHIQWPoyvvJq6kQ9Nvyczy38yLFOMVy+N+2EL6?= =?us-ascii?q?yFvGjMj9KHQlQ11kkQjUlK4aB20ds/c0qTT00v0LqRFxEHNMrfKgFVd9Ff+2?= =?us-ascii?q?TSfSaVrerNxoh5MJm6FuDtVeWOrrobglq4HAY1GIQB9toBEYeq0EHXIsfnK6?= =?us-ascii?q?AFyRQ26Qv3JVWFF+hGeBWRnDgbpMG/yYd93ZNBKTEFHWV9LSK3667JpgA0hv?= =?us-ascii?q?qDQck2b2wGUYsFLXI5RMq6lzRFsHRHCTm9yvgZxxSa7z/guiTQCyHxbtt5a/?= =?us-ascii?q?eQZBNhE825+TQk86eqjl7b6InRJ2b/Nd56oN/A9fsap4qbC/NTVbR8skbcm5?= =?us-ascii?q?JdR3OwUm7PFcW4KITxa4k3cdP0DWy2XUC4izIwHI/MOs2wJP2InR3wXtQT95?= =?us-ascii?q?aEw3YiONOzUDYEFFB1ruAH4at6Igobf5s8ZwWvrRgxcqaxLFSl1M6zSTOoID?= =?us-ascii?q?pSU/4N1/m1IrZZw282Y/anxWA8ZpA30+fx9lQCE4oXhBPTzur2eo9FTCLoEW?= =?us-ascii?q?ZccQicmS1sw2kkOqM7xOE43RXDvHEdPiyFMutzZzoXkcs7AAaTJ2l7EGw1Wx?= =?us-ascii?q?qQl4PN/hWE3r0O8W1ahdkHgqV+rHHis8qHM3qXU6uxpMCN6ndyQfsHhuhcL4?= =?us-ascii?q?XnP8KatZTYwmePHoeF617NWXugDPMfgdhZen8GE7FDzHsoPcUWtIYG8ks0Ts?= =?us-ascii?q?MzdPRDXaghur7sbiBrXmYJmC4US43Zj1lg4/vpguaAyUfPKMV8YU9MupUX2N?= =?us-ascii?q?ghczBscHsUg4KYbdzxq0CAZ3cbOgQNszhX2Fss0dB+I8O/56XRD5Rj1GsFxp?= =?us-ascii?q?AVUn7lDJ5tpWf8GFqLi1r1Q+nzv+W10FB2zenwl/gXCjp+ElQY+uBNi0EzI6?= =?us-ascii?q?t2IaRCmo/Rrnqhb0j6vXzgmo7ERRF1yNbIMmX/F5aXkWvnTmg89HkMF6tO02?= =?us-ascii?q?2aLokYiAFjaawm9n5Hc+XEG0yrxTkm4oZlOOCEdZ6g+gYHqSokfQ3xS/5NBM?= =?us-ascii?q?844Gz6ZAVCRpb1jZXdK5d+ZVAJp6/HglRlqQZGDRXhz4BhKshLxj1pPlkHjW?= =?us-ascii?q?yQsOCJd+Bf9uluC8Q0AsxfpinjA49YB4DPhVAxgqS3+Hzz6xoH7XSd4GSTOZ?= =?us-ascii?q?SmT89jxmFGSiIGIEWZpFtzU7VzlwWzunXprQ5a0dp1PuCpj2Moo29FPchBWj?= =?us-ascii?q?NTklO0LQtOEnNC6dtkdb/2ecsJELEiIB61PBomEuQ6mlaE5lxwgSLhajdp5V?= =?us-ascii?q?IHqQz+fixxeDcchqrkhTwZrJ35ZW0EHssbJTx0dTzMbhmbkHoK4kUXYBRwVp?= =?us-ascii?q?QQEttJvKoa2JNQ85mKRROtJD0LGht4OVFwyq9emFJN6Rb9G0HBWFP1L6mf7U?= =?us-ascii?q?UmI5jC5MSpea76wCdZkJG/uscVzJ9aYEGJnSCyUcrdsdHAreHTmgzRevrbae?= =?us-ascii?q?qTeDzKYyeZ3nXS5LdxIYPN+nrvN1hgNpN4xHE4M7ToFWOZGRVdO+c6Kxh/VL?= =?us-ascii?q?tmLOhAuf1QfMR+eawEq4tsHQ7CbwnkGI2xoasjTDebYTXFM2C59fej86bS9q?= =?us-ascii?q?CYaeXkfp6oxm3bBplqNIxx8zjxFuXB2tw7mCv8j/df82pxQ2fjdHvfvfK9BS?= =?us-ascii?q?JM9PmLTG36gr9qMj3UJrQq113nzRlfVcsdQnGb4qYK8dAI+VzWbMRB/k7Dvb?= =?us-ascii?q?QC6p57jOtWq6hTydfrILj8IvRFqnB7DR2mDFlF6pcoK2UnQ0lVYcMeFdX2Vv?= =?us-ascii?q?w3ysC1iKP2Kp4GtF7O4sd0T/39GFPwpvWWGxOQU3km/U9Ru2ZGITSM7a+HhK?= =?us-ascii?q?5OeP6Chs3y1GsP82G4LTAo0pJ99J3fwKy3/7LqOkiZ3f0FQK/sXsTpsvE2tl?= =?us-ascii?q?iP4eFxkrMTZnZ8Z17vAK0cTMkb3mD60eUn1zgrCZblGLTtq6MRe1cQpBm5wM?= =?us-ascii?q?4vRxE6H/oOFoCG9oNEkjVwg7nfMdsbNuhakXraTEb8VvcZ0SvvoyKbI2hg1w?= =?us-ascii?q?uKmxjrWW3m9hu+tzJxFBiMgNvmm1BeYbC4Cm9MVi6of0J9uTKLc06g7YKr6f?= =?us-ascii?q?lqshl3diSk+96InXGqfalaB8rlOPSdLDU64lUNg9J1DoX3hdBGRoTlYeJV9n?= =?us-ascii?q?Z4Y6GEuUq2jy9MpbtGjIPC48aTv8/aBmSkk7bA8u3fzTRczD05u1s499asc/?= =?us-ascii?q?+I7NyRSPPu3GEUHG9kowWUZxeusfTAqkwMf0mC0UPFgosPa8tF0jwy2E2j7u?= =?us-ascii?q?8+Rtk+7y1fG5rOIfQYqmO7IyP6lHCYZd9/TSyCy31XE1byREF/A7Q50Xnssd?= =?us-ascii?q?jhkH7R/xspS5V+MUv9ik8/A4Y5LBc14UMMimoYEAcLYAyGFrzgG0n/LIUFWE?= =?us-ascii?q?RCIRSK1bS3YOE2iGVyz6+houjJYr80C68ELP0IlgeVhxAbAscQtqsTCL59YA?= =?us-ascii?q?pb86ja50DuXonqQ/agkmA/bKfneM1R/MEHundn2T6RGkr4u69K9K1TyJmMcq?= =?us-ascii?q?gBYJ7Gu9164wJpozUObSdKxhN4ikHxXecZreHlqt/V1fjgovyyW+MnSelS/R?= =?us-ascii?q?8pAW9zlLPxjUwt59bN2K9QR5bUhoL27A1WayLM49+cikgsb7ZSY4uwNK5t7X?= =?us-ascii?q?AGOzQTKxdsdZKNZv8w7jUseDTf6lpeA98dMNYRPc7DgwdR2QXiXLBe8NaeG0?= =?us-ascii?q?fNV8EoLoZxvjqxlGxmlPl0Gvzt4zK3O53FulhJO/UGjSNmk8/EqK0bh/HTEy?= =?us-ascii?q?MQp3KebksQoGvKxp+TBvL35ejJxsvTUgZMBDI5Fo1TKH+I/hGhTeeuvJTkTg?= =?us-ascii?q?3S7dX8ysFbFgrYVjmqkaIJv7wZW/RchWDx0DQbHIfogfmYqPKt5XdZ8FpdH8?= =?us-ascii?q?wgpQ2AE6JZMJJhPB3+ncT+XVByMSz5fNCHE3hm8PrT3OoH5P9yclfvfYJOaA?= =?us-ascii?q?xR0Kr0sDAGBhsrUrP9uUyVGP4cdMczAu2RtWhbsOcCY+cOJATP/cas9G0O9Q?= =?us-ascii?q?BwWEhzNPcxtmAIKBWIxVINHfek/uZH0FdUUMYl6xMKQjv2YTNuoWGdEv4K6c?= =?us-ascii?q?vZQP0NrmfJFv1ICR04dHovBUrkgtI0JPOohawV7TkAx30i5qFwiHo8HEfZ22?= =?us-ascii?q?WkprpTi2h4oOjq7WVQ4S4cFL6XwXWPVAsLzexU3/1EUy+wsAztOCtaNtX5su?= =?us-ascii?q?sgeJqFl8Fp4mxhM097J3RUBLX4U3Or1/vRUNTX6YsO1kbK5pmGbKftf3JMbu?= =?us-ascii?q?tvx0u8HyotilCGzk81qDNZEG3nsoNBRs31fM8hwmDxQzrheV0B471EvI7KjX?= =?us-ascii?q?BQFLRkT1RnzS0j28yDQGgMQsbIBmA5ywZiYmRfe5UF4hgfReEuhX6Ts69K8x?= =?us-ascii?q?txAn+cG5m5+oTWgcbD2GUsBdZsyGXMo6SZh5QsmHR7ktJw5ySKtTwcbevdG8?= =?us-ascii?q?NrB3Hy0M9Yx4mcL721tfsbTYJ91Lm7ePoLM83l+Gaq1tNtQEDkjrUSElylMf?= =?us-ascii?q?MSk7fWVyD2LA/QEe+PcmWKg3M4Khuuo0LxaARmOIEW8xx1KObJi59Cmhe0WL?= =?us-ascii?q?dwQGCRo1Xc0WovdO1cfAMts4DhcAsPH4tzL6CRI/YjxPomBR4CdXjMSGFsF+?= =?us-ascii?q?Dzu1Ch2YJ8JnNr7F7SYOnx/EbhKtTYSXxmWcbK64V8//C3XDfLIXh70Bh7J1?= =?us-ascii?q?V57c/aHlU18O5Rb5jXmsLfzYczwasOcPFjNjc4s9gYl9d48Yej18GOYEiAnK?= =?us-ascii?q?a3Hsncp72jO9Oayk0rfm9AVb9AOVH06pk0eNkjVO+KROYLjVEnHaE/BacZGS?= =?us-ascii?q?Lx+aVzdV4hdwfQYPK1j9Xk4OWRackMqg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0G2AAA3dRFbhyzGHwRcHQEBBQELAYJ?= =?us-ascii?q?wUGVwBCATg3eIBF+MCYFYlG2BbhUYCwkChDkDAoIIGQcBNBgBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAhABAQEKCwkIKCMMgjUFAgMYCAkvHC8BAQEBAQEnAQEBAQEBIwJEMAQ?= =?us-ascii?q?CIB0BAQQKKQECAwECBgIcCAIiBAICAwFDAhQYgx0CggACAgqmGG2CHIJvAQE?= =?us-ascii?q?FhQZEgWAIgQqFCYIsghOBDzCFbgEBAgEBFoFbCC+CNIJUjRSLWgmFbIh1gTx?= =?us-ascii?q?AgzeHYolzhyaBQTiBU30iXgtVgSYJgguIfIVeT3yMfYFxAQE?= X-IPAS-Result: =?us-ascii?q?A0G2AAA3dRFbhyzGHwRcHQEBBQELAYJwUGVwBCATg3eIB?= =?us-ascii?q?F+MCYFYlG2BbhUYCwkChDkDAoIIGQcBNBgBAQEBAQEBAQEBAQEBAhABAQEKC?= =?us-ascii?q?wkIKCMMgjUFAgMYCAkvHC8BAQEBAQEnAQEBAQEBIwJEMAQCIB0BAQQKKQECA?= =?us-ascii?q?wECBgIcCAIiBAICAwFDAhQYgx0CggACAgqmGG2CHIJvAQEFhQZEgWAIgQqFC?= =?us-ascii?q?YIsghOBDzCFbgEBAgEBFoFbCC+CNIJUjRSLWgmFbIh1gTxAgzeHYolzhyaBQ?= =?us-ascii?q?TiBU30iXgtVgSYJgguIfIVeT3yMfYFxAQE?= X-IronPort-AV: E=Sophos;i="5.49,467,1520899200"; d="scan'208";a="83324536" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mail.ietf.org ([4.31.198.44]) by alln-inbound-f.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2018 16:36:09 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0334D12DA25; Fri, 1 Jun 2018 09:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1527870969; bh=2kTHvrz0bOESR1OTGlEwxrkv6TsT1D/7f5K2oGq+cGw=; h=From:To:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=JmjMjdO1TH6cU8Jl4JRB30LdgF68VETPOMn6MhPxjDOW17Z2AkTQ+CVS0nrUianLk D1edSSWEtGNpl3PHsHu6vsDtWp6NEoPp0ZkBxBS5KOL9HJSvhERQd08OGoIofz4467 MLw6FFUFP0NjN1k1PK0g4mr/Kyj7U6bl2VV5sKbo= X-Mailbox-Line: From rtg-bfd-bounces@ietf.org Fri Jun 1 09:36:07 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 147EB12D96A; Fri, 1 Jun 2018 09:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1527870967; bh=2kTHvrz0bOESR1OTGlEwxrkv6TsT1D/7f5K2oGq+cGw=; h=From:To:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=hZmAcbWM/36yN4KI/xXARNpTJ+GfjNK2/Obc0wJibi4YzZzQ+9yBNMNQDnXe18uOw pRhx7mwFchwsWtgmZb4GtjmCe0lAlkDgUJOC0F/h3K+iUZy4+3qCENNRWzYTTAyJdr 8z04gWxR9jwiRYPOKMcfAJxQnkFFvJxyr3RnW35U= X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B1A12D95A; Fri, 1 Jun 2018 09:36:05 -0700 (PDT) From: To: Subject: I-D Action: draft-ietf-bfd-yang-14.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152787096504.15240.3903059178554924393@ietfa.amsl.com> Date: Fri, 1 Jun 2018 09:36:05 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , CC: Errors-To: rtg-bfd-bounces@ietf.org Sender: Rtg-bfd Return-Path: rtg-bfd-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: XCH-RTP-014.cisco.com X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-Network-Message-Id: de702fc0-bf7a-4f7a-a54b-08d5c7e036a1 X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection WG of the IETF. Title : YANG Data Model for Bidirectional Forwarding Detection (BFD) Authors : Reshad Rahman Lianshu Zheng Mahesh Jethanandani Santosh Pallagatti Greg Mirsky Filename : draft-ietf-bfd-yang-14.txt Pages : 74 Date : 2018-06-01 Abstract: This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-yang-14 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-yang-14 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/ --_002_087AACB45F004A13B5C98D50B7C40C06ciscocom_-- From nobody Mon Jun 4 12:16:27 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F7E130DCC; Mon, 4 Jun 2018 11:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no 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 OVar4S6tE4Qe; Mon, 4 Jun 2018 11:58:45 -0700 (PDT) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (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 63C89130DC0; Mon, 4 Jun 2018 11:58:44 -0700 (PDT) Received: by mail-lf0-x243.google.com with SMTP id n3-v6so26897400lfe.12; Mon, 04 Jun 2018 11:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LRHVBqnUqCJdnlRHJh4l5SQrDlXSF8qAwVVpBWCN3XM=; b=g1+8kfOfYjo9qFbiKbPTDUJfjO4iU36D/R7j7ER7FIO97vIZNwcVpx0Y3rHUTtYuCG Ldv7TTLgPeBKSeyDZFRVSZKxowhKQk861QkqoIDjHrjFhKmBLomIgQP0IygvNlkx9cdX W0aPi5jCNsUOUx4+Bx4W0+Rp9pdNtQLEKhOJ7k3Mycd7Zn4q6QDPGINOszHpDAzZz3Ux Ecxibwn8kcjDEccSNHcZA0B/wjRBgl38OpesReGzRz31p9pKg8GBdBtgiytkqZtqjzbi kaHtkJBOR0CJnjTb3bg26mIN5MTOAQlmauG5I0Jggo0xWOViUMpIJutyHILXKFHHLYsN jfRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LRHVBqnUqCJdnlRHJh4l5SQrDlXSF8qAwVVpBWCN3XM=; b=KaD9AW5kk32ZXg1Xp25crqOdBImXPvB7z97g2unrUmRkTUfyk6xQ1c0zGQpqWbEFEl P0FY3RJxb3ZCDjDm3PDfkJHl7bUMS+5O9SWnAvSHIPeQ1LZQrira1mv4y09wzYP9TEMV ltY0kJgeSBwBncDOuZC0CRGD15zQ+r/NQPLBRm49R0PQZkMCxgAIdtkgalhqQ91LJD1F nSDZffvQlUCT9IgMa4KBwCTgWGbO/+quuD6v+JohIzGmDWtkGtaD11UPbvP/Yc0AgwuK wKlrBMUpaAZsFyyiA3ETCcync8gehTvROPjSiBov67tCaSNO6WvlDQP5naOLeXm956Ir nKgA== X-Gm-Message-State: APt69E3VDAAOwOwrfYbyKqBNdqkchkdoVgEHvfyaBpjSV92OFEd+a0M6 4aUhX7aVEk5W6FR4J2YTq4KdAQ7Nk9dPRtZWdxM= X-Google-Smtp-Source: ADUXVKIBoAD8PyZM7OujQa5t4TyvCXOvUoVtFmTGX7rSip95eA0f2Yr43x+W190w61cHTUsUMGXsoGJi8//izM39HzU= X-Received: by 2002:a19:a413:: with SMTP id q19-v6mr8592902lfc.143.1528138722363; Mon, 04 Jun 2018 11:58:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Mon, 4 Jun 2018 11:58:40 -0700 (PDT) In-Reply-To: <5e3c3eb1-23ec-3dc3-23c7-a8b22e8cdf4b@nokia.com> References: <04c76bec-ed2d-c3b1-6b92-b31d6a5ff620@nokia.com> <5e3c3eb1-23ec-3dc3-23c7-a8b22e8cdf4b@nokia.com> From: Greg Mirsky Date: Mon, 4 Jun 2018 11:58:40 -0700 Message-ID: Subject: Re: AD review for draft-ietf-bfd-multipoint-active-tail To: Martin Vigoureux Cc: draft-ietf-bfd-multipoint-active-tail@ietf.org, "Reshad Rahman (rrahman)" , rtg-bfd@ietf.org, bfd-chairs@ietf.org Content-Type: multipart/mixed; boundary="000000000000b6edba056dd585ed" Archived-At: X-Mailman-Approved-At: Mon, 04 Jun 2018 12:16:26 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 18:58:57 -0000 --000000000000b6edba056dd585ed Content-Type: multipart/alternative; boundary="000000000000b6edb7056dd585eb" --000000000000b6edb7056dd585eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Martin, thank you for clarifications and my apology for the missed question. Couple follow-up notes tagged GIM2>>. I'll publish new version shortly. Regards, Greg On Thu, May 31, 2018 at 5:53 AM, Martin Vigoureux < martin.vigoureux@nokia.com> wrote: > Greg, > thanks in return for your answers. > Please see in-line. Please publish a new version. > I'll go through it and then might request LC. > > -m > > Le 2018-05-23 =C3=A0 5:56, Greg Mirsky a =C3=A9crit : > >> Hi Martin, >> thank you for the thorough review, thoughtful comments, and questions >> that require discussion. >> Please find my answers, notes in-line tagged GIM>>. >> >> Attached are the new working version of the draft and the diff to -07. >> I'll update the references and share an update after that's done. >> >> Regards, >> Greg >> >> On Fri, May 18, 2018 at 10:35 AM, Martin Vigoureux < >> martin.vigoureux@nokia.com > wrote: >> >> WG, Authors, >> >> hello. >> >> thank you for this Document. I have done my AD review. >> I find the document much harder to apprehend than mpBFD. I have a >> number of comments but may have another round of them based on your >> replies. >> >> -m >> >> --- >> >> General: >> I find the use of reliable (and of its variants) not appropriate. >> You refer to reliability in terms disambiguating failure scenarios, >> you don't make packet transfer/delivery more reliable which is >> usually the context that comes in mind when talking about >> reliability. So I'd really prefer if you could use another word. >> >> GIM>> Trying to characterize polling tails by the head over the multicas= t >> path as unreliable mechanism vs. over the unicast as relaible may be is = as >> a strech. I think that we should replace "unreliable/semi-reliable/relia= ble" >> references with ones that characterize the polling. The "unreliable" >> notification to the head doesn't use polling tail(s) and may be referred= to >> as no-polling method. For the two other methods I can propose two option= s: >> >> * "in-band" for polling using the multicast tree and "out-band" - >> polling using unicast; >> * "fate-sharing" for polling using the multicast tree and "disjoint" - >> polling using unicast. >> > I don't like any of these :-) > > I'd simply call them: "no-poll", "1-poll", "2-polls". > GIM2>> I like your idea and may propose minor change: - no-poll - replaces "unreliable"; - mcast-poll - semi-reliable; - composite-poll (composite - use of both mcast and unicast poll sequences) - reliable. And I would rewrite first paragraph as: > This application of BFD is an extension to Multipoint BFD > [I-D.ietf-bfd-multipoint], which allows tails to notify the head of > the lack of multipoint connectivity. As a further option, heads can > request a notification from the tails by means of a polling > mechanism. Notification to the head can be enabled for all tails, or > for only a subset of the tails. > > The discussion on fate sharing between unicast and multipoint paths >> is really reduced to the bare minimum while it is of key importance >> on the operation of the protocol and on the deduction the head can >> make of what it receives or not. >> >> GIM>> The new text to introduce and explain the terms may be good place >> to expand on how selection of the path to use for tail polling impacts o= n >> how useful is the proposed extension. >> > Maybe, though I'm not convinced. To do so you'd have to get a bit into th= e > details of the three modes of operation. That would look a lot like > 4.1/2/3/4. > I think it would fit nicely in 4. because you introduce here the types of > paths. Have a paragraph there which raises the awareness of the reader to > the fate sharing issue. Doesn't need to be long. > > Abstract >> >> Please specify here which document(s) this one updates. Please see >> further down on the Update point. >> > You still need to address that. > This Document updates mpBFD. It is also missing in the header now. > >> >> >> 1. Introduction >> >> Multipoint BFD base document [I-D.ietf-bfd-multipoint] describes >> procedures to verify only the head-to-tail connectivity over the >> multipoint path. Although it may use unicast paths in both >> directions, Multipoint BFD does not verify those paths (and in >> fact >> it is preferable if unicast paths share as little fate with the >> multipoint path as is feasible, so to increase probability of >> delivering the notification from the tail to the head). >> This is unclear. The first sentence sets the reader in the context >> of I-D.ietf-bfd-multipoint where unicast paths are not discussed at >> all. And the rest of this paragraph discusses the unicast paths >> which are in fact introduced later in this document. So this is >> totally confusing. One only understands this after having read the >> whole document... >> I would suggest to completely remove, or rephrase to indicate to the >> user that this is an aspect that is introduced later, or move to the >> relevant place in the document. >> >> GIM>> The text is confusing, agree. And I think that removing this >> paragraph would not lose any helpful information as the very next paragr= aph >> gives clear motivation for this extension: >> The goal of this application is for the head to reasonably rapidly >> have knowledge of tails that have lost connectivity from the head. >> > agreed. > > >> >> This document effectively modifies and adds to the base BFD >> specification [RFC5880] and base BFD multipoint document >> [I-D.ietf-bfd-multipoint]. >> In the same was as for mpBFD, I don't see how this document updates >> 7880. Please clarify. >> >> GIM>> It is all related, or so we thought, to bfd.SessionType that has >> been added as the new BFD variable in RFC 7880 and the new values added = in >> mp BFD. In this draft a new value, MultipointClient, is added: >> bfd.SessionType >> >> The type of this session as defined in [RFC7880]. A new value >> introduced is: >> >> MultipointClient: A session on the head that tracks the state >> of an individual tail, when desirable. >> >> We've discussed whether the base mp BFD specification updates RFC 7880 >> and had agreed to remove it from the list. I'll be glad to do the same f= or >> this draft. >> > I view Update as a way to indicate a modification rather than an addition= . > As an example 7471 does not Update 3630. From that point of view, adding = a > value to a variable defined in 7880 does not change and thus does not > Update 7880. > > >> In fact I also think this document does not update 5880. >> This document updates mpBFD so in principle that should be reflected >> in the header, but I'm not sure if we can reference anything else >> than RFCs there... But I'll push the two at the same time to IESG so >> that might work. >> And one could wonder why these two documents are separate and not >> merged. >> >> GIM>> I think that you're right that this specification does not update >> RFC 5880 but does update mp BFD specification (which, in turn, updates R= FC >> 5880). Should references to sections of RFC 5880 in 14.13.1 through 14.1= 3.3 >> of this draft be replaced with references to corresponding sections 4.13= .1 >> through 4.13.3 of I-D.ietf-bfd-multipoint? >> > Yes, please make sure that you point to the correct rfc/section that you > update. > Please also add what you update in the header and in the abstract. GIM2>> Please check the new version. > > > 2. Overview >> >> A head may wish to be alerted to the tails' connectivity (or lac= k >> thereof), there are a number of options. >> Something's wrong with the structure of that sentence. >> > you missed that one. > > I find this: >> First, if all that is needed is an unreliable failure >> notification, >> as discussed in Section 3.2, the head can request the tails to >> transmit unicast BFD Control packets back to the head when the >> path >> fails, as described in Section 4.4. >> somehow in conflict with what is said in 3.2 (to which the reader is >> pointed) and which says: >> In this scenario, the tail sends back unsolicited BFD packets in >> response to the detection of a multipoint path failure. It uses >> the >> reverse unicast path, but not the forward unicast path. >> On one hand you say "request" on the other you say "unsolicited", >> and just before that word you say "sends back" which gives a sense >> of "in response to". Could you clarify? >> I have more comments on this section, and more precisely on the >> different modes of operations, but I'll discuss theses as part of >> the review of Section 3.x >> >> GIM>> The new state variable bfd.ReportTailDown controls whether a >> MultipointClient sends periodic, i.e. unsolicited, BFD control packets t= o >> the MultipointHead, as >> > Did you really mean "MultipointClient to MultipointHead" here? > GIM2>> Yes, I misspoke. It is MultipointTail that sends control packets to MultipointHead. The variable has meaning only if bfd.SessionType is MultipointHead or MultipointClient. > > Also, as far as I understand, in the "no-poll" scenario the head is not > requesting anything so this needs to be reworded: > the head can request the tails to transmit unicast BFD Control > packets back to the head when the path fails, as described in Section > 4.4. > You could say: > the tails can send unsolicited unicast BFD Control packets to the > head when the path fails. > GIM2>> Done. > > Also: > s/the tail sends back unsolicited/the tail sends unsolicited/ GIM2>> Done. > > >> >> In the two subsequent paragraphs a pointer to 3.3. and 3.4 would not >> be superfluous. >> >> GIM>> Will add. >> > Please do. > >> >> >> If the head wishes to know the identity of the tails on the >> multipoint path, it may solicit membership by sending a multipoi= nt >> I don't think it is appropriate to talk about identity and >> membership. Head is polling a set of tails. You can't say much more >> than that. >> >> GIM>> Agree. Would the following update be acceptable: >> OLD TEXT: >> If the head wishes to know the identity of the tails on the >> multipoint path, it may solicit membership by sending a multipoint >> BFD Control packet with the Poll (P) bit set ... >> NEW TEXT: >> If the head wishes to know of the active tails on the >> multipoint path, it may send a multipoint >> BFD Control packet with the Poll (P) bit set ... >> > I'm ok with that, but that is not what you changed the text to in the > Document. GIM2>> Fixed. > > >> >> >> Individual tails may be configured so that they never send BFD >> control packets to the head, even when the head wishes >> notification >> of path failure from the tail. Such tails will never be known >> to the >> head, but will still be able to detect multipoint path failures >> from >> the head. >> ok, but how does the head knows of this config? How can the head >> distinguish between a failure and this? I guess the answer is oos of >> the document but I think that this situation is worth more than 4 >> lines. >> Or is there a requirement that a Head SHOULD/MUST NOT have a >> MulticastClient session with a tail who is silent? >> >> GIM>> I think this refers to the case when bfd.SilentTail being set to 1= . >> In this case the tail is invisible to the head as it would not respond t= o >> any polling, muticast or unicast. As result, such tail would not notify = the >> head of the detected failure either. These tails acting as in the mode >> defined in the base mp BFD specification. >> > Ok. understood. Then I think there is a slight clarification to bring. > Indeed the first sentence says: > even when the head wishes notification of path failure from the tail. > This gives the impression that the head knows *the tail*. You can't be > wishing a notification from something you don't know exists. > Maybe simply remove that part of the sentence. GIM2>> Agreed. > > 3.x Operational Scenarios >> >> I find the description of the different modes of operation quite >> confusing. Beyond this I have other comments/questions on 3.x that >> you'll find after. >> > I would like to see some text saying: > For the different modes described below the setting of new state variable= s > are given even if these are only introduced later in the document (see > Section X.Y). > > And that for each mode you say how should the variables be set, in which > session. GIM2>> I've tried in the new version (attached). > > > > 3.1 is plain multipoint BFD I guess. Correct? >> >> GIM>> Yes the behavior of MultipointTail as defined >> in I-D.ietf-bfd-multipoint (can we refer to it as base mp BFD >> specification?). But with active tail extension this behavior is the res= ult >> of setting the new BFD variables to very specific values. Section 4.4 >> explains that the base mp BFD mode is when bfd.ReportTailDown to 0 >> bfd.SessionType is MultipointHead. >> > So I believe it is important to inform the reader of that. With something > like: > This mode emulates the behaviour of mpBFD. > > > >> In 3.2 you say that tails send packets to the source when they >> detect a failure (stop receiving packets). At this point of the >> reading it is not clear which element makes a difference between 3.1 >> and 3.2 such that, suddenly in 3.2, tails can send packets. >> >> GIM>> For one, bfd.SilentTail must be set to 0. >> >> I believe it is worth clarifying that, though not giving too many >> details. Relates to 4.4? >> Also at this stage it is not clear what are those packets that tails >> send in 3.2. Are they replies to Polls? If so what is the difference >> between 3.2 and 3.3? >> >> GIM>> The MultipointTail may periodically send BFD control packets with >> Poll set. If the MultipointHead does not send unicast BFD control packet >> with Poll cleared and the Final set, then, I believe, the MultipointTail >> will continue sending its Poll packets periodically. Hence the differenc= e >> between polling by the MultipointHead per 3.3 and 3.4 and the unsolicite= d >> periodic Polls from the tail. >> >> >> >> 3.1. No Head Notification >> >> You say: >> Since the only path used in this scenario is the multipoint path >> as if it had been stated before that this scenario only uses the >> mpPath. >> It would be much more comprehensible if it was saying: >> In this scenario only the multipoint path is used. >> >> GIM>> Thank you, accepted. The text now is: >> In this scenario only the multipoint path is used and none of the others >> matter. >> > ok > >> >> >> >> 3.3. Semi-reliable Head Notification and Tail Solicitation >> >> You say (twice): >> the head will see the BFD session fail >> Could you clarify which session fails,? >> >> GIM>> It is the MultipointClient session. Would the new text make it >> clearer: >> OLD TEXT: >> ... the head will see the BFD session fail, but the state of the >> multipoint path will be unknown to the head. >> NEW TEXT: >> ... the head will see that the particular MultipointClient >> session fail ... >> > ok > > >> >> >> 3.4. Reliable Head Notification >> >> same comment as for 3.3 >> >> GIM>> Would the text proposed above be acceptable? >> > yes. please apply it > >> >> >> >> 4. Protocol Details >> >> This section is an update to section 4 of >> [I-D.ietf-bfd-multipoint]. >> Should you rather say that it's only some parts of this section >> which update mpBFD, and say which ones. >> >> GIM>> Here's the proposed new text: >> OLD TEXT: >> This section is an update to section 4 of [I-D.ietf-bfd-multipoint]. >> NEW TEXT: >> This section updates Section 4 of [I-D.ietf-bfd-multipoint] as the >> following: >> - Section 4.3 introduces new state variables and modifies the usage >> of a few existing ones; >> - Section 4.13 replaces the corresponding sections in the base BFD >> for multipoint networks specification. >> > ok > > >> >> >> >> 4.1. Multipoint Client Session >> >> If the head is keeping track of some or all of the tails, it has= a >> session of type MultipointClient per tail that it cares about. >> All >> of the MultipointClient sessions for tails on a particular >> multipoint >> path are grouped with the MultipointHead session to which the >> clients >> are listening. >> What do you mean by "grouped", associated? >> >> GIM>> Yes, "associated" is better term, I agree. Will update. >> > ok > > >> >> These sessions receive any BFD Control packets sent by the >> tails, and >> never transmit periodic BFD Control packets other than Poll >> Sequences >> (since periodic transmission is always done by the MultipointHea= d >> session). >> Should it be "MUST never send"? >> >> GIM>> Would s/never/MUST NOT/ to make it into "MUST NOT transmit" be >> acceptable? >> > yes, thanks > >> >> >> A BFD Poll Sequence may be sent over such a session to a tail if >> the >> head wishes to verify connectivity. >> It is not clear here if you are talking about sending a multipoint >> Poll sequence to all tails over the MultipointHead session or a >> unicast Poll sequence to a single tail over one MultipointClient >> session. >> >> GIM>> s/such a session/a MultipointClient session/ >> > thanks > > >> >> >> 4.3.2. New State Variable Value >> >> This variable MUST be initialized to the appropriate type >> when the >> session is created, according to the rules in section 4.13 of >> [I-D.ietf-bfd-multipoint]. >> There is nothing in 4.13 of mpBFD that talks about the >> initialization of bfd.SessionType. >> >> GIM>> This is the problem with keeping cross-references while updating >> both documents. The correct reference now is to Section 4.4 >> of[I-D.ietf-bfd-multipoint]. >> > > ok > >> >> >> >> 4.3.3. State Variable Initialization and Maintenance >> >> Some state variables defined in section 6.8.1 of the [RFC5880] >> needs >> to be initialized or manipulated differently depending on the >> session >> type (see section 4.4.2 of [I-D.ietf-bfd-multipoint]). >> s/of the/of/ >> s/needs/need/ >> s/ (see section 4.4.2 of [I-D.ietf-bfd-multipoint])./. The values of >> some of these variables relate to those of the same variables of a >> MultipointHead session (see section 4.4.2 of >> [I-D.ietf-bfd-multipoint])./ >> >> GIM>> All accepted and applied to the working version. >> > thanks > minor typo: > s/type/type./ > >> >> >> >> bfd.RequiredMinRxInterval >> It should be noted that for sessions of type MultipointTai= l, >> this variable only affects the rate of unicast Polls sent = by >> the head; the rate of multipoint packets is necessarily >> unaffected by it. >> what is specific to MultipointClient here? If nothing, please remove= . >> If something, please add it clearly. >> >> GIM>> I propose the new text below. >> OLD TEXT: >> It should be noted that for sessions of type MultipointTail, >> this variable only affects the rate of unicast Polls sent by >> the head; the rate of multipoint packets is necessarily >> unaffected by it. >> NEW TEXT: >> It MAY be set to zero at the head BFD system to suppress traffic from th= e >> tails. >> Setting it to zero in the MultipointHead session suppresses traffic from >> all tails, >> setting in a MultipointClient session suppresses traffic form a single >> tail. >> > > ok > >> >> >> >> 4.4. Controlling Multipoint BFD Options >> >> The most basic form of operation, as explained in >> [I-D.ietf-bfd-multipoint], in which BFD Control packets flow onl= y >> from the head and no tracking is desired of tail state at the >> head, >> is accomplished by setting bfd.ReportTailDown to 0 in the >> MultipointHead session (Section 3.1). >> I am a bit concerned that mpBFD in fact works with a state variable >> defined in another document. Wouldn't it be better to introduce this >> variable in mpBFD and set it to always be zero and then allow in >> this doc to be set at 1. A bit like the M bit. >> >> GIM>> Great idea, thank you! If we do that, would such update to mpBFD >> document require re-start of WGLC? >> > thinking twice about that, let's keep the way things are. > > >> >> You have text relating to 3.1. What about 3.2/3/4? >> >> GIM>> The fifth paragraph can be back referenced to section 3.4. The >> fourth paragrah describes use of bfd.ReportTailDown common to unsolicite= d >> notifications, multicast and unicast polling, i.e. sections 3.2, 3.3, an= d >> 3.4. >> > please do. > >> >> >> If the head wishes to know the identity of the tails, it sends >> multipoint Polls as needed. Previously known tails that don't >> respond to the Polls will be detected (as per Section 3.3). >> Again, I'd prefer not to talk about identity, but simply about >> messages received from tails or not. >> I don't see the purpose of this paragraph here. What is the relation >> with state variables? >> >> GIM>> It may be better to move this paragraph down by one, swap >> paragraphs. And would the following re-wording mak text clearer: >> OLD TEXT: >> If the head wishes to know the identity of the tails, it sends >> multipoint Polls as needed. Previously known tails that don't >> respond to the Polls will be detected (as per Section 3.3). >> NEW TEXT: >> If the head wishes to know of the active tails, it sends >> multipoint Polls as needed. Previously known tails that don't >> respond to the Polls will be detected (as per Section 3.3). >> > ok, ok. > >> >> >> If the head wishes to be notified by the tails when they lose >> connectivity, it sets bfd.ReportTailDown to 1 in either the >> MultipointHead session (if such notification is desired from all >> tails) or in the MultipointClient session (if notification is >> desired >> from a particular tail). Note that the setting of this variable >> in a >> MultipointClient session for a particular tail overrides the >> setting >> in the MultipointHead session. >> Does that correspond to 3.2, 3.3, 3.4? >> >> GIM>> Yes, it enables all three modes. >> > Still not clear. > ReportTailDown =3D 0 : don't poll tails > ReportTailDown =3D 1 : poll tails > is that correct? > GIM2>> Yes. > > If so: > s/If the head wishes to be notified by the/If the head wishes to request = a > notification from the/ GIM2>> Accepted. > > > >> >> If the head wishes to verify the state of a tail on an ongoing >> basis, >> it sends a Poll Sequence from the MultipointClient session >> associated >> with that tail as needed. >> If the head wants to more quickly be alerted to a session failur= e >> from a particular tail, it sends a BFD Control packet from the >> MultipointClient session associated with that tail. This has th= e >> effect of eliminating the initial delay, described in Section >> 4.13.3, >> that the tail would otherwise insert prior to transmission of th= e >> packet. >> I don't see the link with state variables here neither. Consider >> moving somewhere else. >> >> GIM>> I read it as continuation of what described in the preceeding >> paragraph regarding setting bfd.ReportTailDown in MultipointClient. >> > So please indicate it GIM2>> I've merged two paragraphs and re-worded to the following: OLD TEXT: If the head wishes to verify the state of a tail on an ongoing basis, it sends a Poll Sequence from the MultipointClient session associated with that tail as needed. If the head wants to be alerted to a session failure from a particular tail more quickly, it sends a BFD Control packet from the MultipointClient session associated with that tail. This has the effect of eliminating the initial delay, described in Section 6.13.3, that the tail would otherwise insert prior to transmission of the packet. NEW TEXT: If the head wishes to verify the state of a tail on an ongoing basis, it sends a Poll Sequence from the MultipointClient session associated with that tail as needed. This has the effect of eliminating the initial delay, described in Section 6.13.3, that the tail would otherwise insert prior to transmission of the packet thus the head may have notification of the session failure more quickly when comparing with use of m-poll. > >> >> If a tail wishes to operate silently (sending no BFD Control >> packets >> to the head) it sets bfd.SilentTail to 1 in the MultipointTail >> session. This allows a tail to be silent independent of the >> settings >> on the head. >> The implications of that option are not really discussed. The head >> will likely consider the session down, no? >> >> GIM>> The head would not learn of such tail nor it will be able to notic= e >> the tail state change. I think that s/be silent/be invisible to the head= / >> may make the text clearer. >> > understood > >> >> >> >> 4.5. State Machine >> >> The state machine for session of type MultipointClient is same a= s >> defined in section 4.5 of [I-D.ietf-bfd-multipoint]. >> Is that really the case? MultipointHead only fails administratively >> while MultipointClient can fails based on received message, no? >> >> GIM>> True. It is noted in Section 4.5 in mpBFD that for MultipointHead >> all state transitions are administratively driven. But the diagram is st= ill >> applicable for BFD MultipointClient session. >> > So, is a small clarification needed? I would think so. GIM2>> Added. > > >> >> >> 4.6. Session Establishment >> >> The head directly controls whether or not tails are allowed to >> send >> BFD Control packets back to the head. >> Not fully true, because of SilentTail, no? >> >> GIM>> It can be done by setting bfd.RequiredMinRxInterval to zero in >> MultipointHead session or a MultipointClient session. The former will fo= rce >> all tails not to send any BFD packet to the head. The latter - only the >> particular BFD tail. As stressed in the specification, the value in >> MultipointClient overrides the value in MultipointHead. >> > So please remind that to the reader (pointing to mpBFD spec) GIM2>> Added a sentence. > > >> >> >> 4.13.1/2/3 >> >> I think that, as said, you are not updating 5880. Also, you said >> that you update sections but really you are updating parts of them. >> I encourage you to find a clear way to indicate what you >> change/update. >> >> GIM>> I'll remove from these sections references to sections 6.8.6 and >> 6.8.7 of RFC 5880 and link updates to mpBFD specification. >> > please do > >> >> >> >> 7. Security Considerations >> >> Can't you elaborate a bit? This look a bit like the bare minimum. >> >> GIM>> You're right and more should be said about possible impact >> MultipointClient sessions. Proposed new text below: >> NEW TEXT: >> Additionally, implementations that create >> MultpointClient sessions dynamically upon receipt of BFD >> Control packet from a tail MUST implement protective measures to >> prevent an >> infinite number of MultipointClient sessions being created. Below a= re >> listed some points to be considered in such implementations. >> >> When the number of MultipointClient sessions exceeds the number o= f >> expected tails, then the implementation should generate an alarm >> to users to indicate the anomaly. >> >> The implementation should have a reasonable upper bound on the >> number of MultipointClient sessions that can be created, with the >> upper bound potentially being computed based on the number of >> multicast streams that the system is expecting. >> >> The text may be inserted as the second paragraph or replace the current >> second paragraph. >> > > ok > >> >> --- >> >> >> --000000000000b6edb7056dd585eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,
thank you for clarifications and=C2=A0my ap= ology for the missed question. Couple follow-up notes tagged GIM2>>.<= /div>
I'll publish new version shortly.

Re= gards,
Greg

On Thu, May 31, 2018 at 5:53 AM, Martin Vigoureux <mart= in.vigoureux@nokia.com> wrote:
Greg,
thanks in return for your answers.
Please see in-line. Please publish a new version.
I'll go through it and then might request LC.
-m

Le 2018-05-23 =C3=A0 5:56, Greg Mirsky a =C3=A9crit=C2=A0:
Hi Martin,
thank you for the thorough review, thoughtful comments, and questions that = require discussion.
Please find my answers, notes in-line tagged GIM>>.

Attached are the new working version of the draft and the diff to -07. I= 9;ll update the references and share an update after that's done.

Regards,
Greg

 On Fri, May 18, 2018 at 10:35 AM, Martin Vigoureux <martin.vigoureux@nokia.com = <mailto:= martin.vigoureux@nokia.com>> wrote:

=C2=A0 =C2=A0 WG, Authors,

=C2=A0 =C2=A0 hello.

=C2=A0 =C2=A0 thank you for this Document. I have done my AD review.
=C2=A0 =C2=A0 I find the document much harder to apprehend than mpBFD. I ha= ve a
=C2=A0 =C2=A0 number of comments but may have another round of them based o= n your
=C2=A0 =C2=A0 replies.

=C2=A0 =C2=A0 -m

=C2=A0 =C2=A0 ---

=C2=A0 =C2=A0 General:
=C2=A0 =C2=A0 I find the use of reliable (and of its variants) not appropri= ate.
=C2=A0 =C2=A0 You refer to reliability in terms disambiguating failure scen= arios,
=C2=A0 =C2=A0 you don't make packet transfer/delivery more reliable whi= ch is
=C2=A0 =C2=A0 usually the context that comes in mind when talking about
=C2=A0 =C2=A0 reliability. So I'd really prefer if you could use anothe= r word.

GIM>> Trying to characterize polling tails by the head over the multi= cast path as unreliable mechanism vs. over the unicast as relaible may be i= s as a strech. I think that we should replace "unreliable/semi-reliabl= e/reliable" references with ones that characterize the polling. T= he "unreliable" notification to the head doesn't use polling = tail(s) and may be referred to as no-polling method. For the two other meth= ods I can propose two options:

 =C2=A0 * "in-band" for polling using the multicast tree and "= ;out-band" -
=C2=A0 =C2=A0 polling using unicast;
=C2=A0 * "fate-sharing" for polling using the multicast tree and = "disjoint" -
=C2=A0 =C2=A0 polling using unicast.
I don't like any of these :-)

I'd simply call them: "no-poll", "1-poll", "2-= polls".
GIM2>> I like your idea and may pro= pose minor change:
  • no-poll - replaces "unreliable&qu= ot;;
  • mcast-poll - semi-reliable;
  • =C2=A0composite-poll (comp= osite - use of both mcast and unicast poll sequences) - reliable.
    • <= /ul>
And I would rewrite first paragraph as:
=C2=A0 =C2=A0This application of BFD is an extension to Multipoint BFD
=C2=A0 =C2=A0[I-D.ietf-bfd-multipoint], which allows tails to notify the he= ad of
=C2=A0 =C2=A0the lack of multipoint connectivity.=C2=A0 As a further option= , heads can
=C2=A0 =C2=A0request a notification from the tails by means of a polling =C2=A0 =C2=A0mechanism.=C2=A0 Notification to the head can be enabled for a= ll tails, or
=C2=A0 =C2=A0for only a subset of the tails.

=C2=A0 =C2=A0 The discussion on fate sharing between unicast and multipoint= paths
=C2=A0 =C2=A0 is really reduced to the bare minimum while it is of key impo= rtance
=C2=A0 =C2=A0 on the operation of the protocol and on the deduction the hea= d can
=C2=A0 =C2=A0 make of what it receives or not.

GIM>> The new text to introduce and explain the terms may be good pla= ce to expand on how selection of the path to use for tail polling impacts o= n how useful is the proposed extension.
 Maybe, though I'm not convinced. To do so you'd have to get a bit i= nto the details of the three modes of operation. That would look a lot like= 4.1/2/3/4.
I think it would fit nicely in 4. because you introduce here the types of p= aths. Have a paragraph there which raises the awareness of the reader to th= e fate sharing issue. Doesn't need to be long.
=C2=A0 =C2=A0 Abstract

=C2=A0 =C2=A0 Please specify here which document(s) this one updates. Pleas= e see
=C2=A0 =C2=A0 further down on the Update point.
 You still need to address that.
This Document updates mpBFD. It is also missing in the header now.


=C2=A0 =C2=A0 1.=C2=A0 Introduction

=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Multipoint BFD base document [I-D.ietf-bfd= -multipoint] describes
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0procedures to verify only the head-to-tail= connectivity over the
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0multipoint path.=C2=A0 Although it may use= unicast paths in both
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0directions, Multipoint BFD does not verify= those paths (and in fact
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0it is preferable if unicast paths share as= little fate with the
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0multipoint path as is feasible, so to incr= ease probability of
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0delivering the notification from the tail = to the head).
=C2=A0 =C2=A0 This is unclear. The first sentence sets the reader in the co= ntext
=C2=A0 =C2=A0 of I-D.ietf-bfd-multipoint where unicast paths are not discus= sed at
=C2=A0 =C2=A0 all. And the rest of this paragraph discusses the unicast pat= hs
=C2=A0 =C2=A0 which are in fact introduced later in this document. So this = is
=C2=A0 =C2=A0 totally confusing. One only understands this after having rea= d the
=C2=A0 =C2=A0 whole document...
=C2=A0 =C2=A0 I would suggest to completely remove, or rephrase to indicate= to the
=C2=A0 =C2=A0 user that this is an aspect that is introduced later, or move= to the
=C2=A0 =C2=A0 relevant place in the document.

GIM>> The text is confusing, agree. And I think that removing this pa= ragraph would not lose any helpful information as the very next paragraph g= ives clear motivation for this extension:
=C2=A0=C2=A0 =C2=A0The goal of this application is for the head to reasonab= ly rapidly
=C2=A0=C2=A0 =C2=A0have knowledge of tails that have lost connectivity from= the head.
 agreed.



=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0This document effectively modifies and add= s to the base BFD
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0specification [RFC5880] and base BFD multi= point document
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0[I-D.ietf-bfd-multipoint].
=C2=A0 =C2=A0 In the same was as for mpBFD, I don't see how this docume= nt updates
=C2=A0 =C2=A0 7880. Please clarify.

GIM>> It is all related, or so we thought, to=C2=A0bfd.SessionType th= at has been added as the new BFD variable in RFC 7880 and the new values ad= ded in mp BFD. In this draft a new value, MultipointClient, is added:
=C2=A0=C2=A0 =C2=A0 bfd.SessionType

=C2=A0=C2=A0 =C2=A0 =C2=A0 The type of this session as defined in [RFC7880]= .=C2=A0 A new value
=C2=A0=C2=A0 =C2=A0 =C2=A0 introduced is:

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MultipointClient: A session on the = head that tracks the state
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of an individual tail, when desirab= le.

We've discussed whether the base mp BFD specification updates RFC 7880 = and had agreed to remove it from the list. I'll be glad to do the same = for this draft.
 I view Update as a way to indicate a modification rather than an addition. = As an example 7471 does not Update 3630. From that point of view, adding a = value to a variable defined in 7880 does not change and thus does not Updat= e 7880.


=C2=A0 =C2=A0 In fact I also think this document does not update 5880.
=C2=A0 =C2=A0 This document updates mpBFD so in principle that should be re= flected
=C2=A0 =C2=A0 in the header, but I'm not sure if we can reference anyth= ing else
=C2=A0 =C2=A0 than RFCs there... But I'll push the two at the same time= to IESG so
=C2=A0 =C2=A0 that might work.
=C2=A0 =C2=A0 And one could wonder why these two documents are separate and= not
=C2=A0 =C2=A0 merged.

GIM>> I think that you're right that this specification does not= =C2=A0 update RFC 5880 but does update mp BFD specification (which, in turn= , updates RFC 5880). Should references to sections of RFC 5880 in 14.13.1 t= hrough 14.13.3 of this draft be replaced with references to corresponding s= ections 4.13.1 through 4.13.3 of=C2=A0I-D.ietf-bfd-multipoint?
 Yes, please make sure that you point to the correct rfc/section that you up= date.
Please also add what you update in the header and in the abstract.
GIM2>> Please check the new version.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
=C2=A0 =C2=A0 2.=C2=A0 Overview

=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0A head may wish to be alerted to the tails= ' connectivity (or lack
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0thereof), there are a number of options. =C2=A0 =C2=A0 Something's wrong with the structure of that sentence.
you missed that one.

=C2=A0 =C2=A0 I find this:
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0First, if all that is needed is an unrelia= ble failure notification,
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0as discussed in Section 3.2, the head can = request the tails to
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0transmit unicast BFD Control packets back = to the head when the path
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0fails, as described in Section 4.4.
=C2=A0 =C2=A0 somehow in conflict with what is said in 3.2 (to which the re= ader is
=C2=A0 =C2=A0 pointed) and which says:
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0In this scenario, the tail sends back unso= licited BFD packets in
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0response to the detection of a multipoint = path failure.=C2=A0 It uses the
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0reverse unicast path, but not the forward = unicast path.
=C2=A0 =C2=A0 On one hand you say "request" on the other you say = "unsolicited",
=C2=A0 =C2=A0 and just before that word you say "sends back" whic= h gives a sense
=C2=A0 =C2=A0 of "in response to". Could you clarify?
=C2=A0 =C2=A0 I have more comments on this section, and more precisely on t= he
=C2=A0 =C2=A0 different modes of operations, but I'll discuss theses as= part of
=C2=A0 =C2=A0 the review of Section 3.x

GIM>> The new state variable=C2=A0bfd.ReportTailDown controls whether= a MultipointClient sends periodic, i.e. unsolicited, BFD control packets t= o the MultipointHead, as
 Did you really mean "MultipointClient to MultipointHead" here?
GIM2>> Yes, I misspoke. It is MultipointTail that = sends control packets to MultipointHead. The variable has meaning only if b= fd.SessionType=C2=A0 is MultipointHead or MultipointClient.=C2=A0

Also, as far as I understand, in the "no-poll" scenario the head = is not requesting anything so this needs to be reworded:
=C2=A0 =C2=A0the head can request the tails to transmit unicast BFD Control=
=C2=A0 =C2=A0packets back to the head when the path fails, as described in = Section
=C2=A0 =C2=A04.4.
 You could say:
=C2=A0 =C2=A0the tails can send unsolicited unicast BFD Control packets to = the
=C2=A0 =C2=A0head when the path fails.
GIM2>> Do= ne.=C2=A0

Also:
s/the tail sends back unsolicited/the tail sends unsolicited/
<= div>GIM2>> Done.=C2=A0



=C2=A0 =C2=A0 In the two subsequent paragraphs a pointer to 3.3. and 3.4 wo= uld not
=C2=A0 =C2=A0 be superfluous.

GIM>> Will add.
 Please do.


=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0If the head wishes to know the identity of= the tails on the
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0multipoint path, it may solicit membership= by sending a multipoint
=C2=A0 =C2=A0 I don't think it is appropriate to talk about identity an= d
=C2=A0 =C2=A0 membership. Head is polling a set of tails. You can't say= much more
=C2=A0 =C2=A0 than that.

GIM>> Agree. Would the following update be acceptable:
OLD TEXT:
=C2=A0=C2=A0 =C2=A0If the head wishes to know the identity of the tails on = the
=C2=A0=C2=A0 =C2=A0multipoint path, it may solicit membership by sending a = multipoint
=C2=A0=C2=A0 =C2=A0BFD Control packet with the Poll (P) bit set ...
NEW TEXT:
=C2=A0=C2=A0 =C2=A0If the head wishes to know of the active tails on the =C2=A0=C2=A0 =C2=A0multipoint path, it may send a multipoint
=C2=A0=C2=A0 =C2=A0BFD Control packet with the Poll (P) bit set ...
 I'm ok with that, but that is not what you changed the text to in the D= ocument.
GIM2>> Fixed.=C2=A0




=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Individual tails may be configured so that= they never send BFD
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0control packets to the head, even when the= head wishes notification
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0of path failure from the tail.=C2=A0 Such = tails will never be known
=C2=A0 =C2=A0 to the
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0head, but will still be able to detect mul= tipoint path failures from
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0the head.
=C2=A0 =C2=A0 ok, but how does the head knows of this config? How can the h= ead
=C2=A0 =C2=A0 distinguish between a failure and this? I guess the answer is= oos of
=C2=A0 =C2=A0 the document but I think that this situation is worth more th= an 4 lines.
=C2=A0 =C2=A0 Or is there a requirement that a Head SHOULD/MUST NOT have a<= br> =C2=A0 =C2=A0 MulticastClient session with a tail who is silent?

GIM>> I think this refers to the case when bfd.SilentTail being set t= o 1. In this case the tail is invisible to the head as it would not respond= to any polling, muticast or unicast. As result, such tail would not notify= the head of the detected failure either. These tails acting as in the mode= defined in the base mp BFD specification.
 Ok. understood. Then I think there is a slight clarification to bring.
Indeed the first sentence says:
=C2=A0 =C2=A0even when the head wishes notification of path failure from th= e tail.
This gives the impression that the head knows *the tail*. You can't be = wishing a notification from something you don't know exists.
Maybe simply remove that part of the sentence.
GIM2>>= ; Agreed.



=C2=A0 =C2=A0 3.x Operational Scenarios

=C2=A0 =C2=A0 I find the description of the different modes of operation qu= ite
=C2=A0 =C2=A0 confusing. Beyond this I have other comments/questions on 3.x= that
=C2=A0 =C2=A0 you'll find after.
 I would like to see some text saying:
For the different modes described below the setting of new state variables = are given even if these are only introduced later in the document (see Sect= ion X.Y).

And that for each mode you say how should the variables be set, in which se= ssion.
GIM2>> I've tried in the new version (att= ached).=C2=A0



=C2=A0 =C2=A0 3.1 is plain multipoint BFD I guess. Correct?

GIM>> Yes the behavior of MultipointTail as defined in=C2=A0I-D.ietf-= bfd-multipoint (can we refer to it as base mp BFD specification?). But with= active tail extension this behavior is the result of setting the new BFD v= ariables to very specific values. Section 4.4 explains that the base mp BFD= mode is when=C2=A0bfd.ReportTailDown to 0 bfd.SessionType is=C2=A0 Multipo= intHead.
 So I believe it is important to inform the reader of that. With something l= ike:
=C2=A0 =C2=A0This mode emulates the behaviour of mpBFD.



=C2=A0 =C2=A0 In 3.2 you say that tails send packets to the source when the= y
=C2=A0 =C2=A0 detect a failure (stop receiving packets). At this point of t= he
=C2=A0 =C2=A0 reading it is not clear which element makes a difference betw= een 3.1
=C2=A0 =C2=A0 and 3.2 such that, suddenly in 3.2, tails can send packets.
GIM>> For one,=C2=A0bfd.SilentTail must be set to 0.

=C2=A0 =C2=A0 I believe it is worth clarifying that, though not giving too = many
=C2=A0 =C2=A0 details. Relates to 4.4?
=C2=A0 =C2=A0 Also at this stage it is not clear what are those packets tha= t tails
=C2=A0 =C2=A0 send in 3.2. Are they replies to Polls? If so what is the dif= ference
=C2=A0 =C2=A0 between 3.2 and 3.3?

GIM>> The MultipointTail may periodically send BFD control packets wi= th Poll set. If the MultipointHead does not send unicast BFD control packet= with Poll cleared and the Final set, then, I believe, the MultipointTail w= ill continue sending its Poll packets periodically. Hence the difference be= tween polling by the MultipointHead per 3.3 and 3.4 and the unsolicited per= iodic Polls from the tail.



=C2=A0 =C2=A0 3.1.=C2=A0 No Head Notification

=C2=A0 =C2=A0 You say:
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Since the only path used in this scenario = is the multipoint path
=C2=A0 =C2=A0 as if it had been stated before that this scenario only uses = the mpPath.
=C2=A0 =C2=A0 It would be much more comprehensible if it was saying:
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0In this scenario only the multipoint path = is used.

GIM>> Thank you, accepted. The text now is:
In this scenario only the multipoint path is used and none of the others ma= tter.
 ok



=C2=A0 =C2=A0 3.3.=C2=A0 Semi-reliable Head Notification and Tail Solicitat= ion

=C2=A0 =C2=A0 You say (twice):
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0the head will see the BFD session fail
=C2=A0 =C2=A0 Could you clarify which session fails,?

GIM>> It is the MultipointClient session. Would the new text make it = clearer:
OLD TEXT:
... the head will see the BFD session fail, but the state of the
=C2=A0=C2=A0 =C2=A0multipoint path will be unknown to the head.
NEW TEXT:
... the head will see that the particular MultipointClient
session fail ...
 ok




=C2=A0 =C2=A0 3.4.=C2=A0 Reliable Head Notification

=C2=A0 =C2=A0 same comment as for 3.3

GIM>> Would the text proposed above be acceptable?
 yes. please apply it



=C2=A0 =C2=A0 4.=C2=A0 Protocol Details

=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0This section is an update to section 4 of = [I-D.ietf-bfd-multipoint].
=C2=A0 =C2=A0 Should you rather say that it's only some parts of this s= ection
=C2=A0 =C2=A0 which update mpBFD, and say which ones.

GIM>> Here's the proposed new text:
OLD TEXT:
=C2=A0=C2=A0 =C2=A0This section is an update to section 4 of [I-D.ietf-bfd-= multipoint].
NEW TEXT:
=C2=A0=C2=A0 =C2=A0This section updates Section 4 of [I-D.ietf-bfd-multipoi= nt] as the following:
=C2=A0=C2=A0 =C2=A0- Section 4.3 introduces new state variables and modifie= s the usage of a few existing ones;
=C2=A0=C2=A0 =C2=A0- Section 4.13 replaces the corresponding sections in th= e base BFD for multipoint networks specification.
 ok





=C2=A0 =C2=A0 4.1.=C2=A0 Multipoint Client Session

=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0If the head is keeping track of some or al= l of the tails, it has a
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0session of type MultipointClient per tail = that it cares about.=C2=A0 All
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0of the MultipointClient sessions for tails= on a particular
=C2=A0 =C2=A0 multipoint
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0path are grouped with the MultipointHead s= ession to which the
=C2=A0 =C2=A0 clients
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0are listening.
=C2=A0 =C2=A0 What do you mean by "grouped", associated?

GIM>> Yes, "associated" is better term, I agree. Will updat= e.
 ok



=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0These sessions receive any BFD Control pac= kets sent by the
=C2=A0 =C2=A0 tails, and
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0never transmit periodic BFD Control packet= s other than Poll
=C2=A0 =C2=A0 Sequences
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(since periodic transmission is always don= e by the MultipointHead
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0session).
=C2=A0 =C2=A0 Should it be "MUST never send"?

GIM>> Would s/never/MUST NOT/ to make it into "MUST NOT transmit= " be acceptable?
 yes, thanks


=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0A BFD Poll Sequence may be sent over such = a session to a tail if the
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0head wishes to verify connectivity.
=C2=A0 =C2=A0 It is not clear here if you are talking about sending a multi= point
=C2=A0 =C2=A0 Poll sequence to all tails over the MultipointHead session or= a
=C2=A0 =C2=A0 unicast Poll sequence to a single tail over one MultipointCli= ent
=C2=A0 =C2=A0 session.

GIM>> s/such a session/a MultipointClient session/
 thanks




=C2=A0 =C2=A0 4.3.2.=C2=A0 New State Variable Value

=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 This variable MUST be initialized = to the appropriate type
=C2=A0 =C2=A0 when the
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 session is created, according to t= he rules in section 4.13 of
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 [I-D.ietf-bfd-multipoint].
=C2=A0 =C2=A0 There is nothing in 4.13 of mpBFD that talks about the
=C2=A0 =C2=A0 initialization of bfd.SessionType.

GIM>> This is the problem with keeping cross-references while updatin= g both documents. The correct reference now is to Section 4.4 of[I-D.ietf-b= fd-multipoint].

 ok



=C2=A0 =C2=A0 4.3.3.=C2=A0 State Variable Initialization and Maintenance
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Some state variables defined in section 6.= 8.1 of the [RFC5880] needs
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0to be initialized or manipulated different= ly depending on the
=C2=A0 =C2=A0 session
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0type (see section 4.4.2 of [I-D.ietf-bfd-m= ultipoint]).
=C2=A0 =C2=A0 s/of the/of/
=C2=A0 =C2=A0 s/needs/need/
=C2=A0 =C2=A0 s/ (see section 4.4.2 of [I-D.ietf-bfd-multipoint])./. The va= lues of
=C2=A0 =C2=A0 some of these variables relate to those of the same variables= of a
=C2=A0 =C2=A0 MultipointHead session (see section 4.4.2 of
=C2=A0 =C2=A0 [I-D.ietf-bfd-multipoint])./

GIM>> All accepted and applied to the working version.
 thanks
minor typo:
s/type/type./



=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 bfd.RequiredMinRxInterval
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It should be noted th= at for sessions of type MultipointTail,
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this variable only af= fects the rate of unicast Polls sent by
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the head; the rate of= multipoint packets is necessarily
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unaffected by it.
=C2=A0 =C2=A0 what is specific to MultipointClient here? If nothing, please= remove.
=C2=A0 =C2=A0 If something, please add it clearly.

GIM>> I propose the new text below.
OLD TEXT:
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It should be noted that for session= s of type MultipointTail,
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this variable only affects the rate= of unicast Polls sent by
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the head; the rate of multipoint pa= ckets is necessarily
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unaffected by it.
NEW TEXT:
It MAY be set to zero at the head BFD system to suppress traffic from the t= ails.
Setting it to zero in the MultipointHead session suppresses traffic from al= l tails,
setting in a MultipointClient session suppresses traffic form a single tail= .

 ok



=C2=A0 =C2=A0 4.4.=C2=A0 Controlling Multipoint BFD Options

=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0The most basic form of operation, as expla= ined in
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0[I-D.ietf-bfd-multipoint], in which BFD Co= ntrol packets flow only
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0from the head and no tracking is desired o= f tail state at the head,
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0is accomplished by setting bfd.ReportTailD= own to 0 in the
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0MultipointHead session (Section 3.1).
=C2=A0 =C2=A0 I am a bit concerned that mpBFD in fact works with a state va= riable
=C2=A0 =C2=A0 defined in another document. Wouldn't it be better to int= roduce this
=C2=A0 =C2=A0 variable in mpBFD and set it to always be zero and then allow= in
=C2=A0 =C2=A0 this doc to be set at 1. A bit like the M bit.

GIM>> Great idea, thank you! If we do that, would such update to mpBF= D document require re-start of WGLC?
 thinking twice about that, let's keep the way things are.



=C2=A0 =C2=A0 You have text relating to 3.1. What about 3.2/3/4?

GIM>> The fifth paragraph can be back referenced to section 3.4. The = fourth paragrah describes use of bfd.ReportTailDown common to unsolicited n= otifications, multicast and unicast polling, i.e. sections 3.2, 3.3, and 3.= 4.
 please do.


=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0If the head wishes to know the identity of= the tails, it sends
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0multipoint Polls as needed.=C2=A0 Previous= ly known tails that don't
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0respond to the Polls will be detected (as = per Section 3.3).
=C2=A0 =C2=A0 Again, I'd prefer not to talk about identity, but simply = about
=C2=A0 =C2=A0 messages received from tails or not.
=C2=A0 =C2=A0 I don't see the purpose of this paragraph here. What is t= he relation
=C2=A0 =C2=A0 with state variables?

GIM>> It may be better to move this paragraph down by one, swap parag= raphs. And would the following re-wording mak text clearer:
OLD TEXT:
=C2=A0=C2=A0 =C2=A0If the head wishes to know the identity of the tails, it= sends
=C2=A0=C2=A0 =C2=A0multipoint Polls as needed.=C2=A0 Previously known tails= that don't
=C2=A0=C2=A0 =C2=A0respond to the Polls will be detected (as per Section 3.= 3).
NEW TEXT:
=C2=A0=C2=A0 =C2=A0If the head wishes to know of the active tails, it sends=
=C2=A0=C2=A0 =C2=A0multipoint Polls as needed.=C2=A0 Previously known tails= that don't
=C2=A0=C2=A0 =C2=A0respond to the Polls will be detected (as per Section 3.= 3).
 ok, ok.


=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0If the head wishes to be notified by the t= ails when they lose
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0connectivity, it sets bfd.ReportTailDown t= o 1 in either the
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0MultipointHead session (if such notificati= on is desired from all
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0tails) or in the MultipointClient session = (if notification is
=C2=A0 =C2=A0 desired
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0from a particular tail).=C2=A0 Note that t= he setting of this variable
=C2=A0 =C2=A0 in a
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0MultipointClient session for a particular = tail overrides the setting
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0in the MultipointHead session.
=C2=A0 =C2=A0 Does that correspond to 3.2, 3.3, 3.4?

GIM>> Yes, it enables all three modes.
 Still not clear.
ReportTailDown =3D 0 : don't poll tails
ReportTailDown =3D 1 : poll tails
is that correct?
GIM2>> Yes.=C2=A0

If so:
s/If the head wishes to be notified by the/If the head wishes to request a = notification from the/
GIM2>> Accepted.=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">


=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0If the head wishes to verify the state of = a tail on an ongoing
=C2=A0 =C2=A0 basis,
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0it sends a Poll Sequence from the Multipoi= ntClient session
=C2=A0 =C2=A0 associated
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0with that tail as needed.
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0If the head wants to more quickly be alert= ed to a session failure
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0from a particular tail, it sends a BFD Con= trol packet from the
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0MultipointClient session associated with t= hat tail.=C2=A0 This has the
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0effect of eliminating the initial delay, d= escribed in Section
=C2=A0 =C2=A0 4.13.3,
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0that the tail would otherwise insert prior= to transmission of the
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0packet.
=C2=A0 =C2=A0 I don't see the link with state variables here neither. C= onsider
=C2=A0 =C2=A0 moving somewhere else.

GIM>> I read it as continuation of what described in the preceeding p= aragraph regarding setting bfd.ReportTailDown in MultipointClient.
 So please indicate it
GIM2>> I've merged two par= agraphs and re-worded to the following:
OLD TEXT:
=C2= =A0 =C2=A0 If the head wishes to verify the state of a tail on an ongoing b= asis,
=C2=A0 =C2=A0it sends a Poll Sequence from the MultipointCl= ient session associated
=C2=A0 =C2=A0with that tail as needed.

=C2=A0 =C2=A0If the head wants to be alerted to a se= ssion failure from a
=C2=A0 =C2=A0particular tail more quickly, i= t sends a BFD Control packet from the
=C2=A0 =C2=A0MultipointClie= nt session associated with that tail.=C2=A0 This has the
=C2=A0 = =C2=A0effect of eliminating the initial delay, described in Section 6.13.3,=
=C2=A0 =C2=A0that the tail would otherwise insert prior to trans= mission of the
=C2=A0 =C2=A0packet.
NEW TEXT:
=C2=A0 =C2=A0If the head wishes to verify the state of a tail on an o= ngoing basis,
=C2=A0 =C2=A0it sends a Poll Sequence from the Mult= ipointClient session associated
=C2=A0 =C2=A0with that= tail as needed.=C2=A0 This has the effect of eliminating the
=C2= =A0 =C2=A0initial delay, described in Section 6.13.3, that the tail would
=C2=A0 =C2=A0otherwise insert prior to transmission of the packet = thus the head
=C2=A0 =C2=A0may have notification of the session f= ailure more quickly when
=C2=A0 =C2=A0comparing with use of m-pol= l.




=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0If a tail wishes to operate silently (send= ing no BFD Control packets
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0to the head) it sets bfd.SilentTail to 1 i= n the MultipointTail
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0session.=C2=A0 This allows a tail to be si= lent independent of the
=C2=A0 =C2=A0 settings
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0on the head.
=C2=A0 =C2=A0 The implications of that option are not really discussed. The= head
=C2=A0 =C2=A0 will likely consider the session down, no?

GIM>> The head would not learn of such tail nor it will be able to no= tice the tail state change. I think that s/be silent/be invisible to the he= ad/ may make the text clearer.
 understood



=C2=A0 =C2=A0 4.5.=C2=A0 State Machine

=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0The state machine for session of type Mult= ipointClient is same as
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0defined in section 4.5 of [I-D.ietf-bfd-mu= ltipoint].
=C2=A0 =C2=A0 Is that really the case? MultipointHead only fails administra= tively
=C2=A0 =C2=A0 while MultipointClient can fails based on received message, n= o?

GIM>> True. It is noted in Section 4.5 in mpBFD that for MultipointHe= ad all state transitions are administratively driven. But the diagram is st= ill applicable for BFD MultipointClient session.
 So, is a small clarification needed? I would think so.
GIM= 2>> Added.=C2=A0




=C2=A0 =C2=A0 4.6.=C2=A0 Session Establishment

=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0The head directly controls whether or not = tails are allowed to send
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0BFD Control packets back to the head.
=C2=A0 =C2=A0 Not fully true, because of SilentTail, no?

GIM>> It can be done by setting bfd.RequiredMinRxInterval to zero in = MultipointHead session or a MultipointClient session. The former will force= all tails not to send any BFD packet to the head. The latter - only the pa= rticular BFD tail. As stressed in the specification, the value in Multipoin= tClient overrides the value in MultipointHead.
 So please remind that to the reader (pointing to mpBFD spec)
GIM2>> Added a sentence.=C2=A0




=C2=A0 =C2=A0 4.13.1/2/3

=C2=A0 =C2=A0 I think that, as said, you are not updating 5880. Also, you s= aid
=C2=A0 =C2=A0 that you update sections but really you are updating parts of= them.
=C2=A0 =C2=A0 I encourage you to find a clear way to indicate what you chan= ge/update.

GIM>> I'll remove from these sections references to sections 6.8.= 6 and 6.8.7 of RFC 5880 and link updates to mpBFD specification.
 please do



=C2=A0 =C2=A0 7. Security Considerations

=C2=A0 =C2=A0 Can't you elaborate a bit? This look a bit like the bare = minimum.

GIM>> You're right and more should be said about possible impact = MultipointClient sessions. Proposed new text below:
NEW TEXT:
=C2=A0=C2=A0 =C2=A0Additionally, implementations that create
=C2=A0=C2=A0 =C2=A0MultpointClient sessions dynamically upon receipt of BFD=
=C2=A0=C2=A0 =C2=A0Control packet from a tail MUST implement protective mea= sures to prevent an
=C2=A0=C2=A0 =C2=A0infinite number of MultipointClient sessions being creat= ed.=C2=A0 Below are
=C2=A0=C2=A0 =C2=A0listed some points to be considered in such implementati= ons.

=C2=A0=C2=A0 =C2=A0 =C2=A0 When the number of MultipointClient sessions exc= eeds the number of
expected=C2=A0tails, then the implementation should generate an alarm
to users to indicate the anomaly.

=C2=A0=C2=A0 =C2=A0 =C2=A0 The implementation should have a reasonable uppe= r bound on the
=C2=A0=C2=A0 =C2=A0 =C2=A0 number of MultipointClient sessions that can be = created, with the
=C2=A0=C2=A0 =C2=A0 =C2=A0 upper bound potentially being computed based on = the number of
=C2=A0=C2=A0 =C2=A0 =C2=A0 multicast streams that the system is expecting.<= br>
The text may be inserted as the second paragraph or replace the current sec= ond paragraph.

 ok

=C2=A0 =C2=A0 ---



--000000000000b6edb7056dd585eb-- --000000000000b6edba056dd585ed Content-Type: text/plain; charset="US-ASCII"; name="draft-ietf-bfd-multipoint-active-tail-08.txt" Content-Disposition: attachment; filename="draft-ietf-bfd-multipoint-active-tail-08.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ji0mc4g91 CgoKCkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgRC4gS2F0egpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEp1bmlwZXIgTmV0d29ya3MKVXBkYXRlczogWFhYWCAoUkZDIEJG RCBmb3IgTXVsdGktcG9pbnQgICAgICAgICAgICAgICAgICAgICAgICAgICBELiBXYXJkCiAgICAg ICAgIE5ldHdvcmtzKSAoaWYgYXBwcm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2lz Y28gU3lzdGVtcwpJbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAg ICAgICAgICBTLiBQYWxsYWdhdHRpLCBFZC4KRXhwaXJlczogRGVjZW1iZXIgNiwgMjAxOCAgICAg ICAgICAgICAgICAgICAgICAgICBJbmRpdmlkdWFsIENvbnRyaWJ1dG9yCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHLiBNaXJza3ksIEVk LgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBaVEUgQ29ycC4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgSnVuZSA0LCAyMDE4CgoKICAgICAgICAgICAgICAgICAgICAg IEJGRCBNdWx0aXBvaW50IEFjdGl2ZSBUYWlscy4KICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYt YmZkLW11bHRpcG9pbnQtYWN0aXZlLXRhaWwtMDgKCkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyBhY3RpdmUgdGFpbCBleHRlbnNpb25zIHRvIGFuZCB1cGRhdGVzIHRoZQogICBC aWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIHByb3RvY29sIGZvciBtdWx0 aXBvaW50CiAgIG5ldHdvcmtzLgoKU3RhdHVzIG9mIFRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5l dC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92 aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3Jr aW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAo SUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29y a2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJ bnRlcm5ldC0KICAgRHJhZnRzIGlzIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJh ZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFs aWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVw bGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJ dCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAg IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNz LiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gRGVjZW1iZXIgNiwgMjAx OC4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAxOCBJRVRGIFRydXN0IGFu ZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxs IHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzgg YW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRG IERvY3VtZW50cwogICAoaHR0cHM6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4g ZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQ bGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3Jp YmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBk b2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11 c3QKCgoKS2F0eiwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciA2LCAyMDE4ICAg ICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBCRkQgTXVsdGlw b2ludCBBY3RpdmUgVGFpbHMgICAgICAgICAgICAgSnVuZSAyMDE4CgoKICAgaW5jbHVkZSBTaW1w bGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCiAg IHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJy YW50eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgpUYWJs ZSBvZiBDb250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgIDIuICBUZXJtaW5vbG9neSBhbmQgQWNy b255bXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICAzLiAgS2V5 d29yZHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDMKICAgNC4gIE92ZXJ2aWV3ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgIDUuICBPcGVyYXRpb25hbCBTY2VuYXJpb3MgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICAgIDUuMS4gIE5vIEhlYWQg Tm90aWZpY2F0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAg ICA1LjIuICBIZWFkIE5vdGlmaWNhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA1CiAgICAgICA1LjIuMS4gIEhlYWQgTm90aWZpY2F0aW9uIFdpdGhvdXQgUG9s bGluZyAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQogICAgICAgNS4yLjIuICBIZWFkIE5vdGlmaWNh dGlvbiBhbmQgVGFpbCBTb2xpY2l0YXRpb24gd2l0aAogICAgICAgICAgICAgICBNdWx0aXBvaW50 IFBvbGxpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYKICAgICAgIDUu Mi4zLiAgSGVhZCBOb3RpZmljYXRpb24gd2l0aCBDb21wb3NpdGUgUG9sbGluZyAgLiAuIC4gLiAu IC4gICA2CiAgIDYuICBQcm90b2NvbCBEZXRhaWxzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgNwogICAgIDYuMS4gIE11bHRpcG9pbnQgQ2xpZW50IFNlc3Np b24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcKICAgICA2LjIuICBNdWx0aXBv aW50IENsaWVudCBTZXNzaW9uIEZhaWx1cmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4CiAg ICAgNi4zLiAgU3RhdGUgVmFyaWFibGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgOAogICAgICAgNi4zLjEuICBOZXcgU3RhdGUgVmFyaWFibGVzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgKICAgICAgIDYuMy4yLiAgTmV3IFN0YXRlIFZh cmlhYmxlIFZhbHVlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA5CiAgICAgICA2LjMu My4gIFN0YXRlIFZhcmlhYmxlIEluaXRpYWxpemF0aW9uIGFuZCBNYWludGVuYW5jZSAuIC4gLiAu ICAgOQogICAgIDYuNC4gIENvbnRyb2xsaW5nIE11bHRpcG9pbnQgQkZEIE9wdGlvbnMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMTAKICAgICA2LjUuICBTdGF0ZSBNYWNoaW5lIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExCiAgICAgNi42LiAgU2Vzc2lvbiBF c3RhYmxpc2htZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMQogICAg IDYuNy4gIERpc2NyaW1pbmF0b3JzIGFuZCBQYWNrZXQgRGVtdWx0aXBsZXhpbmcgIC4gLiAuIC4g LiAuIC4gLiAgMTEKICAgICA2LjguICBDb250cm9sbGluZyBUYWlsIFBhY2tldCBUcmFuc21pc3Np b24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyCiAgICAgNi45LiAgU29saWNpdGluZyB0aGUgVGFp bHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMgogICAgIDYuMTAuIFZl cmlmeWluZyBDb25uZWN0aXZpdHkgdG8gU3BlY2lmaWMgVGFpbHMgIC4gLiAuIC4gLiAuIC4gLiAg MTMKICAgICA2LjExLiBEZXRlY3Rpb24gVGltZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDE0CiAgICAgNi4xMi4gTXVsdGlwb2ludENsaWVudCBEb3duL0FkbWlu RG93biBTZXNzaW9ucyAgLiAuIC4gLiAuIC4gLiAuICAxNAogICAgIDYuMTMuIEJhc2UgQkZEIGZv ciBNdWx0aXBvaW50IE5ldHdvcmtzIFNwZWNpZmljYXRpb24gVGV4dAogICAgICAgICAgIFJlcGxh Y2VtZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTQK ICAgICAgIDYuMTMuMS4gIFJlY2VwdGlvbiBvZiBCRkQgQ29udHJvbCBQYWNrZXRzIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDE1CiAgICAgICA2LjEzLjIuICBEZW11bHRpcGxleGluZyBCRkQgQ29udHJv bCBQYWNrZXRzIC4gLiAuIC4gLiAuIC4gLiAuICAxNQogICAgICAgNi4xMy4zLiAgVHJhbnNtaXR0 aW5nIEJGRCBDb250cm9sIFBhY2tldHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTYKICAgNy4gIEFz c3VtcHRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDE2CiAgIDguICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAxNwogICA5LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTcKICAgMTAuIENvbnRyaWJ1dG9y cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE3CiAg IDExLiBBY2tub3dsZWRnbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAxOAogICAxMi4gTm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTgKICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE4CgoKCgoKCkthdHos IGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNiwgMjAxOCAgICAgICAgICAgICAg ICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgQkZEIE11bHRpcG9pbnQgQWN0aXZl IFRhaWxzICAgICAgICAgICAgIEp1bmUgMjAxOAoKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIFRoaXMg YXBwbGljYXRpb24gb2YgQkZEIGlzIGFuIGV4dGVuc2lvbiB0byBNdWx0aXBvaW50IEJGRAogICBb SS1ELmlldGYtYmZkLW11bHRpcG9pbnRdLCB3aGljaCBhbGxvd3MgdGFpbHMgdG8gbm90aWZ5IHRo ZSBoZWFkIG9mCiAgIHRoZSBsYWNrIG9mIG11bHRpcG9pbnQgY29ubmVjdGl2aXR5LiAgQXMgYSBm dXJ0aGVyIG9wdGlvbiwgaGVhZHMgY2FuCiAgIHJlcXVlc3QgYSBub3RpZmljYXRpb24gZnJvbSB0 aGUgdGFpbHMgYnkgbWVhbnMgb2YgYSBwb2xsaW5nCiAgIG1lY2hhbmlzbS4gIE5vdGlmaWNhdGlv biB0byB0aGUgaGVhZCBjYW4gYmUgZW5hYmxlZCBmb3IgYWxsIHRhaWxzLCBvcgogICBmb3Igb25s eSBhIHN1YnNldCBvZiB0aGUgdGFpbHMuCgogICBUaGUgZ29hbCBvZiB0aGlzIGFwcGxpY2F0aW9u IGlzIGZvciB0aGUgaGVhZCB0byByZWFzb25hYmx5IHJhcGlkbHkKICAgaGF2ZSBrbm93bGVkZ2Ug b2YgdGFpbHMgdGhhdCBoYXZlIGxvc3QgY29ubmVjdGl2aXR5IGZyb20gdGhlIGhlYWQuCgogICBT aW5jZSBzY2FsaW5nIGlzIGEgcHJpbWFyeSBjb25jZXJuIChwYXJ0aWN1bGFybHkgc3RhdGUgZXhw bG9zaW9uCiAgIHRvd2FyZCB0aGUgaGVhZCksIGl0IGlzIHJlcXVpcmVkIHRoYXQgdGhlIGhlYWQg YmUgaW4gY29udHJvbCBvZiBhbGwKICAgdGltaW5nIGFzcGVjdHMgb2YgdGhlIG1lY2hhbmlzbSwg YW5kIHRoYXQgQkZEIHBhY2tldHMgZnJvbSB0aGUgdGFpbHMKICAgdG8gdGhlIGhlYWQgbm90IGJl IHN5bmNocm9uaXplZC4KCiAgIFRocm91Z2hvdXQgdGhpcyBkb2N1bWVudCwgdGhlIHRlcm0gIm11 bHRpcG9pbnQiIGlzIGRlZmluZWQgYXMgYQogICBtZWNoYW5pc20gYnkgd2hpY2ggb25lIG9yIG1v cmUgc3lzdGVtcyByZWNlaXZlIHBhY2tldHMgc2VudCBieSBhCiAgIHNpbmdsZSBzZW5kZXIuICBU aGlzIHNwZWNpZmljYWxseSBpbmNsdWRlcyBzdWNoIHRoaW5ncyBhcyBJUAogICBtdWx0aWNhc3Qg YW5kIHBvaW50LXRvLW11bHRpcG9pbnQgTVBMUy4KCiAgIFRlcm0gImNvbm5lY3Rpdml0eSIgaW4g dGhpcyBkb2N1bWVudCBpcyBub3QgYmVpbmcgdXNlZCBpbiB0aGUgY29udGV4dAogICBvZiBjb25u ZWN0aXZpdHkgdmVyaWZpY2F0aW9uIGluIHRyYW5zcG9ydCBuZXR3b3JrIGJ1dCBhcyBhbgogICBh bHRlcm5hdGl2ZSB0byAiY29udGludWl0eSIsIGkuZS4gZXhpc3RlbmNlIG9mIGEgcGF0aCBiZXR3 ZWVuIHRoZQogICBzZW5kZXIgYW5kIHRoZSByZWNlaXZlci4KCiAgIFRoaXMgZG9jdW1lbnQgZWZm ZWN0aXZlbHkgbW9kaWZpZXMgYW5kIGFkZHMgdG8gU2VjdGlvbnMgNS4xMiBhbmQgNS4xMwogICBv ZiB0aGUgYmFzZSBCRkQgbXVsdGlwb2ludCBkb2N1bWVudCBbSS1ELmlldGYtYmZkLW11bHRpcG9p bnRdLgoKMi4gIFRlcm1pbm9sb2d5IGFuZCBBY3JvbnltcwoKICAgQkZEIEJpZGlyZWN0aW9uYWwg Rm9yd2FyZGluZyBEZXRlY3Rpb24KCiAgIGMtcG9sbCBDb21wb3NpdGUgUG9sbAoKICAgbS1wb2xs IE11bHRpcG9pbnQgUG9sbAoKMy4gIEtleXdvcmRzCgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwg Ik1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQi LCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJOT1QgUkVDT01NRU5ERUQiLCAiTUFZIiwg YW5kCiAgICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQg YXMgZGVzY3JpYmVkIGluIEJDUAogICAxNCBbUkZDMjExOV0gW1JGQzgxNzRdIHdoZW4sIGFuZCBv bmx5IHdoZW4sIHRoZXkgYXBwZWFyIGluIGFsbAogICBjYXBpdGFscywgYXMgc2hvd24gaGVyZS4K CgoKCgoKS2F0eiwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciA2LCAyMDE4ICAg ICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBCRkQgTXVsdGlw b2ludCBBY3RpdmUgVGFpbHMgICAgICAgICAgICAgSnVuZSAyMDE4CgoKNC4gIE92ZXJ2aWV3Cgog ICBBIGhlYWQgbWF5IHdpc2ggdG8gYmUgYWxlcnRlZCB0byB0aGUgdGFpbHMnIGNvbm5lY3Rpdml0 eSAob3IgbGFjawogICB0aGVyZW9mKSwgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIG9wdGlvbnMuICBG aXJzdCwgaWYgYWxsIHRoYXQgaXMKICAgbmVlZGVkIGlzIGEgYmVzdC1lZmZvcnQgZmFpbHVyZSBu b3RpZmljYXRpb24sIGFzIGRpc2N1c3NlZCBpbgogICBTZWN0aW9uIDUuMi4xLCB0aGUgdGFpbHMg Y2FuIHNlbmQgdW5zb2xpY2l0ZWQgdW5pY2FzdCBCRkQgQ29udHJvbAogICBwYWNrZXRzIHRvIHRo ZSBoZWFkIHdoZW4gdGhlIHBhdGggZmFpbHMsIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDYuNC4K CiAgIElmIHRoZSBoZWFkIHdpc2hlcyB0byBrbm93IG9mIHRoZSBhY3RpdmUgdGFpbHMgb24gdGhl IG11bHRpcG9pbnQKICAgcGF0aCwgaXQgbWF5IHNlbmQgYSBtdWx0aXBvaW50IEJGRCBDb250cm9s IHBhY2tldCB3aXRoIHRoZSBQb2xsIChQKQogICBiaXQgc2V0LCB3aGljaCB3aWxsIGluZHVjZSB0 aGUgdGFpbHMgdG8gcmV0dXJuIGEgdW5pY2FzdCBCRkQgQ29udHJvbAogICBwYWNrZXQgd2l0aCB0 aGUgRmluYWwgKEYpIGJpdCBzZXQgKGRldGFpbGVkIGRlc2NyaXB0aW9uIGluCiAgIFNlY3Rpb24g NS4yLjIpLiAgVGhlIGhlYWQgY2FuIHRoZW4gY3JlYXRlIEJGRCBzZXNzaW9uIHN0YXRlIGZvciBl YWNoCiAgIG9mIHRoZSB0YWlscyB0aGF0IGhhdmUgbXVsdGlwb2ludCBjb25uZWN0aXZpdHkuICBJ ZiB0aGUgaGVhZCBzZW5kcwogICBzdWNoIGEgcGFja2V0IG9uIG9jY2FzaW9uLCBpdCBjYW4ga2Vl cCB0cmFjayBvZiB3aGljaCB0YWlscyBhbnN3ZXIsCiAgIHRodXMgcHJvdmlkaW5nIGEgbW9yZSBk ZXRlcm1pbmlzdGljIG1lY2hhbmlzbSBmb3IgZGV0ZWN0aW5nIHdoaWNoCiAgIHRhaWxzIGZhaWwg dG8gcmVzcG9uZCAoaW1wbHlpbmcgYSBsb3NzIG9mIG11bHRpcG9pbnQgY29ubmVjdGl2aXR5KS4K ICAgSW4gdGhpcyBkb2N1bWVudCB0aGlzIG1ldGhvZCByZWZlcmVuY2VkIHRvIGFzIE11bHRpcG9p bnQgUG9sbAogICAobS1wb2xsKS4KCiAgIElmIHRoZSBoZWFkIHdpc2hlcyB0aGUgZGVmaW5pdGUg aW5kaWNhdGlvbiBvZiB0aGUgdGFpbHMnCiAgIGNvbm5lY3Rpdml0eSwgaXQgbWF5IGRvIGFsbCBv ZiB0aGUgYWJvdmUsIGJ1dCBpZiBpdCBkZXRlY3RzIHRoYXQgYQogICB0YWlsIGRpZCBub3QgYW5z d2VyIHRoZSBwcmV2aW91cyBtdWx0aXBvaW50IHBvbGwsIGl0IG1heSBpbml0aWF0ZSBhCiAgIERl bWFuZCBtb2RlIFBvbGwgU2VxdWVuY2UgYXMgYSB1bmljYXN0IHRvIHRoYXQgdGFpbCAoZGV0YWls ZWQKICAgZGVzY3JpcHRpb24gaW4gU2VjdGlvbiA1LjIuMykuICBUaGlzIGNvdmVycyB0aGUgY2Fz ZSB3aGVyZSBlaXRoZXIgdGhlCiAgIG11bHRpcG9pbnQgcG9sbCBvciB0aGUgc2luZ2xlIHJlcGx5 IGFsc28gaXMgbG9zdCBpbiB0cmFuc2l0LiAgSWYKICAgZGVzaXJlZCwgdGhlIGhlYWQgbWF5IFBv bGwgb25lIG9yIG1vcmUgdGFpbHMgcHJvYWN0aXZlbHkgdG8gdHJhY2sgdGhlCiAgIHRhaWxzJyBj b25uZWN0aXZpdHkuICBJbiB0aGlzIGRvY3VtZW50IHRoaXMgbWV0aG9kIHRoYXQgY29tYmluZXMg dXNlCiAgIG9mIG11bHRpcG9pbnQgYW5kIHVuaWNhc3QgcG9sbGluZyBvZiB0YWlscyBieSB0aGUg aGVhZCByZWZlcmVuY2VkIHRvCiAgIGFzIENvbXBvc2l0ZSBQb2xsIChjLXBvbGwpLgoKICAgSWYg dGhlIGF3YXJlbmVzcyBvZiB0aGUgc3RhdGUgb2Ygc29tZSBub2RlcyBpcyBtb3JlIGltcG9ydGFu dCBmb3IgdGhlCiAgIGhlYWQsIGluIHRoZSBzZW5zZSB0aGF0IHRoZSBoZWFkIG5lZWRzIHRvIGRl dGVjdCB0aGUgbGFjayBvZgogICBtdWx0aXBvaW50IGNvbm5lY3Rpdml0eSB0byBhIHN1YnNldCBv ZiB0YWlscyBhdCBhIGRpZmZlcmVudCByYXRlLCB0aGUKICAgaGVhZCBtYXkgdHJhbnNtaXQgdW5p Y2FzdCBCRkQgUG9sbHMgdG8gdGhhdCBzdWJzZXQgb2YgdGFpbHMuICBJbiB0aGlzCiAgIGNhc2Us IHRoZSB0aW1pbmcgbWF5IGJlIGluZGVwZW5kZW50IG9uIGEgdGFpbC1ieS10YWlsIGJhc2lzLgoK ICAgSW5kaXZpZHVhbCB0YWlscyBtYXkgYmUgY29uZmlndXJlZCBzbyB0aGF0IHRoZXkgbmV2ZXIg c2VuZCBCRkQKICAgY29udHJvbCBwYWNrZXRzIHRvIHRoZSBoZWFkLiAgU3VjaCB0YWlscyB3aWxs IG5ldmVyIGJlIGtub3duIHRvIHRoZQogICBoZWFkLCBidXQgd2lsbCBzdGlsbCBiZSBhYmxlIHRv IGRldGVjdCBtdWx0aXBvaW50IHBhdGggZmFpbHVyZXMgZnJvbQogICB0aGUgaGVhZC4KCjUuICBP cGVyYXRpb25hbCBTY2VuYXJpb3MKCiAgIEl0IGlzIHdvcnRoIGFuYWx5emluZyBob3cgdGhpcyBw cm90b2NvbCByZWFjdHMgdG8gdmFyaW91cyBzY2VuYXJpb3MuCiAgIFRoZXJlIGFyZSB0aHJlZSBw YXRoIGNvbXBvbmVudHMgcHJlc2VudCwgbmFtZWx5LCB0aGUgbXVsdGlwb2ludCBwYXRoLAogICB0 aGUgZm9yd2FyZCB1bmljYXN0IHBhdGggKGZyb20gaGVhZCB0byBhIHBhcnRpY3VsYXIgdGFpbCks IGFuZCB0aGUKICAgcmV2ZXJzZSB1bmljYXN0IHBhdGggKGZyb20gYSB0YWlsIHRvIHRoZSBoZWFk KS4gIFRoZXJlIGFyZSBhbHNvIGZvdXIKCgoKS2F0eiwgZXQgYWwuICAgICAgICAgICAgRXhwaXJl cyBEZWNlbWJlciA2LCAyMDE4ICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICBCRkQgTXVsdGlwb2ludCBBY3RpdmUgVGFpbHMgICAgICAgICAgICAgSnVuZSAy MDE4CgoKICAgb3B0aW9ucyBhcyB0byBob3cgdGhlIGhlYWQgaXMgbm90aWZpZWQgYWJvdXQgZmFp bHVyZXMgZnJvbSB0aGUgdGFpbC4KICAgRm9yIHRoZSBkaWZmZXJlbnQgbW9kZXMgZGVzY3JpYmVk IGJlbG93IHRoZSBzZXR0aW5nIG9mIG5ldyBzdGF0ZQogICB2YXJpYWJsZXMgYXJlIGdpdmVuIGV2 ZW4gaWYgdGhlc2UgYXJlIG9ubHkgaW50cm9kdWNlZCBsYXRlciBpbiB0aGUKICAgZG9jdW1lbnQg KHNlZSBTZWN0aW9uIDYuMykuCgo1LjEuICBObyBIZWFkIE5vdGlmaWNhdGlvbgoKICAgSW4gdGhp cyBzY2VuYXJpbywgb25seSB0aGUgbXVsdGlwb2ludCBwYXRoIGlzIHVzZWQgYW5kIG5vbmUgb2Yg dGhlCiAgIG90aGVycyBtYXR0ZXIuICBBIGZhaWx1cmUgaW4gdGhlIG11bHRpcG9pbnQgcGF0aCB3 aWxsIHJlc3VsdCBpbiB0aGUKICAgdGFpbCBub3RpY2luZyB0aGUgZmFpbHVyZSB3aXRoaW4gYSBk ZXRlY3Rpb24gdGltZSwgYW5kIHRoZSBoZWFkIHdpbGwKICAgcmVtYWluIGlnbm9yYW50IG9mIHRo ZSB0YWlsIHN0YXRlLiAgVGhpcyBtb2RlIGVtdWxhdGVzIHRoZSBiZWhhdmlvcgogICBkZXNjcmli ZWQgaW4gW0ktRC5pZXRmLWJmZC1tdWx0aXBvaW50XS4gIEluIHRoaXMgbW9kZSBmb3IKICAgYmZk LlNlc3Npb25UeXBlIGlzIE11bHRpcG9pbnRUYWlsLCB2YXJpYWJsZSBiZmQuU2lsZW50VGFpbCAo c2VlCiAgIFNlY3Rpb24gNi4zLjEpIE1VU1QgYmUgc2V0IHRvIDEuICBJZiBiZmQuU2Vzc2lvblR5 cGUgaXMKICAgTXVsdGlwb2ludEhlYWQgb3IgTXVsdGlwb2ludENsaWVudCBiZmQuUmVwb3J0VGFp bERvd24gTVVTVCBiZSBzZXQgdG8KICAgMC5UaGUgaGVhZCBNQVkgc2V0IGJmZC5SZXF1aXJlZE1p blJ4SW50ZXJ2YWwgdG8gemVybyBhbmQgdGh1cyBzdXByZXNzCiAgIHRhaWxzIHNlbmRpbmcgYW55 IEJGRCBjb250cm9sIHBhY2tldHMuCgo1LjIuICBIZWFkIE5vdGlmaWNhdGlvbgoKICAgSW4gdGhl c2Ugc2NlbmFyaW9zIHRoZSB0YWlsIHNlbmRzIHVuc29saWNpdGVkIG9yIHNvbGljaXRlZCBCRkQK ICAgcGFja2V0cyBpbiByZXNwb25zZSB0byB0aGUgZGV0ZWN0aW9uIG9mIGEgbXVsdGlwb2ludCBw YXRoIGZhaWx1cmUuCiAgIEFsbCB0aGVzZSBzY2VuYXJpb3MgaGF2ZSBjb21tb24gc2V0dGluZ3M6 CgogICBvICBpZiBiZmQuU2Vzc2lvblR5cGUgaXMgTXVsdGlwb2ludFRhaWwsIHZhcmlhYmxlIGJm ZC5TaWxlbnRUYWlsIChzZWUKICAgICAgU2VjdGlvbiA2LjMuMSkgTVVTVCBiZSBzZXQgdG8gMDsK CiAgIG8gIGlmIGJmZC5TZXNzaW9uVHlwZSBpcyBNdWx0aXBvaW50SGVhZCBvciBNdWx0aXBvaW50 Q2xpZW50CiAgICAgIGJmZC5SZXBvcnRUYWlsRG93biBNVVNUIGJlIHNldCB0byAxOwoKICAgbyAg dGhlIGhlYWQgTVVTVCBzZXQgYmZkLlJlcXVpcmVkTWluUnhJbnRlcnZhbCB0byBub24temVybyBh bmQgdGh1cwogICAgICBhbGxvdyB0YWlscyBzZW5kaW5nIEJGRCBjb250cm9sIHBhY2tldHMuCgo1 LjIuMS4gIEhlYWQgTm90aWZpY2F0aW9uIFdpdGhvdXQgUG9sbGluZwoKICAgSW4gdGhpcyBzY2Vu YXJpbywgdGhlIHRhaWwgc2VuZHMgdW5zb2xpY2l0ZWQgQkZEIHBhY2tldHMgaW4gcmVzcG9uc2UK ICAgdG8gdGhlIGRldGVjdGlvbiBvZiBhIG11bHRpcG9pbnQgcGF0aCBmYWlsdXJlLiAgSXQgdXNl cyB0aGUgcmV2ZXJzZQogICB1bmljYXN0IHBhdGgsIGJ1dCBub3QgdGhlIGZvcndhcmQgdW5pY2Fz dCBwYXRoLgoKICAgSWYgdGhlIG11bHRpcG9pbnQgcGF0aCBmYWlscyBidXQgdGhlIHJldmVyc2Ug dW5pY2FzdCBwYXRoIHN0YXlzIHVwLAogICB0aGUgdGFpbCB3aWxsIGRldGVjdCB0aGUgZmFpbHVy ZSB3aXRoaW4gYSBkZXRlY3Rpb24gdGltZSwgYW5kIHRoZQogICBoZWFkIHdpbGwga25vdyBhYm91 dCBpdCB3aXRoaW4gb25lIHJldmVyc2UgcGFja2V0IHRpbWUgKHNpbmNlIHRoZQogICBub3RpZmlj YXRpb24gaXMgZGVsYXllZCkuCgogICBJZiBib3RoIHRoZSBtdWx0aXBvaW50IHBhdGggYW5kIHRo ZSByZXZlcnNlIHVuaWNhc3QgcGF0aHMgZmFpbCwgdGhlCiAgIHRhaWwgd2lsbCBkZXRlY3QgdGhl IGZhaWx1cmUgYnV0IHRoZSBoZWFkIHdpbGwgcmVtYWluIHVuYXdhcmUgb2YgaXQuCgoKCgoKS2F0 eiwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciA2LCAyMDE4ICAgICAgICAgICAg ICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBCRkQgTXVsdGlwb2ludCBBY3Rp dmUgVGFpbHMgICAgICAgICAgICAgSnVuZSAyMDE4CgoKNS4yLjIuICBIZWFkIE5vdGlmaWNhdGlv biBhbmQgVGFpbCBTb2xpY2l0YXRpb24gd2l0aCBNdWx0aXBvaW50IFBvbGxpbmcKCiAgIEluIHRo aXMgc2NlbmFyaW8sIHRoZSBoZWFkIHNlbmRzIG9jY2FzaW9uYWwgbXVsdGlwb2ludCBQb2xscyBp bgogICBhZGRpdGlvbiB0byAob3IgaW4gbGlldSBvZikgbm9uLVBvbGwgbXVsdGlwb2ludCBCRkQg Q29udHJvbCBwYWNrZXRzLAogICBleHBlY3RpbmcgdGhlIHRhaWxzIHRvIHJlcGx5IHdpdGggRmlu YWwuICBUaGlzIGFsc28gdXNlcyB0aGUgcmV2ZXJzZQogICB1bmljYXN0IHBhdGgsIGJ1dCBub3Qg dGhlIGZvcndhcmQgdW5pY2FzdCBwYXRoLgoKICAgSWYgdGhlIG11bHRpcG9pbnQgcGF0aCBmYWls cyBidXQgdGhlIHJldmVyc2UgdW5pY2FzdCBwYXRoIHN0YXlzIHVwLAogICB0aGUgdGFpbCB3aWxs IGRldGVjdCB0aGUgZmFpbHVyZSB3aXRoaW4gYSBkZXRlY3Rpb24gdGltZSwgYW5kIHRoZQogICBo ZWFkIHdpbGwga25vdyBhYm91dCBpdCB3aXRoaW4gb25lIHJldmVyc2UgcGFja2V0IHRpbWUgKHRo ZQogICBub3RpZmljYXRpb24gaXMgZGVsYXllZCB0byBhdm9pZCBzeW5jaHJvbml6YXRpb24gb2Yg dGhlIHRhaWxzKS4KCiAgIElmIGJvdGggdGhlIG11bHRpcG9pbnQgcGF0aCBhbmQgdGhlIHJldmVy c2UgdW5pY2FzdCBwYXRocyBmYWlsLCB0aGUKICAgdGFpbCB3aWxsIGRldGVjdCB0aGUgZmFpbHVy ZSBidXQgdGhlIGhlYWQgd2lsbCByZW1haW4gdW5hd2FyZSBvZiB0aGlzCiAgIGZhY3QuCgogICBJ ZiB0aGUgcmV2ZXJzZSB1bmljYXN0IHBhdGggZmFpbHMgYnV0IHRoZSBtdWx0aXBvaW50IHBhdGgg c3RheXMgdXAsCiAgIHRoZSBoZWFkIHdpbGwgc2VlIHRoZSBCRkQgc2Vzc2lvbiBmYWlsLCBidXQg dGhlIHN0YXRlIG9mIHRoZQogICBtdWx0aXBvaW50IHBhdGggd2lsbCBiZSB1bmtub3duIHRvIHRo ZSBoZWFkLiAgVGhlIHRhaWwgd2lsbCBjb250aW51ZQogICB0byByZWNlaXZlIG11bHRpcG9pbnQg ZGF0YSB0cmFmZmljLgoKICAgSWYgZWl0aGVyIHRoZSBtdWx0aXBvaW50IFBvbGwgb3IgdGhlIHVu aWNhc3QgcmVwbHkgaXMgbG9zdCBpbgogICB0cmFuc2l0LCB0aGUgaGVhZCB3aWxsIHNlZSB0aGUg QkZEIHNlc3Npb24gZmFpbCwgYnV0IHRoZSBzdGF0ZSBvZiB0aGUKICAgbXVsdGlwb2ludCBwYXRo IHdpbGwgYmUgdW5rbm93biB0byB0aGUgaGVhZC4gIFRoZSB0YWlsIHdpbGwgY29udGludWUKICAg dG8gcmVjZWl2ZSBtdWx0aXBvaW50IGRhdGEgdHJhZmZpYy4KCjUuMi4zLiAgSGVhZCBOb3RpZmlj YXRpb24gd2l0aCBDb21wb3NpdGUgUG9sbGluZwoKICAgSW4gdGhpcyBzY2VuYXJpbywgdGhlIGhl YWQgc2VuZHMgb2NjYXNpb25hbCBtdWx0aXBvaW50IFBvbGxzIGluCiAgIGFkZGl0aW9uIHRvIChv ciBpbiBsaWV1IG9mKSBub24tUG9sbCBtdWx0aXBvaW50IEJGRCBjb250cm9sIHBhY2tldHMsCiAg IGV4cGVjdGluZyB0aGUgdGFpbHMgdG8gcmVwbHkgd2l0aCBGaW5hbC4gIElmIGEgdGFpbCB0aGF0 IGhhZAogICBwcmV2aW91c2x5IHJlcGxpZWQgdG8gYSBtdWx0aXBvaW50IFBvbGwgZmFpbHMgdG8g cmVwbHkgKG9yIGlmIHRoZQogICBoZWFkIHNpbXBseSB3aXNoZXMgdG8gdmVyaWZ5IHRhaWwgY29u bmVjdGl2aXR5KSwgdGhlIGhlYWQgaXNzdWVzIGEKICAgdW5pY2FzdCBQb2xsIFNlcXVlbmNlIHRv IHRoZSB0YWlsLiAgVGhpcyBzY2VuYXJpbyBtYWtlcyB1c2Ugb2YgYWxsCiAgIHRocmVlIHBhdGhz LiAgSW4gdGhpcyBtb2RlIGZvciBiZmQuU2Vzc2lvblR5cGUgb2YgTXVsdGlwb2ludFRhaWwsCiAg IHZhcmlhYmxlIGJmZC5TaWxlbnRUYWlsIChzZWUgU2VjdGlvbiA2LjMuMSkgTVVTVCBiZSBzZXQg dG8gMC4KCiAgIElmIHRoZSBtdWx0aXBvaW50IHBhdGggZmFpbHMgYnV0IHRoZSB0d28gdW5pY2Fz dCBwYXRocyBzdGF5IHVwLCB0aGUKICAgdGFpbCB3aWxsIGRldGVjdCB0aGUgZmFpbHVyZSB3aXRo aW4gYSBkZXRlY3Rpb24gdGltZSwgYW5kIHRoZSBoZWFkCiAgIHdpbGwga25vdyBhYm91dCBpdCB3 aXRoaW4gb25lIHJldmVyc2UgcGFja2V0IHRpbWUgKHNpbmNlIHRoZQogICBub3RpZmljYXRpb24g aXMgZGVsYXllZCkuICBOb3RlIHRoYXQgdGhlIHJldmVyc2UgcGFja2V0IHRpbWUgbWF5IGJlCiAg IHNtYWxsZXIgaW4gdGhpcyBjYXNlIGlmIHRoZSBoZWFkIGhhcyBwcmV2aW91c2x5IGlzc3VlZCBh IHVuaWNhc3QgUG9sbAogICAoc2luY2UgdGhlIHRhaWwgd2lsbCBub3QgZGVsYXkgdHJhbnNtaXNz aW9uIG9mIHRoZSBub3RpZmljYXRpb24gaW4KICAgdGhpcyBjYXNlKS4KCiAgIElmIGJvdGggdGhl IG11bHRpcG9pbnQgcGF0aCBhbmQgdGhlIHJldmVyc2UgdW5pY2FzdCBwYXRocyBmYWlsCiAgIChy ZWdhcmRsZXNzIG9mIHRoZSBzdGF0ZSBvZiB0aGUgZm9yd2FyZCB1bmljYXN0IHBhdGgpLCB0aGUg dGFpbCB3aWxsCiAgIGRldGVjdCB0aGUgZmFpbHVyZSBidXQgdGhlIGhlYWQgd2lsbCByZW1haW4g dW5hd2FyZSBvZiB0aGlzIGZhY3QuCgoKCkthdHosIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMg RGVjZW1iZXIgNiwgMjAxOCAgICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgQkZEIE11bHRpcG9pbnQgQWN0aXZlIFRhaWxzICAgICAgICAgICAgIEp1bmUgMjAx OAoKCiAgIFRoZSBoZWFkIHdpbGwgZGV0ZWN0IGEgQkZEIHNlc3Npb24gZmFpbHVyZSB0byB0aGUg dGFpbCBidXQgY2Fubm90CiAgIG1ha2UgYSBkZXRlcm1pbmF0aW9uIGFib3V0IHRoZSBzdGF0ZSBv ZiB0aGUgdGFpbCdzIG11bHRpcG9pbnQKICAgY29ubmVjdGl2aXR5LgoKICAgSWYgdGhlIGZvcndh cmQgdW5pY2FzdCBwYXRoIGZhaWxzIGJ1dCB0aGUgcmV2ZXJzZSB1bmljYXN0IHBhdGggc3RheXMK ICAgdXAsIHRoZSBoZWFkIHdpbGwgZGV0ZWN0IGEgQkZEIHNlc3Npb24gZmFpbHVyZSB0byB0aGUg dGFpbCBpZiBpdAogICBoYXBwZW5zIHRvIHNlbmQgYSB1bmljYXN0IFBvbGwgc2VxdWVuY2UsIGJ1 dCBjYW5ub3QgbWFrZSBhCiAgIGRldGVybWluYXRpb24gYWJvdXQgdGhlIHN0YXRlIG9mIHRoZSB0 YWlsJ3MgbXVsdGlwb2ludCBjb25uZWN0aXZpdHkuCiAgIElmIHRoZSBtdWx0aXBvaW50IHBhdGgg dG8gdGhlIHRhaWwgZmFpbHMgcHJpb3IgdG8gYW55IHVuaWNhc3QgUG9sbAogICBiZWluZyBzZW50 LCB0aGUgdGFpbCB3aWxsIGRldGVjdCB0aGUgZmFpbHVyZSB3aXRoaW4gYSBkZXRlY3Rpb24gdGlt ZSwKICAgYW5kIHRoZSBoZWFkIHdpbGwga25vdyBhYm91dCBpdCB3aXRoaW4gb25lIHJldmVyc2Ug cGFja2V0IHRpbWUgKHNpbmNlCiAgIHRoZSBub3RpZmljYXRpb24gaXMgZGVsYXllZCkuCgogICBJ ZiB0aGUgbXVsdGlwb2ludCBwYXRoIHN0YXlzIHVwIGJ1dCB0aGUgcmV2ZXJzZSB1bmljYXN0IHBh dGggZmFpbHMsCiAgIHRoZSBoZWFkIHdpbGwgc2VlIHRoZSBwYXJ0aWN1bGFyIE11bHRpcG9pbnRD bGllbnQgc2Vzc2lvbiBmYWlsIGlmIGl0CiAgIGhhcHBlbnMgdG8gc2VuZCBhIFBvbGwgU2VxdWVu Y2UsIGJ1dCB0aGUgc3RhdGUgb2YgdGhlIG11bHRpcG9pbnQgcGF0aAogICB3aWxsIGJlIHVua25v d24gdG8gdGhlIGhlYWQuICBUaGUgdGFpbCB3aWxsIGNvbnRpbnVlIHRvIHJlY2VpdmUKICAgbXVs dGlwb2ludCBkYXRhIHRyYWZmaWMuCgogICBJZiB0aGUgbXVsdGlwb2ludCBwYXRoIGFuZCB0aGUg cmV2ZXJzZSB1bmljYXN0IHBhdGggYm90aCBzdGF5IHVwIGJ1dAogICB0aGUgZm9yd2FyZCB1bmlj YXN0IHBhdGggZmFpbHMsIG5laXRoZXIgc2lkZSB3aWxsIG5vdGljZSBzbyBsb25nIGFzIGEKICAg dW5pY2FzdCBQb2xsIFNlcXVlbmNlIGlzIG5ldmVyIHNlbnQgYnkgdGhlIGhlYWQuICBJZiB0aGUg aGVhZCBzZW5kcyBhCiAgIHVuaWNhc3QgUG9sbCBTZXF1ZW5jZSwgdGhlIGhlYWQgd2lsbCBzZWUg dGhlIEJGRCBzZXNzaW9uIGZhaWwsIGJ1dAogICB0aGUgc3RhdGUgb2YgdGhlIG11bHRpcG9pbnQg cGF0aCB3aWxsIGJlIHVua25vd24gdG8gdGhlIGhlYWQuICBUaGUKICAgdGFpbCB3aWxsIGNvbnRp bnVlIHRvIHJlY2VpdmUgbXVsdGlwb2ludCBkYXRhIHRyYWZmaWMuCgo2LiAgUHJvdG9jb2wgRGV0 YWlscwoKICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgb3BlcmF0aW9uIG9mIEJGRCBNdWx0 aXBvaW50IGFjdGl2ZSB0YWlsIGluCiAgIGRldGFpbC4gIFRoaXMgc2VjdGlvbiB1cGRhdGVzIHRo ZSBzZWN0aW9uIDQgb2YKICAgW0ktRC5pZXRmLWJmZC1tdWx0aXBvaW50XSBhcyB0aGUgZm9sbG93 aW5nOgoKICAgbyAgU2VjdGlvbiA2LjMgaW50cm9kdWNlcyBuZXcgc3RhdGUgdmFyaWFibGVzIGFu ZCBtb2RpZmllcyB0aGUgdXNhZ2UKICAgICAgb2YgYSBmZXcgZXhpc3Rpbmcgb25lczsKCiAgIG8g IFNlY3Rpb24gNi4xMyByZXBsYWNlcyB0aGUgY29ycmVzcG9uZGluZyBzZWN0aW9ucyBpbiB0aGUg YmFzZSBCRkQKICAgICAgZm9yIG11bHRpcG9pbnQgbmV0d29ya3Mgc3BlY2lmaWNhdGlvbi4KCjYu MS4gIE11bHRpcG9pbnQgQ2xpZW50IFNlc3Npb24KCiAgIElmIHRoZSBoZWFkIGlzIGtlZXBpbmcg dHJhY2sgb2Ygc29tZSBvciBhbGwgb2YgdGhlIHRhaWxzLCBpdCBoYXMgYQogICBzZXNzaW9uIG9m IHR5cGUgTXVsdGlwb2ludENsaWVudCBwZXIgdGFpbCB0aGF0IGl0IGNhcmVzIGFib3V0LiAgQWxs CiAgIG9mIHRoZSBNdWx0aXBvaW50Q2xpZW50IHNlc3Npb25zIGZvciB0YWlscyBvbiBhIHBhcnRp Y3VsYXIgbXVsdGlwb2ludAogICBwYXRoIGFyZSBhc3NvY2lhdGVkIHdpdGggdGhlIE11bHRpcG9p bnRIZWFkIHNlc3Npb24gdG8gd2hpY2ggdGhlCiAgIGNsaWVudHMgYXJlIGxpc3RlbmluZy4gIEEg QkZEIFBvbGwgU2VxdWVuY2UgbWF5IGJlIHNlbnQgb3ZlciBhCiAgIE11bHRpcG9pbnRDbGllbnQg c2Vzc2lvbiB0byBhIHRhaWwgaWYgdGhlIGhlYWQgd2lzaGVzIHRvIHZlcmlmeQogICBjb25uZWN0 aXZpdHkuICBUaGVzZSBzZXNzaW9ucyByZWNlaXZlIGFueSBCRkQgQ29udHJvbCBwYWNrZXRzIHNl bnQgYnkKICAgdGhlIHRhaWxzLCBhbmQgTVVTVCBOT1QgdHJhbnNtaXQgcGVyaW9kaWMgQkZEIENv bnRyb2wgcGFja2V0cyBvdGhlcgoKCgpLYXR6LCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIERl Y2VtYmVyIDYsIDIwMTggICAgICAgICAgICAgICAgW1BhZ2UgN10KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgIEJGRCBNdWx0aXBvaW50IEFjdGl2ZSBUYWlscyAgICAgICAgICAgICBKdW5lIDIwMTgK CgogICB0aGFuIFBvbGwgU2VxdWVuY2VzIChzaW5jZSBwZXJpb2RpYyB0cmFuc21pc3Npb24gaXMg YWx3YXlzIGRvbmUgYnkKICAgdGhlIE11bHRpcG9pbnRIZWFkIHNlc3Npb24pLgoKNi4yLiAgTXVs dGlwb2ludCBDbGllbnQgU2Vzc2lvbiBGYWlsdXJlCgogICBJZiBhIE11bHRpcG9pbnRDbGllbnQg c2Vzc2lvbiByZWNlaXZlcyBhIEJGRCBDb250cm9sIHBhY2tldCBmcm9tIHRoZQogICB0YWlsIHdp dGggc3RhdGUgRG93biBvciBBZG1pbkRvd24sIHRoZSBoZWFkIHJlbGlhYmx5IGtub3dzIHRoYXQg dGhlCiAgIHRhaWwgaGFzIGxvc3QgbXVsdGlwb2ludCBjb25uZWN0aXZpdHkuICBJZiB0aGUgRGV0 ZWN0aW9uIFRpbWUgZXhwaXJlcwogICBvbiBhIE11bHRpcG9pbnRDbGllbnQgc2Vzc2lvbiwgaXQg aXMgYW1iaWd1b3VzIGFzIHRvIHdoZXRoZXIgdGhlCiAgIG11bHRpcG9pbnQgY29ubmVjdGl2aXR5 IGZhaWxlZCBvciB3aGV0aGVyIHRoZXJlIHdhcyBhIHVuaWNhc3QgcGF0aAogICBwcm9ibGVtIGlu IG9uZSBkaXJlY3Rpb24gb3IgdGhlIG90aGVyLCBzbyB0aGUgaGVhZCBkb2VzIG5vdCByZWxpYWJs eQogICBrbm93IHRoZSB0YWlsJ3Mgc3RhdGUuCgo2LjMuICBTdGF0ZSBWYXJpYWJsZXMKCiAgIEJG RCBNdWx0aXBvaW50IGFjdGl2ZSB0YWlsIGludHJvZHVjZXMgbmV3IHN0YXRlIHZhcmlhYmxlcyBh bmQKICAgbW9kaWZpZXMgdGhlIHVzYWdlIG9mIGEgZmV3IGV4aXN0aW5nIG9uZXMgZGVmaW5lZCBp biBzZWN0aW9uIDQuNCBvZgogICBbSS1ELmlldGYtYmZkLW11bHRpcG9pbnRdLgoKNi4zLjEuICBO ZXcgU3RhdGUgVmFyaWFibGVzCgogICBGZXcgc3RhdGUgdmFyaWFibGVzIGFyZSBhZGRlZCBpbiBz dXBwb3J0IG9mIE11bHRpcG9pbnQgQkZEIGFjdGl2ZQogICB0YWlsLgoKICAgICAgYmZkLlNpbGVu dFRhaWwKCiAgICAgICAgIElmIDAsIGEgdGFpbCBtYXkgc2VuZCBwYWNrZXRzIHRvIHRoZSBoZWFk IGFjY29yZGluZyB0byBvdGhlcgogICAgICAgICBwYXJ0cyBvZiB0aGlzIHNwZWNpZmljYXRpb24u ICBTZXR0aW5nIHRoaXMgdG8gMSBhbGxvd3MgdGFpbHMgdG8KICAgICAgICAgYmUgcHJvdmlzaW9u ZWQgdG8gYWx3YXlzIGJlIHNpbGVudCwgZXZlbiB3aGVuIHRoZSBoZWFkIGlzCiAgICAgICAgIHNv bGljaXRpbmcgdHJhZmZpYyBmcm9tIHRoZSB0YWlscy4gIFRoaXMgY2FuIGJlIHVzZWZ1bCwgZm9y CiAgICAgICAgIGV4YW1wbGUsIGluIGRlcGxveW1lbnRzIG9mIGEgbGFyZ2UgbnVtYmVyIG9mIHRh aWxzIHdoZW4gdGhlCiAgICAgICAgIGhlYWQgd2lzaGVzIHRvIHRyYWNrIHRoZSBzdGF0ZSBvZiBh IHN1YnNldCBvZiB0aGVtLiAgVGhpcwogICAgICAgICB2YXJpYWJsZSBNVVNUIGJlIGluaXRpYWxp emVkIGJhc2VkIG9uIGNvbmZpZ3VyYXRpb24uCgogICAgICAgICBUaGlzIHZhcmlhYmxlIGlzIG9u bHkgcGVydGluZW50IHdoZW4gYmZkLlNlc3Npb25UeXBlIGlzCiAgICAgICAgIE11bHRpcG9pbnRU YWlsIGFuZCBTSE9VTEQgTk9UIGJlIG1vZGlmaWVkIGFmdGVyIHRoZQogICAgICAgICBNdWx0aXBv aW50VGFpbCBzZXNzaW9uIGhhcyBiZWVuIGNyZWF0ZWQuCgogICAgICBiZmQuUmVwb3J0VGFpbERv d24KCiAgICAgICAgIFNldCB0byAxIGlmIHRoZSBoZWFkIHdpc2hlcyB0YWlscyB0byBub3RpZnkg dGhlIGhlYWQsIHZpYQogICAgICAgICBwZXJpb2RpYyBCRkQgQ29udHJvbCBwYWNrZXRzLCB3aGVu IHRoZXkgc2VlIHRoZSBCRkQgc2Vzc2lvbgogICAgICAgICBmYWlsLiAgSWYgMCwgdGhlIHRhaWwg d2lsbCBuZXZlciBzZW5kIHBlcmlvZGljIEJGRCBDb250cm9sCiAgICAgICAgIHBhY2tldHMsIGFu ZCB0aGUgaGVhZCB3aWxsIG5vdCBiZSBub3RpZmllZCBvZiBzZXNzaW9uIGZhaWx1cmVzCiAgICAg ICAgIGJ5IHRoZSB0YWlscy4gIFRoaXMgdmFyaWFibGUgTVVTVCBiZSBpbml0aWFsaXplZCBiYXNl ZCBvbgogICAgICAgICBjb25maWd1cmF0aW9uLgoKCgoKCkthdHosIGV0IGFsLiAgICAgICAgICAg IEV4cGlyZXMgRGVjZW1iZXIgNiwgMjAxOCAgICAgICAgICAgICAgICBbUGFnZSA4XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgQkZEIE11bHRpcG9pbnQgQWN0aXZlIFRhaWxzICAgICAgICAgICAg IEp1bmUgMjAxOAoKCiAgICAgICAgIFRoaXMgdmFyaWFibGUgaXMgb25seSBwZXJ0aW5lbnQgd2hl biBiZmQuU2Vzc2lvblR5cGUgaXMKICAgICAgICAgTXVsdGlwb2ludEhlYWQgb3IgTXVsdGlwb2lu dENsaWVudC4KCiAgICAgIGJmZC5VbmljYXN0UmN2ZAoKICAgICAgICAgU2V0IHRvIDEgaWYgYSB0 YWlsIHJlY2VpdmVzIGEgdW5pY2FzdCBCRkQgQ29udHJvbCBwYWNrZXQgZnJvbQogICAgICAgICB0 aGUgaGVhZC4gIFRoaXMgdmFyaWFibGUgTVVTVCBiZSBzZXQgdG8gemVybyBpZiB0aGUgc2Vzc2lv bgogICAgICAgICB0cmFuc2l0aW9ucyBmcm9tIFVwIHN0YXRlIHRvIHNvbWUgb3RoZXIgc3RhdGUu CgogICAgICAgICBUaGlzIHZhcmlhYmxlIE1VU1QgYmUgaW5pdGlhbGl6ZWQgdG8gemVyby4KCiAg ICAgICAgIFRoaXMgdmFyaWFibGUgaXMgb25seSBwZXJ0aW5lbnQgd2hlbiBiZmQuU2Vzc2lvblR5 cGUgaXMKICAgICAgICAgTXVsdGlwb2ludFRhaWwuCgo2LjMuMi4gIE5ldyBTdGF0ZSBWYXJpYWJs ZSBWYWx1ZQoKICAgQSBuZXcgc3RhdGUgdmFyaWFibGUgdmFsdWUgYmVpbmcgYWRkZWQgdG86Cgog ICBiZmQuU2Vzc2lvblR5cGUKCiAgICAgIFRoZSB0eXBlIG9mIHRoaXMgc2Vzc2lvbiBhcyBkZWZp bmVkIGluIFtSRkM3ODgwXS4gIEEgbmV3IHZhbHVlCiAgICAgIGludHJvZHVjZWQgaXM6CgogICAg ICAgICBNdWx0aXBvaW50Q2xpZW50OiBBIHNlc3Npb24gb24gdGhlIGhlYWQgdGhhdCB0cmFja3Mg dGhlIHN0YXRlCiAgICAgICAgIG9mIGFuIGluZGl2aWR1YWwgdGFpbCwgd2hlbiBkZXNpcmFibGUu CgogICAgICBUaGlzIHZhcmlhYmxlIE1VU1QgYmUgaW5pdGlhbGl6ZWQgdG8gdGhlIGFwcHJvcHJp YXRlIHR5cGUgd2hlbiB0aGUKICAgICAgc2Vzc2lvbiBpcyBjcmVhdGVkLCBhY2NvcmRpbmcgdG8g dGhlIHJ1bGVzIGluIHNlY3Rpb24gNC40IG9mCiAgICAgIFtJLUQuaWV0Zi1iZmQtbXVsdGlwb2lu dF0uCgo2LjMuMy4gIFN0YXRlIFZhcmlhYmxlIEluaXRpYWxpemF0aW9uIGFuZCBNYWludGVuYW5j ZQoKICAgU29tZSBzdGF0ZSB2YXJpYWJsZXMgZGVmaW5lZCBpbiBzZWN0aW9uIDYuOC4xIG9mIFtS RkM1ODgwXSBuZWVkIHRvIGJlCiAgIGluaXRpYWxpemVkIG9yIG1hbmlwdWxhdGVkIGRpZmZlcmVu dGx5IGRlcGVuZGluZyBvbiB0aGUgc2Vzc2lvbiB0eXBlLgogICBUaGUgdmFsdWVzIG9mIHNvbWUg b2YgdGhlc2UgdmFyaWFibGVzIHJlbGF0ZSB0byB0aG9zZSBvZiB0aGUgc2FtZQogICB2YXJpYWJs ZXMgb2YgYSBNdWx0aXBvaW50SGVhZCBzZXNzaW9uIChzZWUgc2VjdGlvbiA0LjQuMiBvZgogICBb SS1ELmlldGYtYmZkLW11bHRpcG9pbnRdKS4KCiAgICAgIGJmZC5Mb2NhbERpc2NyCgogICAgICAg ICBGb3Igc2Vzc2lvbiB0eXBlIE11bHRpcG9pbnRDbGllbnQsIHRoaXMgdmFyaWFibGUgTVVTVCBh bHdheXMKICAgICAgICAgbWF0Y2ggdGhlIHZhbHVlIG9mIGJmZC5Mb2NhbERpc2NyIGluIHRoZSBh c3NvY2lhdGVkCiAgICAgICAgIE11bHRpcG9pbnRIZWFkIHNlc3Npb24uCgogICAgICBiZmQuRGVz aXJlZE1pblR4SW50ZXJ2YWwKCgoKCgoKS2F0eiwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBE ZWNlbWJlciA2LCAyMDE4ICAgICAgICAgICAgICAgIFtQYWdlIDldCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICBCRkQgTXVsdGlwb2ludCBBY3RpdmUgVGFpbHMgICAgICAgICAgICAgSnVuZSAyMDE4 CgoKICAgICAgICAgRm9yIHNlc3Npb24gdHlwZSBNdWx0aXBvaW50Q2xpZW50LCB0aGlzIHZhcmlh YmxlIE1VU1QgYWx3YXlzCiAgICAgICAgIG1hdGNoIHRoZSB2YWx1ZSBvZiBiZmQuRGVzaXJlZE1p blR4SW50ZXJ2YWwgaW4gdGhlIGFzc29jaWF0ZWQKICAgICAgICAgTXVsdGlwb2ludEhlYWQgc2Vz c2lvbi4KCiAgICAgIGJmZC5SZXF1aXJlZE1pblJ4SW50ZXJ2YWwKCiAgICAgICAgIEl0IE1BWSBi ZSBzZXQgdG8gemVybyBhdCB0aGUgaGVhZCBCRkQgc3lzdGVtIHRvIHN1cHByZXNzCiAgICAgICAg IHRyYWZmaWMgZnJvbSB0aGUgdGFpbHMuICBTZXR0aW5nIGl0IHRvIHplcm8gaW4gdGhlCiAgICAg ICAgIE11bHRpcG9pbnRIZWFkIHNlc3Npb24gc3VwcHJlc3NlcyB0cmFmZmljIGZyb20gYWxsIHRh aWxzLCB0aGUKICAgICAgICAgc2V0dGluZyBpbiBhIE11bHRpcG9pbnRDbGllbnQgc2Vzc2lvbiBz dXBwcmVzc2VzIHRyYWZmaWMgZnJvbSBhCiAgICAgICAgIHNpbmdsZSB0YWlsLgoKICAgICAgYmZk LkRlbWFuZE1vZGUKCiAgICAgICAgIFRoaXMgdmFyaWFibGUgTVVTVCBiZSBpbml0aWFsaXplZCB0 byAxIGZvciBzZXNzaW9uIHR5cGVzCiAgICAgICAgIE11bHRpcG9pbnRDbGllbnQuCgogICAgICBi ZmQuRGV0ZWN0TXVsdAoKICAgICAgICAgRm9yIHNlc3Npb24gdHlwZSBNdWx0aXBvaW50Q2xpZW50 LCB0aGlzIHZhcmlhYmxlIE1VU1QgYWx3YXlzCiAgICAgICAgIG1hdGNoIHRoZSB2YWx1ZSBvZiBi ZmQuRGV0ZWN0TXVsdCBpbiB0aGUgYXNzb2NpYXRlZAogICAgICAgICBNdWx0aXBvaW50SGVhZCBz ZXNzaW9uLgoKNi40LiAgQ29udHJvbGxpbmcgTXVsdGlwb2ludCBCRkQgT3B0aW9ucwoKICAgVGhl IHN0YXRlIHZhcmlhYmxlcyBkZWZpbmVkIGFib3ZlIGFyZSB1c2VkIHRvIGNob29zZSB3aGljaAog ICBvcGVyYXRpb25hbCBvcHRpb25zIGFyZSBhY3RpdmUuCgogICBUaGUgbW9zdCBiYXNpYyBmb3Jt IG9mIG9wZXJhdGlvbiwgYXMgZXhwbGFpbmVkIGluCiAgIFtJLUQuaWV0Zi1iZmQtbXVsdGlwb2lu dF0sIGluIHdoaWNoIEJGRCBDb250cm9sIHBhY2tldHMgZmxvdyBvbmx5CiAgIGZyb20gdGhlIGhl YWQgYW5kIG5vIHRyYWNraW5nIGlzIGRlc2lyZWQgb2YgdGFpbCBzdGF0ZSBhdCB0aGUgaGVhZCwK ICAgaXMgYWNjb21wbGlzaGVkIGJ5IHNldHRpbmcgYmZkLlJlcG9ydFRhaWxEb3duIHRvIDAgaW4g dGhlCiAgIE11bHRpcG9pbnRIZWFkIHNlc3Npb24gKFNlY3Rpb24gNS4xKS4KCiAgIElmIHRoZSBo ZWFkIHdpc2hlcyB0byBrbm93IG9mIGFjdGl2ZSB0aGUgdGFpbHMsIGl0IHNlbmRzIG11bHRpcG9p bnQKICAgUG9sbHMgYXMgbmVlZGVkLiAgUHJldmlvdXNseSBrbm93biB0YWlscyB0aGF0IGRvbid0 IHJlc3BvbmQgdG8gdGhlCiAgIFBvbGxzIHdpbGwgYmUgZGV0ZWN0ZWQgKGFzIHBlciBTZWN0aW9u IDUuMi4yKS4KCiAgIElmIHRoZSBoZWFkIHdpc2hlcyB0byByZXF1ZXN0IGEgbm90aWZpY2F0aW9u IGZyb20gdGhlIHRhaWxzIHdoZW4gdGhleQogICBsb3NlIGNvbm5lY3Rpdml0eSwgaXQgc2V0cyBi ZmQuUmVwb3J0VGFpbERvd24gdG8gMSBpbiBlaXRoZXIgdGhlCiAgIE11bHRpcG9pbnRIZWFkIHNl c3Npb24gKGlmIHN1Y2ggbm90aWZpY2F0aW9uIGlzIGRlc2lyZWQgZnJvbSBhbGwKICAgdGFpbHMp IG9yIGluIHRoZSBNdWx0aXBvaW50Q2xpZW50IHNlc3Npb24gKGlmIG5vdGlmaWNhdGlvbiBpcyBk ZXNpcmVkCiAgIGZyb20gYSBwYXJ0aWN1bGFyIHRhaWwpLiAgTm90ZSB0aGF0IHRoZSBzZXR0aW5n IG9mIHRoaXMgdmFyaWFibGUgaW4gYQogICBNdWx0aXBvaW50Q2xpZW50IHNlc3Npb24gZm9yIGEg cGFydGljdWxhciB0YWlsIG92ZXJyaWRlcyB0aGUgc2V0dGluZwogICBpbiB0aGUgTXVsdGlwb2lu dEhlYWQgc2Vzc2lvbi4KCiAgIElmIHRoZSBoZWFkIHdpc2hlcyB0byB2ZXJpZnkgdGhlIHN0YXRl IG9mIGEgdGFpbCBvbiBhbiBvbmdvaW5nIGJhc2lzLAogICBpdCBzZW5kcyBhIFBvbGwgU2VxdWVu Y2UgZnJvbSB0aGUgTXVsdGlwb2ludENsaWVudCBzZXNzaW9uIGFzc29jaWF0ZWQKCgoKS2F0eiwg ZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciA2LCAyMDE4ICAgICAgICAgICAgICAg W1BhZ2UgMTBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBCRkQgTXVsdGlwb2ludCBBY3RpdmUg VGFpbHMgICAgICAgICAgICAgSnVuZSAyMDE4CgoKICAgd2l0aCB0aGF0IHRhaWwgYXMgbmVlZGVk LiAgVGhpcyBoYXMgdGhlIGVmZmVjdCBvZiBlbGltaW5hdGluZyB0aGUKICAgaW5pdGlhbCBkZWxh eSwgZGVzY3JpYmVkIGluIFNlY3Rpb24gNi4xMy4zLCB0aGF0IHRoZSB0YWlsIHdvdWxkCiAgIG90 aGVyd2lzZSBpbnNlcnQgcHJpb3IgdG8gdHJhbnNtaXNzaW9uIG9mIHRoZSBwYWNrZXQgdGh1cyB0 aGUgaGVhZAogICBtYXkgaGF2ZSBub3RpZmljYXRpb24gb2YgdGhlIHNlc3Npb24gZmFpbHVyZSBt b3JlIHF1aWNrbHkgd2hlbgogICBjb21wYXJpbmcgd2l0aCB1c2Ugb2YgbS1wb2xsLgoKICAgSWYg YSB0YWlsIHdpc2hlcyB0byBvcGVyYXRlIHNpbGVudGx5IChzZW5kaW5nIG5vIEJGRCBDb250cm9s IHBhY2tldHMKICAgdG8gdGhlIGhlYWQpIGl0IHNldHMgYmZkLlNpbGVudFRhaWwgdG8gMSBpbiB0 aGUgTXVsdGlwb2ludFRhaWwKICAgc2Vzc2lvbi4gIFRoaXMgYWxsb3dzIGEgdGFpbCB0byBiZSBz aWxlbnQgaW5kZXBlbmRlbnQgb2YgdGhlIHNldHRpbmdzCiAgIG9uIHRoZSBoZWFkLgoKNi41LiAg U3RhdGUgTWFjaGluZQoKICAgVGhvdWdoIHRoZSBzdGF0ZSB0cmFuc2l0aW9ucyBmb3IgdGhlIHN0 YXRlIG1hY2hpbmUsIGFzIGRlZmluZWQgaW4KICAgc2VjdGlvbiA1LjUgb2YgW0ktRC5pZXRmLWJm ZC1tdWx0aXBvaW50XSwgZm9yIGEgc2Vzc2lvbiB0eXBlCiAgIE11bHRpcG9pbnRIZWFkIGFyZSBv bmx5IGFkbWluaXN0cmF0aXZlbHkgZHJpdmVuIHRoZSBzdGF0ZSBtYWNoaW5lIGZvcgogICBhIHNl c3Npb24gb2YgdHlwZSBNdWx0aXBvaW50Q2xpZW50IGlzIHNhbWUgYW5kIHRoZSBkaWFncmFtIGlz CiAgIGFwcGxpY2FibGUuCgo2LjYuICBTZXNzaW9uIEVzdGFibGlzaG1lbnQKCiAgIElmIEJGRCBD b250cm9sIHBhY2tldHMgYXJlIHJlY2VpdmVkIGF0IHRoZSBoZWFkLCB0aGV5IGFyZQogICBkZW11 bHRpcGxleGVkIHRvIHNlc3Npb25zIG9mIHR5cGUgTXVsdGlwb2ludENsaWVudCwgd2hpY2ggcmVw cmVzZW50CiAgIHRoZSBzZXQgb2YgdGFpbHMgdGhhdCB0aGUgaGVhZCBpcyBpbnRlcmVzdGVkIGlu IHRyYWNraW5nLiAgVGhlc2UKICAgc2Vzc2lvbnMgd2lsbCB0eXBpY2FsbHkgYWxzbyBiZSBlc3Rh Ymxpc2hlZCBkeW5hbWljYWxseSBiYXNlZCBvbiB0aGUKICAgcmVjZWlwdCBvZiBCRkQgQ29udHJv bCBwYWNrZXRzLiAgVGhlIGhlYWQgaGFzIGJyb2FkIGxhdGl0dWRlIGluCiAgIGNob29zaW5nIHdo aWNoIHRhaWxzIHRvIHRyYWNrLCBpZiBhbnksIHdpdGhvdXQgYWZmZWN0aW5nIHRoZSBiYXNpYwog ICBvcGVyYXRpb24gb2YgdGhlIHByb3RvY29sLiAgVGhlIGhlYWQgZGlyZWN0bHkgY29udHJvbHMg d2hldGhlciBvciBub3QKICAgdGFpbHMgYXJlIGFsbG93ZWQgdG8gc2VuZCBCRkQgQ29udHJvbCBw YWNrZXRzIGJhY2sgdG8gdGhlIGhlYWQgYnkKICAgc2V0dGluZyBiZmQuUmVxdWlyZWRNaW5SeElu dGVydmFsIHRvIHplcm8gaW4gYSBNdWx0aXBvaW50SGVhZCBvciBhCiAgIE11bHRpcG9pbnRDbGll bnQgc2Vzc2lvbi4KCjYuNy4gIERpc2NyaW1pbmF0b3JzIGFuZCBQYWNrZXQgRGVtdWx0aXBsZXhp bmcKCiAgIFdoZW4gdGhlIHRhaWxzIHNlbmQgQkZEIENvbnRyb2wgcGFja2V0cyB0byB0aGUgaGVh ZCBmcm9tIHRoZQogICBNdWx0aXBvaW50VGFpbCBzZXNzaW9uLCB0aGUgY29udGVudHMgb2YgWW91 ciBEaXNjciAodGhlIGRpc2NyaW1pbmF0b3IKICAgcmVjZWl2ZWQgZnJvbSB0aGUgaGVhZCkgd2ls bCBub3QgYmUgc3VmZmljaWVudCBmb3IgdGhlIGhlYWQgdG8KICAgZGVtdWx0aXBsZXggdGhlIHBh Y2tldCwgc2luY2UgdGhlIHNhbWUgdmFsdWUgd2lsbCBiZSByZWNlaXZlZCBmcm9tCiAgIGFsbCB0 YWlscyBvbiB0aGUgbXVsdGljYXN0IHRyZWUuICBJbiB0aGlzIGNhc2UsIHRoZSBoZWFkIE1VU1QK ICAgZGVtdWx0aXBsZXggcGFja2V0cyBiYXNlZCBvbiB0aGUgc291cmNlIGFkZHJlc3MgYW5kIHRo ZSB2YWx1ZSBvZiBZb3VyCiAgIERpc2NyLCB3aGljaCB0b2dldGhlciB1bmlxdWVseSBpZGVudGlm eSB0aGUgdGFpbCBhbmQgdGhlIG11bHRpcG9pbnQKICAgcGF0aC4KCiAgIFdoZW4gdGhlIGhlYWQg c2VuZHMgdW5pY2FzdCBCRkQgQ29udHJvbCBwYWNrZXRzIHRvIGEgdGFpbCBmcm9tIGEKICAgTXVs dGlwb2ludENsaWVudCBzZXNzaW9uLCB0aGUgdmFsdWUgb2YgWW91ciBEaXNjciB3aWxsIGJlIHZh bGlkLCBhbmQKICAgdGhlIHRhaWwgTVVTVCBkZW11bHRpcGxleCB0aGUgcGFja2V0IGJhc2VkIHNv bGVseSBvbiBZb3VyIERpc2NyLgoKCgoKCkthdHosIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMg RGVjZW1iZXIgNiwgMjAxOCAgICAgICAgICAgICAgIFtQYWdlIDExXQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgQkZEIE11bHRpcG9pbnQgQWN0aXZlIFRhaWxzICAgICAgICAgICAgIEp1bmUgMjAx OAoKCjYuOC4gIENvbnRyb2xsaW5nIFRhaWwgUGFja2V0IFRyYW5zbWlzc2lvbgoKICAgQXMgdGhl IGZhbi1pbiBmcm9tIHRoZSB0YWlscyB0byB0aGUgaGVhZCBtYXkgYmUgdmVyeSBsYXJnZSwgaXQg aXMKICAgY3JpdGljYWwgdGhhdCB0aGUgZmxvdyBvZiBCRkQgQ29udHJvbCBwYWNrZXRzIGZyb20g dGhlIHRhaWxzIGlzCiAgIGNvbnRyb2xsZWQuCgogICBUaGUgaGVhZCBhbHdheXMgb3BlcmF0ZXMg aW4gRGVtYW5kIG1vZGUuICBUaGlzIG1lYW5zIHRoYXQgbm8gdGFpbAogICB3aWxsIHNlbmQgYW4g YXN5bmNocm9ub3VzIEJGRCBDb250cm9sIHBhY2tldCBhcyBsb25nIGFzIHRoZSBzZXNzaW9uCiAg IGlzIFVwLgoKICAgVGhlIHZhbHVlIG9mIFJlcXVpcmVkIE1pbiBSeCBJbnRlcnZhbCByZWNlaXZl ZCBieSBhIHRhaWwgaW4gYSB1bmljYXN0CiAgIEJGRCBDb250cm9sIHBhY2tldCwgaWYgYW55LCBh bHdheXMgdGFrZXMgcHJlY2VkZW5jZSBvdmVyIHRoZSB2YWx1ZQogICByZWNlaXZlZCBpbiBNdWx0 aXBvaW50IEJGRCBDb250cm9sIHBhY2tldHMuICBUaGlzIGFsbG93cyB0aGUgcGFja2V0CiAgIHJh dGUgZnJvbSBpbmRpdmlkdWFsIHRhaWxzIHRvIGJlIGNvbnRyb2xsZWQgc2VwYXJhdGVseSBhcyBk ZXNpcmVkIGJ5CiAgIHNlbmRpbmcgYSBCRkQgQ29udHJvbCBwYWNrZXQgZnJvbSB0aGUgY29ycmVz cG9uZGluZyBNdWx0aXBvaW50Q2xpZW50CiAgIHNlc3Npb24uICBUaGlzIGFsc28gZWxpbWluYXRl cyB0aGUgcmFuZG9tIGRlbGF5LCBhcyBkaXNjdXNzZWQgaW4KICAgU2VjdGlvbiA2LjEzLjMsIHBy aW9yIHRvIHRyYW5zbWlzc2lvbiBmcm9tIHRoZSB0YWlsIHRoYXQgd291bGQKICAgb3RoZXJ3aXNl IGJlIGluc2VydGVkLCByZWR1Y2luZyB0aGUgbGF0ZW5jeSBvZiByZXBvcnRpbmcgYSBmYWlsdXJl IHRvCiAgIHRoZSBoZWFkLgoKICAgSWYgdGhlIGhlYWQgd2lzaGVzIHRvIHN1cHByZXNzIHRyYWZm aWMgZnJvbSB0aGUgdGFpbHMgd2hlbiB0aGV5CiAgIGRldGVjdCBhIHNlc3Npb24gZmFpbHVyZSwg aXQgTUFZIHNldCBiZmQuUmVxdWlyZWRNaW5SeEludGVydmFsIHRvCiAgIHplcm8sIHdoaWNoIGlz IGEgcmVzZXJ2ZWQgdmFsdWUgdGhhdCBpbmRpY2F0ZXMgdGhhdCB0aGUgc2VuZGVyIHdpc2hlcwog ICB0byByZWNlaXZlIG5vIHBlcmlvZGljIHRyYWZmaWMuICBUaGlzIGNhbiBiZSBzZXQgaW4gdGhl CiAgIE11bHRpcG9pbnRIZWFkIHNlc3Npb24gKHN1cHByZXNzaW5nIHRyYWZmaWMgZnJvbSBhbGwg dGFpbHMpIG9yIGl0IGNhbgogICBiZSBzZXQgaW4gYSBNdWx0aXBvaW50Q2xpZW50IHNlc3Npb24g KHN1cHByZXNzaW5nIHRyYWZmaWMgZnJvbSBvbmx5IGEKICAgc2luZ2xlIHRhaWwpLgoKICAgQW55 IHRhaWwgbWF5IGJlIHByb3Zpc2lvbmVkIHRvIG5ldmVyIHNlbmQgKmFueSogQkZEIENvbnRyb2wg cGFja2V0cwogICB0byB0aGUgaGVhZCBieSBzZXR0aW5nIGJmZC5TaWxlbnRUYWlsIHRvIDEuICBU aGlzIHByb3ZpZGVzIGEKICAgbWVjaGFuaXNtIGJ5IHdoaWNoIG9ubHkgYSBzdWJzZXQgb2YgdGFp bHMgcmVwb3J0cyB0aGVpciBzZXNzaW9uCiAgIHN0YXR1cyB0byB0aGUgaGVhZC4KCjYuOS4gIFNv bGljaXRpbmcgdGhlIFRhaWxzCgogICBJZiB0aGUgaGVhZCB3aXNoZXMgdG8ga25vdyBvZiB0aGUg YWN0aXZlIHRhaWxzLCB0aGUgTXVsdGlwb2ludEhlYWQKICAgc2Vzc2lvbiBNQVkgc2VuZCBhIEJG RCBDb250cm9sIHBhY2tldCBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiA2LjEzLjMsCiAgIHdpdGgg dGhlIFBvbGwgKFApIGJpdCBzZXQgdG8gMS4gIFRoaXMgd2lsbCBjYXVzZSBhbGwgb2YgdGhlIHRh aWxzIHRvCiAgIHJlcGx5IHdpdGggYSB1bmljYXN0IEJGRCBDb250cm9sIFBhY2tldCwgcmFuZG9t aXplZCBhY3Jvc3Mgb25lIHBhY2tldAogICBpbnRlcnZhbC4KCiAgIFRoZSBkZWNpc2lvbiBhcyB0 byB3aGVuIHRvIHNlbmQgYSBtdWx0aXBvaW50IFBvbGwgaXMgb3V0c2lkZSB0aGUKICAgc2NvcGUg b2YgdGhpcyBzcGVjaWZpY2F0aW9uLiAgSG93ZXZlciwgaXQgbXVzdCBuZXZlciBiZSBzZW50IG1v cmUKICAgb2Z0ZW4gdGhhbiB0aGUgcmVndWxhciBtdWx0aXBvaW50IEJGRCBDb250cm9sIHBhY2tl dC4gIFNpbmNlIHRoZSB0YWlsCiAgIHdpbGwgdHJlYXQgYSBtdWx0aXBvaW50IFBvbGwgbGlrZSBh bnkgb3RoZXIgbXVsdGlwb2ludCBCRkQgQ29udHJvbAogICBwYWNrZXQsIFBvbGxzIG1heSBiZSBz ZW50IGluIGxpZXUgb2Ygbm9uLVBvbGwgcGFja2V0cy4KCgoKCgpLYXR6LCBldCBhbC4gICAgICAg ICAgICBFeHBpcmVzIERlY2VtYmVyIDYsIDIwMTggICAgICAgICAgICAgICBbUGFnZSAxMl0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgIEJGRCBNdWx0aXBvaW50IEFjdGl2ZSBUYWlscyAgICAgICAg ICAgICBKdW5lIDIwMTgKCgogICBTb2xpY2l0aW5nIHRoZSB0YWlscyBhbHNvIHN0YXJ0cyB0aGUg RGV0ZWN0aW9uIFRpbWVyIGZvciBlYWNoIG9mIHRoZQogICBhc3NvY2lhdGVkIE11bHRpcG9pbnRD bGllbnQgc2Vzc2lvbnMsIHdoaWNoIHdpbGwgY2F1c2UgdGhvc2Ugc2Vzc2lvbnMKICAgdG8gdGlt ZSBvdXQgaWYgdGhlIGFzc29jaWF0ZWQgdGFpbHMgZG8gbm90IHJlc3BvbmQuCgogICBOb3RlIHRo YXQgZm9yIHRoaXMgbWVjaGFuaXNtIHRvIHdvcmsgcHJvcGVybHksIHRoZSBEZXRlY3Rpb24gVGlt ZQogICAod2hpY2ggaXMgZXF1YWwgdG8gYmZkLkRlc2lyZWRNaW5UeEludGVydmFsKSBNVVNUIGJl IGdyZWF0ZXIgdGhhbiB0aGUKICAgcm91bmQgdHJpcCB0aW1lIG9mIEJGRCBDb250cm9sIHBhY2tl dHMgZnJvbSB0aGUgaGVhZCB0byB0aGUgdGFpbCAodmlhCiAgIHRoZSBtdWx0aXBvaW50IHBhdGgp IGFuZCBiYWNrICh2aWEgYSB1bmljYXN0IHBhdGgpLiAgU2VlIFNlY3Rpb24gNi4xMQogICBmb3Ig bW9yZSBkZXRhaWxzLgoKNi4xMC4gIFZlcmlmeWluZyBDb25uZWN0aXZpdHkgdG8gU3BlY2lmaWMg VGFpbHMKCiAgIElmIHRoZSBoZWFkIHdpc2hlcyB0byB2ZXJpZnkgY29ubmVjdGl2aXR5IHRvIGEg c3BlY2lmaWMgdGFpbCwgdGhlCiAgIGNvcnJlc3BvbmRpbmcgTXVsdGlwb2ludENsaWVudCBzZXNz aW9uIE1BWSBzZW5kIGEgQkZEIFBvbGwgU2VxdWVuY2UKICAgdG8gc2FpZCB0YWlsLiAgVGhpcyBt aWdodCBiZSBkb25lIGluIHJlYWN0aW9uIHRvIHRoZSBleHBpcmF0aW9uIG9mCiAgIHRoZSBEZXRl Y3Rpb24gVGltZXIgKHRoZSB0YWlsIGRpZG4ndCByZXNwb25kIHRvIGEgbXVsdGlwb2ludCBQb2xs KSwKICAgb3IgaXQgbWlnaHQgYmUgZG9uZSBvbiBhIHByb2FjdGl2ZSBiYXNpcy4KCiAgIFRoZSBp bnRlcnZhbCBiZXR3ZWVuIHRyYW5zbWl0dGVkIHBhY2tldHMgaW4gdGhlIFBvbGwgU2VxdWVuY2Ug TVVTVCBiZQogICBjYWxjdWxhdGVkIGFzIHNwZWNpZmllZCBpbiB0aGUgYmFzZSBCRkQgc3BlY2lm aWNhdGlvbiBbUkZDNTg4MF0gKHRoZQogICBncmVhdGVyIG9mIGJmZC5EZXNpcmVkTWluVHhJbnRl cnZhbCBhbmQgYmZkLlJlbW90ZU1pblJ4SW50ZXJ2YWwpLgoKICAgVGhlIHZhbHVlIHRyYW5zbWl0 dGVkIGluIFJlcXVpcmVkIE1pbiBSWCBJbnRlcnZhbCB3aWxsIGJlIHVzZWQgYnkgdGhlCiAgIHRh aWwgKHJhdGhlciB0aGFuIHRoZSB2YWx1ZSByZWNlaXZlZCBpbiBhbnkgbXVsdGlwb2ludCBwYWNr ZXQpIHdoZW4KICAgaXQgdHJhbnNtaXRzIEJGRCBDb250cm9sIHBhY2tldHMgdG8gdGhlIGhlYWQg bm90aWZ5aW5nIGl0IG9mIGEKICAgc2Vzc2lvbiBmYWlsdXJlIGFuZCB0aGUgdHJhbnNtaXR0ZWQg cGFja2V0cyB3aWxsIG5vdCBiZSBkZWxheWVkLgogICBUaGlzIHZhbHVlIGNhbiBwb3RlbnRpYWxs eSBiZSBzZXQgbXVjaCBsb3dlciB0aGFuIGluIHRoZSBtdWx0aXBvaW50CiAgIGNhc2UsIGluIG9y ZGVyIHRvIHNwZWVkIHVwIGEgbm90aWZpY2F0aW9uIHRvIHRoZSBoZWFkLCBzaW5jZSB0aGUKICAg dmFsdWUgd2lsbCBiZSB1c2VkIG9ubHkgYnkgdGhlIHNpbmdsZSB0YWlsLiAgVGhpcyB2YWx1ZSAo YW5kIHRoZSBsYWNrCiAgIG9mIGRlbGF5KSBhcmUgInN0aWNreSIsIGluIHRoYXQgb25jZSB0aGUg dGFpbCByZWNlaXZlcyBpdCwgaXQgd2lsbAogICBjb250aW51ZSB0byB1c2UgaXQgaW5kZWZpbml0 ZWx5LiAgVGhlcmVmb3JlLCBpZiB0aGUgaGVhZCBubyBsb25nZXIKICAgd2lzaGVzIHRvIHNpbmds ZSBvdXQgdGhlIHRhaWwsIGl0IFNIT1VMRCByZXNldCB0aGUgdGltZXIgdG8gdGhlCiAgIGRlZmF1 bHQgYnkgc2VuZGluZyBhIFBvbGwgU2VxdWVuY2Ugd2l0aCB0aGUgc2FtZSB2YWx1ZSBvZiBSZXF1 aXJlZAogICBNaW4gUnggSW50ZXJ2YWwgYXMgaXMgY2FycmllZCBpbiB0aGUgbXVsdGlwb2ludCBw YWNrZXRzLCBvciBpdCBNQVkKICAgcmVzZXQgdGhlIHRhaWwgc2Vzc2lvbiBieSBzZW5kaW5nIGEg UG9sbCBTZXF1ZW5jZSB3aXRoIHN0YXRlCiAgIEFkbWluRG93biAoYWZ0ZXIgdGhlIGNvbXBsZXRp b24gb2Ygd2hpY2ggdGhlIHNlc3Npb24gd2lsbCBjb21lIGJhY2sKICAgdXApLgoKICAgTm90ZSB0 aGF0IGEgZmFpbHVyZSBvZiB0aGUgaGVhZCB0byByZWNlaXZlIGEgcmVzcG9uc2UgdG8gYSBQb2xs CiAgIFNlcXVlbmNlIGRvZXMgbm90IG5lY2Vzc2FyaWx5IG1lYW4gdGhhdCB0aGUgdGFpbCBoYXMg bG9zdCBtdWx0aXBvaW50CiAgIGNvbm5lY3Rpdml0eSwgdGhvdWdoIGEgcmVwbHkgdG8gYSBQb2xs IFNlcXVlbmNlIGRvZXMgcmVsaWFibHkKICAgaW5kaWNhdGUgY29ubmVjdGl2aXR5IG9yIGxhY2sg dGhlcmVvZiAoYnkgdmlydHVlIG9mIHRoZSB0YWlsJ3Mgc3RhdGUKICAgbm90IGJlaW5nIFVwIGlu IHRoZSBCRkQgQ29udHJvbCBwYWNrZXQpLgoKCgoKCgoKCkthdHosIGV0IGFsLiAgICAgICAgICAg IEV4cGlyZXMgRGVjZW1iZXIgNiwgMjAxOCAgICAgICAgICAgICAgIFtQYWdlIDEzXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgQkZEIE11bHRpcG9pbnQgQWN0aXZlIFRhaWxzICAgICAgICAgICAg IEp1bmUgMjAxOAoKCjYuMTEuICBEZXRlY3Rpb24gVGltZXMKCiAgIE11bHRpcG9pbnRDbGllbnQg c2Vzc2lvbnMgYXQgdGhlIGhlYWQgYXJlIGFsd2F5cyBpbiB0aGUgRGVtYW5kIG1vZGUsCiAgIGFu ZCBhcyBzdWNoIG9ubHkgY2FyZSBhYm91dCBkZXRlY3Rpb24gdGltZSBpbiB0d28gY2FzZXMuICBG aXJzdCwgaWYgYQogICBQb2xsIFNlcXVlbmNlIGlzIGJlaW5nIHNlbnQgb24gYSBNdWx0aXBvaW50 Q2xpZW50IHNlc3Npb24sIHRoZQogICBkZXRlY3Rpb24gdGltZSBvbiB0aGlzIHNlc3Npb24gaXMg Y2FsY3VsYXRlZCBhY2NvcmRpbmcgdG8gdGhlIGJhc2UKICAgQkZEIHNwZWNpZmljYXRpb24gW1JG QzU4ODBdLCB0aGF0IGlzLCB0aGUgdHJhbnNtaXNzaW9uIGludGVydmFsCiAgIG11bHRpcGxpZWQg YnkgYmZkLkRldGVjdE11bHQuICBTZWNvbmQsIHdoZW4gYSBtdWx0aXBvaW50IFBvbGwgaXMgc2Vu dAogICB0byBzb2xpY2l0IHRhaWwgcmVwbGllcywgdGhlIGRldGVjdGlvbiB0aW1lIG9uIGFsbCBh c3NvY2lhdGVkCiAgIE11bHRpcG9pbnRDbGllbnQgc2Vzc2lvbnMgdGhhdCBhcmVuJ3QgY3VycmVu dGx5IHNlbmRpbmcgUG9sbAogICBTZXF1ZW5jZXMgaXMgc2V0IHRvIGEgdmFsdWUgZ3JlYXRlciB0 aGFuIG9yIGVxdWFsIHRvCiAgIGJmZC5SZXF1aXJlZE1pblJ4SW50ZXJ2YWwgKG9uZSBwYWNrZXQg dGltZSkuICBUaGlzIHZhbHVlIGNhbiBiZSBtYWRlCiAgIGFyYml0cmFyaWx5IGxhcmdlIGluIG9y ZGVyIHRvIGVuc3VyZSB0aGF0IHRoZSBkZXRlY3Rpb24gdGltZSBpcwogICBncmVhdGVyIHRoYW4g dGhlIHJvdW5kIHRyaXAgdGltZSBvZiBhIEJGRCBDb250cm9sIHBhY2tldCBiZXR3ZWVuIHRoZQog ICBoZWFkIGFuZCB0aGUgdGFpbCB3aXRoIG5vIGlsbCBlZmZlY3RzLCBvdGhlciB0aGFuIGRlbGF5 aW5nIHRoZQogICBkZXRlY3Rpb24gb2YgdW5yZXNwb25zaXZlIHRhaWxzLiAgTm90ZSB0aGF0IGEg ZGV0ZWN0aW9uIHRpbWUKICAgZXhwaXJhdGlvbiBvbiBhIE11bHRpcG9pbnRDbGllbnQgc2Vzc2lv biBhdCB0aGUgaGVhZCwgd2hpbGUKICAgaW5kaWNhdGluZyBhIEJGRCBzZXNzaW9uIGZhaWx1cmUs IGNhbm5vdCBiZSBjb25zdHJ1ZWQgdG8gbWVhbiB0aGF0CiAgIHRoZSB0YWlsIGlzIG5vdCBoZWFy aW5nIG11bHRpcG9pbnQgcGFja2V0cyBmcm9tIHRoZSBoZWFkLgoKNi4xMi4gIE11bHRpcG9pbnRD bGllbnQgRG93bi9BZG1pbkRvd24gU2Vzc2lvbnMKCiAgIElmIHRoZSBNdWx0aXBvaW50SGVhZCBz ZXNzaW9uIGlzIGdvaW5nIGRvd24gKHdoaWNoIG9ubHkgaGFwcGVucwogICBhZG1pbmlzdHJhdGl2 ZWx5KSwgYWxsIGFzc29jaWF0ZWQgTXVsdGlwb2ludENsaWVudCBzZXNzaW9ucyBTSE9VTEQgYmUK ICAgZGVzdHJveWVkIGFzIHRoZXkgYXJlIHN1cGVyZmx1b3VzLgoKICAgSWYgYSBNdWx0aXBvaW50 Q2xpZW50IHNlc3Npb24gZ29lcyBkb3duIGR1ZSB0byB0aGUgcmVjZWlwdCBvZiBhbgogICB1bnNv bGljaXRlZCBCRkQgQ29udHJvbCBwYWNrZXQgZnJvbSB0aGUgdGFpbCB3aXRoIHN0YXRlIERvd24g b3IKICAgQWRtaW5Eb3duIChub3QgaW4gcmVzcG9uc2UgdG8gYSBQb2xsKSwgYW5kIHRhaWwgY29u bmVjdGl2aXR5CiAgIHZlcmlmaWNhdGlvbiBpcyBub3QgYmVpbmcgZG9uZSwgdGhlIHNlc3Npb24g TUFZIGJlIGRlc3Ryb3llZC4gIElmCiAgIHZlcmlmaWNhdGlvbiBpcyBkZXNpcmVkLCB0aGUgc2Vz c2lvbiBTSE9VTEQgc2VuZCBhIFBvbGwgU2VxdWVuY2UgYW5kCiAgIHRoZSBzZXNzaW9uIFNIT1VM RCBiZSBtYWludGFpbmVkLgoKICAgSWYgdGhlIHRhaWwgcmVwbGllcyB0byBhIFBvbGwgU2VxdWVu Y2Ugd2l0aCBzdGF0ZSBEb3duIG9yIEFkbWluRG93biwKICAgaXQgbWVhbnMgdGhhdCB0aGUgdGFp bCBzZXNzaW9uIGlzIGRlZmluaXRlbHkgZG93bi4gIEluIHRoaXMgY2FzZSwgdGhlCiAgIHNlc3Np b24gTUFZIGJlIGRlc3Ryb3llZC4KCiAgIElmIHRoZSBEZXRlY3Rpb24gVGltZSBleHBpcmVzIG9u IGEgTXVsdGlwb2ludENsaWVudCBzZXNzaW9uIChtZWFuaW5nCiAgIHRoYXQgdGhlIHRhaWwgZGlk IG5vdCByZXBseSB0byBhIFBvbGwgU2VxdWVuY2UpIHRoZSBzZXNzaW9uIE1BWSBiZQogICBkZXN0 cm95ZWQuCgo2LjEzLiAgQmFzZSBCRkQgZm9yIE11bHRpcG9pbnQgTmV0d29ya3MgU3BlY2lmaWNh dGlvbiBUZXh0IFJlcGxhY2VtZW50CgogICBUaGUgZm9sbG93aW5nIHNlY3Rpb25zIGFyZSBtZWFu dCB0byBleHRlbmQgdGhlIGNvcnJlc3BvbmRpbmcgc2VjdGlvbnMKICAgaW4gdGhlIGJhc2UgQkZE IGZvciBNdWx0aXBvaW50IE5ldHdvcmtzIHNwZWNpZmljYXRpb24KICAgW0ktRC5pZXRmLWJmZC1t dWx0aXBvaW50XS4KCgoKCgpLYXR6LCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIERlY2VtYmVy IDYsIDIwMTggICAgICAgICAgICAgICBbUGFnZSAxNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg IEJGRCBNdWx0aXBvaW50IEFjdGl2ZSBUYWlscyAgICAgICAgICAgICBKdW5lIDIwMTgKCgo2LjEz LjEuICBSZWNlcHRpb24gb2YgQkZEIENvbnRyb2wgUGFja2V0cwoKICAgVGhlIGZvbGxvd2luZyBw cm9jZWR1cmUgdXBkYXRlcyBwYXJ0cyBvZiBTZWN0aW9uIDUuMTMuMSBvZgogICBbSS1ELmlldGYt YmZkLW11bHRpcG9pbnRdLgoKICAgV2hlbiBhIEJGRCBDb250cm9sIHBhY2tldCBpcyByZWNlaXZl ZCwgdGhlIHByb2NlZHVyZSBkZWZpbmVkIGluCiAgIFNlY3Rpb24gNS4xMy4xIG9mIFtJLUQuaWV0 Zi1iZmQtbXVsdGlwb2ludF0gTVVTVCBiZSBmb2xsb3dlZCwgaW4gdGhlCiAgIG9yZGVyIHNwZWNp ZmllZC4gIElmIHRoZSBwYWNrZXQgaXMgZGlzY2FyZGVkIGFjY29yZGluZyB0byB0aGVzZQogICBy dWxlcywgcHJvY2Vzc2luZyBvZiB0aGUgcGFja2V0IE1VU1QgY2Vhc2UgYXQgdGhhdCBwb2ludC4g IEluCiAgIGFkZGl0aW9uIHRvIHRoYXQsIGlmIHRhaWwgdHJhY2tpbmcgaXMgZGVzaXJlZCBieSB0 aGUgaGVhZCwgYmVsb3cKICAgcHJvY2VkdXJlIE1VU1QgYmUgYXBwbGllZC4KCiAgICAgIElmIGJm ZC5TZXNzaW9uVHlwZSBpcyBNdWx0aXBvaW50VGFpbAoKICAgICAgICAgSWYgYmZkLlVuaWNhc3RS Y3ZkIGlzIDAgb3IgdGhlIE0gYml0IGlzIGNsZWFyLCBzZXQKICAgICAgICAgYmZkLlJlbW90ZU1p blJ4SW50ZXJ2YWwgdG8gdGhlIHZhbHVlIG9mIFJlcXVpcmVkIE1pbiBSWAogICAgICAgICBJbnRl cnZhbC4KCiAgICAgICAgIElmIHRoZSBNIGJpdCBpcyBjbGVhciwgc2V0IGJmZC5VbmljYXN0UmN2 ZCB0byAxLgoKICAgICAgRWxzZSAobm90IE11bHRpcG9pbnRUYWlsKQoKICAgICAgICAgU2V0IGJm ZC5SZW1vdGVNaW5SeEludGVydmFsIHRvIHRoZSB2YWx1ZSBvZiBSZXF1aXJlZCBNaW4gUlgKICAg ICAgICAgSW50ZXJ2YWwuCgogICAgICBJZiB0aGUgUG9sbCAoUCkgYml0IGlzIHNldCwgYW5kIGJm ZC5TaWxlbnRUYWlsIGlzIHplcm8sIHNlbmQgYSBCRkQKICAgICAgQ29udHJvbCBwYWNrZXQgdG8g dGhlIHJlbW90ZSBzeXN0ZW0gd2l0aCB0aGUgUG9sbCAoUCkgYml0IGNsZWFyLAogICAgICBhbmQg dGhlIEZpbmFsIChGKSBiaXQgc2V0IChzZWUgU2VjdGlvbiA2LjEzLjMpLgoKNi4xMy4yLiAgRGVt dWx0aXBsZXhpbmcgQkZEIENvbnRyb2wgUGFja2V0cwoKICAgVGhpcyBzZWN0aW9uIGlzIHBhcnQg b2YgdGhlIGFkZGl0aW9uIHRvIFNlY3Rpb24gNS4xMy4yIG9mCiAgIFtJLUQuaWV0Zi1iZmQtbXVs dGlwb2ludF0sIHNlcGFyYXRlZCBmb3IgY2xhcml0eS4KCiAgICAgIElmIE11bHRpcG9pbnQgKE0p IGJpdCBpcyBjbGVhcgoKICAgICAgICAgSWYgdGhlIFlvdXIgRGlzY3JpbWluYXRvciBmaWVsZCBp cyBub256ZXJvCgogICAgICAgICAgICBTZWxlY3QgYSBzZXNzaW9uIGJhc2VkIG9uIHRoZSB2YWx1 ZSBvZiBZb3VyIERpc2NyaW1pbmF0b3IuCiAgICAgICAgICAgIElmIG5vIHNlc3Npb24gaXMgZm91 bmQsIHRoZSBwYWNrZXQgTVVTVCBiZSBkaXNjYXJkZWQuCgogICAgICAgICAgICBJZiBiZmQuU2Vz c2lvblR5cGUgaXMgTXVsdGlwb2ludEhlYWQKCiAgICAgICAgICAgICAgIEZpbmQgYSBNdWx0aXBv aW50Q2xpZW50IHNlc3Npb24gZ3JvdXBlZCB0byB0aGlzCiAgICAgICAgICAgICAgIE11bHRpcG9p bnRIZWFkIHNlc3Npb24sIGJhc2VkIG9uIHRoZSBzb3VyY2UgYWRkcmVzcyBhbmQKICAgICAgICAg ICAgICAgdGhlIHZhbHVlIG9mIFlvdXIgRGlzY3JpbWluYXRvci4gIElmIGEgc2Vzc2lvbiBpcyBm b3VuZAogICAgICAgICAgICAgICBhbmQgaXMgbm90IE11bHRpcG9pbnRDbGllbnQsIHRoZSBwYWNr ZXQgTVVTVCBiZQogICAgICAgICAgICAgICBkaXNjYXJkZWQuICBJZiBubyBzZXNzaW9uIGlzIGZv dW5kLCBhIG5ldyBzZXNzaW9uIG9mIHR5cGUKCgoKS2F0eiwgZXQgYWwuICAgICAgICAgICAgRXhw aXJlcyBEZWNlbWJlciA2LCAyMDE4ICAgICAgICAgICAgICAgW1BhZ2UgMTVdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICBCRkQgTXVsdGlwb2ludCBBY3RpdmUgVGFpbHMgICAgICAgICAgICAgSnVu ZSAyMDE4CgoKICAgICAgICAgICAgICAgTXVsdGlwb2ludENsaWVudCBNQVkgYmUgY3JlYXRlZCwg b3IgdGhlIHBhY2tldCBNQVkgYmUKICAgICAgICAgICAgICAgZGlzY2FyZGVkLiAgVGhpcyBjaG9p Y2UgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcwogICAgICAgICAgICAgICBzcGVjaWZpY2F0 aW9uLgoKICAgICAgICAgICAgICAgSWYgYmZkLlNlc3Npb25UeXBlIGlzIG5vdCBNdWx0aXBvaW50 Q2xpZW50LCB0aGUgcGFja2V0CiAgICAgICAgICAgICAgIE1VU1QgYmUgZGlzY2FyZGVkLgoKNi4x My4zLiAgVHJhbnNtaXR0aW5nIEJGRCBDb250cm9sIFBhY2tldHMKCiAgIEEgc3lzdGVtIE1VU1Qg Tk9UIHBlcmlvZGljYWxseSB0cmFuc21pdCBCRkQgQ29udHJvbCBwYWNrZXRzIGlmCiAgIGJmZC5T ZXNzaW9uVHlwZSBpcyBNdWx0aXBvaW50Q2xpZW50IGFuZCBhIFBvbGwgU2VxdWVuY2UgaXMgbm90 IGJlaW5nCiAgIHRyYW5zbWl0dGVkLgoKICAgSWYgYmZkLlNlc3Npb25UeXBlIGlzIE11bHRpcG9p bnRUYWlsIGFuZCBwZXJpb2RpYyB0cmFuc21pc3Npb24gb2YgQkZECiAgIENvbnRyb2wgcGFja2V0 cyBpcyBqdXN0IHN0YXJ0aW5nIChkdWUgdG8gRGVtYW5kIG1vZGUgbm90IGJlaW5nIGFjdGl2ZQog ICBvbiB0aGUgcmVtb3RlIHN5c3RlbSksIHRoZSBmaXJzdCBwYWNrZXQgdG8gYmUgdHJhbnNtaXR0 ZWQgTVVTVCBiZQogICBkZWxheWVkIGJ5IGEgcmFuZG9tIGFtb3VudCBvZiB0aW1lIGJldHdlZW4g emVybyBhbmQgKDAuOSAqCiAgIGJmZC5SZW1vdGVNaW5SeEludGVydmFsKS4KCiAgIElmIGEgQkZE IENvbnRyb2wgcGFja2V0IGlzIHJlY2VpdmVkIHdpdGggdGhlIFBvbGwgKFApIGJpdCBzZXQgdG8g MSwKICAgdGhlIHJlY2VpdmluZyBzeXN0ZW0gTVVTVCB0cmFuc21pdCBhIEJGRCBDb250cm9sIHBh Y2tldCB3aXRoIHRoZSBQb2xsCiAgIChQKSBiaXQgY2xlYXIgYW5kIHRoZSBGaW5hbCAoRikgYml0 LCB3aXRob3V0IHJlc3BlY3QgdG8gdGhlCiAgIHRyYW5zbWlzc2lvbiB0aW1lciBvciBhbnkgb3Ro ZXIgdHJhbnNtaXNzaW9uIGxpbWl0YXRpb25zLCB3aXRob3V0CiAgIHJlc3BlY3QgdG8gdGhlIHNl c3Npb24gc3RhdGUsIGFuZCB3aXRob3V0IHJlc3BlY3QgdG8gd2hldGhlciBEZW1hbmQKICAgbW9k ZSBpcyBhY3RpdmUgb24gZWl0aGVyIHN5c3RlbS4gIEEgc3lzdGVtIE1BWSBsaW1pdCB0aGUgcmF0 ZSBhdAogICB3aGljaCBzdWNoIHBhY2tldHMgYXJlIHRyYW5zbWl0dGVkLiAgSWYgcmF0ZSBsaW1p dGluZyBpcyBpbiBlZmZlY3QsCiAgIHRoZSBhZHZlcnRpc2VkIHZhbHVlIG9mIERlc2lyZWQgTWlu IFRYIEludGVydmFsIE1VU1QgYmUgZ3JlYXRlciB0aGFuCiAgIG9yIGVxdWFsIHRvIHRoZSBpbnRl cnZhbCBiZXR3ZWVuIHRyYW5zbWl0dGVkIHBhY2tldHMgaW1wb3NlZCBieSB0aGUKICAgcmF0ZSBs aW1pdGluZyBmdW5jdGlvbi4gIElmIHRoZSBNdWx0aXBvaW50IChNKSBiaXQgaXMgc2V0IGluIHRo ZQogICByZWNlaXZlZCBwYWNrZXQsIHRoZSBwYWNrZXQgdHJhbnNtaXNzaW9uIE1VU1QgYmUgZGVs YXllZCBieSBhIHJhbmRvbQogICBhbW91bnQgb2YgdGltZSBiZXR3ZWVuIHplcm8gYW5kICgwLjkg KiBiZmQuUmVtb3RlTWluUnhJbnRlcnZhbCkuCiAgIE90aGVyd2lzZSwgdGhlIHBhY2tldCBNVVNU IGJlIHRyYW5zbWl0dGVkIGFzIHNvb24gYXMgcHJhY3RpY2FibGUuCgogICBBIHN5c3RlbSBNVVNU IE5PVCBzZXQgdGhlIERlbWFuZCAoRCkgYml0IGlmIGJmZC5TZXNzaW9uVHlwZSBpcwogICBNdWx0 aXBvaW50Q2xpZW50IHVubGVzcyBiZmQuRGVtYW5kTW9kZSBpcyAxLCBiZmQuU2Vzc2lvblN0YXRl IGlzIFVwLAogICBhbmQgYmZkLlJlbW90ZVNlc3Npb25TdGF0ZSBpcyBVcC4KCiAgIENvbnRlbnRz IG9mIHRyYW5zbWl0dGVkIHBhY2tldCBNVVNUIGJlIGFzIGV4cGxhaW5lZCBpbiBzZWN0aW9uIDUu MTMuMwogICBvZiBbSS1ELmlldGYtYmZkLW11bHRpcG9pbnRdLgoKNy4gIEFzc3VtcHRpb25zCgog ICBJZiBoZWFkIG5vdGlmaWNhdGlvbiBpcyB0byBiZSB1c2VkLCBpdCBpcyBhc3N1bWVkIHRoYXQg YSBtdWx0aXBvaW50CiAgIEJGRCBwYWNrZXQgZW5jYXBzdWxhdGlvbiBjb250YWlucyBlbm91Z2gg aW5mb3JtYXRpb24gc28gdGhhdCBhIHRhaWwKICAgY2FuIGFkZHJlc3MgYSB1bmljYXN0IEJGRCBw YWNrZXQgdG8gdGhlIGhlYWQuCgogICBJZiBoZWFkIG5vdGlmaWNhdGlvbiBpcyB0byBiZSB1c2Vk LCBpdCBpcyBhc3N1bWVkIHRoYXQgaXMgdGhhdCB0aGVyZQogICBpcyBiaWRpcmVjdGlvbmFsIHVu aWNhc3QgY29tbXVuaWNhdGlvbiBhdmFpbGFibGUgKGF0IHRoZSBzYW1lCgoKCkthdHosIGV0IGFs LiAgICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNiwgMjAxOCAgICAgICAgICAgICAgIFtQYWdl IDE2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgQkZEIE11bHRpcG9pbnQgQWN0aXZlIFRhaWxz ICAgICAgICAgICAgIEp1bmUgMjAxOAoKCiAgIHByb3RvY29sIGxheWVyIHdpdGhpbiB3aGljaCBC RkQgaXMgYmVpbmcgcnVuKSBiZXR3ZWVuIHRoZSB0YWlsIGFuZAogICBoZWFkLgoKICAgRm9yIHRo ZSBoZWFkIHRvIGtub3cgcmVsaWFibHkgdGhhdCBhIHRhaWwgaGFzIGxvc3QgbXVsdGlwb2ludAog ICBjb25uZWN0aXZpdHksIHRoZSB1bmljYXN0IHBhdGhzIGluIGJvdGggZGlyZWN0aW9ucyBiZXR3 ZWVuIHRoYXQgdGFpbAogICBhbmQgdGhlIGhlYWQgbXVzdCByZW1haW4gb3BlcmF0aW9uYWwgd2hl biB0aGUgbXVsdGlwb2ludCBwYXRoIGZhaWxzLgogICBJdCBpcyB0aHVzIGRlc2lyYWJsZSB0aGF0 IHVuaWNhc3QgcGF0aHMgbm90IHNoYXJlIGZhdGUgd2l0aCB0aGUKICAgbXVsdGlwb2ludCBwYXRo IHRvIHRoZSBleHRlbnQgcG9zc2libGUgaWYgdGhlIGhlYWQgd2FudHMgbW9yZQogICBkZWZpbml0 ZSBrbm93bGVkZ2Ugb2YgdGhlIHRhaWwgc3RhdGUuCgogICBTaW5jZSB0aGUgbm9ybWFsIEJGRCB0 aHJlZS13YXkgaGFuZHNoYWtlIGlzIG5vdCB1c2VkIGluIHRoaXMKICAgYXBwbGljYXRpb24sIGEg dGFpbCB0cmFuc2l0aW9uaW5nIGZyb20gc3RhdGUgVXAgdG8gRG93biBhbmQgYmFjayB0bwogICBV cCBhZ2FpbiBtYXkgbm90IGJlIHJlbGlhYmx5IGRldGVjdGVkIGF0IHRoZSBoZWFkLgoKOC4gIElB TkEgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgZG9jdW1lbnQgaGFzIG5vIGFjdGlvbnMgZm9yIElB TkEuCgo5LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFRoZSBzYW1lIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIGFzIHRob3NlIGRlc2NyaWJlZCBpbiBbUkZDNTg4MF0gYW5kCiAgIFtJLUQu aWV0Zi1iZmQtbXVsdGlwb2ludF0gYXBwbHkgdG8gdGhpcyBkb2N1bWVudC4KCiAgIEFkZGl0aW9u YWxseSwgaW1wbGVtZW50YXRpb25zIHRoYXQgY3JlYXRlIE11bHRwb2ludENsaWVudCBzZXNzaW9u cwogICBkeW5hbWljYWxseSB1cG9uIHJlY2VpcHQgb2YgQkZEIENvbnRyb2wgcGFja2V0IGZyb20g YSB0YWlsIE1VU1QKICAgaW1wbGVtZW50IHByb3RlY3RpdmUgbWVhc3VyZXMgdG8gcHJldmVudCBh biBpbmZpbml0ZSBudW1iZXIgb2YKICAgTXVsdGlwb2ludENsaWVudCBzZXNzaW9ucyBiZWluZyBj cmVhdGVkLiAgQmVsb3cgYXJlIGxpc3RlZCBzb21lCiAgIHBvaW50cyB0byBiZSBjb25zaWRlcmVk IGluIHN1Y2ggaW1wbGVtZW50YXRpb25zLgoKICAgICAgV2hlbiB0aGUgbnVtYmVyIG9mIE11bHRp cG9pbnRDbGllbnQgc2Vzc2lvbnMgZXhjZWVkcyB0aGUgbnVtYmVyIG9mCiAgICAgIGV4cGVjdGVk IHRhaWxzLCB0aGVuIHRoZSBpbXBsZW1lbnRhdGlvbiBzaG91bGQgZ2VuZXJhdGUgYW4gYWxhcm0K ICAgICAgdG8gdXNlcnMgdG8gaW5kaWNhdGUgdGhlIGFub21hbHkuCgogICAgICBUaGUgaW1wbGVt ZW50YXRpb24gc2hvdWxkIGhhdmUgYSByZWFzb25hYmxlIHVwcGVyIGJvdW5kIG9uIHRoZQogICAg ICBudW1iZXIgb2YgTXVsdGlwb2ludENsaWVudCBzZXNzaW9ucyB0aGF0IGNhbiBiZSBjcmVhdGVk LCB3aXRoIHRoZQogICAgICB1cHBlciBib3VuZCBwb3RlbnRpYWxseSBiZWluZyBjb21wdXRlZCBi YXNlZCBvbiB0aGUgbnVtYmVyIG9mCiAgICAgIG11bHRpY2FzdCBzdHJlYW1zIHRoYXQgdGhlIHN5 c3RlbSBpcyBleHBlY3RpbmcuCgogICBUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgcmFpc2Ug YW55IGFkZGl0aW9uYWwgc2VjdXJpdHkgaXNzdWVzCiAgIGJleW9uZCB0aG9zZSBvZiB0aGUgc3Bl Y2lmaWNhdGlvbnMgcmVmZXJyZWQgdG8gaW4gdGhlIGxpc3Qgb2YKICAgbm9ybWF0aXZlIHJlZmVy ZW5jZXMuCgoxMC4gIENvbnRyaWJ1dG9ycwoKICAgUmFodWwgQWdnYXJ3YWwgb2YgSnVuaXBlciBO ZXR3b3JrcyBhbmQgR2VvcmdlIFN3YWxsb3cgb2YgQ2lzY28KICAgU3lzdGVtcyBwcm92aWRlZCB0 aGUgaW5pdGlhbCBpZGVhIGZvciB0aGlzIHNwZWNpZmljYXRpb24gYW5kCiAgIGNvbnRyaWJ1dGVk IHRvIGl0cyBkZXZlbG9wbWVudC4KCgoKCkthdHosIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMg RGVjZW1iZXIgNiwgMjAxOCAgICAgICAgICAgICAgIFtQYWdlIDE3XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgQkZEIE11bHRpcG9pbnQgQWN0aXZlIFRhaWxzICAgICAgICAgICAgIEp1bmUgMjAx OAoKCjExLiAgQWNrbm93bGVkZ21lbnRzCgogICBBdXRob3JzIHdvdWxkIGFsc28gbGlrZSB0byB0 aGFuayBOb2JvIEFraXlhLCBWZW5nYWRhIFByYXNhZCBHb3ZpbmRhbiwKICAgSmVmZiBIYWFzLCBX aW0gSGVuZGVyaWNreCwgR3JlZ29yeSBNaXJza3kgYW5kIE1pbmd1aSBaaGFuZyB3aG8gaGF2ZQog ICBncmVhdGx5IGNvbnRyaWJ1dGVkIHRvIHRoaXMgZG9jdW1lbnQuCgoxMi4gIE5vcm1hdGl2ZSBS ZWZlcmVuY2VzCgogICBbSS1ELmlldGYtYmZkLW11bHRpcG9pbnRdCiAgICAgICAgICAgICAgS2F0 eiwgRC4sIFdhcmQsIEQuLCBOZXR3b3JrcywgSi4sIGFuZCBHLiBNaXJza3ksICJCRkQgZm9yCiAg ICAgICAgICAgICAgTXVsdGlwb2ludCBOZXR3b3JrcyIsIGRyYWZ0LWlldGYtYmZkLW11bHRpcG9p bnQtMTYgKHdvcmsKICAgICAgICAgICAgICBpbiBwcm9ncmVzcyksIEFwcmlsIDIwMTguCgogICBb UkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRp Y2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTks CiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzIxMTksIE1hcmNoIDE5OTcsCiAgICAgICAg ICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjMjExOT4uCgogICBbUkZD NTg4MF0gIEthdHosIEQuIGFuZCBELiBXYXJkLCAiQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERl dGVjdGlvbgogICAgICAgICAgICAgIChCRkQpIiwgUkZDIDU4ODAsIERPSSAxMC4xNzQ4Ny9SRkM1 ODgwLCBKdW5lIDIwMTAsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3Jn L2luZm8vcmZjNTg4MD4uCgogICBbUkZDNzg4MF0gIFBpZ25hdGFybywgQy4sIFdhcmQsIEQuLCBB a2l5YSwgTi4sIEJoYXRpYSwgTS4sIGFuZCBTLgogICAgICAgICAgICAgIFBhbGxhZ2F0dGksICJT ZWFtbGVzcyBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uCiAgICAgICAgICAgICAg KFMtQkZEKSIsIFJGQyA3ODgwLCBET0kgMTAuMTc0ODcvUkZDNzg4MCwgSnVseSAyMDE2LAogICAg ICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc4ODA+LgoKICAg W1JGQzgxNzRdICBMZWliYSwgQi4sICJBbWJpZ3VpdHkgb2YgVXBwZXJjYXNlIHZzIExvd2VyY2Fz ZSBpbiBSRkMKICAgICAgICAgICAgICAyMTE5IEtleSBXb3JkcyIsIEJDUCAxNCwgUkZDIDgxNzQs IERPSSAxMC4xNzQ4Ny9SRkM4MTc0LAogICAgICAgICAgICAgIE1heSAyMDE3LCA8aHR0cHM6Ly93 d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM4MTc0Pi4KCkF1dGhvcnMnIEFkZHJlc3NlcwoKICAg RGF2ZSBLYXR6CiAgIEp1bmlwZXIgTmV0d29ya3MKICAgMTE5NCBOLiBNYXRoaWxkYSBBdmUuCiAg IFN1bm55dmFsZSwgQ2FsaWZvcm5pYSAgOTQwODktMTIwNgogICBVU0EKCiAgIEVtYWlsOiBka2F0 ekBqdW5pcGVyLm5ldAoKCgoKCgoKCgoKCkthdHosIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMg RGVjZW1iZXIgNiwgMjAxOCAgICAgICAgICAgICAgIFtQYWdlIDE4XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgQkZEIE11bHRpcG9pbnQgQWN0aXZlIFRhaWxzICAgICAgICAgICAgIEp1bmUgMjAx OAoKCiAgIERhdmUgV2FyZAogICBDaXNjbyBTeXN0ZW1zCiAgIDE3MCBXZXN0IFRhc21hbiBEci4K ICAgU2FuIEpvc2UsIENhbGlmb3JuaWEgIDk1MTM0CiAgIFVTQQoKICAgRW1haWw6IHdhcmRkQGNp c2NvLmNvbQoKCiAgIFNhbnRvc2ggUGFsbGFnYXR0aSAoZWRpdG9yKQogICBJbmRpdmlkdWFsIENv bnRyaWJ1dG9yCiAgIEVtYmFzc3kgQnVzaW5lc3MgUGFyawogICBCYW5nYWxvcmUsIEtBICA1NjAw OTMKICAgSW5kaWEKCiAgIEVtYWlsOiBzYW50b3NoLnBhbGxhZ2F0dGlAZ21haWwuY29tCgoKICAg R3JlZyBNaXJza3kgKGVkaXRvcikKICAgWlRFIENvcnAuCgogICBFbWFpbDogZ3JlZ2ltaXJza3lA Z21haWwuY29tCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKS2F0eiwgZXQgYWwuICAgICAg ICAgICAgRXhwaXJlcyBEZWNlbWJlciA2LCAyMDE4ICAgICAgICAgICAgICAgW1BhZ2UgMTldCg== --000000000000b6edba056dd585ed Content-Type: text/html; charset="US-ASCII"; name="Diff_ draft-ietf-bfd-multipoint-active-tail-07.txt - draft-ietf-bfd-multipoint-active-tail-08.txt.html" Content-Disposition: attachment; filename="Diff_ draft-ietf-bfd-multipoint-active-tail-07.txt - draft-ietf-bfd-multipoint-active-tail-08.txt.html" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ji0mbytf0 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPgo8IS0tIHNhdmVkIGZyb20gdXJsPSgwMDQxKWh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmYvcmZjZGlmZi5weWh0IC0tPgo8aHRtbCB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS94aHRtbCIgY2xhc3M9ImdyX19pZXRmX29yZyI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29u dGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPiAKICAgCiAgPG1l dGEgaHR0cC1lcXVpdj0iQ29udGVudC1TdHlsZS1UeXBlIiBjb250ZW50PSJ0ZXh0L2NzcyI+IAog IDx0aXRsZT5EaWZmOiBkcmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50LWFjdGl2ZS10YWlsLTA3LnR4 dCAtIGRyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQtYWN0aXZlLXRhaWwtMDgudHh0PC90aXRsZT4g CiAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4gCiAgICBib2R5ICAgIHsgbWFyZ2luOiAwLjRleDsg bWFyZ2luLXJpZ2h0OiBhdXRvOyB9IAogICAgdHIgICAgICB7IH0gCiAgICB0ZCAgICAgIHsgd2hp dGUtc3BhY2U6IHByZTsgZm9udC1mYW1pbHk6IG1vbm9zcGFjZTsgdmVydGljYWwtYWxpZ246IHRv cDsgZm9udC1zaXplOiAwLjg2ZW07fSAKICAgIHRoICAgICAgeyBmb250LXNpemU6IDAuODZlbTsg fSAKICAgIC5zbWFsbCAgeyBmb250LXNpemU6IDAuNmVtOyBmb250LXN0eWxlOiBpdGFsaWM7IGZv bnQtZmFtaWx5OiBWZXJkYW5hLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IH0gCiAgICAubGVmdCAg IHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5yaWdodCAgeyBiYWNrZ3JvdW5kLWNv bG9yOiAjRkZGOyB9IAogICAgLmRpZmYgICB7IGJhY2tncm91bmQtY29sb3I6ICNDQ0Y7IH0gCiAg ICAubGJsb2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0JGQjsgfSAKICAgIC5yYmxvY2sgeyBiYWNr Z3JvdW5kLWNvbG9yOiAjRkY4OyB9IAogICAgLmluc2VydCB7IGJhY2tncm91bmQtY29sb3I6ICM4 RkY7IH0gCiAgICAuZGVsZXRlIHsgYmFja2dyb3VuZC1jb2xvcjogI0FDRjsgfSAKICAgIC52b2lk ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZCOyB9IAogICAgLmNvbnQgICB7IGJhY2tncm91bmQt Y29sb3I6ICNFRUU7IH0gCiAgICAubGluZWJyIHsgYmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSAK ICAgIC5saW5lbm8geyBjb2xvcjogcmVkOyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZGOyBmb250LXNp emU6IDAuN2VtOyB0ZXh0LWFsaWduOiByaWdodDsgcGFkZGluZzogMCAycHg7IH0gCiAgICAuZWxp cHNpc3sgYmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSAKICAgIC5sZWZ0IC5jb250IHsgYmFja2dy b3VuZC1jb2xvcjogI0RERDsgfSAKICAgIC5yaWdodCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6 ICNFRUU7IH0gCiAgICAubGJsb2NrIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogIzlEOTsgfSAK ICAgIC5yYmxvY2sgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjREQ2OyB9IAogICAgLmluc2Vy dCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICMwREQ7IH0gCiAgICAuZGVsZXRlIC5jb250IHsg YmFja2dyb3VuZC1jb2xvcjogIzhBRDsgfSAKICAgIC5zdGF0cywgLnN0YXRzIHRkLCAuc3RhdHMg dGggeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyBwYWRkaW5nOiAycHggMDsgfSAKICAgIHNwYW4u aGlkZSB7IGRpc3BsYXk6IG5vbmU7IGNvbG9yOiAjYWFhO30gICAgYTpob3ZlciBzcGFuIHsgZGlz cGxheTogaW5saW5lOyB9ICAgIHRyLmNoYW5nZSB7IGJhY2tncm91bmQtY29sb3I6IGdyYXk7IH0g CiAgICB0ci5jaGFuZ2UgYSB7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgY29sb3I6IGJsYWNrIH0g CiAgPC9zdHlsZT4gCiAgICAgPHNjcmlwdD4KdmFyIGNodW5rX2luZGV4ID0gMDsKdmFyIG9sZF9j aHVuayA9IG51bGw7CgpmdW5jdGlvbiBmb3JtYXRfY2h1bmsoaW5kZXgpIHsKICAgIHZhciBwcmVm aXggPSAiZGlmZiI7CiAgICB2YXIgc3RyID0gaW5kZXgudG9TdHJpbmcoKTsKICAgIGZvciAoeD0w OyB4PCg0LXN0ci5sZW5ndGgpOyArK3gpIHsKICAgICAgICBwcmVmaXgrPScwJzsKICAgIH0KICAg IHJldHVybiBwcmVmaXggKyBzdHI7Cn0KCmZ1bmN0aW9uIGZpbmRfY2h1bmsobil7CiAgICByZXR1 cm4gZG9jdW1lbnQucXVlcnlTZWxlY3RvcigndHJbaWQkPSInICsgbiArICciXScpOwp9CgpmdW5j dGlvbiBjaGFuZ2VfY2h1bmsob2Zmc2V0KSB7CiAgICB2YXIgaW5kZXggPSBjaHVua19pbmRleCAr IG9mZnNldDsKICAgIHZhciBuZXdfc3RyOwogICAgdmFyIG5ld19jaHVuazsKCiAgICBuZXdfc3Ry ID0gZm9ybWF0X2NodW5rKGluZGV4KTsKICAgIG5ld19jaHVuayA9IGZpbmRfY2h1bmsobmV3X3N0 cik7CiAgICBpZiAoIW5ld19jaHVuaykgewogICAgICAgIHJldHVybjsKICAgIH0KICAgIGlmIChv bGRfY2h1bmspIHsKICAgICAgICBvbGRfY2h1bmsuc3R5bGUub3V0bGluZSA9ICIiOwogICAgfQog ICAgb2xkX2NodW5rID0gbmV3X2NodW5rOwogICAgb2xkX2NodW5rLnN0eWxlLm91dGxpbmUgPSAi MXB4IHNvbGlkIHJlZCI7CiAgICB3aW5kb3cubG9jYXRpb24ucmVwbGFjZSgiIyIgKyBuZXdfc3Ry KQogICAgd2luZG93LnNjcm9sbEJ5KDAsLTEwMCk7CiAgICBjaHVua19pbmRleCA9IGluZGV4Owp9 Cgpkb2N1bWVudC5vbmtleWRvd24gPSBmdW5jdGlvbihlKSB7CiAgICBzd2l0Y2ggKGUua2V5Q29k ZSkgewogICAgY2FzZSA3ODoKICAgICAgICBjaGFuZ2VfY2h1bmsoMSk7CiAgICAgICAgYnJlYWs7 CiAgICBjYXNlIDgwOgogICAgICAgIGNoYW5nZV9jaHVuaygtMSk7CiAgICAgICAgYnJlYWs7CiAg ICB9Cn07CiAgIDwvc2NyaXB0PiAKPC9oZWFkPiAKPGJvZHkgZGF0YS1nci1jLXMtbG9hZGVkPSJ0 cnVlIj4gCiAgPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIw Ij4gCiAgPHRib2R5Pjx0ciBpZD0icGFydC0xIiBiZ2NvbG9yPSJvcmFuZ2UiPjx0aD48L3RoPjx0 aD48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1i ZmQtbXVsdGlwb2ludC1hY3RpdmUtdGFpbC0wNy50eHQiIHN0eWxlPSJjb2xvcjojMDA4OyB0ZXh0 LWRlY29yYXRpb246bm9uZTsiPiZsdDs8L2E+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQtYWN0aXZlLXRhaWwtMDcudHh0 IiBzdHlsZT0iY29sb3I6IzAwOCI+ZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludC1hY3RpdmUtdGFp bC0wNy50eHQ8L2E+Jm5ic3A7PC90aD48dGg+IDwvdGg+PHRoPiZuYnNwOzxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50LWFjdGl2ZS10 YWlsLTA4LnR4dCIgc3R5bGU9ImNvbG9yOiMwMDgiPmRyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQt YWN0aXZlLXRhaWwtMDgudHh0PC9hPiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMT1kcmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50LWFjdGl2ZS10YWlsLTA4LnR4 dCIgc3R5bGU9ImNvbG9yOiMwMDg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Jmd0OzwvYT48L3Ro Pjx0aD48L3RoPjwvdHI+IAogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRC4gS2F0ejwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgRC4gS2F0ejwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+SW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdW5pcGVy IE5ldHdvcmtzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+SW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdW5pcGVyIE5ldHdvcmtz PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDAx Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPlVwZGF0ZXM6IDxzcGFuIGNsYXNzPSJkZWxldGUiPjU4ODAsIDc4ODAgKGlm IGFwcHJvdmVkKTwvc3Bhbj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEQuIFdhcmQ8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+VXBkYXRlczogPHNwYW4gY2xhc3M9Imlu c2VydCI+WFhYWCAoUkZDIEJGRCBmb3IgTXVsdGktcG9pbnQ8L3NwYW4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgRC4gV2FyZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj5JbnRlbmRl ZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzcGFu IGNsYXNzPSJkZWxldGUiPkNpc2NvIFN5c3RlbXM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgICAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPk5ldHdvcmtzKSAoaWYg YXBwcm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2lzY28gU3lzdGVtczwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+RXhwaXJl czogQXVndXN0IDI1LCAyMDE4PC9zcGFuPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFMu IFBhbGxhZ2F0dGksIEVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj5JbnRlbmRl ZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICBTLiBQYWxsYWdh dHRpLCBFZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJbmRpdmlkdWFsIENvbnRyaWJ1dG9yPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPkV4cGly ZXM6IERlY2VtYmVyIDYsIDIwMTg8L3NwYW4+ICAgICAgICAgICAgICAgICAgICAgICAgIEluZGl2 aWR1YWwgQ29udHJpYnV0b3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHLiBNaXJza3ks IEVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHLiBNaXJza3ksIEVkLjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWlRFIENvcnAuPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgWlRFIENvcnAuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDAyIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3BhbiBjbGFzcz0iZGVs ZXRlIj5GZWJydWFyeSAyMTwvc3Bhbj4sIDIwMTg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgSnVuZSA0PC9zcGFuPiwgMjAxODwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgQkZEIE11bHRp cG9pbnQgQWN0aXZlIFRhaWxzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg ICAgICAgICAgICAgICAgICBCRkQgTXVsdGlwb2ludCBBY3RpdmUgVGFpbHMuPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDAzIj48dGQ+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50LWFjdGl2ZS10YWlsLTA8 c3BhbiBjbGFzcz0iZGVsZXRlIj43PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludC1hY3RpdmUtdGFp bC0wPHNwYW4gY2xhc3M9Imluc2VydCI+ODwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+QWJzdHJhY3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5BYnN0cmFj dDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRp ZmYwMDA0Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFjdGl2ZSB0YWls IGV4dGVuc2lvbnMgdG8gdGhlIEJpZGlyZWN0aW9uYWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYWN0aXZlIHRhaWwgZXh0ZW5zaW9u cyB0byA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hbmQgdXBkYXRlczwvc3Bhbj4gdGhlPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIHByb3Rv Y29sIGZvciBtdWx0aXBvaW50IDxzcGFuIGNsYXNzPSJkZWxldGUiPmFuZCBtdWx0aWNhc3Q8L3Nw YW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIEJpZGlyZWN0aW9uYWwgRm9y d2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgcHJvdG9jb2wgZm9yIG11bHRpcG9pbnQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG5ldHdvcmtzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIG5ldHdvcmtzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHIgaWQ9ImRpZmYwMDA1Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUi PlJlcXVpcmVtZW50cyBMYW5ndWFnZTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUi Pjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIFRoZSBrZXkgd29yZHMgIk1V U1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiw8L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAi UkVDT01NRU5ERUQiLCAiTk9UIFJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZDwvc3Bhbj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUg dG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIEJDUDwvc3Bhbj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFu IGNsYXNzPSJkZWxldGUiPiAgIDE0IFtSRkMyMTE5XSBbUkZDODE3NF0gd2hlbiwgYW5kIG9ubHkg d2hlbiwgdGhleSBhcHBlYXIgaW4gYWxsPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0 ZSI+ICAgY2FwaXRhbHMsIGFzIHNob3duIGhlcmUuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPlN0YXR1cyBvZiBUaGlzIE1lbW88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij5TdGF0dXMgb2YgVGhpcyBNZW1vPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ug d2l0aCB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIEludGVybmV0 LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5Ljwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFu ZCBCQ1AgNzkuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEludGVybmV0LURy YWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3Jr aW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3Vw cyBtYXkgYWxzbyBkaXN0cmlidXRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg VGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3Ry aWJ1dGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFz IEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQt RHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC08L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIERyYWZ0cyBpcyBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Ry YWZ0cy9jdXJyZW50Ly48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBEcmFmdHMg aXMgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQg ZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRoczwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRz IHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRoczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90 aGVyIGRvY3VtZW50cyBhdCBhbnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBh bmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1l bnRzIGF0IGFueTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGltZS4gIEl0IGlzIGlu YXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2U8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1 c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJv Z3Jlc3MuIjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG1hdGVyaWFsIG9yIHRv IGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiI8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwNiI+PHRkPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIDxzcGFuIGNsYXNzPSJk ZWxldGUiPkF1Z3VzdCAyNTwvc3Bhbj4sIDIwMTguPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gPHNwYW4gY2xhc3M9 Imluc2VydCI+RGVjZW1iZXIgNjwvc3Bhbj4sIDIwMTguPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPkNvcHlyaWdodCBOb3RpY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij5Db3B5cmlnaHQgTm90aWNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENv cHlyaWdodCAoYykgMjAxOCBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFz IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENvcHlyaWdodCAoYykgMjAx OCBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2 ZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZG9jdW1lbnQgYXV0aG9ycy4g IEFsbCByaWdodHMgcmVzZXJ2ZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3Mg TGVnYWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IGlz IHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRz PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0 byBJRVRGIERvY3VtZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKGh0dHBzOi8v dHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIChodHRwczovL3RydXN0ZWUuaWV0Zi5v cmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2Y8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2 aWV3IHRoZXNlIGRvY3VtZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHB1 YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50 czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2Ny aWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIg cmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBm cm9tIHRoaXMgZG9jdW1lbnQgbXVzdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBk b2N1bWVudCBtdXN0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbmNsdWRlIFNpbXBs aWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2Y8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExp Y2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2Y8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlk ZWQgd2l0aG91dCB3YXJyYW50eSBhczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJy YW50eSBhczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGVzY3JpYmVkIGluIHRoZSBT aW1wbGlmaWVkIEJTRCBMaWNlbnNlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+VGFibGUgb2YgQ29udGVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij5UYWJsZSBvZiBDb250ZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAxLiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAx LiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgIDM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBp ZD0iZGlmZjAwMDciPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgMi4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPk92ZXJ2 aWV3PC9zcGFuPiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgMzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAyLiAgPHNwYW4g Y2xhc3M9Imluc2VydCI+VGVybWlub2xvZ3kgYW5kIEFjcm9ueW1zICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPjMuPC9zcGFuPiAgT3BlcmF0aW9uYWwgU2NlbmFy aW9zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgMy4gIEtleXdv cmRzPC9zcGFuPiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgMzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgIDxzcGFuIGNsYXNz PSJkZWxldGUiPjMuMS48L3NwYW4+ICBObyBIZWFkIE5vdGlmaWNhdGlvbiAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj40PC9zcGFuPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij40 LiAgT3ZlcnZpZXcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgIDQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNs YXNzPSJkZWxldGUiPiAgICAgMy4yLiAgVW5yZWxpYWJsZTwvc3Bhbj4gSGVhZCBOb3RpZmljYXRp b24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgNS48L3NwYW4+ICBPcGVyYXRpb25h bCBTY2VuYXJpb3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPjMu My4gIFNlbWktcmVsaWFibGU8L3NwYW4+IEhlYWQgTm90aWZpY2F0aW9uIDxzcGFuIGNsYXNzPSJk ZWxldGUiPmFuZCBUYWlsIFNvbGljaXRhdGlvbjwvc3Bhbj4gLiAuICAgNTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjUuMS48L3NwYW4+ ICBObyBIZWFkIE5vdGlmaWNhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij41PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPjMuNC4gIFJlbGlhYmxlPC9zcGFuPiBI ZWFkIE5vdGlmaWNhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBj bGFzcz0iZGVsZXRlIj41PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48 c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgIDUuMi48L3NwYW4+ICBIZWFkIE5vdGlmaWNhdGlvbiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAu IC48L3NwYW4+ICAgNTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0i ZGVsZXRlIj4gICA0Ljwvc3Bhbj4gIFByb3RvY29sIERldGFpbHMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj42PC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgPHNwYW4gY2xhc3M9Imlu c2VydCI+NS4yLjEuPC9zcGFuPiAgSGVhZCBOb3RpZmljYXRpb24gPHNwYW4gY2xhc3M9Imluc2Vy dCI+V2l0aG91dCBQb2xsaW5nIC4gLiAuIC4gLiAuIC4gLjwvc3Bhbj4gLiAuICAgNTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgIDQuMS48L3Nw YW4+ICBNdWx0aXBvaW50IENsaWVudCBTZXNzaW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICA3PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICA8c3BhbiBj bGFzcz0iaW5zZXJ0Ij41LjIuMi48L3NwYW4+ICBIZWFkIE5vdGlmaWNhdGlvbiA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij5hbmQgVGFpbCBTb2xpY2l0YXRpb24gd2l0aDwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgICA8c3BhbiBjbGFzcz0iZGVsZXRlIj40LjIuPC9zcGFuPiAg TXVsdGlwb2ludCBDbGllbnQgU2Vzc2lvbiBGYWlsdXJlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Nzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICAgTXVsdGlwb2ludCBQ b2xsaW5nPC9zcGFuPiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9 Imluc2VydCI+LiAuICAgNjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNw YW4gY2xhc3M9ImRlbGV0ZSI+ICAgICA0LjMuPC9zcGFuPiAgU3RhdGUgVmFyaWFibGVzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9ImRlbGV0 ZSI+Nzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+ICAgICAgIDUuMi4zLiAgSGVhZCBOb3RpZmljYXRpb24gd2l0aCBDb21wb3NpdGUg UG9sbGluZyAgLiAuIC4gLiAuIC4gICA2PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgICAgNC4zLjEuPC9zcGFuPiAgTmV3IFN0YXRl IFZhcmlhYmxlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFz cz0iZGVsZXRlIj43PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh biBjbGFzcz0iaW5zZXJ0Ij4gICA2Ljwvc3Bhbj4gIFByb3RvY29sIERldGFpbHMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0 Ij43PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVs ZXRlIj4gICAgICAgNC4zLjIuPC9zcGFuPiAgTmV3IFN0YXRlIFZhcmlhYmxlIFZhbHVlICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj44PC9zcGFuPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAg IDYuMS48L3NwYW4+ICBNdWx0aXBvaW50IENsaWVudCBTZXNzaW9uIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICA3PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNs YXNzPSJkZWxldGUiPiAgICAgICA0LjMuMy48L3NwYW4+ICBTdGF0ZSBWYXJpYWJsZSBJbml0aWFs aXphdGlvbiBhbmQgTWFpbnRlbmFuY2UgLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPjg8 L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgPHNwYW4gY2xhc3M9 Imluc2VydCI+Ni4yLjwvc3Bhbj4gIE11bHRpcG9pbnQgQ2xpZW50IFNlc3Npb24gRmFpbHVyZSAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjg8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgNC40 Ljwvc3Bhbj4gIENvbnRyb2xsaW5nIE11bHRpcG9pbnQgQkZEIE9wdGlvbnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPjk8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgNi4zLjwvc3Bhbj4g IFN0YXRlIFZhcmlhYmxlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjg8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgNC41Ljwvc3Bhbj4gIFN0YXRlIE1hY2hp bmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xh c3M9ImRlbGV0ZSI+MTA8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICA2LjMuMS48L3NwYW4+ICBOZXcgU3RhdGUgVmFyaWFi bGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJpbnNl cnQiPjg8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJk ZWxldGUiPiAgICAgNC42Ljwvc3Bhbj4gIFNlc3Npb24gRXN0YWJsaXNobWVudCAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTA8L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg ICAgICA2LjMuMi48L3NwYW4+ICBOZXcgU3RhdGUgVmFyaWFibGUgVmFsdWUgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjk8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgNC43Ljwvc3Bh bj4gIERpc2NyaW1pbmF0b3JzIGFuZCBQYWNrZXQgRGVtdWx0aXBsZXhpbmcgIC4gLiAuIC4gLiAu IC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTA8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICA2LjMuMy48L3NwYW4+ICBT dGF0ZSBWYXJpYWJsZSBJbml0aWFsaXphdGlvbiBhbmQgTWFpbnRlbmFuY2UgLiAuIC4gLiAgIDxz cGFuIGNsYXNzPSJpbnNlcnQiPjk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgNC44Ljwvc3Bhbj4gIENvbnRyb2xsaW5nIFRhaWwg UGFja2V0IFRyYW5zbWlzc2lvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRl bGV0ZSI+MTE8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgICAgNi40Ljwvc3Bhbj4gIENvbnRyb2xsaW5nIE11bHRpcG9pbnQgQkZE IE9wdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+MTA8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUi PiAgICAgNC45Ljwvc3Bhbj4gIFNvbGljaXRpbmcgdGhlIFRhaWxzICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTE8L3NwYW4+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgNi41 Ljwvc3Bhbj4gIFN0YXRlIE1hY2hpbmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+MTE8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgNC4xMC48L3NwYW4+IFZl cmlmeWluZyBDb25uZWN0aXZpdHkgdG8gU3BlY2lmaWMgVGFpbHMgIC4gLiAuIC4gLiAuIC4gLiAg PHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTI8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgNi42Ljwvc3Bhbj4gIFNlc3Npb24gRXN0 YWJsaXNobWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xh c3M9Imluc2VydCI+MTE8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFu IGNsYXNzPSJkZWxldGUiPiAgICAgNC4xMS48L3NwYW4+IERldGVjdGlvbiBUaW1lcyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ MTM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgICAgNi43Ljwvc3Bhbj4gIERpc2NyaW1pbmF0b3JzIGFuZCBQYWNrZXQgRGVtdWx0 aXBsZXhpbmcgIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+MTE8L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAg NC4xMi48L3NwYW4+IE11bHRpcG9pbnRDbGllbnQgRG93bi9BZG1pbkRvd24gU2Vzc2lvbnMgIC4g LiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTM8L3NwYW4+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgNi44Ljwvc3Bh bj4gIENvbnRyb2xsaW5nIFRhaWwgUGFja2V0IFRyYW5zbWlzc2lvbiAgLiAuIC4gLiAuIC4gLiAu IC4gLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+MTI8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgNC4xMy48L3NwYW4+IEJhc2UgQkZE IFNwZWNpZmljYXRpb24gVGV4dCBSZXBsYWNlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+MTM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgNi45Ljwvc3Bhbj4gIFNvbGljaXRpbmcgdGhlIFRh aWxzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imlu c2VydCI+MTI8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNz PSJkZWxldGUiPiAgICAgICA0LjEzLjEuPC9zcGFuPiAgUmVjZXB0aW9uIG9mIEJGRCBDb250cm9s IFBhY2tldHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTQ8L3Nw YW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgICAgNi4xMC48L3NwYW4+IFZlcmlmeWluZyBDb25uZWN0aXZpdHkgdG8gU3BlY2lmaWMgVGFp bHMgIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+MTM8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICA0LjEz LjIuPC9zcGFuPiAgRGVtdWx0aXBsZXhpbmcgQkZEIENvbnRyb2wgUGFja2V0cyAuIC4gLiAuIC4g LiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTQ8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgNi4xMS48L3NwYW4+IERl dGVjdGlvbiBUaW1lcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg PHNwYW4gY2xhc3M9Imluc2VydCI+MTQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICA0LjEzLjMuPC9zcGFuPiAgVHJhbnNtaXR0 aW5nIEJGRCBDb250cm9sIFBhY2tldHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+MTU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu IGNsYXNzPSJpbnNlcnQiPiAgICAgNi4xMi48L3NwYW4+IE11bHRpcG9pbnRDbGllbnQgRG93bi9B ZG1pbkRvd24gU2Vzc2lvbnMgIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+ MTQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxl dGUiPiAgIDUuPC9zcGFuPiAgQXNzdW1wdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTU8L3NwYW4+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAg Ni4xMy48L3NwYW4+IEJhc2UgQkZEIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmZvciBNdWx0aXBvaW50 IE5ldHdvcmtzPC9zcGFuPiBTcGVjaWZpY2F0aW9uIFRleHQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgNi48L3NwYW4+ICBJQU5BIENvbnNpZGVy YXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBj bGFzcz0iZGVsZXRlIj4xNjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgICAgICAgICBSZXBsYWNlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE0PC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICA3Ljwvc3Bhbj4gIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDxzcGFuIGNsYXNzPSJkZWxldGUiPjE2PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgNi4xMy4xLjwvc3Bhbj4gIFJlY2Vw dGlvbiBvZiBCRkQgQ29udHJvbCBQYWNrZXRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNs YXNzPSJpbnNlcnQiPjE1PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3Bh biBjbGFzcz0iZGVsZXRlIj4gICA4Ljwvc3Bhbj4gIENvbnRyaWJ1dG9ycyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUi PjE2PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICAgICAgNi4xMy4yLjwvc3Bhbj4gIERlbXVsdGlwbGV4aW5nIEJGRCBDb250cm9s IFBhY2tldHMgLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjE1PC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICA5 LiAgQWNrbm93bGVkZ2VtZW50czwvc3Bhbj4gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjE2PC9zcGFuPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgNi4xMy4z Ljwvc3Bhbj4gIFRyYW5zbWl0dGluZyBCRkQgQ29udHJvbCBQYWNrZXRzIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjE2PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAxMC48L3NwYW4+IE5vcm1hdGl2ZSBS ZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFu IGNsYXNzPSJkZWxldGUiPjE2PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICA3Ljwvc3Bhbj4gIEFzc3VtcHRpb25zIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJp bnNlcnQiPjE2PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBBdXRob3Jz JyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTc8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIDguPC9zcGFuPiAgSUFOQSBDb25zaWRl cmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4g Y2xhc3M9Imluc2VydCI+MTc8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICA5 Ljwvc3Bhbj4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjE3PC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+ICAgMTAuPC9zcGFuPiBDb250cmlidXRvcnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4xNzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIDExLiBBY2tub3dsZWRn bWVudHM8L3NwYW4+IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g PHNwYW4gY2xhc3M9Imluc2VydCI+LiAgMTg8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4gICAxMi48L3NwYW4+IE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjE4PC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjE4PC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4xLiAgSW50cm9kdWN0aW9uPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+MS4gIEludHJvZHVjdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBUaGlzIGFwcGxpY2F0aW9uIG9mIEJGRCBpcyBhbiBleHRlbnNpb24gdG8g TXVsdGlwb2ludCBCRkQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGFw cGxpY2F0aW9uIG9mIEJGRCBpcyBhbiBleHRlbnNpb24gdG8gTXVsdGlwb2ludCBCRkQ8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDgiPjx0ZD48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgW0ktRC5pZXRmLWJmZC1tdWx0aXBvaW50XSwgd2hpY2ggYWxsb3dzIHRhaWxzIHRv IDxzcGFuIGNsYXNzPSJkZWxldGUiPnVucmVsaWFibHk8L3NwYW4+IG5vdGlmeTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBbSS1ELmlldGYtYmZkLW11bHRpcG9pbnRdLCB3aGlj aCBhbGxvd3MgdGFpbHMgdG8gbm90aWZ5IHRoZSBoZWFkIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgIHRoZSBoZWFkIG9mIHRoZSBsYWNrIG9mIG11bHRpcG9pbnQgY29ubmVjdGl2 aXR5LiAgQXMgYSBmdXJ0aGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHRo ZSBsYWNrIG9mIG11bHRpcG9pbnQgY29ubmVjdGl2aXR5LiAgQXMgYSBmdXJ0aGVyIG9wdGlvbiwg PHNwYW4gY2xhc3M9Imluc2VydCI+aGVhZHM8L3NwYW4+IGNhbjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICBvcHRpb24sIDxzcGFuIGNsYXNzPSJkZWxldGUiPnRoaXMgbm90aWZpY2F0 aW9uPC9zcGFuPiBjYW4gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+YmUgbWFkZSByZWxpYWJsZS48L3Nw YW4+ICBOb3RpZmljYXRpb24gdG8gdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnJlcXVlc3QgYSBub3RpZmljYXRpb24gZnJvbSB0aGUg dGFpbHMgYnkgbWVhbnMgb2YgYSBwb2xsaW5nPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICBoZWFkIGNhbiBiZSBlbmFibGVkIGZvciBhbGwgdGFpbHMsIG9yIGZvciBvbmx5 IGEgc3Vic2V0IG9mIHRoZSB0YWlscy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgbWVjaGFuaXNtLjwvc3Bhbj4gIE5vdGlmaWNhdGlvbiB0 byB0aGUgaGVhZCBjYW4gYmUgZW5hYmxlZCBmb3IgYWxsIHRhaWxzLCBvcjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIGZvciBvbmx5IGEgc3Vic2V0IG9mIHRoZSB0YWlscy48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+TXVsdGlwb2ludCBCRkQg YmFzZSBkb2N1bWVudCBbSS1ELmlldGYtYmZkLW11bHRpcG9pbnRdIGRlc2NyaWJlczwvc3Bhbj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIHByb2NlZHVyZXMgdG8gdmVyaWZ5IG9ubHkg dGhlIGhlYWQtdG8tdGFpbCBjb25uZWN0aXZpdHkgb3ZlciB0aGU8L3NwYW4+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3Bh biBjbGFzcz0iZGVsZXRlIj4gICBtdWx0aXBvaW50IHBhdGguICBBbHRob3VnaCBpdCBtYXkgdXNl IHVuaWNhc3QgcGF0aHMgaW4gYm90aDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUi PiAgIGRpcmVjdGlvbnMsIE11bHRpcG9pbnQgQkZEIGRvZXMgbm90IHZlcmlmeSB0aG9zZSBwYXRo cyAoYW5kIGluIGZhY3Q8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBpdCBp cyBwcmVmZXJhYmxlIGlmIHVuaWNhc3QgcGF0aHMgc2hhcmUgYXMgbGl0dGxlIGZhdGUgd2l0aCB0 aGU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBtdWx0aXBvaW50IHBhdGgg YXMgaXMgZmVhc2libGUsIHNvIHRvIGluY3JlYXNlIHByb2JhYmlsaXR5IG9mPC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgZGVsaXZlcmluZyB0aGUgbm90aWZpY2F0aW9uIGZy b20gdGhlIHRhaWwgdG8gdGhlIGhlYWQpLjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBnb2FsIG9m IHRoaXMgYXBwbGljYXRpb24gaXMgZm9yIHRoZSBoZWFkIHRvIHJlYXNvbmFibHkgcmFwaWRseTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBnb2FsIG9mIHRoaXMgYXBwbGlj YXRpb24gaXMgZm9yIHRoZSBoZWFkIHRvIHJlYXNvbmFibHkgcmFwaWRseTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgaGF2ZSBrbm93bGVkZ2Ugb2YgdGFpbHMgdGhhdCBoYXZlIGxvc3Qg Y29ubmVjdGl2aXR5IGZyb20gdGhlIGhlYWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgaGF2ZSBrbm93bGVkZ2Ugb2YgdGFpbHMgdGhhdCBoYXZlIGxvc3QgY29ubmVjdGl2aXR5 IGZyb20gdGhlIGhlYWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFNpbmNl IHNjYWxpbmcgaXMgYSBwcmltYXJ5IGNvbmNlcm4gKHBhcnRpY3VsYXJseSBzdGF0ZSBleHBsb3Np b248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBTaW5jZSBzY2FsaW5nIGlzIGEg cHJpbWFyeSBjb25jZXJuIChwYXJ0aWN1bGFybHkgc3RhdGUgZXhwbG9zaW9uPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICB0b3dhcmQgdGhlIGhlYWQpLCBpdCBpcyByZXF1aXJlZCB0aGF0 IHRoZSBoZWFkIGJlIGluIGNvbnRyb2wgb2YgYWxsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgdG93YXJkIHRoZSBoZWFkKSwgaXQgaXMgcmVxdWlyZWQgdGhhdCB0aGUgaGVhZCBi ZSBpbiBjb250cm9sIG9mIGFsbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGltaW5n IGFzcGVjdHMgb2YgdGhlIG1lY2hhbmlzbSwgYW5kIHRoYXQgQkZEIHBhY2tldHMgZnJvbSB0aGUg dGFpbHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aW1pbmcgYXNwZWN0cyBv ZiB0aGUgbWVjaGFuaXNtLCBhbmQgdGhhdCBCRkQgcGFja2V0cyBmcm9tIHRoZSB0YWlsczwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdG8gdGhlIGhlYWQgbm90IGJlIHN5bmNocm9uaXpl ZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0byB0aGUgaGVhZCBub3QgYmUg c3luY2hyb25pemVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaHJvdWdo b3V0IHRoaXMgZG9jdW1lbnQsIHRoZSB0ZXJtICJtdWx0aXBvaW50IiBpcyBkZWZpbmVkIGFzIGE8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaHJvdWdob3V0IHRoaXMgZG9jdW1l bnQsIHRoZSB0ZXJtICJtdWx0aXBvaW50IiBpcyBkZWZpbmVkIGFzIGE8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIG1lY2hhbmlzbSBieSB3aGljaCBvbmUgb3IgbW9yZSBzeXN0ZW1zIHJl Y2VpdmUgcGFja2V0cyBzZW50IGJ5IGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBtZWNoYW5pc20gYnkgd2hpY2ggb25lIG9yIG1vcmUgc3lzdGVtcyByZWNlaXZlIHBhY2tldHMg c2VudCBieSBhPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzaW5nbGUgc2VuZGVyLiAg VGhpcyBzcGVjaWZpY2FsbHkgaW5jbHVkZXMgc3VjaCB0aGluZ3MgYXMgSVA8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzaW5nbGUgc2VuZGVyLiAgVGhpcyBzcGVjaWZpY2FsbHkg aW5jbHVkZXMgc3VjaCB0aGluZ3MgYXMgSVA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IG11bHRpY2FzdCBhbmQgcG9pbnQtdG8tbXVsdGlwb2ludCBNUExTLjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIG11bHRpY2FzdCBhbmQgcG9pbnQtdG8tbXVsdGlwb2ludCBNUExT LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRp ZmYwMDA5Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRlcm0gImNvbm5lY3Rpdml0eSIgaW4gdGhpcyBkb2N1bWVu dCBpcyBub3QgYmVpbmcgdXNlZCBpbiBjb250ZXh0IG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIFRlcm0gImNvbm5lY3Rpdml0eSIgaW4gdGhpcyBkb2N1bWVudCBpcyBub3Qg YmVpbmcgdXNlZCBpbiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij50aGU8L3NwYW4+IGNvbnRleHQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgY29ubmVjdGl2aXR5IHZlcmlmaWNhdGlvbiBp biB0cmFuc3BvcnQgbmV0d29yayBidXQgYXMgYW4gYWx0ZXJuYXRpdmU8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgb2YgY29ubmVjdGl2aXR5IHZlcmlmaWNhdGlvbiBpbiB0cmFu c3BvcnQgbmV0d29yayBidXQgYXMgYW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg dG8gImNvbnRpbnVpdHkiLCBpLmUuIGV4aXN0ZW5jZSBvZiBhIHBhdGggYmV0d2VlbiB0aGUgc2Vu ZGVyIGFuZCB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgYWx0ZXJuYXRp dmUgdG8gImNvbnRpbnVpdHkiLCBpLmUuIGV4aXN0ZW5jZSBvZiBhIHBhdGggYmV0d2VlbiB0aGU8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgcmVjZWl2ZXIuPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgIHNlbmRlciBhbmQgdGhlIHJlY2VpdmVyLjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDEwIj48dGQ+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgIFRoaXMgZG9jdW1lbnQgZWZmZWN0aXZlbHkgbW9kaWZpZXMgYW5kIGFkZHMgdG8g PHNwYW4gY2xhc3M9ImRlbGV0ZSI+dGhlIGJhc2UgQkZEPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICBUaGlzIGRvY3VtZW50IGVmZmVjdGl2ZWx5IG1vZGlmaWVzIGFu ZCBhZGRzIHRvIDxzcGFuIGNsYXNzPSJpbnNlcnQiPlNlY3Rpb25zIDUuMTI8L3NwYW4+IGFuZCA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij41LjEzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBzcGVjaWZpY2F0aW9uIFtSRkM1ODgwXTwvc3Bh bj4gYW5kIGJhc2UgQkZEIG11bHRpcG9pbnQgZG9jdW1lbnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgb2YgdGhlPC9zcGFuPiBiYXNlIEJG RCBtdWx0aXBvaW50IGRvY3VtZW50IFtJLUQuaWV0Zi1iZmQtbXVsdGlwb2ludF0uPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFtJLUQuaWV0Zi1iZmQtbXVsdGlwb2ludF0uPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDExIj48dGQ+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjIuICBPdmVydmll dzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4yLiAgPHNwYW4gY2xhc3M9Imluc2Vy dCI+VGVybWlub2xvZ3kgYW5kIEFjcm9ueW1zPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgQkZEIEJpZGlyZWN0 aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb248L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBjLXBvbGwgQ29tcG9z aXRlIFBvbGw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBtLXBvbGwgTXVsdGlwb2ludCBQb2xsPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+My4gIEtleXdvcmRzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgVGhlIGtleSB3b3JkcyAiTVVTVCIs ICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLDwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNP TU1FTkRFRCIsICJOT1QgUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+ICAgIk9QVElPTkFMIiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBi ZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gQkNQPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+ICAgMTQgW1JGQzIxMTldIFtSRkM4MTc0XSB3aGVuLCBhbmQgb25seSB3aGVu LCB0aGV5IGFwcGVhciBpbiBhbGw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICBjYXBpdGFscywgYXMgc2hvd24gaGVyZS48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij40Ljwvc3Bhbj4gIE92ZXJ2 aWV3PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEEgaGVhZCBtYXkgd2lzaCB0 byBiZSBhbGVydGVkIHRvIHRoZSB0YWlscycgY29ubmVjdGl2aXR5IChvciBsYWNrPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQSBoZWFkIG1heSB3aXNoIHRvIGJlIGFsZXJ0ZWQg dG8gdGhlIHRhaWxzJyBjb25uZWN0aXZpdHkgKG9yIGxhY2s8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHRoZXJlb2YpLCB0aGVyZSBhcmUgYSBudW1iZXIgb2Ygb3B0aW9ucy4gIEZpcnN0 LCBpZiBhbGwgdGhhdCBpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZXJl b2YpLCB0aGVyZSBhcmUgYSBudW1iZXIgb2Ygb3B0aW9ucy4gIEZpcnN0LCBpZiBhbGwgdGhhdCBp czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAx MiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICBuZWVkZWQgaXMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+YW4gdW5yZWxp YWJsZTwvc3Bhbj4gZmFpbHVyZSBub3RpZmljYXRpb24sIGFzIGRpc2N1c3NlZCBpbjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBuZWVkZWQgaXMgPHNwYW4gY2xhc3M9Imluc2Vy dCI+YSBiZXN0LWVmZm9ydDwvc3Bhbj4gZmFpbHVyZSBub3RpZmljYXRpb24sIGFzIGRpc2N1c3Nl ZCBpbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBTZWN0aW9uIDxzcGFuIGNsYXNz PSJkZWxldGUiPjMuMiwgdGhlIGhlYWQgY2FuIHJlcXVlc3Q8L3NwYW4+IHRoZSB0YWlscyA8c3Bh biBjbGFzcz0iZGVsZXRlIj50byB0cmFuc21pdDwvc3Bhbj4gdW5pY2FzdCBCRkQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgU2VjdGlvbiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij41 LjIuMSw8L3NwYW4+IHRoZSB0YWlscyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5jYW4gc2VuZCB1bnNv bGljaXRlZDwvc3Bhbj4gdW5pY2FzdCBCRkQgQ29udHJvbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICBDb250cm9sIHBhY2tldHMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+YmFjazwvc3Bh bj4gdG8gdGhlIGhlYWQgd2hlbiB0aGUgcGF0aCBmYWlscywgYXMgZGVzY3JpYmVkIGluPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHBhY2tldHMgdG8gdGhlIGhlYWQgd2hlbiB0 aGUgcGF0aCBmYWlscywgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gPHNwYW4gY2xhc3M9Imluc2Vy dCI+Ni40Ljwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgU2VjdGlvbiA8 c3BhbiBjbGFzcz0iZGVsZXRlIj40LjQuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy IGlkPSJkaWZmMDAxMyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBJZiB0aGUgaGVhZCB3aXNoZXMgdG8ga25vdyA8 c3BhbiBjbGFzcz0iZGVsZXRlIj50aGUgaWRlbnRpdHk8L3NwYW4+IG9mIHRoZSB0YWlscyBvbiB0 aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgSWYgdGhlIGhlYWQgd2lzaGVz IHRvIGtub3cgb2YgdGhlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmFjdGl2ZTwvc3Bhbj4gdGFpbHMg b24gdGhlIG11bHRpcG9pbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgbXVsdGlw b2ludCBwYXRoLCBpdCBtYXkgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+c29saWNpdCBtZW1iZXJzaGlw IGJ5IHNlbmRpbmc8L3NwYW4+IGEgbXVsdGlwb2ludDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICBwYXRoLCBpdCBtYXkgPHNwYW4gY2xhc3M9Imluc2VydCI+c2VuZDwvc3Bhbj4g YSBtdWx0aXBvaW50IEJGRCBDb250cm9sIHBhY2tldCB3aXRoIHRoZSBQb2xsIChQKTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBCRkQgQ29udHJvbCBwYWNrZXQgd2l0aCB0aGUgUG9s bCAoUCkgYml0IHNldCwgd2hpY2ggd2lsbCBpbmR1Y2UgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgIGJpdCBzZXQsIHdoaWNoIHdpbGwgaW5kdWNlIHRoZSB0YWlscyB0byBy ZXR1cm4gYSB1bmljYXN0IEJGRCBDb250cm9sPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIHRhaWxzIHRvIHJldHVybiBhIHVuaWNhc3QgQkZEIENvbnRyb2wgcGFja2V0IHdpdGggdGhl IEZpbmFsIChGKSBiaXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgcGFja2V0 IHdpdGggdGhlIEZpbmFsIChGKSBiaXQgPHNwYW4gY2xhc3M9Imluc2VydCI+c2V0IChkZXRhaWxl ZCBkZXNjcmlwdGlvbiBpbjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg PHNwYW4gY2xhc3M9ImRlbGV0ZSI+c2V0Ljwvc3Bhbj4gIFRoZSBoZWFkIGNhbiB0aGVuIGNyZWF0 ZSBCRkQgc2Vzc2lvbiBzdGF0ZSBmb3IgZWFjaCBvZiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgU2VjdGlvbiA1LjIuMikuPC9zcGFu PiAgVGhlIGhlYWQgY2FuIHRoZW4gY3JlYXRlIEJGRCBzZXNzaW9uIHN0YXRlIGZvciBlYWNoPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHRhaWxzIHRoYXQgaGF2ZSBtdWx0aXBvaW50 IGNvbm5lY3Rpdml0eS4gIElmIHRoZSBoZWFkIHNlbmRzIHN1Y2ggYTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICBvZiB0aGUgdGFpbHMgdGhhdCBoYXZlIG11bHRpcG9pbnQgY29u bmVjdGl2aXR5LiAgSWYgdGhlIGhlYWQgc2VuZHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgcGFja2V0IG9uIG9jY2FzaW9uLCBpdCBjYW4ga2VlcCB0cmFjayBvZiB3aGljaCB0YWls cyBhbnN3ZXIsIHRodXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgc3VjaCBh IHBhY2tldCBvbiBvY2Nhc2lvbiwgaXQgY2FuIGtlZXAgdHJhY2sgb2Ygd2hpY2ggdGFpbHMgYW5z d2VyLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBwcm92aWRpbmcgYSA8c3BhbiBj bGFzcz0iZGVsZXRlIj5zb21ld2hhdCByZWxpYWJsZTwvc3Bhbj4gbWVjaGFuaXNtIGZvciBkZXRl Y3Rpbmcgd2hpY2ggdGFpbHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgdGh1 cyBwcm92aWRpbmcgYSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5tb3JlIGRldGVybWluaXN0aWM8L3Nw YW4+IG1lY2hhbmlzbSBmb3IgZGV0ZWN0aW5nIHdoaWNoPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgIGZhaWwgdG8gcmVzcG9uZCAoaW1wbHlpbmcgYSBsb3NzIG9mIG11bHRpcG9pbnQg Y29ubmVjdGl2aXR5KS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgdGFpbHMg ZmFpbCB0byByZXNwb25kIChpbXBseWluZyBhIGxvc3Mgb2YgbXVsdGlwb2ludCBjb25uZWN0aXZp dHkpLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+SW4gdGhpcyBkb2N1bWVudCB0aGlz IG1ldGhvZCByZWZlcmVuY2VkIHRvIGFzIE11bHRpcG9pbnQgUG9sbDwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPiAgIChtLXBvbGwpLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxNCI+PHRkPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICBJZiB0aGUgaGVhZCB3aXNoZXMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+YSByZWxpYWJsZTwvc3Bh bj4gaW5kaWNhdGlvbiBvZiB0aGUgdGFpbHMnIGNvbm5lY3Rpdml0eSw8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgSWYgdGhlIGhlYWQgd2lzaGVzIDxzcGFuIGNsYXNzPSJpbnNl cnQiPnRoZSBkZWZpbml0ZTwvc3Bhbj4gaW5kaWNhdGlvbiBvZiB0aGUgdGFpbHMnPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGl0IG1heSBkbyBhbGwgb2YgdGhlIGFib3ZlLCBidXQg aWYgaXQgZGV0ZWN0cyB0aGF0IGEgdGFpbCBkaWQgbm90PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIGNvbm5lY3Rpdml0eSwgaXQgbWF5IGRvIGFsbCBvZiB0aGUgYWJvdmUsIGJ1 dCBpZiBpdCBkZXRlY3RzIHRoYXQgYTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBh bnN3ZXIgdGhlIHByZXZpb3VzIG11bHRpcG9pbnQgcG9sbCwgaXQgbWF5IGluaXRpYXRlIGEgRGVt YW5kIG1vZGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgdGFpbCBkaWQgbm90 IGFuc3dlciB0aGUgcHJldmlvdXMgbXVsdGlwb2ludCBwb2xsLCBpdCBtYXkgaW5pdGlhdGUgYTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBQb2xsIFNlcXVlbmNlIGFzIGEgdW5pY2Fz dCB0byB0aGF0IDxzcGFuIGNsYXNzPSJkZWxldGUiPnRhaWwuPC9zcGFuPiAgVGhpcyBjb3ZlcnMg dGhlIGNhc2Ugd2hlcmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgRGVtYW5k IG1vZGUgUG9sbCBTZXF1ZW5jZSBhcyBhIHVuaWNhc3QgdG8gdGhhdCA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij50YWlsIChkZXRhaWxlZDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgZWl0aGVyIHRoZSBtdWx0aXBvaW50IHBvbGwgb3IgdGhlIHNpbmdsZSByZXBseSBhbHNvIGlz IGxvc3QgaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgZGVzY3JpcHRpb24gaW4gU2VjdGlvbiA1LjIuMykuPC9zcGFuPiAgVGhpcyBjb3Zl cnMgdGhlIGNhc2Ugd2hlcmUgZWl0aGVyIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICB0cmFuc2l0LiAgSWYgZGVzaXJlZCwgdGhlIGhlYWQgbWF5IFBvbGwgb25lIG9yIG1vcmUg dGFpbHMgcHJvYWN0aXZlbHk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgbXVs dGlwb2ludCBwb2xsIG9yIHRoZSBzaW5nbGUgcmVwbHkgYWxzbyBpcyBsb3N0IGluIHRyYW5zaXQu ICBJZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB0byB0cmFjayB0aGUgdGFpbHMn IGNvbm5lY3Rpdml0eS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgZGVzaXJl ZCwgdGhlIGhlYWQgbWF5IFBvbGwgb25lIG9yIG1vcmUgdGFpbHMgcHJvYWN0aXZlbHkgdG8gdHJh Y2sgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICB0YWlscycgY29ubmVjdGl2aXR5LiAgPHNwYW4gY2xhc3M9Imluc2Vy dCI+SW4gdGhpcyBkb2N1bWVudCB0aGlzIG1ldGhvZCB0aGF0IGNvbWJpbmVzIHVzZTwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIG9mIG11bHRpcG9pbnQgYW5kIHVuaWNhc3Qg cG9sbGluZyBvZiB0YWlscyBieSB0aGUgaGVhZCByZWZlcmVuY2VkIHRvPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgYXMgQ29tcG9zaXRlIFBvbGwgKGMtcG9sbCkuPC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJZiB0aGUgYXdhcmVuZXNzIG9m IHRoZSBzdGF0ZSBvZiBzb21lIG5vZGVzIGlzIG1vcmUgaW1wb3J0YW50IGZvciB0aGU8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJZiB0aGUgYXdhcmVuZXNzIG9mIHRoZSBzdGF0 ZSBvZiBzb21lIG5vZGVzIGlzIG1vcmUgaW1wb3J0YW50IGZvciB0aGU8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIGhlYWQsIGluIHRoZSBzZW5zZSB0aGF0IHRoZSBoZWFkIG5lZWRzIHRv IGRldGVjdCB0aGUgbGFjayBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGhl YWQsIGluIHRoZSBzZW5zZSB0aGF0IHRoZSBoZWFkIG5lZWRzIHRvIGRldGVjdCB0aGUgbGFjayBv ZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbXVsdGlwb2ludCBjb25uZWN0aXZpdHkg dG8gYSBzdWJzZXQgb2YgdGFpbHMgYXQgYSBkaWZmZXJlbnQgcmF0ZSwgdGhlPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbXVsdGlwb2ludCBjb25uZWN0aXZpdHkgdG8gYSBzdWJz ZXQgb2YgdGFpbHMgYXQgYSBkaWZmZXJlbnQgcmF0ZSwgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBoZWFkIG1heSB0cmFuc21pdCB1bmljYXN0IEJGRCBQb2xscyB0byB0aGF0IHN1 YnNldCBvZiB0YWlscy4gIEluIHRoaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBoZWFkIG1heSB0cmFuc21pdCB1bmljYXN0IEJGRCBQb2xscyB0byB0aGF0IHN1YnNldCBvZiB0 YWlscy4gIEluIHRoaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNhc2UsIHRoZSB0 aW1pbmcgbWF5IGJlIGluZGVwZW5kZW50IG9uIGEgdGFpbC1ieS10YWlsIGJhc2lzLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNhc2UsIHRoZSB0aW1pbmcgbWF5IGJlIGluZGVw ZW5kZW50IG9uIGEgdGFpbC1ieS10YWlsIGJhc2lzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBJbmRpdmlkdWFsIHRhaWxzIG1heSBiZSBjb25maWd1cmVkIHNvIHRoYXQgdGhl eSBuZXZlciBzZW5kIEJGRDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEluZGl2 aWR1YWwgdGFpbHMgbWF5IGJlIGNvbmZpZ3VyZWQgc28gdGhhdCB0aGV5IG5ldmVyIHNlbmQgQkZE PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDE1 Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIGNvbnRyb2wgcGFja2V0cyB0byB0aGUgPHNwYW4gY2xhc3M9ImRlbGV0 ZSI+aGVhZCwgZXZlbiB3aGVuIHRoZSBoZWFkIHdpc2hlcyBub3RpZmljYXRpb248L3NwYW4+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGNvbnRyb2wgcGFja2V0cyB0byB0aGUg PHNwYW4gY2xhc3M9Imluc2VydCI+aGVhZC48L3NwYW4+ICBTdWNoIHRhaWxzIHdpbGwgbmV2ZXIg YmUga25vd24gdG8gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNz PSJkZWxldGUiPiAgIG9mIHBhdGggZmFpbHVyZSBmcm9tIHRoZSB0YWlsLjwvc3Bhbj4gIFN1Y2gg dGFpbHMgd2lsbCBuZXZlciBiZSBrbm93biB0byB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBoZWFkLCBidXQgd2lsbCBz dGlsbCBiZSBhYmxlIHRvIGRldGVjdCBtdWx0aXBvaW50IHBhdGggZmFpbHVyZXMgZnJvbTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGhlYWQsIGJ1dCB3aWxsIHN0aWxsIGJlIGFi bGUgdG8gZGV0ZWN0IG11bHRpcG9pbnQgcGF0aCBmYWlsdXJlcyBmcm9tPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICB0aGUgaGVhZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICB0aGUgaGVhZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyIGlkPSJkaWZmMDAxNiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4zPC9z cGFuPi4gIE9wZXJhdGlvbmFsIFNjZW5hcmlvczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij41PC9zcGFuPi4gIE9wZXJhdGlvbmFsIFNjZW5hcmlv czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJdCBpcyB3b3J0aCBhbmFseXpp bmcgaG93IHRoaXMgcHJvdG9jb2wgcmVhY3RzIHRvIHZhcmlvdXMgc2NlbmFyaW9zLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEl0IGlzIHdvcnRoIGFuYWx5emluZyBob3cgdGhp cyBwcm90b2NvbCByZWFjdHMgdG8gdmFyaW91cyBzY2VuYXJpb3MuPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBUaGVyZSBhcmUgdGhyZWUgcGF0aCBjb21wb25lbnRzIHByZXNlbnQsIG5h bWVseSwgdGhlIG11bHRpcG9pbnQgcGF0aCw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBUaGVyZSBhcmUgdGhyZWUgcGF0aCBjb21wb25lbnRzIHByZXNlbnQsIG5hbWVseSwgdGhl IG11bHRpcG9pbnQgcGF0aCw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSBmb3J3 YXJkIHVuaWNhc3QgcGF0aCAoZnJvbSBoZWFkIHRvIGEgcGFydGljdWxhciB0YWlsKSwgYW5kIHRo ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSBmb3J3YXJkIHVuaWNhc3Qg cGF0aCAoZnJvbSBoZWFkIHRvIGEgcGFydGljdWxhciB0YWlsKSwgYW5kIHRoZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgcmV2ZXJzZSB1bmljYXN0IHBhdGggKGZyb20gYSB0YWlsIHRv IHRoZSBoZWFkKS4gIFRoZXJlIGFyZSBhbHNvIGZvdXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICByZXZlcnNlIHVuaWNhc3QgcGF0aCAoZnJvbSBhIHRhaWwgdG8gdGhlIGhlYWQp LiAgVGhlcmUgYXJlIGFsc28gZm91cjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb3B0 aW9ucyBhcyB0byBob3cgdGhlIGhlYWQgaXMgbm90aWZpZWQgYWJvdXQgZmFpbHVyZXMgZnJvbSB0 aGUgdGFpbC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvcHRpb25zIGFzIHRv IGhvdyB0aGUgaGVhZCBpcyBub3RpZmllZCBhYm91dCBmYWlsdXJlcyBmcm9tIHRoZSB0YWlsLjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxNyI+ PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xh c3M9Imluc2VydCI+Rm9yIHRoZSBkaWZmZXJlbnQgbW9kZXMgZGVzY3JpYmVkIGJlbG93IHRoZSBz ZXR0aW5nIG9mIG5ldyBzdGF0ZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg IHZhcmlhYmxlcyBhcmUgZ2l2ZW4gZXZlbiBpZiB0aGVzZSBhcmUgb25seSBpbnRyb2R1Y2VkIGxh dGVyIGluIHRoZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGRvY3VtZW50 IChzZWUgU2VjdGlvbiA2LjMpLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxOCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0i ZGVsZXRlIj4zPC9zcGFuPi4xLiAgTm8gSGVhZCBOb3RpZmljYXRpb248L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+NTwvc3Bhbj4uMS4gIE5vIEhl YWQgTm90aWZpY2F0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0ciBpZD0iZGlmZjAwMTkiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ U2luY2UgdGhlIG9ubHkgcGF0aCB1c2VkIGluPC9zcGFuPiB0aGlzIDxzcGFuIGNsYXNzPSJkZWxl dGUiPnNjZW5hcmlvIGlzPC9zcGFuPiB0aGUgbXVsdGlwb2ludCA8c3BhbiBjbGFzcz0iZGVsZXRl Ij5wYXRoLDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4g Y2xhc3M9Imluc2VydCI+SW48L3NwYW4+IHRoaXMgPHNwYW4gY2xhc3M9Imluc2VydCI+c2NlbmFy aW8sIG9ubHk8L3NwYW4+IHRoZSBtdWx0aXBvaW50IDxzcGFuIGNsYXNzPSJpbnNlcnQiPnBhdGgg aXMgdXNlZCBhbmQ8L3NwYW4+IG5vbmUgb2YgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgIG5vbmUgb2YgdGhlIG90aGVycyBtYXR0ZXIuICBBIGZhaWx1cmUgaW4gdGhlIG11bHRp cG9pbnQgcGF0aCB3aWxsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIG90aGVy cyBtYXR0ZXIuICBBIGZhaWx1cmUgaW4gdGhlIG11bHRpcG9pbnQgcGF0aCB3aWxsIHJlc3VsdCBp biB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgcmVzdWx0IGluIHRoZSB0YWls IG5vdGljaW5nIHRoZSBmYWlsdXJlIHdpdGhpbiBhIGRldGVjdGlvbiB0aW1lLCBhbmQ8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgdGFpbCBub3RpY2luZyB0aGUgZmFpbHVyZSB3 aXRoaW4gYSBkZXRlY3Rpb24gdGltZSwgYW5kIHRoZSBoZWFkIHdpbGw8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgdGhlIGhlYWQgd2lsbCByZW1haW4gaWdub3JhbnQgb2YgdGhlIHRh aWwgc3RhdGUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHJlbWFpbiBpZ25v cmFudCBvZiB0aGUgdGFpbCBzdGF0ZS4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPlRoaXMgbW9kZSBl bXVsYXRlcyB0aGUgYmVoYXZpb3I8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICBkZXNjcmliZWQgaW4gW0ktRC5pZXRmLWJmZC1tdWx0aXBvaW50XS4gIEluIHRoaXMgbW9kZSBm b3I8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBiZmQuU2Vzc2lvblR5cGUg aXMgTXVsdGlwb2ludFRhaWwsIHZhcmlhYmxlIGJmZC5TaWxlbnRUYWlsIChzZWU8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBTZWN0aW9uIDYuMy4xKSBNVVNUIGJlIHNldCB0 byAxLiAgSWYgYmZkLlNlc3Npb25UeXBlIGlzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgTXVsdGlwb2ludEhlYWQgb3IgTXVsdGlwb2ludENsaWVudCBiZmQuUmVwb3J0VGFp bERvd24gTVVTVCBiZSBzZXQgdG88L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICAwLlRoZSBoZWFkIE1BWSBzZXQgYmZkLlJlcXVpcmVkTWluUnhJbnRlcnZhbCB0byB6ZXJvIGFu ZCB0aHVzIHN1cHJlc3M8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB0YWls cyBzZW5kaW5nIGFueSBCRkQgY29udHJvbCBwYWNrZXRzLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyMCI+PHRkPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48c3BhbiBjbGFzcz0iZGVsZXRlIj4zLjIuICBVbnJlbGlhYmxlPC9zcGFuPiBIZWFkIE5vdGlm aWNhdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij41LjIuIDwvc3Bhbj4gSGVhZCBOb3RpZmljYXRpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyMSI+PHRkPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBJ biB0aGlzIHNjZW5hcmlvLCB0aGUgdGFpbCBzZW5kcyA8c3BhbiBjbGFzcz0iZGVsZXRlIj5iYWNr PC9zcGFuPiB1bnNvbGljaXRlZCBCRkQgcGFja2V0cyBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICBJbiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij50aGVzZSBzY2VuYXJpb3MgdGhl IHRhaWwgc2VuZHMgdW5zb2xpY2l0ZWQgb3Igc29saWNpdGVkIEJGRDwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgcmVzcG9uc2UgdG8gdGhlIGRldGVjdGlvbiBvZiBhIG11 bHRpcG9pbnQgcGF0aCBmYWlsdXJlLiAgSXQgdXNlcyB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgcGFja2V0cyBpbiByZXNwb25zZSB0 byB0aGUgZGV0ZWN0aW9uIG9mIGEgbXVsdGlwb2ludCBwYXRoIGZhaWx1cmUuPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICByZXZlcnNlIHVuaWNhc3QgcGF0aCwgYnV0IG5v dCB0aGUgZm9yd2FyZCB1bmljYXN0IHBhdGguPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIEFsbCB0aGVzZSBzY2VuYXJpb3MgaGF2ZSBjb21t b24gc2V0dGluZ3M6PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgbyAgaWYgYmZkLlNlc3Npb25UeXBlIGlzIE11 bHRpcG9pbnRUYWlsLCB2YXJpYWJsZSBiZmQuU2lsZW50VGFpbCAoc2VlPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgU2VjdGlvbiA2LjMuMSkgTVVTVCBiZSBzZXQgdG8g MDs8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh biBjbGFzcz0iaW5zZXJ0Ij4gICBvICBpZiBiZmQuU2Vzc2lvblR5cGUgaXMgTXVsdGlwb2ludEhl YWQgb3IgTXVsdGlwb2ludENsaWVudDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgICAgIGJmZC5SZXBvcnRUYWlsRG93biBNVVNUIGJlIHNldCB0byAxOzwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgIG8gIHRoZSBoZWFkIE1VU1Qgc2V0IGJmZC5SZXF1aXJlZE1pblJ4SW50ZXJ2YWwgdG8gbm9u LXplcm8gYW5kIHRodXM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBh bGxvdyB0YWlscyBzZW5kaW5nIEJGRCBjb250cm9sIHBhY2tldHMuPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+NS4y LjEuICBIZWFkIE5vdGlmaWNhdGlvbiBXaXRob3V0IFBvbGxpbmc8L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh biBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBJ bjwvc3Bhbj4gdGhpcyBzY2VuYXJpbywgdGhlIHRhaWwgc2VuZHMgdW5zb2xpY2l0ZWQgQkZEIHBh Y2tldHMgaW4gcmVzcG9uc2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHRvIHRoZSBkZXRlY3Rpb24gb2YgYSBtdWx0aXBv aW50IHBhdGggZmFpbHVyZS4gIEl0IHVzZXMgdGhlIHJldmVyc2U8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHVuaWNhc3Qg cGF0aCwgYnV0IG5vdCB0aGUgZm9yd2FyZCB1bmljYXN0IHBhdGguPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIElmIHRoZSBtdWx0aXBvaW50IHBhdGggZmFpbHMgYnV0IHRoZSBy ZXZlcnNlIHVuaWNhc3QgcGF0aCBzdGF5cyB1cCw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBJZiB0aGUgbXVsdGlwb2ludCBwYXRoIGZhaWxzIGJ1dCB0aGUgcmV2ZXJzZSB1bmlj YXN0IHBhdGggc3RheXMgdXAsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGUgdGFp bCB3aWxsIGRldGVjdCB0aGUgZmFpbHVyZSB3aXRoaW4gYSBkZXRlY3Rpb24gdGltZSwgYW5kIHRo ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSB0YWlsIHdpbGwgZGV0ZWN0 IHRoZSBmYWlsdXJlIHdpdGhpbiBhIGRldGVjdGlvbiB0aW1lLCBhbmQgdGhlPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBoZWFkIHdpbGwga25vdyBhYm91dCBpdCB3aXRoaW4gb25lIHJl dmVyc2UgcGFja2V0IHRpbWUgKHNpbmNlIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGhlYWQgd2lsbCBrbm93IGFib3V0IGl0IHdpdGhpbiBvbmUgcmV2ZXJzZSBwYWNrZXQg dGltZSAoc2luY2UgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBub3RpZmljYXRp b24gaXMgZGVsYXllZCkuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbm90aWZp Y2F0aW9uIGlzIGRlbGF5ZWQpLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJ ZiBib3RoIHRoZSBtdWx0aXBvaW50IHBhdGggYW5kIHRoZSByZXZlcnNlIHVuaWNhc3QgcGF0aHMg ZmFpbCwgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSWYgYm90aCB0aGUg bXVsdGlwb2ludCBwYXRoIGFuZCB0aGUgcmV2ZXJzZSB1bmljYXN0IHBhdGhzIGZhaWwsIHRoZTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGFpbCB3aWxsIGRldGVjdCB0aGUgZmFpbHVy ZSBidXQgdGhlIGhlYWQgd2lsbCByZW1haW4gdW5hd2FyZSBvZiBpdC48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICB0YWlsIHdpbGwgZGV0ZWN0IHRoZSBmYWlsdXJlIGJ1dCB0aGUg aGVhZCB3aWxsIHJlbWFpbiB1bmF3YXJlIG9mIGl0LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDIyIj48dGQ+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNs YXNzPSJkZWxldGUiPjMuMy4gIFNlbWktcmVsaWFibGUgSGVhZCBOb3RpZmljYXRpb24gYW5kIFRh aWwgU29saWNpdGF0aW9uPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48 c3BhbiBjbGFzcz0iaW5zZXJ0Ij41LjIuMi4gIEhlYWQgTm90aWZpY2F0aW9uIGFuZCBUYWlsIFNv bGljaXRhdGlvbiB3aXRoIE11bHRpcG9pbnQgUG9sbGluZzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW4gdGhpcyBzY2VuYXJpbywgdGhlIGhlYWQgc2VuZHMgb2Nj YXNpb25hbCBtdWx0aXBvaW50IFBvbGxzIGluPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgSW4gdGhpcyBzY2VuYXJpbywgdGhlIGhlYWQgc2VuZHMgb2NjYXNpb25hbCBtdWx0aXBv aW50IFBvbGxzIGluPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhZGRpdGlvbiB0byAo b3IgaW4gbGlldSBvZikgbm9uLVBvbGwgbXVsdGlwb2ludCBCRkQgQ29udHJvbCBwYWNrZXRzLDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFkZGl0aW9uIHRvIChvciBpbiBsaWV1 IG9mKSBub24tUG9sbCBtdWx0aXBvaW50IEJGRCBDb250cm9sIHBhY2tldHMsPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBleHBlY3RpbmcgdGhlIHRhaWxzIHRvIHJlcGx5IHdpdGggRmlu YWwuICBUaGlzIGFsc28gdXNlcyB0aGUgcmV2ZXJzZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIGV4cGVjdGluZyB0aGUgdGFpbHMgdG8gcmVwbHkgd2l0aCBGaW5hbC4gIFRoaXMg YWxzbyB1c2VzIHRoZSByZXZlcnNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB1bmlj YXN0IHBhdGgsIGJ1dCBub3QgdGhlIGZvcndhcmQgdW5pY2FzdCBwYXRoLjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIHVuaWNhc3QgcGF0aCwgYnV0IG5vdCB0aGUgZm9yd2FyZCB1 bmljYXN0IHBhdGguPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIElmIHRoZSBt dWx0aXBvaW50IHBhdGggZmFpbHMgYnV0IHRoZSByZXZlcnNlIHVuaWNhc3QgcGF0aCBzdGF5cyB1 cCw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJZiB0aGUgbXVsdGlwb2ludCBw YXRoIGZhaWxzIGJ1dCB0aGUgcmV2ZXJzZSB1bmljYXN0IHBhdGggc3RheXMgdXAsPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGUgdGFpbCB3aWxsIGRldGVjdCB0aGUgZmFpbHVyZSB3 aXRoaW4gYSBkZXRlY3Rpb24gdGltZSwgYW5kIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIHRoZSB0YWlsIHdpbGwgZGV0ZWN0IHRoZSBmYWlsdXJlIHdpdGhpbiBhIGRldGVj dGlvbiB0aW1lLCBhbmQgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBoZWFkIHdp bGwga25vdyBhYm91dCBpdCB3aXRoaW4gb25lIHJldmVyc2UgcGFja2V0IHRpbWUgKHRoZTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGhlYWQgd2lsbCBrbm93IGFib3V0IGl0IHdp dGhpbiBvbmUgcmV2ZXJzZSBwYWNrZXQgdGltZSAodGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBub3RpZmljYXRpb24gaXMgZGVsYXllZCB0byBhdm9pZCBzeW5jaHJvbml6YXRpb24g b2YgdGhlIHRhaWxzKS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBub3RpZmlj YXRpb24gaXMgZGVsYXllZCB0byBhdm9pZCBzeW5jaHJvbml6YXRpb24gb2YgdGhlIHRhaWxzKS48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0 LTIiIGNsYXNzPSJjaGFuZ2UiPjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdl IGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYu cHlodCNwYXJ0LTIiPjxlbT4gcGFnZSA1LCBsaW5lIDQ1PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwv c3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5n ZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZm LnB5aHQjcGFydC0yIj48ZW0+IHBhZ2UgNiwgbGluZSAzMTxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8 L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJZiB0aGUgcmV2ZXJzZSB1bmljYXN0IHBh dGggZmFpbHMgYnV0IHRoZSBtdWx0aXBvaW50IHBhdGggc3RheXMgdXAsPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgSWYgdGhlIHJldmVyc2UgdW5pY2FzdCBwYXRoIGZhaWxzIGJ1 dCB0aGUgbXVsdGlwb2ludCBwYXRoIHN0YXlzIHVwLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgdGhlIGhlYWQgd2lsbCBzZWUgdGhlIEJGRCBzZXNzaW9uIGZhaWwsIGJ1dCB0aGUgc3Rh dGUgb2YgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhlIGhlYWQgd2ls bCBzZWUgdGhlIEJGRCBzZXNzaW9uIGZhaWwsIGJ1dCB0aGUgc3RhdGUgb2YgdGhlPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtdWx0aXBvaW50IHBhdGggd2lsbCBiZSB1bmtub3duIHRv IHRoZSBoZWFkLiAgVGhlIHRhaWwgd2lsbCBjb250aW51ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIG11bHRpcG9pbnQgcGF0aCB3aWxsIGJlIHVua25vd24gdG8gdGhlIGhlYWQu ICBUaGUgdGFpbCB3aWxsIGNvbnRpbnVlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0 byByZWNlaXZlIG11bHRpcG9pbnQgZGF0YSB0cmFmZmljLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIHRvIHJlY2VpdmUgbXVsdGlwb2ludCBkYXRhIHRyYWZmaWMuPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIElmIGVpdGhlciB0aGUgbXVsdGlwb2ludCBQb2xs IG9yIHRoZSB1bmljYXN0IHJlcGx5IGlzIGxvc3QgaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBJZiBlaXRoZXIgdGhlIG11bHRpcG9pbnQgUG9sbCBvciB0aGUgdW5pY2FzdCBy ZXBseSBpcyBsb3N0IGluPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0cmFuc2l0LCB0 aGUgaGVhZCB3aWxsIHNlZSB0aGUgQkZEIHNlc3Npb24gZmFpbCwgYnV0IHRoZSBzdGF0ZSBvZiB0 aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0cmFuc2l0LCB0aGUgaGVhZCB3 aWxsIHNlZSB0aGUgQkZEIHNlc3Npb24gZmFpbCwgYnV0IHRoZSBzdGF0ZSBvZiB0aGU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG11bHRpcG9pbnQgcGF0aCB3aWxsIGJlIHVua25vd24g dG8gdGhlIGhlYWQuICBUaGUgdGFpbCB3aWxsIGNvbnRpbnVlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgbXVsdGlwb2ludCBwYXRoIHdpbGwgYmUgdW5rbm93biB0byB0aGUgaGVh ZC4gIFRoZSB0YWlsIHdpbGwgY29udGludWU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHRvIHJlY2VpdmUgbXVsdGlwb2ludCBkYXRhIHRyYWZmaWMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgdG8gcmVjZWl2ZSBtdWx0aXBvaW50IGRhdGEgdHJhZmZpYy48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyMyI+ PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4zLjQuICBSZWxpYWJsZSBIZWFkIE5vdGlm aWNhdGlvbjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+NS4yLjMuICBIZWFkIE5vdGlmaWNhdGlvbiB3aXRoIENvbXBvc2l0ZSBQb2xs aW5nPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbiB0aGlzIHNj ZW5hcmlvLCB0aGUgaGVhZCBzZW5kcyBvY2Nhc2lvbmFsIG11bHRpcG9pbnQgUG9sbHMgaW48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbiB0aGlzIHNjZW5hcmlvLCB0aGUgaGVh ZCBzZW5kcyBvY2Nhc2lvbmFsIG11bHRpcG9pbnQgUG9sbHMgaW48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGFkZGl0aW9uIHRvIChvciBpbiBsaWV1IG9mKSBub24tUG9sbCBtdWx0aXBv aW50IEJGRCBjb250cm9sIHBhY2tldHMsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgYWRkaXRpb24gdG8gKG9yIGluIGxpZXUgb2YpIG5vbi1Qb2xsIG11bHRpcG9pbnQgQkZEIGNv bnRyb2wgcGFja2V0cyw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGV4cGVjdGluZyB0 aGUgdGFpbHMgdG8gcmVwbHkgd2l0aCBGaW5hbC4gIElmIGEgdGFpbCB0aGF0IGhhZDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGV4cGVjdGluZyB0aGUgdGFpbHMgdG8gcmVwbHkg d2l0aCBGaW5hbC4gIElmIGEgdGFpbCB0aGF0IGhhZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgcHJldmlvdXNseSByZXBsaWVkIHRvIGEgbXVsdGlwb2ludCBQb2xsIGZhaWxzIHRvIHJl cGx5IChvciBpZiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwcmV2aW91 c2x5IHJlcGxpZWQgdG8gYSBtdWx0aXBvaW50IFBvbGwgZmFpbHMgdG8gcmVwbHkgKG9yIGlmIHRo ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaGVhZCBzaW1wbHkgd2lzaGVzIHRvIHZl cmlmeSB0YWlsIGNvbm5lY3Rpdml0eSksIHRoZSBoZWFkIGlzc3VlcyBhPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgaGVhZCBzaW1wbHkgd2lzaGVzIHRvIHZlcmlmeSB0YWlsIGNv bm5lY3Rpdml0eSksIHRoZSBoZWFkIGlzc3VlcyBhPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICB1bmljYXN0IFBvbGwgU2VxdWVuY2UgdG8gdGhlIHRhaWwuICBUaGlzIHNjZW5hcmlvIG1h a2VzIHVzZSBvZiBhbGw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB1bmljYXN0 IFBvbGwgU2VxdWVuY2UgdG8gdGhlIHRhaWwuICBUaGlzIHNjZW5hcmlvIG1ha2VzIHVzZSBvZiBh bGw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAw MjQiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgdGhyZWUgcGF0aHMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgIHRocmVlIHBhdGhzLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+SW4gdGhpcyBtb2Rl IGZvciBiZmQuU2Vzc2lvblR5cGUgb2YgTXVsdGlwb2ludFRhaWwsPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+ICAgdmFyaWFibGUgYmZkLlNpbGVudFRhaWwgKHNlZSBTZWN0aW9u IDYuMy4xKSBNVVNUIGJlIHNldCB0byAwLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgSWYgdGhlIG11bHRpcG9pbnQgcGF0aCBmYWlscyBidXQgdGhlIHR3byB1bmlj YXN0IHBhdGhzIHN0YXkgdXAsIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IElmIHRoZSBtdWx0aXBvaW50IHBhdGggZmFpbHMgYnV0IHRoZSB0d28gdW5pY2FzdCBwYXRocyBz dGF5IHVwLCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRhaWwgd2lsbCBkZXRl Y3QgdGhlIGZhaWx1cmUgd2l0aGluIGEgZGV0ZWN0aW9uIHRpbWUsIGFuZCB0aGUgaGVhZDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRhaWwgd2lsbCBkZXRlY3QgdGhlIGZhaWx1 cmUgd2l0aGluIGEgZGV0ZWN0aW9uIHRpbWUsIGFuZCB0aGUgaGVhZDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgd2lsbCBrbm93IGFib3V0IGl0IHdpdGhpbiBvbmUgcmV2ZXJzZSBwYWNr ZXQgdGltZSAoc2luY2UgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgd2ls bCBrbm93IGFib3V0IGl0IHdpdGhpbiBvbmUgcmV2ZXJzZSBwYWNrZXQgdGltZSAoc2luY2UgdGhl PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBub3RpZmljYXRpb24gaXMgZGVsYXllZCku ICBOb3RlIHRoYXQgdGhlIHJldmVyc2UgcGFja2V0IHRpbWUgbWF5IGJlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgbm90aWZpY2F0aW9uIGlzIGRlbGF5ZWQpLiAgTm90ZSB0aGF0 IHRoZSByZXZlcnNlIHBhY2tldCB0aW1lIG1heSBiZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgc21hbGxlciBpbiB0aGlzIGNhc2UgaWYgdGhlIGhlYWQgaGFzIHByZXZpb3VzbHkgaXNz dWVkIGEgdW5pY2FzdCBQb2xsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc21h bGxlciBpbiB0aGlzIGNhc2UgaWYgdGhlIGhlYWQgaGFzIHByZXZpb3VzbHkgaXNzdWVkIGEgdW5p Y2FzdCBQb2xsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAoc2luY2UgdGhlIHRhaWwg d2lsbCBub3QgZGVsYXkgdHJhbnNtaXNzaW9uIG9mIHRoZSBub3RpZmljYXRpb24gaW48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAoc2luY2UgdGhlIHRhaWwgd2lsbCBub3QgZGVs YXkgdHJhbnNtaXNzaW9uIG9mIHRoZSBub3RpZmljYXRpb24gaW48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIHRoaXMgY2FzZSkuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgdGhpcyBjYXNlKS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSWYgYm90 aCB0aGUgbXVsdGlwb2ludCBwYXRoIGFuZCB0aGUgcmV2ZXJzZSB1bmljYXN0IHBhdGhzIGZhaWw8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJZiBib3RoIHRoZSBtdWx0aXBvaW50 IHBhdGggYW5kIHRoZSByZXZlcnNlIHVuaWNhc3QgcGF0aHMgZmFpbDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9InBhcnQtMyIgY2xhc3M9ImNoYW5n ZSI+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmYvcmZjZGlmZi5weWh0I3BhcnQtMyI+PGVt PiBwYWdlIDYsIGxpbmUgMzI8c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwv dGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTMiPjxl bT4gcGFnZSA3LCBsaW5lIDE5PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48 L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIElmIHRoZSBmb3J3YXJkIHVuaWNhc3QgcGF0aCBmYWlscyBidXQgdGhl IHJldmVyc2UgdW5pY2FzdCBwYXRoIHN0YXlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgSWYgdGhlIGZvcndhcmQgdW5pY2FzdCBwYXRoIGZhaWxzIGJ1dCB0aGUgcmV2ZXJzZSB1 bmljYXN0IHBhdGggc3RheXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHVwLCB0aGUg aGVhZCB3aWxsIGRldGVjdCBhIEJGRCBzZXNzaW9uIGZhaWx1cmUgdG8gdGhlIHRhaWwgaWYgaXQ8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB1cCwgdGhlIGhlYWQgd2lsbCBkZXRl Y3QgYSBCRkQgc2Vzc2lvbiBmYWlsdXJlIHRvIHRoZSB0YWlsIGlmIGl0PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBoYXBwZW5zIHRvIHNlbmQgYSB1bmljYXN0IFBvbGwgc2VxdWVuY2Us IGJ1dCBjYW5ub3QgbWFrZSBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaGFw cGVucyB0byBzZW5kIGEgdW5pY2FzdCBQb2xsIHNlcXVlbmNlLCBidXQgY2Fubm90IG1ha2UgYTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGV0ZXJtaW5hdGlvbiBhYm91dCB0aGUgc3Rh dGUgb2YgdGhlIHRhaWwncyBtdWx0aXBvaW50IGNvbm5lY3Rpdml0eS48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBkZXRlcm1pbmF0aW9uIGFib3V0IHRoZSBzdGF0ZSBvZiB0aGUg dGFpbCdzIG11bHRpcG9pbnQgY29ubmVjdGl2aXR5LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgSWYgdGhlIG11bHRpcG9pbnQgcGF0aCB0byB0aGUgdGFpbCBmYWlscyBwcmlvciB0byBh bnkgdW5pY2FzdCBQb2xsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSWYgdGhl IG11bHRpcG9pbnQgcGF0aCB0byB0aGUgdGFpbCBmYWlscyBwcmlvciB0byBhbnkgdW5pY2FzdCBQ b2xsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBiZWluZyBzZW50LCB0aGUgdGFpbCB3 aWxsIGRldGVjdCB0aGUgZmFpbHVyZSB3aXRoaW4gYSBkZXRlY3Rpb24gdGltZSw8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBiZWluZyBzZW50LCB0aGUgdGFpbCB3aWxsIGRldGVj dCB0aGUgZmFpbHVyZSB3aXRoaW4gYSBkZXRlY3Rpb24gdGltZSw8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGFuZCB0aGUgaGVhZCB3aWxsIGtub3cgYWJvdXQgaXQgd2l0aGluIG9uZSBy ZXZlcnNlIHBhY2tldCB0aW1lIChzaW5jZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGFuZCB0aGUgaGVhZCB3aWxsIGtub3cgYWJvdXQgaXQgd2l0aGluIG9uZSByZXZlcnNlIHBh Y2tldCB0aW1lIChzaW5jZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIG5vdGlm aWNhdGlvbiBpcyBkZWxheWVkKS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0 aGUgbm90aWZpY2F0aW9uIGlzIGRlbGF5ZWQpLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBJZiB0aGUgbXVsdGlwb2ludCBwYXRoIHN0YXlzIHVwIGJ1dCB0aGUgcmV2ZXJzZSB1 bmljYXN0IHBhdGggZmFpbHMsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSWYg dGhlIG11bHRpcG9pbnQgcGF0aCBzdGF5cyB1cCBidXQgdGhlIHJldmVyc2UgdW5pY2FzdCBwYXRo IGZhaWxzLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJk aWZmMDAyNSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB0aGUgaGVhZCB3aWxsIHNlZSB0aGUgPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+QkZEPC9zcGFuPiBzZXNzaW9uIGZhaWwgaWYgaXQgaGFwcGVucyB0byBzZW5kIGEg UG9sbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICB0aGUgaGVhZCB3aWxsIHNl ZSB0aGUgPHNwYW4gY2xhc3M9Imluc2VydCI+cGFydGljdWxhciBNdWx0aXBvaW50Q2xpZW50PC9z cGFuPiBzZXNzaW9uIGZhaWwgaWYgaXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg U2VxdWVuY2UsIGJ1dCB0aGUgc3RhdGUgb2YgdGhlIG11bHRpcG9pbnQgcGF0aCB3aWxsIGJlIHVu a25vd24gdG8gdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGhhcHBlbnMg dG8gc2VuZCBhIFBvbGwgU2VxdWVuY2UsIGJ1dCB0aGUgc3RhdGUgb2YgdGhlIG11bHRpcG9pbnQg cGF0aDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBoZWFkLiAgVGhlIHRhaWwgd2ls bCBjb250aW51ZSB0byByZWNlaXZlIG11bHRpcG9pbnQgZGF0YSB0cmFmZmljLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICB3aWxsIGJlIHVua25vd24gdG8gdGhlIGhlYWQuICBU aGUgdGFpbCB3aWxsIGNvbnRpbnVlIHRvIHJlY2VpdmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIG11bHRpcG9pbnQgZGF0 YSB0cmFmZmljLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJZiB0aGUgbXVs dGlwb2ludCBwYXRoIGFuZCB0aGUgcmV2ZXJzZSB1bmljYXN0IHBhdGggYm90aCBzdGF5IHVwIGJ1 dDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIElmIHRoZSBtdWx0aXBvaW50IHBh dGggYW5kIHRoZSByZXZlcnNlIHVuaWNhc3QgcGF0aCBib3RoIHN0YXkgdXAgYnV0PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGUgZm9yd2FyZCB1bmljYXN0IHBhdGggZmFpbHMsIG5l aXRoZXIgc2lkZSB3aWxsIG5vdGljZSBzbyBsb25nIGFzIGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICB0aGUgZm9yd2FyZCB1bmljYXN0IHBhdGggZmFpbHMsIG5laXRoZXIgc2lk ZSB3aWxsIG5vdGljZSBzbyBsb25nIGFzIGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHVuaWNhc3QgUG9sbCBTZXF1ZW5jZSBpcyBuZXZlciBzZW50IGJ5IHRoZSBoZWFkLiAgSWYgdGhl IGhlYWQgc2VuZHMgYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHVuaWNhc3Qg UG9sbCBTZXF1ZW5jZSBpcyBuZXZlciBzZW50IGJ5IHRoZSBoZWFkLiAgSWYgdGhlIGhlYWQgc2Vu ZHMgYTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdW5pY2FzdCBQb2xsIFNlcXVlbmNl LCB0aGUgaGVhZCB3aWxsIHNlZSB0aGUgQkZEIHNlc3Npb24gZmFpbCwgYnV0PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdW5pY2FzdCBQb2xsIFNlcXVlbmNlLCB0aGUgaGVhZCB3 aWxsIHNlZSB0aGUgQkZEIHNlc3Npb24gZmFpbCwgYnV0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICB0aGUgc3RhdGUgb2YgdGhlIG11bHRpcG9pbnQgcGF0aCB3aWxsIGJlIHVua25vd24g dG8gdGhlIGhlYWQuICBUaGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGUg c3RhdGUgb2YgdGhlIG11bHRpcG9pbnQgcGF0aCB3aWxsIGJlIHVua25vd24gdG8gdGhlIGhlYWQu ICBUaGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRhaWwgd2lsbCBjb250aW51ZSB0 byByZWNlaXZlIG11bHRpcG9pbnQgZGF0YSB0cmFmZmljLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIHRhaWwgd2lsbCBjb250aW51ZSB0byByZWNlaXZlIG11bHRpcG9pbnQgZGF0 YSB0cmFmZmljLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHIgaWQ9ImRpZmYwMDI2Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPjQ8L3NwYW4+ LiAgUHJvdG9jb2wgRGV0YWlsczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh biBjbGFzcz0iaW5zZXJ0Ij42PC9zcGFuPi4gIFByb3RvY29sIERldGFpbHM8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgb3BlcmF0 aW9uIG9mIEJGRCBNdWx0aXBvaW50IGFjdGl2ZSB0YWlsIGluPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgb3BlcmF0aW9uIG9mIEJG RCBNdWx0aXBvaW50IGFjdGl2ZSB0YWlsIGluPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDI3Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGRldGFpbC4gIFRoaXMg c2VjdGlvbiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5pcyBhbiB1cGRhdGUgdG88L3NwYW4+IHNlY3Rp b24gNCBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBkZXRhaWwuICBUaGlz IHNlY3Rpb24gPHNwYW4gY2xhc3M9Imluc2VydCI+dXBkYXRlcyB0aGU8L3NwYW4+IHNlY3Rpb24g NCBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRl Ij5bSS1ELmlldGYtYmZkLW11bHRpcG9pbnRdLjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+W0ktRC5pZXRmLWJmZC1tdWx0aXBv aW50XSBhcyB0aGUgZm9sbG93aW5nOjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyOCI+PHRkPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFz cz0iZGVsZXRlIj40LjEuPC9zcGFuPiAgTXVsdGlwb2ludCBDbGllbnQgU2Vzc2lvbjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5vICBTZWN0 aW9uIDYuMyBpbnRyb2R1Y2VzIG5ldyBzdGF0ZSB2YXJpYWJsZXMgYW5kIG1vZGlmaWVzIHRoZSB1 c2FnZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIG9mIGEgZmV3IGV4 aXN0aW5nIG9uZXM7PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgbyAgU2VjdGlvbiA2LjEzIHJlcGxhY2VzIHRo ZSBjb3JyZXNwb25kaW5nIHNlY3Rpb25zIGluIHRoZSBiYXNlIEJGRDwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIGZvciBtdWx0aXBvaW50IG5ldHdvcmtzIHNwZWNpZmlj YXRpb24uPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+Ni4xLjwvc3Bhbj4gIE11bHRpcG9pbnQgQ2xpZW50IFNlc3Np b248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSWYgdGhlIGhlYWQgaXMga2Vl cGluZyB0cmFjayBvZiBzb21lIG9yIGFsbCBvZiB0aGUgdGFpbHMsIGl0IGhhcyBhPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSWYgdGhlIGhlYWQgaXMga2VlcGluZyB0cmFjayBv ZiBzb21lIG9yIGFsbCBvZiB0aGUgdGFpbHMsIGl0IGhhcyBhPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBzZXNzaW9uIG9mIHR5cGUgTXVsdGlwb2ludENsaWVudCBwZXIgdGFpbCB0aGF0 IGl0IGNhcmVzIGFib3V0LiAgQWxsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg c2Vzc2lvbiBvZiB0eXBlIE11bHRpcG9pbnRDbGllbnQgcGVyIHRhaWwgdGhhdCBpdCBjYXJlcyBh Ym91dC4gIEFsbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb2YgdGhlIE11bHRpcG9p bnRDbGllbnQgc2Vzc2lvbnMgZm9yIHRhaWxzIG9uIGEgcGFydGljdWxhciBtdWx0aXBvaW50PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb2YgdGhlIE11bHRpcG9pbnRDbGllbnQg c2Vzc2lvbnMgZm9yIHRhaWxzIG9uIGEgcGFydGljdWxhciBtdWx0aXBvaW50PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDI5Ij48dGQ+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIHBhdGggYXJlIDxzcGFuIGNsYXNzPSJkZWxldGUiPmdyb3VwZWQ8L3NwYW4+IHdpdGggdGhl IE11bHRpcG9pbnRIZWFkIHNlc3Npb24gdG8gd2hpY2ggdGhlIGNsaWVudHM8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgcGF0aCBhcmUgPHNwYW4gY2xhc3M9Imluc2VydCI+YXNz b2NpYXRlZDwvc3Bhbj4gd2l0aCB0aGUgTXVsdGlwb2ludEhlYWQgc2Vzc2lvbiB0byB3aGljaCB0 aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgYXJlIGxpc3RlbmluZy4gIEEgQkZE IFBvbGwgU2VxdWVuY2UgbWF5IGJlIHNlbnQgb3ZlciA8c3BhbiBjbGFzcz0iZGVsZXRlIj5zdWNo PC9zcGFuPiBhIHNlc3Npb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgY2xp ZW50cyBhcmUgbGlzdGVuaW5nLiAgQSBCRkQgUG9sbCBTZXF1ZW5jZSBtYXkgYmUgc2VudCBvdmVy IGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgdG8gYSB0YWlsIGlmIHRoZSBoZWFk IHdpc2hlcyB0byB2ZXJpZnkgY29ubmVjdGl2aXR5LiAgVGhlc2Ugc2Vzc2lvbnM8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+TXVsdGlwb2lu dENsaWVudDwvc3Bhbj4gc2Vzc2lvbiB0byBhIHRhaWwgaWYgdGhlIGhlYWQgd2lzaGVzIHRvIHZl cmlmeTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICByZWNlaXZlIGFueSBCRkQgQ29u dHJvbCBwYWNrZXRzIHNlbnQgYnkgdGhlIHRhaWxzLCBhbmQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ bmV2ZXI8L3NwYW4+IHRyYW5zbWl0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg IGNvbm5lY3Rpdml0eS4gIFRoZXNlIHNlc3Npb25zIHJlY2VpdmUgYW55IEJGRCBDb250cm9sIHBh Y2tldHMgc2VudCBieTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBwZXJpb2RpYyBC RkQgQ29udHJvbCBwYWNrZXRzIG90aGVyIHRoYW4gUG9sbCBTZXF1ZW5jZXMgKHNpbmNlPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHRoZSB0YWlscywgYW5kIDxzcGFuIGNsYXNz PSJpbnNlcnQiPk1VU1QgTk9UPC9zcGFuPiB0cmFuc21pdCBwZXJpb2RpYyBCRkQgQ29udHJvbCBw YWNrZXRzIG90aGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHBlcmlvZGljIHRy YW5zbWlzc2lvbiBpcyBhbHdheXMgZG9uZSBieSB0aGUgTXVsdGlwb2ludEhlYWQgc2Vzc2lvbiku PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHRoYW4gUG9sbCBTZXF1ZW5jZXMg KHNpbmNlIHBlcmlvZGljIHRyYW5zbWlzc2lvbiBpcyBhbHdheXMgZG9uZSBieTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg dGhlIE11bHRpcG9pbnRIZWFkIHNlc3Npb24pLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDMwIj48dGQ+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNz PSJkZWxldGUiPjQ8L3NwYW4+LjIuICBNdWx0aXBvaW50IENsaWVudCBTZXNzaW9uIEZhaWx1cmU8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+Njwv c3Bhbj4uMi4gIE11bHRpcG9pbnQgQ2xpZW50IFNlc3Npb24gRmFpbHVyZTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJZiBhIE11bHRpcG9pbnRDbGllbnQgc2Vzc2lvbiByZWNl aXZlcyBhIEJGRCBDb250cm9sIHBhY2tldCBmcm9tIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIElmIGEgTXVsdGlwb2ludENsaWVudCBzZXNzaW9uIHJlY2VpdmVzIGEgQkZE IENvbnRyb2wgcGFja2V0IGZyb20gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0 YWlsIHdpdGggc3RhdGUgRG93biBvciBBZG1pbkRvd24sIHRoZSBoZWFkIHJlbGlhYmx5IGtub3dz IHRoYXQgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGFpbCB3aXRoIHN0 YXRlIERvd24gb3IgQWRtaW5Eb3duLCB0aGUgaGVhZCByZWxpYWJseSBrbm93cyB0aGF0IHRoZTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGFpbCBoYXMgbG9zdCBtdWx0aXBvaW50IGNv bm5lY3Rpdml0eS4gIElmIHRoZSBEZXRlY3Rpb24gVGltZSBleHBpcmVzPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgdGFpbCBoYXMgbG9zdCBtdWx0aXBvaW50IGNvbm5lY3Rpdml0 eS4gIElmIHRoZSBEZXRlY3Rpb24gVGltZSBleHBpcmVzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBvbiBhIE11bHRpcG9pbnRDbGllbnQgc2Vzc2lvbiwgaXQgaXMgYW1iaWd1b3VzIGFz IHRvIHdoZXRoZXIgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb24gYSBN dWx0aXBvaW50Q2xpZW50IHNlc3Npb24sIGl0IGlzIGFtYmlndW91cyBhcyB0byB3aGV0aGVyIHRo ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbXVsdGlwb2ludCBjb25uZWN0aXZpdHkg ZmFpbGVkIG9yIHdoZXRoZXIgdGhlcmUgd2FzIGEgdW5pY2FzdCBwYXRoPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgbXVsdGlwb2ludCBjb25uZWN0aXZpdHkgZmFpbGVkIG9yIHdo ZXRoZXIgdGhlcmUgd2FzIGEgdW5pY2FzdCBwYXRoPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBwcm9ibGVtIGluIG9uZSBkaXJlY3Rpb24gb3IgdGhlIG90aGVyLCBzbyB0aGUgaGVhZCBk b2VzIG5vdCByZWxpYWJseTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHByb2Js ZW0gaW4gb25lIGRpcmVjdGlvbiBvciB0aGUgb3RoZXIsIHNvIHRoZSBoZWFkIGRvZXMgbm90IHJl bGlhYmx5PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBrbm93IHRoZSB0YWlsJ3Mgc3Rh dGUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAga25vdyB0aGUgdGFpbCdzIHN0 YXRlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9 ImRpZmYwMDMxIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPjQ8L3NwYW4+LjMuICBT dGF0ZSBWYXJpYWJsZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+Njwvc3Bhbj4uMy4gIFN0YXRlIFZhcmlhYmxlczwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBCRkQgTXVsdGlwb2ludCBhY3RpdmUgdGFpbCBpbnRyb2R1Y2Vz IG5ldyBzdGF0ZSB2YXJpYWJsZXMgYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgQkZEIE11bHRpcG9pbnQgYWN0aXZlIHRhaWwgaW50cm9kdWNlcyBuZXcgc3RhdGUgdmFyaWFi bGVzIGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbW9kaWZpZXMgdGhlIHVzYWdl IG9mIGEgZmV3IGV4aXN0aW5nIG9uZXMgZGVmaW5lZCBpbiBzZWN0aW9uIDQuNCBvZjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG1vZGlmaWVzIHRoZSB1c2FnZSBvZiBhIGZldyBl eGlzdGluZyBvbmVzIGRlZmluZWQgaW4gc2VjdGlvbiA0LjQgb2Y8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIFtJLUQuaWV0Zi1iZmQtbXVsdGlwb2ludF0uPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgW0ktRC5pZXRmLWJmZC1tdWx0aXBvaW50XS48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAzMiI+PHRkPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj40PC9zcGFuPi4zLjEuICBOZXcgU3RhdGUgVmFyaWFi bGVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PjY8L3NwYW4+LjMuMS4gIE5ldyBTdGF0ZSBWYXJpYWJsZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgRmV3IHN0YXRlIHZhcmlhYmxlcyBhcmUgYWRkZWQgaW4gc3VwcG9ydCBv ZiBNdWx0aXBvaW50IEJGRCBhY3RpdmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBGZXcgc3RhdGUgdmFyaWFibGVzIGFyZSBhZGRlZCBpbiBzdXBwb3J0IG9mIE11bHRpcG9pbnQg QkZEIGFjdGl2ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGFpbC48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0YWlsLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICBiZmQuU2lsZW50VGFpbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgIGJmZC5TaWxlbnRUYWlsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgIElmIDAsIGEgdGFpbCBtYXkgc2VuZCBwYWNrZXRzIHRvIHRoZSBoZWFkIGFjY29y ZGluZyB0byBvdGhlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgIElm IDAsIGEgdGFpbCBtYXkgc2VuZCBwYWNrZXRzIHRvIHRoZSBoZWFkIGFjY29yZGluZyB0byBvdGhl cjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgcGFydHMgb2YgdGhpcyBzcGVj aWZpY2F0aW9uLiAgU2V0dGluZyB0aGlzIHRvIDEgYWxsb3dzIHRhaWxzIHRvPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgcGFydHMgb2YgdGhpcyBzcGVjaWZpY2F0aW9u LiAgU2V0dGluZyB0aGlzIHRvIDEgYWxsb3dzIHRhaWxzIHRvPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICAgICBiZSBwcm92aXNpb25lZCB0byBhbHdheXMgYmUgc2lsZW50LCBldmVu IHdoZW4gdGhlIGhlYWQgaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg ICBiZSBwcm92aXNpb25lZCB0byBhbHdheXMgYmUgc2lsZW50LCBldmVuIHdoZW4gdGhlIGhlYWQg aXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgIHNvbGljaXRpbmcgdHJhZmZp YyBmcm9tIHRoZSB0YWlscy4gIFRoaXMgY2FuIGJlIHVzZWZ1bCwgZm9yPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgc29saWNpdGluZyB0cmFmZmljIGZyb20gdGhlIHRh aWxzLiAgVGhpcyBjYW4gYmUgdXNlZnVsLCBmb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTQiIGNsYXNzPSJjaGFuZ2UiPjx0ZD48L3Rk Pjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTQiPjxlbT4gcGFnZSA4LCBs aW5lIDI1PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90 aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC00Ij48ZW0+IHBhZ2UgOSwg bGluZSAxOTxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgICAgIFNldCB0byAxIGlmIGEgdGFpbCByZWNlaXZlcyBhIHVuaWNhc3QgQkZE IENvbnRyb2wgcGFja2V0IGZyb208L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICAgICBTZXQgdG8gMSBpZiBhIHRhaWwgcmVjZWl2ZXMgYSB1bmljYXN0IEJGRCBDb250cm9sIHBh Y2tldCBmcm9tPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICB0aGUgaGVhZC4g IFRoaXMgdmFyaWFibGUgTVVTVCBiZSBzZXQgdG8gemVybyBpZiB0aGUgc2Vzc2lvbjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgIHRoZSBoZWFkLiAgVGhpcyB2YXJpYWJs ZSBNVVNUIGJlIHNldCB0byB6ZXJvIGlmIHRoZSBzZXNzaW9uPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICAgICB0cmFuc2l0aW9ucyBmcm9tIFVwIHN0YXRlIHRvIHNvbWUgb3RoZXIg c3RhdGUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgdHJhbnNpdGlv bnMgZnJvbSBVcCBzdGF0ZSB0byBzb21lIG90aGVyIHN0YXRlLjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICAgICBUaGlzIHZhcmlhYmxlIE1VU1QgYmUgaW5pdGlhbGl6ZWQg dG8gemVyby48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICBUaGlzIHZh cmlhYmxlIE1VU1QgYmUgaW5pdGlhbGl6ZWQgdG8gemVyby48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICAgVGhpcyB2YXJpYWJsZSBpcyBvbmx5IHBlcnRpbmVudCB3aGVu IGJmZC5TZXNzaW9uVHlwZSBpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg ICAgIFRoaXMgdmFyaWFibGUgaXMgb25seSBwZXJ0aW5lbnQgd2hlbiBiZmQuU2Vzc2lvblR5cGUg aXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgIE11bHRpcG9pbnRUYWlsLjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgIE11bHRpcG9pbnRUYWlsLjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYw MDMzIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPjQ8L3NwYW4+LjMuMi4gIE5ldyBT dGF0ZSBWYXJpYWJsZSBWYWx1ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh biBjbGFzcz0iaW5zZXJ0Ij42PC9zcGFuPi4zLjIuICBOZXcgU3RhdGUgVmFyaWFibGUgVmFsdWU8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQSBuZXcgc3RhdGUgdmFyaWFibGUg dmFsdWUgYmVpbmcgYWRkZWQgdG86PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg QSBuZXcgc3RhdGUgdmFyaWFibGUgdmFsdWUgYmVpbmcgYWRkZWQgdG86PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGJmZC5TZXNzaW9uVHlwZTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIGJmZC5TZXNzaW9uVHlwZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICBUaGUgdHlwZSBvZiB0aGlzIHNlc3Npb24gYXMgZGVmaW5lZCBpbiBbUkZD Nzg4MF0uICBBIG5ldyB2YWx1ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg IFRoZSB0eXBlIG9mIHRoaXMgc2Vzc2lvbiBhcyBkZWZpbmVkIGluIFtSRkM3ODgwXS4gIEEgbmV3 IHZhbHVlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBpbnRyb2R1Y2VkIGlzOjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGludHJvZHVjZWQgaXM6PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgIE11bHRpcG9pbnRDbGllbnQ6IEEg c2Vzc2lvbiBvbiB0aGUgaGVhZCB0aGF0IHRyYWNrcyB0aGUgc3RhdGU8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICBNdWx0aXBvaW50Q2xpZW50OiBBIHNlc3Npb24gb24g dGhlIGhlYWQgdGhhdCB0cmFja3MgdGhlIHN0YXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICAgICBvZiBhbiBpbmRpdmlkdWFsIHRhaWwsIHdoZW4gZGVzaXJhYmxlLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgIG9mIGFuIGluZGl2aWR1YWwgdGFpbCwg d2hlbiBkZXNpcmFibGUuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIFRo aXMgdmFyaWFibGUgTVVTVCBiZSBpbml0aWFsaXplZCB0byB0aGUgYXBwcm9wcmlhdGUgdHlwZSB3 aGVuIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIFRoaXMgdmFyaWFi bGUgTVVTVCBiZSBpbml0aWFsaXplZCB0byB0aGUgYXBwcm9wcmlhdGUgdHlwZSB3aGVuIHRoZTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAzNCI+ PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICAgICBzZXNzaW9uIGlzIGNyZWF0ZWQsIGFjY29yZGluZyB0byB0aGUgcnVs ZXMgaW4gc2VjdGlvbiA0LjxzcGFuIGNsYXNzPSJkZWxldGUiPjEzPC9zcGFuPiBvZjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICBzZXNzaW9uIGlzIGNyZWF0ZWQsIGFjY29y ZGluZyB0byB0aGUgcnVsZXMgaW4gc2VjdGlvbiA0LjxzcGFuIGNsYXNzPSJpbnNlcnQiPjQ8L3Nw YW4+IG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBbSS1ELmlldGYtYmZkLW11 bHRpcG9pbnRdLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIFtJLUQuaWV0 Zi1iZmQtbXVsdGlwb2ludF0uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0ciBpZD0iZGlmZjAwMzUiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ NDwvc3Bhbj4uMy4zLiAgU3RhdGUgVmFyaWFibGUgSW5pdGlhbGl6YXRpb24gYW5kIE1haW50ZW5h bmNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PjY8L3NwYW4+LjMuMy4gIFN0YXRlIFZhcmlhYmxlIEluaXRpYWxpemF0aW9uIGFuZCBNYWludGVu YW5jZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9 ImRpZmYwMDM2Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFNvbWUgc3RhdGUgdmFyaWFibGVzIGRlZmluZWQgaW4g c2VjdGlvbiA2LjguMSBvZiA8c3BhbiBjbGFzcz0iZGVsZXRlIj50aGU8L3NwYW4+IFtSRkM1ODgw XSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5uZWVkczwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgU29tZSBzdGF0ZSB2YXJpYWJsZXMgZGVmaW5lZCBpbiBzZWN0aW9uIDYu OC4xIG9mIFtSRkM1ODgwXSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5uZWVkPC9zcGFuPiB0byBiZTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB0byBiZSBpbml0aWFsaXplZCBvciBtYW5p cHVsYXRlZCBkaWZmZXJlbnRseSBkZXBlbmRpbmcgb24gdGhlIHNlc3Npb248L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgaW5pdGlhbGl6ZWQgb3IgbWFuaXB1bGF0ZWQgZGlmZmVy ZW50bHkgZGVwZW5kaW5nIG9uIHRoZSBzZXNzaW9uIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnR5cGUu PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVs ZXRlIj50eXBlPC9zcGFuPiAoc2VlIHNlY3Rpb24gNC40LjIgb2YgW0ktRC5pZXRmLWJmZC1tdWx0 aXBvaW50XSkuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgIFRoZSB2YWx1ZXMgb2Ygc29tZSBvZiB0aGVzZSB2YXJpYWJsZXMgcmVsYXRlIHRv IHRob3NlIG9mIHRoZSBzYW1lPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAg dmFyaWFibGVzIG9mIGEgTXVsdGlwb2ludEhlYWQgc2Vzc2lvbjwvc3Bhbj4gKHNlZSBzZWN0aW9u IDQuNC4yIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICBbSS1ELmlldGYtYmZkLW11bHRpcG9pbnRdKS48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgYmZkLkxvY2FsRGlzY3I8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBiZmQuTG9jYWxEaXNjcjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICBGb3Igc2Vzc2lvbiB0eXBlIE11bHRpcG9pbnRDbGll bnQsIHRoaXMgdmFyaWFibGUgTVVTVCBhbHdheXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICAgICBGb3Igc2Vzc2lvbiB0eXBlIE11bHRpcG9pbnRDbGllbnQsIHRoaXMgdmFy aWFibGUgTVVTVCBhbHdheXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgIG1h dGNoIHRoZSB2YWx1ZSBvZiBiZmQuTG9jYWxEaXNjciBpbiB0aGUgYXNzb2NpYXRlZDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgIG1hdGNoIHRoZSB2YWx1ZSBvZiBiZmQu TG9jYWxEaXNjciBpbiB0aGUgYXNzb2NpYXRlZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICAgTXVsdGlwb2ludEhlYWQgc2Vzc2lvbi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICAgICBNdWx0aXBvaW50SGVhZCBzZXNzaW9uLjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBiZmQuRGVzaXJlZE1pblR4SW50ZXJ2YWw8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBiZmQuRGVzaXJlZE1pblR4SW50ZXJ2YWw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMzciPjx0 ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvc3Bhbj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICAgICBGb3Igc2Vzc2lvbiB0eXBlIE11bHRpcG9pbnRDbGllbnQsIHRoaXMgdmFyaWFi bGUgTVVTVCBhbHdheXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICBG b3Igc2Vzc2lvbiB0eXBlIE11bHRpcG9pbnRDbGllbnQsIHRoaXMgdmFyaWFibGUgTVVTVCBhbHdh eXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgIG1hdGNoIHRoZSB2YWx1ZSBv ZiBiZmQuRGVzaXJlZE1pblR4SW50ZXJ2YWwgaW4gdGhlIGFzc29jaWF0ZWQ8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICBtYXRjaCB0aGUgdmFsdWUgb2YgYmZkLkRlc2ly ZWRNaW5UeEludGVydmFsIGluIHRoZSBhc3NvY2lhdGVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgICAgICBNdWx0aXBvaW50SGVhZCBzZXNzaW9uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgICAgIE11bHRpcG9pbnRIZWFkIHNlc3Npb24uPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGJmZC5SZXF1aXJlZE1pblJ4SW50ZXJ2YWw8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBiZmQuUmVxdWlyZWRNaW5SeEludGVy dmFsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0i ZGlmZjAwMzgiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgSXQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+c2hv dWxkPC9zcGFuPiBiZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5ub3RlZCB0aGF0IGZvciBzZXNzaW9u cyBvZiB0eXBlIE11bHRpcG9pbnRUYWlsLDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgICAgICAgSXQgPHNwYW4gY2xhc3M9Imluc2VydCI+TUFZPC9zcGFuPiBiZSA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zZXQgdG8gemVybyBhdDwvc3Bhbj4gdGhlIDxzcGFuIGNsYXNz PSJpbnNlcnQiPmhlYWQgQkZEIHN5c3RlbSB0byBzdXBwcmVzczwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgICAgdGhpcyB2YXJp YWJsZSBvbmx5IGFmZmVjdHM8L3NwYW4+IHRoZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5yYXRlIG9m IHVuaWNhc3QgUG9sbHMgc2VudCBieTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgdHJhZmZpYyBmcm9tPC9zcGFuPiB0 aGUgPHNwYW4gY2xhc3M9Imluc2VydCI+dGFpbHMuICBTZXR0aW5nIGl0IHRvIHplcm8gaW48L3Nw YW4+IHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICB0aGUgPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+aGVhZDs8L3NwYW4+IHRoZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5yYXRl IG9mIG11bHRpcG9pbnQgcGFja2V0cyBpcyBuZWNlc3NhcmlseTwvc3Bhbj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgPHNwYW4gY2xhc3M9Imluc2VydCI+TXVsdGlw b2ludEhlYWQgc2Vzc2lvbiBzdXBwcmVzc2VzIHRyYWZmaWMgZnJvbSBhbGwgdGFpbHMsIHRoZTwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ ICAgICAgICAgdW5hZmZlY3RlZCBieSBpdC48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgIHNldHRpbmcgaW4gYSBNdWx0 aXBvaW50Q2xpZW50IHNlc3Npb24gc3VwcHJlc3NlcyB0cmFmZmljIGZyb20gYTwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgIHNpbmdsZSB0YWlsLjwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgYmZkLkRlbWFuZE1vZGU8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBiZmQuRGVtYW5kTW9kZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICBUaGlzIHZhcmlhYmxlIE1VU1QgYmUgaW5p dGlhbGl6ZWQgdG8gMSBmb3Igc2Vzc2lvbiB0eXBlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgICAgIFRoaXMgdmFyaWFibGUgTVVTVCBiZSBpbml0aWFsaXplZCB0byAxIGZv ciBzZXNzaW9uIHR5cGVzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICBNdWx0 aXBvaW50Q2xpZW50LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgIE11 bHRpcG9pbnRDbGllbnQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGJm ZC5EZXRlY3RNdWx0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgYmZkLkRl dGVjdE11bHQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgRm9yIHNl c3Npb24gdHlwZSBNdWx0aXBvaW50Q2xpZW50LCB0aGlzIHZhcmlhYmxlIE1VU1QgYWx3YXlzPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgRm9yIHNlc3Npb24gdHlwZSBN dWx0aXBvaW50Q2xpZW50LCB0aGlzIHZhcmlhYmxlIE1VU1QgYWx3YXlzPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICAgICBtYXRjaCB0aGUgdmFsdWUgb2YgYmZkLkRldGVjdE11bHQg aW4gdGhlIGFzc29jaWF0ZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg ICBtYXRjaCB0aGUgdmFsdWUgb2YgYmZkLkRldGVjdE11bHQgaW4gdGhlIGFzc29jaWF0ZWQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgIE11bHRpcG9pbnRIZWFkIHNlc3Npb24u PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgTXVsdGlwb2ludEhlYWQg c2Vzc2lvbi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy IGlkPSJkaWZmMDAzOSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj40PC9zcGFuPi40 LiAgQ29udHJvbGxpbmcgTXVsdGlwb2ludCBCRkQgT3B0aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij42PC9zcGFuPi40LiAgQ29udHJvbGxp bmcgTXVsdGlwb2ludCBCRkQgT3B0aW9uczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBUaGUgc3RhdGUgdmFyaWFibGVzIGRlZmluZWQgYWJvdmUgYXJlIHVzZWQgdG8gY2hvb3Nl IHdoaWNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIHN0YXRlIHZhcmlh YmxlcyBkZWZpbmVkIGFib3ZlIGFyZSB1c2VkIHRvIGNob29zZSB3aGljaDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgb3BlcmF0aW9uYWwgb3B0aW9ucyBhcmUgYWN0aXZlLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9wZXJhdGlvbmFsIG9wdGlvbnMgYXJlIGFjdGl2 ZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIG1vc3QgYmFzaWMgZm9y bSBvZiBvcGVyYXRpb24sIGFzIGV4cGxhaW5lZCBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIFRoZSBtb3N0IGJhc2ljIGZvcm0gb2Ygb3BlcmF0aW9uLCBhcyBleHBsYWluZWQg aW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtJLUQuaWV0Zi1iZmQtbXVsdGlwb2lu dF0sIGluIHdoaWNoIEJGRCBDb250cm9sIHBhY2tldHMgZmxvdyBvbmx5PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgW0ktRC5pZXRmLWJmZC1tdWx0aXBvaW50XSwgaW4gd2hpY2gg QkZEIENvbnRyb2wgcGFja2V0cyBmbG93IG9ubHk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIGZyb20gdGhlIGhlYWQgYW5kIG5vIHRyYWNraW5nIGlzIGRlc2lyZWQgb2YgdGFpbCBzdGF0 ZSBhdCB0aGUgaGVhZCw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBmcm9tIHRo ZSBoZWFkIGFuZCBubyB0cmFja2luZyBpcyBkZXNpcmVkIG9mIHRhaWwgc3RhdGUgYXQgdGhlIGhl YWQsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpcyBhY2NvbXBsaXNoZWQgYnkgc2V0 dGluZyBiZmQuUmVwb3J0VGFpbERvd24gdG8gMCBpbiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBpcyBhY2NvbXBsaXNoZWQgYnkgc2V0dGluZyBiZmQuUmVwb3J0VGFpbERv d24gdG8gMCBpbiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 ciBpZD0iZGlmZjAwNDAiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgTXVsdGlwb2ludEhlYWQgc2Vzc2lvbiAoU2Vj dGlvbiA8c3BhbiBjbGFzcz0iZGVsZXRlIj4zPC9zcGFuPi4xKS48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgTXVsdGlwb2ludEhlYWQgc2Vzc2lvbiAoU2VjdGlvbiA8c3BhbiBj bGFzcz0iaW5zZXJ0Ij41PC9zcGFuPi4xKS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDA0MSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBJZiB0aGUgaGVh ZCB3aXNoZXMgdG8ga25vdyA8c3BhbiBjbGFzcz0iZGVsZXRlIj50aGUgaWRlbnRpdHk8L3NwYW4+ IG9mIHRoZSB0YWlscywgaXQgc2VuZHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgSWYgdGhlIGhlYWQgd2lzaGVzIHRvIGtub3cgb2YgPHNwYW4gY2xhc3M9Imluc2VydCI+YWN0 aXZlPC9zcGFuPiB0aGUgdGFpbHMsIGl0IHNlbmRzIG11bHRpcG9pbnQ8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgbXVsdGlwb2ludCBQb2xscyBhcyBuZWVkZWQuICBQcmV2aW91c2x5 IGtub3duIHRhaWxzIHRoYXQgZG9uJ3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgUG9sbHMgYXMgbmVlZGVkLiAgUHJldmlvdXNseSBrbm93biB0YWlscyB0aGF0IGRvbid0IHJl c3BvbmQgdG8gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHJlc3BvbmQgdG8g dGhlIFBvbGxzIHdpbGwgYmUgZGV0ZWN0ZWQgKGFzIHBlciBTZWN0aW9uIDxzcGFuIGNsYXNzPSJk ZWxldGUiPjMuMykuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBQ b2xscyB3aWxsIGJlIGRldGVjdGVkIChhcyBwZXIgU2VjdGlvbiA8c3BhbiBjbGFzcz0iaW5zZXJ0 Ij41LjIuMikuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHIgaWQ9ImRpZmYwMDQyIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIElmIHRoZSBoZWFkIHdpc2hlcyB0 byA8c3BhbiBjbGFzcz0iZGVsZXRlIj5iZSBub3RpZmllZCBieTwvc3Bhbj4gdGhlIHRhaWxzIHdo ZW4gdGhleSBsb3NlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIElmIHRoZSBo ZWFkIHdpc2hlcyB0byA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5yZXF1ZXN0IGEgbm90aWZpY2F0aW9u IGZyb208L3NwYW4+IHRoZSB0YWlscyB3aGVuIHRoZXk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgY29ubmVjdGl2aXR5LCBpdCBzZXRzIGJmZC5SZXBvcnRUYWlsRG93biB0byAxIGlu IGVpdGhlciB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgbG9zZSBjb25u ZWN0aXZpdHksIGl0IHNldHMgYmZkLlJlcG9ydFRhaWxEb3duIHRvIDEgaW4gZWl0aGVyIHRoZTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgTXVsdGlwb2ludEhlYWQgc2Vzc2lvbiAoaWYg c3VjaCBub3RpZmljYXRpb24gaXMgZGVzaXJlZCBmcm9tIGFsbDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIE11bHRpcG9pbnRIZWFkIHNlc3Npb24gKGlmIHN1Y2ggbm90aWZpY2F0 aW9uIGlzIGRlc2lyZWQgZnJvbSBhbGw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRh aWxzKSBvciBpbiB0aGUgTXVsdGlwb2ludENsaWVudCBzZXNzaW9uIChpZiBub3RpZmljYXRpb24g aXMgZGVzaXJlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRhaWxzKSBvciBp biB0aGUgTXVsdGlwb2ludENsaWVudCBzZXNzaW9uIChpZiBub3RpZmljYXRpb24gaXMgZGVzaXJl ZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZnJvbSBhIHBhcnRpY3VsYXIgdGFpbCku ICBOb3RlIHRoYXQgdGhlIHNldHRpbmcgb2YgdGhpcyB2YXJpYWJsZSBpbiBhPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZnJvbSBhIHBhcnRpY3VsYXIgdGFpbCkuICBOb3RlIHRo YXQgdGhlIHNldHRpbmcgb2YgdGhpcyB2YXJpYWJsZSBpbiBhPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBNdWx0aXBvaW50Q2xpZW50IHNlc3Npb24gZm9yIGEgcGFydGljdWxhciB0YWls IG92ZXJyaWRlcyB0aGUgc2V0dGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IE11bHRpcG9pbnRDbGllbnQgc2Vzc2lvbiBmb3IgYSBwYXJ0aWN1bGFyIHRhaWwgb3ZlcnJpZGVz IHRoZSBzZXR0aW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbiB0aGUgTXVsdGlw b2ludEhlYWQgc2Vzc2lvbi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbiB0 aGUgTXVsdGlwb2ludEhlYWQgc2Vzc2lvbi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgSWYgdGhlIGhlYWQgd2lzaGVzIHRvIHZlcmlmeSB0aGUgc3RhdGUgb2YgYSB0YWlsIG9u IGFuIG9uZ29pbmcgYmFzaXMsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSWYg dGhlIGhlYWQgd2lzaGVzIHRvIHZlcmlmeSB0aGUgc3RhdGUgb2YgYSB0YWlsIG9uIGFuIG9uZ29p bmcgYmFzaXMsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpdCBzZW5kcyBhIFBvbGwg U2VxdWVuY2UgZnJvbSB0aGUgTXVsdGlwb2ludENsaWVudCBzZXNzaW9uIGFzc29jaWF0ZWQ8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpdCBzZW5kcyBhIFBvbGwgU2VxdWVuY2Ug ZnJvbSB0aGUgTXVsdGlwb2ludENsaWVudCBzZXNzaW9uIGFzc29jaWF0ZWQ8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwNDMiPjx0ZD48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgd2l0aCB0aGF0IHRhaWwgYXMgbmVlZGVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICB3aXRoIHRoYXQgdGFpbCBhcyBuZWVkZWQuICBUaGlzIGhhcyB0aGUgZWZmZWN0IG9m IGVsaW1pbmF0aW5nIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGluaXRpYWwgZGVsYXks IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjYuMTMuMyw8L3NwYW4+ IHRoYXQgdGhlIHRhaWwgd291bGQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNw YW4gY2xhc3M9ImRlbGV0ZSI+SWYgdGhlIGhlYWQgd2FudHMgdG8gbW9yZSBxdWlja2x5IGJlIGFs ZXJ0ZWQgdG8gYSBzZXNzaW9uIGZhaWx1cmU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIG90aGVyd2lzZSBpbnNlcnQgcHJpb3IgdG8gdHJhbnNtaXNzaW9uIG9mIHRo ZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5wYWNrZXQgdGh1cyB0aGUgaGVhZDwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgZnJvbSBhIHBh cnRpY3VsYXIgdGFpbCwgaXQgc2VuZHMgYSBCRkQgQ29udHJvbCBwYWNrZXQgZnJvbSB0aGU8L3Nw YW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgIG1heSBoYXZlIG5vdGlmaWNhdGlvbiBvZiB0aGUgc2Vzc2lvbiBmYWlsdXJlIG1vcmUgcXVp Y2tseSB3aGVuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFz cz0iZGVsZXRlIj4gICBNdWx0aXBvaW50Q2xpZW50IHNlc3Npb24gYXNzb2NpYXRlZCB3aXRoIHRo YXQgdGFpbC48L3NwYW4+ICBUaGlzIGhhcyB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgY29tcGFyaW5nIHdpdGggdXNlIG9mIG0tcG9s bC48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGVmZmVjdCBvZiBlbGlt aW5hdGluZyB0aGUgaW5pdGlhbCBkZWxheSwgZGVzY3JpYmVkIGluIFNlY3Rpb24gPHNwYW4gY2xh c3M9ImRlbGV0ZSI+NC4xMy4zLDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHRoYXQgdGhlIHRhaWwgd291bGQg b3RoZXJ3aXNlIGluc2VydCBwcmlvciB0byB0cmFuc21pc3Npb24gb2YgdGhlPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8 c3BhbiBjbGFzcz0iZGVsZXRlIj5wYWNrZXQuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSWYgYSB0YWls IHdpc2hlcyB0byBvcGVyYXRlIHNpbGVudGx5IChzZW5kaW5nIG5vIEJGRCBDb250cm9sIHBhY2tl dHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJZiBhIHRhaWwgd2lzaGVzIHRv IG9wZXJhdGUgc2lsZW50bHkgKHNlbmRpbmcgbm8gQkZEIENvbnRyb2wgcGFja2V0czwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdG8gdGhlIGhlYWQpIGl0IHNldHMgYmZkLlNpbGVudFRh aWwgdG8gMSBpbiB0aGUgTXVsdGlwb2ludFRhaWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICB0byB0aGUgaGVhZCkgaXQgc2V0cyBiZmQuU2lsZW50VGFpbCB0byAxIGluIHRoZSBN dWx0aXBvaW50VGFpbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc2Vzc2lvbi4gIFRo aXMgYWxsb3dzIGEgdGFpbCB0byBiZSBzaWxlbnQgaW5kZXBlbmRlbnQgb2YgdGhlIHNldHRpbmdz PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc2Vzc2lvbi4gIFRoaXMgYWxsb3dz IGEgdGFpbCB0byBiZSBzaWxlbnQgaW5kZXBlbmRlbnQgb2YgdGhlIHNldHRpbmdzPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvbiB0aGUgaGVhZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBvbiB0aGUgaGVhZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDA0NCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0i ZGVsZXRlIj40PC9zcGFuPi41LiAgU3RhdGUgTWFjaGluZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij42PC9zcGFuPi41LiAgU3RhdGUgTWFjaGlu ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRp ZmYwMDQ1Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPlRoZTwvc3Bhbj4gc3Rh dGUgbWFjaGluZSBmb3Igc2Vzc2lvbiBvZiB0eXBlIE11bHRpcG9pbnRDbGllbnQgaXMgc2FtZSA8 c3BhbiBjbGFzcz0iZGVsZXRlIj5hczwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+VGhvdWdoIHRoZSBzdGF0ZSB0cmFuc2l0aW9u cyBmb3IgdGhlIHN0YXRlIG1hY2hpbmUsIGFzIGRlZmluZWQgaW48L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIGRlZmluZWQgaW4gc2Vj dGlvbiA0LjUgb2YgW0ktRC5pZXRmLWJmZC1tdWx0aXBvaW50XS48L3NwYW4+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHNlY3Rpb24gNS41 IG9mIFtJLUQuaWV0Zi1iZmQtbXVsdGlwb2ludF0sIGZvciBhIHNlc3Npb24gdHlwZTwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIE11bHRpcG9pbnRIZWFkIGFyZSBvbmx5IGFk bWluaXN0cmF0aXZlbHkgZHJpdmVuIHRoZTwvc3Bhbj4gc3RhdGUgbWFjaGluZSBmb3I8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmE8L3NwYW4+IHNlc3Npb24gb2YgdHlwZSBNdWx0aXBv aW50Q2xpZW50IGlzIHNhbWUgPHNwYW4gY2xhc3M9Imluc2VydCI+YW5kIHRoZSBkaWFncmFtIGlz PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgYXBwbGljYWJsZS48L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlm ZjAwNDYiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+NDwvc3Bhbj4uNi4gIFNlc3Np b24gRXN0YWJsaXNobWVudDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij42PC9zcGFuPi42LiAgU2Vzc2lvbiBFc3RhYmxpc2htZW50PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIElmIEJGRCBDb250cm9sIHBhY2tldHMgYXJlIHJl Y2VpdmVkIGF0IHRoZSBoZWFkLCB0aGV5IGFyZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIElmIEJGRCBDb250cm9sIHBhY2tldHMgYXJlIHJlY2VpdmVkIGF0IHRoZSBoZWFkLCB0 aGV5IGFyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGVtdWx0aXBsZXhlZCB0byBz ZXNzaW9ucyBvZiB0eXBlIE11bHRpcG9pbnRDbGllbnQsIHdoaWNoIHJlcHJlc2VudDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRlbXVsdGlwbGV4ZWQgdG8gc2Vzc2lvbnMgb2Yg dHlwZSBNdWx0aXBvaW50Q2xpZW50LCB3aGljaCByZXByZXNlbnQ8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIHRoZSBzZXQgb2YgdGFpbHMgdGhhdCB0aGUgaGVhZCBpcyBpbnRlcmVzdGVk IGluIHRyYWNraW5nLiAgVGhlc2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0 aGUgc2V0IG9mIHRhaWxzIHRoYXQgdGhlIGhlYWQgaXMgaW50ZXJlc3RlZCBpbiB0cmFja2luZy4g IFRoZXNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzZXNzaW9ucyB3aWxsIHR5cGlj YWxseSBhbHNvIGJlIGVzdGFibGlzaGVkIGR5bmFtaWNhbGx5IGJhc2VkIG9uIHRoZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNlc3Npb25zIHdpbGwgdHlwaWNhbGx5IGFsc28g YmUgZXN0YWJsaXNoZWQgZHluYW1pY2FsbHkgYmFzZWQgb24gdGhlPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICByZWNlaXB0IG9mIEJGRCBDb250cm9sIHBhY2tldHMuICBUaGUgaGVhZCBo YXMgYnJvYWQgbGF0aXR1ZGUgaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBy ZWNlaXB0IG9mIEJGRCBDb250cm9sIHBhY2tldHMuICBUaGUgaGVhZCBoYXMgYnJvYWQgbGF0aXR1 ZGUgaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNob29zaW5nIHdoaWNoIHRhaWxz IHRvIHRyYWNrLCBpZiBhbnksIHdpdGhvdXQgYWZmZWN0aW5nIHRoZSBiYXNpYzwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNob29zaW5nIHdoaWNoIHRhaWxzIHRvIHRyYWNrLCBp ZiBhbnksIHdpdGhvdXQgYWZmZWN0aW5nIHRoZSBiYXNpYzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgb3BlcmF0aW9uIG9mIHRoZSBwcm90b2NvbC4gIFRoZSBoZWFkIGRpcmVjdGx5IGNv bnRyb2xzIHdoZXRoZXIgb3Igbm90PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg b3BlcmF0aW9uIG9mIHRoZSBwcm90b2NvbC4gIFRoZSBoZWFkIGRpcmVjdGx5IGNvbnRyb2xzIHdo ZXRoZXIgb3Igbm90PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIg aWQ9ImRpZmYwMDQ3Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHRhaWxzIGFyZSBhbGxvd2VkIHRvIHNlbmQgQkZE IENvbnRyb2wgcGFja2V0cyBiYWNrIHRvIHRoZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5oZWFkLjwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgdGFpbHMgYXJlIGFsbG93 ZWQgdG8gc2VuZCBCRkQgQ29udHJvbCBwYWNrZXRzIGJhY2sgdG8gdGhlIDxzcGFuIGNsYXNzPSJp bnNlcnQiPmhlYWQgYnk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBzZXR0 aW5nIGJmZC5SZXF1aXJlZE1pblJ4SW50ZXJ2YWwgdG8gemVybyBpbiBhIE11bHRpcG9pbnRIZWFk IG9yIGE8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBNdWx0aXBvaW50Q2xp ZW50IHNlc3Npb24uPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHIgaWQ9ImRpZmYwMDQ4Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUi PjQ8L3NwYW4+LjcuICBEaXNjcmltaW5hdG9ycyBhbmQgUGFja2V0IERlbXVsdGlwbGV4aW5nPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjY8L3Nw YW4+LjcuICBEaXNjcmltaW5hdG9ycyBhbmQgUGFja2V0IERlbXVsdGlwbGV4aW5nPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFdoZW4gdGhlIHRhaWxzIHNlbmQgQkZEIENvbnRy b2wgcGFja2V0cyB0byB0aGUgaGVhZCBmcm9tIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIFdoZW4gdGhlIHRhaWxzIHNlbmQgQkZEIENvbnRyb2wgcGFja2V0cyB0byB0aGUg aGVhZCBmcm9tIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgTXVsdGlwb2ludFRh aWwgc2Vzc2lvbiwgdGhlIGNvbnRlbnRzIG9mIFlvdXIgRGlzY3IgKHRoZSBkaXNjcmltaW5hdG9y PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTXVsdGlwb2ludFRhaWwgc2Vzc2lv biwgdGhlIGNvbnRlbnRzIG9mIFlvdXIgRGlzY3IgKHRoZSBkaXNjcmltaW5hdG9yPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZWNlaXZlZCBmcm9tIHRoZSBoZWFkKSB3aWxsIG5vdCBi ZSBzdWZmaWNpZW50IGZvciB0aGUgaGVhZCB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIHJlY2VpdmVkIGZyb20gdGhlIGhlYWQpIHdpbGwgbm90IGJlIHN1ZmZpY2llbnQgZm9y IHRoZSBoZWFkIHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZW11bHRpcGxleCB0 aGUgcGFja2V0LCBzaW5jZSB0aGUgc2FtZSB2YWx1ZSB3aWxsIGJlIHJlY2VpdmVkIGZyb208L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkZW11bHRpcGxleCB0aGUgcGFja2V0LCBz aW5jZSB0aGUgc2FtZSB2YWx1ZSB3aWxsIGJlIHJlY2VpdmVkIGZyb208L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIGFsbCB0YWlscyBvbiB0aGUgbXVsdGljYXN0IHRyZWUuICBJbiB0aGlz IGNhc2UsIHRoZSBoZWFkIE1VU1Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBh bGwgdGFpbHMgb24gdGhlIG11bHRpY2FzdCB0cmVlLiAgSW4gdGhpcyBjYXNlLCB0aGUgaGVhZCBN VVNUPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZW11bHRpcGxleCBwYWNrZXRzIGJh c2VkIG9uIHRoZSBzb3VyY2UgYWRkcmVzcyBhbmQgdGhlIHZhbHVlIG9mIFlvdXI8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkZW11bHRpcGxleCBwYWNrZXRzIGJhc2VkIG9uIHRo ZSBzb3VyY2UgYWRkcmVzcyBhbmQgdGhlIHZhbHVlIG9mIFlvdXI8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIERpc2NyLCB3aGljaCB0b2dldGhlciB1bmlxdWVseSBpZGVudGlmeSB0aGUg dGFpbCBhbmQgdGhlIG11bHRpcG9pbnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBEaXNjciwgd2hpY2ggdG9nZXRoZXIgdW5pcXVlbHkgaWRlbnRpZnkgdGhlIHRhaWwgYW5kIHRo ZSBtdWx0aXBvaW50PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwYXRoLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHBhdGguPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIFdoZW4gdGhlIGhlYWQgc2VuZHMgdW5pY2FzdCBCRkQgQ29udHJvbCBwYWNr ZXRzIHRvIGEgdGFpbCBmcm9tIGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBX aGVuIHRoZSBoZWFkIHNlbmRzIHVuaWNhc3QgQkZEIENvbnRyb2wgcGFja2V0cyB0byBhIHRhaWwg ZnJvbSBhPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBNdWx0aXBvaW50Q2xpZW50IHNl c3Npb24sIHRoZSB2YWx1ZSBvZiBZb3VyIERpc2NyIHdpbGwgYmUgdmFsaWQsIGFuZDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIE11bHRpcG9pbnRDbGllbnQgc2Vzc2lvbiwgdGhl IHZhbHVlIG9mIFlvdXIgRGlzY3Igd2lsbCBiZSB2YWxpZCwgYW5kPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICB0aGUgdGFpbCBNVVNUIGRlbXVsdGlwbGV4IHRoZSBwYWNrZXQgYmFzZWQg c29sZWx5IG9uIFlvdXIgRGlzY3IuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg dGhlIHRhaWwgTVVTVCBkZW11bHRpcGxleCB0aGUgcGFja2V0IGJhc2VkIHNvbGVseSBvbiBZb3Vy IERpc2NyLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIg aWQ9ImRpZmYwMDQ5Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPjQ8L3NwYW4+Ljgu ICBDb250cm9sbGluZyBUYWlsIFBhY2tldCBUcmFuc21pc3Npb248L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+Njwvc3Bhbj4uOC4gIENvbnRyb2xs aW5nIFRhaWwgUGFja2V0IFRyYW5zbWlzc2lvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBBcyB0aGUgZmFuLWluIGZyb20gdGhlIHRhaWxzIHRvIHRoZSBoZWFkIG1heSBiZSB2 ZXJ5IGxhcmdlLCBpdCBpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEFzIHRo ZSBmYW4taW4gZnJvbSB0aGUgdGFpbHMgdG8gdGhlIGhlYWQgbWF5IGJlIHZlcnkgbGFyZ2UsIGl0 IGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjcml0aWNhbCB0aGF0IHRoZSBmbG93 IG9mIEJGRCBDb250cm9sIHBhY2tldHMgZnJvbSB0aGUgdGFpbHMgaXM8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBjcml0aWNhbCB0aGF0IHRoZSBmbG93IG9mIEJGRCBDb250cm9s IHBhY2tldHMgZnJvbSB0aGUgdGFpbHMgaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IGNvbnRyb2xsZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY29udHJvbGxl ZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGhlYWQgYWx3YXlzIG9w ZXJhdGVzIGluIERlbWFuZCBtb2RlLiAgVGhpcyBtZWFucyB0aGF0IG5vIHRhaWw8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgaGVhZCBhbHdheXMgb3BlcmF0ZXMgaW4gRGVt YW5kIG1vZGUuICBUaGlzIG1lYW5zIHRoYXQgbm8gdGFpbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgd2lsbCBzZW5kIGFuIGFzeW5jaHJvbm91cyBCRkQgQ29udHJvbCBwYWNrZXQgYXMg bG9uZyBhcyB0aGUgc2Vzc2lvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHdp bGwgc2VuZCBhbiBhc3luY2hyb25vdXMgQkZEIENvbnRyb2wgcGFja2V0IGFzIGxvbmcgYXMgdGhl IHNlc3Npb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGlzIFVwLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGlzIFVwLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBUaGUgdmFsdWUgb2YgUmVxdWlyZWQgTWluIFJ4IEludGVydmFsIHJlY2VpdmVk IGJ5IGEgdGFpbCBpbiBhIHVuaWNhc3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBUaGUgdmFsdWUgb2YgUmVxdWlyZWQgTWluIFJ4IEludGVydmFsIHJlY2VpdmVkIGJ5IGEgdGFp bCBpbiBhIHVuaWNhc3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEJGRCBDb250cm9s IHBhY2tldCwgaWYgYW55LCBhbHdheXMgdGFrZXMgcHJlY2VkZW5jZSBvdmVyIHRoZSB2YWx1ZTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEJGRCBDb250cm9sIHBhY2tldCwgaWYg YW55LCBhbHdheXMgdGFrZXMgcHJlY2VkZW5jZSBvdmVyIHRoZSB2YWx1ZTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgcmVjZWl2ZWQgaW4gTXVsdGlwb2ludCBCRkQgQ29udHJvbCBwYWNr ZXRzLiAgVGhpcyBhbGxvd3MgdGhlIHBhY2tldDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIHJlY2VpdmVkIGluIE11bHRpcG9pbnQgQkZEIENvbnRyb2wgcGFja2V0cy4gIFRoaXMg YWxsb3dzIHRoZSBwYWNrZXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJhdGUgZnJv bSBpbmRpdmlkdWFsIHRhaWxzIHRvIGJlIGNvbnRyb2xsZWQgc2VwYXJhdGVseSBhcyBkZXNpcmVk IGJ5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmF0ZSBmcm9tIGluZGl2aWR1 YWwgdGFpbHMgdG8gYmUgY29udHJvbGxlZCBzZXBhcmF0ZWx5IGFzIGRlc2lyZWQgYnk8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNlbmRpbmcgYSBCRkQgQ29udHJvbCBwYWNrZXQgZnJv bSB0aGUgY29ycmVzcG9uZGluZyBNdWx0aXBvaW50Q2xpZW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgc2VuZGluZyBhIEJGRCBDb250cm9sIHBhY2tldCBmcm9tIHRoZSBjb3Jy ZXNwb25kaW5nIE11bHRpcG9pbnRDbGllbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHNlc3Npb24uICBUaGlzIGFsc28gZWxpbWluYXRlcyB0aGUgcmFuZG9tIGRlbGF5LCBhcyBkaXNj dXNzZWQgaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzZXNzaW9uLiAgVGhp cyBhbHNvIGVsaW1pbmF0ZXMgdGhlIHJhbmRvbSBkZWxheSwgYXMgZGlzY3Vzc2VkIGluPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDUwIj48dGQ+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgIFNlY3Rpb24gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+NDwvc3Bhbj4uMTMuMywgcHJp b3IgdG8gdHJhbnNtaXNzaW9uIGZyb20gdGhlIHRhaWwgdGhhdCB3b3VsZDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICBTZWN0aW9uIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjY8L3Nw YW4+LjEzLjMsIHByaW9yIHRvIHRyYW5zbWlzc2lvbiBmcm9tIHRoZSB0YWlsIHRoYXQgd291bGQ8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG90aGVyd2lzZSBiZSBpbnNlcnRlZCwgcmVk dWNpbmcgdGhlIGxhdGVuY3kgb2YgcmVwb3J0aW5nIGEgZmFpbHVyZSB0bzwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIG90aGVyd2lzZSBiZSBpbnNlcnRlZCwgcmVkdWNpbmcgdGhl IGxhdGVuY3kgb2YgcmVwb3J0aW5nIGEgZmFpbHVyZSB0bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgdGhlIGhlYWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhl IGhlYWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIElmIHRoZSBoZWFkIHdp c2hlcyB0byBzdXBwcmVzcyB0cmFmZmljIGZyb20gdGhlIHRhaWxzIHdoZW4gdGhleTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIElmIHRoZSBoZWFkIHdpc2hlcyB0byBzdXBwcmVz cyB0cmFmZmljIGZyb20gdGhlIHRhaWxzIHdoZW4gdGhleTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgZGV0ZWN0IGEgc2Vzc2lvbiBmYWlsdXJlLCBpdCBNQVkgc2V0IGJmZC5SZXF1aXJl ZE1pblJ4SW50ZXJ2YWwgdG88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkZXRl Y3QgYSBzZXNzaW9uIGZhaWx1cmUsIGl0IE1BWSBzZXQgYmZkLlJlcXVpcmVkTWluUnhJbnRlcnZh bCB0bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgemVybywgd2hpY2ggaXMgYSByZXNl cnZlZCB2YWx1ZSB0aGF0IGluZGljYXRlcyB0aGF0IHRoZSBzZW5kZXIgd2lzaGVzPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgemVybywgd2hpY2ggaXMgYSByZXNlcnZlZCB2YWx1 ZSB0aGF0IGluZGljYXRlcyB0aGF0IHRoZSBzZW5kZXIgd2lzaGVzPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICB0byByZWNlaXZlIG5vIHBlcmlvZGljIHRyYWZmaWMuICBUaGlzIGNhbiBi ZSBzZXQgaW4gdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdG8gcmVjZWl2 ZSBubyBwZXJpb2RpYyB0cmFmZmljLiAgVGhpcyBjYW4gYmUgc2V0IGluIHRoZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgTXVsdGlwb2ludEhlYWQgc2Vzc2lvbiAoc3VwcHJlc3Npbmcg dHJhZmZpYyBmcm9tIGFsbCB0YWlscykgb3IgaXQgY2FuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgTXVsdGlwb2ludEhlYWQgc2Vzc2lvbiAoc3VwcHJlc3NpbmcgdHJhZmZpYyBm cm9tIGFsbCB0YWlscykgb3IgaXQgY2FuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBi ZSBzZXQgaW4gYSBNdWx0aXBvaW50Q2xpZW50IHNlc3Npb24gKHN1cHByZXNzaW5nIHRyYWZmaWMg ZnJvbSBvbmx5IGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBiZSBzZXQgaW4g YSBNdWx0aXBvaW50Q2xpZW50IHNlc3Npb24gKHN1cHByZXNzaW5nIHRyYWZmaWMgZnJvbSBvbmx5 IGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNpbmdsZSB0YWlsKS48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzaW5nbGUgdGFpbCkuPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIEFueSB0YWlsIG1heSBiZSBwcm92aXNpb25lZCB0byBuZXZlciBz ZW5kICphbnkqIEJGRCBDb250cm9sIHBhY2tldHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBBbnkgdGFpbCBtYXkgYmUgcHJvdmlzaW9uZWQgdG8gbmV2ZXIgc2VuZCAqYW55KiBC RkQgQ29udHJvbCBwYWNrZXRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0byB0aGUg aGVhZCBieSBzZXR0aW5nIGJmZC5TaWxlbnRUYWlsIHRvIDEuICBUaGlzIHByb3ZpZGVzIGE8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0byB0aGUgaGVhZCBieSBzZXR0aW5nIGJm ZC5TaWxlbnRUYWlsIHRvIDEuICBUaGlzIHByb3ZpZGVzIGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwNTEiPjx0ZD48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgbWVjaGFu aXNtIGJ5IHdoaWNoIG9ubHkgYSBzdWJzZXQgb2YgdGFpbHMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ cmVwb3J0PC9zcGFuPiB0aGVpciBzZXNzaW9uIHN0YXR1czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICBtZWNoYW5pc20gYnkgd2hpY2ggb25seSBhIHN1YnNldCBvZiB0YWlscyA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5yZXBvcnRzPC9zcGFuPiB0aGVpciBzZXNzaW9uPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHRvIHRoZSBoZWFkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICBzdGF0dXMgdG8gdGhlIGhlYWQuPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwNTIiPjx0ZD48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNw YW4gY2xhc3M9ImRlbGV0ZSI+NDwvc3Bhbj4uOS4gIFNvbGljaXRpbmcgdGhlIFRhaWxzPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjY8L3NwYW4+ LjkuICBTb2xpY2l0aW5nIHRoZSBUYWlsczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDUzIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIElmIHRoZSBoZWFk IHdpc2hlcyB0byBrbm93IDxzcGFuIGNsYXNzPSJkZWxldGUiPnRoZSBpZGVudGl0aWVzPC9zcGFu PiBvZiB0aGUgdGFpbHMsIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBJ ZiB0aGUgaGVhZCB3aXNoZXMgdG8ga25vdyBvZiB0aGUgPHNwYW4gY2xhc3M9Imluc2VydCI+YWN0 aXZlPC9zcGFuPiB0YWlscywgdGhlIE11bHRpcG9pbnRIZWFkPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgIE11bHRpcG9pbnRIZWFkIHNlc3Npb24gTUFZIHNlbmQgYSBCRkQgQ29udHJv bCBwYWNrZXQgYXMgc3BlY2lmaWVkIGluPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIHNlc3Npb24gTUFZIHNlbmQgYSBCRkQgQ29udHJvbCBwYWNrZXQgYXMgc3BlY2lmaWVkIGlu IFNlY3Rpb24gPHNwYW4gY2xhc3M9Imluc2VydCI+Ni4xMy4zLDwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgU2VjdGlvbiA8c3BhbiBjbGFzcz0iZGVsZXRlIj40LjEzLjMs PC9zcGFuPiB3aXRoIHRoZSBQb2xsIChQKSBiaXQgc2V0IHRvIDEuICBUaGlzIHdpbGwgY2F1c2Ug YWxsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHdpdGggdGhlIFBvbGwgKFAp IGJpdCBzZXQgdG8gMS4gIFRoaXMgd2lsbCBjYXVzZSBhbGwgb2YgdGhlIHRhaWxzIHRvPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIG9mIHRoZSB0YWlscyB0byByZXBseSB3aXRoIGEg dW5pY2FzdCBCRkQgQ29udHJvbCBQYWNrZXQsIHJhbmRvbWl6ZWQ8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgcmVwbHkgd2l0aCBhIHVuaWNhc3QgQkZEIENvbnRyb2wgUGFja2V0 LCByYW5kb21pemVkIGFjcm9zcyBvbmUgcGFja2V0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgIGFjcm9zcyBvbmUgcGFja2V0IGludGVydmFsLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICBpbnRlcnZhbC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgVGhlIGRlY2lzaW9uIGFzIHRvIHdoZW4gdG8gc2VuZCBhIG11bHRpcG9pbnQgUG9sbCBpcyBv dXRzaWRlIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBkZWNpc2lv biBhcyB0byB3aGVuIHRvIHNlbmQgYSBtdWx0aXBvaW50IFBvbGwgaXMgb3V0c2lkZSB0aGU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4g IEhvd2V2ZXIsIGl0IG11c3QgbmV2ZXIgYmUgc2VudCBtb3JlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLiAgSG93ZXZlciwgaXQg bXVzdCBuZXZlciBiZSBzZW50IG1vcmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9m dGVuIHRoYW4gdGhlIHJlZ3VsYXIgbXVsdGlwb2ludCBCRkQgQ29udHJvbCBwYWNrZXQuICBTaW5j ZSB0aGUgdGFpbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9mdGVuIHRoYW4g dGhlIHJlZ3VsYXIgbXVsdGlwb2ludCBCRkQgQ29udHJvbCBwYWNrZXQuICBTaW5jZSB0aGUgdGFp bDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgd2lsbCB0cmVhdCBhIG11bHRpcG9pbnQg UG9sbCBsaWtlIGFueSBvdGhlciBtdWx0aXBvaW50IEJGRCBDb250cm9sPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgd2lsbCB0cmVhdCBhIG11bHRpcG9pbnQgUG9sbCBsaWtlIGFu eSBvdGhlciBtdWx0aXBvaW50IEJGRCBDb250cm9sPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBwYWNrZXQsIFBvbGxzIG1heSBiZSBzZW50IGluIGxpZXUgb2Ygbm9uLVBvbGwgcGFja2V0 cy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwYWNrZXQsIFBvbGxzIG1heSBi ZSBzZW50IGluIGxpZXUgb2Ygbm9uLVBvbGwgcGFja2V0cy48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDA1NCI+PHRkPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBT b2xpY2l0aW5nIHRoZSB0YWlscyBhbHNvIHN0YXJ0cyB0aGUgRGV0ZWN0aW9uIFRpbWVyIGZvciBl YWNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFNvbGljaXRpbmcgdGhlIHRh aWxzIGFsc28gc3RhcnRzIHRoZSBEZXRlY3Rpb24gVGltZXIgZm9yIGVhY2ggPHNwYW4gY2xhc3M9 Imluc2VydCI+b2YgdGhlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBh c3NvY2lhdGVkIE11bHRpcG9pbnRDbGllbnQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+c2Vzc2lvbiw8 L3NwYW4+IHdoaWNoIHdpbGwgY2F1c2UgdGhvc2Ugc2Vzc2lvbnM8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgYXNzb2NpYXRlZCBNdWx0aXBvaW50Q2xpZW50IDxzcGFuIGNsYXNz PSJpbnNlcnQiPnNlc3Npb25zLDwvc3Bhbj4gd2hpY2ggd2lsbCBjYXVzZSB0aG9zZSBzZXNzaW9u czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdG8gdGltZSBvdXQgaWYgdGhlIGFzc29j aWF0ZWQgdGFpbHMgZG8gbm90IHJlc3BvbmQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgdG8gdGltZSBvdXQgaWYgdGhlIGFzc29jaWF0ZWQgdGFpbHMgZG8gbm90IHJlc3BvbmQu PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE5vdGUgdGhhdCBmb3IgdGhpcyBt ZWNoYW5pc20gdG8gd29yayBwcm9wZXJseSwgdGhlIERldGVjdGlvbiBUaW1lPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTm90ZSB0aGF0IGZvciB0aGlzIG1lY2hhbmlzbSB0byB3 b3JrIHByb3Blcmx5LCB0aGUgRGV0ZWN0aW9uIFRpbWU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICh3aGljaCBpcyBlcXVhbCB0byBiZmQuRGVzaXJlZE1pblR4SW50ZXJ2YWwpIE1VU1Qg YmUgZ3JlYXRlciB0aGFuIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICh3 aGljaCBpcyBlcXVhbCB0byBiZmQuRGVzaXJlZE1pblR4SW50ZXJ2YWwpIE1VU1QgYmUgZ3JlYXRl ciB0aGFuIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcm91bmQgdHJpcCB0aW1l IG9mIEJGRCBDb250cm9sIHBhY2tldHMgZnJvbSB0aGUgaGVhZCB0byB0aGUgdGFpbCAodmlhPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcm91bmQgdHJpcCB0aW1lIG9mIEJGRCBD b250cm9sIHBhY2tldHMgZnJvbSB0aGUgaGVhZCB0byB0aGUgdGFpbCAodmlhPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDU1Ij48dGQ+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIHRoZSBtdWx0aXBvaW50IHBhdGgpIGFuZCBiYWNrICh2aWEgYSB1bmljYXN0IHBhdGgpLiAg U2VlIFNlY3Rpb24gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+NDwvc3Bhbj4uMTE8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgdGhlIG11bHRpcG9pbnQgcGF0aCkgYW5kIGJhY2sgKHZp YSBhIHVuaWNhc3QgcGF0aCkuICBTZWUgU2VjdGlvbiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij42PC9z cGFuPi4xMTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZm9yIG1vcmUgZGV0YWlscy48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBmb3IgbW9yZSBkZXRhaWxzLjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDU2 Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPjQ8L3NwYW4+LjEwLiAgVmVyaWZ5aW5n IENvbm5lY3Rpdml0eSB0byBTcGVjaWZpYyBUYWlsczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij42PC9zcGFuPi4xMC4gIFZlcmlmeWluZyBDb25u ZWN0aXZpdHkgdG8gU3BlY2lmaWMgVGFpbHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgSWYgdGhlIGhlYWQgd2lzaGVzIHRvIHZlcmlmeSBjb25uZWN0aXZpdHkgdG8gYSBzcGVj aWZpYyB0YWlsLCB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJZiB0aGUg aGVhZCB3aXNoZXMgdG8gdmVyaWZ5IGNvbm5lY3Rpdml0eSB0byBhIHNwZWNpZmljIHRhaWwsIHRo ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29ycmVzcG9uZGluZyBNdWx0aXBvaW50 Q2xpZW50IHNlc3Npb24gTUFZIHNlbmQgYSBCRkQgUG9sbCBTZXF1ZW5jZTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvcnJlc3BvbmRpbmcgTXVsdGlwb2ludENsaWVudCBzZXNz aW9uIE1BWSBzZW5kIGEgQkZEIFBvbGwgU2VxdWVuY2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIHRvIHNhaWQgdGFpbC4gIFRoaXMgbWlnaHQgYmUgZG9uZSBpbiByZWFjdGlvbiB0byB0 aGUgZXhwaXJhdGlvbiBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRvIHNh aWQgdGFpbC4gIFRoaXMgbWlnaHQgYmUgZG9uZSBpbiByZWFjdGlvbiB0byB0aGUgZXhwaXJhdGlv biBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIERldGVjdGlvbiBUaW1lciAo dGhlIHRhaWwgZGlkbid0IHJlc3BvbmQgdG8gYSBtdWx0aXBvaW50IFBvbGwpLDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSBEZXRlY3Rpb24gVGltZXIgKHRoZSB0YWlsIGRp ZG4ndCByZXNwb25kIHRvIGEgbXVsdGlwb2ludCBQb2xsKSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIG9yIGl0IG1pZ2h0IGJlIGRvbmUgb24gYSBwcm9hY3RpdmUgYmFzaXMuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb3IgaXQgbWlnaHQgYmUgZG9uZSBvbiBhIHBy b2FjdGl2ZSBiYXNpcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGlu dGVydmFsIGJldHdlZW4gdHJhbnNtaXR0ZWQgcGFja2V0cyBpbiB0aGUgUG9sbCBTZXF1ZW5jZSBN VVNUIGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGludGVydmFsIGJl dHdlZW4gdHJhbnNtaXR0ZWQgcGFja2V0cyBpbiB0aGUgUG9sbCBTZXF1ZW5jZSBNVVNUIGJlPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjYWxjdWxhdGVkIGFzIHNwZWNpZmllZCBpbiB0 aGUgYmFzZSBCRkQgc3BlY2lmaWNhdGlvbiBbUkZDNTg4MF0gKHRoZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIGNhbGN1bGF0ZWQgYXMgc3BlY2lmaWVkIGluIHRoZSBiYXNlIEJG RCBzcGVjaWZpY2F0aW9uIFtSRkM1ODgwXSAodGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBncmVhdGVyIG9mIGJmZC5EZXNpcmVkTWluVHhJbnRlcnZhbCBhbmQgYmZkLlJlbW90ZU1p blJ4SW50ZXJ2YWwpLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGdyZWF0ZXIg b2YgYmZkLkRlc2lyZWRNaW5UeEludGVydmFsIGFuZCBiZmQuUmVtb3RlTWluUnhJbnRlcnZhbCku PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSB2YWx1ZSB0cmFuc21pdHRl ZCBpbiBSZXF1aXJlZCBNaW4gUlggSW50ZXJ2YWwgd2lsbCBiZSB1c2VkIGJ5IHRoZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSB2YWx1ZSB0cmFuc21pdHRlZCBpbiBSZXF1 aXJlZCBNaW4gUlggSW50ZXJ2YWwgd2lsbCBiZSB1c2VkIGJ5IHRoZTwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgdGFpbCAocmF0aGVyIHRoYW4gdGhlIHZhbHVlIHJlY2VpdmVkIGluIGFu eSBtdWx0aXBvaW50IHBhY2tldCkgd2hlbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIHRhaWwgKHJhdGhlciB0aGFuIHRoZSB2YWx1ZSByZWNlaXZlZCBpbiBhbnkgbXVsdGlwb2lu dCBwYWNrZXQpIHdoZW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGl0IHRyYW5zbWl0 cyBCRkQgQ29udHJvbCBwYWNrZXRzIHRvIHRoZSBoZWFkIG5vdGlmeWluZyBpdCBvZiBhPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaXQgdHJhbnNtaXRzIEJGRCBDb250cm9sIHBh Y2tldHMgdG8gdGhlIGhlYWQgbm90aWZ5aW5nIGl0IG9mIGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwNTciPjx0ZD48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgc2Vzc2lv biBmYWlsdXJlPHNwYW4gY2xhc3M9ImRlbGV0ZSI+LDwvc3Bhbj4gYW5kIHRoZSB0cmFuc21pdHRl ZCBwYWNrZXRzIHdpbGwgbm90IGJlIGRlbGF5ZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgIHNlc3Npb24gZmFpbHVyZSBhbmQgdGhlIHRyYW5zbWl0dGVkIHBhY2tldHMgd2ls bCBub3QgYmUgZGVsYXllZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgdmFs dWUgY2FuIHBvdGVudGlhbGx5IGJlIHNldCBtdWNoIGxvd2VyIHRoYW4gaW4gdGhlIG11bHRpcG9p bnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIHZhbHVlIGNhbiBwb3Rl bnRpYWxseSBiZSBzZXQgbXVjaCBsb3dlciB0aGFuIGluIHRoZSBtdWx0aXBvaW50PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDU4Ij48dGQ+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgIGNhc2UsIGluIG9yZGVyIHRvIHNwZWVkIHVwIG5vdGlmaWNhdGlvbiB0byB0aGUgaGVh ZCwgc2luY2UgdGhlIHZhbHVlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGNh c2UsIGluIG9yZGVyIHRvIHNwZWVkIHVwIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmE8L3NwYW4+IG5v dGlmaWNhdGlvbiB0byB0aGUgaGVhZCwgc2luY2UgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgIHdpbGwgYmUgdXNlZCBvbmx5IGJ5IHRoZSBzaW5nbGUgdGFpbC4gIFRoaXMgdmFs dWUgKGFuZCB0aGUgbGFjayBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICB2 YWx1ZSB3aWxsIGJlIHVzZWQgb25seSBieSB0aGUgc2luZ2xlIHRhaWwuICBUaGlzIHZhbHVlIChh bmQgdGhlIGxhY2s8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgZGVsYXkpIGFyZSAi c3RpY2t5IiwgaW4gdGhhdCBvbmNlIHRoZSB0YWlsIHJlY2VpdmVzIGl0LCBpdCB3aWxsPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIG9mIGRlbGF5KSBhcmUgInN0aWNreSIsIGlu IHRoYXQgb25jZSB0aGUgdGFpbCByZWNlaXZlcyBpdCwgaXQgd2lsbDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgY29udGludWUgdG8gdXNlIGl0IGluZGVmaW5pdGVseS4gIFRoZXJlZm9y ZSwgaWYgdGhlIGhlYWQgbm8gbG9uZ2VyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgY29udGludWUgdG8gdXNlIGl0IGluZGVmaW5pdGVseS4gIFRoZXJlZm9yZSwgaWYgdGhlIGhl YWQgbm8gbG9uZ2VyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3aXNoZXMgdG8gc2lu Z2xlIG91dCB0aGUgdGFpbCwgaXQgU0hPVUxEIHJlc2V0IHRoZSB0aW1lciB0byB0aGU8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3aXNoZXMgdG8gc2luZ2xlIG91dCB0aGUgdGFp bCwgaXQgU0hPVUxEIHJlc2V0IHRoZSB0aW1lciB0byB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIGRlZmF1bHQgYnkgc2VuZGluZyBhIFBvbGwgU2VxdWVuY2Ugd2l0aCB0aGUgc2Ft ZSB2YWx1ZSBvZiBSZXF1aXJlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRl ZmF1bHQgYnkgc2VuZGluZyBhIFBvbGwgU2VxdWVuY2Ugd2l0aCB0aGUgc2FtZSB2YWx1ZSBvZiBS ZXF1aXJlZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgTWluIFJ4IEludGVydmFsIGFz IGlzIGNhcnJpZWQgaW4gdGhlIG11bHRpcG9pbnQgcGFja2V0cywgb3IgaXQgTUFZPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTWluIFJ4IEludGVydmFsIGFzIGlzIGNhcnJpZWQg aW4gdGhlIG11bHRpcG9pbnQgcGFja2V0cywgb3IgaXQgTUFZPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICByZXNldCB0aGUgdGFpbCBzZXNzaW9uIGJ5IHNlbmRpbmcgYSBQb2xsIFNlcXVl bmNlIHdpdGggc3RhdGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICByZXNldCB0 aGUgdGFpbCBzZXNzaW9uIGJ5IHNlbmRpbmcgYSBQb2xsIFNlcXVlbmNlIHdpdGggc3RhdGU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEFkbWluRG93biAoYWZ0ZXIgdGhlIGNvbXBsZXRp b24gb2Ygd2hpY2ggdGhlIHNlc3Npb24gd2lsbCBjb21lIGJhY2s8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBBZG1pbkRvd24gKGFmdGVyIHRoZSBjb21wbGV0aW9uIG9mIHdoaWNo IHRoZSBzZXNzaW9uIHdpbGwgY29tZSBiYWNrPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICB1cCkuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdXApLjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBOb3RlIHRoYXQgYSBmYWlsdXJlIG9mIHRoZSBoZWFk IHRvIHJlY2VpdmUgYSByZXNwb25zZSB0byBhIFBvbGw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBOb3RlIHRoYXQgYSBmYWlsdXJlIG9mIHRoZSBoZWFkIHRvIHJlY2VpdmUgYSBy ZXNwb25zZSB0byBhIFBvbGw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFNlcXVlbmNl IGRvZXMgbm90IG5lY2Vzc2FyaWx5IG1lYW4gdGhhdCB0aGUgdGFpbCBoYXMgbG9zdCBtdWx0aXBv aW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgU2VxdWVuY2UgZG9lcyBub3Qg bmVjZXNzYXJpbHkgbWVhbiB0aGF0IHRoZSB0YWlsIGhhcyBsb3N0IG11bHRpcG9pbnQ8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNvbm5lY3Rpdml0eSwgdGhvdWdoIGEgcmVwbHkgdG8g YSBQb2xsIFNlcXVlbmNlIGRvZXMgcmVsaWFibHk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBjb25uZWN0aXZpdHksIHRob3VnaCBhIHJlcGx5IHRvIGEgUG9sbCBTZXF1ZW5jZSBk b2VzIHJlbGlhYmx5PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbmRpY2F0ZSBjb25u ZWN0aXZpdHkgb3IgbGFjayB0aGVyZW9mIChieSB2aXJ0dWUgb2YgdGhlIHRhaWwncyBzdGF0ZTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGluZGljYXRlIGNvbm5lY3Rpdml0eSBv ciBsYWNrIHRoZXJlb2YgKGJ5IHZpcnR1ZSBvZiB0aGUgdGFpbCdzIHN0YXRlPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBub3QgYmVpbmcgVXAgaW4gdGhlIEJGRCBDb250cm9sIHBhY2tl dCkuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbm90IGJlaW5nIFVwIGluIHRo ZSBCRkQgQ29udHJvbCBwYWNrZXQpLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDU5Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxl dGUiPjQ8L3NwYW4+LjExLiAgRGV0ZWN0aW9uIFRpbWVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjY8L3NwYW4+LjExLiAgRGV0ZWN0aW9uIFRp bWVzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0i ZGlmZjAwNjAiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgTXVsdGlwb2ludENsaWVudCBzZXNzaW9ucyBhdCB0aGUg aGVhZCBhcmUgYWx3YXlzIGluIERlbWFuZCBtb2RlLCBhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgTXVsdGlwb2ludENsaWVudCBzZXNzaW9ucyBhdCB0aGUgaGVhZCBhcmUg YWx3YXlzIGluIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnRoZTwvc3Bhbj4gRGVtYW5kIG1vZGUsPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGFzIHN1Y2ggb25seSBjYXJlIGFib3V0IGRl dGVjdGlvbiB0aW1lIGluIHR3byBjYXNlcy4gIEZpcnN0LCBpZiBhPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgIGFuZCBhcyBzdWNoIG9ubHkgY2FyZSBhYm91dCBkZXRlY3Rpb24g dGltZSBpbiB0d28gY2FzZXMuICBGaXJzdCwgaWYgYTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgUG9sbCBTZXF1ZW5jZSBpcyBiZWluZyBzZW50IG9uIGEgTXVsdGlwb2ludENsaWVudCBz ZXNzaW9uLCB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQb2xsIFNlcXVl bmNlIGlzIGJlaW5nIHNlbnQgb24gYSBNdWx0aXBvaW50Q2xpZW50IHNlc3Npb24sIHRoZTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGV0ZWN0aW9uIHRpbWUgb24gdGhpcyBzZXNzaW9u IGlzIGNhbGN1bGF0ZWQgYWNjb3JkaW5nIHRvIHRoZSBiYXNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgZGV0ZWN0aW9uIHRpbWUgb24gdGhpcyBzZXNzaW9uIGlzIGNhbGN1bGF0 ZWQgYWNjb3JkaW5nIHRvIHRoZSBiYXNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBC RkQgc3BlY2lmaWNhdGlvbiBbUkZDNTg4MF0sIHRoYXQgaXMsIHRoZSB0cmFuc21pc3Npb24gaW50 ZXJ2YWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBCRkQgc3BlY2lmaWNhdGlv biBbUkZDNTg4MF0sIHRoYXQgaXMsIHRoZSB0cmFuc21pc3Npb24gaW50ZXJ2YWw8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG11bHRpcGxpZWQgYnkgYmZkLkRldGVjdE11bHQuICBTZWNv bmQsIHdoZW4gYSBtdWx0aXBvaW50IFBvbGwgaXMgc2VudDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIG11bHRpcGxpZWQgYnkgYmZkLkRldGVjdE11bHQuICBTZWNvbmQsIHdoZW4g YSBtdWx0aXBvaW50IFBvbGwgaXMgc2VudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg dG8gc29saWNpdCB0YWlsIHJlcGxpZXMsIHRoZSBkZXRlY3Rpb24gdGltZSBvbiBhbGwgYXNzb2Np YXRlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRvIHNvbGljaXQgdGFpbCBy ZXBsaWVzLCB0aGUgZGV0ZWN0aW9uIHRpbWUgb24gYWxsIGFzc29jaWF0ZWQ8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIE11bHRpcG9pbnRDbGllbnQgc2Vzc2lvbnMgdGhhdCBhcmVuJ3Qg Y3VycmVudGx5IHNlbmRpbmcgUG9sbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IE11bHRpcG9pbnRDbGllbnQgc2Vzc2lvbnMgdGhhdCBhcmVuJ3QgY3VycmVudGx5IHNlbmRpbmcg UG9sbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU2VxdWVuY2VzIGlzIHNldCB0byBh IHZhbHVlIGdyZWF0ZXIgdGhhbiBvciBlcXVhbCB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIFNlcXVlbmNlcyBpcyBzZXQgdG8gYSB2YWx1ZSBncmVhdGVyIHRoYW4gb3IgZXF1 YWwgdG88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGJmZC5SZXF1aXJlZE1pblJ4SW50 ZXJ2YWwgKG9uZSBwYWNrZXQgdGltZSkuICBUaGlzIHZhbHVlIGNhbiBiZSBtYWRlPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYmZkLlJlcXVpcmVkTWluUnhJbnRlcnZhbCAob25l IHBhY2tldCB0aW1lKS4gIFRoaXMgdmFsdWUgY2FuIGJlIG1hZGU8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGFyYml0cmFyaWx5IGxhcmdlIGluIG9yZGVyIHRvIGVuc3VyZSB0aGF0IHRo ZSBkZXRlY3Rpb24gdGltZSBpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFy Yml0cmFyaWx5IGxhcmdlIGluIG9yZGVyIHRvIGVuc3VyZSB0aGF0IHRoZSBkZXRlY3Rpb24gdGlt ZSBpczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZ3JlYXRlciB0aGFuIHRoZSByb3Vu ZCB0cmlwIHRpbWUgb2YgYSBCRkQgQ29udHJvbCBwYWNrZXQgYmV0d2VlbiB0aGU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBncmVhdGVyIHRoYW4gdGhlIHJvdW5kIHRyaXAgdGlt ZSBvZiBhIEJGRCBDb250cm9sIHBhY2tldCBiZXR3ZWVuIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgaGVhZCBhbmQgdGhlIHRhaWwgd2l0aCBubyBpbGwgZWZmZWN0cywgb3RoZXIg dGhhbiBkZWxheWluZyB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBoZWFk IGFuZCB0aGUgdGFpbCB3aXRoIG5vIGlsbCBlZmZlY3RzLCBvdGhlciB0aGFuIGRlbGF5aW5nIHRo ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGV0ZWN0aW9uIG9mIHVucmVzcG9uc2l2 ZSB0YWlscy4gIE5vdGUgdGhhdCBhIGRldGVjdGlvbiB0aW1lPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgZGV0ZWN0aW9uIG9mIHVucmVzcG9uc2l2ZSB0YWlscy4gIE5vdGUgdGhh dCBhIGRldGVjdGlvbiB0aW1lPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBleHBpcmF0 aW9uIG9uIGEgTXVsdGlwb2ludENsaWVudCBzZXNzaW9uIGF0IHRoZSBoZWFkLCB3aGlsZTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGV4cGlyYXRpb24gb24gYSBNdWx0aXBvaW50 Q2xpZW50IHNlc3Npb24gYXQgdGhlIGhlYWQsIHdoaWxlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBpbmRpY2F0aW5nIGEgQkZEIHNlc3Npb24gZmFpbHVyZSwgY2Fubm90IGJlIGNvbnN0 cnVlZCB0byBtZWFuIHRoYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbmRp Y2F0aW5nIGEgQkZEIHNlc3Npb24gZmFpbHVyZSwgY2Fubm90IGJlIGNvbnN0cnVlZCB0byBtZWFu IHRoYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSB0YWlsIGlzIG5vdCBoZWFy aW5nIG11bHRpcG9pbnQgcGFja2V0cyBmcm9tIHRoZSBoZWFkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIHRoZSB0YWlsIGlzIG5vdCBoZWFyaW5nIG11bHRpcG9pbnQgcGFja2V0 cyBmcm9tIHRoZSBoZWFkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHIgaWQ9ImRpZmYwMDYxIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPjQ8 L3NwYW4+LjEyLiAgTXVsdGlwb2ludENsaWVudCBEb3duL0FkbWluRG93biBTZXNzaW9uczwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij42PC9zcGFu Pi4xMi4gIE11bHRpcG9pbnRDbGllbnQgRG93bi9BZG1pbkRvd24gU2Vzc2lvbnM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSWYgdGhlIE11bHRpcG9pbnRIZWFkIHNlc3Npb24g aXMgZ29pbmcgZG93biAod2hpY2ggb25seSBoYXBwZW5zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgSWYgdGhlIE11bHRpcG9pbnRIZWFkIHNlc3Npb24gaXMgZ29pbmcgZG93biAo d2hpY2ggb25seSBoYXBwZW5zPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhZG1pbmlz dHJhdGl2ZWx5KSwgYWxsIGFzc29jaWF0ZWQgTXVsdGlwb2ludENsaWVudCBzZXNzaW9ucyBTSE9V TEQgYmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhZG1pbmlzdHJhdGl2ZWx5 KSwgYWxsIGFzc29jaWF0ZWQgTXVsdGlwb2ludENsaWVudCBzZXNzaW9ucyBTSE9VTEQgYmU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRlc3Ryb3llZCBhcyB0aGV5IGFyZSBzdXBlcmZs dW91cy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkZXN0cm95ZWQgYXMgdGhl eSBhcmUgc3VwZXJmbHVvdXMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIElm IGEgTXVsdGlwb2ludENsaWVudCBzZXNzaW9uIGdvZXMgZG93biBkdWUgdG8gdGhlIHJlY2VpcHQg b2YgYW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJZiBhIE11bHRpcG9pbnRD bGllbnQgc2Vzc2lvbiBnb2VzIGRvd24gZHVlIHRvIHRoZSByZWNlaXB0IG9mIGFuPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB1bnNvbGljaXRlZCBCRkQgQ29udHJvbCBwYWNrZXQgZnJv bSB0aGUgdGFpbCB3aXRoIHN0YXRlIERvd24gb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICB1bnNvbGljaXRlZCBCRkQgQ29udHJvbCBwYWNrZXQgZnJvbSB0aGUgdGFpbCB3aXRo IHN0YXRlIERvd24gb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEFkbWluRG93biAo bm90IGluIHJlc3BvbnNlIHRvIGEgUG9sbCksIGFuZCB0YWlsIGNvbm5lY3Rpdml0eTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEFkbWluRG93biAobm90IGluIHJlc3BvbnNlIHRv IGEgUG9sbCksIGFuZCB0YWlsIGNvbm5lY3Rpdml0eTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgdmVyaWZpY2F0aW9uIGlzIG5vdCBiZWluZyBkb25lLCB0aGUgc2Vzc2lvbiBNQVkgYmUg ZGVzdHJveWVkLiAgSWY8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB2ZXJpZmlj YXRpb24gaXMgbm90IGJlaW5nIGRvbmUsIHRoZSBzZXNzaW9uIE1BWSBiZSBkZXN0cm95ZWQuICBJ ZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdmVyaWZpY2F0aW9uIGlzIGRlc2lyZWQs IHRoZSBzZXNzaW9uIFNIT1VMRCBzZW5kIGEgUG9sbCBTZXF1ZW5jZSBhbmQ8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB2ZXJpZmljYXRpb24gaXMgZGVzaXJlZCwgdGhlIHNlc3Np b24gU0hPVUxEIHNlbmQgYSBQb2xsIFNlcXVlbmNlIGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgdGhlIHNlc3Npb24gU0hPVUxEIGJlIG1haW50YWluZWQuPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhlIHNlc3Npb24gU0hPVUxEIGJlIG1haW50YWluZWQuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIElmIHRoZSB0YWlsIHJlcGxpZXMgdG8g YSBQb2xsIFNlcXVlbmNlIHdpdGggc3RhdGUgRG93biBvciBBZG1pbkRvd24sPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSWYgdGhlIHRhaWwgcmVwbGllcyB0byBhIFBvbGwgU2Vx dWVuY2Ugd2l0aCBzdGF0ZSBEb3duIG9yIEFkbWluRG93biw8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIGl0IG1lYW5zIHRoYXQgdGhlIHRhaWwgc2Vzc2lvbiBpcyBkZWZpbml0ZWx5IGRv d24uICBJbiB0aGlzIGNhc2UsIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGl0IG1lYW5zIHRoYXQgdGhlIHRhaWwgc2Vzc2lvbiBpcyBkZWZpbml0ZWx5IGRvd24uICBJbiB0 aGlzIGNhc2UsIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc2Vzc2lvbiBNQVkg YmUgZGVzdHJveWVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNlc3Npb24g TUFZIGJlIGRlc3Ryb3llZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSWYg dGhlIERldGVjdGlvbiBUaW1lIGV4cGlyZXMgb24gYSBNdWx0aXBvaW50Q2xpZW50IHNlc3Npb24g KG1lYW5pbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJZiB0aGUgRGV0ZWN0 aW9uIFRpbWUgZXhwaXJlcyBvbiBhIE11bHRpcG9pbnRDbGllbnQgc2Vzc2lvbiAobWVhbmluZzwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhhdCB0aGUgdGFpbCBkaWQgbm90IHJlcGx5 IHRvIGEgUG9sbCBTZXF1ZW5jZSkgdGhlIHNlc3Npb24gTUFZIGJlPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgdGhhdCB0aGUgdGFpbCBkaWQgbm90IHJlcGx5IHRvIGEgUG9sbCBT ZXF1ZW5jZSkgdGhlIHNlc3Npb24gTUFZIGJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBkZXN0cm95ZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGVzdHJveWVk LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRp ZmYwMDYyIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPjQuMTMuICBCYXNlIEJGRDwv c3Bhbj4gU3BlY2lmaWNhdGlvbiBUZXh0IFJlcGxhY2VtZW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjYuMTMuICBCYXNlIEJGRCBmb3IgTXVs dGlwb2ludCBOZXR3b3Jrczwvc3Bhbj4gU3BlY2lmaWNhdGlvbiBUZXh0IFJlcGxhY2VtZW50PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAw NjMiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgVGhlIGZvbGxvd2luZyBzZWN0aW9ucyBhcmUgbWVhbnQgdG8gPHNw YW4gY2xhc3M9ImRlbGV0ZSI+cmVwbGFjZTwvc3Bhbj4gdGhlIGNvcnJlc3BvbmRpbmc8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVGhlIGZvbGxvd2luZyBzZWN0aW9ucyBhcmUg bWVhbnQgdG8gPHNwYW4gY2xhc3M9Imluc2VydCI+ZXh0ZW5kPC9zcGFuPiB0aGUgY29ycmVzcG9u ZGluZyBzZWN0aW9uczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBzZWN0aW9ucyBp biB0aGUgYmFzZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5zcGVjaWZpY2F0aW9ucyBbUkZDNTg4MF0g YW5kPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBpbiB0aGUgYmFz ZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5CRkQgZm9yIE11bHRpcG9pbnQgTmV0d29ya3Mgc3BlY2lm aWNhdGlvbjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtJLUQuaWV0Zi1i ZmQtbXVsdGlwb2ludF0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW0ktRC5p ZXRmLWJmZC1tdWx0aXBvaW50XS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyIGlkPSJkaWZmMDA2NCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRl Ij40PC9zcGFuPi4xMy4xLiAgUmVjZXB0aW9uIG9mIEJGRCBDb250cm9sIFBhY2tldHM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+Njwvc3Bhbj4u MTMuMS4gIFJlY2VwdGlvbiBvZiBCRkQgQ29udHJvbCBQYWNrZXRzPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwNjUiPjx0ZD48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgVGhlIGZvbGxvd2luZyBwcm9jZWR1cmUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+cmVwbGFjZXMg c2VjdGlvbiA2LjguNjwvc3Bhbj4gb2YgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+W1JGQzU4ODBdLjwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVGhlIGZvbGxvd2luZyBw cm9jZWR1cmUgPHNwYW4gY2xhc3M9Imluc2VydCI+dXBkYXRlcyBwYXJ0czwvc3Bhbj4gb2YgPHNw YW4gY2xhc3M9Imluc2VydCI+U2VjdGlvbiA1LjEzLjEgb2Y8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICBbSS1ELmlldGYtYmZkLW11bHRpcG9pbnRdLjwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDA2NiI+ PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICBXaGVuIGEgQkZEIENvbnRyb2wgcGFja2V0IGlzIHJlY2VpdmVkLCBwcm9j ZWR1cmUgZGVmaW5lZCBpbiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5zZWN0aW9uPC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBXaGVuIGEgQkZEIENvbnRyb2wgcGFja2V0 IGlzIHJlY2VpdmVkLCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij50aGU8L3NwYW4+IHByb2NlZHVyZSBk ZWZpbmVkIGluPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxl dGUiPiAgIDQuMTMuMTwvc3Bhbj4gb2YgW0ktRC5pZXRmLWJmZC1tdWx0aXBvaW50XSBNVVNUIGJl IGZvbGxvd2VkLCBpbiB0aGUgb3JkZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+U2VjdGlvbiA1LjEzLjE8L3NwYW4+IG9mIFtJLUQuaWV0 Zi1iZmQtbXVsdGlwb2ludF0gTVVTVCBiZSBmb2xsb3dlZCwgaW4gdGhlPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIHNwZWNpZmllZC4gIElmIHRoZSBwYWNrZXQgaXMgZGlzY2FyZGVk IGFjY29yZGluZyB0byB0aGVzZSBydWxlcyw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgb3JkZXIgc3BlY2lmaWVkLiAgSWYgdGhlIHBhY2tldCBpcyBkaXNjYXJkZWQgYWNjb3Jk aW5nIHRvIHRoZXNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHByb2Nlc3Npbmcg b2YgdGhlIHBhY2tldCBNVVNUIGNlYXNlIGF0IHRoYXQgcG9pbnQuICBJbiBhZGRpdGlvbiB0bzwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBydWxlcywgcHJvY2Vzc2luZyBvZiB0 aGUgcGFja2V0IE1VU1QgY2Vhc2UgYXQgdGhhdCBwb2ludC4gIEluPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIHRoYXQsIGlmIHRhaWwgdHJhY2tpbmcgaXMgZGVzaXJlZCBieSBoZWFk LCBiZWxvdyBwcm9jZWR1cmUgTVVTVCBiZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICBhZGRpdGlvbiB0byB0aGF0LCBpZiB0YWlsIHRyYWNraW5nIGlzIGRlc2lyZWQgYnkgPHNw YW4gY2xhc3M9Imluc2VydCI+dGhlPC9zcGFuPiBoZWFkLCBiZWxvdzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICBhcHBsaWVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICBwcm9jZWR1cmUgTVVTVCBiZSBhcHBsaWVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICBJZiBiZmQuU2Vzc2lvblR5cGUgaXMgTXVsdGlwb2ludFRhaWw8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBJZiBiZmQuU2Vzc2lvblR5cGUgaXMgTXVs dGlwb2ludFRhaWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgSWYg YmZkLlVuaWNhc3RSY3ZkIGlzIDAgb3IgdGhlIE0gYml0IGlzIGNsZWFyLCBzZXQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICBJZiBiZmQuVW5pY2FzdFJjdmQgaXMgMCBv ciB0aGUgTSBiaXQgaXMgY2xlYXIsIHNldDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgICAgYmZkLlJlbW90ZU1pblJ4SW50ZXJ2YWwgdG8gdGhlIHZhbHVlIG9mIFJlcXVpcmVkIE1p biBSWDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgIGJmZC5SZW1vdGVN aW5SeEludGVydmFsIHRvIHRoZSB2YWx1ZSBvZiBSZXF1aXJlZCBNaW4gUlg8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgIEludGVydmFsLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICAgIEludGVydmFsLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgICAgICBJZiB0aGUgTSBiaXQgaXMgY2xlYXIsIHNldCBiZmQuVW5pY2FzdFJjdmQg dG8gMS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICBJZiB0aGUgTSBi aXQgaXMgY2xlYXIsIHNldCBiZmQuVW5pY2FzdFJjdmQgdG8gMS48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgRWxzZSAobm90IE11bHRpcG9pbnRUYWlsKTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIEVsc2UgKG5vdCBNdWx0aXBvaW50VGFpbCk8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgU2V0IGJmZC5SZW1vdGVNaW5S eEludGVydmFsIHRvIHRoZSB2YWx1ZSBvZiBSZXF1aXJlZCBNaW4gUlg8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICBTZXQgYmZkLlJlbW90ZU1pblJ4SW50ZXJ2YWwgdG8g dGhlIHZhbHVlIG9mIFJlcXVpcmVkIE1pbiBSWDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICAgSW50ZXJ2YWwuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg ICAgSW50ZXJ2YWwuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIElmIHRo ZSBQb2xsIChQKSBiaXQgaXMgc2V0LCBhbmQgYmZkLlNpbGVudFRhaWwgaXMgemVybywgc2VuZCBh IEJGRDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIElmIHRoZSBQb2xsIChQ KSBiaXQgaXMgc2V0LCBhbmQgYmZkLlNpbGVudFRhaWwgaXMgemVybywgc2VuZCBhIEJGRDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgQ29udHJvbCBwYWNrZXQgdG8gdGhlIHJlbW90 ZSBzeXN0ZW0gd2l0aCB0aGUgUG9sbCAoUCkgYml0IGNsZWFyLDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgIENvbnRyb2wgcGFja2V0IHRvIHRoZSByZW1vdGUgc3lzdGVtIHdp dGggdGhlIFBvbGwgKFApIGJpdCBjbGVhciw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwNjciPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgYW5kIHRoZSBGaW5h bCAoRikgYml0IHNldCAoc2VlIFNlY3Rpb24gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+NDwvc3Bhbj4u MTMuMykuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIGFuZCB0aGUgRmlu YWwgKEYpIGJpdCBzZXQgKHNlZSBTZWN0aW9uIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjY8L3NwYW4+ LjEzLjMpLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIg aWQ9ImRpZmYwMDY4Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPjQ8L3NwYW4+LjEz LjIuICBEZW11bHRpcGxleGluZyBCRkQgQ29udHJvbCBQYWNrZXRzPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjY8L3NwYW4+LjEzLjIuICBEZW11 bHRpcGxleGluZyBCRkQgQ29udHJvbCBQYWNrZXRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwNjkiPjx0ZD48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgVGhpcyBz ZWN0aW9uIGlzIHBhcnQgb2YgdGhlIDxzcGFuIGNsYXNzPSJkZWxldGUiPnJlcGxhY2VtZW50IGZv ciBbUkZDNTg4MF0gc2VjdGlvbiA2LjguNjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgVGhpcyBzZWN0aW9uIGlzIHBhcnQgb2YgdGhlIGFkZGl0aW9uIHRvIDxzcGFu IGNsYXNzPSJpbnNlcnQiPlNlY3Rpb24gNS4xMy4yPC9zcGFuPiBvZjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBhbmQ8L3NwYW4+IGFkZGl0aW9u IHRvIDxzcGFuIGNsYXNzPSJkZWxldGUiPnNlY3Rpb24gNC4xMy4yPC9zcGFuPiBvZiBbSS1ELmll dGYtYmZkLW11bHRpcG9pbnRdLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBb SS1ELmlldGYtYmZkLW11bHRpcG9pbnRdLCBzZXBhcmF0ZWQgZm9yIGNsYXJpdHkuPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHNlcGFyYXRlZCBmb3IgY2xhcml0eS48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgIElmIE11bHRpcG9pbnQgKE0pIGJpdCBpcyBjbGVhcjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgIElmIE11bHRpcG9pbnQgKE0pIGJpdCBpcyBjbGVhcjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICBJZiB0aGUgWW91ciBEaXNjcmltaW5h dG9yIGZpZWxkIGlzIG5vbnplcm88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICAgICBJZiB0aGUgWW91ciBEaXNjcmltaW5hdG9yIGZpZWxkIGlzIG5vbnplcm88L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgU2VsZWN0IGEgc2Vzc2lvbiBiYXNl ZCBvbiB0aGUgdmFsdWUgb2YgWW91ciBEaXNjcmltaW5hdG9yLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgICAgICAgIFNlbGVjdCBhIHNlc3Npb24gYmFzZWQgb24gdGhlIHZh bHVlIG9mIFlvdXIgRGlzY3JpbWluYXRvci48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgICAgIElmIG5vIHNlc3Npb24gaXMgZm91bmQsIHRoZSBwYWNrZXQgTVVTVCBiZSBkaXNj YXJkZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgSWYgbm8g c2Vzc2lvbiBpcyBmb3VuZCwgdGhlIHBhY2tldCBNVVNUIGJlIGRpc2NhcmRlZC48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDA3MCI+PHRk PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICAgICAgICAgICBJZiBiZmQuU2Vzc2lvblR5cGUgaXMgTXVsdGk8c3BhbiBjbGFz cz0iZGVsZXRlIj5jYXM8L3NwYW4+dEhlYWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgICAgICAgICAgSWYgYmZkLlNlc3Npb25UeXBlIGlzIE11bHRpPHNwYW4gY2xhc3M9Imlu c2VydCI+cG9pbjwvc3Bhbj50SGVhZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICAgICAgICAgICBGaW5kIGEgTXVsdGlwb2ludENsaWVudCBzZXNzaW9uIGdyb3VwZWQgdG8g dGhpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgIEZpbmQg YSBNdWx0aXBvaW50Q2xpZW50IHNlc3Npb24gZ3JvdXBlZCB0byB0aGlzPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDcxIj48dGQ+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg ICAgICAgICAgICAgIE11bHRpPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Y2FzPC9zcGFuPnRIZWFkIHNl c3Npb24sIGJhc2VkIG9uIHRoZSBzb3VyY2UgYWRkcmVzcyBhbmQ8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAgTXVsdGk8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5w b2luPC9zcGFuPnRIZWFkIHNlc3Npb24sIGJhc2VkIG9uIHRoZSBzb3VyY2UgYWRkcmVzcyBhbmQ8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgIHRoZSB2YWx1ZSBvZiBZ b3VyIERpc2NyaW1pbmF0b3IuICBJZiBhIHNlc3Npb24gaXMgZm91bmQ8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICB0aGUgdmFsdWUgb2YgWW91ciBEaXNjcmlt aW5hdG9yLiAgSWYgYSBzZXNzaW9uIGlzIGZvdW5kPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDcyIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICAg IGFuZCBpcyBub3QgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+TXVsdGljYXN0Q2xpZW50LDwvc3Bhbj4g dGhlIHBhY2tldCBNVVNUIGJlIGRpc2NhcmRlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgICAgICAgICAgICAgYW5kIGlzIG5vdCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5NdWx0 aXBvaW50Q2xpZW50LDwvc3Bhbj4gdGhlIHBhY2tldCBNVVNUIGJlPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgICAgICAgICAgICAgIElmIG5vIHNlc3Npb24gaXMgZm91bmQsIGEgbmV3 IHNlc3Npb24gb2YgdHlwZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAg ICAgICAgICBkaXNjYXJkZWQuICBJZiBubyBzZXNzaW9uIGlzIGZvdW5kLCBhIG5ldyBzZXNzaW9u IG9mIHR5cGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgIE11bHRp cG9pbnRDbGllbnQgTUFZIGJlIGNyZWF0ZWQsIG9yIHRoZSBwYWNrZXQgTUFZIGJlPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgTXVsdGlwb2ludENsaWVudCBN QVkgYmUgY3JlYXRlZCwgb3IgdGhlIHBhY2tldCBNQVkgYmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgICAgICAgICAgIGRpc2NhcmRlZC4gIFRoaXMgY2hvaWNlIGlzIG91dHNpZGUg dGhlIHNjb3BlIG9mIHRoaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg ICAgICAgICBkaXNjYXJkZWQuICBUaGlzIGNob2ljZSBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0 aGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICBzcGVjaWZpY2F0 aW9uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgIHNwZWNp ZmljYXRpb24uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 ciBpZD0iZGlmZjAwNzMiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICAgSWYgYmZkLlNlc3Npb25U eXBlIGlzIG5vdCBNdWx0aTxzcGFuIGNsYXNzPSJkZWxldGUiPmNhczwvc3Bhbj50Q2xpZW50LCB0 aGUgcGFja2V0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAg IElmIGJmZC5TZXNzaW9uVHlwZSBpcyBub3QgTXVsdGk8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5wb2lu PC9zcGFuPnRDbGllbnQsIHRoZSBwYWNrZXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgICAgICAgIE1VU1QgYmUgZGlzY2FyZGVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgICAgICAgICAgIE1VU1QgYmUgZGlzY2FyZGVkLjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDc0Ij48dGQ+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjxzcGFuIGNsYXNzPSJkZWxldGUiPjQuMTMuMy48L3NwYW4+ICBUcmFuc21pdHRpbmcgQkZEIENv bnRyb2wgUGFja2V0czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz cz0iaW5zZXJ0Ij42LjEzLjMuPC9zcGFuPiAgVHJhbnNtaXR0aW5nIEJGRCBDb250cm9sIFBhY2tl dHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+VGhlIGZvbGxvd2luZyBwcm9jZWR1cmUgcmVwbGFjZXMg c2VjdGlvbiA2LjguNyBvZiBbUkZDNTg4MF0uPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQSBzeXN0ZW0g TVVTVCBOT1QgcGVyaW9kaWNhbGx5IHRyYW5zbWl0IEJGRCBDb250cm9sIHBhY2tldHMgaWY8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBIHN5c3RlbSBNVVNUIE5PVCBwZXJpb2Rp Y2FsbHkgdHJhbnNtaXQgQkZEIENvbnRyb2wgcGFja2V0cyBpZjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDA3NSI+PHRkPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBiZmQu U2Vzc2lvblR5cGUgaXMgTXVsdGk8c3BhbiBjbGFzcz0iZGVsZXRlIj5jYXM8L3NwYW4+dENsaWVu dCBhbmQgYSBQb2xsIFNlcXVlbmNlIGlzIG5vdCBiZWluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICBiZmQuU2Vzc2lvblR5cGUgaXMgTXVsdGk8c3BhbiBjbGFzcz0iaW5zZXJ0 Ij5wb2luPC9zcGFuPnRDbGllbnQgYW5kIGEgUG9sbCBTZXF1ZW5jZSBpcyBub3QgYmVpbmc8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRyYW5zbWl0dGVkLjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIHRyYW5zbWl0dGVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDc2Ij48dGQ+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIElmIGJm ZC5TZXNzaW9uVHlwZSBpcyBNdWx0aTxzcGFuIGNsYXNzPSJkZWxldGUiPmNhczwvc3Bhbj50VGFp bCBhbmQgcGVyaW9kaWMgdHJhbnNtaXNzaW9uIG9mIEJGRDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICBJZiBiZmQuU2Vzc2lvblR5cGUgaXMgTXVsdGk8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij5wb2luPC9zcGFuPnRUYWlsIGFuZCBwZXJpb2RpYyB0cmFuc21pc3Npb24gb2YgQkZEPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDb250cm9sIHBhY2tldHMgaXMganVzdCBzdGFy dGluZyAoZHVlIHRvIERlbWFuZCBtb2RlIG5vdCBiZWluZyBhY3RpdmU8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBDb250cm9sIHBhY2tldHMgaXMganVzdCBzdGFydGluZyAoZHVl IHRvIERlbWFuZCBtb2RlIG5vdCBiZWluZyBhY3RpdmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIG9uIHRoZSByZW1vdGUgc3lzdGVtKSwgdGhlIGZpcnN0IHBhY2tldCB0byBiZSB0cmFu c21pdHRlZCBNVVNUIGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb24gdGhl IHJlbW90ZSBzeXN0ZW0pLCB0aGUgZmlyc3QgcGFja2V0IHRvIGJlIHRyYW5zbWl0dGVkIE1VU1Qg YmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRlbGF5ZWQgYnkgYSByYW5kb20gYW1v dW50IG9mIHRpbWUgYmV0d2VlbiB6ZXJvIGFuZCAoMC45ICo8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBkZWxheWVkIGJ5IGEgcmFuZG9tIGFtb3VudCBvZiB0aW1lIGJldHdlZW4g emVybyBhbmQgKDAuOSAqPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBiZmQuUmVtb3Rl TWluUnhJbnRlcnZhbCkuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYmZkLlJl bW90ZU1pblJ4SW50ZXJ2YWwpLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJ ZiBhIEJGRCBDb250cm9sIHBhY2tldCBpcyByZWNlaXZlZCB3aXRoIHRoZSBQb2xsIChQKSBiaXQg c2V0IHRvIDEsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSWYgYSBCRkQgQ29u dHJvbCBwYWNrZXQgaXMgcmVjZWl2ZWQgd2l0aCB0aGUgUG9sbCAoUCkgYml0IHNldCB0byAxLDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIHJlY2VpdmluZyBzeXN0ZW0gTVVTVCB0 cmFuc21pdCBhIEJGRCBDb250cm9sIHBhY2tldCB3aXRoIHRoZSBQb2xsPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhlIHJlY2VpdmluZyBzeXN0ZW0gTVVTVCB0cmFuc21pdCBh IEJGRCBDb250cm9sIHBhY2tldCB3aXRoIHRoZSBQb2xsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAoUCkgYml0IGNsZWFyIGFuZCB0aGUgRmluYWwgKEYpIGJpdCwgd2l0aG91dCByZXNw ZWN0IHRvIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIChQKSBiaXQgY2xl YXIgYW5kIHRoZSBGaW5hbCAoRikgYml0LCB3aXRob3V0IHJlc3BlY3QgdG8gdGhlPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0cmFuc21pc3Npb24gdGltZXIgb3IgYW55IG90aGVyIHRy YW5zbWlzc2lvbiBsaW1pdGF0aW9ucywgd2l0aG91dDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIHRyYW5zbWlzc2lvbiB0aW1lciBvciBhbnkgb3RoZXIgdHJhbnNtaXNzaW9uIGxp bWl0YXRpb25zLCB3aXRob3V0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZXNwZWN0 IHRvIHRoZSBzZXNzaW9uIHN0YXRlLCBhbmQgd2l0aG91dCByZXNwZWN0IHRvIHdoZXRoZXIgRGVt YW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVzcGVjdCB0byB0aGUgc2Vz c2lvbiBzdGF0ZSwgYW5kIHdpdGhvdXQgcmVzcGVjdCB0byB3aGV0aGVyIERlbWFuZDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9InBhcnQtNSIgY2xh c3M9ImNoYW5nZSI+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3Nt YWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmYvcmZjZGlmZi5weWh0I3Bh cnQtNSI+PGVtPiBwYWdlIDE1LCBsaW5lIDQzPHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48 L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwv c21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQj cGFydC01Ij48ZW0+IHBhZ2UgMTYsIGxpbmUgNDE8c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFu PjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb3IgZXF1YWwgdG8gdGhlIGludGVydmFsIGJldHdl ZW4gdHJhbnNtaXR0ZWQgcGFja2V0cyBpbXBvc2VkIGJ5IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIG9yIGVxdWFsIHRvIHRoZSBpbnRlcnZhbCBiZXR3ZWVuIHRyYW5zbWl0 dGVkIHBhY2tldHMgaW1wb3NlZCBieSB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHJhdGUgbGltaXRpbmcgZnVuY3Rpb24uICBJZiB0aGUgTXVsdGlwb2ludCAoTSkgYml0IGlzIHNl dCBpbiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICByYXRlIGxpbWl0aW5n IGZ1bmN0aW9uLiAgSWYgdGhlIE11bHRpcG9pbnQgKE0pIGJpdCBpcyBzZXQgaW4gdGhlPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZWNlaXZlZCBwYWNrZXQsIHRoZSBwYWNrZXQgdHJh bnNtaXNzaW9uIE1VU1QgYmUgZGVsYXllZCBieSBhIHJhbmRvbTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIHJlY2VpdmVkIHBhY2tldCwgdGhlIHBhY2tldCB0cmFuc21pc3Npb24g TVVTVCBiZSBkZWxheWVkIGJ5IGEgcmFuZG9tPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBhbW91bnQgb2YgdGltZSBiZXR3ZWVuIHplcm8gYW5kICgwLjkgKiBiZmQuUmVtb3RlTWluUnhJ bnRlcnZhbCkuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYW1vdW50IG9mIHRp bWUgYmV0d2VlbiB6ZXJvIGFuZCAoMC45ICogYmZkLlJlbW90ZU1pblJ4SW50ZXJ2YWwpLjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgT3RoZXJ3aXNlLCB0aGUgcGFja2V0IE1VU1QgYmUg dHJhbnNtaXR0ZWQgYXMgc29vbiBhcyBwcmFjdGljYWJsZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBPdGhlcndpc2UsIHRoZSBwYWNrZXQgTVVTVCBiZSB0cmFuc21pdHRlZCBh cyBzb29uIGFzIHByYWN0aWNhYmxlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBBIHN5c3RlbSBNVVNUIE5PVCBzZXQgdGhlIERlbWFuZCAoRCkgYml0IGlmIGJmZC5TZXNzaW9u VHlwZSBpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEEgc3lzdGVtIE1VU1Qg Tk9UIHNldCB0aGUgRGVtYW5kIChEKSBiaXQgaWYgYmZkLlNlc3Npb25UeXBlIGlzPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBNdWx0aXBvaW50Q2xpZW50IHVubGVzcyBiZmQuRGVtYW5k TW9kZSBpcyAxLCBiZmQuU2Vzc2lvblN0YXRlIGlzIFVwLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIE11bHRpcG9pbnRDbGllbnQgdW5sZXNzIGJmZC5EZW1hbmRNb2RlIGlzIDEs IGJmZC5TZXNzaW9uU3RhdGUgaXMgVXAsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBh bmQgYmZkLlJlbW90ZVNlc3Npb25TdGF0ZSBpcyBVcC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBhbmQgYmZkLlJlbW90ZVNlc3Npb25TdGF0ZSBpcyBVcC48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDA3NyI+PHRkPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICBDb250ZW50cyBvZiB0cmFuc21pdHRlZCBwYWNrZXQgTVVTVCBiZSBhcyBleHBsYWlu ZWQgaW4gc2VjdGlvbiA8c3BhbiBjbGFzcz0iZGVsZXRlIj40PC9zcGFuPi4xMy4zPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIENvbnRlbnRzIG9mIHRyYW5zbWl0dGVkIHBhY2tl dCBNVVNUIGJlIGFzIGV4cGxhaW5lZCBpbiBzZWN0aW9uIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjU8 L3NwYW4+LjEzLjM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9mIFtJLUQuaWV0Zi1i ZmQtbXVsdGlwb2ludF0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb2YgW0kt RC5pZXRmLWJmZC1tdWx0aXBvaW50XS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDA3OCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVs ZXRlIj41PC9zcGFuPi4gIEFzc3VtcHRpb25zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjc8L3NwYW4+LiAgQXNzdW1wdGlvbnM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSWYgaGVhZCBub3RpZmljYXRpb24gaXMgdG8gYmUg dXNlZCwgaXQgaXMgYXNzdW1lZCB0aGF0IGEgbXVsdGlwb2ludDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIElmIGhlYWQgbm90aWZpY2F0aW9uIGlzIHRvIGJlIHVzZWQsIGl0IGlz IGFzc3VtZWQgdGhhdCBhIG11bHRpcG9pbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IEJGRCBwYWNrZXQgZW5jYXBzdWxhdGlvbiBjb250YWlucyBlbm91Z2ggaW5mb3JtYXRpb24gc28g dGhhdCBhIHRhaWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBCRkQgcGFja2V0 IGVuY2Fwc3VsYXRpb24gY29udGFpbnMgZW5vdWdoIGluZm9ybWF0aW9uIHNvIHRoYXQgYSB0YWls PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjYW4gYWRkcmVzcyBhIHVuaWNhc3QgQkZE IHBhY2tldCB0byB0aGUgaGVhZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBj YW4gYWRkcmVzcyBhIHVuaWNhc3QgQkZEIHBhY2tldCB0byB0aGUgaGVhZC48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSWYgaGVhZCBub3RpZmljYXRpb24gaXMgdG8gYmUgdXNl ZCwgaXQgaXMgYXNzdW1lZCB0aGF0IGlzIHRoYXQgdGhlcmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBJZiBoZWFkIG5vdGlmaWNhdGlvbiBpcyB0byBiZSB1c2VkLCBpdCBpcyBh c3N1bWVkIHRoYXQgaXMgdGhhdCB0aGVyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg aXMgYmlkaXJlY3Rpb25hbCB1bmljYXN0IGNvbW11bmljYXRpb24gYXZhaWxhYmxlIChhdCB0aGUg c2FtZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGlzIGJpZGlyZWN0aW9uYWwg dW5pY2FzdCBjb21tdW5pY2F0aW9uIGF2YWlsYWJsZSAoYXQgdGhlIHNhbWU8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIHByb3RvY29sIGxheWVyIHdpdGhpbiB3aGljaCBCRkQgaXMgYmVp bmcgcnVuKSBiZXR3ZWVuIHRoZSB0YWlsIGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIHByb3RvY29sIGxheWVyIHdpdGhpbiB3aGljaCBCRkQgaXMgYmVpbmcgcnVuKSBiZXR3 ZWVuIHRoZSB0YWlsIGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaGVhZC48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBoZWFkLjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBGb3IgdGhlIGhlYWQgdG8ga25vdyByZWxpYWJseSB0aGF0IGEgdGFp bCBoYXMgbG9zdCBtdWx0aXBvaW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg Rm9yIHRoZSBoZWFkIHRvIGtub3cgcmVsaWFibHkgdGhhdCBhIHRhaWwgaGFzIGxvc3QgbXVsdGlw b2ludDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29ubmVjdGl2aXR5LCB0aGUgdW5p Y2FzdCBwYXRocyBpbiBib3RoIGRpcmVjdGlvbnMgYmV0d2VlbiB0aGF0IHRhaWw8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjb25uZWN0aXZpdHksIHRoZSB1bmljYXN0IHBhdGhz IGluIGJvdGggZGlyZWN0aW9ucyBiZXR3ZWVuIHRoYXQgdGFpbDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgYW5kIHRoZSBoZWFkIG11c3QgcmVtYWluIG9wZXJhdGlvbmFsIHdoZW4gdGhl IG11bHRpcG9pbnQgcGF0aCBmYWlscy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBhbmQgdGhlIGhlYWQgbXVzdCByZW1haW4gb3BlcmF0aW9uYWwgd2hlbiB0aGUgbXVsdGlwb2lu dCBwYXRoIGZhaWxzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSXQgaXMgdGh1cyBk ZXNpcmFibGUgdGhhdCB1bmljYXN0IHBhdGhzIG5vdCBzaGFyZSBmYXRlIHdpdGggdGhlPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSXQgaXMgdGh1cyBkZXNpcmFibGUgdGhhdCB1 bmljYXN0IHBhdGhzIG5vdCBzaGFyZSBmYXRlIHdpdGggdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDc5Ij48dGQ+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIG11bHRp cG9pbnQgcGF0aCB0byB0aGUgZXh0ZW50IHBvc3NpYmxlIGlmIHRoZSBoZWFkIHdhbnRzIDxzcGFu IGNsYXNzPSJkZWxldGUiPnJlbGlhYmxlPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICBtdWx0aXBvaW50IHBhdGggdG8gdGhlIGV4dGVudCBwb3NzaWJsZSBpZiB0aGUg aGVhZCB3YW50cyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5tb3JlPC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICBrbm93bGVkZ2Ugb2YgdGFpbCBzdGF0ZS48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgZGVmaW5pdGU8L3Nw YW4+IGtub3dsZWRnZSBvZiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij50aGU8L3NwYW4+IHRhaWwgc3Rh dGUuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFNpbmNlIHRoZSBub3JtYWwg QkZEIHRocmVlLXdheSBoYW5kc2hha2UgaXMgbm90IHVzZWQgaW4gdGhpczwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNpbmNlIHRoZSBub3JtYWwgQkZEIHRocmVlLXdheSBoYW5k c2hha2UgaXMgbm90IHVzZWQgaW4gdGhpczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg YXBwbGljYXRpb24sIGEgdGFpbCB0cmFuc2l0aW9uaW5nIGZyb20gc3RhdGUgVXAgdG8gRG93biBh bmQgYmFjayB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFwcGxpY2F0aW9u LCBhIHRhaWwgdHJhbnNpdGlvbmluZyBmcm9tIHN0YXRlIFVwIHRvIERvd24gYW5kIGJhY2sgdG88 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFVwIGFnYWluIG1heSBub3QgYmUgcmVsaWFi bHkgZGV0ZWN0ZWQgYXQgdGhlIGhlYWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgVXAgYWdhaW4gbWF5IG5vdCBiZSByZWxpYWJseSBkZXRlY3RlZCBhdCB0aGUgaGVhZC48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDA4 MCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj42PC9zcGFuPi4gIElBTkEgQ29uc2lk ZXJhdGlvbnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+ODwvc3Bhbj4uICBJQU5BIENvbnNpZGVyYXRpb25zPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIFRoaXMgZG9jdW1lbnQgaGFzIG5vIGFjdGlvbnMgZm9yIElBTkEuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBkb2N1bWVudCBoYXMgbm8gYWN0 aW9ucyBmb3IgSUFOQS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyIGlkPSJkaWZmMDA4MSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj43PC9z cGFuPi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjk8L3NwYW4+LiAgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIHNhbWUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgYXMgdGhvc2UgZGVzY3JpYmVkIGluIFtSRkM1ODgwXSBhbmQ8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgc2FtZSBzZWN1cml0eSBjb25zaWRl cmF0aW9ucyBhcyB0aG9zZSBkZXNjcmliZWQgaW4gW1JGQzU4ODBdIGFuZDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgW0ktRC5pZXRmLWJmZC1tdWx0aXBvaW50XSBhcHBseSB0byB0aGlz IGRvY3VtZW50LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtJLUQuaWV0Zi1i ZmQtbXVsdGlwb2ludF0gYXBwbHkgdG8gdGhpcyBkb2N1bWVudC48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDA4MiI+PHRkPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+ QWRkaXRpb25hbGx5LCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBjcmVhdGUgTXVsdHBvaW50Q2xpZW50 IHNlc3Npb25zPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgZHluYW1pY2Fs bHkgdXBvbiByZWNlaXB0IG9mIEJGRCBDb250cm9sIHBhY2tldCBmcm9tIGEgdGFpbCBNVVNUPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgaW1wbGVtZW50IHByb3RlY3RpdmUg bWVhc3VyZXMgdG8gcHJldmVudCBhbiBpbmZpbml0ZSBudW1iZXIgb2Y8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48 c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBNdWx0aXBvaW50Q2xpZW50IHNlc3Npb25zIGJlaW5nIGNy ZWF0ZWQuICBCZWxvdyBhcmUgbGlzdGVkIHNvbWU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICBwb2ludHMgdG8gYmUgY29uc2lkZXJlZCBpbiBzdWNoIGltcGxlbWVudGF0aW9u cy48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh biBjbGFzcz0iaW5zZXJ0Ij4gICAgICBXaGVuIHRoZSBudW1iZXIgb2YgTXVsdGlwb2ludENsaWVu dCBzZXNzaW9ucyBleGNlZWRzIHRoZSBudW1iZXIgb2Y8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz cz0iaW5zZXJ0Ij4gICAgICBleHBlY3RlZCB0YWlscywgdGhlbiB0aGUgaW1wbGVtZW50YXRpb24g c2hvdWxkIGdlbmVyYXRlIGFuIGFsYXJtPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+ICAgICAgdG8gdXNlcnMgdG8gaW5kaWNhdGUgdGhlIGFub21hbHkuPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ ICAgICAgVGhlIGltcGxlbWVudGF0aW9uIHNob3VsZCBoYXZlIGEgcmVhc29uYWJsZSB1cHBlciBi b3VuZCBvbiB0aGU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBudW1i ZXIgb2YgTXVsdGlwb2ludENsaWVudCBzZXNzaW9ucyB0aGF0IGNhbiBiZSBjcmVhdGVkLCB3aXRo IHRoZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIHVwcGVyIGJvdW5k IHBvdGVudGlhbGx5IGJlaW5nIGNvbXB1dGVkIGJhc2VkIG9uIHRoZSBudW1iZXIgb2Y8L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBtdWx0aWNhc3Qgc3RyZWFtcyB0aGF0 IHRoZSBzeXN0ZW0gaXMgZXhwZWN0aW5nLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5v dCByYWlzZSBhbnkgYWRkaXRpb25hbCBzZWN1cml0eSBpc3N1ZXM8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgcmFpc2UgYW55IGFk ZGl0aW9uYWwgc2VjdXJpdHkgaXNzdWVzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBi ZXlvbmQgdGhvc2Ugb2YgdGhlIHNwZWNpZmljYXRpb25zIHJlZmVycmVkIHRvIGluIHRoZSBsaXN0 IG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYmV5b25kIHRob3NlIG9mIHRo ZSBzcGVjaWZpY2F0aW9ucyByZWZlcnJlZCB0byBpbiB0aGUgbGlzdCBvZjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgbm9ybWF0aXZlIHJlZmVyZW5jZXMuPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgbm9ybWF0aXZlIHJlZmVyZW5jZXMuPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwODMiPjx0ZD48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ODwvc3Bhbj4uICBDb250cmlidXRvcnM8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+MTA8L3NwYW4+LiAgQ29u dHJpYnV0b3JzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFJhaHVsIEFnZ2Fy d2FsIG9mIEp1bmlwZXIgTmV0d29ya3MgYW5kIEdlb3JnZSBTd2FsbG93IG9mIENpc2NvPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUmFodWwgQWdnYXJ3YWwgb2YgSnVuaXBlciBO ZXR3b3JrcyBhbmQgR2VvcmdlIFN3YWxsb3cgb2YgQ2lzY288L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIFN5c3RlbXMgcHJvdmlkZWQgdGhlIGluaXRpYWwgaWRlYSBmb3IgdGhpcyBzcGVj aWZpY2F0aW9uIGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFN5c3RlbXMg cHJvdmlkZWQgdGhlIGluaXRpYWwgaWRlYSBmb3IgdGhpcyBzcGVjaWZpY2F0aW9uIGFuZDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29udHJpYnV0ZWQgdG8gaXRzIGRldmVsb3BtZW50 LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvbnRyaWJ1dGVkIHRvIGl0cyBk ZXZlbG9wbWVudC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyIGlkPSJkaWZmMDA4NCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj45LiAgQWNr bm93bGVkZ2U8L3NwYW4+bWVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+MTEuICBBY2tub3dsZWRnPC9zcGFuPm1lbnRzPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEF1dGhvcnMgd291bGQgYWxzbyBsaWtlIHRvIHRoYW5r IE5vYm8gQWtpeWEsIFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuLDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIEF1dGhvcnMgd291bGQgYWxzbyBsaWtlIHRvIHRoYW5rIE5vYm8gQWtp eWEsIFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgSmVmZiBIYWFzLCBXaW0gSGVuZGVyaWNreCwgR3JlZ29yeSBNaXJza3kgYW5kIE1pbmd1aSBa aGFuZyB3aG8gaGF2ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEplZmYgSGFh cywgV2ltIEhlbmRlcmlja3gsIEdyZWdvcnkgTWlyc2t5IGFuZCBNaW5ndWkgWmhhbmcgd2hvIGhh dmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGdyZWF0bHkgY29udHJpYnV0ZWQgdG8g dGhpcyBkb2N1bWVudC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBncmVhdGx5 IGNvbnRyaWJ1dGVkIHRvIHRoaXMgZG9jdW1lbnQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwODUiPjx0ZD48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+MTxzcGFuIGNs YXNzPSJkZWxldGUiPjA8L3NwYW4+LiAgTm9ybWF0aXZlIFJlZmVyZW5jZXM8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+MTxzcGFuIGNsYXNzPSJpbnNlcnQiPjI8L3NwYW4+LiAgTm9y bWF0aXZlIFJlZmVyZW5jZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW0kt RC5pZXRmLWJmZC1tdWx0aXBvaW50XTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFtJLUQuaWV0Zi1iZmQtbXVsdGlwb2ludF08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgICAgICAgS2F0eiwgRC4sIFdhcmQsIEQuLCBOZXR3b3JrcywgSi4sIGFuZCBHLiBNaXJz a3ksICJCRkQgZm9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAg ICBLYXR6LCBELiwgV2FyZCwgRC4sIE5ldHdvcmtzLCBKLiwgYW5kIEcuIE1pcnNreSwgIkJGRCBm b3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAw ODYiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICBNdWx0aXBvaW50IE5ldHdvcmtzIiwgPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+ZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludC0xMzwvc3Bhbj4gKHdvcms8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICBNdWx0aXBvaW50 IE5ldHdvcmtzIiwgPHNwYW4gY2xhc3M9Imluc2VydCI+ZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2lu dC0xNjwvc3Bhbj4gKHdvcms8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAg ICAgICBpbiBwcm9ncmVzcyksIDxzcGFuIGNsYXNzPSJkZWxldGUiPkphbnVhcnk8L3NwYW4+IDIw MTguPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgaW4gcHJv Z3Jlc3MpLCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5BcHJpbDwvc3Bhbj4gMjAxOC48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3 b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4g UkZDcyB0byBJbmRpY2F0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAg ICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0 LCBSRkMgMjExOSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgRE9J IDEwLjE3NDg3L1JGQzIxMTksIE1hcmNoIDE5OTcsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDMjExOSwgTWFyY2ggMTk5Nyw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgJmx0O2h0dHBzOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL2luZm8vcmZjMjExOSZndDsuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgICAgICAgICAmbHQ7aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9y ZmMyMTE5Jmd0Oy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1JGQzU4ODBd ICBLYXR6LCBELiBhbmQgRC4gV2FyZCwgIkJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rp b248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZDNTg4MF0gIEthdHosIEQu IGFuZCBELiBXYXJkLCAiQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAoQkZEKSIsIFJGQyA1ODgwLCBET0kg MTAuMTc0ODcvUkZDNTg4MCwgSnVuZSAyMDEwLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgICAgICAgICAgKEJGRCkiLCBSRkMgNTg4MCwgRE9JIDEwLjE3NDg3L1JGQzU4ODAs IEp1bmUgMjAxMCw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgJmx0 O2h0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNTg4MCZndDsuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAmbHQ7aHR0cHM6Ly93d3cucmZjLWVk aXRvci5vcmcvaW5mby9yZmM1ODgwJmd0Oy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KCiAgICAgPHRyPjx0ZD48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQ+PC90ZD48L3RyPgogICAgIDx0ciBpZD0iZW5k IiBiZ2NvbG9yPSJncmF5Ij48dGggY29sc3Bhbj0iNSIgYWxpZ249ImNlbnRlciI+Jm5ic3A7RW5k IG9mIGNoYW5nZXMuIDg2IGNoYW5nZSBibG9ja3MuJm5ic3A7PC90aD48L3RyPgogICAgIDx0ciBj bGFzcz0ic3RhdHMiPjx0ZD48L3RkPjx0aD48aT4yMTIgbGluZXMgY2hhbmdlZCBvciBkZWxldGVk PC9pPjwvdGg+PHRoPjxpPiA8L2k+PC90aD48dGg+PGk+MjcwIGxpbmVzIGNoYW5nZWQgb3IgYWRk ZWQ8L2k+PC90aD48dGQ+PC90ZD48L3RyPgogICAgIDx0cj48dGQgY29sc3Bhbj0iNSIgYWxpZ249 ImNlbnRlciIgY2xhc3M9InNtYWxsIj48YnI+VGhpcyBodG1sIGRpZmYgd2FzIHByb2R1Y2VkIGJ5 IHJmY2RpZmYgMS40Ni4gVGhlIGxhdGVzdCB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBmcm9tIDxhIGhy ZWY9Imh0dHBzOi8vd3d3LnRvb2xzLmlldGYub3JnL3Rvb2xzL3JmY2RpZmYvIj5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlmZi88L2E+IDwvdGQ+PC90cj4KICAgPC90Ym9keT48L3Rh YmxlPgogICAKICAgCjwvYm9keT48L2h0bWw+ --000000000000b6edba056dd585ed-- From nobody Mon Jun 4 12:49:10 2018 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC9B130DC0; Mon, 4 Jun 2018 12:49:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-multipoint-active-tail-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152814174699.30578.11301679413002495497@ietfa.amsl.com> Date: Mon, 04 Jun 2018 12:49:07 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 19:49:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection WG of the IETF. Title : BFD Multipoint Active Tails. Authors : Dave Katz Dave Ward Santosh Pallagatti Greg Mirsky Filename : draft-ietf-bfd-multipoint-active-tail-08.txt Pages : 19 Date : 2018-06-04 Abstract: This document describes active tail extensions to and updates the Bidirectional Forwarding Detection (BFD) protocol for multipoint networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-08 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-multipoint-active-tail-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-active-tail-08 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 Mon Jun 4 13:37:05 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651A1130DC0; Mon, 4 Jun 2018 13:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=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 mJvA-hvokEBQ; Mon, 4 Jun 2018 13:36:51 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 CEE26130DE1; Mon, 4 Jun 2018 13:36:50 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id i83-v6so22606lfh.5; Mon, 04 Jun 2018 13:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HZLmakq6BCQfnwRSCYAvFHI150/5UXepZM1wwBF5b7Y=; b=AqyU3uHQaJMuZu/tzzZPjtO5dsd9aqwQUnEp9t3gIagCYGaqkJ9hY3tHugwUfF2Ozc Pr9jRlUbVg3XP1hHItz18Yg3txoURLij8sZs06zWqFlgWRKECdfGtyX8ROvLM/wYPWjn cd+YmxiDv6iquDx7rSwbBhUK2cnf1mlO6tPC56b1hiPImuhoy+NEZ7nImPG2tdTZ1kwB Aob2zM+6YvKO2LrxT3xpTgrNSdTXfZpSshxnGdifpzgTPJQoGiX2i42uK3BNS0oH/vx2 DDE5kqvJc21V3gCpb2J2+o569YeyiFJQzpMN52+V2DozXa4GfXsef/BdBMZpvweFFuz8 l09A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HZLmakq6BCQfnwRSCYAvFHI150/5UXepZM1wwBF5b7Y=; b=DQN8M9YGiWRYNfku/OG23PSKbwJtWzmnn7sjtYTd1hr4RkqCBHUlu6g9QA+29wPKyQ D5+DfUNb/xPvAvueH0NfbtHDmr0oBVeMKqufHNfLrtf+ql0kXMDhVjcGvEBbcnD8X3Yp j0q0AV7fbsBYu54C/Xg0mISGJEQ9pCvpwjx2+qRmwkLw4fEsW2mHPmwGs38ae3XsvIQ0 IOGolOPiSgodxehg9JPAQ9Z3J0W830X+elzZWxLNxgXNU59k7KXGVm6vKRKzl+RCMQId PtwanEDZMx6lHvH5EWUylunLE1nuXs137/mAM4aCyHepzdgKg9fI64ckb4EbT6H24MjL /c8A== X-Gm-Message-State: ALKqPwfotlZ8ZYxhfMSKSWwL82dMrE9sGY3gQQ3isOLQ16F02oSMAfhM JM/Q6sYoZ+ySVOHDb0iJfdOXKsJH+IFxWgMGnWg= X-Google-Smtp-Source: ADUXVKL5GG8TNTxq4t10DoFBXJH1dri+KvW7xe8AsGhJfhGynHMtZ9qAuAkcsNQ007rY2skDuN4pBCN6t4cxQ4hlbU0= X-Received: by 2002:a2e:878f:: with SMTP id n15-v6mr9561091lji.69.1528144608909; Mon, 04 Jun 2018 13:36:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Mon, 4 Jun 2018 13:36:48 -0700 (PDT) In-Reply-To: References: <152694840016.8083.12174100605609215107@ietfa.amsl.com> <1afa9af2-9fce-1588-ca09-cd39f1122688@bobbriscoe.net> From: Greg Mirsky Date: Mon, 4 Jun 2018 13:36:48 -0700 Message-ID: Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-bfd-multipoint-16 To: Spencer Dawkins at IETF Cc: Bob Briscoe , draft-ietf-bfd-multipoint.all@ietf.org, tsv-art@ietf.org, rtg-bfd@ietf.org, IETF list Content-Type: multipart/alternative; boundary="000000000000945c3a056dd6e473" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 20:36:54 -0000 --000000000000945c3a056dd6e473 Content-Type: text/plain; charset="UTF-8" Hi Spencer, many thanks for the most helpful suggestion. I will use it with a minor modification: s/multipath/multipoint/. Regards, Greg On Tue, May 29, 2018 at 10:05 AM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Mirja and I do read these reviews, but don't usually comment on them while > the authors and reviewers are still chatting. But, on one point ... > > On Tue, May 29, 2018 at 5:23 AM Bob Briscoe wrote: > >> Greg, >> >> On 26/05/18 20:49, Greg Mirsky wrote: >> > > [snip] > >> NEW TEXT: >> >> Use of shared keys to authenticate BFD Control packet in multipoint >> scenarios is limited because tail can spoof the head from the >> viewpoint of the other tails. Thus, if shared keys are used, all >> tails MUST be trusted not to spoof the head. >> >> [BB]: Normally a MUST is applied to implementations. It would be rather >> odd to require users/operators to satisfy a spec requirement, particularly >> requiring them to trust each other. I think this should be written as an >> applicability statement not a normative requirement. >> > > Bob is formally correct here, but it may be useful for me to say that I do > see "requirements" language used to provide guidance about security and > about operational considerations (as here). > > If I understand Bob's suggestion to be something like > > NEW > > Shared keys in multipath scenarios allow any tail to spoof > the head from the viewpoint of any other tail. For this reason, > using shared keys to authenticate BFD Control packets in multipoint > scenarios is a significant security exposure unless all tails can > be trusted not to spoof the head. > > that would also work. > > "Do the right thing", of course. > > Spencer > > > --000000000000945c3a056dd6e473 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Spencer,
many thanks for the most helpful suggestio= n. I will use it with a minor modification:
s/multipath/multipoint/.

Regards,
Greg

On Tue, May 29, 2018 at 10= :05 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com= > wrote:
M= irja and I do read these reviews, but don't usually comment on them whi= le the authors and reviewers are still chatting. But, on one point ...
=
On Tue, Ma= y 29, 2018 at 5:23 AM Bob Briscoe <ietf@bobbriscoe.net> wrote:
=20 =20 =20
Greg,

On 26/05/18 20:49, Greg Mirsky wrote:
<= br>
[snip]=C2=A0
NEW TEXT:
=C2=A0 =C2=A0Use of shared keys to authenticate BFD Cont= rol packet in multipoint
=C2=A0 =C2=A0scenarios is limited because tail can spoof= the head from the
=C2=A0 =C2=A0viewpoint of the other tails.=C2=A0 Thus, i= f shared keys are used, all
=C2=A0 =C2=A0tails MUST be trusted not to spoof the head= .=C2=A0
[BB]: Normally a MUST is applied to implementations. It would be rather odd to require users/operators to satisfy a spec requirement, particularly requiring them to trust each other. I think this should be written as an applicability statement not a normative requirement.

Bob is formal= ly correct here, but it may be useful for me to say that I do see "req= uirements" language used to provide guidance about security and about = operational considerations (as here).=C2=A0=C2=A0

= If I understand Bob's suggestion to be something like=C2=A0
<= br>
NEW
=C2=A0 =C2=A0Shared keys in multipath scenarios allow any tai= l to spoof=C2=A0
=C2=A0 =C2=A0the head from the viewpoint of any = other tail. For this reason,
=C2=A0 =C2=A0using shared keys to au= thenticate BFD Control packets in multipoint
=C2=A0 =C2=A0scenari= os is a significant security exposure unless all tails can=C2=A0
=C2=A0 =C2=A0be trusted not to spoof the head.
that would also work.=C2=A0
=
"Do the right thing", of course.

Spencer
=C2=A0=


--000000000000945c3a056dd6e473-- From nobody Mon Jun 4 15:41:42 2018 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7F8130E02; Mon, 4 Jun 2018 15:41:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" Subject: Last Call: (BFD Multipoint Active Tails.) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk CC: Reshad Rahman , rrahman@cisco.com, rtg-bfd@ietf.org, draft-ietf-bfd-multipoint-active-tail@ietf.org, martin.vigoureux@nokia.com, bfd-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152815209915.30754.18349705412173023163.idtracker@ietfa.amsl.com> Date: Mon, 04 Jun 2018 15:41:39 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 22:41:40 -0000 The IESG has received a request from the Bidirectional Forwarding Detection WG (bfd) to consider the following document: - 'BFD Multipoint Active Tails.' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-06-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes active tail extensions to and updates the Bidirectional Forwarding Detection (BFD) protocol for multipoint networks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Jun 4 21:05:41 2018 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1170130EA3; Mon, 4 Jun 2018 21:05:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-multipoint-17.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152817153394.30742.13913022992008777607@ietfa.amsl.com> Date: Mon, 04 Jun 2018 21:05:33 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 04:05:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection WG of the IETF. Title : BFD for Multipoint Networks Authors : Dave Katz Dave Ward Santosh Pallagatti Greg Mirsky Filename : draft-ietf-bfd-multipoint-17.txt Pages : 20 Date : 2018-06-04 Abstract: This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-multipoint-17 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-multipoint-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-17 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 Tue Jun 5 07:07:48 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A4B130E77; Mon, 4 Jun 2018 19:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 m-P6l_ardgRZ; Mon, 4 Jun 2018 19:23:20 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 4133B130E78; Mon, 4 Jun 2018 19:23:20 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id j13-v6so987036lfb.13; Mon, 04 Jun 2018 19:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+nmWtEVqAI2j0lYDVY9Pus9YnVdryYVwf4OYknTFaTo=; b=QeTOOUTIqpjgOJGnyim7qiFOg0oX4508BXnGPBu4EoPC5jhN7bB2XLsOH9k0311+q9 8oLXo6sTdrD4/iEqWGDT2SGGZtK7wikvVWuWicro1ftfyaL9+Cm5Nei8lZoSLUgX7l7+ KPfmu321yPm/n1fAL3Po+onziWlcNP33QjcE/0z3eqQXJoFixuQ5QobJ153urSsly6PD PZnPA1GagPpaAr647bhYks2HUZXuo/OlmUXFSB3LLKxU6LC3H9Wic2Bf2/qlpAkr+mdX Bs+BNlBIMLnEUOuGxGk5saaQwk1Anz11CVowJIVTY3NSrUbI0hNY+VQtZJzwpZyuOu8a I6kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+nmWtEVqAI2j0lYDVY9Pus9YnVdryYVwf4OYknTFaTo=; b=ZSijjQPfN3jib1Jql8zFn8JVn8Kd/RZMtmZtz2aQbV8YhISrGrbToB/HtH47RqVSyQ NMZm2a1q3bYjMxM2u7T6oFPTdapKyF2b24mbp5lALzUy27/7ufZdr1Rt77FJdU9GHTWj vvClS43zL73OSvWVarIW4oDXIsVE/LPX9Y0YdxpMBjp7CNW48THZpvOX7nM1lc7kGJiB /xAgghlVqmMoi/Lf++f01kwuccmhnM8QAFtBBUL6isHjdPAcIDETXlIX+LWbX1lQVNAm dm1pgcDZKUiGIGlK4VU9eDDuh037DMYXFudNEmb4qRHBoLsMNG8ws9UwKyCQCrCZHpdr jbQQ== X-Gm-Message-State: APt69E0H9v/cXJTf1ObyaXz/Pdrfv+n+SQ+0yqZi1CGfMqyyW721R8nU k5s/iYg1zT72JMKOds0z2U6sBT1t4q1MtyH8kzQ= X-Google-Smtp-Source: ADUXVKKe2sU/CSLyuIKqbardzVvkBUkxi83F8PhCDngAm7SM2cEo7/Uu3uFmTZCehyD/HiLaeQyybwf9Z6Gx0qgEnrw= X-Received: by 2002:a19:5c94:: with SMTP id u20-v6mr293924lfi.138.1528165398022; Mon, 04 Jun 2018 19:23:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Mon, 4 Jun 2018 19:23:17 -0700 (PDT) In-Reply-To: <1afa9af2-9fce-1588-ca09-cd39f1122688@bobbriscoe.net> References: <152694840016.8083.12174100605609215107@ietfa.amsl.com> <1afa9af2-9fce-1588-ca09-cd39f1122688@bobbriscoe.net> From: Greg Mirsky Date: Mon, 4 Jun 2018 19:23:17 -0700 Message-ID: Subject: Re: Tsvart last call review of draft-ietf-bfd-multipoint-16 To: Bob Briscoe Cc: tsv-art@ietf.org, draft-ietf-bfd-multipoint.all@ietf.org, rtg-bfd@ietf.org, IETF list Content-Type: multipart/alternative; boundary="000000000000b50dda056ddbbb2b" Archived-At: X-Mailman-Approved-At: Tue, 05 Jun 2018 07:07:46 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 02:23:26 -0000 --000000000000b50dda056ddbbb2b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bob, thank you for further clarifications and the new ideas. Please find my follow-up in-line and tagger GIM2>>. I'll check for nits and grammar and will publish the new version shortly. Regards, Greg On Tue, May 29, 2018 at 3:22 AM, Bob Briscoe wrote: > Greg, > > > On 26/05/18 20:49, Greg Mirsky wrote: > > Hi Bob, > thank you for the thorough review, detailed questions and helpful > comments. Please find my answers in-line and tagged GIM>>. > I've updated the working version of the draft based on your comments and > suggestions. Appreciate your feedback whether all questions have been > addressed. > Attached please find the diff of -16 and the working version and the copy > of the working version of the draft. > > Regards, > Greg > > On Mon, May 21, 2018 at 5:20 PM, Bob Briscoe wrote: > >> Reviewer: Bob Briscoe >> Review result: Not Ready >> >> Altho this is a TSV-ART review, I did not find many transport-related >> issues to >> focus on, except a need to justify why lack of information for adapting >> the >> transmit interval is not an issue. >> >> Nonetheless, I did find a few other non-trivial technical issues, >> including 2 >> security issues, enumerated below (I mis-spent some of my early research >> career >> working on a multicast session control and security, for which we used >> beaconing control channels). However, I only have passing prior knowledg= e >> of >> BFD, so my critique might be off-beam. >> >> =3D=3DMain Technical Concerns=3D=3D=3D >> >> 1/ Mandatory return path? >> RFC5880 is the base RFC that this draft updates. RFC5880 says that >> "unidirectional links" are in scope, but only as long as there is a >> return path. >> >> The introduction of this bfd-multipoint draft seems to contradict that, >> making >> a return path optional: " >> As an option, the tail may notify the head of the lack of multipoint >> connectivity. Details of tail notification to the head are outside >> the scope of this document. >> " >> It's allowable for irrelevant details to be outside the scope, but surel= y >> it >> needs to be clear whether at least the existence of a return path is >> mandatory. >> > GIM>> Thank you for highlighting this issue. I think that the second > paragraph of Introduction is the appropriate place to note that this > mechanism does not require existence of a return path from tails to the > head. Would the following be acceptable: > NEW TEXT: > Use of BFD in > Demand mode enables a tail monitor availability of a multipoint path > even without the existence of some kind of a return path to the head. > >> >> 2/ Mechanism for verifying connectivity, or not? >> The introduction seems to contradict itself: >> " >> As multipoint transmissions are inherently unidirectional, this >> mechanism purports only to verify this unidirectional connectivity. >> " >> " >> Term "connectivity" in this document is not being used in the context >> of connectivity verification in transport network but as an >> alternative to "continuity", i.e. existence of a forwarding path >> between the sender and the receiver. >> " >> How can this mechanism verify connectivity, but not be used in the >> context of >> connectivity verification in the transport network? >> > GIM>> This draft defines the base specification for multipoint BFD. In > order for multipoint BFD to support the transport-like connectivity > verification we need to do work similar to described in RFC 6428. > > [BB]: Caveat: I am having to talk in generalizations, cos I don't actuall= y > know how you are going to get this protocol to work in a wide range of > circumstances, given inherent problems like multipoint feedback implosion > {Note 1}. > > My point was that, having broken up the drafts in this way, this draft on > its own no longer defined a workable protocol. Therefore, it needed some > references to other drafts (even if they are placeholders), so that the > extent of the pre-requisite collection of work is clear. The refs you giv= e > later go a long way to fixing this issue. > > If each pre-requisite protocol is intended to only represent one example, > the citation can say that and the ref can be informative. But with zero > examples for all the prerequisite parts, all the reader sees is a > dismembered octopus, not a protocol. > > > >> 3/ Use case >> The introduction seems to be written rather academically. Surely, in cas= es >> where there is never a return path, only the tails will ever be able to >> verify >> connectivity. The head could continue transmitting BFD packets (and data >> packets) for years without ever knowing whether it is connected to >> anything. >> Knowledge of connectivity is surely of little use if it excludes the lin= k >> sender, which is the node that always controls routing. >> >> If there are scenarios where it is useful for tails but not the head to >> be able >> to verify connectivity, can you please give a concrete example? >> > GIM>> One example could be a multicast system with 1+1 protection. Withou= t > multipoint BFD tails would not be able to detect the failure of the > muticast path from the head. Other examples discussed in several drafts: > > - BESS WG draft MVPN fast upstream failover > > - Individual draft BFD for Multipoint Networks and VRRP Use Case > > - Individual draft BFD for Multipoint Networks and PIM-SM Use Case > > > I am not sure how references to non-WG drafts affect the progress of this > document. Appreciate your suggestion. > > [BB]: In my experience, informative refs to non-WG drafts as use-cases > would be OK during doc development. However, if a non-WG draft fails to > proceed, its citation has to be removed later. So choose those that are > most likely to proceed. > > Nonetheless, if you cite some specs that turn this into a workable > protocol (see previous issue) use-cases might not be necessary. > GIM2>> I've added reference to use of this mechanism in BGP/MPLS MVPN. > > > > >> 4/ Interval adaptation >> Text is needed to describe why it is not an issue for the head to be >> unaware >> whether it needs to adapt its transmit interval. Otherwise, this seems >> potentially problematic. >> > GIM>> Very interesting, thank you. I wouldn't say that the case when a > tail cannot process incoming mpBFD control packets at the offered rate is > entirely non-issue. Such scenario must be handled by the implementation a= nd > may be controlled by local policy, e.g., close the MultipointTail session= . > > [BB]: Fair enough. > > In some scenarios, this issue will not necessarily be so unlikely tho: > * If asymmetric crypto is used to solve the group message authentication > problem (see later), the processing burden on any lightweight endpoints > might lead to message verification leaving less available processor > resource than needed for the host's other tasks. > * Each tail might be joined to a very large number of multipoint sessions= . > > Where would you suggest to add the text? > > I would suggest a new section listing potential issues when there is no > back channel. > GIM2>> I've tried to start the new section but decided to insert the note in the first paragraph of Timer Manipulation section. Hope that is acceptable. > > > > >> 5/ Inability to authenticate the sender with symmetric keys >> In unicast scenarios, symmetric keys can be used for message >> authentication, >> because each end knows there is only one other node with the shared key. >> But, >> in multipoint scenarios, all the tails would share the key, so a shared >> key >> does not authenticate who sent the message - any tail can spoof the head >> from >> the viewpoint of the other tails. >> >> Therefore text is needed to say that: >> * multipoint message authentication is limited to cases where all tails >> are >> trusted not to spoof the head, if shared keys are used. * otherwise >> asymmetric >> message authentication would be needed, e.g. TESLA [RFC4082] >> > GIM>> Thank you for the suggested text. Would the Security Considerations > section be appropriate place: > > [BB]: Well, the point limits the applicability of the assumption about > security in 5. 'Assumptions', so this would fit well there. > Then "Security Considerations" should point to everywhere in the doc that > discusses security, such as this (to save time for security reviewers). > > NEW TEXT: > Use of shared keys to authenticate BFD Control packet in multipoint > scenarios is limited because tail can spoof the head from the > viewpoint of the other tails. Thus, if shared keys are used, all > tails MUST be trusted not to spoof the head. > > [BB]: Normally a MUST is applied to implementations. It would be rather > odd to require users/operators to satisfy a spec requirement, particularl= y > requiring them to trust each other. I think this should be written as an > applicability statement not a normative requirement. > GIM2>> I've adopted text suggested by Spencer and moved the paragraph to section Assumption. > > > Otherwise, asymmetric > message authentication would be needed, e.g., Timed Efficient Stream > Loss-Tolerant Authentication (TESLA) as described in [RFC4082]. > > > [BB]: If you are going to allow for cases where all tails are trusted not > to spoof the head, then the assumption written in section 5 is no longer > correct. > > [FYI, RFC4082 is only a generic description. Many RFCs have been written > to authenticate specific protocols along TESLA lines.] > > >> A related nit: Section 5 says all tails are assumed to have a common >> authentication key. In cases with symmetric message authentication, >> surely the >> head also needs the same key. >> > GIM>> Thank you. Please check the updated text: > NEW TEXT: > If authentication is in use, the head and all tails must be > configured to have a common authentication key in order for the tails > to validate received the multipoint BFD Control packets. > > [BB]: Yup. Except delete "received the". > Also see above about whether this is now a correct assumption. > GIM2>> I think that s/must/may/ will keep the Assumption valid. > > > >> 6/ Source address spoofing >> A 3-way handshake makes a protocol robust against simple source address >> spoofing. Without a 3WHS, surely the spec. needs to highlight this >> vulnerability or discuss ways to address it or why it is not an issue. >> > GIM>> Because mpBFD control packets cannot be demultiplexed by tail base= d > on the value of Your Discriminator field as per RFC 5880, > the new procedure outlined in Section 4.7: > IP and MPLS multipoint tails MUST demultiplex BFD packets based on a > combination of the source address, My Discriminator and the identity > of the multipoint tree which the Multipoint BFD Control packet was > received from. Together they uniquely identify the head of the > multipoint path. > and described in details in Section 4.13.2: > If the Multipoint (M) bit is set > > If the Your Discriminator field is nonzero, the packet MUST be > discarded. > > Select a session as based on source address, My Discriminator > and the identity of the multipoint tree which the Multipoint > BFD Control packet was received. If a session is found, and > bfd.SessionType is not MultipointTail, the packet MUST be > discarded. If a session is not found, a new session of type > MultipointTail MAY be created, or the packet MAY be discarded. > This choice is outside the scope of this specification. > > Would you suggest additional text to a use case where the new > demultiplexing is not sufficent to protect from source address spoofing? > > > [BB]: I seem to have become co-opted into redesigning this protocol. I'd > prefer to limit my involvement to reviewing :) > > > >> 7/ Scope >> On eight occasions an issue is raised, but resolution is stated as >> outside the >> scope of this document. It is OK to limit the scope of a spec, for >> example to >> allow for multiple solutions to each issue. But at least one solution mu= st >> already exist for each of these eight issues. So, at least one example >> solution >> ought to be cited in each case. If any issues are open, then this should >> not be >> on the standards track. >> >> It would be more useful to state why each issue is out of scope. This >> would be >> helped by stating from the start what the scope of the document is. >> > GIM>> I've listed all eight occasions with the explanation for each one: > > 1. Details of tail notification to the head are outside the scope of > this document. - Notifications by tails addressed in > draft-ietf-bfd-multipoint-active-tail > . > Will add as informational reference. > > [BB]: Good. > > Nonetheless, given you have confirmed that a reverse path is optional, th= e > doc still needs to address the case where there is no reverse path. > GIM2>> Introduction notes: Use of BFD in Demand mode enables a tail monitor availability of a multipoint path even without the existence of some kind of a return path to the head. > {Note 1} For the active tail draft, you might find the following ideas fo= r > scaling multipoint feedback useful: > > *Statistical feedback:* > Nonnenmacher, J=C3=B6. & Biersack, E.W., "Scalable Feedback for Large Gro= ups > ," IEEE/ACM Transactions on > Networking 7(3):375--386 (June 1999) > > FUHRMANN, T., AND WIDMER, J. "On the scaling of feedback algorithms for > very large multicast groups ," > Computer Communications 24, 5-6 (March 2001), 539 547; > WIDMER, J., AND FUHRMANN, T. Extremum feedback for very large multicast > groups. Tech. Rep. TR 12-2001, Prakfische Informatik IV, University of > Mannheim, Germany, May 2001. > > Also, anycast can be used to select different representative feedback > tails, e.g. for a certain time, which might overlap with the periods for > which a few other tails are selected using subsequent anycasts. > > *Logical 'AND' feedback:* > Burbridge, T., Soppera, A., Briscoe, R. and Jacquet, A. "Method and > device for co-ordinating networked group members > " > Patent WO2004059479, (Jul 2004; Priority 24 Dec 2002) > [AFAICT this patent is still being maintained, so use of it in a protocol > would require an IPR declaration.] > > > > 1. Details of how the head keeps track of tails and how tails alert > their connectivity to the head are outside scope of this document. - S= ame > as #1. > > [BB]: And my response is same as #1. > > > 1. Bootstrapping BFD session to multipoint MPLS LSP in case of > penultimate hop popping is outside the scope of this document. - It ma= y use > control plane as in MVPN draft. Will add as informational reference. > > [BB]: Good. > > > 1. Use of other types of encapsulation of the BFD control message over > multipoint LSP is outside the scope of this document. - This in refere= nce > to ACH encapsulation that is discussed in draft-mirsky-mpls-p2mp-bfd > . Should it > be added as informational reference? What would be the imacpt of > progressing this specification? > > [BB]: See earlier comment about citing individual drafts (I don't have > enough BFD knowledge to give a BFD-specific answer). > > Also, in my review I should also have said: when creating new > encapsulations, pls see the common transport issues related to > encapsulation: > https://trac.ietf.org/trac/tsv/wiki/tsvdir-common-issues# > TunnelingprotocolsandTransportRelatedIssues > > > > 1. Change in the value of bfd.RequiredMinRxInterval is outside the > scope of this document. - Same as #1. > > [BB]: And my response is same as #1. > > > 1. If a session is not found, a new session of type MultipointTail MAY > be created, or the packet MAY be discarded. This choice is outside the > scope of this specification. - I propose to add "based on local policy= " to > the last sentence. > > [BB]: On what basis will local policy decide? It's my job as a reviewer t= o > ensure that this spec does not contain any loose ends (open issues). > GIM2>> It could be based on the maximum number of MultipointTail sessions and number of active MultipointTail sessions on the node. I'd clarify it as= : This choice MAY be controlled by the local policy, e.g. maximum number of MultipointTail sessions and number of active MultipointTail sessions, and is outside the scope of this specification. > > > 1. The exact method of selection is application-specific and is thus > outside the scope of this specification. - This is copied from RFC 588= 0: > "The exact method of selection is application specific and is thus out= side > the scope of this specification." as the section is to replace Section > 6.8.6. > > [BB]: OK. > > > 1. If a matching session is not found, a new session of type > PointToPoint MAY be created, or the packet MAY be discarded. This choi= ce is > outside the scope of this specification. - Same as #6. > > > [BB]: And my response is same as #6. > [Sry, my embedded comments have broken your numbered list.] > > > > > > >> There is also one issue that is "for further discussion". Does this mean >> the >> document is not ready yet? >> > GIM>> I think that the question left for further discussion is > non-technical: > The semantic difference between Down and AdminDown state is for > further discussion. > I propose to remove the sentence altogether. > > [BB]: OK. > > > >> 8/ Incremental deployment >> >> Section 4.4.1. "New State Variable Values" defines bfd.SessionType =3D >> PointToPoint as well as a couple of Multipoint alternatives. Presumably >> this >> spec does not require all existing PointToPoint systems to support this >> state >> value. Is the implication that only Multipoint systems that happen to be >> in >> PointToPoint mode should use this state? >> > GIM>> You're aboultely right, existing implementations of BFD don't need > to support bfd.SessionType variable. Only implementations that support th= e > base BFD, single-hop or multi-hop, and this specification, mpBFD, should > support bfd.SessionType and set it to PointToPoint value when BFD is in > single-hop or multi-hop mode. When in mpBFD mode, bfd.SessionType will be > set to either MultipointHead or MultipointClient. > > [BB]: Doesn't something need to be written (or referenced) to clarify all > this? AFAIR, this spec. never made clear that multipoint is a fork in > implementations. > GIM2>> And so is S-BFD. (Note, bfd.SessionType introduced in RFC 7880 S-BFD but missed to define PointToPoint value). > > > > >> =3D=3DNits=3D=3D >> >> * Sometimes 'tree' is used to mean a multipoint path in general. I suspe= ct >> 'path' was intended. >> > GIM>> I've found six occasions of "tree" and s/tree/path/ > >> >> 4.8. Packet consumption on tails >> s/Node/Nodes/ >> s/packet/packets/ >> s/demultiplex/demultiplexed/ >> > GIM>> Accepted all three. > >> >> 4.9. Bringing Up and Shutting Down Multipoint BFD Service >> " >> a newly >> started head (that does not have any previous state information >> available) SHOULD start with... >> " >> ... >> " >> ... (so long as the restarted head >> is using the same or a larger value of bfd.DesiredMinTxInterval than >> it did previously). >> " >> If it has no state available, how can it know whether a value is larger >> than >> previously? >> > GIM>> You are right, the BFD system at the head would not know the > previous value of bfd.DesiredMinTxInterval. This text is to caution > operator from decreasing bfd.DesiredMinTxInterval upon restart of the > BFD system. > >> >> 4.9. Bringing Up and Shutting Down Multipoint BFD Service >> There are a number of "SHOULD"s and "SHOULD NOT"s that do not state or >> give >> examples of circumstances in which the "SHOULD" would not be appropriate= . >> If >> there are none, "MUST" would be more appropriate. >> > GIM>> In the first paragraph SHOULD may not be followed if the > implementation can differentiate between the very first start and restart= s > of BFD system. If it is the first start of BFD system, the head MAY > directly progress to Up state skipping Down state. > The last paragraph describes graceful shuttdown. The head MAY shut the BF= D > mp session abruptly by just stopping transmission of BFD Control packets. > > [BB]: I assume you will say all this in the next rev, not just in this > email. > GIM2>> Appended the following: NEW TEXT: Alternatively, the head MAY stop transmitting BFD Control packets and not send any more BFD Control packets with the new state (Down or AdminDown). Tails will declare the multipoint session down only after the detection time interval runs out. > > > >> 4.10. Timer Manipulation >> " >> Because of the one-to-many mapping, a session of type MultipointHead >> SHOULD NOT initiate a Poll Sequence in conjunction with timer value >> changes. However, to indicate a change in the packets, >> MultipointHead session MUST send packets with the P bit set. >> MultipointTail session MUST NOT reply if the packet has M and P bits >> set and bfd.RequiredMinRxInterval set to 0. >> " >> The initial "SHOULD NOT" needs to be written another way. Perhaps >> " >> ...a session of type MultipointHead >> does not initiate a Poll Sequence >> " >> The head's normative action is defined by the following "MUST", then the >> tail's >> "MUST NOT reply" is what prevents the poll sequence happening. >> > GIM>> A Poll Sequence starts with the initiator setting Poll bit. Unless > the peer sends BFD Control packet with Finl bit set the poll sequence wou= ld > continue indefinetely. The initial SHOULD NOT, in my opinion, correctly > points that the mechanism of Poll Sequence not to be used by MultipointHe= ad > when changing transmission interval. I think that MUST in the first > paragraph can be downgraded to MAY because the MultipointHead doesn't nee= d > to use transition period when changing the transmission interval to lower > level, i.e., decreasing frequency. May I propose the following: > OLD TEXT: > Because of the one-to-many mapping, a session of type MultipointHead > SHOULD NOT initiate a Poll Sequence in conjunction with timer value > changes. However, to indicate a change in the packets, > MultipointHead session MUST send packets with the P bit set. > NEW TEXT: > Because of the one-to-many mapping, a session of type MultipointHead > SHOULD NOT initiate a Poll Sequence in conjunction with timer value > changes. However, to indicate a change in the packets, > MultipointHead session MAY send packets with the P bit set during > transition period. > > [BB]: If I were an implementer, I would not know what this is saying I > ought to implement. The spec needs to answer this question: If the head > changes the packets what happens differently if it sets the P bit vs. if = it > doesn't? > GIM2>> I think we can expect that the implementer is familiar with RFC 5880 and, very likely, has implemented it one or more times already. > > >> 4.11. Detection Times >> Delete "in the calculation" (repetition). >> > GIM>> Done. > >> >> 4.13.1. Reception of BFD Control Packets >> Some actions seem to be only relevant to PointToPoint sessions, but they >> are >> stated for all session types. Specifically: "the transmission of Echo >> packets, >> if any, MUST cease." "the Poll Sequence MUST be terminated." "MUST cease >> the >> periodic transmission of BFD Control packets" "MUST send periodic BFD >> Control >> packets" >> >> " >> If bfd.SessionType is PointToPoint, update the Detection Time as >> described in section 6.8.4 of [RFC5880]. If bfd.SessionType is >> MultipointTail, >> " >> The second sentence above ought to start on a new line as an Else if. >> > GIM>> Hope I got it right: > If bfd.SessionType is PointToPoint, update the Detection Time as > described in section 6.8.4 of [RFC5880]. > > Else > > If bfd.SessionType is MultipointTail, then update the Detection > Time as the product of the last received values of Desired Min > TX Interval and Detect Mult, as described in Section 5.11 of > this specification. > >> >> 4.13.2. Demultiplexing BFD Control Packets >> " >> This section is part of the replacement for [RFC5880] section 6.8.6, >> separated for clarity. >> " >> Do you mean "This section replaces the sentence: "If the Multipoint (M) >> bit is >> nonzero, the packet MUST be discarded." in [RFC5880] section 6.8.6? >> >> The statements under "If the Multipoint (M) bit is set" are not formatte= d >> like >> the rest of the if-else logic, and I think an Else is missing at the >> start of >> the statement after the nested "If". >> > GIM>> Agree, the paragraph is not structured properly. How about this > formating: > If the Multipoint (M) bit is set > > If the Your Discriminator field is nonzero, the packet MUST be > discarded. > > Select a session as based on source address, My Discriminator > and the identity of the multipoint path which the Multipoint > BFD Control packet was received. > > If a session is found, and bfd.SessionType is not > MultipointTail, the packet MUST be discarded. > > Else > > If a session is not found, a new session of type > MultipointTail MAY be created, or the packet MAY be > discarded. This choice is outside the scope of this > specification. > > [BB]: As long as this represents the logic you want, fine. The point is > that the indentation is the only clue to whether one 'if' is conditional = on > a previous 'if', or not. > > HTH > > Bob > > > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > --000000000000b50dda056ddbbb2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bob,
thank you for further clarifications and the n= ew ideas. Please find my follow-up in-line and tagger GIM2>>.
I'll check for nits and grammar and will publish the new version sho= rtly.

Regards,
Greg

On Tue, May 29, 2018 at 3:22 AM,= Bob Briscoe <ietf@bobbriscoe.net> wrote:
=20 =20 =20
Greg,


On 26/05/18 20= :49, Greg Mirsky wrote:
Hi Bob,
thank you for the thorough review, detailed questions and helpful comments. Please find my answers in-line and tagged GIM>>.
I've updated the working version of the draft based on you= r comments and suggestions. Appreciate your feedback whether all questions have been addressed.
Attached please find the diff of -16 and the working version and the copy of the working version of the draft.

Regards,
Greg

On Mon, May 21, 2018 at 5:20 PM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
Reviewer: Bob= Briscoe
Review result: Not Ready

Altho this is a TSV-ART review, I did not find many transport-related issues to
focus on, except a need to justify why lack of information for adapting the
transmit interval is not an issue.

Nonetheless, I did find a few other non-trivial technical issues, including 2
security issues, enumerated below (I mis-spent some of my early research career
working on a multicast session control and security, for which we used
beaconing control channels). However, I only have passing prior knowledge of
BFD, so my critique might be off-beam.

=3D=3DMain Technical Concerns=3D=3D=3D

1/ Mandatory return path?
RFC5880 is the base RFC that this draft updates. RFC5880 says that
"unidirectional links" are in scope, but only as lo= ng as there is a return path.

The introduction of this bfd-multipoint draft seems to contradict that, making
a return path optional: "
=C2=A0 =C2=A0As an option, the tail may notify the head of th= e lack of multipoint
=C2=A0 =C2=A0connectivity.=C2=A0 Details of tail notification= to the head are outside
=C2=A0 =C2=A0the scope of this document.
"
It's allowable for irrelevant details to be outside the scope, but surely it
needs to be clear whether at least the existence of a return path is mandatory.
GIM>> Thank you for highlighting this issue. I think that the second paragraph of Introduction is the appropriate place to note that this mechanism does not require existence of a return path from tails to the head. Would the following be acceptable:
NEW TEXT:
=C2=A0 =C2=A0Use of BFD in
=C2=A0 =C2=A0Demand mode enables a tail monitor availabi= lity of a multipoint path
=C2=A0 =C2=A0even without the existence of some kind of = a return path to the head.

2/ Mechanism for verifying connectivity, or not?
The introduction seems to contradict itself:
"
=C2=A0 =C2=A0As multipoint transmissions are inherently unidirectional, this
=C2=A0 =C2=A0mechanism purports only to verify this unidirect= ional connectivity.
"
"
=C2=A0 =C2=A0Term "connectivity" in this document i= s not being used in the context
=C2=A0 =C2=A0of connectivity verification in transport networ= k but as an
=C2=A0 =C2=A0alternative to "continuity", i.e. exis= tence of a forwarding path
=C2=A0 =C2=A0between the sender and the receiver.
"
How can this mechanism verify connectivity, but not be used in the context of
connectivity verification in the transport network?
GIM>> This draft defines the base specification for multipoint BFD. In order for multipoint BFD to support the transport-like connectivity verification we need to do work similar to described in RFC 6428.=C2=A0
[BB]: Caveat: I am having to talk in generalizations, cos I don't actually know how you are going to get this protocol to work in a wide range of circumstances, given inherent problems like multipoint feedback implosion {Note 1}.

My point was that, having broken up the drafts in this way, this draft on its own no longer defined a workable protocol. Therefore, it needed some references to other drafts (even if they are placeholders), so that the extent of the pre-requisite collection of work is clear. The refs you give later go a long way to fixing this issue.

If each pre-requisite protocol is intended to only represent one example, the citation can say that and the ref can be informative. But with zero examples for all the prerequisite parts, all the reader sees is a dismembered octopus, not a protocol.



3/ Use case
The introduction seems to be written rather academically. Surely, in cases
where there is never a return path, only the tails will ever be able to verify
connectivity. The head could continue transmitting BFD packets (and data
packets) for years without ever knowing whether it is connected to anything.
Knowledge of connectivity is surely of little use if it excludes the link
sender, which is the node that always controls routing.

If there are scenarios where it is useful for tails but not the head to be able
to verify connectivity, can you please give a concrete example?
GIM>> One example could be a multicast system with 1+1 protection. Without multipoint BFD tails would not be able to detect the failure of the muticast path from the head. Other examples discussed in several drafts:
I am not sure how references to non-WG drafts affect the progress of this document. Appreciate your suggestion.
 [BB]: In my experience, informative refs to non-WG drafts as use-cases would be OK during doc development. However, if a non-WG draft fails to proceed, its citation has to be removed later. So choose those that are most likely to proceed.

Nonetheless, if you cite some specs that turn this into a workable protocol (see previous issue) use-cases might not be necessary.
GIM2>> I've added reference to use of this mechan= ism in BGP/MPLS MVPN.=C2=A0




4/ Interval adaptation
Text is needed to describe why it is not an issue for the head to be unaware
whether it needs to adapt its transmit interval. Otherwise, this seems
potentially problematic.
GIM>> Very interesting, thank you. I wouldn't sa= y that the case when a tail cannot process incoming mpBFD control packets at the offered rate is entirely non-issue. Such scenario must be handled by the implementation and may be controlled by local policy, e.g., close the MultipointTail session.
[BB]: Fair enough.

In some scenarios, this issue will not necessarily be so unlikely tho:
* If asymmetric crypto is used to solve the group message authentication problem (see later), the processing burden on any lightweight endpoints might lead to message verification leaving less available processor resource than needed for the host's other tasks.
* Each tail might be joined to a very large number of multipoint sessions.

Where would you suggest to add the text?
 I would suggest a new section listing potential issues when there is no back channel.
GIM2>> I've tried to = start the new section but decided to insert the note in the first paragraph= of Timer Manipulation section. Hope that is acceptable.=C2=A0




5/ Inability to authenticate the sender with symmetric keys
In unicast scenarios, symmetric keys can be used for message authentication,
because each end knows there is only one other node with the shared key. But,
in multipoint scenarios, all the tails would share the key, so a shared key
does not authenticate who sent the message - any tail can spoof the head from
the viewpoint of the other tails.

Therefore text is needed to say that:
* multipoint message authentication is limited to cases where all tails are
trusted not to spoof the head, if shared keys are used. * otherwise asymmetric
message authentication would be needed, e.g. TESLA [RFC4082]
GIM>> Thank you for the suggested text. Would the Security Considerations section be appropriate place:
 [BB]: Well, the point limits the applicability of the assumption about security in 5. 'Assumptions', so this would fit well ther= e.
Then "Security Considerations" should point to everywhere in = the doc that discusses security, such as this (to save time for security reviewers).

NEW TEXT:
=C2=A0 =C2=A0Use of shared keys to authenticate BFD Cont= rol packet in multipoint
=C2=A0 =C2=A0scenarios is limited because tail can spoof= the head from the
=C2=A0 =C2=A0viewpoint of the other tails.=C2=A0 Thus, i= f shared keys are used, all
=C2=A0 =C2=A0tails MUST be trusted not to spoof the head= .=C2=A0
[BB]: Normally a MUST is applied to implementations. It would be rather odd to require users/operators to satisfy a spec requirement, particularly requiring them to trust each other. I think this should be written as an applicability statement not a normative requirement.
GIM2>> I've adopted text = suggested by Spencer and moved the paragraph to section Assumption.


Otherwise, asymmetric
=C2=A0 =C2=A0message authentication would be needed, e.g= ., Timed Efficient Stream
=C2=A0 =C2=A0Loss-Tolerant Authentication (TESLA) as des= cribed in [RFC4082].

[BB]: If you are going to allow for cases where all tails are trusted not to spoof the head, then the assumption written in section 5 is no longer correct.

[FYI, RFC4082 is only a generic description. Many RFCs have been written to authenticate specific protocols along TESLA lines.]


A related nit: Section 5 says all tails are assumed to have a common
authentication key. In cases with symmetric message authentication, surely the
head also needs the same key.
GIM>> Thank you. Please check the updated text:
NEW TEXT:
=C2=A0 =C2=A0If authentication is in use, the head and all= tails must be
=C2=A0 =C2=A0configured to have a common authentication ke= y in order for the tails
=C2=A0 =C2=A0to validate received the multipoint BFD Contr= ol packets.
[BB]: Yup. Except delete "received the".
Also see above about whether this is now a correct assumption.
GIM2>> I think that s/must/may/ will keep the Assumpti= on valid.=C2=A0



6/ Source address spoofing
A 3-way handshake makes a protocol robust against simple source address
spoofing. Without a 3WHS, surely the spec. needs to highlight this
vulnerability or discuss ways to address it or why it is not an issue.
GIM>> Because mpBFD control packets cannot be demultiplexed by=C2=A0 tail based on the value of Your Discriminator field as per RFC 5880,
the new procedure outlined in Section 4.7:
=C2=A0 =C2=A0IP and MPLS multipoint tails MUST demultipl= ex BFD packets based on a
=C2=A0 =C2=A0combination of the source address, My Discriminator and the identity
=C2=A0 =C2=A0of the multipoint tree which the Multipoint= BFD Control packet was
=C2=A0 =C2=A0received from.=C2=A0 Together they uniquely= identify the head of the
=C2=A0 =C2=A0multipoint path.
and described in details in Section 4.13.2:
=C2=A0 =C2=A0 =C2=A0 If the Multipoint (M) bit is set

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If the Your Discrimina= tor field is nonzero, the packet MUST be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discarded.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Select a session as ba= sed on source address, My Discriminator
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and the identity of th= e multipoint tree which the Multipoint
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD Control packet was= received.=C2=A0 If a session is found, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bfd.SessionType is not= MultipointTail, the packet MUST be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discarded.=C2=A0 If a = session is not found, a new session of type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MultipointTail MAY be = created, or the packet MAY be discarded.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This choice is outside= the scope of this specification.

Would you suggest additional text to a use case where the new demultiplexing is not sufficent to protect from source address spoofing?

 [BB]: I seem to have become co-opted into redesigning this protocol. I'd prefer to limit my involvement to reviewing :)



7/ Scope
On eight occasions an issue is raised, but resolution is stated as outside the
scope of this document. It is OK to limit the scope of a spec, for example to
allow for multiple solutions to each issue. But at least one solution must
already exist for each of these eight issues. So, at least one example solution
ought to be cited in each case. If any issues are open, then this should not be
on the standards track.

It would be more useful to state why each issue is out of scope. This would be
helped by stating from the start what the scope of the document is.
GIM>> I've listed all eight occasions with the explanation for each one:
  1. Details of tail notification to the head are outside the scope of this document. - Notifications by tails addressed in=C2=A0draft-ietf-b= fd-multipoint-active-tail. Will add as informational reference.
 [BB]: Good.

Nonetheless, given you have confirmed that a reverse path is optional, the doc still needs to address the case where there is no reverse path.
GIM2>> Introduction note= s:
=C2=A0Use of BFD in Demand mode enables a tail monitor availab= ility
=C2=A0of a multipoint path even without the existence of so= me kind of a
=C2=A0return path to the head.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

{Note 1} For the active tail draft, you might find the following ideas for scaling multipoint feedback useful:

Statistical feedback:
Nonnenmacher, J=C3=B6. & Biersack, E.W., "Scalable Feedback for Large Groups," IEEE/ACM Transactions on Networking 7(3):375--386 (June 1999)

FUHRMANN, T., AND WIDMER, J. "On the scaling of feedback algorithms for very large multicast groups," Computer Communications 24, 5-6 (March 2001), 539 547;
WIDMER, J., AND FUHRMANN, T. Extremum feedback for very large multicast groups. Tech. Rep. TR 12-2001, Prakfische Informatik IV, University of Mannheim, Germany, May 2001.

Also, anycast can be used to select different representative feedback tails, e.g. for a certain time, which might overlap with the periods for which a few other tails are selected using subsequent anycasts.

Logical 'AND' feedback:
Burbridge, T., Soppera, A., Briscoe, R. and Jacquet, A. "Method and device for co-ordinating networked group members" Patent WO2004059479, (Jul 2004; Priority 24 Dec 2002)
[AFAICT this patent is still being maintained, so use of it in a protocol would require an IPR declaration.]


  1. Details of how the head keeps track of tails and how tails alert their connectivity to the head are outside scope of this document. - Same as #1.
 [BB]: And my response is same as #1.
  1. Bootstrapping BFD session to multipoint MPLS LSP in case of penultimate hop popping is outside the scope of this document. - It may use control plane as in MVPN draft. Will add as informational reference.
 [BB]: Good.
  1. Use of other types of encapsulation of the BFD control message over multipoint LSP is outside the scope of this document. - This in reference to ACH encapsulation that is discussed in=C2=A0draf= t-mirsky-mpls-p2mp-bfd. Should it be added as informational reference? What would be the imacpt of progressing this specification?
[BB]: See earlier comment about citing individual drafts (I don't have enough BFD knowledge to give a BFD-specific answer).

Also, in my review I should also have said: when creating new encapsulations, pls see the common transport issues related to encapsulation:
https://trac.ietf.org/trac/tsv/= wiki/tsvdir-common-issues#TunnelingprotocolsandTransportRelatedIs= sues


  1. Change in the value of bfd.RequiredMinRxInterval is outside the scope of this document. - Same as #1.
 [BB]: And my response is same as #1.
  1. If a session is not found, a new session of type MultipointTail MAY be created, or the packet MAY be discarded. This choice is outside the scope of this specification. - I propose to add "based on local policy" to the last sentence.
 [BB]: On what basis will local policy decide? It's my job as a reviewer to ensure that this spec does not contain any loose ends (open issues).
GIM2>> It could be based on= the maximum number of MultipointTail sessions and number of active Multipo= intTail sessions on the node. I'd clarify it as:
=C2=A0 = This choice MAY be controlled by the local policy, e.g. maximum number of= =C2=A0
=C2=A0 MultipointTail sessions and number of active Multip= ointTail sessions,
=C2=A0 and is outside the scope of this specif= ication.



  1. The exact method of selection is application-specific and is thus outside the scope of this specification. - This is copied from RFC 5880: "The exact method of selection is application specif= ic and is thus outside the scope of this specification."= ; as the section is to replace Section 6.8.6.
 [BB]: OK.
  1. If a matching session is not found, a new session of type PointToPoint MAY be created, or the packet MAY be discarded. This choice is outside the scope of this specification. - Same as #6.

 [BB]: And my response is same as #6.
[Sry, my embedded comments have broken your numbered list.]


    =C2=A0

There is also one issue that is "for further discussion&= quot;. Does this mean the
document is not ready yet?
GIM>> I think that the question left for further discussion is non-technical:
=C2=A0 =C2=A0The semantic difference between Down and Admi= nDown state is for
=C2=A0 =C2=A0further discussion.=C2=A0
I propose to remove the sentence altogether.
 [BB]: OK.



8/ Incremental deployment

Section 4.4.1.=C2=A0 "New State Variable Values" de= fines bfd.SessionType =3D
PointToPoint as well as a couple of Multipoint alternatives. Presumably this
spec does not require all existing PointToPoint systems to support this state
value. Is the implication that only Multipoint systems that happen to be in
PointToPoint mode should use this state?
GIM>> You're aboultely right, existing implementations of BFD don't need to support bfd.SessionType variable. Only implementations that support the base BFD, single-hop or multi-hop, and this specification, mpBFD, should support bfd.SessionType and set it to PointToPoint value when BFD is in single-hop or multi-hop mode. When in mpBFD mode, bfd.SessionType will be set to either MultipointHead or MultipointClient.
 [BB]: Doesn't something need to be written (or referenced) to clarify all this? AFAIR, this spec. never made clear that multipoint is a fork in implementations.
GIM2>> And s= o is S-BFD. (Note, bfd.SessionType introduced in RFC 7880 S-BFD but missed = to define PointToPoint value).=C2=A0




=3D=3DNits=3D=3D

* Sometimes 'tree' is used to mean a multipoint path = in general. I suspect
'path' was intended.
GIM>> I've found six occasions of "tree&quo= t; and s/tree/path/=C2=A0

4.8.=C2=A0 Packet consumption on tails
s/Node/Nodes/
s/packet/packets/
s/demultiplex/demultiplexed/
GIM>> Accepted all three.=C2=A0

4.9.=C2=A0 Bringing Up and Shutting Down Multipoint BFD Servi= ce
"
=C2=A0 =C2=A0a newly
=C2=A0 =C2=A0started head (that does not have any previous st= ate information
=C2=A0 =C2=A0available) SHOULD start with...
"
...
"
=C2=A0 =C2=A0... (so long as the restarted head
=C2=A0 =C2=A0is using the same or a larger value of bfd.DesiredMinTxInterval than
=C2=A0 =C2=A0it did previously).
"
If it has no state available, how can it know whether a value is larger than
previously?
GIM>> You are right, the BFD system at the head would not know the previous value of=C2=A0bfd.DesiredMinTxInterval. This text is to caution operator from decreasing=C2=A0 bfd.DesiredMinTxInterval upon restart of the BFD system.

4.9.=C2=A0 Bringing Up and Shutting Down Multipoint BFD Servi= ce
There are a number of "SHOULD"s and "SHOULD NO= T"s that do not state or give
examples of circumstances in which the "SHOULD" wou= ld not be appropriate. If
there are none, "MUST" would be more appropriate.
GIM>> In the first paragraph SHOULD may not be followed if the implementation can differentiate between the very first start and restarts of BFD system. If it is the first start of BFD system, the head MAY directly progress to Up state skipping Down state.
The last paragraph describes graceful shuttdown. The head MAY shut the BFD mp session abruptly by just stopping transmission of BFD Control packets.
[BB]: I assume you will say all this in the next rev, not just in this email.
GIM2>> Appended the following:=
NEW TEXT:
Alt= ernatively, the head MAY stop transmitting BFD Control packets=C2=A0
<= div> and not send any more BFD Cont= rol packets with the new state (Down or AdminDown). Tails
will declare the multipoint session down = only after the detection time interval runs out.=C2=A0



4.10.=C2=A0 Timer Manipulation
"
=C2=A0 =C2=A0Because of the one-to-many mapping, a session of= type MultipointHead
=C2=A0 =C2=A0SHOULD NOT initiate a Poll Sequence in conjuncti= on with timer value
=C2=A0 =C2=A0changes.=C2=A0 However, to indicate a change in = the packets,
=C2=A0 =C2=A0MultipointHead session MUST send packets with th= e P bit set.
=C2=A0 =C2=A0MultipointTail session MUST NOT reply if the pac= ket has M and P bits
=C2=A0 =C2=A0set and bfd.RequiredMinRxInterval set to 0.
"
The initial "SHOULD NOT" needs to be written anothe= r way. Perhaps
"
=C2=A0 =C2=A0...a session of type MultipointHead
=C2=A0 =C2=A0does not initiate a Poll Sequence
"
The head's normative action is defined by the following "MUST", then the tail's
"MUST NOT reply" is what prevents the poll sequence happening.
GIM>> A Poll Sequence starts with the initiator setting Poll bit. Unless the peer sends BFD Control packet with Finl bit set the poll sequence would continue indefinetely. The initial SHOULD NOT, in my opinion, correctly points that the mechanism of Poll Sequence not to be used by MultipointHead when changing transmission interval. I think that MUST in the first paragraph can be downgraded to MAY because the MultipointHead doesn't need to use transition period when changing the transmission interval to lower level, i.e., decreasing frequency. May I propose the following:
OLD TEXT:
=C2=A0 =C2=A0Because of the one-to-many mapping, a sessi= on of type MultipointHead
=C2=A0 =C2=A0SHOULD NOT initiate a Poll Sequence in conj= unction with timer value
=C2=A0 =C2=A0changes.=C2=A0 However, to indicate a chang= e in the packets,
=C2=A0 =C2=A0MultipointHead session MUST send packets wi= th the P bit set.
NEW TEXT:
=C2=A0 =C2=A0Because of the one-to-many mapping, a sessi= on of type MultipointHead
=C2=A0 =C2=A0SHOULD NOT initiate a Poll Sequence in conj= unction with timer value
=C2=A0 =C2=A0changes.=C2=A0 However, to indicate a chang= e in the packets,
=C2=A0 =C2=A0MultipointHead session MAY send packets wit= h the P bit set during transition period.
 [BB]: If I were an implementer, I would not know what this is saying I ought to implement. The spec needs to answer this question: If the head changes the packets what happens differently if it sets the P bit vs. if it doesn't?
GIM2>> I t= hink we can expect that the implementer is familiar with RFC 5880 and, very= likely, has implemented it one or more times already.=C2=A0


4.11.=C2=A0 Detection Times
Delete "in the calculation" (repetition).
GIM>> Done.=C2=A0

4.13.1.=C2=A0 Reception of BFD Control Packets
Some actions seem to be only relevant to PointToPoint sessions, but they are
stated for all session types. Specifically: "the transmission of Echo packets,
if any, MUST cease." "the Poll Sequence MUST be terminated." "MUST cease the
periodic transmission of BFD Control packets" "MUST= send periodic BFD Control
packets"

"
If bfd.SessionType is PointToPoint, update the Detection Time as
=C2=A0 =C2=A0 =C2=A0 described in section 6.8.4 of [RFC5880].= =C2=A0 If bfd.SessionType is
=C2=A0 =C2=A0 =C2=A0 MultipointTail,
"
The second sentence above ought to start on a new line as an Else if.
GIM>> Hope I got it right:
=C2=A0 =C2=A0 =C2=A0 If bfd.SessionType is PointToPoint, u= pdate the Detection Time as
=C2=A0 =C2=A0 =C2=A0 described in section 6.8.4 of [RFC588= 0].

=C2=A0 =C2=A0 =C2=A0 Else

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If bfd.SessionType is Mu= ltipointTail, then update the Detection
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Time as the product of t= he last received values of Desired Min
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TX Interval and Detect M= ult, as described in Section 5.11 of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this specification.=C2= =A0

4.13.2.=C2=A0 Demultiplexing BFD Control Packets
"
=C2=A0 =C2=A0This section is part of the replacement for [RFC= 5880] section 6.8.6,
=C2=A0 =C2=A0separated for clarity.
"
Do you mean "This section replaces the sentence: "I= f the Multipoint (M) bit is
nonzero, the packet MUST be discarded." in [RFC5880] section 6.8.6?

The statements under "If the Multipoint (M) bit is set&q= uot; are not formatted like
the rest of the if-else logic, and I think an Else is missing at the start of
the statement after the nested "If".
GIM>> Agree, the paragraph is not structured properly. How about this formating:
=C2=A0 =C2=A0 =C2=A0 If the Multipoint (M) bit is set

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If the Your Discriminato= r field is nonzero, the packet MUST be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discarded.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Select a session as base= d on source address, My Discriminator
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and the identity of the = multipoint path which the Multipoint
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD Control packet was r= eceived.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If a session is found, a= nd bfd.SessionType is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MultipointTail, the pack= et MUST be discarded.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Else

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If a session is = not found, a new session of type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MultipointTail M= AY be created, or the packet MAY be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 discarded.=C2=A0= This choice is outside the scope of this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specification.= =C2=A0

[BB]: As long as this represents the logic you want, fine. The point is that the indentation is the only clue to whether one 'if' is conditional on a previous 'if', or not.

HTH

Bob




--=
=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--000000000000b50dda056ddbbb2b-- From nobody Tue Jun 5 09:09:53 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04611310EE; Tue, 5 Jun 2018 09:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 fbil5DvIUKgm; Tue, 5 Jun 2018 09:09:42 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00135.outbound.protection.outlook.com [40.107.0.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8891310AD; Tue, 5 Jun 2018 09:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M0CTiStrEMvyHtYISCG6AdzKAMM0nuLSquKY34Pw7jM=; b=EgOFRc8TUPPxjs143foHhrHMLeEEI4uitupsN5iu7yCOOSVwsrBVlx0uoMInPlAT6Qikwed8R3Umt6yJf7e3kt7GKXyQvDCpQUN+NPgCoHyZe/3IybLaALBzTBENvnqH1aKRPcVBmzT0xNi3ZvQjBZYMi8P0mp7nIoIzgvEwkiM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; Received: from pc6 (86.165.129.94) by DB6PR0701MB2344.eurprd07.prod.outlook.com (2603:10a6:4:60::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.10; Tue, 5 Jun 2018 16:09:39 +0000 Message-ID: <004001d3fce7$58cdbec0$4001a8c0@gateway.2wire.net> From: "tom p." To: "tom p." , "ietf" Cc: , , References: <012d01d3fc28$ade60260$4001a8c0@gateway.2wire.net> Subject: Re: Last Call: (YANG Data Model for Bidirectional Forwarding Detection (BFD)) to Proposed Standard Date: Tue, 5 Jun 2018 17:07:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.165.129.94] X-ClientProxiedBy: CWLP265CA0159.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:52::27) To DB6PR0701MB2344.eurprd07.prod.outlook.com (2603:10a6:4:60::10) X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:(219612443155931); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(2017052603328)(7193020); SRVR:DB6PR0701MB2344; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2344; 3:ADWbZWaMsIIBp70JZJ4RfgzoyZnVdSfmTHMlTNUoWsHuD5ljSQz4CflA3tlxi/vzueumv/JzRnhvIkBNcsAi8sox4ehCrPrk1jSGn2giIXFkR3ONeMkXa3SUXsXcgXIEmu1+oCAevMQnekQlNwqVwpKyggcyiuzHXwaE5VcfLfKECHtUBhWlnP2OVuCz1tMscGgvm9dZwza9T9UZR8lwp4u4fT8S2h3SLBtQyJYqjInM5zC9V/NWkaRlADZvxyowgkHb2I3GRVxWtpV1z+EjOkXJ9ENaM9UmlBc48AVH1eE=; 25:bjfRXXFVKDqPNNgZO95+3jHIvvE1fC3dsbctwfsUDhMBOULqx/uWK2AEKfEaUtjMLuDXfLhHfhOR+ZAA9SOIrhYLiaItY02WLIlQWkvi4voAM75bW5GOy0dUPOM9pT3J6muqZKkQpXRhjyt0yYRoTSBtNeoeTGfvT3S4MAo1OP9QQLLI02o7SzPYXjCZ3EAK02keDDslwsb1HaUZWZVNN7B40LVMes+zBbmRS69Obkm7SLjs1F2wtY5hLvIgerpIwByZULeFR3i6AxwXbU7DTbmLKxTgyLkC6BXQiwyutilYfU59K+pPmZwfyYnUogLPZNsxx0aQUPeLsa6EzHXiuw==; 31:sahbojzobXHEvoRzRbAQrPXFTHj+/JPwulQnJ/++QXIatTLIedgvxfN4q5baAQwyADUNQR/rfEg2q0ReA+LmemY3pi7fBEQQpEB3l5AxYNIzyrPzdXxNbAY9jO6B8u4xvlmR2APQAapKNpEo0ZCqQiX1qyq9pm1q2bKe2JO21v/GrSxd4hMIzqV3SzWXQZOcyxN8RoW7KOScLDl4W/WHQPUkih1a3rqBZnqr5RKT8vI= X-MS-TrafficTypeDiagnostic: DB6PR0701MB2344: X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2344; 20:0Fzs6PwoYW/oT4w1965tH6++gIF8DpuxEzxXPxsmNbLZSBHF2/E//zWXdQmR+zo1D05iLhPukrBe8FcZIBPREZu/ohqO4r5MVN8Iz0SNJxy0tpwKx5nywXiKVpFgrFyW7KW4d987/qV5sM0nZPCea/AGEY8bz4a6RROrhWfbELg=; 4:N3xgyu1MkowOmufvXB8awGbvIYiO+5xCXbU6+b8XmK3lLMA+AZzWauFSOVm/q3lQd5ZURfkFZ70M9YGqv6CtqzIR1l2O9cPlcZPE6wH1+qYtHrDvkfKgBwURMUFlBiBhI/7Pkod/fDYTmEr8XR3AQIFL64OFPCYrq+knPj/DvVq6piwutWvvxaSkd/J86FcnlOp8A/Ssp/7Tyi/PNAOAW5Vh92z3UbbXfqKYYAMkyAf6wWgSkQhSb2tjRsp5p6v67aHYYCJ08F8+A1fsu7j5ph66758SrTUDjzw7cE0hSHJ7kMDGUMXRzxJD8icE05ZhKsBXB10Jyr+QB3FrLewFtz94DAA19vO2xn0xYRyFikqKM3Q7QKL9jWv/+lMifNfv X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(120809045254105)(219612443155931); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(3231254)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:DB6PR0701MB2344; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2344; X-Forefront-PRVS: 0694C54398 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39380400002)(396003)(39860400002)(366004)(199004)(189003)(13464003)(54906003)(61296003)(84392002)(296002)(9686003)(305945005)(2906002)(956004)(476003)(446003)(7736002)(14496001)(97736004)(316002)(8666007)(6306002)(105586002)(53936002)(68736007)(106356001)(44736005)(486006)(6496006)(8676002)(3846002)(25786009)(6116002)(81156014)(81166006)(86362001)(230700001)(229853002)(4326008)(4720700003)(59450400001)(1556002)(386003)(50226002)(16526019)(62236002)(8936002)(47776003)(33896004)(6246003)(23676004)(6666003)(50466002)(81686011)(44716002)(2486003)(966005)(5660300001)(81816011)(66066001)(478600001)(76176011)(110136005)(6486002)(52116002)(26005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2344; H:pc6; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3MDFNQjIzNDQ7MjM6K0ZwbjFXMnBlaUtjMWZxUUFsbEg2d2Fn?= =?utf-8?B?OGpUUHJGeEJzVlVXbzFBbjkxNzVZQk9zL3p1ZU5WRVl1ZWUyQW40MXZkb1Yv?= =?utf-8?B?TkwzNkZvUGw3ajhRTjRiRzc0NjlBZ1ZTSk0vUnphWXNOWUFHNk5IT2xSRDI2?= =?utf-8?B?Rmx6MGtkWGYveGZNNFB6WXlDdTQzcWFDakNJVkVYZnNIVFN4MHIwWHlScHVT?= =?utf-8?B?TndSUTl6YUpXdngrTGlrUnhjZldKcGVmNTBPdEJMSE01RzFKbnR4NkpFa2R1?= =?utf-8?B?cHd2RGpqdmR0UmFIUG8wL21EWDZFcjRDb1JYTzZwdUhhWU5nSFp5THNhZm4w?= =?utf-8?B?VGRIcnFzbHVtSThPaDdFcStpSm9pc05rZlVtL2l5Yk45bDJqOWJVZGlKM3BO?= =?utf-8?B?THFMWFBvaHlySjJseXdKU1k2RThHZVBXV3k3R2xiaFozT29sZmk4KzIrMUZ6?= =?utf-8?B?ZmVyamRVSkhnaVRYQk53L0tXaHd1Tk9EUVhaSldDeUx2K3BIRFRkSENjdnpo?= =?utf-8?B?TnAzeUozR3Q3L0hhMWl0SG9tcW5ncTF5c2NYVHhUTnRFZkUxZUVCdjhxaUhL?= =?utf-8?B?TkFxMmhsR0x6T3pDQjdsUkp3T09BNlBadGVRQ2hrN3hUSGRrNm5wMlE5VnRm?= =?utf-8?B?WHZhRW9KQ3lmTXhNVlJ3UFFTZDFhS1IwNGw3YjFjQUtONnd4TFVPVVRtNFFU?= =?utf-8?B?c3lJQXh2TXNtTXJaZFQyZ2R1aStWOUhFc01kZnA3MkxiVjVPMEJJYjlJRFJo?= =?utf-8?B?NlNHTkYrZlA3cXBnVE4rWEpkcmNNbTZicC9helJiYzcrSWZsd1FFWE5zblRP?= =?utf-8?B?UUNPd2JwSjNiQnVQamVTZ2xVdmhZL2NWZU5CRnRIVXVFM0FtTFp0UG9OTHla?= =?utf-8?B?cnZGUnVEdGFoZzFzQVgrNFY2aS8ybm9hcVZGYVdMbS9VUkpZaXBSa3V1NDVw?= =?utf-8?B?RTZjTFpraVVhbUpvVDVjOVE5dnkyRm51VFVWN0c3ZUhjbU9Hd2FvK2lad3lm?= =?utf-8?B?NzF2VW5MTUhJc0FkNjRjdnNIeU5jSmRtbUxhT1ZwcnBWNkJTT3Awa1J1K2t5?= =?utf-8?B?ZmdaL3lTMGQ1RVdFeTNybjU4LzYxbUpzRnd2dDFwKzNjeVc1eVV1MWhQQVdr?= =?utf-8?B?czc0UGdEWUsxbkJXZ0NncEVLbGlEZ2VaQXB2aWtkZEdoVkNXalNjdllyYUpp?= =?utf-8?B?SUJBdUdFWmp3WlVCN2greG5rR2NCZHNCUmpiMDZGcjZpeG5RelZiZTJIOU5R?= =?utf-8?B?WG5SNDhNUnJrZUpoT1E0eHA3ajFZcU8xUUJoNGRkSmhrNkFPUC9Ud2VRdTNo?= =?utf-8?B?QjFsdzVQWXFnNWx6czZPUWZzK1JXa2NvWG9uWlZRamF1VUdzUi9HeldheUhG?= =?utf-8?B?NEJBRGtqT2djUjBWVDJhaXlhRGVqN3ZvU3lSQVVIRzFpNzJZeUhrenZCZFJ5?= =?utf-8?B?ZmR2aVpTb1A3V3NPSmd1SkQ3NlpjMDlUaW5Ld2p1YytJRmsvTksrQXpiQ3k0?= =?utf-8?B?cU02RWZhcDhla2s3N1hkL3FPTjdJS2dXNEhlMlh6YUlzNFRCQy9xSUJvdXFx?= =?utf-8?B?dU05UFdpWmxsWUFLa1p5K3pUMXFPQVNWaHZ2ckhPZUd5OEI2OURtS1puWkZT?= =?utf-8?B?OW1tTURUQy92Sk10NVVMdll6bFF4NU5Odi9lemlwaTZ0THdrb3hLSXEzTERZ?= =?utf-8?B?bE5Sb0VJaDZiZDZxMm40TFJmb25RbVd6Ykp0R0REbnF4eCtpL1laNWRIM0VR?= =?utf-8?B?bWRsV0JOT1VRTzBXd2xiaHNDY2h6SnJXVHpWcnE3RkdNQUpWNFdmcExsUlU1?= =?utf-8?B?OEpaWW45SWIwUXorMzM5OXhjV3I5RVFIbTJZd0lrbVk0YlhjYkVyQ1NObmFm?= =?utf-8?B?dFNqQkxEd3M1T1ZiREh6cWkwakRuVTQwUkZxZjZhOE54dzZjcG8vU1V3WVZH?= =?utf-8?B?V3NSUk5jcUFPUkc1emtCZlpEOFhra25oU0NIL2pvbHFycnJGOFlFcjJEUVdW?= =?utf-8?B?b0xmYm5QbTQ0czYybUVFbW15cDQzcXpTeVArWW5QKzc3SVhsT3g4NE5GRU5x?= =?utf-8?B?SkY4YnlsOHpablRBRlVqZ2RkaS85MDRkTFhUVTkwSW1lUU9UZUxHRzVibHE2?= =?utf-8?B?OVVxUT09?= X-Microsoft-Antispam-Message-Info: vlBA0pKTGl7rjt7n4Mh3EXGv2kcPPhO2g7BHMNpUqn3wnyy+IjYcQ+gxqp7PaC2gJBURdhmOvUzrUuIPk/jTg9ouUAkXZeSLgYxNbklApkihp0+4J+8oOl3tcV/kkQq6mdTjmBguC+gHFsimxOUuo3UXl3qbfOv2SUZsWnmZQP1DewATdNJcLHfgqlE8Ho+r X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2344; 6:iVTc+x1mB3m0rLkiJ1Y4iyTmAZpfmgKdPiNBQyxIhkKjPcDMtlyqHBdiADGJWHXzuONCsaL8v8KzJjeQNJRsSQaE0mXSfrubSfwHKBhwv3i1l3DfXwznXFxFMoo5tFWBVefDzIsLiag+F09eZ/zaZv6SzKLYIzot3JyleVdYc3BaFK1Q/cBrtatnv6zLxRsbCNpUi5zScRHH5IGlfOBW2XJNKG9tbOkdrjG/NYGP0V3qTOksCbO2+YpQk6+NHAJwGnx0nPFUJM0CTKyy33tuP1Oaad5sUX6kZjKyhBaO0k006BbKewuTr7Aeev0YfTf9wB1UZixG9YmJJWfi08a42vSG4FAkpSoXkGtx+VMVJSKi6GcHHE/e7b4WKb4slXOYaRhRQHpA5Ha4WdE1WjOcU0xzt5WxLSd8nOmqDkWFowPSDA/wEezLbfgX2INYLW6izGUj5mf7TH1UmWlI/cNx/g==; 5:YdAJc+jRS47YmHHNfjC46MVqjQiv+aMblLQ5WeOc/7EWByfSA6d3MKUtyKHK226Hx9SrXP/s2+45mtruxN7s5yNlKGsnykkPthHyAO4y5g1rIOj6++wGRvwVOsQZ5csEHd6L47Of/TWJQwzSYaWu+TNkZwu8D4DKHKX2tqHn33o=; 24:s94mgWUf/gvmVf8Irv4ZO0YZneXkRsKLmAwv+OAZOChW5M+10dWgQGWi9+LBMq3XuPk63CFTUKh92E9oRXdW55y5KsytbHTp9PnAR2G2Wo8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2344; 7:IxTgs/RC5TEcwsD3VIy97l6daRyjC7goRfKNSrbVzVZcurS8fTS4mb376agIH7e53FusyfEKXFs8qlTcrrDs6Js1adfaGI+RMiLUrRP0Ub9WvVQZjWOpRMqUnOqcsoJijxyhorOYAocE3W1ldByH6mAr3p5mrGlxbBw/tnvAT2bjBDKfhZrJeZ3CT7a6fjt8ATsHDy7feXvGE4+A+mVTOCKjfZkATZDYjzWq7W4Ji5V/RSeSf/3i+uH6xef2dRh0 X-MS-Office365-Filtering-Correlation-Id: f6c61555-bbef-4c71-1b46-08d5cafebda9 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2018 16:09:39.1367 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f6c61555-bbef-4c71-1b46-08d5cafebda9 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2344 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 16:09:45 -0000 The newly published -14 addresses these comments I made, below. Tom Petch > ----- Original Message ----- > From: "tom p." > Sent: Saturday, May 26, 2018 12:19 PM > > > This I-D has a number of import statements from other YANG modules for > > which there is no Reference statement where I believe that there > should > > be, statements such as . > > > > import iana-bfd-types > > import ietf-bfd > > import ietf-bfd-mpls > > import ietf-te > > import ietf-routing > > > > In the first three cases, it may be that the editors of this I-D > > consider that such a reference is not needed because the relevant > > modules are in the same I-D but such thinking is erroneous. These are > > separate modules which will lead independent existences in the wild so > > that there will be nothing to tell a user of e.g. module > > ietf-bfd-mpls-te > > where to look for > > ietf-bfd-types, ietf-bfd, ietf-bfd-mpls > > > > These need reference statement such as > > > > reference "RFC XXXX: YANG Data Model for BFD"; > > > > Tom Petch > > > > ----- Original Message ----- > > From: "The IESG" > > To: "IETF-Announce" > > Cc: ; ; > > > > Sent: Friday, May 25, 2018 2:26 PM > > > > > The IESG has received a request from the Bidirectional Forwarding > > Detection > > > WG (bfd) to consider the following document: - 'YANG Data Model for > > > Bidirectional Forwarding Detection (BFD)' > > > as Proposed Standard > > > > > > The IESG plans to make a decision in the next few weeks, and > solicits > > final > > > comments on this action. Please send substantive comments to the > > > ietf@ietf.org mailing lists by 2018-06-08. Exceptionally, comments > may > > be > > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of > > > the Subject line to allow automated sorting. > > > > > > Abstract > > > > > > > > > This document defines a YANG data model that can be used to > > configure > > > and manage Bidirectional Forwarding Detection (BFD). > > > > > > The YANG modules in this document conform to the Network > Management > > > Datastore Architecture (NMDA). > > > > > > > > > > > > > > > The file can be obtained via > > > https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ > > > > > > IESG discussion can be tracked via > > > https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > The document contains these normative downward references. > > > See RFC 3967 for additional information: > > > draft-ietf-teas-yang-te: A YANG Data Model for Traffic > Engineering > > Tunnels and Interfaces (None - IETF stream) > > > draft-ietf-mpls-base-yang: A YANG Data Model for MPLS Base > (None - > > IETF stream) > From nobody Thu Jun 7 18:37:56 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B0D130DF6; Thu, 7 Jun 2018 17:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 hBW8kUJO8aqG; Thu, 7 Jun 2018 17:02:45 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 1BD18130DED; Thu, 7 Jun 2018 17:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=X3172GkKG12rfmJxLA5UHP4hO75plTiAJBqOB6UxSv4=; b=p+yJ8dml7y3uTqF7CeYvK6jp7 C8D42LNfYQy1L7/D9L3XLeGIlp0vnQTXXekSiN936mQ2gg8jdmn3wAkwlMQM3pIqkukG4AxvNm8QY klUF6VBDhQw1aEsegGE5oI4wK2SNouLgBk/Y4UbLIsGCRA1CaGZdX4WPU/XCTMrm0Fyl2XZlVmx/u TkLtb3icG1h8NAWJvZK5oJGdFKBEKPJ7CGbxNBjsl2FD5d8K1t9tlt4nlOZses7ObB3SoMy7eZYR4 E78va/zY7XJuPyMetpRy+GSNGdZ4gbGLGd+FFs2rxLDKIkPir+K00qLNDMgMIXmvtlxKlWaFuV7mG zrGFEKCyg==; Received: from host-79-78-166-168.static.as9105.net ([79.78.166.168]:33686 helo=[192.168.2.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1fR4rV-0006lO-V2; Fri, 08 Jun 2018 01:02:40 +0100 Subject: Re: Tsvart last call review of draft-ietf-bfd-multipoint-16 To: Greg Mirsky Cc: tsv-art@ietf.org, draft-ietf-bfd-multipoint.all@ietf.org, rtg-bfd@ietf.org, IETF list References: <152694840016.8083.12174100605609215107@ietfa.amsl.com> <1afa9af2-9fce-1588-ca09-cd39f1122688@bobbriscoe.net> From: Bob Briscoe Message-ID: <4a8bd1a3-3cfc-9c9c-c2cd-d0f8467da2c8@bobbriscoe.net> Date: Fri, 8 Jun 2018 01:02:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FAC01BFEF94116A1C31C9BED" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: X-Mailman-Approved-At: Thu, 07 Jun 2018 18:37:55 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 00:02:54 -0000 This is a multi-part message in MIME format. --------------FAC01BFEF94116A1C31C9BED Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Greg, Your responses are AOK now. *Remaining Security Vulnerability** * I think you may have misunderstood my point about vulnerability to source address spoofing without a 3WHS. When you said in response: > >> Would you suggest additional text to a use case where the new >> demultiplexing is not sufficent to protect from source address spoofing? I said: > [BB]: I seem to have become co-opted into redesigning this protocol. > I'd prefer to limit my involvement to reviewing :) If this wasn't clear, I meant, "I believe this protocol has a security problem that needs to be fixed. But it's your job to fix it, not mine." If you can't fix it, I suggested that you need to at least add a section listing all the limitations when a multipoint scheme has no back channel (the others being no feedback on timing control and no way to set up asymmetric authentication). Apologies, if the following is already obvious to you, but it is safer to be over-cautious: The text you originally quoted in response to my point about 3WHS uses the source address as part of the identification of a session. That is the problem (not a solution). If a malicious host M masquerading as the source S spoofs the source address of S in its packets, the tails will not be able to tell that these packets are not from S. A 3WHS (e.g. as in TCP) is a simple way to address this vulnerability, by the tails using the routing system to send a packet to the location where the source claims to be sending from. I.e. the tail returns a packet to address S with some random information in it (in TCP's case, the initial sequence number). If S genuinely initiated the handshake, it will reflect the random info to the tail in the 3rd way of the handshake. If M is masquerading as S, it will not receive the 2nd way of the handshake. And it won't be able to spoof the 3rd way without the random info. Without a 3WHS, multipoint BFD does not check that the source address is genuine. *Some (mostly editorial) comments from scanning the diff:** * In the intro, the para starting "As an option, the tail may notify the head..." is prerequisite info that needs to come before the para ending "even without the existence of some kind of a return path to the head." s/in the received by MultipointTail BFD Control packet/  /in the received MultipointTail BFD Control packet/ s/entire/the entire/ (twice) Section 6 (Assumptions) has no flow of logic between the new text and the pre-existing text. It would be better to switch the order of the paras. Otherwise, I think my comments are becoming increasingly less useful, so I'll stop. I don't know enough about the whole ecosystem around this draft to be any more helpful, I think. Bob On 05/06/18 03:23, Greg Mirsky wrote: > Hi Bob, > thank you for further clarifications and the new ideas. Please find my > follow-up in-line and tagger GIM2>>. > I'll check for nits and grammar and will publish the new version shortly. > > Regards, > Greg > > On Tue, May 29, 2018 at 3:22 AM, Bob Briscoe > wrote: > > Greg, > > > On 26/05/18 20:49, Greg Mirsky wrote: >> Hi Bob, >> thank you for the thorough review, detailed questions and helpful >> comments. Please find my answers in-line and tagged GIM>>. >> I've updated the working version of the draft based on your >> comments and suggestions. Appreciate your feedback whether all >> questions have been addressed. >> Attached please find the diff of -16 and the working version and >> the copy of the working version of the draft. >> >> Regards, >> Greg >> >> On Mon, May 21, 2018 at 5:20 PM, Bob Briscoe > > wrote: >> >> Reviewer: Bob Briscoe >> Review result: Not Ready >> >> Altho this is a TSV-ART review, I did not find many >> transport-related issues to >> focus on, except a need to justify why lack of information >> for adapting the >> transmit interval is not an issue. >> >> Nonetheless, I did find a few other non-trivial technical >> issues, including 2 >> security issues, enumerated below (I mis-spent some of my >> early research career >> working on a multicast session control and security, for >> which we used >> beaconing control channels). However, I only have passing >> prior knowledge of >> BFD, so my critique might be off-beam. >> >> ==Main Technical Concerns=== >> >> 1/ Mandatory return path? >> RFC5880 is the base RFC that this draft updates. RFC5880 says >> that >> "unidirectional links" are in scope, but only as long as >> there is a return path. >> >> The introduction of this bfd-multipoint draft seems to >> contradict that, making >> a return path optional: " >>    As an option, the tail may notify the head of the lack of >> multipoint >>    connectivity.  Details of tail notification to the head >> are outside >>    the scope of this document. >> " >> It's allowable for irrelevant details to be outside the >> scope, but surely it >> needs to be clear whether at least the existence of a return >> path is mandatory. >> >> GIM>> Thank you for highlighting this issue. I think that the >> second paragraph of Introduction is the appropriate place to note >> that this mechanism does not require existence of a return path >> from tails to the head. Would the following be acceptable: >> NEW TEXT: >>    Use of BFD in >>    Demand mode enables a tail monitor availability of a >> multipoint path >>    even without the existence of some kind of a return path to >> the head. >> >> >> 2/ Mechanism for verifying connectivity, or not? >> The introduction seems to contradict itself: >> " >>    As multipoint transmissions are inherently unidirectional, >> this >>    mechanism purports only to verify this unidirectional >> connectivity. >> " >> " >>    Term "connectivity" in this document is not being used in >> the context >>    of connectivity verification in transport network but as an >>    alternative to "continuity", i.e. existence of a >> forwarding path >>    between the sender and the receiver. >> " >> How can this mechanism verify connectivity, but not be used >> in the context of >> connectivity verification in the transport network? >> >> GIM>> This draft defines the base specification for multipoint >> BFD. In order for multipoint BFD to support the transport-like >> connectivity verification we need to do work similar to described >> in RFC 6428. > [BB]: Caveat: I am having to talk in generalizations, cos I don't > actually know how you are going to get this protocol to work in a > wide range of circumstances, given inherent problems like > multipoint feedback implosion {Note 1}. > > My point was that, having broken up the drafts in this way, this > draft on its own no longer defined a workable protocol. Therefore, > it needed some references to other drafts (even if they are > placeholders), so that the extent of the pre-requisite collection > of work is clear. The refs you give later go a long way to fixing > this issue. > > If each pre-requisite protocol is intended to only represent one > example, the citation can say that and the ref can be informative. > But with zero examples for all the prerequisite parts, all the > reader sees is a dismembered octopus, not a protocol. > > >> >> 3/ Use case >> The introduction seems to be written rather academically. >> Surely, in cases >> where there is never a return path, only the tails will ever >> be able to verify >> connectivity. The head could continue transmitting BFD >> packets (and data >> packets) for years without ever knowing whether it is >> connected to anything. >> Knowledge of connectivity is surely of little use if it >> excludes the link >> sender, which is the node that always controls routing. >> >> If there are scenarios where it is useful for tails but not >> the head to be able >> to verify connectivity, can you please give a concrete example? >> >> GIM>> One example could be a multicast system with 1+1 >> protection. Without multipoint BFD tails would not be able to >> detect the failure of the muticast path from the head. Other >> examples discussed in several drafts: >> >> * BESS WG draft MVPN fast upstream failover >> >> * Individual draft BFD for Multipoint Networks and VRRP Use >> Case >> >> * Individual draft BFD for Multipoint Networks and PIM-SM Use >> Case >> >> >> I am not sure how references to non-WG drafts affect the progress >> of this document. Appreciate your suggestion. > [BB]: In my experience, informative refs to non-WG drafts as > use-cases would be OK during doc development. However, if a non-WG > draft fails to proceed, its citation has to be removed later. So > choose those that are most likely to proceed. > > Nonetheless, if you cite some specs that turn this into a workable > protocol (see previous issue) use-cases might not be necessary. > > GIM2>> I've added reference to use of this mechanism in BGP/MPLS MVPN. > > > >> >> >> 4/ Interval adaptation >> Text is needed to describe why it is not an issue for the >> head to be unaware >> whether it needs to adapt its transmit interval. Otherwise, >> this seems >> potentially problematic. >> >> GIM>> Very interesting, thank you. I wouldn't say that the case >> when a tail cannot process incoming mpBFD control packets at the >> offered rate is entirely non-issue. Such scenario must be handled >> by the implementation and may be controlled by local policy, >> e.g., close the MultipointTail session. > [BB]: Fair enough. > > In some scenarios, this issue will not necessarily be so unlikely tho: > * If asymmetric crypto is used to solve the group message > authentication problem (see later), the processing burden on any > lightweight endpoints might lead to message verification leaving > less available processor resource than needed for the host's other > tasks. > * Each tail might be joined to a very large number of multipoint > sessions. > >> Where would you suggest to add the text? > I would suggest a new section listing potential issues when there > is no back channel. > > GIM2>> I've tried to start the new section but decided to insert the > note in the first paragraph of Timer Manipulation section. Hope that > is acceptable. > > > > >> >> 5/ Inability to authenticate the sender with symmetric keys >> In unicast scenarios, symmetric keys can be used for message >> authentication, >> because each end knows there is only one other node with the >> shared key. But, >> in multipoint scenarios, all the tails would share the key, >> so a shared key >> does not authenticate who sent the message - any tail can >> spoof the head from >> the viewpoint of the other tails. >> >> Therefore text is needed to say that: >> * multipoint message authentication is limited to cases where >> all tails are >> trusted not to spoof the head, if shared keys are used. * >> otherwise asymmetric >> message authentication would be needed, e.g. TESLA [RFC4082] >> >> GIM>> Thank you for the suggested text. Would the Security >> Considerations section be appropriate place: > [BB]: Well, the point limits the applicability of the assumption > about security in 5. 'Assumptions', so this would fit well there. > Then "Security Considerations" should point to everywhere in the > doc that discusses security, such as this (to save time for > security reviewers). > >> NEW TEXT: >>    Use of shared keys to authenticate BFD Control packet in >> multipoint >>    scenarios is limited because tail can spoof the head from the >>    viewpoint of the other tails.  Thus, if shared keys are used, all >>    tails MUST be trusted not to spoof the head. > [BB]: Normally a MUST is applied to implementations. It would be > rather odd to require users/operators to satisfy a spec > requirement, particularly requiring them to trust each other. I > think this should be written as an applicability statement not a > normative requirement. > > GIM2>> I've adopted text suggested by Spencer and moved the paragraph > to section Assumption. > > > >> Otherwise, asymmetric >>    message authentication would be needed, e.g., Timed Efficient >> Stream >>    Loss-Tolerant Authentication (TESLA) as described in [RFC4082]. > > [BB]: If you are going to allow for cases where all tails are > trusted not to spoof the head, then the assumption written in > section 5 is no longer correct. > > [FYI, RFC4082 is only a generic description. Many RFCs have been > written to authenticate specific protocols along TESLA lines.] > >> >> A related nit: Section 5 says all tails are assumed to have a >> common >> authentication key. In cases with symmetric message >> authentication, surely the >> head also needs the same key. >> >> GIM>> Thank you. Please check the updated text: >> NEW TEXT: >>    If authentication is in use, the head and all tails must be >>    configured to have a common authentication key in order for >> the tails >>    to validate received the multipoint BFD Control packets. > [BB]: Yup. Except delete "received the". > Also see above about whether this is now a correct assumption. > > GIM2>> I think that s/must/may/ will keep the Assumption valid. > > > >> >> 6/ Source address spoofing >> A 3-way handshake makes a protocol robust against simple >> source address >> spoofing. Without a 3WHS, surely the spec. needs to highlight >> this >> vulnerability or discuss ways to address it or why it is not >> an issue. >> >> GIM>> Because mpBFD control packets cannot be demultiplexed by  >> tail based on the value of Your Discriminator field as per RFC 5880, >> the new procedure outlined in Section 4.7: >>    IP and MPLS multipoint tails MUST demultiplex BFD packets >> based on a >>    combination of the source address, My Discriminator and the >> identity >>    of the multipoint tree which the Multipoint BFD Control packet was >>    received from.  Together they uniquely identify the head of the >>    multipoint path. >> and described in details in Section 4.13.2: >>       If the Multipoint (M) bit is set >> >>          If the Your Discriminator field is nonzero, the packet >> MUST be >>          discarded. >> >>          Select a session as based on source address, My >> Discriminator >>          and the identity of the multipoint tree which the Multipoint >>          BFD Control packet was received.  If a session is found, and >>          bfd.SessionType is not MultipointTail, the packet MUST be >>          discarded.  If a session is not found, a new session of type >>          MultipointTail MAY be created, or the packet MAY be >> discarded. >>          This choice is outside the scope of this specification. >> >> Would you suggest additional text to a use case where the new >> demultiplexing is not sufficent to protect from source address >> spoofing? > > [BB]: I seem to have become co-opted into redesigning this > protocol. I'd prefer to limit my involvement to reviewing :) > > >> >> 7/ Scope >> On eight occasions an issue is raised, but resolution is >> stated as outside the >> scope of this document. It is OK to limit the scope of a >> spec, for example to >> allow for multiple solutions to each issue. But at least one >> solution must >> already exist for each of these eight issues. So, at least >> one example solution >> ought to be cited in each case. If any issues are open, then >> this should not be >> on the standards track. >> >> It would be more useful to state why each issue is out of >> scope. This would be >> helped by stating from the start what the scope of the >> document is. >> >> GIM>> I've listed all eight occasions with the explanation for >> each one: >> >> 1. Details of tail notification to the head are outside the >> scope of this document. - Notifications by tails addressed in >> draft-ietf-bfd-multipoint-active-tail >> . >> Will add as informational reference. >> > [BB]: Good. > > Nonetheless, given you have confirmed that a reverse path is > optional, the doc still needs to address the case where there is > no reverse path. > > GIM2>> Introduction notes: >  Use of BFD in Demand mode enables a tail monitor availability >  of a multipoint path even without the existence of some kind of a >  return path to the head. > > > {Note 1} For the active tail draft, you might find the following > ideas for scaling multipoint feedback useful: > > *Statistical feedback:* > Nonnenmacher, Jö. & Biersack, E.W., "Scalable Feedback for Large > Groups ," IEEE/ACM > Transactions on Networking 7(3):375--386 (June 1999) > > FUHRMANN, T., AND WIDMER, J. "On the scaling of feedback > algorithms for very large multicast groups > ," Computer > Communications 24, 5-6 (March 2001), 539 547; > WIDMER, J., AND FUHRMANN, T. Extremum feedback for very large > multicast groups. Tech. Rep. TR 12-2001, Prakfische Informatik IV, > University of Mannheim, Germany, May 2001. > > Also, anycast can be used to select different representative > feedback tails, e.g. for a certain time, which might overlap with > the periods for which a few other tails are selected using > subsequent anycasts. > > *Logical 'AND' feedback:* > Burbridge, T., Soppera, A., Briscoe, R. and Jacquet, A. "Method > and device for co-ordinating networked group members > " > Patent WO2004059479, (Jul 2004; Priority 24 Dec 2002) > [AFAICT this patent is still being maintained, so use of it in a > protocol would require an IPR declaration.] > > >> 1. Details of how the head keeps track of tails and how tails >> alert their connectivity to the head are outside scope of >> this document. - Same as #1. >> > [BB]: And my response is same as #1. >> >> 1. Bootstrapping BFD session to multipoint MPLS LSP in case of >> penultimate hop popping is outside the scope of this >> document. - It may use control plane as in MVPN draft. Will >> add as informational reference. >> > [BB]: Good. >> >> 1. Use of other types of encapsulation of the BFD control >> message over multipoint LSP is outside the scope of this >> document. - This in reference to ACH encapsulation that is >> discussed in draft-mirsky-mpls-p2mp-bfd >> . >> Should it be added as informational reference? What would be >> the imacpt of progressing this specification? >> > [BB]: See earlier comment about citing individual drafts (I don't > have enough BFD knowledge to give a BFD-specific answer). > > Also, in my review I should also have said: when creating new > encapsulations, pls see the common transport issues related to > encapsulation: > https://trac.ietf.org/trac/tsv/wiki/tsvdir-common-issues#TunnelingprotocolsandTransportRelatedIssues > > > >> 1. Change in the value of bfd.RequiredMinRxInterval is outside >> the scope of this document. - Same as #1. >> > [BB]: And my response is same as #1. >> >> 1. If a session is not found, a new session of type >> MultipointTail MAY be created, or the packet MAY be >> discarded. This choice is outside the scope of this >> specification. - I propose to add "based on local policy" to >> the last sentence. >> > [BB]: On what basis will local policy decide? It's my job as a > reviewer to ensure that this spec does not contain any loose ends > (open issues). > > GIM2>> It could be based on the maximum number of MultipointTail > sessions and number of active MultipointTail sessions on the node. I'd > clarify it as: >   This choice MAY be controlled by the local policy, e.g. maximum > number of >   MultipointTail sessions and number of active MultipointTail sessions, >   and is outside the scope of this specification. > > > >> 1. The exact method of selection is application-specific and is >> thus outside the scope of this specification. - This is >> copied from RFC 5880: "The exact method of selection is >> application specific and is thus outside the scope of this >> specification." as the section is to replace Section 6.8.6. >> > [BB]: OK. >> >> 1. If a matching session is not found, a new session of type >> PointToPoint MAY be created, or the packet MAY be discarded. >> This choice is outside the scope of this specification. - >> Same as #6. >> > > [BB]: And my response is same as #6. > [Sry, my embedded comments have broken your numbered list.] > > >> >> >> There is also one issue that is "for further discussion". >> Does this mean the >> document is not ready yet? >> >> GIM>> I think that the question left for further discussion is >> non-technical: >>    The semantic difference between Down and AdminDown state is for >>    further discussion. >> I propose to remove the sentence altogether. > [BB]: OK. > >> >> >> 8/ Incremental deployment >> >> Section 4.4.1.  "New State Variable Values" defines >> bfd.SessionType = >> PointToPoint as well as a couple of Multipoint alternatives. >> Presumably this >> spec does not require all existing PointToPoint systems to >> support this state >> value. Is the implication that only Multipoint systems that >> happen to be in >> PointToPoint mode should use this state? >> >> GIM>> You're aboultely right, existing implementations of BFD >> don't need to support bfd.SessionType variable. Only >> implementations that support the base BFD, single-hop or >> multi-hop, and this specification, mpBFD, should support >> bfd.SessionType and set it to PointToPoint value when BFD is in >> single-hop or multi-hop mode. When in mpBFD mode, bfd.SessionType >> will be set to either MultipointHead or MultipointClient. > [BB]: Doesn't something need to be written (or referenced) to > clarify all this? AFAIR, this spec. never made clear that > multipoint is a fork in implementations. > > GIM2>> And so is S-BFD. (Note, bfd.SessionType introduced in RFC 7880 > S-BFD but missed to define PointToPoint value). > > > > >> >> ==Nits== >> >> * Sometimes 'tree' is used to mean a multipoint path in >> general. I suspect >> 'path' was intended. >> >> GIM>> I've found six occasions of "tree" and s/tree/path/ >> >> >> 4.8.  Packet consumption on tails >> s/Node/Nodes/ >> s/packet/packets/ >> s/demultiplex/demultiplexed/ >> >> GIM>> Accepted all three. >> >> >> 4.9.  Bringing Up and Shutting Down Multipoint BFD Service >> " >>    a newly >>    started head (that does not have any previous state >> information >>    available) SHOULD start with... >> " >> ... >> " >>    ... (so long as the restarted head >>    is using the same or a larger value of >> bfd.DesiredMinTxInterval than >>    it did previously). >> " >> If it has no state available, how can it know whether a value >> is larger than >> previously? >> >> GIM>> You are right, the BFD system at the head would not know >> the previous value of bfd.DesiredMinTxInterval. This text is to >> caution operator from decreasing bfd.DesiredMinTxInterval upon >> restart of the BFD system. >> >> >> 4.9.  Bringing Up and Shutting Down Multipoint BFD Service >> There are a number of "SHOULD"s and "SHOULD NOT"s that do not >> state or give >> examples of circumstances in which the "SHOULD" would not be >> appropriate. If >> there are none, "MUST" would be more appropriate. >> >> GIM>> In the first paragraph SHOULD may not be followed if the >> implementation can differentiate between the very first start and >> restarts of BFD system. If it is the first start of BFD system, >> the head MAY directly progress to Up state skipping Down state. >> The last paragraph describes graceful shuttdown. The head MAY >> shut the BFD mp session abruptly by just stopping transmission of >> BFD Control packets. > [BB]: I assume you will say all this in the next rev, not just in > this email. > > GIM2>> Appended the following: > NEW TEXT: > Alternatively, the head MAY stop transmitting BFD Control packets > and not send any more BFD Control packets with the new state (Down or > AdminDown). Tails > will declare the multipoint session down only after the detection time > interval runs out. > > > >> >> 4.10.  Timer Manipulation >> " >>    Because of the one-to-many mapping, a session of type >> MultipointHead >>    SHOULD NOT initiate a Poll Sequence in conjunction with >> timer value >>    changes.  However, to indicate a change in the packets, >>    MultipointHead session MUST send packets with the P bit set. >>    MultipointTail session MUST NOT reply if the packet has M >> and P bits >>    set and bfd.RequiredMinRxInterval set to 0. >> " >> The initial "SHOULD NOT" needs to be written another way. Perhaps >> " >>    ...a session of type MultipointHead >>    does not initiate a Poll Sequence >> " >> The head's normative action is defined by the following >> "MUST", then the tail's >> "MUST NOT reply" is what prevents the poll sequence happening. >> >> GIM>> A Poll Sequence starts with the initiator setting Poll bit. >> Unless the peer sends BFD Control packet with Finl bit set the >> poll sequence would continue indefinetely. The initial SHOULD >> NOT, in my opinion, correctly points that the mechanism of Poll >> Sequence not to be used by MultipointHead when changing >> transmission interval. I think that MUST in the first paragraph >> can be downgraded to MAY because the MultipointHead doesn't need >> to use transition period when changing the transmission interval >> to lower level, i.e., decreasing frequency. May I propose the >> following: >> OLD TEXT: >>    Because of the one-to-many mapping, a session of type >> MultipointHead >>    SHOULD NOT initiate a Poll Sequence in conjunction with timer >> value >>    changes.  However, to indicate a change in the packets, >>    MultipointHead session MUST send packets with the P bit set. >> NEW TEXT: >>    Because of the one-to-many mapping, a session of type >> MultipointHead >>    SHOULD NOT initiate a Poll Sequence in conjunction with timer >> value >>    changes.  However, to indicate a change in the packets, >>    MultipointHead session MAY send packets with the P bit set >> during transition period. > [BB]: If I were an implementer, I would not know what this is > saying I ought to implement. The spec needs to answer this > question: If the head changes the packets what happens differently > if it sets the P bit vs. if it doesn't? > > GIM2>> I think we can expect that the implementer is familiar with RFC > 5880 and, very likely, has implemented it one or more times already. > > >> >> 4.11.  Detection Times >> Delete "in the calculation" (repetition). >> >> GIM>> Done. >> >> >> 4.13.1.  Reception of BFD Control Packets >> Some actions seem to be only relevant to PointToPoint >> sessions, but they are >> stated for all session types. Specifically: "the transmission >> of Echo packets, >> if any, MUST cease." "the Poll Sequence MUST be terminated." >> "MUST cease the >> periodic transmission of BFD Control packets" "MUST send >> periodic BFD Control >> packets" >> >> " >> If bfd.SessionType is PointToPoint, update the Detection Time as >>       described in section 6.8.4 of [RFC5880].  If >> bfd.SessionType is >>       MultipointTail, >> " >> The second sentence above ought to start on a new line as an >> Else if. >> >> GIM>> Hope I got it right: >>       If bfd.SessionType is PointToPoint, update the Detection >> Time as >>       described in section 6.8.4 of [RFC5880]. >> >>       Else >> >>          If bfd.SessionType is MultipointTail, then update the >> Detection >>          Time as the product of the last received values of >> Desired Min >>          TX Interval and Detect Mult, as described in Section 5.11 of >>          this specification. >> >> >> 4.13.2.  Demultiplexing BFD Control Packets >> " >>    This section is part of the replacement for [RFC5880] >> section 6.8.6, >>    separated for clarity. >> " >> Do you mean "This section replaces the sentence: "If the >> Multipoint (M) bit is >> nonzero, the packet MUST be discarded." in [RFC5880] section >> 6.8.6? >> >> The statements under "If the Multipoint (M) bit is set" are >> not formatted like >> the rest of the if-else logic, and I think an Else is missing >> at the start of >> the statement after the nested "If". >> >> GIM>> Agree, the paragraph is not structured properly. How about >> this formating: >>       If the Multipoint (M) bit is set >> >>          If the Your Discriminator field is nonzero, the packet >> MUST be >>          discarded. >> >>          Select a session as based on source address, My >> Discriminator >>          and the identity of the multipoint path which the Multipoint >>          BFD Control packet was received. >> >>          If a session is found, and bfd.SessionType is not >>          MultipointTail, the packet MUST be discarded. >> >>          Else >> >>             If a session is not found, a new session of type >>             MultipointTail MAY be created, or the packet MAY be >>             discarded.  This choice is outside the scope of this >>             specification. >> > [BB]: As long as this represents the logic you want, fine. The > point is that the indentation is the only clue to whether one 'if' > is conditional on a previous 'if', or not. > > HTH > > Bob > > > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------FAC01BFEF94116A1C31C9BED Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Greg,

Your responses are AOK now.

Remaining Security Vulnerability

I think you may have misunderstood my point about vulnerability to source address spoofing without a 3WHS. When you said in response:

Would you suggest additional text to a use case where the new demultiplexing is not sufficent to protect from source address spoofing?

I said:
[BB]: I seem to have become co-opted into redesigning this protocol. I'd prefer to limit my involvement to reviewing :)

If this wasn't clear, I meant, "I believe this protocol has a security problem that needs to be fixed. But it's your job to fix it, not mine."

If you can't fix it, I suggested that you need to at least add a section listing all the limitations when a multipoint scheme has no back channel (the others being no feedback on timing control and no way to set up asymmetric authentication).


Apologies, if the following is already obvious to you, but it is safer to be over-cautious:
The text you originally quoted in response to my point about 3WHS uses the source address as part of the identification of a session. That is the problem (not a solution). If a malicious host M masquerading as the source S spoofs the source address of S in its packets, the tails will not be able to tell that these packets are not from S.

A 3WHS (e.g. as in TCP) is a simple way to address this vulnerability, by the tails using the routing system to send a packet to the location where the source claims to be sending from. I.e. the tail returns a packet to address S with some random information in it (in TCP's case, the initial sequence number). If S genuinely initiated the handshake, it will reflect the random info to the tail in the 3rd way of the handshake. If M is masquerading as S, it will not receive the 2nd way of the handshake. And it won't be able to spoof the 3rd way without the random info.

Without a 3WHS, multipoint BFD does not check that the source address is genuine.


Some (mostly editorial) comments from scanning the diff:

In the intro, the para starting "As an option, the tail may notify the head..." is prerequisite info that needs to come before the para ending "even without the existence of some kind of a return path to the head."

s/in the received by MultipointTail BFD Control packet/
 /in the received MultipointTail BFD Control packet/

s/entire/the entire/ (twice)

Section 6 (Assumptions) has no flow of logic between the new text and the pre-existing text. It would be better to switch the order of the paras.


Otherwise, I think my comments are becoming increasingly less useful, so I'll stop. I don't know enough about the whole ecosystem around this draft to be any more helpful, I think.


Bob

On 05/06/18 03:23, Greg Mirsky wrote:
Hi Bob,
thank you for further clarifications and the new ideas. Please find my follow-up in-line and tagger GIM2>>.
I'll check for nits and grammar and will publish the new version shortly.

Regards,
Greg

On Tue, May 29, 2018 at 3:22 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
Greg,


On 26/05/18 20:49, Greg Mirsky wrote:
Hi Bob,
thank you for the thorough review, detailed questions and helpful comments. Please find my answers in-line and tagged GIM>>.
I've updated the working version of the draft based on your comments and suggestions. Appreciate your feedback whether all questions have been addressed.
Attached please find the diff of -16 and the working version and the copy of the working version of the draft.

Regards,
Greg

On Mon, May 21, 2018 at 5:20 PM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
Reviewer: Bob Briscoe
Review result: Not Ready

Altho this is a TSV-ART review, I did not find many transport-related issues to
focus on, except a need to justify why lack of information for adapting the
transmit interval is not an issue.

Nonetheless, I did find a few other non-trivial technical issues, including 2
security issues, enumerated below (I mis-spent some of my early research career
working on a multicast session control and security, for which we used
beaconing control channels). However, I only have passing prior knowledge of
BFD, so my critique might be off-beam.

==Main Technical Concerns===

1/ Mandatory return path?
RFC5880 is the base RFC that this draft updates. RFC5880 says that
"unidirectional links" are in scope, but only as long as there is a return path.

The introduction of this bfd-multipoint draft seems to contradict that, making
a return path optional: "
   As an option, the tail may notify the head of the lack of multipoint
   connectivity.  Details of tail notification to the head are outside
   the scope of this document.
"
It's allowable for irrelevant details to be outside the scope, but surely it
needs to be clear whether at least the existence of a return path is mandatory.
GIM>> Thank you for highlighting this issue. I think that the second paragraph of Introduction is the appropriate place to note that this mechanism does not require existence of a return path from tails to the head. Would the following be acceptable:
NEW TEXT:
   Use of BFD in
   Demand mode enables a tail monitor availability of a multipoint path
   even without the existence of some kind of a return path to the head.

2/ Mechanism for verifying connectivity, or not?
The introduction seems to contradict itself:
"
   As multipoint transmissions are inherently unidirectional, this
   mechanism purports only to verify this unidirectional connectivity.
"
"
   Term "connectivity" in this document is not being used in the context
   of connectivity verification in transport network but as an
   alternative to "continuity", i.e. existence of a forwarding path
   between the sender and the receiver.
"
How can this mechanism verify connectivity, but not be used in the context of
connectivity verification in the transport network?
GIM>> This draft defines the base specification for multipoint BFD. In order for multipoint BFD to support the transport-like connectivity verification we need to do work similar to described in RFC 6428. 
[BB]: Caveat: I am having to talk in generalizations, cos I don't actually know how you are going to get this protocol to work in a wide range of circumstances, given inherent problems like multipoint feedback implosion {Note 1}.

My point was that, having broken up the drafts in this way, this draft on its own no longer defined a workable protocol. Therefore, it needed some references to other drafts (even if they are placeholders), so that the extent of the pre-requisite collection of work is clear. The refs you give later go a long way to fixing this issue.

If each pre-requisite protocol is intended to only represent one example, the citation can say that and the ref can be informative. But with zero examples for all the prerequisite parts, all the reader sees is a dismembered octopus, not a protocol.



3/ Use case
The introduction seems to be written rather academically. Surely, in cases
where there is never a return path, only the tails will ever be able to verify
connectivity. The head could continue transmitting BFD packets (and data
packets) for years without ever knowing whether it is connected to anything.
Knowledge of connectivity is surely of little use if it excludes the link
sender, which is the node that always controls routing.

If there are scenarios where it is useful for tails but not the head to be able
to verify connectivity, can you please give a concrete example?
GIM>> One example could be a multicast system with 1+1 protection. Without multipoint BFD tails would not be able to detect the failure of the muticast path from the head. Other examples discussed in several drafts:
I am not sure how references to non-WG drafts affect the progress of this document. Appreciate your suggestion.
 [BB]: In my experience, informative refs to non-WG drafts as use-cases would be OK during doc development. However, if a non-WG draft fails to proceed, its citation has to be removed later. So choose those that are most likely to proceed.

Nonetheless, if you cite some specs that turn this into a workable protocol (see previous issue) use-cases might not be necessary.
GIM2>> I've added reference to use of this mechanism in BGP/MPLS MVPN. 




4/ Interval adaptation
Text is needed to describe why it is not an issue for the head to be unaware
whether it needs to adapt its transmit interval. Otherwise, this seems
potentially problematic.
GIM>> Very interesting, thank you. I wouldn't say that the case when a tail cannot process incoming mpBFD control packets at the offered rate is entirely non-issue. Such scenario must be handled by the implementation and may be controlled by local policy, e.g., close the MultipointTail session.
[BB]: Fair enough.

In some scenarios, this issue will not necessarily be so unlikely tho:
* If asymmetric crypto is used to solve the group message authentication problem (see later), the processing burden on any lightweight endpoints might lead to message verification leaving less available processor resource than needed for the host's other tasks.
* Each tail might be joined to a very large number of multipoint sessions.

Where would you suggest to add the text?
 I would suggest a new section listing potential issues when there is no back channel.
GIM2>> I've tried to start the new section but decided to insert the note in the first paragraph of Timer Manipulation section. Hope that is acceptable. 




5/ Inability to authenticate the sender with symmetric keys
In unicast scenarios, symmetric keys can be used for message authentication,
because each end knows there is only one other node with the shared key. But,
in multipoint scenarios, all the tails would share the key, so a shared key
does not authenticate who sent the message - any tail can spoof the head from
the viewpoint of the other tails.

Therefore text is needed to say that:
* multipoint message authentication is limited to cases where all tails are
trusted not to spoof the head, if shared keys are used. * otherwise asymmetric
message authentication would be needed, e.g. TESLA [RFC4082]
GIM>> Thank you for the suggested text. Would the Security Considerations section be appropriate place:
 [BB]: Well, the point limits the applicability of the assumption about security in 5. 'Assumptions', so this would fit well there.
Then "Security Considerations" should point to everywhere in the doc that discusses security, such as this (to save time for security reviewers).

NEW TEXT:
   Use of shared keys to authenticate BFD Control packet in multipoint
   scenarios is limited because tail can spoof the head from the
   viewpoint of the other tails.  Thus, if shared keys are used, all
   tails MUST be trusted not to spoof the head. 
[BB]: Normally a MUST is applied to implementations. It would be rather odd to require users/operators to satisfy a spec requirement, particularly requiring them to trust each other. I think this should be written as an applicability statement not a normative requirement.
GIM2>> I've adopted text suggested by Spencer and moved the paragraph to section Assumption.


Otherwise, asymmetric
   message authentication would be needed, e.g., Timed Efficient Stream
   Loss-Tolerant Authentication (TESLA) as described in [RFC4082].

 [BB]: If you are going to allow for cases where all tails are trusted not to spoof the head, then the assumption written in section 5 is no longer correct.

[FYI, RFC4082 is only a generic description. Many RFCs have been written to authenticate specific protocols along TESLA lines.]


A related nit: Section 5 says all tails are assumed to have a common
authentication key. In cases with symmetric message authentication, surely the
head also needs the same key.
GIM>> Thank you. Please check the updated text:
NEW TEXT:
   If authentication is in use, the head and all tails must be
   configured to have a common authentication key in order for the tails
   to validate received the multipoint BFD Control packets.
[BB]: Yup. Except delete "received the".
Also see above about whether this is now a correct assumption.
GIM2>> I think that s/must/may/ will keep the Assumption valid. 



6/ Source address spoofing
A 3-way handshake makes a protocol robust against simple source address
spoofing. Without a 3WHS, surely the spec. needs to highlight this
vulnerability or discuss ways to address it or why it is not an issue.
GIM>> Because mpBFD control packets cannot be demultiplexed by  tail based on the value of Your Discriminator field as per RFC 5880,
the new procedure outlined in Section 4.7:
   IP and MPLS multipoint tails MUST demultiplex BFD packets based on a
   combination of the source address, My Discriminator and the identity
   of the multipoint tree which the Multipoint BFD Control packet was
   received from.  Together they uniquely identify the head of the
   multipoint path.
and described in details in Section 4.13.2:
      If the Multipoint (M) bit is set

         If the Your Discriminator field is nonzero, the packet MUST be
         discarded.

         Select a session as based on source address, My Discriminator
         and the identity of the multipoint tree which the Multipoint
         BFD Control packet was received.  If a session is found, and
         bfd.SessionType is not MultipointTail, the packet MUST be
         discarded.  If a session is not found, a new session of type
         MultipointTail MAY be created, or the packet MAY be discarded.
         This choice is outside the scope of this specification.

Would you suggest additional text to a use case where the new demultiplexing is not sufficent to protect from source address spoofing?

 [BB]: I seem to have become co-opted into redesigning this protocol. I'd prefer to limit my involvement to reviewing :)



7/ Scope
On eight occasions an issue is raised, but resolution is stated as outside the
scope of this document. It is OK to limit the scope of a spec, for example to
allow for multiple solutions to each issue. But at least one solution must
already exist for each of these eight issues. So, at least one example solution
ought to be cited in each case. If any issues are open, then this should not be
on the standards track.

It would be more useful to state why each issue is out of scope. This would be
helped by stating from the start what the scope of the document is.
GIM>> I've listed all eight occasions with the explanation for each one:
  1. Details of tail notification to the head are outside the scope of this document. - Notifications by tails addressed in draft-ietf-bfd-multipoint-active-tail. Will add as informational reference.
 [BB]: Good.

Nonetheless, given you have confirmed that a reverse path is optional, the doc still needs to address the case where there is no reverse path.
GIM2>> Introduction notes:
 Use of BFD in Demand mode enables a tail monitor availability
 of a multipoint path even without the existence of some kind of a
 return path to the head.


{Note 1} For the active tail draft, you might find the following ideas for scaling multipoint feedback useful:

Statistical feedback:
Nonnenmacher, Jö. & Biersack, E.W., "Scalable Feedback for Large Groups," IEEE/ACM Transactions on Networking 7(3):375--386 (June 1999)

FUHRMANN, T., AND WIDMER, J. "On the scaling of feedback algorithms for very large multicast groups," Computer Communications 24, 5-6 (March 2001), 539 547;
WIDMER, J., AND FUHRMANN, T. Extremum feedback for very large multicast groups. Tech. Rep. TR 12-2001, Prakfische Informatik IV, University of Mannheim, Germany, May 2001.

Also, anycast can be used to select different representative feedback tails, e.g. for a certain time, which might overlap with the periods for which a few other tails are selected using subsequent anycasts.

Logical 'AND' feedback:
Burbridge, T., Soppera, A., Briscoe, R. and Jacquet, A. "Method and device for co-ordinating networked group members" Patent WO2004059479, (Jul 2004; Priority 24 Dec 2002)
[AFAICT this patent is still being maintained, so use of it in a protocol would require an IPR declaration.]


  1. Details of how the head keeps track of tails and how tails alert their connectivity to the head are outside scope of this document. - Same as #1.
 [BB]: And my response is same as #1.
  1. Bootstrapping BFD session to multipoint MPLS LSP in case of penultimate hop popping is outside the scope of this document. - It may use control plane as in MVPN draft. Will add as informational reference.
 [BB]: Good.
  1. Use of other types of encapsulation of the BFD control message over multipoint LSP is outside the scope of this document. - This in reference to ACH encapsulation that is discussed in draft-mirsky-mpls-p2mp-bfd. Should it be added as informational reference? What would be the imacpt of progressing this specification?
 [BB]: See earlier comment about citing individual drafts (I don't have enough BFD knowledge to give a BFD-specific answer).

Also, in my review I should also have said: when creating new encapsulations, pls see the common transport issues related to encapsulation:
https://trac.ietf.org/trac/tsv/wiki/tsvdir-common-issues#TunnelingprotocolsandTransportRelatedIssues


  1. Change in the value of bfd.RequiredMinRxInterval is outside the scope of this document. - Same as #1.
 [BB]: And my response is same as #1.
  1. If a session is not found, a new session of type MultipointTail MAY be created, or the packet MAY be discarded. This choice is outside the scope of this specification. - I propose to add "based on local policy" to the last sentence.
 [BB]: On what basis will local policy decide? It's my job as a reviewer to ensure that this spec does not contain any loose ends (open issues).
GIM2>> It could be based on the maximum number of MultipointTail sessions and number of active MultipointTail sessions on the node. I'd clarify it as:
  This choice MAY be controlled by the local policy, e.g. maximum number of 
  MultipointTail sessions and number of active MultipointTail sessions,
  and is outside the scope of this specification.



  1. The exact method of selection is application-specific and is thus outside the scope of this specification. - This is copied from RFC 5880: "The exact method of selection is application specific and is thus outside the scope of this specification." as the section is to replace Section 6.8.6.
 [BB]: OK.
  1. If a matching session is not found, a new session of type PointToPoint MAY be created, or the packet MAY be discarded. This choice is outside the scope of this specification. - Same as #6.

 [BB]: And my response is same as #6.
[Sry, my embedded comments have broken your numbered list.]


     

There is also one issue that is "for further discussion". Does this mean the
document is not ready yet?
GIM>> I think that the question left for further discussion is non-technical:
   The semantic difference between Down and AdminDown state is for
   further discussion. 
I propose to remove the sentence altogether.
 [BB]: OK.



8/ Incremental deployment

Section 4.4.1.  "New State Variable Values" defines bfd.SessionType =
PointToPoint as well as a couple of Multipoint alternatives. Presumably this
spec does not require all existing PointToPoint systems to support this state
value. Is the implication that only Multipoint systems that happen to be in
PointToPoint mode should use this state?
GIM>> You're aboultely right, existing implementations of BFD don't need to support bfd.SessionType variable. Only implementations that support the base BFD, single-hop or multi-hop, and this specification, mpBFD, should support bfd.SessionType and set it to PointToPoint value when BFD is in single-hop or multi-hop mode. When in mpBFD mode, bfd.SessionType will be set to either MultipointHead or MultipointClient.
 [BB]: Doesn't something need to be written (or referenced) to clarify all this? AFAIR, this spec. never made clear that multipoint is a fork in implementations.
GIM2>> And so is S-BFD. (Note, bfd.SessionType introduced in RFC 7880 S-BFD but missed to define PointToPoint value). 




==Nits==

* Sometimes 'tree' is used to mean a multipoint path in general. I suspect
'path' was intended.
GIM>> I've found six occasions of "tree" and s/tree/path/ 

4.8.  Packet consumption on tails
s/Node/Nodes/
s/packet/packets/
s/demultiplex/demultiplexed/
GIM>> Accepted all three. 

4.9.  Bringing Up and Shutting Down Multipoint BFD Service
"
   a newly
   started head (that does not have any previous state information
   available) SHOULD start with...
"
...
"
   ... (so long as the restarted head
   is using the same or a larger value of bfd.DesiredMinTxInterval than
   it did previously).
"
If it has no state available, how can it know whether a value is larger than
previously?
GIM>> You are right, the BFD system at the head would not know the previous value of bfd.DesiredMinTxInterval. This text is to caution operator from decreasing  bfd.DesiredMinTxInterval upon restart of the BFD system.

4.9.  Bringing Up and Shutting Down Multipoint BFD Service
There are a number of "SHOULD"s and "SHOULD NOT"s that do not state or give
examples of circumstances in which the "SHOULD" would not be appropriate. If
there are none, "MUST" would be more appropriate.
GIM>> In the first paragraph SHOULD may not be followed if the implementation can differentiate between the very first start and restarts of BFD system. If it is the first start of BFD system, the head MAY directly progress to Up state skipping Down state.
The last paragraph describes graceful shuttdown. The head MAY shut the BFD mp session abruptly by just stopping transmission of BFD Control packets.
[BB]: I assume you will say all this in the next rev, not just in this email.
GIM2>> Appended the following:
NEW TEXT:
Alternatively, the head MAY stop transmitting BFD Control packets 
and not send any more BFD Control packets with the new state (Down or AdminDown). Tails
will declare the multipoint session down only after the detection time interval runs out. 



4.10.  Timer Manipulation
"
   Because of the one-to-many mapping, a session of type MultipointHead
   SHOULD NOT initiate a Poll Sequence in conjunction with timer value
   changes.  However, to indicate a change in the packets,
   MultipointHead session MUST send packets with the P bit set.
   MultipointTail session MUST NOT reply if the packet has M and P bits
   set and bfd.RequiredMinRxInterval set to 0.
"
The initial "SHOULD NOT" needs to be written another way. Perhaps
"
   ...a session of type MultipointHead
   does not initiate a Poll Sequence
"
The head's normative action is defined by the following "MUST", then the tail's
"MUST NOT reply" is what prevents the poll sequence happening.
GIM>> A Poll Sequence starts with the initiator setting Poll bit. Unless the peer sends BFD Control packet with Finl bit set the poll sequence would continue indefinetely. The initial SHOULD NOT, in my opinion, correctly points that the mechanism of Poll Sequence not to be used by MultipointHead when changing transmission interval. I think that MUST in the first paragraph can be downgraded to MAY because the MultipointHead doesn't need to use transition period when changing the transmission interval to lower level, i.e., decreasing frequency. May I propose the following:
OLD TEXT:
   Because of the one-to-many mapping, a session of type MultipointHead
   SHOULD NOT initiate a Poll Sequence in conjunction with timer value
   changes.  However, to indicate a change in the packets,
   MultipointHead session MUST send packets with the P bit set.
NEW TEXT:
   Because of the one-to-many mapping, a session of type MultipointHead
   SHOULD NOT initiate a Poll Sequence in conjunction with timer value
   changes.  However, to indicate a change in the packets,
   MultipointHead session MAY send packets with the P bit set during transition period.
 [BB]: If I were an implementer, I would not know what this is saying I ought to implement. The spec needs to answer this question: If the head changes the packets what happens differently if it sets the P bit vs. if it doesn't?
GIM2>> I think we can expect that the implementer is familiar with RFC 5880 and, very likely, has implemented it one or more times already. 


4.11.  Detection Times
Delete "in the calculation" (repetition).
GIM>> Done. 

4.13.1.  Reception of BFD Control Packets
Some actions seem to be only relevant to PointToPoint sessions, but they are
stated for all session types. Specifically: "the transmission of Echo packets,
if any, MUST cease." "the Poll Sequence MUST be terminated." "MUST cease the
periodic transmission of BFD Control packets" "MUST send periodic BFD Control
packets"

"
If bfd.SessionType is PointToPoint, update the Detection Time as
      described in section 6.8.4 of [RFC5880].  If bfd.SessionType is
      MultipointTail,
"
The second sentence above ought to start on a new line as an Else if.
GIM>> Hope I got it right:
      If bfd.SessionType is PointToPoint, update the Detection Time as
      described in section 6.8.4 of [RFC5880].

      Else

         If bfd.SessionType is MultipointTail, then update the Detection
         Time as the product of the last received values of Desired Min
         TX Interval and Detect Mult, as described in Section 5.11 of
         this specification. 

4.13.2.  Demultiplexing BFD Control Packets
"
   This section is part of the replacement for [RFC5880] section 6.8.6,
   separated for clarity.
"
Do you mean "This section replaces the sentence: "If the Multipoint (M) bit is
nonzero, the packet MUST be discarded." in [RFC5880] section 6.8.6?

The statements under "If the Multipoint (M) bit is set" are not formatted like
the rest of the if-else logic, and I think an Else is missing at the start of
the statement after the nested "If".
GIM>> Agree, the paragraph is not structured properly. How about this formating:
      If the Multipoint (M) bit is set

         If the Your Discriminator field is nonzero, the packet MUST be
         discarded.

         Select a session as based on source address, My Discriminator
         and the identity of the multipoint path which the Multipoint
         BFD Control packet was received.

         If a session is found, and bfd.SessionType is not
         MultipointTail, the packet MUST be discarded.

         Else

            If a session is not found, a new session of type
            MultipointTail MAY be created, or the packet MAY be
            discarded.  This choice is outside the scope of this
            specification. 

[BB]: As long as this represents the logic you want, fine. The point is that the indentation is the only clue to whether one 'if' is conditional on a previous 'if', or not.

HTH

Bob




-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------FAC01BFEF94116A1C31C9BED-- From nobody Mon Jun 11 11:16:24 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD1B130EA3; Mon, 11 Jun 2018 11:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 gBdVR9EUvE_g; Mon, 11 Jun 2018 11:14:34 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 82EC3130E92; Mon, 11 Jun 2018 11:14:33 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id t134-v6so31983351lff.6; Mon, 11 Jun 2018 11:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IlZq897p6ckzecLnKkIAqgJrOXQc211rXcsrKvtf9ZA=; b=Ptx0SXJ/ssVKIa/EBmldNZgAx7dgjiBFLsqYyuvYFE+u8pQHGyH9CRoOp49RaT+dtj 3IQFECMknSquTzRiJjuU0QHya8x5RwNaePbgCsdO++VETML2o1iAW0Coj0CrSFQHMU7D gJr58gaZjozHxB0dYKiR756GlhAS+DpWSXvrIsuP4kF2pu20UEfkAh69ubxB3HDBZFef vqY/lgEJFpYRIHYuWyIjq3Db1kg9qp401WmhHUOHdEDfs2Dq3xaeya7/Slce87/lgXki 3I2hYvpsRl3OO6pBetEnjsYgqaQxz9GBcS12Njh+Lq4x/UiTKEvmzEN1q0Vh6F+CB5Ro s4sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IlZq897p6ckzecLnKkIAqgJrOXQc211rXcsrKvtf9ZA=; b=pur6a7c3ZiACpRfAaeyppHuWNCm4XNC0d980nf0GpD7s74ljEgbrHwL7wf6inyXGxZ Crnmvl5pX7d0hujyxF3v9QdJgiyycM9/yZoXq6gagX3LvIO25Tfpsxb09gvVOOZy7O+a I4q8aY8RxWVPnVZYV9t/MofqLHl47ST3GgX4aqVqHKcf3XIlQb6Y7974JoCS5/gAykbc prTcSHT9d72eDJNRCEkOlNcSt61XYmTAMuIPyOBEAPTEVU6zF2ig7q8Bvc+ozJJ593u1 UaOBM/RL8uYAWRJwmntI4CgeP3VX6p0TtBneUIuOE8SC4pcP+DlW94D6hQZzBg3tFSPh TbsA== X-Gm-Message-State: APt69E09exZz/piZc8bkoEht6z4ohN0TpxFxTCHvWGNCWbDmOkExyBwG wTRAJZfybNYCUZw8ooOPohm+vkHCtQmyDmkIwHY= X-Google-Smtp-Source: ADUXVKJwzbhwtn4jAlwwF5aaxzqHzEMzYqTpUBy/hHt1r7cSPE9HVx/qcA7sCmQP5/p/nm/EEnlBtCK//hLrBsHNfHk= X-Received: by 2002:a2e:911a:: with SMTP id m26-v6mr130785ljg.73.1528740871273; Mon, 11 Jun 2018 11:14:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Mon, 11 Jun 2018 11:14:30 -0700 (PDT) In-Reply-To: <4a8bd1a3-3cfc-9c9c-c2cd-d0f8467da2c8@bobbriscoe.net> References: <152694840016.8083.12174100605609215107@ietfa.amsl.com> <1afa9af2-9fce-1588-ca09-cd39f1122688@bobbriscoe.net> <4a8bd1a3-3cfc-9c9c-c2cd-d0f8467da2c8@bobbriscoe.net> From: Greg Mirsky Date: Mon, 11 Jun 2018 11:14:30 -0700 Message-ID: Subject: Re: Tsvart last call review of draft-ietf-bfd-multipoint-16 To: Bob Briscoe Cc: tsv-art@ietf.org, draft-ietf-bfd-multipoint.all@ietf.org, rtg-bfd@ietf.org, IETF list Content-Type: multipart/alternative; boundary="0000000000009601f3056e61b80c" Archived-At: X-Mailman-Approved-At: Mon, 11 Jun 2018 11:16:23 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 18:14:41 -0000 --0000000000009601f3056e61b80c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bob, thank you for the most thoughtful and helpful comments. It was not my intention to pull you into re-designing of the specification. I've accepted all the editorial updates, applied them to the new working version. I have to admit that I'm bit confused that you see lack of 3WHS in mpBFD as the significantly increased risk of the spoofing attack on leaves. The BFD Control packet is expected to be received by a leave from one of the following: - multicast path; - directly connected; - p2mp/mp2mp MPLS LSP. For the first scenario, as I understand, a host must first use multicast control protocol to join the multicast path. For the second - it is reasonable to assume, as in VRRP and PIM-SM drafts I've referenced earlier, that BFD control packet be required to have IP TTL =3D=3D 1 and mcast IP address of link scope. And the third, I think, is similar to #1 above. If these considerations are technically accurate, I'll work on the text for Assumptions section. Regards, Greg On Thu, Jun 7, 2018 at 5:02 PM, Bob Briscoe wrote: > Greg, > > Your responses are AOK now. > > *Remaining Security Vulnerability* > > I think you may have misunderstood my point about vulnerability to source > address spoofing without a 3WHS. When you said in response: > > > Would you suggest additional text to a use case where the new > demultiplexing is not sufficent to protect from source address spoofing? > > > I said: > > [BB]: I seem to have become co-opted into redesigning this protocol. I'd > prefer to limit my involvement to reviewing :) > > > If this wasn't clear, I meant, "I believe this protocol has a security > problem that needs to be fixed. But it's your job to fix it, not mine." > > If you can't fix it, I suggested that you need to at least add a section > listing all the limitations when a multipoint scheme has no back channel > (the others being no feedback on timing control and no way to set up > asymmetric authentication). > > > Apologies, if the following is already obvious to you, but it is safer to > be over-cautious: > The text you originally quoted in response to my point about 3WHS uses th= e > source address as part of the identification of a session. That is the > problem (not a solution). If a malicious host M masquerading as the sourc= e > S spoofs the source address of S in its packets, the tails will not be ab= le > to tell that these packets are not from S. > > A 3WHS (e.g. as in TCP) is a simple way to address this vulnerability, by > the tails using the routing system to send a packet to the location where > the source claims to be sending from. I.e. the tail returns a packet to > address S with some random information in it (in TCP's case, the initial > sequence number). If S genuinely initiated the handshake, it will reflect > the random info to the tail in the 3rd way of the handshake. If M is > masquerading as S, it will not receive the 2nd way of the handshake. And = it > won't be able to spoof the 3rd way without the random info. > > Without a 3WHS, multipoint BFD does not check that the source address is > genuine. > > > *Some (mostly editorial) comments from scanning the diff:* > > In the intro, the para starting "As an option, the tail may notify the > head..." is prerequisite info that needs to come before the para ending > "even without the existence of some kind of a return path to the head." > > s/in the received by MultipointTail BFD Control packet/ > /in the received MultipointTail BFD Control packet/ > > s/entire/the entire/ (twice) > > Section 6 (Assumptions) has no flow of logic between the new text and the > pre-existing text. It would be better to switch the order of the paras. > > > Otherwise, I think my comments are becoming increasingly less useful, so > I'll stop. I don't know enough about the whole ecosystem around this draf= t > to be any more helpful, I think. > > > Bob > > > On 05/06/18 03:23, Greg Mirsky wrote: > > Hi Bob, > thank you for further clarifications and the new ideas. Please find my > follow-up in-line and tagger GIM2>>. > I'll check for nits and grammar and will publish the new version shortly. > > Regards, > Greg > > On Tue, May 29, 2018 at 3:22 AM, Bob Briscoe wrote: > >> Greg, >> >> >> On 26/05/18 20:49, Greg Mirsky wrote: >> >> Hi Bob, >> thank you for the thorough review, detailed questions and helpful >> comments. Please find my answers in-line and tagged GIM>>. >> I've updated the working version of the draft based on your comments and >> suggestions. Appreciate your feedback whether all questions have been >> addressed. >> Attached please find the diff of -16 and the working version and the cop= y >> of the working version of the draft. >> >> Regards, >> Greg >> >> On Mon, May 21, 2018 at 5:20 PM, Bob Briscoe wrote= : >> >>> Reviewer: Bob Briscoe >>> Review result: Not Ready >>> >>> Altho this is a TSV-ART review, I did not find many transport-related >>> issues to >>> focus on, except a need to justify why lack of information for adapting >>> the >>> transmit interval is not an issue. >>> >>> Nonetheless, I did find a few other non-trivial technical issues, >>> including 2 >>> security issues, enumerated below (I mis-spent some of my early researc= h >>> career >>> working on a multicast session control and security, for which we used >>> beaconing control channels). However, I only have passing prior >>> knowledge of >>> BFD, so my critique might be off-beam. >>> >>> =3D=3DMain Technical Concerns=3D=3D=3D >>> >>> 1/ Mandatory return path? >>> RFC5880 is the base RFC that this draft updates. RFC5880 says that >>> "unidirectional links" are in scope, but only as long as there is a >>> return path. >>> >>> The introduction of this bfd-multipoint draft seems to contradict that, >>> making >>> a return path optional: " >>> As an option, the tail may notify the head of the lack of multipoint >>> connectivity. Details of tail notification to the head are outside >>> the scope of this document. >>> " >>> It's allowable for irrelevant details to be outside the scope, but >>> surely it >>> needs to be clear whether at least the existence of a return path is >>> mandatory. >>> >> GIM>> Thank you for highlighting this issue. I think that the second >> paragraph of Introduction is the appropriate place to note that this >> mechanism does not require existence of a return path from tails to the >> head. Would the following be acceptable: >> NEW TEXT: >> Use of BFD in >> Demand mode enables a tail monitor availability of a multipoint path >> even without the existence of some kind of a return path to the head. >> >>> >>> 2/ Mechanism for verifying connectivity, or not? >>> The introduction seems to contradict itself: >>> " >>> As multipoint transmissions are inherently unidirectional, this >>> mechanism purports only to verify this unidirectional connectivity. >>> " >>> " >>> Term "connectivity" in this document is not being used in the contex= t >>> of connectivity verification in transport network but as an >>> alternative to "continuity", i.e. existence of a forwarding path >>> between the sender and the receiver. >>> " >>> How can this mechanism verify connectivity, but not be used in the >>> context of >>> connectivity verification in the transport network? >>> >> GIM>> This draft defines the base specification for multipoint BFD. In >> order for multipoint BFD to support the transport-like connectivity >> verification we need to do work similar to described in RFC 6428. >> >> [BB]: Caveat: I am having to talk in generalizations, cos I don't >> actually know how you are going to get this protocol to work in a wide >> range of circumstances, given inherent problems like multipoint feedback >> implosion {Note 1}. >> >> My point was that, having broken up the drafts in this way, this draft o= n >> its own no longer defined a workable protocol. Therefore, it needed some >> references to other drafts (even if they are placeholders), so that the >> extent of the pre-requisite collection of work is clear. The refs you gi= ve >> later go a long way to fixing this issue. >> >> If each pre-requisite protocol is intended to only represent one example= , >> the citation can say that and the ref can be informative. But with zero >> examples for all the prerequisite parts, all the reader sees is a >> dismembered octopus, not a protocol. >> >> >> >>> 3/ Use case >>> The introduction seems to be written rather academically. Surely, in >>> cases >>> where there is never a return path, only the tails will ever be able to >>> verify >>> connectivity. The head could continue transmitting BFD packets (and dat= a >>> packets) for years without ever knowing whether it is connected to >>> anything. >>> Knowledge of connectivity is surely of little use if it excludes the li= nk >>> sender, which is the node that always controls routing. >>> >>> If there are scenarios where it is useful for tails but not the head to >>> be able >>> to verify connectivity, can you please give a concrete example? >>> >> GIM>> One example could be a multicast system with 1+1 protection. >> Without multipoint BFD tails would not be able to detect the failure of = the >> muticast path from the head. Other examples discussed in several drafts: >> >> - BESS WG draft MVPN fast upstream failover >> >> - Individual draft BFD for Multipoint Networks and VRRP Use Case >> >> - Individual draft BFD for Multipoint Networks and PIM-SM Use Case >> >> >> I am not sure how references to non-WG drafts affect the progress of thi= s >> document. Appreciate your suggestion. >> >> [BB]: In my experience, informative refs to non-WG drafts as use-cases >> would be OK during doc development. However, if a non-WG draft fails to >> proceed, its citation has to be removed later. So choose those that are >> most likely to proceed. >> >> Nonetheless, if you cite some specs that turn this into a workable >> protocol (see previous issue) use-cases might not be necessary. >> > GIM2>> I've added reference to use of this mechanism in BGP/MPLS MVPN. > >> >> >> >> >>> 4/ Interval adaptation >>> Text is needed to describe why it is not an issue for the head to be >>> unaware >>> whether it needs to adapt its transmit interval. Otherwise, this seems >>> potentially problematic. >>> >> GIM>> Very interesting, thank you. I wouldn't say that the case when a >> tail cannot process incoming mpBFD control packets at the offered rate i= s >> entirely non-issue. Such scenario must be handled by the implementation = and >> may be controlled by local policy, e.g., close the MultipointTail sessio= n. >> >> [BB]: Fair enough. >> >> In some scenarios, this issue will not necessarily be so unlikely tho: >> * If asymmetric crypto is used to solve the group message authentication >> problem (see later), the processing burden on any lightweight endpoints >> might lead to message verification leaving less available processor >> resource than needed for the host's other tasks. >> * Each tail might be joined to a very large number of multipoint session= s. >> >> Where would you suggest to add the text? >> >> I would suggest a new section listing potential issues when there is no >> back channel. >> > GIM2>> I've tried to start the new section but decided to insert the note > in the first paragraph of Timer Manipulation section. Hope that is > acceptable. > >> >> >> >> >>> 5/ Inability to authenticate the sender with symmetric keys >>> In unicast scenarios, symmetric keys can be used for message >>> authentication, >>> because each end knows there is only one other node with the shared key= . >>> But, >>> in multipoint scenarios, all the tails would share the key, so a shared >>> key >>> does not authenticate who sent the message - any tail can spoof the hea= d >>> from >>> the viewpoint of the other tails. >>> >>> Therefore text is needed to say that: >>> * multipoint message authentication is limited to cases where all tails >>> are >>> trusted not to spoof the head, if shared keys are used. * otherwise >>> asymmetric >>> message authentication would be needed, e.g. TESLA [RFC4082] >>> >> GIM>> Thank you for the suggested text. Would the Security Consideration= s >> section be appropriate place: >> >> [BB]: Well, the point limits the applicability of the assumption about >> security in 5. 'Assumptions', so this would fit well there. >> Then "Security Considerations" should point to everywhere in the doc tha= t >> discusses security, such as this (to save time for security reviewers). >> >> NEW TEXT: >> Use of shared keys to authenticate BFD Control packet in multipoint >> scenarios is limited because tail can spoof the head from the >> viewpoint of the other tails. Thus, if shared keys are used, all >> tails MUST be trusted not to spoof the head. >> >> [BB]: Normally a MUST is applied to implementations. It would be rather >> odd to require users/operators to satisfy a spec requirement, particular= ly >> requiring them to trust each other. I think this should be written as an >> applicability statement not a normative requirement. >> > GIM2>> I've adopted text suggested by Spencer and moved the paragraph to > section Assumption. > >> >> >> Otherwise, asymmetric >> message authentication would be needed, e.g., Timed Efficient Stream >> Loss-Tolerant Authentication (TESLA) as described in [RFC4082]. >> >> >> [BB]: If you are going to allow for cases where all tails are trusted no= t >> to spoof the head, then the assumption written in section 5 is no longer >> correct. >> >> [FYI, RFC4082 is only a generic description. Many RFCs have been written >> to authenticate specific protocols along TESLA lines.] >> >> >>> A related nit: Section 5 says all tails are assumed to have a common >>> authentication key. In cases with symmetric message authentication, >>> surely the >>> head also needs the same key. >>> >> GIM>> Thank you. Please check the updated text: >> NEW TEXT: >> If authentication is in use, the head and all tails must be >> configured to have a common authentication key in order for the tails >> to validate received the multipoint BFD Control packets. >> >> [BB]: Yup. Except delete "received the". >> Also see above about whether this is now a correct assumption. >> > GIM2>> I think that s/must/may/ will keep the Assumption valid. > >> >> >> >>> 6/ Source address spoofing >>> A 3-way handshake makes a protocol robust against simple source address >>> spoofing. Without a 3WHS, surely the spec. needs to highlight this >>> vulnerability or discuss ways to address it or why it is not an issue. >>> >> GIM>> Because mpBFD control packets cannot be demultiplexed by tail >> based on the value of Your Discriminator field as per RFC 5880, >> the new procedure outlined in Section 4.7: >> IP and MPLS multipoint tails MUST demultiplex BFD packets based on a >> combination of the source address, My Discriminator and the identity >> of the multipoint tree which the Multipoint BFD Control packet was >> received from. Together they uniquely identify the head of the >> multipoint path. >> and described in details in Section 4.13.2: >> If the Multipoint (M) bit is set >> >> If the Your Discriminator field is nonzero, the packet MUST be >> discarded. >> >> Select a session as based on source address, My Discriminator >> and the identity of the multipoint tree which the Multipoint >> BFD Control packet was received. If a session is found, and >> bfd.SessionType is not MultipointTail, the packet MUST be >> discarded. If a session is not found, a new session of type >> MultipointTail MAY be created, or the packet MAY be discarded. >> This choice is outside the scope of this specification. >> >> Would you suggest additional text to a use case where the new >> demultiplexing is not sufficent to protect from source address spoofing? >> >> >> [BB]: I seem to have become co-opted into redesigning this protocol. I'd >> prefer to limit my involvement to reviewing :) >> >> >> >>> 7/ Scope >>> On eight occasions an issue is raised, but resolution is stated as >>> outside the >>> scope of this document. It is OK to limit the scope of a spec, for >>> example to >>> allow for multiple solutions to each issue. But at least one solution >>> must >>> already exist for each of these eight issues. So, at least one example >>> solution >>> ought to be cited in each case. If any issues are open, then this shoul= d >>> not be >>> on the standards track. >>> >>> It would be more useful to state why each issue is out of scope. This >>> would be >>> helped by stating from the start what the scope of the document is. >>> >> GIM>> I've listed all eight occasions with the explanation for each one: >> >> 1. Details of tail notification to the head are outside the scope of >> this document. - Notifications by tails addressed in >> draft-ietf-bfd-multipoint-active-tail >> . >> Will add as informational reference. >> >> [BB]: Good. >> >> Nonetheless, given you have confirmed that a reverse path is optional, >> the doc still needs to address the case where there is no reverse path. >> > GIM2>> Introduction notes: > Use of BFD in Demand mode enables a tail monitor availability > of a multipoint path even without the existence of some kind of a > return path to the head. > > >> {Note 1} For the active tail draft, you might find the following ideas >> for scaling multipoint feedback useful: >> >> *Statistical feedback:* >> Nonnenmacher, J=C3=B6. & Biersack, E.W., "Scalable Feedback for Large Gr= oups >> ," IEEE/ACM Transactions on >> Networking 7(3):375--386 (June 1999) >> >> FUHRMANN, T., AND WIDMER, J. "On the scaling of feedback algorithms for >> very large multicast groups ," >> Computer Communications 24, 5-6 (March 2001), 539 547; >> WIDMER, J., AND FUHRMANN, T. Extremum feedback for very large multicast >> groups. Tech. Rep. TR 12-2001, Prakfische Informatik IV, University of >> Mannheim, Germany, May 2001. >> >> Also, anycast can be used to select different representative feedback >> tails, e.g. for a certain time, which might overlap with the periods for >> which a few other tails are selected using subsequent anycasts. >> >> *Logical 'AND' feedback:* >> Burbridge, T., Soppera, A., Briscoe, R. and Jacquet, A. "Method and >> device for co-ordinating networked group members >> " >> Patent WO2004059479, (Jul 2004; Priority 24 Dec 2002) >> [AFAICT this patent is still being maintained, so use of it in a protoco= l >> would require an IPR declaration.] >> >> >> >> 1. Details of how the head keeps track of tails and how tails alert >> their connectivity to the head are outside scope of this document. - = Same >> as #1. >> >> [BB]: And my response is same as #1. >> >> >> 1. Bootstrapping BFD session to multipoint MPLS LSP in case of >> penultimate hop popping is outside the scope of this document. - It m= ay use >> control plane as in MVPN draft. Will add as informational reference. >> >> [BB]: Good. >> >> >> 1. Use of other types of encapsulation of the BFD control message >> over multipoint LSP is outside the scope of this document. - This in >> reference to ACH encapsulation that is discussed in >> draft-mirsky-mpls-p2mp-bfd >> . Should >> it be added as informational reference? What would be the imacpt of >> progressing this specification? >> >> [BB]: See earlier comment about citing individual drafts (I don't have >> enough BFD knowledge to give a BFD-specific answer). >> >> Also, in my review I should also have said: when creating new >> encapsulations, pls see the common transport issues related to >> encapsulation: >> https://trac.ietf.org/trac/tsv/wiki/tsvdir-common-issues#Tun >> nelingprotocolsandTransportRelatedIssues >> >> >> >> 1. Change in the value of bfd.RequiredMinRxInterval is outside the >> scope of this document. - Same as #1. >> >> [BB]: And my response is same as #1. >> >> >> 1. If a session is not found, a new session of type MultipointTail >> MAY be created, or the packet MAY be discarded. This choice is outsid= e the >> scope of this specification. - I propose to add "based on local polic= y" to >> the last sentence. >> >> [BB]: On what basis will local policy decide? It's my job as a reviewer >> to ensure that this spec does not contain any loose ends (open issues). >> > GIM2>> It could be based on the maximum number of MultipointTail sessions > and number of active MultipointTail sessions on the node. I'd clarify it = as: > This choice MAY be controlled by the local policy, e.g. maximum number > of > MultipointTail sessions and number of active MultipointTail sessions, > and is outside the scope of this specification. > > >> >> >> 1. The exact method of selection is application-specific and is thus >> outside the scope of this specification. - This is copied from RFC 58= 80: >> "The exact method of selection is application specific and is thus ou= tside >> the scope of this specification." as the section is to replace Sectio= n >> 6.8.6. >> >> [BB]: OK. >> >> >> 1. If a matching session is not found, a new session of type >> PointToPoint MAY be created, or the packet MAY be discarded. This cho= ice is >> outside the scope of this specification. - Same as #6. >> >> >> [BB]: And my response is same as #6. >> [Sry, my embedded comments have broken your numbered list.] >> >> >> >> >> >> >>> There is also one issue that is "for further discussion". Does this mea= n >>> the >>> document is not ready yet? >>> >> GIM>> I think that the question left for further discussion is >> non-technical: >> The semantic difference between Down and AdminDown state is for >> further discussion. >> I propose to remove the sentence altogether. >> >> [BB]: OK. >> >> >> >>> 8/ Incremental deployment >>> >>> Section 4.4.1. "New State Variable Values" defines bfd.SessionType =3D >>> PointToPoint as well as a couple of Multipoint alternatives. Presumably >>> this >>> spec does not require all existing PointToPoint systems to support this >>> state >>> value. Is the implication that only Multipoint systems that happen to b= e >>> in >>> PointToPoint mode should use this state? >>> >> GIM>> You're aboultely right, existing implementations of BFD don't need >> to support bfd.SessionType variable. Only implementations that support t= he >> base BFD, single-hop or multi-hop, and this specification, mpBFD, should >> support bfd.SessionType and set it to PointToPoint value when BFD is in >> single-hop or multi-hop mode. When in mpBFD mode, bfd.SessionType will b= e >> set to either MultipointHead or MultipointClient. >> >> [BB]: Doesn't something need to be written (or referenced) to clarify al= l >> this? AFAIR, this spec. never made clear that multipoint is a fork in >> implementations. >> > GIM2>> And so is S-BFD. (Note, bfd.SessionType introduced in RFC 7880 > S-BFD but missed to define PointToPoint value). > >> >> >> >> >>> =3D=3DNits=3D=3D >>> >>> * Sometimes 'tree' is used to mean a multipoint path in general. I >>> suspect >>> 'path' was intended. >>> >> GIM>> I've found six occasions of "tree" and s/tree/path/ >> >>> >>> 4.8. Packet consumption on tails >>> s/Node/Nodes/ >>> s/packet/packets/ >>> s/demultiplex/demultiplexed/ >>> >> GIM>> Accepted all three. >> >>> >>> 4.9. Bringing Up and Shutting Down Multipoint BFD Service >>> " >>> a newly >>> started head (that does not have any previous state information >>> available) SHOULD start with... >>> " >>> ... >>> " >>> ... (so long as the restarted head >>> is using the same or a larger value of bfd.DesiredMinTxInterval than >>> it did previously). >>> " >>> If it has no state available, how can it know whether a value is larger >>> than >>> previously? >>> >> GIM>> You are right, the BFD system at the head would not know the >> previous value of bfd.DesiredMinTxInterval. This text is to caution >> operator from decreasing bfd.DesiredMinTxInterval upon restart of the >> BFD system. >> >>> >>> 4.9. Bringing Up and Shutting Down Multipoint BFD Service >>> There are a number of "SHOULD"s and "SHOULD NOT"s that do not state or >>> give >>> examples of circumstances in which the "SHOULD" would not be >>> appropriate. If >>> there are none, "MUST" would be more appropriate. >>> >> GIM>> In the first paragraph SHOULD may not be followed if the >> implementation can differentiate between the very first start and restar= ts >> of BFD system. If it is the first start of BFD system, the head MAY >> directly progress to Up state skipping Down state. >> The last paragraph describes graceful shuttdown. The head MAY shut the >> BFD mp session abruptly by just stopping transmission of BFD Control >> packets. >> >> [BB]: I assume you will say all this in the next rev, not just in this >> email. >> > GIM2>> Appended the following: > NEW TEXT: > Alternatively, the head MAY stop transmitting BFD Control packets > and not send any more BFD Control packets with the new state (Down or > AdminDown). Tails > will declare the multipoint session down only after the detection time > interval runs out. > >> >> >> >>> 4.10. Timer Manipulation >>> " >>> Because of the one-to-many mapping, a session of type MultipointHead >>> SHOULD NOT initiate a Poll Sequence in conjunction with timer value >>> changes. However, to indicate a change in the packets, >>> MultipointHead session MUST send packets with the P bit set. >>> MultipointTail session MUST NOT reply if the packet has M and P bits >>> set and bfd.RequiredMinRxInterval set to 0. >>> " >>> The initial "SHOULD NOT" needs to be written another way. Perhaps >>> " >>> ...a session of type MultipointHead >>> does not initiate a Poll Sequence >>> " >>> The head's normative action is defined by the following "MUST", then th= e >>> tail's >>> "MUST NOT reply" is what prevents the poll sequence happening. >>> >> GIM>> A Poll Sequence starts with the initiator setting Poll bit. Unless >> the peer sends BFD Control packet with Finl bit set the poll sequence wo= uld >> continue indefinetely. The initial SHOULD NOT, in my opinion, correctly >> points that the mechanism of Poll Sequence not to be used by MultipointH= ead >> when changing transmission interval. I think that MUST in the first >> paragraph can be downgraded to MAY because the MultipointHead doesn't ne= ed >> to use transition period when changing the transmission interval to lowe= r >> level, i.e., decreasing frequency. May I propose the following: >> OLD TEXT: >> Because of the one-to-many mapping, a session of type MultipointHead >> SHOULD NOT initiate a Poll Sequence in conjunction with timer value >> changes. However, to indicate a change in the packets, >> MultipointHead session MUST send packets with the P bit set. >> NEW TEXT: >> Because of the one-to-many mapping, a session of type MultipointHead >> SHOULD NOT initiate a Poll Sequence in conjunction with timer value >> changes. However, to indicate a change in the packets, >> MultipointHead session MAY send packets with the P bit set during >> transition period. >> >> [BB]: If I were an implementer, I would not know what this is saying I >> ought to implement. The spec needs to answer this question: If the head >> changes the packets what happens differently if it sets the P bit vs. if= it >> doesn't? >> > GIM2>> I think we can expect that the implementer is familiar with RFC > 5880 and, very likely, has implemented it one or more times already. > >> >> >>> 4.11. Detection Times >>> Delete "in the calculation" (repetition). >>> >> GIM>> Done. >> >>> >>> 4.13.1. Reception of BFD Control Packets >>> Some actions seem to be only relevant to PointToPoint sessions, but the= y >>> are >>> stated for all session types. Specifically: "the transmission of Echo >>> packets, >>> if any, MUST cease." "the Poll Sequence MUST be terminated." "MUST ceas= e >>> the >>> periodic transmission of BFD Control packets" "MUST send periodic BFD >>> Control >>> packets" >>> >>> " >>> If bfd.SessionType is PointToPoint, update the Detection Time as >>> described in section 6.8.4 of [RFC5880]. If bfd.SessionType is >>> MultipointTail, >>> " >>> The second sentence above ought to start on a new line as an Else if. >>> >> GIM>> Hope I got it right: >> If bfd.SessionType is PointToPoint, update the Detection Time as >> described in section 6.8.4 of [RFC5880]. >> >> Else >> >> If bfd.SessionType is MultipointTail, then update the Detection >> Time as the product of the last received values of Desired Min >> TX Interval and Detect Mult, as described in Section 5.11 of >> this specification. >> >>> >>> 4.13.2. Demultiplexing BFD Control Packets >>> " >>> This section is part of the replacement for [RFC5880] section 6.8.6, >>> separated for clarity. >>> " >>> Do you mean "This section replaces the sentence: "If the Multipoint (M) >>> bit is >>> nonzero, the packet MUST be discarded." in [RFC5880] section 6.8.6? >>> >>> The statements under "If the Multipoint (M) bit is set" are not >>> formatted like >>> the rest of the if-else logic, and I think an Else is missing at the >>> start of >>> the statement after the nested "If". >>> >> GIM>> Agree, the paragraph is not structured properly. How about this >> formating: >> If the Multipoint (M) bit is set >> >> If the Your Discriminator field is nonzero, the packet MUST be >> discarded. >> >> Select a session as based on source address, My Discriminator >> and the identity of the multipoint path which the Multipoint >> BFD Control packet was received. >> >> If a session is found, and bfd.SessionType is not >> MultipointTail, the packet MUST be discarded. >> >> Else >> >> If a session is not found, a new session of type >> MultipointTail MAY be created, or the packet MAY be >> discarded. This choice is outside the scope of this >> specification. >> >> [BB]: As long as this represents the logic you want, fine. The point is >> that the indentation is the only clue to whether one 'if' is conditional= on >> a previous 'if', or not. >> >> HTH >> >> Bob >> >> >> >> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >> >> > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > --0000000000009601f3056e61b80c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bob,
thank you for the most thoughtful and helpful = comments. It was not my intention to pull you into re-designing of the spec= ification. I've accepted all the editorial updates, applied them to the= new working version.

I have to admit that I'm= bit confused that you see lack of 3WHS in mpBFD=C2=A0as the significantly = increased risk of the spoofing attack on leaves. The BFD Control packet=C2= =A0is expected to be received by a leave from one of the following:
  • multicast path;
  • directly connected;
  • p2mp/mp2mp M= PLS LSP.
For the first scenario, as I understand, a host must= first use multicast control protocol to join the multicast path.
For the second - it is reasonable to assume, as in VRRP and PIM-SM d= rafts I've referenced earlier, that BFD control packet be required to h= ave IP TTL =3D=3D 1 and mcast=C2=A0IP address of link=C2=A0scope.
And the third, I think, is similar to #1 above.

I= f these considerations are technically accurate, I'll work on the text = for Assumptions section.

Regards,
Greg


On Thu, Jun 7, 2018 at 5:02 PM, Bob Briscoe <<= a href=3D"mailto:ietf@bobbriscoe.net" target=3D"_blank">ietf@bobbriscoe.net= > wrote:
=20 =20 =20
Greg,

Your responses are AOK now.

Remaining Security Vulnerability

I think you may have misunderstood my point about vulnerability to source address spoofing without a 3WHS. When you said in response:

Would you suggest additional text to a use case where the new demultiplexing is not sufficent to protect from source address spoofing?

I said:
[BB]: I seem to have become co-opted into redesigning this protocol. I'd prefer to limit my involvement to reviewing :)

 If this wasn't clear, I meant, "I believe this protocol has a security problem that needs to be fixed. But it's your job to fix it, not mine."

If you can't fix it, I suggested that you need to at least add a section listing all the limitations when a multipoint scheme has no back channel (the others being no feedback on timing control and no way to set up asymmetric authentication).


Apologies, if the following is already obvious to you, but it is safer to be over-cautious:
The text you originally quoted in response to my point about 3WHS uses the source address as part of the identification of a session. That is the problem (not a solution). If a malicious host M masquerading as the source S spoofs the source address of S in its packets, the tails will not be able to tell that these packets are not from S.

A 3WHS (e.g. as in TCP) is a simple way to address this vulnerability, by the tails using the routing system to send a packet to the location where the source claims to be sending from. I.e. the tail returns a packet to address S with some random information in it (in TCP's case, the initial sequence number). If = S genuinely initiated the handshake, it will reflect the random info to the tail in the 3rd way of the handshake. If M is masquerading as S, it will not receive the 2nd way of the handshake. And it won't b= e able to spoof the 3rd way without the random info.

Without a 3WHS, multipoint BFD does not check that the source address is genuine.


Some (mostly editorial) comments from scanning the diff:

In the intro, the para starting "As an option, the tail may notify the head..." is prerequisite info that needs to come before the pa= ra ending "even without the existence of some kind of a return path t= o the head."

s/in the received by MultipointTail BFD Control packet/
=C2=A0/in the received MultipointTail BFD Control packet/

s/entire/the entire/ (twice)

Section 6 (Assumptions) has no flow of logic between the new text and the pre-existing text. It would be better to switch the order of the paras.


Otherwise, I think my comments are becoming increasingly less useful, so I'll stop. I don't know enough about the whole ecosy= stem around this draft to be any more helpful, I think.


Bob


On 05/06/18 03:23,= Greg Mirsky wrote:
Hi Bob,
thank you for further clarifications and the new ideas. Please find my follow-up in-line and tagger GIM2>>.
I'll check for nits and grammar and will publish the new version shortly.

Regards,
Greg

On Tue, May 29, 2018 at 3:22 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
Greg,


On 26/05/18 20:49, Greg Mirsky wrote:
Hi Bob,
thank you for the thorough review, detailed questions and helpful comments. Please find my answers in-line and tagged GIM>>.
I've updated the working version of the draft based on your comments and suggestions. Appreciate your feedback whether all questions have been addressed.
Attached please find the diff of -16 and the working version and the copy of the working version of the draft.

Regards,
Greg

On Mon, May 21, 2018 at 5:20 PM, Bob Briscoe <<= a href=3D"mailto:ietf@bobbriscoe.net" target=3D"_blank">ietf@bobbriscoe.net= > wrote:
Reviewer: Bob Briscoe
Review result: Not Ready

Altho this is a TSV-ART review, I did not find many transport-related issues to
focus on, except a need to justify why lack of information for adapting the
transmit interval is not an issue.

Nonetheless, I did find a few other non-trivial technical issues, including 2
security issues, enumerated below (I mis-spent some of my early research career working on a multicast session control and security, for which we used
beaconing control channels). However, I only have passing prior knowledge of
BFD, so my critique might be off-beam.

=3D=3DMain Technical Concerns=3D=3D=3D

1/ Mandatory return path?
RFC5880 is the base RFC that this draft updates. RFC5880 says that
"unidirectional links" are in scope= , but only as long as there is a return path.

The introduction of this bfd-multipoint draft seems to contradict that, making
a return path optional: "
=C2=A0 =C2=A0As an option, the tail may notif= y the head of the lack of multipoint
=C2=A0 =C2=A0connectivity.=C2=A0 Details of t= ail notification to the head are outside
=C2=A0 =C2=A0the scope of this document.
"
It's allowable for irrelevant details to be outside the scope, but surely it
needs to be clear whether at least the existence of a return path is mandatory.
GIM>> Thank you for highlighting this issue. I think that the second paragraph of Introduction is the appropriate place to note that this mechanism does not require existence of a return path from tails to the head. Would the following be acceptable:
NEW TEXT:
=C2=A0 =C2=A0Use of BFD in
=C2=A0 =C2=A0Demand mode enables a tail = monitor availability of a multipoint path
=C2=A0 =C2=A0even without the existence = of some kind of a return path to the head.

2/ Mechanism for verifying connectivity, or not?
The introduction seems to contradict itself:
"
=C2=A0 =C2=A0As multipoint transmissions are inherently unidirectional, this
=C2=A0 =C2=A0mechanism purports only to verif= y this unidirectional connectivity.
"
"
=C2=A0 =C2=A0Term "connectivity" in= this document is not being used in the context
=C2=A0 =C2=A0of connectivity verification in transport network but as an
=C2=A0 =C2=A0alternative to "continuity&= quot;, i.e. existence of a forwarding path
=C2=A0 =C2=A0between the sender and the recei= ver.
"
How can this mechanism verify connectivity, but not be used in the context of
connectivity verification in the transport network?
GIM>> This draft defines the base specification for multipoint BFD. In order for multipoint BFD to support the transport-like connectivity verification we need to do work similar to described in RFC 6428.=C2=A0
[BB]: Caveat: I am having to talk in generalizations, cos I don't actually know how you are going to get this protocol to work in a wide range of circumstances, given inherent problems like multipoint feedback implosion {Note 1}.

My point was that, having broken up the drafts in this way, this draft on its own no longer defined a workable protocol. Therefore, it needed some references to other drafts (even if they are placeholders), so that the extent of the pre-requisite collection of work is clear. The refs you give later go a long way to fixing this issue.

If each pre-requisite protocol is intended to only represent one example, the citation can say that and the ref can be informative. But with zero examples for all the prerequisite parts, all the reader sees is a dismembered octopus, not a protocol.



3/ Use case
The introduction seems to be written rather academically. Surely, in cases
where there is never a return path, only the tails will ever be able to verify
connectivity. The head could continue transmitting BFD packets (and data
packets) for years without ever knowing whether it is connected to anything.
Knowledge of connectivity is surely of little use if it excludes the link
sender, which is the node that always controls routing.

If there are scenarios where it is useful for tails but not the head to be able
to verify connectivity, can you please give a concrete example?
GIM>> One example could be a multicast system with 1+1 protection. Without multipoint BFD tails would not be able to detect the failure of the muticast path from the head. Other examples discussed in several drafts:
I am not sure how references to non-WG drafts affect the progress of this document. Appreciate your suggestion.
 [BB]: In my experience, informative refs to non-WG drafts as use-cases would be OK during doc development. However, if a non-WG draft fails to proceed, its citation has to be removed later. So choose those that are most likely to proceed.

Nonetheless, if you cite some specs that turn this into a workable protocol (see previous issue) use-cases might not be necessary.
GIM2>> I've added reference to use of this mechanism in BGP/MPLS MVPN.=C2=A0




4/ Interval adaptation
Text is needed to describe why it is not an issue for the head to be unaware
whether it needs to adapt its transmit interval. Otherwise, this seems
potentially problematic.
GIM>> Very interesting, thank you. I wouldn't say that the case when a tail cannot process incoming mpBFD control packets at the offered rate is entirely non-issue. Such scenario must be handled by the implementation and may be controlled by local policy, e.g., close the MultipointTail session.
[BB]: Fair enough.

In some scenarios, this issue will not necessarily be so unlikely tho:
* If asymmetric crypto is used to solve the group message authentication problem (see later), the processing burden on any lightweight endpoints might lead to message verification leaving less available processor resource than needed for the host's other tasks.
* Each tail might be joined to a very large number of multipoint sessions.

Where would you suggest to add the text?
I would suggest a new section listing potential issues when there is no back channel.
GIM2>> I've tried to start the new section but decided to insert the note in the first paragraph of Timer Manipulation section. Hope that is acceptable.=C2=A0




5/ Inability to authenticate the sender with symmetric keys
In unicast scenarios, symmetric keys can be used for message authentication,
because each end knows there is only one other node with the shared key. But,
in multipoint scenarios, all the tails would share the key, so a shared key
does not authenticate who sent the message - any tail can spoof the head from
the viewpoint of the other tails.

Therefore text is needed to say that:
* multipoint message authentication is limited to cases where all tails are
trusted not to spoof the head, if shared keys are used. * otherwise asymmetric
message authentication would be needed, e.g. TESLA [RFC4082]
GIM>> Thank you for the suggested text. Would the Security Considerations section be appropriate place:
 [BB]: Well, the point limits the applicability of the assumption about security in 5. 'Assumptions'= ;, so this would fit well there.
Then "Security Considerations" should point to everywhere in the doc that discusses security, such as this (to save time for security reviewers).

NEW TEXT:
=C2=A0 =C2=A0Use of shared keys to authent= icate BFD Control packet in multipoint
=C2=A0 =C2=A0scenarios is limited because = tail can spoof the head from the
=C2=A0 =C2=A0viewpoint of the other tails.= =C2=A0 Thus, if shared keys are used, all
=C2=A0 =C2=A0tails MUST be trusted not to = spoof the head.=C2=A0
[BB]: Normally a MUST is applied to implementations. It would be rather odd to require users/operators to satisfy a spec requirement, particularly requiring them to trust each other. I think this should be written as an applicability statement not a normative requirement.
GIM2>> I've adopted text suggested by Spencer an= d moved the paragraph to section Assumption.


Otherwise, asymmetric
=C2=A0 =C2=A0message authentication would = be needed, e.g., Timed Efficient Stream
=C2=A0 =C2=A0Loss-Tolerant Authentication = (TESLA) as described in [RFC4082].

 [BB]: If you are going to allow for cases where all tails are trusted not to spoof the head, then the assumption written in section 5 is no longer correct.

[FYI, RFC4082 is only a generic description. Many RFCs have been written to authenticate specific protocols along TESLA lines.]


A related nit: Section 5 says all tails are assumed to have a common
authentication key. In cases with symmetric message authentication, surely the
head also needs the same key.
GIM>> Thank you. Please check the updated text:
NEW TEXT:
=C2=A0 =C2=A0If authentication is in use, th= e head and all tails must be
=C2=A0 =C2=A0configured to have a common authentication key in order for the tails
=C2=A0 =C2=A0to validate received the multip= oint BFD Control packets.
[BB]: Yup. Except delete "received the".<= br> Also see above about whether this is now a correct assumption.
GIM2>> I think that s/must/may/ will keep the Assumption valid.=C2=A0



6/ Source address spoofing
A 3-way handshake makes a protocol robust against simple source address
spoofing. Without a 3WHS, surely the spec. needs to highlight this
vulnerability or discuss ways to address it or why it is not an issue.
GIM>> Because mpBFD control packets cannot be demultiplexed by=C2=A0 tail based on the value of Your Discriminator field as per RFC 5880,
the new procedure outlined in Section 4.7:
=C2=A0 =C2=A0IP and MPLS multipoint tails = MUST demultiplex BFD packets based on a
=C2=A0 =C2=A0combination of the source add= ress, My Discriminator and the identity
=C2=A0 =C2=A0of the multipoint tree which = the Multipoint BFD Control packet was
=C2=A0 =C2=A0received from.=C2=A0 Together= they uniquely identify the head of the
=C2=A0 =C2=A0multipoint path.
and described in details in Section 4.13.2:
=C2=A0 =C2=A0 =C2=A0 If the Multipoint (M)= bit is set

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If the Y= our Discriminator field is nonzero, the packet MUST be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discarde= d.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Select a= session as based on source address, My Discriminator
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and the = identity of the multipoint tree which the Multipoint
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD Cont= rol packet was received.=C2=A0 If a session is found, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bfd.Sess= ionType is not MultipointTail, the packet MUST be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discarde= d.=C2=A0 If a session is not found, a new session of type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Multipoi= ntTail MAY be created, or the packet MAY be discarded.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This cho= ice is outside the scope of this specification.

Would you suggest additional text to a use case where the new demultiplexing is not sufficent to protect from source address spoofing?

 [BB]: I seem to have become co-opted into redesigning this protocol. I'd prefer to limit my involvement to reviewing :)



7/ Scope
On eight occasions an issue is raised, but resolution is stated as outside the
scope of this document. It is OK to limit the scope of a spec, for example to
allow for multiple solutions to each issue. But at least one solution must
already exist for each of these eight issues. So, at least one example solution
ought to be cited in each case. If any issues are open, then this should not be
on the standards track.

It would be more useful to state why each issue is out of scope. This would be
helped by stating from the start what the scope of the document is.
GIM>> I've listed all eight occasions with the explanation for each one:
  1. Details of tail notification to the head are outside the scope of this document. - Notifications by tails addressed in=C2=A0draft-ietf-bfd-multipoint-active-tail. Will add as informational reference.
 [BB]: Good.

Nonetheless, given you have confirmed that a reverse path is optional, the doc still needs to address the case where there is no reverse path.
GIM2>> Introduction notes:
=C2=A0Use of BFD in Demand mode enables a tail monitor availability
=C2=A0of a multipoint path even without the existence of some kind of a
=C2=A0return path to the head.


{Note 1} For the active tail draft, you might find the following ideas for scaling multipoint feedback useful:

Statistical feedback:
Nonnenmacher, J=C3=B6. & Biersack, E.W., "Scalable Feedback for Large Groups," IEEE/ACM Transaction= s on Networking 7(3):375--386 (June 1999)

FUHRMANN, T., AND WIDMER, J. "On the scaling of feedback algorithms for very large multicast groups," Computer Communications 24, 5-6 (March 2001), 539 547;
WIDMER, J., AND FUHRMANN, T. Extremum feedback for very large multicast groups. Tech. Rep. TR 12-2001, Prakfische Informatik IV, University of Mannheim, Germany, May 2001.

Also, anycast can be used to select different representative feedback tails, e.g. for a certain time, which might overlap with the periods for which a few other tails are selected using subsequent anycasts.

Logical 'AND' feedback:
Burbridge, T., Soppera, A., Briscoe, R. and Jacquet, A. "Method and device for co-ordinating networked group members"= ; Patent WO2004059479, (Jul 2004; Priority 24 Dec 2002)
[AFAICT this patent is still being maintained, so use of it in a protocol would require an IPR declaration.]


  1. Details of how the head keeps track of tails and how tails alert their connectivity to the head are outside scope of this document. - Same as #1.
 [BB]: And my response is same as #1.
  1. Bootstrapping BFD session to multipoint MPLS LSP in case of penultimate hop popping is outside the scope of this document. - It may use control plane as in MVPN draft. Will add as informational reference.
 [BB]: Good.
  1. Use of other types of encapsulation of the BFD control message over multipoint LSP is outside the scope of this document. - This in reference to ACH encapsulation that is discussed in=C2=A0draft-mirsky-mpls-p2mp-bfd. Should it be added as informational reference? What would be the imacpt of progressing this specification?
 [BB]: See earlier comment about citing individual drafts (I don't have enough BFD knowledge to give a BFD-specific answer).

Also, in my review I should also have said: when creating new encapsulations, pls see the common transport issues related to encapsulation:
https://trac.ietf.org/trac/tsv/wiki/tsvdir-common-issues#Tunnel= ingprotocolsandTransportRelatedIssues


  1. Change in the value of bfd.RequiredMinRxInterval is outside the scope of this document. - Same as #1.
 [BB]: And my response is same as #1.
  1. If a session is not found, a new session of type MultipointTail MAY be created, or the packet MAY be discarded. This choice is outside the scope of this specification. - I propose to add "bas= ed on local policy" to the last sentence.=
[BB]: On what basis will local policy decide? It's my job as a reviewer to ensure that this spec does not contain any loose ends (open issues).
GIM2>> It could be based on the maximum number of MultipointTail sessions and number of active MultipointTail sessions on the node. I'd clarify it as:
=C2=A0 This choice MAY be controlled by the local policy= , e.g. maximum number of=C2=A0
=C2=A0 MultipointTail sessions and number of active MultipointTail sessions,
=C2=A0 and is outside the scope of this specification.



  1. The exact method of selection is application-specific and is thus outside the scope of this specification. - This is copied from RFC 5880: "The exact method of selection is application specific and is thus outside the scope of this specification." as the section is to replace Section 6.8.6.
 [BB]: OK.
  1. If a matching session is not found, a new session of type PointToPoint MAY be created, or the packet MAY be discarded. This choice is outside the scope of this specification. - Same as #6.

 [BB]: And my response is same as #6.
[Sry, my embedded comments have broken your numbered list.]


    =C2=A0

There is also one issue that is "for furth= er discussion". Does this mean the
document is not ready yet?
GIM>> I think that the question left for further discussion is non-technical:
=C2=A0 =C2=A0The semantic difference between= Down and AdminDown state is for
=C2=A0 =C2=A0further discussion.=C2=A0
I propose to remove the sentence altogether.
 [BB]: OK.



8/ Incremental deployment

Section 4.4.1.=C2=A0 "New State Variable V= alues" defines bfd.SessionType =3D
PointToPoint as well as a couple of Multipoint alternatives. Presumably this
spec does not require all existing PointToPoint systems to support this state
value. Is the implication that only Multipoint systems that happen to be in
PointToPoint mode should use this state?
GIM>> You're aboultely right, existing implementations of BFD don't need to support bfd.SessionType variable. Only implementations that support the base BFD, single-hop or multi-hop, and this specification, mpBFD, should support bfd.SessionType and set it to PointToPoint value when BFD is in single-hop or multi-hop mode. When in mpBFD mode, bfd.SessionType will be set to either MultipointHead or MultipointClient.
 [BB]: Doesn't something need to be written (or referenced) to clarify all this? AFAIR, this spec. never made clear that multipoint is a fork in implementations.
GIM2>> And so is S-BFD. (Note, bfd.SessionType introduced in RFC 7880 S-BFD but missed to define PointToPoint value).=C2=A0




=3D=3DNits=3D=3D

* Sometimes 'tree' is used to mean a multipoint path in general. I suspect
'path' was intended.
GIM>> I've found six occasions o= f "tree" and s/tree/path/=C2=A0

4.8.=C2=A0 Packet consumption on tails
s/Node/Nodes/
s/packet/packets/
s/demultiplex/demultiplexed/
GIM>> Accepted all three.=C2=A0

4.9.=C2=A0 Bringing Up and Shutting Down Multipoint BFD Service
"
=C2=A0 =C2=A0a newly
=C2=A0 =C2=A0started head (that does not have= any previous state information
=C2=A0 =C2=A0available) SHOULD start with...<= br> "
...
"
=C2=A0 =C2=A0... (so long as the restarted he= ad
=C2=A0 =C2=A0is using the same or a larger va= lue of bfd.DesiredMinTxInterval than
=C2=A0 =C2=A0it did previously).
"
If it has no state available, how can it know whether a value is larger than
previously?
GIM>> You are right, the BFD system at the head would not know the previous value of=C2=A0bfd.DesiredMinTxInterval. This text is to caution operator from decreasing=C2=A0 = bfd.DesiredMinTxInterval upon restart of the BFD system.

4.9.=C2=A0 Bringing Up and Shutting Down Multipoint BFD Service
There are a number of "SHOULD"s and "SHOULD NOT"s that do not state or = give
examples of circumstances in which the "SHOULD" would not be appropriate. = If
there are none, "MUST" would be mor= e appropriate.
GIM>> In the first paragraph SHOULD may not be followed if the implementation can differentiate between the very first start and restarts of BFD system. If it is the first start of BFD system, the head MAY directly progress to Up state skipping Down state.
The last paragraph describes graceful shuttdown. The head MAY shut the BFD mp session abruptly by just stopping transmission of BFD Control packets.
[BB]: I assume you will say all this in the next rev, not just in this email.
GIM2>> Appended the following:
NEW TEXT:
Alternativel= y, the head MAY stop transmitting BFD Control packets=C2=A0
and not send= any more BFD Control packets with the new state (Down or AdminDown). Tails
will declare= the multipoint session down only after the detection time interval runs out.=C2=A0



4.10.=C2=A0 Timer Manipulation
"
=C2=A0 =C2=A0Because of the one-to-many mapping= , a session of type MultipointHead
=C2=A0 =C2=A0SHOULD NOT initiate a Poll Sequenc= e in conjunction with timer value
=C2=A0 =C2=A0changes.=C2=A0 However, to indicat= e a change in the packets,
=C2=A0 =C2=A0MultipointHead session MUST send p= ackets with the P bit set.
=C2=A0 =C2=A0MultipointTail session MUST NOT re= ply if the packet has M and P bits
=C2=A0 =C2=A0set and bfd.RequiredMinRxInterval = set to 0.
"
The initial "SHOULD NOT" needs to be = written another way. Perhaps
"
=C2=A0 =C2=A0...a session of type MultipointHea= d
=C2=A0 =C2=A0does not initiate a Poll Sequence<= br> "
The head's normative action is defined by the following "MUST", then the tail&#= 39;s
"MUST NOT reply" is what prevents the= poll sequence happening.
GIM>> A Poll Sequence starts with the initiator setting Poll bit. Unless the peer sends BFD Control packet with Finl bit set the poll sequence would continue indefinetely. The initial SHOULD NOT, in my opinion, correctly points that the mechanism of Poll Sequence not to be used by MultipointHead when changing transmission interval. I think that MUST in the first paragraph can be downgraded to MAY because the MultipointHead doesn't need to use transition period when changing the transmission interval to lower level, i.e., decreasing frequency. May I propose the following:
OLD TEXT:
=C2=A0 =C2=A0Because of the one-to-many ma= pping, a session of type MultipointHead
=C2=A0 =C2=A0SHOULD NOT initiate a Poll Se= quence in conjunction with timer value
=C2=A0 =C2=A0changes.=C2=A0 However, to in= dicate a change in the packets,
=C2=A0 =C2=A0MultipointHead session MUST s= end packets with the P bit set.
NEW TEXT:
=C2=A0 =C2=A0Because of the one-to-many ma= pping, a session of type MultipointHead
=C2=A0 =C2=A0SHOULD NOT initiate a Poll Se= quence in conjunction with timer value
=C2=A0 =C2=A0changes.=C2=A0 However, to in= dicate a change in the packets,
=C2=A0 =C2=A0MultipointHead session MAY se= nd packets with the P bit set during transition period.
 [BB]: If I were an implementer, I would not know what this is saying I ought to implement. The spec needs to answer this question: If the head changes the packets what happens differently if it sets the P bit vs. if it doesn't?
GIM2>> I think we can expect that the implementer is familiar with RFC 5880 and, very likely, has implemented it one or more times already.=C2=A0


4.11.=C2=A0 Detection Times
Delete "in the calculation" (repeti= tion).
GIM>> Done.=C2=A0

4.13.1.=C2=A0 Reception of BFD Control Packet= s
Some actions seem to be only relevant to PointToPoint sessions, but they are
stated for all session types. Specifically: "the transmission of Echo packets,
if any, MUST cease." "the Poll Sequ= ence MUST be terminated." "MUST cease th= e
periodic transmission of BFD Control packets" "MUST send periodic BFD Co= ntrol
packets"

"
If bfd.SessionType is PointToPoint, update the Detection Time as
=C2=A0 =C2=A0 =C2=A0 described in section 6.8= .4 of [RFC5880].=C2=A0 If bfd.SessionType is
=C2=A0 =C2=A0 =C2=A0 MultipointTail,
"
The second sentence above ought to start on a new line as an Else if.
GIM>> Hope I got it right:
=C2=A0 =C2=A0 =C2=A0 If bfd.SessionType is PointToPoint, update the Detection Time as
=C2=A0 =C2=A0 =C2=A0 described in section = 6.8.4 of [RFC5880].

=C2=A0 =C2=A0 =C2=A0 Else

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If bfd.S= essionType is MultipointTail, then update the Detection
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Time as = the product of the last received values of Desired Min
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TX Inter= val and Detect Mult, as described in Section 5.11 of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this spe= cification.=C2=A0

4.13.2.=C2=A0 Demultiplexing BFD Control Packets
"
=C2=A0 =C2=A0This section is part of the repl= acement for [RFC5880] section 6.8.6,
=C2=A0 =C2=A0separated for clarity.
"
Do you mean "This section replaces the sentence: "If the Multipoint (M) bit is<= br> nonzero, the packet MUST be discarded." = in [RFC5880] section 6.8.6?

The statements under "If the Multipoint (M) bit is set" are not formatted like the rest of the if-else logic, and I think an Else is missing at the start of
the statement after the nested "If"= .
GIM>> Agree, the paragraph is not structured properly. How about this formating:
=C2=A0 =C2=A0 =C2=A0 If the Multipoint (M)= bit is set

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If the Y= our Discriminator field is nonzero, the packet MUST be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discarde= d.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Select a= session as based on source address, My Discriminator
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and the = identity of the multipoint path which the Multipoint
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD Cont= rol packet was received.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If a ses= sion is found, and bfd.SessionType is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Multipoi= ntTail, the packet MUST be discarded.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Else

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = If a session is not found, a new session of type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = MultipointTail MAY be created, or the packet MAY be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = discarded.=C2=A0 This choice is outside the scope of this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = specification.=C2=A0

[BB]: As long as this represents the logic you want, fine. The point is that the indentation is the only clue to whether one 'if' is conditional on a previous &#= 39;if', or not.

HTH

Bob




--=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


--=20
________________________________________________________________
Bob Briscoe                               h=
ttp://bobbriscoe.net/

--0000000000009601f3056e61b80c-- From nobody Mon Jun 11 14:48:40 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12831130EA4; Mon, 11 Jun 2018 14:47:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 EbQf8TZLGKqU; Mon, 11 Jun 2018 14:47:36 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 51778130DBE; Mon, 11 Jun 2018 14:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=rkCko6ga5zcnBey5BSg0k3EYsgwXTUU5mOvTiI8ULmI=; b=6cBIB7bkttlZpCfUIOoahpYr7 BDsW/LgHHm8MYQR/v9rTOZgfTjIkLJhVNt679iLg8eySu6U/xP/hTXmsUtX4WlWZPcUZd9xsD4O63 xjNrLYOo0gsBNBOn9cmA3TrYuHAbP9rrUhAg8dlQTj9SzLlm57cOpTOmM65ttZ4fEO4W1Ii1tusgN iDHFOuWVgDX9t0u80bCsE5wwa0VuDOc88vI+dpVqZV4U4V6zpfIQWBKBb/UccW8qQraHstieVlVNq 7lzd7TM1D/strBOgxhtR0ogXQQyBW70jcY5WXFOAu7uchmVvP++UpCQ9HCNft1w2BGu3YMOs9xpcz 6QHbOLsvw==; Received: from 244.187.112.87.dyn.plus.net ([87.112.187.244]:59398 helo=[192.168.0.4]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1fSUev-0000dh-5r; Mon, 11 Jun 2018 22:47:31 +0100 Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-bfd-multipoint-16 To: Greg Mirsky Cc: draft-ietf-bfd-multipoint.all@ietf.org, tsv-art@ietf.org, rtg-bfd@ietf.org, IETF list References: <152694840016.8083.12174100605609215107@ietfa.amsl.com> <1afa9af2-9fce-1588-ca09-cd39f1122688@bobbriscoe.net> <4a8bd1a3-3cfc-9c9c-c2cd-d0f8467da2c8@bobbriscoe.net> From: Bob Briscoe Message-ID: <4d67197f-7728-d226-66b0-7d188a995148@bobbriscoe.net> Date: Mon, 11 Jun 2018 22:47:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------50CD63D6F60077829ED42DCB" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: X-Mailman-Approved-At: Mon, 11 Jun 2018 14:48:36 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 21:47:43 -0000 This is a multi-part message in MIME format. --------------50CD63D6F60077829ED42DCB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Greg, I may be wrong, in which case fine. But I'll take each case in turn (there may not be security problems with all, but a problem with just one would still be of concern): Multicast: If there is an SSM tree from host A to multicast address G, I am not familiar enough with SSM to know what happens when host B sends a packet to G with source address A (i.e. spoofing A). I assume the IGMP messages build the tree back from each member to A, so usually there will be no route from B, even if it is spoofing A as the source. However, I would have thought that a host connected to the same router as A could spoof A and get onto the SSM tree. Or does SSM always check for this type of spoofing? Directly connected. As with multicast, even tho not every machine on the Internet could spoof the source address, surely if the link were a shared link (which is implied in this use-case) any machine on the shared link could spoof the genuine source. MPLS I think the MPLS case is safe, cos at each hop the label switched path is specific to each prior hop. As I said, I may be wrong. But, if either of the first two cases have a vulnerability in certain cases, it ought to be described in the draft, even if the vulnerability is confined to a specific set of circumstances. Bob On 11/06/18 19:14, Greg Mirsky wrote: > Hi Bob, > thank you for the most thoughtful and helpful comments. It was not my > intention to pull you into re-designing of the specification. I've > accepted all the editorial updates, applied them to the new working > version. > > I have to admit that I'm bit confused that you see lack of 3WHS in > mpBFD as the significantly increased risk of the spoofing attack on > leaves. The BFD Control packet is expected to be received by a leave > from one of the following: > > * multicast path; > * directly connected; > * p2mp/mp2mp MPLS LSP. > > For the first scenario, as I understand, a host must first use > multicast control protocol to join the multicast path. > For the second - it is reasonable to assume, as in VRRP and PIM-SM > drafts I've referenced earlier, that BFD control packet be required to > have IP TTL == 1 and mcast IP address of link scope. > And the third, I think, is similar to #1 above. > > If these considerations are technically accurate, I'll work on the > text for Assumptions section. > > Regards, > Greg > > > On Thu, Jun 7, 2018 at 5:02 PM, Bob Briscoe > wrote: > > Greg, > > Your responses are AOK now. > > *Remaining Security Vulnerability** > * > I think you may have misunderstood my point about vulnerability to > source address spoofing without a 3WHS. When you said in response: >> >>> Would you suggest additional text to a use case where the new >>> demultiplexing is not sufficent to protect from source address >>> spoofing? > > I said: >> [BB]: I seem to have become co-opted into redesigning this >> protocol. I'd prefer to limit my involvement to reviewing :) > > If this wasn't clear, I meant, "I believe this protocol has a > security problem that needs to be fixed. But it's your job to fix > it, not mine." > > If you can't fix it, I suggested that you need to at least add a > section listing all the limitations when a multipoint scheme has > no back channel (the others being no feedback on timing control > and no way to set up asymmetric authentication). > > > Apologies, if the following is already obvious to you, but it is > safer to be over-cautious: > The text you originally quoted in response to my point about 3WHS > uses the source address as part of the identification of a > session. That is the problem (not a solution). If a malicious host > M masquerading as the source S spoofs the source address of S in > its packets, the tails will not be able to tell that these packets > are not from S. > > A 3WHS (e.g. as in TCP) is a simple way to address this > vulnerability, by the tails using the routing system to send a > packet to the location where the source claims to be sending from. > I.e. the tail returns a packet to address S with some random > information in it (in TCP's case, the initial sequence number). If > S genuinely initiated the handshake, it will reflect the random > info to the tail in the 3rd way of the handshake. If M is > masquerading as S, it will not receive the 2nd way of the > handshake. And it won't be able to spoof the 3rd way without the > random info. > > Without a 3WHS, multipoint BFD does not check that the source > address is genuine. > > > *Some (mostly editorial) comments from scanning the diff:** > * > In the intro, the para starting "As an option, the tail may notify > the head..." is prerequisite info that needs to come before the > para ending "even without the existence of some kind of a return > path to the head." > > s/in the received by MultipointTail BFD Control packet/ >  /in the received MultipointTail BFD Control packet/ > > s/entire/the entire/ (twice) > > Section 6 (Assumptions) has no flow of logic between the new text > and the pre-existing text. It would be better to switch the order > of the paras. > > > Otherwise, I think my comments are becoming increasingly less > useful, so I'll stop. I don't know enough about the whole > ecosystem around this draft to be any more helpful, I think. > > > Bob > > > On 05/06/18 03:23, Greg Mirsky wrote: >> Hi Bob, >> thank you for further clarifications and the new ideas. Please >> find my follow-up in-line and tagger GIM2>>. >> I'll check for nits and grammar and will publish the new version >> shortly. >> >> Regards, >> Greg >> >> On Tue, May 29, 2018 at 3:22 AM, Bob Briscoe > > wrote: >> >> Greg, >> >> >> On 26/05/18 20:49, Greg Mirsky wrote: >>> Hi Bob, >>> thank you for the thorough review, detailed questions and >>> helpful comments. Please find my answers in-line and tagged >>> GIM>>. >>> I've updated the working version of the draft based on your >>> comments and suggestions. Appreciate your feedback whether >>> all questions have been addressed. >>> Attached please find the diff of -16 and the working version >>> and the copy of the working version of the draft. >>> >>> Regards, >>> Greg >>> >>> On Mon, May 21, 2018 at 5:20 PM, Bob Briscoe >>> > wrote: >>> >>> Reviewer: Bob Briscoe >>> Review result: Not Ready >>> >>> Altho this is a TSV-ART review, I did not find many >>> transport-related issues to >>> focus on, except a need to justify why lack of >>> information for adapting the >>> transmit interval is not an issue. >>> >>> Nonetheless, I did find a few other non-trivial >>> technical issues, including 2 >>> security issues, enumerated below (I mis-spent some of >>> my early research career >>> working on a multicast session control and security, for >>> which we used >>> beaconing control channels). However, I only have >>> passing prior knowledge of >>> BFD, so my critique might be off-beam. >>> >>> ==Main Technical Concerns=== >>> >>> 1/ Mandatory return path? >>> RFC5880 is the base RFC that this draft updates. RFC5880 >>> says that >>> "unidirectional links" are in scope, but only as long as >>> there is a return path. >>> >>> The introduction of this bfd-multipoint draft seems to >>> contradict that, making >>> a return path optional: " >>>    As an option, the tail may notify the head of the >>> lack of multipoint >>>    connectivity.  Details of tail notification to the >>> head are outside >>>    the scope of this document. >>> " >>> It's allowable for irrelevant details to be outside the >>> scope, but surely it >>> needs to be clear whether at least the existence of a >>> return path is mandatory. >>> >>> GIM>> Thank you for highlighting this issue. I think that >>> the second paragraph of Introduction is the appropriate >>> place to note that this mechanism does not require existence >>> of a return path from tails to the head. Would the following >>> be acceptable: >>> NEW TEXT: >>>    Use of BFD in >>>    Demand mode enables a tail monitor availability of a >>> multipoint path >>>    even without the existence of some kind of a return path >>> to the head. >>> >>> >>> 2/ Mechanism for verifying connectivity, or not? >>> The introduction seems to contradict itself: >>> " >>>    As multipoint transmissions are inherently >>> unidirectional, this >>>    mechanism purports only to verify this unidirectional >>> connectivity. >>> " >>> " >>>    Term "connectivity" in this document is not being >>> used in the context >>>    of connectivity verification in transport network but >>> as an >>>    alternative to "continuity", i.e. existence of a >>> forwarding path >>>    between the sender and the receiver. >>> " >>> How can this mechanism verify connectivity, but not be >>> used in the context of >>> connectivity verification in the transport network? >>> >>> GIM>> This draft defines the base specification for >>> multipoint BFD. In order for multipoint BFD to support the >>> transport-like connectivity verification we need to do work >>> similar to described in RFC 6428. >> [BB]: Caveat: I am having to talk in generalizations, cos I >> don't actually know how you are going to get this protocol to >> work in a wide range of circumstances, given inherent >> problems like multipoint feedback implosion {Note 1}. >> >> My point was that, having broken up the drafts in this way, >> this draft on its own no longer defined a workable protocol. >> Therefore, it needed some references to other drafts (even if >> they are placeholders), so that the extent of the >> pre-requisite collection of work is clear. The refs you give >> later go a long way to fixing this issue. >> >> If each pre-requisite protocol is intended to only represent >> one example, the citation can say that and the ref can be >> informative. But with zero examples for all the prerequisite >> parts, all the reader sees is a dismembered octopus, not a >> protocol. >> >> >>> >>> 3/ Use case >>> The introduction seems to be written rather >>> academically. Surely, in cases >>> where there is never a return path, only the tails will >>> ever be able to verify >>> connectivity. The head could continue transmitting BFD >>> packets (and data >>> packets) for years without ever knowing whether it is >>> connected to anything. >>> Knowledge of connectivity is surely of little use if it >>> excludes the link >>> sender, which is the node that always controls routing. >>> >>> If there are scenarios where it is useful for tails but >>> not the head to be able >>> to verify connectivity, can you please give a concrete >>> example? >>> >>> GIM>> One example could be a multicast system with 1+1 >>> protection. Without multipoint BFD tails would not be able >>> to detect the failure of the muticast path from the head. >>> Other examples discussed in several drafts: >>> >>> * BESS WG draft MVPN fast upstream failover >>> >>> * Individual draft BFD for Multipoint Networks and VRRP >>> Use Case >>> >>> * Individual draft BFD for Multipoint Networks and PIM-SM >>> Use Case >>> >>> >>> I am not sure how references to non-WG drafts affect the >>> progress of this document. Appreciate your suggestion. >> [BB]: In my experience, informative refs to non-WG drafts as >> use-cases would be OK during doc development. However, if a >> non-WG draft fails to proceed, its citation has to be removed >> later. So choose those that are most likely to proceed. >> >> Nonetheless, if you cite some specs that turn this into a >> workable protocol (see previous issue) use-cases might not be >> necessary. >> >> GIM2>> I've added reference to use of this mechanism in BGP/MPLS >> MVPN. >> >> >> >>> >>> >>> 4/ Interval adaptation >>> Text is needed to describe why it is not an issue for >>> the head to be unaware >>> whether it needs to adapt its transmit interval. >>> Otherwise, this seems >>> potentially problematic. >>> >>> GIM>> Very interesting, thank you. I wouldn't say that the >>> case when a tail cannot process incoming mpBFD control >>> packets at the offered rate is entirely non-issue. Such >>> scenario must be handled by the implementation and may be >>> controlled by local policy, e.g., close the MultipointTail >>> session. >> [BB]: Fair enough. >> >> In some scenarios, this issue will not necessarily be so >> unlikely tho: >> * If asymmetric crypto is used to solve the group message >> authentication problem (see later), the processing burden on >> any lightweight endpoints might lead to message verification >> leaving less available processor resource than needed for the >> host's other tasks. >> * Each tail might be joined to a very large number of >> multipoint sessions. >> >>> Where would you suggest to add the text? >> I would suggest a new section listing potential issues when >> there is no back channel. >> >> GIM2>> I've tried to start the new section but decided to insert >> the note in the first paragraph of Timer Manipulation section. >> Hope that is acceptable. >> >> >> >> >>> >>> 5/ Inability to authenticate the sender with symmetric keys >>> In unicast scenarios, symmetric keys can be used for >>> message authentication, >>> because each end knows there is only one other node with >>> the shared key. But, >>> in multipoint scenarios, all the tails would share the >>> key, so a shared key >>> does not authenticate who sent the message - any tail >>> can spoof the head from >>> the viewpoint of the other tails. >>> >>> Therefore text is needed to say that: >>> * multipoint message authentication is limited to cases >>> where all tails are >>> trusted not to spoof the head, if shared keys are used. >>> * otherwise asymmetric >>> message authentication would be needed, e.g. TESLA [RFC4082] >>> >>> GIM>> Thank you for the suggested text. Would the Security >>> Considerations section be appropriate place: >> [BB]: Well, the point limits the applicability of the >> assumption about security in 5. 'Assumptions', so this would >> fit well there. >> Then "Security Considerations" should point to everywhere in >> the doc that discusses security, such as this (to save time >> for security reviewers). >> >>> NEW TEXT: >>>    Use of shared keys to authenticate BFD Control packet in >>> multipoint >>>    scenarios is limited because tail can spoof the head from the >>>    viewpoint of the other tails.  Thus, if shared keys are >>> used, all >>>    tails MUST be trusted not to spoof the head. >> [BB]: Normally a MUST is applied to implementations. It would >> be rather odd to require users/operators to satisfy a spec >> requirement, particularly requiring them to trust each other. >> I think this should be written as an applicability statement >> not a normative requirement. >> >> GIM2>> I've adopted text suggested by Spencer and moved the >> paragraph to section Assumption. >> >> >> >>> Otherwise, asymmetric >>>    message authentication would be needed, e.g., Timed >>> Efficient Stream >>>    Loss-Tolerant Authentication (TESLA) as described in >>> [RFC4082]. >> >> [BB]: If you are going to allow for cases where all tails are >> trusted not to spoof the head, then the assumption written in >> section 5 is no longer correct. >> >> [FYI, RFC4082 is only a generic description. Many RFCs have >> been written to authenticate specific protocols along TESLA >> lines.] >> >>> >>> A related nit: Section 5 says all tails are assumed to >>> have a common >>> authentication key. In cases with symmetric message >>> authentication, surely the >>> head also needs the same key. >>> >>> GIM>> Thank you. Please check the updated text: >>> NEW TEXT: >>>    If authentication is in use, the head and all tails must be >>>    configured to have a common authentication key in order >>> for the tails >>>    to validate received the multipoint BFD Control packets. >> [BB]: Yup. Except delete "received the". >> Also see above about whether this is now a correct assumption. >> >> GIM2>> I think that s/must/may/ will keep the Assumption valid. >> >> >> >>> >>> 6/ Source address spoofing >>> A 3-way handshake makes a protocol robust against simple >>> source address >>> spoofing. Without a 3WHS, surely the spec. needs to >>> highlight this >>> vulnerability or discuss ways to address it or why it is >>> not an issue. >>> >>> GIM>> Because mpBFD control packets cannot be demultiplexed >>> by  tail based on the value of Your Discriminator field as >>> per RFC 5880, >>> the new procedure outlined in Section 4.7: >>>    IP and MPLS multipoint tails MUST demultiplex BFD packets >>> based on a >>>    combination of the source address, My Discriminator and >>> the identity >>>    of the multipoint tree which the Multipoint BFD Control >>> packet was >>>    received from. Together they uniquely identify the head >>> of the >>>    multipoint path. >>> and described in details in Section 4.13.2: >>>       If the Multipoint (M) bit is set >>> >>>          If the Your Discriminator field is nonzero, the >>> packet MUST be >>>          discarded. >>> >>>          Select a session as based on source address, My >>> Discriminator >>>          and the identity of the multipoint tree which the >>> Multipoint >>>          BFD Control packet was received.  If a session is >>> found, and >>>          bfd.SessionType is not MultipointTail, the packet >>> MUST be >>>          discarded.  If a session is not found, a new >>> session of type >>>          MultipointTail MAY be created, or the packet MAY be >>> discarded. >>>          This choice is outside the scope of this specification. >>> >>> Would you suggest additional text to a use case where the >>> new demultiplexing is not sufficent to protect from source >>> address spoofing? >> >> [BB]: I seem to have become co-opted into redesigning this >> protocol. I'd prefer to limit my involvement to reviewing :) >> >> >>> >>> 7/ Scope >>> On eight occasions an issue is raised, but resolution is >>> stated as outside the >>> scope of this document. It is OK to limit the scope of a >>> spec, for example to >>> allow for multiple solutions to each issue. But at least >>> one solution must >>> already exist for each of these eight issues. So, at >>> least one example solution >>> ought to be cited in each case. If any issues are open, >>> then this should not be >>> on the standards track. >>> >>> It would be more useful to state why each issue is out >>> of scope. This would be >>> helped by stating from the start what the scope of the >>> document is. >>> >>> GIM>> I've listed all eight occasions with the explanation >>> for each one: >>> >>> 1. Details of tail notification to the head are outside the >>> scope of this document. - Notifications by tails >>> addressed in draft-ietf-bfd-multipoint-active-tail >>> . >>> Will add as informational reference. >>> >> [BB]: Good. >> >> Nonetheless, given you have confirmed that a reverse path is >> optional, the doc still needs to address the case where there >> is no reverse path. >> >> GIM2>> Introduction notes: >>  Use of BFD in Demand mode enables a tail monitor availability >>  of a multipoint path even without the existence of some kind of a >>  return path to the head. >> >> >> {Note 1} For the active tail draft, you might find the >> following ideas for scaling multipoint feedback useful: >> >> *Statistical feedback:* >> Nonnenmacher, Jö. & Biersack, E.W., "Scalable Feedback for >> Large Groups ," >> IEEE/ACM Transactions on Networking 7(3):375--386 (June 1999) >> >> FUHRMANN, T., AND WIDMER, J. "On the scaling of feedback >> algorithms for very large multicast groups >> ," Computer >> Communications 24, 5-6 (March 2001), 539 547; >> WIDMER, J., AND FUHRMANN, T. Extremum feedback for very large >> multicast groups. Tech. Rep. TR 12-2001, Prakfische >> Informatik IV, University of Mannheim, Germany, May 2001. >> >> Also, anycast can be used to select different representative >> feedback tails, e.g. for a certain time, which might overlap >> with the periods for which a few other tails are selected >> using subsequent anycasts. >> >> *Logical 'AND' feedback:* >> Burbridge, T., Soppera, A., Briscoe, R. and Jacquet, A. >> "Method and device for co-ordinating networked group members >> " >> Patent WO2004059479, (Jul 2004; Priority 24 Dec 2002) >> [AFAICT this patent is still being maintained, so use of it >> in a protocol would require an IPR declaration.] >> >> >>> 1. Details of how the head keeps track of tails and how >>> tails alert their connectivity to the head are outside >>> scope of this document. - Same as #1. >>> >> [BB]: And my response is same as #1. >>> >>> 1. Bootstrapping BFD session to multipoint MPLS LSP in case >>> of penultimate hop popping is outside the scope of this >>> document. - It may use control plane as in MVPN draft. >>> Will add as informational reference. >>> >> [BB]: Good. >>> >>> 1. Use of other types of encapsulation of the BFD control >>> message over multipoint LSP is outside the scope of this >>> document. - This in reference to ACH encapsulation that >>> is discussed in draft-mirsky-mpls-p2mp-bfd >>> . >>> Should it be added as informational reference? What >>> would be the imacpt of progressing this specification? >>> >> [BB]: See earlier comment about citing individual drafts (I >> don't have enough BFD knowledge to give a BFD-specific answer). >> >> Also, in my review I should also have said: when creating new >> encapsulations, pls see the common transport issues related >> to encapsulation: >> https://trac.ietf.org/trac/tsv/wiki/tsvdir-common-issues#TunnelingprotocolsandTransportRelatedIssues >> >> >> >>> 1. Change in the value of bfd.RequiredMinRxInterval is >>> outside the scope of this document. - Same as #1. >>> >> [BB]: And my response is same as #1. >>> >>> 1. If a session is not found, a new session of type >>> MultipointTail MAY be created, or the packet MAY be >>> discarded. This choice is outside the scope of this >>> specification. - I propose to add "based on local >>> policy" to the last sentence. >>> >> [BB]: On what basis will local policy decide? It's my job as >> a reviewer to ensure that this spec does not contain any >> loose ends (open issues). >> >> GIM2>> It could be based on the maximum number of MultipointTail >> sessions and number of active MultipointTail sessions on the >> node. I'd clarify it as: >>   This choice MAY be controlled by the local policy, e.g. maximum >> number of >>   MultipointTail sessions and number of active MultipointTail >> sessions, >>   and is outside the scope of this specification. >> >> >> >>> 1. The exact method of selection is application-specific >>> and is thus outside the scope of this specification. - >>> This is copied from RFC 5880: "The exact method of >>> selection is application specific and is thus outside >>> the scope of this specification." as the section is to >>> replace Section 6.8.6. >>> >> [BB]: OK. >>> >>> 1. If a matching session is not found, a new session of >>> type PointToPoint MAY be created, or the packet MAY be >>> discarded. This choice is outside the scope of this >>> specification. - Same as #6. >>> >> >> [BB]: And my response is same as #6. >> [Sry, my embedded comments have broken your numbered list.] >> >> >>> >>> >>> There is also one issue that is "for further >>> discussion". Does this mean the >>> document is not ready yet? >>> >>> GIM>> I think that the question left for further discussion >>> is non-technical: >>>    The semantic difference between Down and AdminDown state >>> is for >>>    further discussion. >>> I propose to remove the sentence altogether. >> [BB]: OK. >> >>> >>> >>> 8/ Incremental deployment >>> >>> Section 4.4.1.  "New State Variable Values" defines >>> bfd.SessionType = >>> PointToPoint as well as a couple of Multipoint >>> alternatives. Presumably this >>> spec does not require all existing PointToPoint systems >>> to support this state >>> value. Is the implication that only Multipoint systems >>> that happen to be in >>> PointToPoint mode should use this state? >>> >>> GIM>> You're aboultely right, existing implementations of >>> BFD don't need to support bfd.SessionType variable. Only >>> implementations that support the base BFD, single-hop or >>> multi-hop, and this specification, mpBFD, should support >>> bfd.SessionType and set it to PointToPoint value when BFD is >>> in single-hop or multi-hop mode. When in mpBFD mode, >>> bfd.SessionType will be set to either MultipointHead or >>> MultipointClient. >> [BB]: Doesn't something need to be written (or referenced) to >> clarify all this? AFAIR, this spec. never made clear that >> multipoint is a fork in implementations. >> >> GIM2>> And so is S-BFD. (Note, bfd.SessionType introduced in RFC >> 7880 S-BFD but missed to define PointToPoint value). >> >> >> >> >>> >>> ==Nits== >>> >>> * Sometimes 'tree' is used to mean a multipoint path in >>> general. I suspect >>> 'path' was intended. >>> >>> GIM>> I've found six occasions of "tree" and s/tree/path/ >>> >>> >>> 4.8.  Packet consumption on tails >>> s/Node/Nodes/ >>> s/packet/packets/ >>> s/demultiplex/demultiplexed/ >>> >>> GIM>> Accepted all three. >>> >>> >>> 4.9.  Bringing Up and Shutting Down Multipoint BFD Service >>> " >>>    a newly >>>    started head (that does not have any previous state >>> information >>>    available) SHOULD start with... >>> " >>> ... >>> " >>>    ... (so long as the restarted head >>>    is using the same or a larger value of >>> bfd.DesiredMinTxInterval than >>>    it did previously). >>> " >>> If it has no state available, how can it know whether a >>> value is larger than >>> previously? >>> >>> GIM>> You are right, the BFD system at the head would not >>> know the previous value of bfd.DesiredMinTxInterval. This >>> text is to caution operator from decreasing >>> bfd.DesiredMinTxInterval upon restart of the BFD system. >>> >>> >>> 4.9.  Bringing Up and Shutting Down Multipoint BFD Service >>> There are a number of "SHOULD"s and "SHOULD NOT"s that >>> do not state or give >>> examples of circumstances in which the "SHOULD" would >>> not be appropriate. If >>> there are none, "MUST" would be more appropriate. >>> >>> GIM>> In the first paragraph SHOULD may not be followed if >>> the implementation can differentiate between the very first >>> start and restarts of BFD system. If it is the first start >>> of BFD system, the head MAY directly progress to Up state >>> skipping Down state. >>> The last paragraph describes graceful shuttdown. The head >>> MAY shut the BFD mp session abruptly by just stopping >>> transmission of BFD Control packets. >> [BB]: I assume you will say all this in the next rev, not >> just in this email. >> >> GIM2>> Appended the following: >> NEW TEXT: >> Alternatively, the head MAY stop transmitting BFD Control packets >> and not send any more BFD Control packets with the new state >> (Down or AdminDown). Tails >> will declare the multipoint session down only after the detection >> time interval runs out. >> >> >> >>> >>> 4.10.  Timer Manipulation >>> " >>>    Because of the one-to-many mapping, a session of type >>> MultipointHead >>>    SHOULD NOT initiate a Poll Sequence in conjunction >>> with timer value >>>    changes.  However, to indicate a change in the packets, >>>    MultipointHead session MUST send packets with the P >>> bit set. >>>    MultipointTail session MUST NOT reply if the packet >>> has M and P bits >>>    set and bfd.RequiredMinRxInterval set to 0. >>> " >>> The initial "SHOULD NOT" needs to be written another >>> way. Perhaps >>> " >>>    ...a session of type MultipointHead >>>    does not initiate a Poll Sequence >>> " >>> The head's normative action is defined by the following >>> "MUST", then the tail's >>> "MUST NOT reply" is what prevents the poll sequence >>> happening. >>> >>> GIM>> A Poll Sequence starts with the initiator setting Poll >>> bit. Unless the peer sends BFD Control packet with Finl bit >>> set the poll sequence would continue indefinetely. The >>> initial SHOULD NOT, in my opinion, correctly points that the >>> mechanism of Poll Sequence not to be used by MultipointHead >>> when changing transmission interval. I think that MUST in >>> the first paragraph can be downgraded to MAY because the >>> MultipointHead doesn't need to use transition period when >>> changing the transmission interval to lower level, i.e., >>> decreasing frequency. May I propose the following: >>> OLD TEXT: >>>    Because of the one-to-many mapping, a session of type >>> MultipointHead >>>    SHOULD NOT initiate a Poll Sequence in conjunction with >>> timer value >>>    changes.  However, to indicate a change in the packets, >>>    MultipointHead session MUST send packets with the P bit set. >>> NEW TEXT: >>>    Because of the one-to-many mapping, a session of type >>> MultipointHead >>>    SHOULD NOT initiate a Poll Sequence in conjunction with >>> timer value >>>    changes.  However, to indicate a change in the packets, >>>    MultipointHead session MAY send packets with the P bit >>> set during transition period. >> [BB]: If I were an implementer, I would not know what this is >> saying I ought to implement. The spec needs to answer this >> question: If the head changes the packets what happens >> differently if it sets the P bit vs. if it doesn't? >> >> GIM2>> I think we can expect that the implementer is familiar >> with RFC 5880 and, very likely, has implemented it one or more >> times already. >> >> >>> >>> 4.11.  Detection Times >>> Delete "in the calculation" (repetition). >>> >>> GIM>> Done. >>> >>> >>> 4.13.1.  Reception of BFD Control Packets >>> Some actions seem to be only relevant to PointToPoint >>> sessions, but they are >>> stated for all session types. Specifically: "the >>> transmission of Echo packets, >>> if any, MUST cease." "the Poll Sequence MUST be >>> terminated." "MUST cease the >>> periodic transmission of BFD Control packets" "MUST send >>> periodic BFD Control >>> packets" >>> >>> " >>> If bfd.SessionType is PointToPoint, update the Detection >>> Time as >>>       described in section 6.8..4 of [RFC5880].  If >>> bfd.SessionType is >>>       MultipointTail, >>> " >>> The second sentence above ought to start on a new line >>> as an Else if. >>> >>> GIM>> Hope I got it right: >>>       If bfd.SessionType is PointToPoint, update the >>> Detection Time as >>>       described in section 6.8.4 of [RFC5880]. >>> >>>       Else >>> >>>          If bfd.SessionType is MultipointTail, then update >>> the Detection >>>          Time as the product of the last received values of >>> Desired Min >>>          TX Interval and Detect Mult, as described in >>> Section 5.11 of >>>          this specification. >>> >>> >>> 4.13.2.  Demultiplexing BFD Control Packets >>> " >>>    This section is part of the replacement for [RFC5880] >>> section 6.8.6, >>>    separated for clarity. >>> " >>> Do you mean "This section replaces the sentence: "If the >>> Multipoint (M) bit is >>> nonzero, the packet MUST be discarded." in [RFC5880] >>> section 6.8.6? >>> >>> The statements under "If the Multipoint (M) bit is set" >>> are not formatted like >>> the rest of the if-else logic, and I think an Else is >>> missing at the start of >>> the statement after the nested "If".. >>> >>> GIM>> Agree, the paragraph is not structured properly. How >>> about this formating: >>>       If the Multipoint (M) bit is set >>> >>>          If the Your Discriminator field is nonzero, the >>> packet MUST be >>>          discarded. >>> >>>          Select a session as based on source address, My >>> Discriminator >>>          and the identity of the multipoint path which the >>> Multipoint >>>          BFD Control packet was received. >>> >>>          If a session is found, and bfd.SessionType is not >>>          MultipointTail, the packet MUST be discarded. >>> >>>          Else >>> >>>             If a session is not found, a new session of type >>> MultipointTail MAY be created, or the packet MAY be >>>             discarded. This choice is outside the scope of this >>> specification. >>> >> [BB]: As long as this represents the logic you want, fine. >> The point is that the indentation is the only clue to whether >> one 'if' is conditional on a previous 'if', or not. >> >> HTH >> >> Bob >> >> >> >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> >> > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > > > > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------50CD63D6F60077829ED42DCB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Greg,

I may be wrong, in which case fine.
But I'll take each case in turn (there may not be security problems with all, but a problem with just one would still be of concern):

Multicast:
If there is an SSM tree from host A to multicast address G, I am not familiar enough with SSM to know what happens when host B sends a packet to G with source address A (i.e. spoofing A). I assume the IGMP messages build the tree back from each member to A, so usually there will be no route from B, even if it is spoofing A as the source. However, I would have thought that a host connected to the same router as A could spoof A and get onto the SSM tree. Or does SSM always check for this type of spoofing?

Directly connected.
As with multicast, even tho not every machine on the Internet could spoof the source address, surely if the link were a shared link (which is implied in this use-case) any machine on the shared link could spoof the genuine source.

MPLS
I think the MPLS case is safe, cos at each hop the label switched path is specific to each prior hop.

As I said, I may be wrong.
But, if either of the first two cases have a vulnerability in certain cases, it ought to be described in the draft, even if the vulnerability is confined to a specific set of circumstances.


Bob


On 11/06/18 19:14, Greg Mirsky wrote:
Hi Bob,
thank you for the most thoughtful and helpful comments. It was not my intention to pull you into re-designing of the specification. I've accepted all the editorial updates, applied them to the new working version.

I have to admit that I'm bit confused that you see lack of 3WHS in mpBFD as the significantly increased risk of the spoofing attack on leaves. The BFD Control packet is expected to be received by a leave from one of the following:
  • multicast path;
  • directly connected;
  • p2mp/mp2mp MPLS LSP.
For the first scenario, as I understand, a host must first use multicast control protocol to join the multicast path.
For the second - it is reasonable to assume, as in VRRP and PIM-SM drafts I've referenced earlier, that BFD control packet be required to have IP TTL == 1 and mcast IP address of link scope.
And the third, I think, is similar to #1 above.

If these considerations are technically accurate, I'll work on the text for Assumptions section.

Regards,
Greg


On Thu, Jun 7, 2018 at 5:02 PM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
Greg,

Your responses are AOK now.

Remaining Security Vulnerability

I think you may have misunderstood my point about vulnerability to source address spoofing without a 3WHS. When you said in response:

Would you suggest additional text to a use case where the new demultiplexing is not sufficent to protect from source address spoofing?

 I said:
[BB]: I seem to have become co-opted into redesigning this protocol. I'd prefer to limit my involvement to reviewing :)

 If this wasn't clear, I meant, "I believe this protocol has a security problem that needs to be fixed. But it's your job to fix it, not mine."

If you can't fix it, I suggested that you need to at least add a section listing all the limitations when a multipoint scheme has no back channel (the others being no feedback on timing control and no way to set up asymmetric authentication).


Apologies, if the following is already obvious to you, but it is safer to be over-cautious:
The text you originally quoted in response to my point about 3WHS uses the source address as part of the identification of a session. That is the problem (not a solution). If a malicious host M masquerading as the source S spoofs the source address of S in its packets, the tails will not be able to tell that these packets are not from S.

A 3WHS (e.g. as in TCP) is a simple way to address this vulnerability, by the tails using the routing system to send a packet to the location where the source claims to be sending from. I.e. the tail returns a packet to address S with some random information in it (in TCP's case, the initial sequence number). If S genuinely initiated the handshake, it will reflect the random info to the tail in the 3rd way of the handshake. If M is masquerading as S, it will not receive the 2nd way of the handshake. And it won't be able to spoof the 3rd way without the random info.

Without a 3WHS, multipoint BFD does not check that the source address is genuine.


Some (mostly editorial) comments from scanning the diff:

In the intro, the para starting "As an option, the tail may notify the head..." is prerequisite info that needs to come before the para ending "even without the existence of some kind of a return path to the head."

s/in the received by MultipointTail BFD Control packet/
 /in the received MultipointTail BFD Control packet/

s/entire/the entire/ (twice)

Section 6 (Assumptions) has no flow of logic between the new text and the pre-existing text. It would be better to switch the order of the paras.


Otherwise, I think my comments are becoming increasingly less useful, so I'll stop. I don't know enough about the whole ecosystem around this draft to be any more helpful, I think.


Bob


On 05/06/18 03:23, Greg Mirsky wrote:
Hi Bob,
thank you for further clarifications and the new ideas. Please find my follow-up in-line and tagger GIM2>>.
I'll check for nits and grammar and will publish the new version shortly.

Regards,
Greg

On Tue, May 29, 2018 at 3:22 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
Greg,


On 26/05/18 20:49, Greg Mirsky wrote:
Hi Bob,
thank you for the thorough review, detailed questions and helpful comments. Please find my answers in-line and tagged GIM>>.
I've updated the working version of the draft based on your comments and suggestions. Appreciate your feedback whether all questions have been addressed.
Attached please find the diff of -16 and the working version and the copy of the working version of the draft.

Regards,
Greg

On Mon, May 21, 2018 at 5:20 PM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
Reviewer: Bob Briscoe
Review result: Not Ready

Altho this is a TSV-ART review, I did not find many transport-related issues to
focus on, except a need to justify why lack of information for adapting the
transmit interval is not an issue.

Nonetheless, I did find a few other non-trivial technical issues, including 2
security issues, enumerated below (I mis-spent some of my early research career
working on a multicast session control and security, for which we used
beaconing control channels). However, I only have passing prior knowledge of
BFD, so my critique might be off-beam.

==Main Technical Concerns===

1/ Mandatory return path?
RFC5880 is the base RFC that this draft updates. RFC5880 says that
"unidirectional links" are in scope, but only as long as there is a return path.

The introduction of this bfd-multipoint draft seems to contradict that, making
a return path optional: "
   As an option, the tail may notify the head of the lack of multipoint
   connectivity.  Details of tail notification to the head are outside
   the scope of this document.
"
It's allowable for irrelevant details to be outside the scope, but surely it
needs to be clear whether at least the existence of a return path is mandatory.
GIM>> Thank you for highlighting this issue. I think that the second paragraph of Introduction is the appropriate place to note that this mechanism does not require existence of a return path from tails to the head. Would the following be acceptable:
NEW TEXT:
   Use of BFD in
   Demand mode enables a tail monitor availability of a multipoint path
   even without the existence of some kind of a return path to the head.

2/ Mechanism for verifying connectivity, or not?
The introduction seems to contradict itself:
"
   As multipoint transmissions are inherently unidirectional, this
   mechanism purports only to verify this unidirectional connectivity.
"
"
   Term "connectivity" in this document is not being used in the context
   of connectivity verification in transport network but as an
   alternative to "continuity", i.e. existence of a forwarding path
   between the sender and the receiver.
"
How can this mechanism verify connectivity, but not be used in the context of
connectivity verification in the transport network?
GIM>> This draft defines the base specification for multipoint BFD. In order for multipoint BFD to support the transport-like connectivity verification we need to do work similar to described in RFC 6428. 
[BB]: Caveat: I am having to talk in generalizations, cos I don't actually know how you are going to get this protocol to work in a wide range of circumstances, given inherent problems like multipoint feedback implosion {Note 1}.

My point was that, having broken up the drafts in this way, this draft on its own no longer defined a workable protocol. Therefore, it needed some references to other drafts (even if they are placeholders), so that the extent of the pre-requisite collection of work is clear. The refs you give later go a long way to fixing this issue.

If each pre-requisite protocol is intended to only represent one example, the citation can say that and the ref can be informative. But with zero examples for all the prerequisite parts, all the reader sees is a dismembered octopus, not a protocol.



3/ Use case
The introduction seems to be written rather academically. Surely, in cases
where there is never a return path, only the tails will ever be able to verify
connectivity. The head could continue transmitting BFD packets (and data
packets) for years without ever knowing whether it is connected to anything.
Knowledge of connectivity is surely of little use if it excludes the link
sender, which is the node that always controls routing.

If there are scenarios where it is useful for tails but not the head to be able
to verify connectivity, can you please give a concrete example?
GIM>> One example could be a multicast system with 1+1 protection. Without multipoint BFD tails would not be able to detect the failure of the muticast path from the head. Other examples discussed in several drafts:
I am not sure how references to non-WG drafts affect the progress of this document. Appreciate your suggestion.
 [BB]: In my experience, informative refs to non-WG drafts as use-cases would be OK during doc development. However, if a non-WG draft fails to proceed, its citation has to be removed later. So choose those that are most likely to proceed.

Nonetheless, if you cite some specs that turn this into a workable protocol (see previous issue) use-cases might not be necessary.
GIM2>> I've added reference to use of this mechanism in BGP/MPLS MVPN. 




4/ Interval adaptation
Text is needed to describe why it is not an issue for the head to be unaware
whether it needs to adapt its transmit interval. Otherwise, this seems
potentially problematic.
GIM>> Very interesting, thank you. I wouldn't say that the case when a tail cannot process incoming mpBFD control packets at the offered rate is entirely non-issue. Such scenario must be handled by the implementation and may be controlled by local policy, e.g., close the MultipointTail session.
[BB]: Fair enough.

In some scenarios, this issue will not necessarily be so unlikely tho:
* If asymmetric crypto is used to solve the group message authentication problem (see later), the processing burden on any lightweight endpoints might lead to message verification leaving less available processor resource than needed for the host's other tasks.
* Each tail might be joined to a very large number of multipoint sessions.

Where would you suggest to add the text?
 I would suggest a new section listing potential issues when there is no back channel.
GIM2>> I've tried to start the new section but decided to insert the note in the first paragraph of Timer Manipulation section. Hope that is acceptable. 




5/ Inability to authenticate the sender with symmetric keys
In unicast scenarios, symmetric keys can be used for message authentication,
because each end knows there is only one other node with the shared key. But,
in multipoint scenarios, all the tails would share the key, so a shared key
does not authenticate who sent the message - any tail can spoof the head from
the viewpoint of the other tails.

Therefore text is needed to say that:
* multipoint message authentication is limited to cases where all tails are
trusted not to spoof the head, if shared keys are used. * otherwise asymmetric
message authentication would be needed, e.g. TESLA [RFC4082]
GIM>> Thank you for the suggested text. Would the Security Considerations section be appropriate place:
 [BB]: Well, the point limits the applicability of the assumption about security in 5. 'Assumptions', so this would fit well there.
Then "Security Considerations" should point to everywhere in the doc that discusses security, such as this (to save time for security reviewers).

NEW TEXT:
   Use of shared keys to authenticate BFD Control packet in multipoint
   scenarios is limited because tail can spoof the head from the
   viewpoint of the other tails.  Thus, if shared keys are used, all
   tails MUST be trusted not to spoof the head. 
[BB]: Normally a MUST is applied to implementations. It would be rather odd to require users/operators to satisfy a spec requirement, particularly requiring them to trust each other. I think this should be written as an applicability statement not a normative requirement.
GIM2>> I've adopted text suggested by Spencer and moved the paragraph to section Assumption.


Otherwise, asymmetric
   message authentication would be needed, e.g., Timed Efficient Stream
   Loss-Tolerant Authentication (TESLA) as described in [RFC4082].

 [BB]: If you are going to allow for cases where all tails are trusted not to spoof the head, then the assumption written in section 5 is no longer correct.

[FYI, RFC4082 is only a generic description. Many RFCs have been written to authenticate specific protocols along TESLA lines.]


A related nit: Section 5 says all tails are assumed to have a common
authentication key. In cases with symmetric message authentication, surely the
head also needs the same key.
GIM>> Thank you. Please check the updated text:
NEW TEXT:
   If authentication is in use, the head and all tails must be
   configured to have a common authentication key in order for the tails
   to validate received the multipoint BFD Control packets.
[BB]: Yup. Except delete "received the".
Also see above about whether this is now a correct assumption.
GIM2>> I think that s/must/may/ will keep the Assumption valid. 



6/ Source address spoofing
A 3-way handshake makes a protocol robust against simple source address
spoofing. Without a 3WHS, surely the spec. needs to highlight this
vulnerability or discuss ways to address it or why it is not an issue.
GIM>> Because mpBFD control packets cannot be demultiplexed by  tail based on the value of Your Discriminator field as per RFC 5880,
the new procedure outlined in Section 4.7:
   IP and MPLS multipoint tails MUST demultiplex BFD packets based on a
   combination of the source address, My Discriminator and the identity
   of the multipoint tree which the Multipoint BFD Control packet was
   received from.  Together they uniquely identify the head of the
   multipoint path.
and described in details in Section 4.13.2:
      If the Multipoint (M) bit is set

         If the Your Discriminator field is nonzero, the packet MUST be
         discarded.

         Select a session as based on source address, My Discriminator
         and the identity of the multipoint tree which the Multipoint
         BFD Control packet was received.  If a session is found, and
         bfd.SessionType is not MultipointTail, the packet MUST be
         discarded.  If a session is not found, a new session of type
         MultipointTail MAY be created, or the packet MAY be discarded.
         This choice is outside the scope of this specification.

Would you suggest additional text to a use case where the new demultiplexing is not sufficent to protect from source address spoofing?

 [BB]: I seem to have become co-opted into redesigning this protocol. I'd prefer to limit my involvement to reviewing :)



7/ Scope
On eight occasions an issue is raised, but resolution is stated as outside the
scope of this document. It is OK to limit the scope of a spec, for example to
allow for multiple solutions to each issue. But at least one solution must
already exist for each of these eight issues. So, at least one example solution
ought to be cited in each case. If any issues are open, then this should not be
on the standards track.

It would be more useful to state why each issue is out of scope. This would be
helped by stating from the start what the scope of the document is.
GIM>> I've listed all eight occasions with the explanation for each one:
  1. Details of tail notification to the head are outside the scope of this document. - Notifications by tails addressed in draft-ietf-bfd-multipoint-active-tail. Will add as informational reference.
 [BB]: Good.

Nonetheless, given you have confirmed that a reverse path is optional, the doc still needs to address the case where there is no reverse path.
GIM2>> Introduction notes:
 Use of BFD in Demand mode enables a tail monitor availability
 of a multipoint path even without the existence of some kind of a
 return path to the head.


{Note 1} For the active tail draft, you might find the following ideas for scaling multipoint feedback useful:

Statistical feedback:
Nonnenmacher, Jö. & Biersack, E.W., "Scalable Feedback for Large Groups," IEEE/ACM Transactions on Networking 7(3):375--386 (June 1999)

FUHRMANN, T., AND WIDMER, J. "On the scaling of feedback algorithms for very large multicast groups," Computer Communications 24, 5-6 (March 2001), 539 547;
WIDMER, J., AND FUHRMANN, T. Extremum feedback for very large multicast groups. Tech. Rep. TR 12-2001, Prakfische Informatik IV, University of Mannheim, Germany, May 2001.

Also, anycast can be used to select different representative feedback tails, e.g. for a certain time, which might overlap with the periods for which a few other tails are selected using subsequent anycasts.

Logical 'AND' feedback:
Burbridge, T., Soppera, A., Briscoe, R. and Jacquet, A. "Method and device for co-ordinating networked group members" Patent WO2004059479, (Jul 2004; Priority 24 Dec 2002)
[AFAICT this patent is still being maintained, so use of it in a protocol would require an IPR declaration.]


  1. Details of how the head keeps track of tails and how tails alert their connectivity to the head are outside scope of this document. - Same as #1.
 [BB]: And my response is same as #1.
  1. Bootstrapping BFD session to multipoint MPLS LSP in case of penultimate hop popping is outside the scope of this document. - It may use control plane as in MVPN draft. Will add as informational reference.
 [BB]: Good.
  1. Use of other types of encapsulation of the BFD control message over multipoint LSP is outside the scope of this document. - This in reference to ACH encapsulation that is discussed in draft-mirsky-mpls-p2mp-bfd. Should it be added as informational reference? What would be the imacpt of progressing this specification?
 [BB]: See earlier comment about citing individual drafts (I don't have enough BFD knowledge to give a BFD-specific answer).

Also, in my review I should also have said: when creating new encapsulations, pls see the common transport issues related to encapsulation:
https://trac.ietf.org/trac/tsv/wiki/tsvdir-common-issues#TunnelingprotocolsandTransportRelatedIssues


  1. Change in the value of bfd.RequiredMinRxInterval is outside the scope of this document. - Same as #1.
 [BB]: And my response is same as #1.
  1. If a session is not found, a new session of type MultipointTail MAY be created, or the packet MAY be discarded. This choice is outside the scope of this specification. - I propose to add "based on local policy" to the last sentence.
 [BB]: On what basis will local policy decide? It's my job as a reviewer to ensure that this spec does not contain any loose ends (open issues).
GIM2>> It could be based on the maximum number of MultipointTail sessions and number of active MultipointTail sessions on the node. I'd clarify it as:
  This choice MAY be controlled by the local policy, e.g. maximum number of 
  MultipointTail sessions and number of active MultipointTail sessions,
  and is outside the scope of this specification.



  1. The exact method of selection is application-specific and is thus outside the scope of this specification. - This is copied from RFC 5880: "The exact method of selection is application specific and is thus outside the scope of this specification." as the section is to replace Section 6.8.6.
 [BB]: OK.
  1. If a matching session is not found, a new session of type PointToPoint MAY be created, or the packet MAY be discarded. This choice is outside the scope of this specification. - Same as #6.

 [BB]: And my response is same as #6.
[Sry, my embedded comments have broken your numbered list.]


     

There is also one issue that is "for further discussion". Does this mean the
document is not ready yet?
GIM>> I think that the question left for further discussion is non-technical:
   The semantic difference between Down and AdminDown state is for
   further discussion. 
I propose to remove the sentence altogether.
 [BB]: OK.



8/ Incremental deployment

Section 4.4.1.  "New State Variable Values" defines bfd.SessionType =
PointToPoint as well as a couple of Multipoint alternatives. Presumably this
spec does not require all existing PointToPoint systems to support this state
value. Is the implication that only Multipoint systems that happen to be in
PointToPoint mode should use this state?
GIM>> You're aboultely right, existing implementations of BFD don't need to support bfd.SessionType variable. Only implementations that support the base BFD, single-hop or multi-hop, and this specification, mpBFD, should support bfd.SessionType and set it to PointToPoint value when BFD is in single-hop or multi-hop mode. When in mpBFD mode, bfd.SessionType will be set to either MultipointHead or MultipointClient.
 [BB]: Doesn't something need to be written (or referenced) to clarify all this? AFAIR, this spec. never made clear that multipoint is a fork in implementations.
GIM2>> And so is S-BFD. (Note, bfd.SessionType introduced in RFC 7880 S-BFD but missed to define PointToPoint value). 




==Nits==

* Sometimes 'tree' is used to mean a multipoint path in general. I suspect
'path' was intended.
GIM>> I've found six occasions of "tree" and s/tree/path/ 

4.8.  Packet consumption on tails
s/Node/Nodes/
s/packet/packets/
s/demultiplex/demultiplexed/
GIM>> Accepted all three. 

4.9.  Bringing Up and Shutting Down Multipoint BFD Service
"
   a newly
   started head (that does not have any previous state information
   available) SHOULD start with...
"
...
"
   ... (so long as the restarted head
   is using the same or a larger value of bfd.DesiredMinTxInterval than
   it did previously).
"
If it has no state available, how can it know whether a value is larger than
previously?
GIM>> You are right, the BFD system at the head would not know the previous value of bfd.DesiredMinTxInterval. This text is to caution operator from decreasing  bfd.DesiredMinTxInterval upon restart of the BFD system.

4.9.  Bringing Up and Shutting Down Multipoint BFD Service
There are a number of "SHOULD"s and "SHOULD NOT"s that do not state or give
examples of circumstances in which the "SHOULD" would not be appropriate. If
there are none, "MUST" would be more appropriate.
GIM>> In the first paragraph SHOULD may not be followed if the implementation can differentiate between the very first start and restarts of BFD system. If it is the first start of BFD system, the head MAY directly progress to Up state skipping Down state.
The last paragraph describes graceful shuttdown. The head MAY shut the BFD mp session abruptly by just stopping transmission of BFD Control packets.
[BB]: I assume you will say all this in the next rev, not just in this email.
GIM2>> Appended the following:
NEW TEXT:
Alternatively, the head MAY stop transmitting BFD Control packets 
and not send any more BFD Control packets with the new state (Down or AdminDown). Tails
will declare the multipoint session down only after the detection time interval runs out. 



4.10.  Timer Manipulation
"
   Because of the one-to-many mapping, a session of type MultipointHead
   SHOULD NOT initiate a Poll Sequence in conjunction with timer value
   changes.  However, to indicate a change in the packets,
   MultipointHead session MUST send packets with the P bit set.
   MultipointTail session MUST NOT reply if the packet has M and P bits
   set and bfd.RequiredMinRxInterval set to 0.
"
The initial "SHOULD NOT" needs to be written another way. Perhaps
"
   ...a session of type MultipointHead
   does not initiate a Poll Sequence
"
The head's normative action is defined by the following "MUST", then the tail's
"MUST NOT reply" is what prevents the poll sequence happening.
GIM>> A Poll Sequence starts with the initiator setting Poll bit. Unless the peer sends BFD Control packet with Finl bit set the poll sequence would continue indefinetely. The initial SHOULD NOT, in my opinion, correctly points that the mechanism of Poll Sequence not to be used by MultipointHead when changing transmission interval. I think that MUST in the first paragraph can be downgraded to MAY because the MultipointHead doesn't need to use transition period when changing the transmission interval to lower level, i.e., decreasing frequency. May I propose the following:
OLD TEXT:
   Because of the one-to-many mapping, a session of type MultipointHead
   SHOULD NOT initiate a Poll Sequence in conjunction with timer value
   changes.  However, to indicate a change in the packets,
   MultipointHead session MUST send packets with the P bit set.
NEW TEXT:
   Because of the one-to-many mapping, a session of type MultipointHead
   SHOULD NOT initiate a Poll Sequence in conjunction with timer value
   changes.  However, to indicate a change in the packets,
   MultipointHead session MAY send packets with the P bit set during transition period.
 [BB]: If I were an implementer, I would not know what this is saying I ought to implement. The spec needs to answer this question: If the head changes the packets what happens differently if it sets the P bit vs. if it doesn't?
GIM2>> I think we can expect that the implementer is familiar with RFC 5880 and, very likely, has implemented it one or more times already. 


4.11.  Detection Times
Delete "in the calculation" (repetition).
GIM>> Done. 

4.13.1.  Reception of BFD Control Packets
Some actions seem to be only relevant to PointToPoint sessions, but they are
stated for all session types. Specifically: "the transmission of Echo packets,
if any, MUST cease." "the Poll Sequence MUST be terminated." "MUST cease the
periodic transmission of BFD Control packets" "MUST send periodic BFD Control
packets"

"
If bfd.SessionType is PointToPoint, update the Detection Time as
      described in section 6.8..4 of [RFC5880].  If bfd.SessionType is
      MultipointTail,
"
The second sentence above ought to start on a new line as an Else if.
GIM>> Hope I got it right:
      If bfd.SessionType is PointToPoint, update the Detection Time as
      described in section 6.8.4 of [RFC5880].

      Else

         If bfd.SessionType is MultipointTail, then update the Detection
         Time as the product of the last received values of Desired Min
         TX Interval and Detect Mult, as described in Section 5.11 of
         this specification. 

4.13.2.  Demultiplexing BFD Control Packets
"
   This section is part of the replacement for [RFC5880] section 6.8.6,
   separated for clarity.
"
Do you mean "This section replaces the sentence: "If the Multipoint (M) bit is
nonzero, the packet MUST be discarded." in [RFC5880] section 6.8.6?

The statements under "If the Multipoint (M) bit is set" are not formatted like
the rest of the if-else logic, and I think an Else is missing at the start of
the statement after the nested "If"..
GIM>> Agree, the paragraph is not structured properly. How about this formating:
      If the Multipoint (M) bit is set

         If the Your Discriminator field is nonzero, the packet MUST be
         discarded.

         Select a session as based on source address, My Discriminator
         and the identity of the multipoint path which the Multipoint
         BFD Control packet was received.

         If a session is found, and bfd.SessionType is not
         MultipointTail, the packet MUST be discarded.

         Else

            If a session is not found, a new session of type
            MultipointTail MAY be created, or the packet MAY be
            discarded.  This choice is outside the scope of this
            specification. 

[BB]: As long as this represents the logic you want, fine. The point is that the indentation is the only clue to whether one 'if' is conditional on a previous 'if', or not.

HTH

Bob




-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/



_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------50CD63D6F60077829ED42DCB-- From nobody Thu Jun 14 22:27:57 2018 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E138130DC7; Thu, 14 Jun 2018 22:27:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema To: Cc: rtg-bfd@ietf.org, draft-ietf-bfd-yang.all@ietf.org, ietf@ietf.org Subject: Secdir last call review of draft-ietf-bfd-yang-14 X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152904046940.26576.5655178143666756803@ietfa.amsl.com> Date: Thu, 14 Jun 2018 22:27:49 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 05:27:50 -0000 Reviewer: Christian Huitema Review result: Ready I already reviewed version 9 of this draft. The changes since then include more precise syntax definitions, a list of examples, and an extended security section. The security extensions outline the issues with even read-only disclosure of sensitive information, which is a welcome addition to the draft. >From a security point of view, this draft seems ready. From nobody Mon Jun 18 06:41:24 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB28130E3B; Sun, 17 Jun 2018 18:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 HsWkH6cDMNqA; Sun, 17 Jun 2018 18:41:54 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B95A5126CC7; Sun, 17 Jun 2018 18:41:53 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id i15-v6so22157122lfc.2; Sun, 17 Jun 2018 18:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Kz+nQcb6H4TbLP1n3Z/HatWPEtLC+k2nXaOxUH5lNGY=; b=jh0rIbBQ6q3HFCjkKVT8J/2eMmaBtGoIQZsCIzjwvhuHrsZteLWf+0pkhdHOQm9EUr kH3SXg+6m4l1tnavc0GCT4ooHwpzbalE/JvpIg+iiZFuKg9wlQcfrrH/f3WgmY0A2glF okP69h/ENSiURgOBmIN82WHYEMManIqJTznqF9d3EwA/p6wOTLzHgKhIyLGdQyFsriba tlcGpl0Jt8QBXHg1vM8CkgQB7xayoM5ihaMLviuORZErgCWV+rSGHy6mi9x2sffRLelM lZigJT7MT//4t88mO/TZagDPbO2KCjtN3K/78UuGZl/nuC+K/yIlTerPV0LhJVN9Kw4i YNqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Kz+nQcb6H4TbLP1n3Z/HatWPEtLC+k2nXaOxUH5lNGY=; b=nhWn6dLvrODzm9DpJhqknARUzdGvnM70dB2RRR/KPaJYhaqYfUOF+3MKJaNOR/3R6n giEiihQ9rAu01IVWqpKd+qkxs9dpoUwjAgsEt04fIXIkJ5sXkcNShHbaHV4Uc4JJnBXn fT+MX44TEKzrJesUFnkV1nFXv9qObjfCVU9vDoUI3LRORQLmU2gtLtKCA125k8yjeGgq D9XvJmKOW4vo9QUZaHuPKyuDL10Q9dF19XmHnswztQJyiMx0oKbCXydAfDkr4Isoz2LG F4creV5Xw4tuqi/JgLoZEuOR01CtMvJ+O424l9yYHZufPWip9Kk5o37Z5nuyBLnFw//E KMGw== X-Gm-Message-State: APt69E09WUpenMBmx+4hmD5aRRIxtEsF6+iSidXvq5buBGfoVXJuxaIo o4gNnugnfmsEk7PshZGs3fdKnza4dCXW1KDzWtI= X-Google-Smtp-Source: ADUXVKJUKiCxUqm2JLvdXtkiXTWqpdbgxyr8NoUH9cLLuWCf8kIyUPwzw7SX135iJ5ahiSXmi6aJOjjLR3hnP6Lg5SE= X-Received: by 2002:a19:d898:: with SMTP id r24-v6mr5403748lfi.7.1529286111945; Sun, 17 Jun 2018 18:41:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Sun, 17 Jun 2018 18:41:51 -0700 (PDT) In-Reply-To: References: <152815209936.30754.8397183918385058344.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Sun, 17 Jun 2018 18:41:51 -0700 Message-ID: Subject: Re: [IANA #1112479] Last Call: (BFD Multipoint Active Tails.) to Proposed Standard To: drafts-lastcall@iana.org Cc: iesg@ietf.org, ext Dave Katz , "David Ward (wardd)" , Santosh P K , Jeffrey Haas , "Reshad Rahman (rrahman)" , Martin Vigoureux , "BRUNGARD, DEBORAH A (ATTLABS)" , Alvaro Retana , rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary="000000000000766a91056ee0ab2c" Archived-At: X-Mailman-Approved-At: Mon, 18 Jun 2018 06:41:24 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 01:41:56 -0000 --000000000000766a91056ee0ab2c Content-Type: text/plain; charset="UTF-8" With corrected BFD WG address. On Sun, Jun 17, 2018 at 5:57 PM, Greg Mirsky wrote: > Hi Sabrina, > thank you for the review of the draft. Indeed, no IANA actions requested > in this specification. We'll keep the IANA Considerations section in place > upon publication if RFC Editor agrees to that. > > Regards, > Greg > > On Thu, Jun 14, 2018 at 2:28 PM, Sabrina Tanamal via RT < > drafts-lastcall@iana.org> wrote: > >> (BEGIN IANA COMMENTS) >> >> IESG/Authors/WG Chairs: >> >> The IANA Functions Operator has reviewed draft-ietf-bfd-multipoint-active-tail-08, >> which is currently in Last Call, and has the following comments: >> >> We understand that this document doesn't require any registry actions. >> >> While it's often helpful for a document's IANA Considerations section to >> remain in place upon publication even if there are no actions, if the >> authors strongly prefer to remove it, we do not object. >> >> If this assessment is not accurate, please respond as soon as possible. >> >> Thank you, >> >> Sabrina Tanamal >> Senior IANA Services Specialist >> >> (END IANA COMMENTS) >> >> > --000000000000766a91056ee0ab2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
With corrected BFD WG address.

On Sun, Jun 17, 2018 at 5:57 PM, Greg M= irsky <gregimirsky@gmail.com> wrote:
Hi Sabrina,
thank you for the review of= the draft. Indeed, no IANA actions requested in this specification. We'= ;ll keep the IANA Considerations section in place upon publication if RFC E= ditor agrees to that.

Regards,
Greg
<= br>
On Thu, Jun 14, 2018 at 2:28 PM, Sabrina Tana= mal via RT <drafts-lastcall@iana.org> wrote:
(BEGIN IANA COMMENTS)

IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-bfd-multipoint-active-tail-08, which is currently in Last Call, and has the following comment= s:

We understand that this document doesn't require any registry actions. =

While it's often helpful for a document's IANA Considerations secti= on to remain in place upon publication even if there are no actions, if the= authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

(END IANA COMMENTS)



--000000000000766a91056ee0ab2c-- From nobody Mon Jun 18 10:36:38 2018 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE6412872C; Mon, 18 Jun 2018 10:36:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-multipoint-18.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152934338865.3348.2054222505453232364@ietfa.amsl.com> Date: Mon, 18 Jun 2018 10:36:28 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 17:36:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection WG of the IETF. Title : BFD for Multipoint Networks Authors : Dave Katz Dave Ward Santosh Pallagatti Greg Mirsky Filename : draft-ietf-bfd-multipoint-18.txt Pages : 20 Date : 2018-06-18 Abstract: This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-multipoint-18 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-multipoint-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-18 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 Mon Jun 18 10:41:08 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0880F12872C; Mon, 18 Jun 2018 10:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 xRp56EHbjS-w; Mon, 18 Jun 2018 10:39:40 -0700 (PDT) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (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 5B6CD130DF6; Mon, 18 Jun 2018 10:39:39 -0700 (PDT) Received: by mail-lf0-x243.google.com with SMTP id x13-v6so10492071lff.10; Mon, 18 Jun 2018 10:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BRuJ+CJqiI7nhNRjR3FWMcNM9yr4ShhK/OlrUWBCetk=; b=dFEOLENp2/i5akUB1LKyEwMkHhAJSKOYN3DwGbAESKIwd8N6PwPrKezeZw5QHH6rrY G0mhH4zDxGMqx4vCosoTAMTzoHVd1wKX8NHpTeUGwgW0Q2bb7/ZZK2ZymaoysVlXVHJz 7Qcf6wF8J6jCGgqJG9xZBeN7q3CZzT+kHkUeYZZhUT9BWhyAGcAkkUWqEqFzjtp9c4WH M0UyabkvKchlqqGY8A86ZG5OGOMEk9Qj9nhFn3CGBo/ACqjGaF1PUooJsyU9qKB3oBRW tvjchUis5MKEtUxOwtY/2GlLaMvJk7cxuAI/m51ZBFbZQvO+EFO5JQ2SDOLS0mEP/dRL vOtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BRuJ+CJqiI7nhNRjR3FWMcNM9yr4ShhK/OlrUWBCetk=; b=a3dN3I4gsi8Y0pukbiXCV+Nh5wgxIz5SHcZfn1qoa+ppnpeFgd0PYx0LVO9Vwl3cue jmrPoqSDN2ldVHfVYp+6py1G08f2XGvQ/mxrYYhyUEZgGlflIfxP7Nsdsd3GZ/NfcPR5 Q8T6BHjWGlKU5SesD+AbQsM9u/nlPmB5tbh7NA1TTGrq/fXpydEFKyJ8Cf+lAqd6sU8F eeWl+Bf5l+4emSm7IMqjsKp9ffAJZgKKm+AzRPwc72ZyxROzNUaNO2VW7jU8UeGbbZrw Ug0nn+TgJgFQTdh4DHJqtJnF5+/X+NlYLnbh5IMBAoAWsIXdUxhoak8pvtwicgq69TP8 rWgA== X-Gm-Message-State: APt69E2+Qcn5F+29EkpTm3V7dVsV/KLxVjm7RbzE4HXp40WY8J5H4C51 pRzIgQbZ98g/m/oO8gcxjB9MTuSVqG405BjcYMQ= X-Google-Smtp-Source: ADUXVKJtivGN1+yspyU3QUKLRUlnbN1rbmCQRj4P9H3jH7YxQJOFvsPFH0EiuAKbBgj4SrBXAk+KmZkqTxiBIrbSadI= X-Received: by 2002:a2e:1b0a:: with SMTP id b10-v6mr8772143ljb.76.1529343577226; Mon, 18 Jun 2018 10:39:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Mon, 18 Jun 2018 10:39:36 -0700 (PDT) In-Reply-To: <4d67197f-7728-d226-66b0-7d188a995148@bobbriscoe.net> References: <152694840016.8083.12174100605609215107@ietfa.amsl.com> <1afa9af2-9fce-1588-ca09-cd39f1122688@bobbriscoe.net> <4a8bd1a3-3cfc-9c9c-c2cd-d0f8467da2c8@bobbriscoe.net> <4d67197f-7728-d226-66b0-7d188a995148@bobbriscoe.net> From: Greg Mirsky Date: Mon, 18 Jun 2018 10:39:36 -0700 Message-ID: Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-bfd-multipoint-16 To: Bob Briscoe Cc: draft-ietf-bfd-multipoint.all@ietf.org, tsv-art@ietf.org, rtg-bfd@ietf.org, IETF list Content-Type: multipart/alternative; boundary="000000000000a902f9056eee0c11" Archived-At: X-Mailman-Approved-At: Mon, 18 Jun 2018 10:41:02 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 17:39:49 -0000 --000000000000a902f9056eee0c11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bob, many thanks for the comments and the discussion. The new update has been published to address your latest suggestions. Regards, Greg On Mon, Jun 11, 2018 at 2:47 PM, Bob Briscoe wrote: > Greg, > > I may be wrong, in which case fine. > But I'll take each case in turn (there may not be security problems with > all, but a problem with just one would still be of concern): > > Multicast: > If there is an SSM tree from host A to multicast address G, I am not > familiar enough with SSM to know what happens when host B sends a packet = to > G with source address A (i.e. spoofing A). I assume the IGMP messages bui= ld > the tree back from each member to A, so usually there will be no route fr= om > B, even if it is spoofing A as the source. However, I would have thought > that a host connected to the same router as A could spoof A and get onto > the SSM tree. Or does SSM always check for this type of spoofing? > > Directly connected. > As with multicast, even tho not every machine on the Internet could spoof > the source address, surely if the link were a shared link (which is impli= ed > in this use-case) any machine on the shared link could spoof the genuine > source. > > MPLS > I think the MPLS case is safe, cos at each hop the label switched path is > specific to each prior hop. > > As I said, I may be wrong. > But, if either of the first two cases have a vulnerability in certain > cases, it ought to be described in the draft, even if the vulnerability i= s > confined to a specific set of circumstances. > > > Bob > > > On 11/06/18 19:14, Greg Mirsky wrote: > > Hi Bob, > thank you for the most thoughtful and helpful comments. It was not my > intention to pull you into re-designing of the specification. I've accept= ed > all the editorial updates, applied them to the new working version. > > I have to admit that I'm bit confused that you see lack of 3WHS in > mpBFD as the significantly increased risk of the spoofing attack on leave= s. > The BFD Control packet is expected to be received by a leave from one of > the following: > > - multicast path; > - directly connected; > - p2mp/mp2mp MPLS LSP. > > For the first scenario, as I understand, a host must first use multicast > control protocol to join the multicast path. > For the second - it is reasonable to assume, as in VRRP and PIM-SM drafts > I've referenced earlier, that BFD control packet be required to have IP T= TL > =3D=3D 1 and mcast IP address of link scope. > And the third, I think, is similar to #1 above. > > If these considerations are technically accurate, I'll work on the text > for Assumptions section. > > Regards, > Greg > > > On Thu, Jun 7, 2018 at 5:02 PM, Bob Briscoe wrote: > >> Greg, >> >> Your responses are AOK now. >> >> *Remaining Security Vulnerability* >> >> I think you may have misunderstood my point about vulnerability to sourc= e >> address spoofing without a 3WHS. When you said in response: >> >> >> Would you suggest additional text to a use case where the new >> demultiplexing is not sufficent to protect from source address spoofing? >> >> >> I said: >> >> [BB]: I seem to have become co-opted into redesigning this protocol. I'd >> prefer to limit my involvement to reviewing :) >> >> >> If this wasn't clear, I meant, "I believe this protocol has a security >> problem that needs to be fixed. But it's your job to fix it, not mine." >> >> If you can't fix it, I suggested that you need to at least add a section >> listing all the limitations when a multipoint scheme has no back channel >> (the others being no feedback on timing control and no way to set up >> asymmetric authentication). >> >> >> Apologies, if the following is already obvious to you, but it is safer t= o >> be over-cautious: >> The text you originally quoted in response to my point about 3WHS uses >> the source address as part of the identification of a session. That is t= he >> problem (not a solution). If a malicious host M masquerading as the sour= ce >> S spoofs the source address of S in its packets, the tails will not be a= ble >> to tell that these packets are not from S. >> >> A 3WHS (e.g. as in TCP) is a simple way to address this vulnerability, b= y >> the tails using the routing system to send a packet to the location wher= e >> the source claims to be sending from. I.e. the tail returns a packet to >> address S with some random information in it (in TCP's case, the initial >> sequence number). If S genuinely initiated the handshake, it will reflec= t >> the random info to the tail in the 3rd way of the handshake. If M is >> masquerading as S, it will not receive the 2nd way of the handshake. And= it >> won't be able to spoof the 3rd way without the random info. >> >> Without a 3WHS, multipoint BFD does not check that the source address is >> genuine. >> >> >> *Some (mostly editorial) comments from scanning the diff:* >> >> In the intro, the para starting "As an option, the tail may notify the >> head..." is prerequisite info that needs to come before the para ending >> "even without the existence of some kind of a return path to the head." >> >> s/in the received by MultipointTail BFD Control packet/ >> /in the received MultipointTail BFD Control packet/ >> >> s/entire/the entire/ (twice) >> >> Section 6 (Assumptions) has no flow of logic between the new text and th= e >> pre-existing text. It would be better to switch the order of the paras. >> >> >> Otherwise, I think my comments are becoming increasingly less useful, so >> I'll stop. I don't know enough about the whole ecosystem around this dra= ft >> to be any more helpful, I think. >> >> >> Bob >> >> >> On 05/06/18 03:23, Greg Mirsky wrote: >> >> Hi Bob, >> thank you for further clarifications and the new ideas. Please find my >> follow-up in-line and tagger GIM2>>. >> I'll check for nits and grammar and will publish the new version shortly= . >> >> Regards, >> Greg >> >> On Tue, May 29, 2018 at 3:22 AM, Bob Briscoe > > wrote: >> >>> Greg, >>> >>> >>> On 26/05/18 20:49, Greg Mirsky wrote: >>> >>> Hi Bob, >>> thank you for the thorough review, detailed questions and helpful >>> comments. Please find my answers in-line and tagged GIM>>. >>> I've updated the working version of the draft based on your comments an= d >>> suggestions. Appreciate your feedback whether all questions have been >>> addressed. >>> Attached please find the diff of -16 and the working version and the >>> copy of the working version of the draft. >>> >>> Regards, >>> Greg >>> >>> On Mon, May 21, 2018 at 5:20 PM, Bob Briscoe >>> wrote: >>> >>>> Reviewer: Bob Briscoe >>>> Review result: Not Ready >>>> >>>> Altho this is a TSV-ART review, I did not find many transport-related >>>> issues to >>>> focus on, except a need to justify why lack of information for adaptin= g >>>> the >>>> transmit interval is not an issue. >>>> >>>> Nonetheless, I did find a few other non-trivial technical issues, >>>> including 2 >>>> security issues, enumerated below (I mis-spent some of my early >>>> research career >>>> working on a multicast session control and security, for which we used >>>> beaconing control channels). However, I only have passing prior >>>> knowledge of >>>> BFD, so my critique might be off-beam. >>>> >>>> =3D=3DMain Technical Concerns=3D=3D=3D >>>> >>>> 1/ Mandatory return path? >>>> RFC5880 is the base RFC that this draft updates. RFC5880 says that >>>> "unidirectional links" are in scope, but only as long as there is a >>>> return path. >>>> >>>> The introduction of this bfd-multipoint draft seems to contradict that= , >>>> making >>>> a return path optional: " >>>> As an option, the tail may notify the head of the lack of multipoin= t >>>> connectivity. Details of tail notification to the head are outside >>>> the scope of this document. >>>> " >>>> It's allowable for irrelevant details to be outside the scope, but >>>> surely it >>>> needs to be clear whether at least the existence of a return path is >>>> mandatory. >>>> >>> GIM>> Thank you for highlighting this issue. I think that the second >>> paragraph of Introduction is the appropriate place to note that this >>> mechanism does not require existence of a return path from tails to the >>> head. Would the following be acceptable: >>> NEW TEXT: >>> Use of BFD in >>> Demand mode enables a tail monitor availability of a multipoint path >>> even without the existence of some kind of a return path to the head= . >>> >>>> >>>> 2/ Mechanism for verifying connectivity, or not? >>>> The introduction seems to contradict itself: >>>> " >>>> As multipoint transmissions are inherently unidirectional, this >>>> mechanism purports only to verify this unidirectional connectivity. >>>> " >>>> " >>>> Term "connectivity" in this document is not being used in the conte= xt >>>> of connectivity verification in transport network but as an >>>> alternative to "continuity", i.e. existence of a forwarding path >>>> between the sender and the receiver. >>>> " >>>> How can this mechanism verify connectivity, but not be used in the >>>> context of >>>> connectivity verification in the transport network? >>>> >>> GIM>> This draft defines the base specification for multipoint BFD. In >>> order for multipoint BFD to support the transport-like connectivity >>> verification we need to do work similar to described in RFC 6428. >>> >>> [BB]: Caveat: I am having to talk in generalizations, cos I don't >>> actually know how you are going to get this protocol to work in a wide >>> range of circumstances, given inherent problems like multipoint feedbac= k >>> implosion {Note 1}. >>> >>> My point was that, having broken up the drafts in this way, this draft >>> on its own no longer defined a workable protocol. Therefore, it needed = some >>> references to other drafts (even if they are placeholders), so that the >>> extent of the pre-requisite collection of work is clear. The refs you g= ive >>> later go a long way to fixing this issue. >>> >>> If each pre-requisite protocol is intended to only represent one >>> example, the citation can say that and the ref can be informative. But = with >>> zero examples for all the prerequisite parts, all the reader sees is a >>> dismembered octopus, not a protocol. >>> >>> >>> >>>> 3/ Use case >>>> The introduction seems to be written rather academically. Surely, in >>>> cases >>>> where there is never a return path, only the tails will ever be able t= o >>>> verify >>>> connectivity. The head could continue transmitting BFD packets (and da= ta >>>> packets) for years without ever knowing whether it is connected to >>>> anything. >>>> Knowledge of connectivity is surely of little use if it excludes the >>>> link >>>> sender, which is the node that always controls routing. >>>> >>>> If there are scenarios where it is useful for tails but not the head t= o >>>> be able >>>> to verify connectivity, can you please give a concrete example? >>>> >>> GIM>> One example could be a multicast system with 1+1 protection. >>> Without multipoint BFD tails would not be able to detect the failure of= the >>> muticast path from the head. Other examples discussed in several drafts= : >>> >>> - BESS WG draft MVPN fast upstream failover >>> >>> - Individual draft BFD for Multipoint Networks and VRRP Use Case >>> >>> - Individual draft BFD for Multipoint Networks and PIM-SM Use Case >>> >>> >>> I am not sure how references to non-WG drafts affect the progress of >>> this document. Appreciate your suggestion. >>> >>> [BB]: In my experience, informative refs to non-WG drafts as use-cases >>> would be OK during doc development. However, if a non-WG draft fails to >>> proceed, its citation has to be removed later. So choose those that are >>> most likely to proceed. >>> >>> Nonetheless, if you cite some specs that turn this into a workable >>> protocol (see previous issue) use-cases might not be necessary. >>> >> GIM2>> I've added reference to use of this mechanism in BGP/MPLS MVPN. >> >>> >>> >>> >>> >>>> 4/ Interval adaptation >>>> Text is needed to describe why it is not an issue for the head to be >>>> unaware >>>> whether it needs to adapt its transmit interval. Otherwise, this seems >>>> potentially problematic. >>>> >>> GIM>> Very interesting, thank you. I wouldn't say that the case when a >>> tail cannot process incoming mpBFD control packets at the offered rate = is >>> entirely non-issue. Such scenario must be handled by the implementation= and >>> may be controlled by local policy, e.g., close the MultipointTail sessi= on. >>> >>> [BB]: Fair enough. >>> >>> In some scenarios, this issue will not necessarily be so unlikely tho: >>> * If asymmetric crypto is used to solve the group message authenticatio= n >>> problem (see later), the processing burden on any lightweight endpoints >>> might lead to message verification leaving less available processor >>> resource than needed for the host's other tasks. >>> * Each tail might be joined to a very large number of multipoint >>> sessions. >>> >>> Where would you suggest to add the text? >>> >>> I would suggest a new section listing potential issues when there is no >>> back channel. >>> >> GIM2>> I've tried to start the new section but decided to insert the not= e >> in the first paragraph of Timer Manipulation section. Hope that is >> acceptable. >> >>> >>> >>> >>> >>>> 5/ Inability to authenticate the sender with symmetric keys >>>> In unicast scenarios, symmetric keys can be used for message >>>> authentication, >>>> because each end knows there is only one other node with the shared >>>> key. But, >>>> in multipoint scenarios, all the tails would share the key, so a share= d >>>> key >>>> does not authenticate who sent the message - any tail can spoof the >>>> head from >>>> the viewpoint of the other tails. >>>> >>>> Therefore text is needed to say that: >>>> * multipoint message authentication is limited to cases where all tail= s >>>> are >>>> trusted not to spoof the head, if shared keys are used. * otherwise >>>> asymmetric >>>> message authentication would be needed, e.g. TESLA [RFC4082] >>>> >>> GIM>> Thank you for the suggested text. Would the Security >>> Considerations section be appropriate place: >>> >>> [BB]: Well, the point limits the applicability of the assumption about >>> security in 5. 'Assumptions', so this would fit well there. >>> Then "Security Considerations" should point to everywhere in the doc >>> that discusses security, such as this (to save time for security review= ers). >>> >>> NEW TEXT: >>> Use of shared keys to authenticate BFD Control packet in multipoint >>> scenarios is limited because tail can spoof the head from the >>> viewpoint of the other tails. Thus, if shared keys are used, all >>> tails MUST be trusted not to spoof the head. >>> >>> [BB]: Normally a MUST is applied to implementations. It would be rather >>> odd to require users/operators to satisfy a spec requirement, particula= rly >>> requiring them to trust each other. I think this should be written as a= n >>> applicability statement not a normative requirement. >>> >> GIM2>> I've adopted text suggested by Spencer and moved the paragraph to >> section Assumption. >> >>> >>> >>> Otherwise, asymmetric >>> message authentication would be needed, e.g., Timed Efficient Stream >>> Loss-Tolerant Authentication (TESLA) as described in [RFC4082]. >>> >>> >>> [BB]: If you are going to allow for cases where all tails are trusted >>> not to spoof the head, then the assumption written in section 5 is no >>> longer correct. >>> >>> [FYI, RFC4082 is only a generic description. Many RFCs have been writte= n >>> to authenticate specific protocols along TESLA lines.] >>> >>> >>>> A related nit: Section 5 says all tails are assumed to have a common >>>> authentication key. In cases with symmetric message authentication, >>>> surely the >>>> head also needs the same key. >>>> >>> GIM>> Thank you. Please check the updated text: >>> NEW TEXT: >>> If authentication is in use, the head and all tails must be >>> configured to have a common authentication key in order for the tail= s >>> to validate received the multipoint BFD Control packets. >>> >>> [BB]: Yup. Except delete "received the". >>> Also see above about whether this is now a correct assumption. >>> >> GIM2>> I think that s/must/may/ will keep the Assumption valid. >> >>> >>> >>> >>>> 6/ Source address spoofing >>>> A 3-way handshake makes a protocol robust against simple source addres= s >>>> spoofing. Without a 3WHS, surely the spec. needs to highlight this >>>> vulnerability or discuss ways to address it or why it is not an issue. >>>> >>> GIM>> Because mpBFD control packets cannot be demultiplexed by tail >>> based on the value of Your Discriminator field as per RFC 5880, >>> the new procedure outlined in Section 4.7: >>> IP and MPLS multipoint tails MUST demultiplex BFD packets based on a >>> combination of the source address, My Discriminator and the identity >>> of the multipoint tree which the Multipoint BFD Control packet was >>> received from. Together they uniquely identify the head of the >>> multipoint path. >>> and described in details in Section 4.13.2: >>> If the Multipoint (M) bit is set >>> >>> If the Your Discriminator field is nonzero, the packet MUST be >>> discarded. >>> >>> Select a session as based on source address, My Discriminator >>> and the identity of the multipoint tree which the Multipoint >>> BFD Control packet was received. If a session is found, and >>> bfd.SessionType is not MultipointTail, the packet MUST be >>> discarded. If a session is not found, a new session of type >>> MultipointTail MAY be created, or the packet MAY be discarded. >>> This choice is outside the scope of this specification. >>> >>> Would you suggest additional text to a use case where the new >>> demultiplexing is not sufficent to protect from source address spoofing= ? >>> >>> >>> [BB]: I seem to have become co-opted into redesigning this protocol. I'= d >>> prefer to limit my involvement to reviewing :) >>> >>> >>> >>>> 7/ Scope >>>> On eight occasions an issue is raised, but resolution is stated as >>>> outside the >>>> scope of this document. It is OK to limit the scope of a spec, for >>>> example to >>>> allow for multiple solutions to each issue. But at least one solution >>>> must >>>> already exist for each of these eight issues. So, at least one example >>>> solution >>>> ought to be cited in each case. If any issues are open, then this >>>> should not be >>>> on the standards track. >>>> >>>> It would be more useful to state why each issue is out of scope. This >>>> would be >>>> helped by stating from the start what the scope of the document is. >>>> >>> GIM>> I've listed all eight occasions with the explanation for each one= : >>> >>> 1. Details of tail notification to the head are outside the scope of >>> this document. - Notifications by tails addressed in >>> draft-ietf-bfd-multipoint-active-tail >>> . >>> Will add as informational reference. >>> >>> [BB]: Good. >>> >>> Nonetheless, given you have confirmed that a reverse path is optional, >>> the doc still needs to address the case where there is no reverse path. >>> >> GIM2>> Introduction notes: >> Use of BFD in Demand mode enables a tail monitor availability >> of a multipoint path even without the existence of some kind of a >> return path to the head. >> >> >>> {Note 1} For the active tail draft, you might find the following ideas >>> for scaling multipoint feedback useful: >>> >>> *Statistical feedback:* >>> Nonnenmacher, J=C3=B6. & Biersack, E.W., "Scalable Feedback for Large G= roups >>> ," IEEE/ACM Transactions o= n >>> Networking 7(3):375--386 (June 1999) >>> >>> FUHRMANN, T., AND WIDMER, J. "On the scaling of feedback algorithms for >>> very large multicast groups ," >>> Computer Communications 24, 5-6 (March 2001), 539 547; >>> WIDMER, J., AND FUHRMANN, T. Extremum feedback for very large multicast >>> groups. Tech. Rep. TR 12-2001, Prakfische Informatik IV, University of >>> Mannheim, Germany, May 2001. >>> >>> Also, anycast can be used to select different representative feedback >>> tails, e.g. for a certain time, which might overlap with the periods fo= r >>> which a few other tails are selected using subsequent anycasts. >>> >>> *Logical 'AND' feedback:* >>> Burbridge, T., Soppera, A., Briscoe, R. and Jacquet, A. "Method and >>> device for co-ordinating networked group members >>> " >>> Patent WO2004059479, (Jul 2004; Priority 24 Dec 2002) >>> [AFAICT this patent is still being maintained, so use of it in a >>> protocol would require an IPR declaration.] >>> >>> >>> >>> 1. Details of how the head keeps track of tails and how tails alert >>> their connectivity to the head are outside scope of this document. -= Same >>> as #1. >>> >>> [BB]: And my response is same as #1. >>> >>> >>> 1. Bootstrapping BFD session to multipoint MPLS LSP in case of >>> penultimate hop popping is outside the scope of this document. - It = may use >>> control plane as in MVPN draft. Will add as informational reference. >>> >>> [BB]: Good. >>> >>> >>> 1. Use of other types of encapsulation of the BFD control message >>> over multipoint LSP is outside the scope of this document. - This in >>> reference to ACH encapsulation that is discussed in >>> draft-mirsky-mpls-p2mp-bfd >>> . Should >>> it be added as informational reference? What would be the imacpt of >>> progressing this specification? >>> >>> [BB]: See earlier comment about citing individual drafts (I don't have >>> enough BFD knowledge to give a BFD-specific answer). >>> >>> Also, in my review I should also have said: when creating new >>> encapsulations, pls see the common transport issues related to >>> encapsulation: >>> https://trac.ietf.org/trac/tsv/wiki/tsvdir-common-issues#Tun >>> nelingprotocolsandTransportRelatedIssues >>> >>> >>> >>> 1. Change in the value of bfd.RequiredMinRxInterval is outside the >>> scope of this document. - Same as #1. >>> >>> [BB]: And my response is same as #1. >>> >>> >>> 1. If a session is not found, a new session of type MultipointTail >>> MAY be created, or the packet MAY be discarded. This choice is outsi= de the >>> scope of this specification. - I propose to add "based on local poli= cy" to >>> the last sentence. >>> >>> [BB]: On what basis will local policy decide? It's my job as a reviewer >>> to ensure that this spec does not contain any loose ends (open issues). >>> >> GIM2>> It could be based on the maximum number of MultipointTail session= s >> and number of active MultipointTail sessions on the node. I'd clarify it= as: >> This choice MAY be controlled by the local policy, e.g. maximum number >> of >> MultipointTail sessions and number of active MultipointTail sessions, >> and is outside the scope of this specification. >> >> >>> >>> >>> 1. The exact method of selection is application-specific and is thus >>> outside the scope of this specification. - This is copied from RFC 5= 880: >>> "The exact method of selection is application specific and is thus o= utside >>> the scope of this specification." as the section is to replace Secti= on >>> 6.8.6. >>> >>> [BB]: OK. >>> >>> >>> 1. If a matching session is not found, a new session of type >>> PointToPoint MAY be created, or the packet MAY be discarded. This ch= oice is >>> outside the scope of this specification. - Same as #6. >>> >>> >>> [BB]: And my response is same as #6. >>> [Sry, my embedded comments have broken your numbered list.] >>> >>> >>> >>> >>> >>> >>>> There is also one issue that is "for further discussion". Does this >>>> mean the >>>> document is not ready yet? >>>> >>> GIM>> I think that the question left for further discussion is >>> non-technical: >>> The semantic difference between Down and AdminDown state is for >>> further discussion. >>> I propose to remove the sentence altogether. >>> >>> [BB]: OK. >>> >>> >>> >>>> 8/ Incremental deployment >>>> >>>> Section 4.4.1. "New State Variable Values" defines bfd.SessionType = =3D >>>> PointToPoint as well as a couple of Multipoint alternatives. Presumabl= y >>>> this >>>> spec does not require all existing PointToPoint systems to support thi= s >>>> state >>>> value. Is the implication that only Multipoint systems that happen to >>>> be in >>>> PointToPoint mode should use this state? >>>> >>> GIM>> You're aboultely right, existing implementations of BFD don't nee= d >>> to support bfd.SessionType variable. Only implementations that support = the >>> base BFD, single-hop or multi-hop, and this specification, mpBFD, shoul= d >>> support bfd.SessionType and set it to PointToPoint value when BFD is in >>> single-hop or multi-hop mode. When in mpBFD mode, bfd.SessionType will = be >>> set to either MultipointHead or MultipointClient. >>> >>> [BB]: Doesn't something need to be written (or referenced) to clarify >>> all this? AFAIR, this spec. never made clear that multipoint is a fork = in >>> implementations. >>> >> GIM2>> And so is S-BFD. (Note, bfd.SessionType introduced in RFC 7880 >> S-BFD but missed to define PointToPoint value). >> >>> >>> >>> >>> >>>> =3D=3DNits=3D=3D >>>> >>>> * Sometimes 'tree' is used to mean a multipoint path in general. I >>>> suspect >>>> 'path' was intended. >>>> >>> GIM>> I've found six occasions of "tree" and s/tree/path/ >>> >>>> >>>> 4.8. Packet consumption on tails >>>> s/Node/Nodes/ >>>> s/packet/packets/ >>>> s/demultiplex/demultiplexed/ >>>> >>> GIM>> Accepted all three. >>> >>>> >>>> 4.9. Bringing Up and Shutting Down Multipoint BFD Service >>>> " >>>> a newly >>>> started head (that does not have any previous state information >>>> available) SHOULD start with... >>>> " >>>> ... >>>> " >>>> ... (so long as the restarted head >>>> is using the same or a larger value of bfd.DesiredMinTxInterval tha= n >>>> it did previously). >>>> " >>>> If it has no state available, how can it know whether a value is large= r >>>> than >>>> previously? >>>> >>> GIM>> You are right, the BFD system at the head would not know the >>> previous value of bfd.DesiredMinTxInterval. This text is to caution >>> operator from decreasing bfd.DesiredMinTxInterval upon restart of the >>> BFD system. >>> >>>> >>>> 4.9. Bringing Up and Shutting Down Multipoint BFD Service >>>> There are a number of "SHOULD"s and "SHOULD NOT"s that do not state or >>>> give >>>> examples of circumstances in which the "SHOULD" would not be >>>> appropriate. If >>>> there are none, "MUST" would be more appropriate. >>>> >>> GIM>> In the first paragraph SHOULD may not be followed if the >>> implementation can differentiate between the very first start and resta= rts >>> of BFD system. If it is the first start of BFD system, the head MAY >>> directly progress to Up state skipping Down state. >>> The last paragraph describes graceful shuttdown. The head MAY shut the >>> BFD mp session abruptly by just stopping transmission of BFD Control >>> packets. >>> >>> [BB]: I assume you will say all this in the next rev, not just in this >>> email. >>> >> GIM2>> Appended the following: >> NEW TEXT: >> Alternatively, the head MAY stop transmitting BFD Control packets >> and not send any more BFD Control packets with the new state (Down or >> AdminDown). Tails >> will declare the multipoint session down only after the detection time >> interval runs out. >> >>> >>> >>> >>>> 4.10. Timer Manipulation >>>> " >>>> Because of the one-to-many mapping, a session of type MultipointHea= d >>>> SHOULD NOT initiate a Poll Sequence in conjunction with timer value >>>> changes. However, to indicate a change in the packets, >>>> MultipointHead session MUST send packets with the P bit set. >>>> MultipointTail session MUST NOT reply if the packet has M and P bit= s >>>> set and bfd.RequiredMinRxInterval set to 0. >>>> " >>>> The initial "SHOULD NOT" needs to be written another way. Perhaps >>>> " >>>> ...a session of type MultipointHead >>>> does not initiate a Poll Sequence >>>> " >>>> The head's normative action is defined by the following "MUST", then >>>> the tail's >>>> "MUST NOT reply" is what prevents the poll sequence happening. >>>> >>> GIM>> A Poll Sequence starts with the initiator setting Poll bit. Unles= s >>> the peer sends BFD Control packet with Finl bit set the poll sequence w= ould >>> continue indefinetely. The initial SHOULD NOT, in my opinion, correctly >>> points that the mechanism of Poll Sequence not to be used by Multipoint= Head >>> when changing transmission interval. I think that MUST in the first >>> paragraph can be downgraded to MAY because the MultipointHead doesn't n= eed >>> to use transition period when changing the transmission interval to low= er >>> level, i.e., decreasing frequency. May I propose the following: >>> OLD TEXT: >>> Because of the one-to-many mapping, a session of type MultipointHead >>> SHOULD NOT initiate a Poll Sequence in conjunction with timer value >>> changes. However, to indicate a change in the packets, >>> MultipointHead session MUST send packets with the P bit set. >>> NEW TEXT: >>> Because of the one-to-many mapping, a session of type MultipointHead >>> SHOULD NOT initiate a Poll Sequence in conjunction with timer value >>> changes. However, to indicate a change in the packets, >>> MultipointHead session MAY send packets with the P bit set during >>> transition period. >>> >>> [BB]: If I were an implementer, I would not know what this is saying I >>> ought to implement. The spec needs to answer this question: If the head >>> changes the packets what happens differently if it sets the P bit vs. i= f it >>> doesn't? >>> >> GIM2>> I think we can expect that the implementer is familiar with RFC >> 5880 and, very likely, has implemented it one or more times already. >> >>> >>> >>>> 4.11. Detection Times >>>> Delete "in the calculation" (repetition). >>>> >>> GIM>> Done. >>> >>>> >>>> 4.13.1. Reception of BFD Control Packets >>>> Some actions seem to be only relevant to PointToPoint sessions, but >>>> they are >>>> stated for all session types. Specifically: "the transmission of Echo >>>> packets, >>>> if any, MUST cease." "the Poll Sequence MUST be terminated." "MUST >>>> cease the >>>> periodic transmission of BFD Control packets" "MUST send periodic BFD >>>> Control >>>> packets" >>>> >>>> " >>>> If bfd.SessionType is PointToPoint, update the Detection Time as >>>> described in section 6.8..4 of [RFC5880]. If bfd.SessionType is >>>> MultipointTail, >>>> " >>>> The second sentence above ought to start on a new line as an Else if. >>>> >>> GIM>> Hope I got it right: >>> If bfd.SessionType is PointToPoint, update the Detection Time as >>> described in section 6.8.4 of [RFC5880]. >>> >>> Else >>> >>> If bfd.SessionType is MultipointTail, then update the Detectio= n >>> Time as the product of the last received values of Desired Min >>> TX Interval and Detect Mult, as described in Section 5.11 of >>> this specification. >>> >>>> >>>> 4.13.2. Demultiplexing BFD Control Packets >>>> " >>>> This section is part of the replacement for [RFC5880] section 6.8.6= , >>>> separated for clarity. >>>> " >>>> Do you mean "This section replaces the sentence: "If the Multipoint (M= ) >>>> bit is >>>> nonzero, the packet MUST be discarded." in [RFC5880] section 6.8.6? >>>> >>>> The statements under "If the Multipoint (M) bit is set" are not >>>> formatted like >>>> the rest of the if-else logic, and I think an Else is missing at the >>>> start of >>>> the statement after the nested "If".. >>>> >>> GIM>> Agree, the paragraph is not structured properly. How about this >>> formating: >>> If the Multipoint (M) bit is set >>> >>> If the Your Discriminator field is nonzero, the packet MUST be >>> discarded. >>> >>> Select a session as based on source address, My Discriminator >>> and the identity of the multipoint path which the Multipoint >>> BFD Control packet was received. >>> >>> If a session is found, and bfd.SessionType is not >>> MultipointTail, the packet MUST be discarded. >>> >>> Else >>> >>> If a session is not found, a new session of type >>> MultipointTail MAY be created, or the packet MAY be >>> discarded. This choice is outside the scope of this >>> specification. >>> >>> [BB]: As long as this represents the logic you want, fine. The point is >>> that the indentation is the only clue to whether one 'if' is conditiona= l on >>> a previous 'if', or not. >>> >>> HTH >>> >>> Bob >>> >>> >>> >>> >>> -- >>> ________________________________________________________________ >>> Bob Briscoe http://bobbriscoe.net/ >>> >>> >> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >> >> > > > _______________________________________________ > Tsv-art mailing listTsv-art@ietf.orghttps://www.ietf.org/mailman/listinfo= /tsv-art > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > --000000000000a902f9056eee0c11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bob,
many thanks for the comments and the discussio= n. = The new update has been published to address your latest suggestions.

Regards,
Greg

On Mon, Jun 11, 2018 at 2:47 PM, = Bob Briscoe <ietf@bobbriscoe.net> wrote:
=20 =20 =20
Greg,

I may be wrong, in which case fine.
But I'll take each case in turn (there may not be security problems with all, but a problem with just one would still be of concern):

Multicast:
If there is an SSM tree from host A to multicast address G, I am not familiar enough with SSM to know what happens when host B sends a packet to G with source address A (i.e. spoofing A). I assume the IGMP messages build the tree back from each member to A, so usually there will be no route from B, even if it is spoofing A as the source. However, I would have thought that a host connected to the same router as A could spoof A and get onto the SSM tree. Or does SSM always check for this type of spoofing?

Directly connected.
As with multicast, even tho not every machine on the Internet could spoof the source address, surely if the link were a shared link (which is implied in this use-case) any machine on the shared link could spoof the genuine source.

MPLS
I think the MPLS case is safe, cos at each hop the label switched path is specific to each prior hop.

As I said, I may be wrong.
But, if either of the first two cases have a vulnerability in certain cases, it ought to be described in the draft, even if the vulnerability is confined to a specific set of circumstances.


Bob


On 11/06/18 19:14, G= reg Mirsky wrote:
Hi Bob,
thank you for the most thoughtful and helpful comments. It was not my intention to pull you into re-designing of the specification. I've accepted all the editorial updates, applied them to the new working version.

I have to admit that I'm bit confused that you see lack of 3WHS in mpBFD=C2=A0as the significantly increased risk of the spoofing attack on leaves. The BFD Control packet=C2=A0is expecte= d to be received by a leave from one of the following:
  • multicast path;
  • directly connected;
  • p2mp/mp2mp MPLS LSP.
For the first scenario, as I understand, a host must first use multicast control protocol to join the multicast path.
For the second - it is reasonable to assume, as in VRRP and PIM-SM drafts I've referenced earlier, that BFD control packe= t be required to have IP TTL =3D=3D 1 and mcast=C2=A0IP address of link=C2=A0scope.
And the third, I think, is similar to #1 above.

If these considerations are technically accurate, I'll wor= k on the text for Assumptions section.

Regards,
Greg


On Thu, Jun 7, 2018 at 5:02 PM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
Greg,

Your responses are AOK now.

Remaining Security Vulnerability

I think you may have misunderstood my point about vulnerability to source address spoofing without a 3WHS. When you said in response:

Would you suggest additional text to a use case where the new demultiplexing is not sufficent to protect from source address spoofing?

 I said:
[BB]: I seem to have become co-opted into redesigning this protocol. I'd prefer t= o limit my involvement to reviewing :)

 If this wasn't clear, I meant, "I believe th= is protocol has a security problem that needs to be fixed. But it's your job to fix it, not mine."

If you can't fix it, I suggested that you need to at leas= t add a section listing all the limitations when a multipoint scheme has no back channel (the others being no feedback on timing control and no way to set up asymmetric authentication).


Apologies, if the following is already obvious to you, but it is safer to be over-cautious:
The text you originally quoted in response to my point about 3WHS uses the source address as part of the identification of a session. That is the problem (not a solution). If a malicious host M masquerading as the source S spoofs the source address of S in its packets, the tails will not be able to tell that these packets are not from S.

A 3WHS (e.g. as in TCP) is a simple way to address this vulnerability, by the tails using the routing system to send a packet to the location where the source claims to be sending from. I.e. the tail returns a packet to address S with some random information in it (in TCP's case, the initial sequence number). If S genuinely initiated the handshake, it will reflect the random info to the tail in the 3rd way of the handshake. If M is masquerading as S, it will not receive the 2nd way of the handshake. And it won't be able to spoof the 3rd way without the random info.

Without a 3WHS, multipoint BFD does not check that the source address is genuine.


Some (mostly editorial) comments from scanning the diff:

In the intro, the para starting "As an option, the tail may notify the head..." is prerequisite info that needs = to come before the para ending "even without the existence = of some kind of a return path to the head."

s/in the received by MultipointTail BFD Control packet/
=C2=A0/in the received MultipointTail BFD Control packet/

s/entire/the entire/ (twice)

Section 6 (Assumptions) has no flow of logic between the new text and the pre-existing text. It would be better to switch the order of the paras.


Otherwise, I think my comments are becoming increasingly less useful, so I'll stop. I don't know enough about = the whole ecosystem around this draft to be any more helpful, I think.


Bob


On 05/06/18 03:23, Greg Mirsky wrote:
Hi Bob,
thank you for further clarifications and the new ideas. Please find my follow-up in-line and tagger GIM2>>.
I'll check for nits and grammar and will publish the new version shortly.

Regards,
Greg

On Tue, May 29, 2018 at 3:22 AM, Bob Briscoe <ietf@bobbriscoe.net= > wrote:
Greg,


On 26/05/18 20:49, Greg Mirsky wrote:
Hi Bob,
thank you for the thorough review, detailed questions and helpful comments. Please find my answers in-line and tagged GIM>>.
I've updated the working version of the draft based on your comments and suggestions. Appreciate your feedback whether all questions have been addressed.
Attached please find the diff of -16 and the working version and the copy of the working version of the draft.

Regards,
Greg

On Mon, May 21, 2018 at 5:20 PM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
Reviewer: Bob Briscoe
Review result: Not Ready

Altho this is a TSV-ART review, I did not find many transport-related issues to
focus on, except a need to justify why lack of information for adapting the transmit interval is not an issue.

Nonetheless, I did find a few other non-trivial technical issues, including 2
security issues, enumerated below (I mis-spent some of my early research career
working on a multicast session control and security, for which we used
beaconing control channels). However, I only have passing prior knowledge of
BFD, so my critique might be off-beam.

=3D=3DMain Technical Concerns= =3D=3D=3D

1/ Mandatory return path?
RFC5880 is the base RFC that this draft updates. RFC5880 says that
"unidirectional links"= ; are in scope, but only as long as there is a return path.

The introduction of this bfd-multipoint draft seems to contradict that, making
a return path optional: "<= br> =C2=A0 =C2=A0As an option, the = tail may notify the head of the lack of multipoint
=C2=A0 =C2=A0connectivity.=C2= =A0 Details of tail notification to the head are outside
=C2=A0 =C2=A0the scope of this document.
"
It's allowable for irrelevant details to be outside the scope, but surely it
needs to be clear whether at least the existence of a return path is mandatory.
GIM>> Thank you for highlighting this issue. I think that the second paragraph of Introduction is the appropriate place to note that this mechanism does not require existence of a return path from tails to the head. Would the following be acceptable:
NEW TEXT:
=C2=A0 =C2=A0Use of BFD in=
=C2=A0 =C2=A0Demand mode e= nables a tail monitor availability of a multipoint path
=C2=A0 =C2=A0even without = the existence of some kind of a return path to the head.

2/ Mechanism for verifying connectivity, or not?
The introduction seems to contradict itself:
"
=C2=A0 =C2=A0As multipoint transmissions are inherently unidirectional, this
=C2=A0 =C2=A0mechanism purports= only to verify this unidirectional connectivity. "
"
=C2=A0 =C2=A0Term "connect= ivity" in this document is not being used in the context
=C2=A0 =C2=A0of connectivity verification in transport network but as an
=C2=A0 =C2=A0alternative to "continuity", i.e. ex= istence of a forwarding path
=C2=A0 =C2=A0between the sender= and the receiver.
"
How can this mechanism verify connectivity, but not be used in the context of
connectivity verification in the transport network?
GIM>> This draft defines the base specification for multipoint BFD. In order for multipoint BFD to support the transport-like connectivity verification we need to do work similar to described in RFC 6428.=C2=A0
[BB]: Caveat: I am having to talk in generalizations, cos I don't actually kno= w how you are going to get this protocol to work in a wide range of circumstances, given inherent problems like multipoint feedback implosion {Note 1}.

My point was that, having broken up the drafts in this way, this draft on its own no longer defined a workable protocol. Therefore, it needed some references to other drafts (even if they are placeholders), so that the extent of the pre-requisite collection of work is clear. The refs you give later go a long way to fixing this issue.

If each pre-requisite protocol is intended to only represent one example, the citation can say that and the ref can be informative. But with zero examples for all the prerequisite parts, all the reader sees is a dismembered octopus, not a protocol.



3/ Use case
The introduction seems to be written rather academically. Surely, in cases
where there is never a return path, only the tails will ever be able to verify
connectivity. The head could continue transmitting BFD packets (and data
packets) for years without ever knowing whether it is connected to anything.
Knowledge of connectivity is surely of little use if it excludes the link
sender, which is the node that always controls routing.

If there are scenarios where it is useful for tails but not the head to be able
to verify connectivity, can you please give a concrete example?
GIM>> One example could be a multicast system with 1+1 protection. Without multipoint BFD tails would not be able to detect the failure of the muticast path from the head. Other examples discussed in several drafts:
I am not sure how references to non-WG drafts affect the progress of this document. Appreciate your suggestion.
[BB]: In my experience, informative refs to non-WG drafts as use-cases would be OK during doc development. However, if a non-WG draft fails to proceed, its citation has to be removed later. So choose those that are most likely to proceed.

Nonetheless, if you cite some specs that turn this into a workable protocol (see previous issue) use-cases might not be necessary.
GIM2>> I've added reference to use of this mechanism in BGP/MPLS MVPN.=C2=A0




4/ Interval adaptation
Text is needed to describe why it is not an issue for the head to be unaware
whether it needs to adapt its transmit interval. Otherwise, this seems
potentially problematic.
GIM>> Very interesting, thank you. I wouldn't say that the case when a tail cannot process incoming mpBFD control packets at the offered rate is entirely non-issue. Such scenario must be handled by the implementation and may be controlled by local policy, e.g., close the MultipointTail session.
[BB]: Fair enough.

In some scenarios, this issue will not necessarily be so unlikely tho:
* If asymmetric crypto is used to solve the group message authentication problem (see later), the processing burden on any lightweight endpoints might lead to message verification leaving less available processor resource than needed for the host's other tasks.
* Each tail might be joined to a very large number of multipoint sessions.

Where would you suggest to add the text?
 I would suggest a new section listing potential issues when there is no back channel.
GIM2>> I've tried to start the new section but decided to insert the note in the first paragraph of Timer Manipulation section. Hope that is acceptable.=C2=A0




5/ Inability to authenticate the sender with symmetric keys In unicast scenarios, symmetric keys can be used for message authentication,
because each end knows there is only one other node with the shared key. But,
in multipoint scenarios, all the tails would share the key, so a shared key
does not authenticate who sent the message - any tail can spoof the head from
the viewpoint of the other tails.

Therefore text is needed to say that:
* multipoint message authentication is limited to cases where all tails are
trusted not to spoof the head, if shared keys are used. * otherwise asymmetric
message authentication would be needed, e.g. TESLA [RFC4082]
GIM>> Thank you for the suggested text. Would the Security Considerations section be appropriate place:
[BB]: Well, the point limits the applicability of the assumption about security in 5. 'Assumptions', so this would fit well there.
Then "Security Considerations" shou= ld point to everywhere in the doc that discusses security, such as this (to save time for security reviewers).

NEW TEXT:
=C2=A0 =C2=A0Use of shared k= eys to authenticate BFD Control packet in multipoint
=C2=A0 =C2=A0scenarios is li= mited because tail can spoof the head from the
=C2=A0 =C2=A0viewpoint of th= e other tails.=C2=A0 Thus, if shared ke= ys are used, all
=C2=A0 =C2=A0tails MUST be t= rusted not to spoof the head.=C2=A0
[BB]: Normally a MUST is applied to implementations. It would be rather odd to require users/operators to satisfy a spec requirement, particularly requiring them to trust each other. I think this should be written as an applicability statement not a normative requirement.
GIM2>> I've adopted text suggested by Spencer and moved the paragraph to section Assumption.


Otherwise, asymmetric
=C2=A0 =C2=A0message authent= ication would be needed, e.g., Timed Efficient Stream
=C2=A0 =C2=A0Loss-Tolerant Authentication (TESLA) as described in [RFC4082].

 [BB]: If you are going to allow for cases where all tails are trusted not to spoof the head, then the assumption written in section 5 is no longer correct.
[FYI, RFC4082 is only a generic description. Many RFCs have been written to authenticate specific protocols along TESLA lines.]


A related nit: Section 5 says all tails are assumed to have a common
authentication key. In cases with symmetric message authentication, surely the
head also needs the same key.
GIM>> Thank you. Please check the updated text:
NEW TEXT:
=C2=A0 =C2=A0If authentication= is in use, the head and all tails must be
=C2=A0 =C2=A0configured to hav= e a common authentication key in order for the tails
=C2=A0 =C2=A0to validate recei= ved the multipoint BFD Control packets.
[BB]: Yup. Except delete "receiv= ed the".
Also see above about whether this is now a correct assumption.
GIM2>> I think that s/must/may/ will keep the Assumption valid.=C2=A0



6/ Source address spoofing
A 3-way handshake makes a protocol robust against simple source address
spoofing. Without a 3WHS, surely the spec. needs to highlight this
vulnerability or discuss ways to address it or why it is not an issue.
GIM>> Because mpBFD control packets cannot be demultiplexed by=C2=A0 tail based on the value of Your Discriminator field as per RFC 5880,
the new procedure outlined in Section 4.7:
=C2=A0 =C2=A0IP and MPLS mul= tipoint tails MUST demultiplex BFD packets based on a
=C2=A0 =C2=A0combination of = the source address, My Discriminator and the identity
=C2=A0 =C2=A0of the multipoi= nt tree which the Multipoint BFD Control packet was
=C2=A0 =C2=A0received from.= =C2=A0 Together they uniquely identify the head of the
=C2=A0 =C2=A0multipoint path= .
and described in details in Section 4.13.2:
=C2=A0 =C2=A0 =C2=A0 If the = Multipoint (M) bit is set

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0If the Your Discriminator field is nonzero, the packet MUST be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0discarded.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Select a session as based on source address, My Discriminator
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0and the identity of the multipoint tree which the Multipoint
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0BFD Control packet was received.=C2=A0 If a session is found, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0bfd.SessionType is not MultipointTail, the packet MUST be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0discarded.=C2=A0 If a session is not found, a new session of type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0MultipointTail MAY be created, or the packet MAY be discarded.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0This choice is outside the scope of this specification.

Would you suggest additional text to a use case where the new demultiplexing is not sufficent to protect from source address spoofing?

[BB]: I seem to have become co-opted into redesigning this protocol. I'd prefer to limit my involvement to reviewing :)



7/ Scope
On eight occasions an issue is raised, but resolution is stated as outside the
scope of this document. It is OK to limit the scope of a spec, for example to
allow for multiple solutions to each issue. But at least one solution must
already exist for each of these eight issues. So, at least one example solution
ought to be cited in each case. If any issues are open, then this should not be
on the standards track.

It would be more useful to state why each issue is out of scope. This would be
helped by stating from the start what the scope of the document is.
GIM>> I've listed al= l eight occasions with the explanation for each one:
  1. Details of tail notification to the head are outside the scope of this document. - Notifications by tails addressed in=C2=A0draft-ietf-bfd-multipoint-active-tail. Will add as informational reference.
 [BB]: Good.

Nonetheless, given you have confirmed that a reverse path is optional, the doc still needs to address the case where there is no reverse path.
GIM2>> Introduction notes:
=C2=A0Use of BFD in Demand mode enables a ta= il monitor availability
=C2=A0of a multipoint path even without the existence of some kind of a
=C2=A0return path to the head.


{Note 1} For the active tail draft, you might find the following ideas for scaling multipoint feedback useful:

Statistical feedback:
Nonnenmacher, J=C3=B6. & Biersack, E.W., = "Scalable Feedback for Large Groups," IEEE/ACM Transactions on Networking 7(3):375--386 (June 1999)

FUHRMANN, T., AND WIDMER, J. "On the scaling of feedback algorithms for very large multicast groups," Computer Communications 24, 5-6 (March 2001), 539 547;
WIDMER, J., AND FUHRMANN, T. Extremum feedback for very large multicast groups. Tech. Rep. TR 12-2001, Prakfische Informatik IV, University of Mannheim, Germany, May 2001.

Also, anycast can be used to select different representative feedback tails, e.g. for a certain time, which might overlap with the periods for which a few other tails are selected using subsequent anycasts.

Logical 'AND' feedback:
Burbridge, T., Soppera, A., Briscoe, R. and Jacquet, A. "Method and device for co-ordinating networked group members" Patent WO2004059479= , (Jul 2004; Priority 24 Dec 2002)
[AFAICT this patent is still being maintained, so use of it in a protocol would require an IPR declaration.]


  1. Details of how the head keeps track of tails and how tails alert their connectivity to the head are outside scope of this document. - Same as #1.
 [BB]: And my response is same as #1.
  1. Bootstrapping BFD session to multipoint MPLS LSP in case of penultimate hop popping is outside the scope of this document. - It may use control plane as in MVPN draft. Will add as informational reference.
 [BB]: Good.
  1. Use of other types of encapsulation of the BFD control message over multipoint LSP is outside the scope of this document. - This in reference to ACH encapsulation that is discussed in=C2=A0draft-mirsky-mpls-p2mp-bfd. Should it be added as informational reference? What would be the imacpt of progressing this specification?
 [BB]: See earlier comment about citing individual drafts (I don't have enough BFD knowledge to give a BFD-specific answer).

Also, in my review I should also have said: when creating new encapsulations, pls see the common transport issues related to encapsulation:
https://trac.ietf.org/trac/tsv/wik= i/tsvdir-common-issues#TunnelingprotocolsandTransportRelatedIssue= s


  1. Change in the value of bfd.RequiredMinRxInterval is outside the scope of this document. - Same as #1.
 [BB]: And my response is same as #1.
  1. If a session is not found, a new session of type MultipointTail MAY be created, or the packet MAY be discarded. This choice is outside the scope of this specification. - I propose to add "based on local policy" to the las= t sentence.
 [BB]: On what basis will local policy decide? It's my job as a reviewer to ensure that this spec does not contain any loose ends (open issues).
GIM2>> It could be based on the maximum number of MultipointTail sessions and number of active MultipointTail sessions on the node. I'd clarify it as:
=C2=A0 This choice MAY be controlled by th= e local policy, e.g. maximum number of=C2=A0
=C2=A0 MultipointTail sessions and number = of active MultipointTail sessions,
=C2=A0 and is outside the scope of this specification.



  1. The exact method of selection is application-specific and is thus outside the scope of this specification. - This is copied from RFC 5880: "The exact method = of selection is application specific and is thus outside the scope of this specification." as the section is to replace Section 6.8.6.
 [BB]: OK.
  1. If a matching session is not found, a new session of type PointToPoint MAY be created, or the packet MAY be discarded. This choice is outside the scope of this specification. - Same as #6.

 [BB]: And my response is same as #6.
[Sry, my embedded comments have broken your numbered list.]


    =C2=A0

There is also one issue that is "for further discussion&q= uot;. Does this mean the
document is not ready yet?
GIM>> I think that the question left for further discussion is non-technical:
=C2=A0 =C2=A0The semantic diff= erence between Down and AdminDown state is for
=C2=A0 =C2=A0further discussio= n.=C2=A0
I propose to remove the sentence altogether.
 [BB]: OK.



8/ Incremental deployment

Section 4.4.1.=C2=A0 "New St= ate Variable Values" defines bfd.SessionType =3D
PointToPoint as well as a couple of Multipoint alternatives. Presumably this
spec does not require all existing PointToPoint systems to support this state
value. Is the implication that only Multipoint systems that happen to be in
PointToPoint mode should use this state?
GIM>> You're aboultely right, existing implementations of BFD don't need to support bfd.SessionType variable. Only implementations that support the base BFD, single-hop or multi-hop, and this specification, mpBFD, should support bfd.SessionType and set it to PointToPoint value when BFD is in single-hop or multi-hop mode. When in mpBFD mode, bfd.SessionType will be set to either MultipointHead or MultipointClient.
 [BB]: Doesn't something need to b= e written (or referenced) to clarify all this? AFAIR, this spec. never made clear that multipoint is a fork in implementations.
GIM2>> And so is S-BFD. (Note, bfd.SessionType introduced in RFC 7880 S-BFD but missed to define PointToPoint value).=C2=A0=




=3D=3DNits=3D=3D

* Sometimes 'tree' is u= sed to mean a multipoint path in general. I suspect
'path' was intended.
GIM>> I've found six occasions of "tree&quo= t; and s/tree/path/=C2=A0

4.8.=C2=A0 Packet consumption o= n tails
s/Node/Nodes/
s/packet/packets/
s/demultiplex/demultiplexed/
GIM>> Accepted all three.=C2=A0

4.9.=C2=A0 Bringing Up and Shutting Down Multipoint BFD Service
"
=C2=A0 =C2=A0a newly
=C2=A0 =C2=A0started head (that= does not have any previous state information
=C2=A0 =C2=A0available) SHOULD = start with...
"
...
"
=C2=A0 =C2=A0... (so long as th= e restarted head
=C2=A0 =C2=A0is using the same = or a larger value of bfd.DesiredMinTxInterval than
=C2=A0 =C2=A0it did previously)= .
"
If it has no state available, how can it know whether a value is larger than
previously?
GIM>> You are right, the BFD system at the head would not know the previous value of=C2=A0bfd.DesiredMinTxInterval. This text is to caution operator from decreasing=C2= =A0 bfd= .DesiredMinTxInterval upon restart of the BFD system.

4.9.=C2=A0 Bringing Up and Shutting Down Multipoint BFD Service
There are a number of "SHOULD"s and "S= HOULD NOT"s that do not state or give
examples of circumstances in which the "SHOULD" wo= uld not be appropriate. If
there are none, "MUST"= ; would be more appropriate.
GIM>> In the first paragraph SHOULD may not be followed if the implementation can differentiate between the very first start and restarts of BFD system. If it is the first start of BFD system, the head MAY directly progress to Up state skipping Down state.
The last paragraph describes graceful shuttdown. The head MAY shut the BFD mp session abruptly by just stopping transmission of BFD Control packets.
[BB]: I assume you will say all this in the next rev, not just in this email.
GIM2>> Appended the following:
NEW TEXT:
Alternatively, the head MAY stop transmitting BFD Control packets=C2=A0
and not send any more BFD Control packets with the new state (Down or AdminDown). Tails
will declare the multipoint session down only after the detection time interval runs out.=C2= =A0



4.10.=C2=A0 Timer Manipulation "
=C2=A0 =C2=A0Because of the one-t= o-many mapping, a session of type MultipointHead
=C2=A0 =C2=A0SHOULD NOT initiate = a Poll Sequence in conjunction with timer value
=C2=A0 =C2=A0changes.=C2=A0 Howev= er, to indicate a change in the packets,
=C2=A0 =C2=A0MultipointHead sessi= on MUST send packets with the P bit set.
=C2=A0 =C2=A0MultipointTail sessi= on MUST NOT reply if the packet has M and P bits
=C2=A0 =C2=A0set and bfd.RequiredMinRxInterval set to 0.
"
The initial "SHOULD NOT"= ; needs to be written another way. Perhaps
"
=C2=A0 =C2=A0...a session of type MultipointHead
=C2=A0 =C2=A0does not initiate a = Poll Sequence
"
The head's normative action i= s defined by the following "MUST", then the tail&#= 39;s
"MUST NOT reply" is wha= t prevents the poll sequence happening.
GIM>> A Poll Sequence starts with the initiator setting Poll bit. Unless the peer sends BFD Control packet with Finl bit set the poll sequence would continue indefinetely. The initial SHOULD NOT, in my opinion, correctly points that the mechanism of Poll Sequence not to be used by MultipointHead when changing transmission interval. I think that MUST in the first paragraph can be downgraded to MAY because the MultipointHead doesn't need t= o use transition period when changing the transmission interval to lower level, i.e., decreasing frequency. May I propose the following:
OLD TEXT:
=C2=A0 =C2=A0Because of the one-to-many mapping, a session of type MultipointHead
=C2=A0 =C2=A0SHOULD NOT init= iate a Poll Sequence in conjunction with timer value
=C2=A0 =C2=A0changes.=C2=A0 = However, to indicate a change in the packets,
=C2=A0 =C2=A0MultipointHead = session MUST send packets with the P bit set.
NEW TEXT:
=C2=A0 =C2=A0Because of the one-to-many mapping, a session of type MultipointHead
=C2=A0 =C2=A0SHOULD NOT init= iate a Poll Sequence in conjunction with timer value
=C2=A0 =C2=A0changes.=C2=A0 = However, to indicate a change in the packets,
=C2=A0 =C2=A0MultipointHead = session MAY send packets with the P bit set during transition period.
 [BB]: If I were an implementer, I would not know what this is saying I ought to implement. The spec needs to answer this question: If the head changes the packets what happens differently if it sets the P bit vs. if it doesn't?
GIM2>> I think we can expect that the implementer is familiar with RFC 5880 and, very likely, has implemented it one or more times already.=C2=A0


4.11.=C2=A0 Detection Times
Delete "in the calculation= " (repetition).
GIM>> Done.=C2=A0

4.13.1.=C2=A0 Reception of BFD Control Packets
Some actions seem to be only relevant to PointToPoint sessions, but they are
stated for all session types. Specifically: "the transmission of Echo packets,
if any, MUST cease." "= ;the Poll Sequence MUST be terminated." "MUST ce= ase the
periodic transmission of BFD Control packets" "MUS= T send periodic BFD Control
packets"

"
If bfd.SessionType is PointToPoint, update the Detection Time as
=C2=A0 =C2=A0 =C2=A0 described = in section 6.8..4 of [RFC5880].=C2=A0 If bfd.SessionType is
=C2=A0 =C2=A0 =C2=A0 Multipoint= Tail,
"
The second sentence above ought to start on a new line as an Else if.
GIM>> Hope I got it right:
=C2=A0 =C2=A0 =C2=A0 If bfd.= SessionType is PointToPoint, update the Detection Time as
=C2=A0 =C2=A0 =C2=A0 describ= ed in section 6.8.4 of [RFC5880].

=C2=A0 =C2=A0 =C2=A0 Else

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0If bfd.SessionType is MultipointTail, then update the Detection
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Time as the product of the last received values of Desired Min
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0TX Interval and Detect Mult, as described in Section 5.11 of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0this specification.=C2=A0

4.13.2.=C2=A0 Demultiplexing BF= D Control Packets
"
=C2=A0 =C2=A0This section is pa= rt of the replacement for [RFC5880] section 6.8.6,
=C2=A0 =C2=A0separated for clar= ity.
"
Do you mean "This section replaces the sentence: "If the Multipoint (M) bit is
nonzero, the packet MUST be discarded." in [RFC5880] section 6.8.6?

The statements under "If t= he Multipoint (M) bit is set" are not formatted like
the rest of the if-else logic, and I think an Else is missing at the start of
the statement after the nested "If"..
GIM>> Agree, the paragraph is not structured properly. How about this formating:
=C2=A0 =C2=A0 =C2=A0 If the = Multipoint (M) bit is set

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0If the Your Discriminator field is nonzero, the packet MUST be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0discarded.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Select a session as based on source address, My Discriminator
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0and the identity of the multipoint path which the Multipoint
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0BFD Control packet was received.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0If a session is found, and bfd.SessionType is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0MultipointTail, the packet MUST be discarded.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Else

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 If a session is not found, a new session of type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 MultipointTail MAY be created, or the packet MAY be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 discarded.=C2=A0 This choice is outside the scope of this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 specification.=C2=A0

[BB]: As long as this represents the logic you want, fine. The point is that the indentation is the only clue to whether one 'if' is conditional on a previous 'if', or not.

HTH

Bob




--=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
                                


--=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/



_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/m=
ailman/listinfo/tsv-art


--=20
________________________________________________________________
Bob Briscoe                               htt=
p://bobbriscoe.net/

--000000000000a902f9056eee0c11-- From nobody Mon Jun 18 11:02:28 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1F0130EFB; Mon, 18 Jun 2018 11:02:20 -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, 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 r4JTLclSL24p; Mon, 18 Jun 2018 11:02:19 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBC6130EE2; Mon, 18 Jun 2018 11:02:18 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8DC7D1E3D0; Mon, 18 Jun 2018 14:02:15 -0400 (EDT) Date: Mon, 18 Jun 2018 14:02:15 -0400 From: Jeffrey Haas To: Bob Briscoe Cc: Greg Mirsky , draft-ietf-bfd-multipoint.all@ietf.org, tsv-art@ietf.org, rtg-bfd@ietf.org, IETF list Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-bfd-multipoint-16 Message-ID: <20180618180215.GB30347@pfrc.org> References: <152694840016.8083.12174100605609215107@ietfa.amsl.com> <1afa9af2-9fce-1588-ca09-cd39f1122688@bobbriscoe.net> <4a8bd1a3-3cfc-9c9c-c2cd-d0f8467da2c8@bobbriscoe.net> <4d67197f-7728-d226-66b0-7d188a995148@bobbriscoe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4d67197f-7728-d226-66b0-7d188a995148@bobbriscoe.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 18:02:22 -0000 Bob, Addressing these specific points. (Note that I'm not a multicast expert.) On Mon, Jun 11, 2018 at 10:47:28PM +0100, Bob Briscoe wrote: > If there is an SSM tree from host A to multicast address G, I am not > familiar enough with SSM to know what happens when host B sends a > packet to G with source address A (i.e. spoofing A). I assume the > IGMP messages build the tree back from each member to A, so usually > there will be no route from B, even if it is spoofing A as the > source. However, I would have thought that a host connected to the > same router as A could spoof A and get onto the SSM tree. Or does > SSM always check for this type of spoofing? In general, when multicast traffic is forwarded, it is checked against the incoming interface to see if it should be forwarded or not. When it's against a valid IIF, it may be distributed out the outbound interface list for that tree. Traffic that doesn't match the IIF is dropped, I believe. A general problem with multicast is that hosts along the tree can inject spoofed traffic. BFD would have the same issue; it is not a new consideration. Your follow-up comment about MPLS is correct in that external injection is even more difficult without some other way to tunnel the labeled traffic to the tree. But once it's there, the same issue applies. -- Jeff P.S. Thanks, Greg, for handling the followup discussion. From nobody Mon Jun 18 12:25:33 2018 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 366B9130E30; Mon, 18 Jun 2018 12:25:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-multipoint-active-tail-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152934993220.3026.3691179843349471578@ietfa.amsl.com> Date: Mon, 18 Jun 2018 12:25:32 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 19:25:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection WG of the IETF. Title : BFD Multipoint Active Tails. Authors : Dave Katz Dave Ward Santosh Pallagatti Greg Mirsky Filename : draft-ietf-bfd-multipoint-active-tail-09.txt Pages : 19 Date : 2018-06-18 Abstract: This document describes active tail extensions to and updates the Bidirectional Forwarding Detection (BFD) protocol for multipoint networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-09 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-multipoint-active-tail-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-active-tail-09 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 Mon Jun 18 17:45:05 2018 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CE0130E64; Mon, 18 Jun 2018 17:44:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-yang-15.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152936909644.2709.14530396424757110889@ietfa.amsl.com> Date: Mon, 18 Jun 2018 17:44:56 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 00:44:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection WG of the IETF. Title : YANG Data Model for Bidirectional Forwarding Detection (BFD) Authors : Reshad Rahman Lianshu Zheng Mahesh Jethanandani Santosh Pallagatti Greg Mirsky Filename : draft-ietf-bfd-yang-15.txt Pages : 74 Date : 2018-06-18 Abstract: This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-yang-15 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-yang-15 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 Tue Jun 19 10:43:39 2018 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 519D312777C; Tue, 19 Jun 2018 10:43:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: lflynn@amsl.com, rtg-bfd@ietf.org, martin.vigoureux@nokia.com, bfd-chairs@ietf.org Subject: bfd - New Meeting Session Request for IETF 102 X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152943021829.32330.11170667863181322221.idtracker@ietfa.amsl.com> Date: Tue, 19 Jun 2018 10:43:38 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 17:43:38 -0000 A new meeting session request has just been submitted by Liz Flynn, on behalf of the bfd working group. --------------------------------------------------------- Working Group Name: Bidirectional Forwarding Detection Area Name: Routing Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: lisp bess rtgwg grow idr Second Priority: bier spring mpls teas pals sfc Third Priority: ccamp People who must be present: Jeffrey Haas Reshad Rahman Martin Vigoureux Alvaro Retana Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jun 19 10:51:38 2018 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 938401311AF; Tue, 19 Jun 2018 10:51:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: lflynn@amsl.com, rtg-bfd@ietf.org, martin.vigoureux@nokia.com, bfd-chairs@ietf.org Subject: bfd - Update to a Meeting Session Request for IETF 102 X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152943069452.32103.1504850801406320207.idtracker@ietfa.amsl.com> Date: Tue, 19 Jun 2018 10:51:34 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 17:51:35 -0000 An update to a meeting session request has just been submitted by Liz Flynn, on behalf of the bfd working group. --------------------------------------------------------- Working Group Name: Bidirectional Forwarding Detection Area Name: Routing Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: lisp bess rtgwg grow idr netconf netmod Second Priority: bier spring mpls teas pals sfc Third Priority: ccamp People who must be present: Jeffrey Haas Reshad Rahman Martin Vigoureux Alvaro Retana Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jun 19 10:51:52 2018 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF23E1311BD; Tue, 19 Jun 2018 10:51:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: lflynn@amsl.com, rtg-bfd@ietf.org, martin.vigoureux@nokia.com, bfd-chairs@ietf.org Subject: bfd - Update to a Meeting Session Request for IETF 102 X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152943070567.32553.15310579550407771924.idtracker@ietfa.amsl.com> Date: Tue, 19 Jun 2018 10:51:45 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 17:51:49 -0000 An update to a meeting session request has just been submitted by Liz Flynn, on behalf of the bfd working group. --------------------------------------------------------- Working Group Name: Bidirectional Forwarding Detection Area Name: Routing Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: idr grow rtgwg bess lisp netconf netmod Second Priority: bier spring mpls teas pals sfc Third Priority: ccamp People who must be present: Jeffrey Haas Reshad Rahman Martin Vigoureux Alvaro Retana Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jun 19 15:57:11 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBBC130FCD for ; Tue, 19 Jun 2018 15:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 p7xbHtEoO4xB for ; Tue, 19 Jun 2018 15:57:01 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 A654A130FD4 for ; Tue, 19 Jun 2018 15:57:00 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id t2-v6so1971548lfd.6 for ; Tue, 19 Jun 2018 15:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=N0qK0vbVyrtagZJC0wMirNzyTr+WpN/jBg+faW5W+0A=; b=eVGQSGpZlaRZDHtLvIeWOokb0ZAKmz9hNt487xXxYyPkvsSfNNXSYMKth6IFKpy185 tihSSUrsK5fVgLCl31tvbJZVYLnP5B20dlxZqDEOmVFEZ9mSJq1yg9FpTEvtMksA9c/0 h+MQOE+IC0PwxOm0piBeORN3gYUC4TqKByRkGY0PpSnb3DvkIM6bQtjbs947jp3LUSWF MECIn+oHiWGWutUDr7nq1idlzSfU1JJ4hLSRkOISgaEd0Tm+nl39+QFBxal2ToVsWgbP nVUmVTE3aiTwXVzv8l0GPSJmIQDhP4jHXROqz8niKDryu4Tf4iB5JrMBr2YSFOtrnX9F hnTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=N0qK0vbVyrtagZJC0wMirNzyTr+WpN/jBg+faW5W+0A=; b=ckMy+i3ChBwjzXnz3GAn0OWopoS1+7qNVxf7ee/gJfhqHth8O2u8KiLaga3lQ8qF90 9yWT9W/FMcnix0MR+BEoLWUQ0D4kFg4IClHVC2FihLhayzOY341Vw2ueC8gnFGlkqQCy PK3a7WRBVu6uqgBs5bhGp1FYmvl2OLWt3Rk6EtwVJ9n1rX65YH2alS2PF+FDD97q274m VpqgXYDP9B2QCZdZqXJISPfJN3OHIX9ncFtyZm6LdPhD9DZcacQE9fJ4RaSxQ00kYWIz JqcBf0VSLAczUsg9kPlJtxxFfY0VS6cqLs/NxAB+tScfRAQ9/FjH4Sfn+XXodSKZNlso 0rfg== X-Gm-Message-State: APt69E0YBxCQMkwmDi1Y6fMILKDLvUfe/eGegfuSYnice6l/w3E9v9qC 1D+qP33urGI7bIb6XO0V1zlvJaTIuSx2ouVNq8Q= X-Google-Smtp-Source: ADUXVKKzalaES/dSSAJvByRf+uE4+ZlASrSFV2oBnIEScZvF4IBLm2TUoIfwjRYIa/VTO8qICSo0PtsmgmSdl+UPri4= X-Received: by 2002:a2e:7c02:: with SMTP id x2-v6mr12226420ljc.71.1529449018594; Tue, 19 Jun 2018 15:56:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 15:56:57 -0700 (PDT) In-Reply-To: <152944864044.32330.3858680528319222422.idtracker@ietfa.amsl.com> References: <152944864044.32330.3858680528319222422.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Tue, 19 Jun 2018 15:56:57 -0700 Message-ID: Subject: Fwd: New Version Notification for draft-mirsky-bfd-mpls-demand-03.txt To: rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary="000000000000749978056f0699f8" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 22:57:04 -0000 --000000000000749978056f0699f8 Content-Type: text/plain; charset="UTF-8" Dear All, editorial cleanup in this update. Welcome your comments, questions. Regards, Greg ---------- Forwarded message ---------- From: Date: Tue, Jun 19, 2018 at 3:50 PM Subject: New Version Notification for draft-mirsky-bfd-mpls-demand-03.txt To: Gregory Mirsky A new version of I-D, draft-mirsky-bfd-mpls-demand-03.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-bfd-mpls-demand Revision: 03 Title: BFD in Demand Mode over Point-to-Point MPLS LSP Document date: 2018-06-19 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-mirsky-bfd-mpls- demand-03.txt Status: https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls- demand/ Htmlized: https://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-mirsky-bfd- mpls-demand Diff: https://www.ietf.org/rfcdiff?url2=draft-mirsky-bfd-mpls- demand-03 Abstract: This document describes procedures for using Bidirectional Forwarding Detection (BFD) in Demand mode to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-point Label Switched Paths. 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. The IETF Secretariat --000000000000749978056f0699f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
editorial cleanup in this update.
= Welcome your comments, questions.

Regards,
Greg
---------- Forwarded message --------= --
From: <internet-drafts@ietf.org>
Date: Tue, Jun 19, 2018 at 3:50 PM
Subject: New Version Notificati= on for draft-mirsky-bfd-mpls-demand-03.txt
To: Gregory Mirsky <gregimirsky@gmail.com>


A new version of I-D, draft-mirsky-bfd-mpls-demand-03.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-bfd-mpls-demand<= br> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BFD in Demand Mode over Point-to-P= oint MPLS LSP
Document date:=C2=A0 2018-06-19
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky-bf= d-mpls-demand-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/=
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-03
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mirsky-bfd-mpls-dem= and
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-mirsky-bfd-mpls= -demand-03

Abstract:
=C2=A0 =C2=A0This document describes procedures for using Bidirectional For= warding
=C2=A0 =C2=A0Detection (BFD) in Demand mode to detect data plane failures i= n
=C2=A0 =C2=A0Multiprotocol Label Switching (MPLS) point-to-point Label Swit= ched
=C2=A0 =C2=A0Paths.




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

The IETF Secretariat


--000000000000749978056f0699f8-- From nobody Wed Jun 20 09:46:27 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B33131059; Wed, 20 Jun 2018 09:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 GeNER8PlmdaM; Wed, 20 Jun 2018 09:46:24 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 2296E130DEF; Wed, 20 Jun 2018 09:46:24 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id s190-v6so112894qke.10; Wed, 20 Jun 2018 09:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=NRekK+k+eehwEmflpTIrxLeYdu+gkAZNRJgoHX/NLqo=; b=iToASNrY4zZqf+gEFMkMUrTT+nIOxeq4XzQS2UwXxM0R04olM5vH4QrRGKqxJ9m+m3 dcbJTQDUZ+w3lwWGGR5Jpvx5BcKyb7Cxa2DhE/6IX45Dyhu8ho6dC+FJCgVW3YBW8rV1 cKl1qcOtxmK8W60MbtEe5YRghXWiEDYTHQg5YXuknho2GZjTwmUVXbl9CiGIMb0M6qKH pozoUwVNZ0MlxpzCAAyeUgY5/jnKvBZjQ5NtVsDe1Y/yQz85kdWlymxPja33GPrgeX4J FUJguiCsOYM8nD1LlWWfEVc+WaQ/lsVqZP0c46SHP47OC23lgOaJEnIq/KUpkym8jTLX CBpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NRekK+k+eehwEmflpTIrxLeYdu+gkAZNRJgoHX/NLqo=; b=kh/ml6WGjBuUjaszmjKhXNGk9JGeQiMQxQQGx2hAx91GXIVAkqgNyjGQx0BGjyof33 84VbKt4+F8bYeQSYVTBnc48FUrz82ZjvBK3C+cHQfgqF67ney+W3dpQIdxBOLB8QiCfP MTz30o2Om/zphrVu7k99TumsWlPfeVKoP1FT4PIkQvbGgESBH52etgyD0VpCyBqo+Q2i MIBPdG/OgbIScvnvLSIMukuO5rliOxYuepIR5rIggl5nMHQOCzOv6sMHvUQJUzd176hY 5yqUF8sQfTWNOWIY6zT4pRyUjGBTAVZ3YStfpeqP7UX4IrW3B5c/bmlsYfA+P5H1vZ24 3UkA== X-Gm-Message-State: APt69E3/CDhsVlFfbOVn4JaY3hfYnnK2hibNyPNuGAfF/j+ee4ohM11Q 0HIq+uM5DqB8C7ZUYRy05JpVsdw1EdrtkMdLSa7kMA== X-Google-Smtp-Source: ADUXVKIB1154Zg4wH9i7f3gc1qqPa+ZiAlLURHXm7i9eYOrHCVTdfWEHMPUbcYvSEpAIkpf/SYXoY1lWsCXIzpiAWWI= X-Received: by 2002:ae9:c10d:: with SMTP id z13-v6mr18113158qki.359.1529513182973; Wed, 20 Jun 2018 09:46:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2fa4:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 09:46:02 -0700 (PDT) From: Chris Bowers Date: Wed, 20 Jun 2018 11:46:02 -0500 Message-ID: Subject: working group adoption poll for draft-mirsky-bfd-p2mp-vrrp-use-case To: RTGWG , rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary="000000000000f352f2056f15890d" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 16:46:27 -0000 --000000000000f352f2056f15890d Content-Type: text/plain; charset="UTF-8" RTGWG, The authors of draft-mirsky-bfd-p2mp-vrrp-use-case have requested that RTGWG adopt this draft as a WG document. https://datatracker.ietf.org/doc/draft-mirsky-bfd-p2mp-vrrp-use-case/ Please indicate whether or not you support adoption of the draft as a WG document. An explanation of why or why not is also very helpful. The two authors have already indicated that they know of no relevant IPR other than what has already been disclosed. The draft has two IPR disclosures. https://datatracker.ietf.org/ipr/3133/ https://datatracker.ietf.org/ipr/3135/ For some history related to this draft, please see: https://www.ietf.org/mail-archive/web/rtgwg/current/msg06572.html For information about IPR in IETF technology, see RFC 8179. https://datatracker.ietf.org/doc/rfc8179/ Note that one of the basic principles regarding how the IETF deals with IPR claims (from RFC 8179) is that: "The IETF will make no determination about the validity of any particular IPR claim." Since Jeff Tantsura is a co-author, he will not be involved in judging consensus. The closing date for this poll is Friday, July 6th. Thanks, Chris --000000000000f352f2056f15890d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
RTGWG,

The authors of draft-= mirsky-bfd-p2mp-vrrp-use-case have requested
that RTGWG adop= t this draft as a WG document.=C2=A0
Please indicate whether or not you support adoption of the draf= t
as a WG document.=C2=A0 An explanation of why or why not is= also very helpful.

The two authors have alrea= dy indicated that they know of no relevant IPR
other than wha= t has already been disclosed. The draft has two IPR disclosures.
<= div>https://datatracker.= ietf.org/ipr/3133/

For some history related to this draft, please see:

For information about IPR in IETF technology, see RFC 8179.
https://datatracker.ietf.org/doc/rfc8179/=

Note that one of the basic principles=20 regard= ing how the IETF deals with<= span style=3D"font-family:arial,helvetica,sans-serif"><= /span> IPR claims (from RFC 8179)
<= /div>
is that: "The IETF will mak= e no determination about the validity of any particular IPR claim."

Since Jeff Tantsura is a co-author, he will not be involved in = judging consensus.=C2=A0

The closing date for this poll is Frid= ay, July 6th.=C2=A0

Thanks,
Chris




=
--000000000000f352f2056f15890d-- From nobody Thu Jun 21 08:10:14 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAF112F1A6; Thu, 21 Jun 2018 08:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=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 Y5JUkTptoJmR; Thu, 21 Jun 2018 08:10:10 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD28130DE2; Thu, 21 Jun 2018 08:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16634; q=dns/txt; s=iport; t=1529593809; x=1530803409; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=0p8uI5PFuHY8ld/rjFh81FT4cdxx9d7TMYkrYHi+8BU=; b=W7K7cWNtEodZ8ECoP7EYTfClmQPLVXBXn/8+YEbE4kQ/kKXDkUXOzMpZ GjIyCalcJVyWv8WbRNp4u4SKujb8NTNBMaN/ztoZSYmy8duErXD1/pOna ueTsglZ5y5jVO+AwM8GLwN06Thg4tK4/Fsr3snQlfOLoqR6r1ux3Z/oe2 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAADLvitb/4QNJK1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJTdmJ/KAqDb4gEjECCBYglh1iFA4F5CyOESQIXgmUhNBg?= =?us-ascii?q?BAgEBAQEBAQJtHAyFKAEBAQEDI2YCAQgRAwECKwICAh8RHQgCBAESgyUBgRt?= =?us-ascii?q?MAxUPqjCCHIcNDYEsaAWIVIITgTaCaIJWQgIBAgGBPAEBPoJhMYIkAohDiQq?= =?us-ascii?q?HLSwJAoV7hgqDCYE/hAGIAYodTYZPAhETAYEkHTiBUnAVZQGCPAmLCIU+bwG?= =?us-ascii?q?NcoEfgRoBAQ?= X-IronPort-AV: E=Sophos;i="5.51,252,1526342400"; d="scan'208,217";a="132244022" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2018 15:10:08 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w5LFA8X9019170 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Jun 2018 15:10:08 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 21 Jun 2018 11:10:07 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Thu, 21 Jun 2018 11:10:07 -0400 From: "Acee Lindem (acee)" To: Chris Bowers , RTGWG , "rtg-bfd@ietf.org" Subject: Re: working group adoption poll for draft-mirsky-bfd-p2mp-vrrp-use-case Thread-Topic: working group adoption poll for draft-mirsky-bfd-p2mp-vrrp-use-case Thread-Index: AQHUCLZCLZC2WcBtykCJ8MG1S3BFTaRq0nSA Date: Thu, 21 Jun 2018 15:10:07 +0000 Message-ID: <8FF2E837-86A3-400F-85C1-2156D1AD7290@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.202] Content-Type: multipart/alternative; boundary="_000_8FF2E83786A3400F85C12156D1AD7290ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 15:10:13 -0000 --_000_8FF2E83786A3400F85C12156D1AD7290ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IFdHIGFkb3B0aW9uLg0KVGhhbmtzLA0KQWNlZQ0KDQpGcm9tOiBSdGctYmZkIDxy dGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBDaHJpcyBCb3dlcnMgPGNocmlz Ym93ZXJzLmlldGZAZ21haWwuY29tPg0KRGF0ZTogV2VkbmVzZGF5LCBKdW5lIDIwLCAyMDE4IGF0 IDEyOjQ2IFBNDQpUbzogUm91dGluZyBXRyA8cnRnd2dAaWV0Zi5vcmc+LCAicnRnLWJmZEBpZXRm Lm9yZyIgPHJ0Zy1iZmRAaWV0Zi5vcmc+DQpTdWJqZWN0OiB3b3JraW5nIGdyb3VwIGFkb3B0aW9u IHBvbGwgZm9yIGRyYWZ0LW1pcnNreS1iZmQtcDJtcC12cnJwLXVzZS1jYXNlDQoNClJUR1dHLA0K DQpUaGUgYXV0aG9ycyBvZiBkcmFmdC1taXJza3ktYmZkLXAybXAtdnJycC11c2UtY2FzZSBoYXZl IHJlcXVlc3RlZA0KdGhhdCBSVEdXRyBhZG9wdCB0aGlzIGRyYWZ0IGFzIGEgV0cgZG9jdW1lbnQu DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1taXJza3ktYmZkLXAybXAt dnJycC11c2UtY2FzZS8NCg0KUGxlYXNlIGluZGljYXRlIHdoZXRoZXIgb3Igbm90IHlvdSBzdXBw b3J0IGFkb3B0aW9uIG9mIHRoZSBkcmFmdA0KYXMgYSBXRyBkb2N1bWVudC4gIEFuIGV4cGxhbmF0 aW9uIG9mIHdoeSBvciB3aHkgbm90IGlzIGFsc28gdmVyeSBoZWxwZnVsLg0KDQpUaGUgdHdvIGF1 dGhvcnMgaGF2ZSBhbHJlYWR5IGluZGljYXRlZCB0aGF0IHRoZXkga25vdyBvZiBubyByZWxldmFu dCBJUFINCm90aGVyIHRoYW4gd2hhdCBoYXMgYWxyZWFkeSBiZWVuIGRpc2Nsb3NlZC4gVGhlIGRy YWZ0IGhhcyB0d28gSVBSIGRpc2Nsb3N1cmVzLg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9pcHIvMzEzMy8NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzMxMzUvDQoNCkZv ciBzb21lIGhpc3RvcnkgcmVsYXRlZCB0byB0aGlzIGRyYWZ0LCBwbGVhc2Ugc2VlOg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9ydGd3Zy9jdXJyZW50L21zZzA2NTcyLmh0 bWwNCg0KRm9yIGluZm9ybWF0aW9uIGFib3V0IElQUiBpbiBJRVRGIHRlY2hub2xvZ3ksIHNlZSBS RkMgODE3OS4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzgxNzkvDQoNCk5v dGUgdGhhdCBvbmUgb2YgdGhlIGJhc2ljIHByaW5jaXBsZXMgcmVnYXJkaW5nIGhvdyB0aGUgSUVU RiBkZWFscyB3aXRoIElQUiBjbGFpbXMgKGZyb20gUkZDIDgxNzkpDQppcyB0aGF0OiAiVGhlIElF VEYgd2lsbCBtYWtlIG5vIGRldGVybWluYXRpb24gYWJvdXQgdGhlIHZhbGlkaXR5IG9mIGFueSBw YXJ0aWN1bGFyIElQUiBjbGFpbS4iDQoNClNpbmNlIEplZmYgVGFudHN1cmEgaXMgYSBjby1hdXRo b3IsIGhlIHdpbGwgbm90IGJlIGludm9sdmVkIGluIGp1ZGdpbmcgY29uc2Vuc3VzLg0KDQpUaGUg Y2xvc2luZyBkYXRlIGZvciB0aGlzIHBvbGwgaXMgRnJpZGF5LCBKdWx5IDZ0aC4NCg0KVGhhbmtz LA0KQ2hyaXMNCg0KDQoNCg0K --_000_8FF2E83786A3400F85C12156D1AD7290ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxNi4wcHQiPkkgc3VwcG9ydCBXRyBhZG9wdGlvbi4gPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNi4w cHQiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdCI+QWNlZSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+UnRnLWJmZCAmbHQ7cnRnLWJmZC1i b3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgQ2hyaXMgQm93ZXJzICZsdDtjaHJpc2Jv d2Vycy5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBKdW5l IDIwLCAyMDE4IGF0IDEyOjQ2IFBNPGJyPg0KPGI+VG86IDwvYj5Sb3V0aW5nIFdHICZsdDtydGd3 Z0BpZXRmLm9yZyZndDssICZxdW90O3J0Zy1iZmRAaWV0Zi5vcmcmcXVvdDsgJmx0O3J0Zy1iZmRA aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPndvcmtpbmcgZ3JvdXAgYWRvcHRpb24g cG9sbCBmb3IgZHJhZnQtbWlyc2t5LWJmZC1wMm1wLXZycnAtdXNlLWNhc2U8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxhIG5hbWU9 Il9NYWlsT3JpZ2luYWxCb2R5Ij5SVEdXRyw8bzpwPjwvbzpwPjwvYT48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPlRoZSBhdXRob3JzIG9mIGRyYWZ0LW1pcnNreS1iZmQtcDJtcC12cnJwLXVzZS1jYXNlIGhh dmUgcmVxdWVzdGVkDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+dGhhdCBSVEdXRyBhZG9wdCB0aGlzIGRyYWZ0 IGFzIGEgV0cgZG9jdW1lbnQuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1pcnNreS1iZmQtcDJtcC12 cnJwLXVzZS1jYXNlLyI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWlyc2t5LWJmZC1wMm1w LXZycnAtdXNlLWNhc2UvPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5QbGVhc2UgaW5k aWNhdGUgd2hldGhlciBvciBub3QgeW91IHN1cHBvcnQgYWRvcHRpb24gb2YgdGhlIGRyYWZ0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPmFzIGEgV0cgZG9jdW1lbnQuJm5ic3A7IEFuIGV4cGxhbmF0aW9uIG9mIHdo eSBvciB3aHkgbm90IGlzIGFsc28gdmVyeSBoZWxwZnVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+VGhlIHR3byBhdXRob3JzIGhhdmUgYWxyZWFkeSBpbmRpY2F0ZWQgdGhh dCB0aGV5IGtub3cgb2Ygbm8gcmVsZXZhbnQgSVBSPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPm90aGVyIHRoYW4g d2hhdCBoYXMgYWxyZWFkeSBiZWVuIGRpc2Nsb3NlZC4gVGhlIGRyYWZ0IGhhcyB0d28gSVBSIGRp c2Nsb3N1cmVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9pcHIvMzEzMy8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzMxMzMvPC9zcGFu PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjwvc3Bhbj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8zMTM1 LyI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMzEzNS88L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPkZvciBzb21lIGhpc3RvcnkgcmVsYXRlZCB0byB0aGlzIGRyYWZ0LCBwbGVhc2Ugc2VlOg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL3J0Z3dnL2N1cnJlbnQvbXNnMDY1NzIuaHRtbCI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9ydGd3Zy9jdXJyZW50L21zZzA2NTcyLmh0bWw8L3NwYW4+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPkZvciBpbmZvcm1hdGlvbiBhYm91dA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij5JUFIgaW4gSUVURiB0ZWNobm9sb2d5LCBzZWUgUkZDIDgxNzkuPC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzgx NzkvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv cmZjODE3OS88L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Tm90ZSB0aGF0IG9uZSBvZiB0aGUgYmFzaWMgcHJpbmNpcGxl cw0KPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+cmVnYXJkaW5nIGhvdyB0aGUgSUVURiBkZWFscyB3aXRoPC9zcGFuPjwvc3Bhbj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+IElQUiBjbGFpbXMgKGZyb20gUkZDIDgxNzkpPC9zcGFuPjwvc3Bhbj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmlzIHRoYXQ6DQo8L3NwYW4+PC9zcGFuPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZxdW90O1RoZSBJRVRG IHdpbGwgbWFrZSBubyBkZXRlcm1pbmF0aW9uIGFib3V0IHRoZSB2YWxpZGl0eSBvZiBhbnkgcGFy dGljdWxhciBJUFIgY2xhaW0uPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mcXVvdDsNCjwvc3Bh bj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+U2luY2UgSmVmZiBUYW50c3VyYSBpcyBhIGNvLWF1dGhvciwgaGUgd2lsbCBub3Qg YmUgaW52b2x2ZWQgaW4ganVkZ2luZyBjb25zZW5zdXMuJm5ic3A7DQo8L3NwYW4+PC9zcGFuPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRo ZSBjbG9zaW5nIGRhdGUgZm9yIHRoaXMgcG9sbCBpcyBGcmlkYXksIEp1bHkgNnRoLiZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij5UaGFua3MsPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPkNocmlzPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_8FF2E83786A3400F85C12156D1AD7290ciscocom_-- From nobody Thu Jun 21 14:24:58 2018 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AD0130E1C; Thu, 21 Jun 2018 14:24:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-yang-16.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152961629271.31829.3508979803469442606@ietfa.amsl.com> Date: Thu, 21 Jun 2018 14:24:52 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 21:24:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection WG of the IETF. Title : YANG Data Model for Bidirectional Forwarding Detection (BFD) Authors : Reshad Rahman Lianshu Zheng Mahesh Jethanandani Santosh Pallagatti Greg Mirsky Filename : draft-ietf-bfd-yang-16.txt Pages : 77 Date : 2018-06-21 Abstract: This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-yang-16 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-yang-16 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 Mon Jun 25 06:34:28 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BC4130DF0; Mon, 25 Jun 2018 06:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 YYKGVA43TaFh; Mon, 25 Jun 2018 06:34:21 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D904E124D68; Mon, 25 Jun 2018 06:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4744; q=dns/txt; s=iport; t=1529933660; x=1531143260; h=from:to:cc:subject:date:message-id:mime-version; bh=vp9UvfTIB9DSlZVrZKcfpeP6IuZrkoh1LSvgqfose5k=; b=W+HY8lErMApxchg/X4M8N0En6GnmFBn2geDpcfJ+s9NMVowKJfEuIZKM uRKbMl2wsuFPDM/0qJAgliOQqU/80jObvmtE9avTM/GAFNUtOYe/G5B3r jfw+eVZYxh5O9XTL1656bwaZK2zps/bHxZlTYsfwyp5dwh0dKxeEadngd k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAADY7jBb/4cNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJTdmJ/KAqDb4gEjEGSDIUDgXoLLIRAGYJzITQYAQIBAQE?= =?us-ascii?q?BAQECbR0LhVJWEgEMOwMCBDAUEwQOBYMlAYEbZKsLghyEW4NngQKIbIFWP4E?= =?us-ascii?q?2hCmGOjGCJAKZLwkCjw+BQIQGiAORRgIREwGBJB04gVJwFWUBgj6CL44ib4E?= =?us-ascii?q?VjBoBgRkBAQ?= X-IronPort-AV: E=Sophos;i="5.51,270,1526342400"; d="scan'208,217";a="414963708" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jun 2018 13:34:20 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w5PDYKkY031176 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Jun 2018 13:34:20 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 25 Jun 2018 08:34:19 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1320.000; Mon, 25 Jun 2018 08:34:19 -0500 From: "Reshad Rahman (rrahman)" To: "rtg-bfd@ietf.org" CC: "bfd-chairs@ietf.org" Subject: IETF102 BFD WG agenda items Thread-Topic: IETF102 BFD WG agenda items Thread-Index: AQHUDIk4pvhBR5Utw0C5MJ3L/pSRXA== Date: Mon, 25 Jun 2018 13:34:19 +0000 Message-ID: <37A0060B-5D22-4FAC-85EA-AF2BD15716F4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.100] Content-Type: multipart/alternative; boundary="_000_37A0060B5D224FAC85EAAF2BD15716F4ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 13:34:26 -0000 --_000_37A0060B5D224FAC85EAAF2BD15716F4ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgZXZlcnlvbmUsDQoNClRoZSBCRkQgV0cgaGFzIGEgdGltZSBzbG90IGR1cmluZyBJRVRGMTAy IGluIE1vbnRyZWFsLCB3ZSBhcmUgbWVldGluZyBvbiBXZWRuZXNkYXkgSnVseSAxOHRoIDIwMTgg ZnJvbSAxNToyMCB0byAxNjo1MC4NCg0KUGxlYXNlIHNlbmQgeW91ciByZXF1ZXN0cyBmb3IgYWdl bmRhIGl0ZW1zIChwcmVzZW50ZXIsIGRyYWZ0LCB0aW1lIHJlcXVlc3RlZCkgdG8gYmZkLWNoYWly c0BpZXRmLm9yZzxtYWlsdG86YmZkLWNoYWlyc0BpZXRmLm9yZz4sIG5vIGxhdGVyIHRoYW4gTW9u ZGF5IEp1bHkgOXRoIDIwMTguDQoNClJlZ2FyZHMsDQpSZXNoYWQgJiBKZWZmLg0KDQo= --_000_37A0060B5D224FAC85EAAF2BD15716F4ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <828ABF7B421389488758135EB21A725E@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsN Cglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28t c3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQ0Ei IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ SGkgZXZlcnlvbmUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjpibGFjayI+VGhlIEJGRCBXRyBoYXMgYSB0aW1lIHNsb3QgZHVyaW5n IElFVEYxMDIgaW4gTW9udHJlYWwsIHdlIGFyZSBtZWV0aW5nIG9uIFdlZG5lc2RheSBKdWx5IDE4 dGggMjAxOCBmcm9tIDE1OjIwIHRvIDE2OjUwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OmJsYWNrIj5QbGVhc2Ugc2VuZCB5b3VyIHJlcXVlc3RzIGZvcjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5hZ2VuZGE8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+aXRlbXMgKHByZXNlbnRlciwgZHJhZnQsIHRpbWUg cmVxdWVzdGVkKSB0bzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJtYWlsdG86YmZkLWNoYWlyc0BpZXRmLm9yZyI+YmZkLWNoYWlyc0BpZXRm Lm9yZzwvYT4sDQogbm8gbGF0ZXIgdGhhbiBNb25kYXkgSnVseSA5dGggMjAxOC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlJlc2hhZCAmYW1wOyBKZWZmLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_37A0060B5D224FAC85EAAF2BD15716F4ciscocom_-- From nobody Mon Jun 25 22:17:41 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA47130EC6; Mon, 25 Jun 2018 22:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 rzQzbGI4ZEcN; Mon, 25 Jun 2018 22:17:23 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20617130E9B; Mon, 25 Jun 2018 22:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13044; q=dns/txt; s=iport; t=1529990243; x=1531199843; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GunRYBQ79cwg8f4zHigWGKMRBSGtDmraRnDJnIneiXU=; b=LW7gFWTP7hOHTgMUckcG76oaXOabi+jFLy985+pyosajhjHnDSo6uD+1 sNA8SuuMTcOfsWFm+7zytG2GK9Kn0mGxKlW0B6h/rra7KBOtdED3wU+O9 MsMA2lqSW80ZC64A5RSB7BmMmK+tArBqCOSiQ3X0insFww9xqdiSOJlfI M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C0AACWyzFb/4UNJK1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJTVwEBAQEhYn8oCoNviASMQoFliE2HX4UGgXoLI4RJAhe?= =?us-ascii?q?CdiE0GAECAQEBAQEBAm0cDIUpBiNWEAIBCD8DAgICHxEUEQIEDgWDJQGBG0w?= =?us-ascii?q?DFQ+sboIcH4ZxDYEsgRUFiGyBVj+BDgEnDIJcglZCAQECAYReMYIkApFVhy8?= =?us-ascii?q?sCQKFfIYKgwmBQIQGiAOKJU2GVQIREwGBJB04gVJwFWUBgj6CIxeIWYU+bwE?= =?us-ascii?q?BjlaBGgEB?= X-IronPort-AV: E=Sophos;i="5.51,273,1526342400"; d="scan'208,217";a="415295645" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2018 05:17:21 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w5Q5HKHC005023 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Jun 2018 05:17:21 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 26 Jun 2018 01:17:20 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1320.000; Tue, 26 Jun 2018 01:17:20 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: Bob Briscoe , "draft-ietf-bfd-multipoint.all@ietf.org" , "tsv-art@ietf.org" , "rtg-bfd@ietf.org" , IETF list Subject: Re: Tsvart last call review of draft-ietf-bfd-multipoint-16 Thread-Topic: Tsvart last call review of draft-ietf-bfd-multipoint-16 Thread-Index: AQHT/HRExw3CBwk62EGoYxhzIgZ7z6RyZA6A Date: Tue, 26 Jun 2018 05:17:20 +0000 Message-ID: <1A5DF3AA-ED83-4656-AB1B-E8CC9E721CE1@cisco.com> References: <152694840016.8083.12174100605609215107@ietfa.amsl.com> <1afa9af2-9fce-1588-ca09-cd39f1122688@bobbriscoe.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.133] Content-Type: multipart/alternative; boundary="_000_1A5DF3AAED834656AB1BE8CC9E721CE1ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 05:17:26 -0000 --_000_1A5DF3AAED834656AB1BE8CC9E721CE1ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZywNCg0KUGxlYXNlIGZpbmQgb25lIGxhdGUgZm9sbG93LXVwIGlubGluZS4NCg0KT24gSnVu IDQsIDIwMTgsIGF0IDEwOjIzIFBNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29t PG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PiB3cm90ZToNCg0KOC8gSW5jcmVtZW50YWwg ZGVwbG95bWVudA0KDQpTZWN0aW9uIDQuNC4xLiAgIk5ldyBTdGF0ZSBWYXJpYWJsZSBWYWx1ZXMi IGRlZmluZXMgYmZkLlNlc3Npb25UeXBlID0NClBvaW50VG9Qb2ludCBhcyB3ZWxsIGFzIGEgY291 cGxlIG9mIE11bHRpcG9pbnQgYWx0ZXJuYXRpdmVzLiBQcmVzdW1hYmx5IHRoaXMNCnNwZWMgZG9l cyBub3QgcmVxdWlyZSBhbGwgZXhpc3RpbmcgUG9pbnRUb1BvaW50IHN5c3RlbXMgdG8gc3VwcG9y dCB0aGlzIHN0YXRlDQp2YWx1ZS4gSXMgdGhlIGltcGxpY2F0aW9uIHRoYXQgb25seSBNdWx0aXBv aW50IHN5c3RlbXMgdGhhdCBoYXBwZW4gdG8gYmUgaW4NClBvaW50VG9Qb2ludCBtb2RlIHNob3Vs ZCB1c2UgdGhpcyBzdGF0ZT8NCkdJTT4+IFlvdSdyZSBhYm91bHRlbHkgcmlnaHQsIGV4aXN0aW5n IGltcGxlbWVudGF0aW9ucyBvZiBCRkQgZG9uJ3QgbmVlZCB0byBzdXBwb3J0IGJmZC5TZXNzaW9u VHlwZSB2YXJpYWJsZS4gT25seSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBzdXBwb3J0IHRoZSBiYXNl IEJGRCwgc2luZ2xlLWhvcCBvciBtdWx0aS1ob3AsIGFuZCB0aGlzIHNwZWNpZmljYXRpb24sIG1w QkZELCBzaG91bGQgc3VwcG9ydCBiZmQuU2Vzc2lvblR5cGUgYW5kIHNldCBpdCB0byBQb2ludFRv UG9pbnQgdmFsdWUgd2hlbiBCRkQgaXMgaW4gc2luZ2xlLWhvcCBvciBtdWx0aS1ob3AgbW9kZS4g V2hlbiBpbiBtcEJGRCBtb2RlLCBiZmQuU2Vzc2lvblR5cGUgd2lsbCBiZSBzZXQgdG8gZWl0aGVy IE11bHRpcG9pbnRIZWFkIG9yIE11bHRpcG9pbnRDbGllbnQuDQpbQkJdOiBEb2Vzbid0IHNvbWV0 aGluZyBuZWVkIHRvIGJlIHdyaXR0ZW4gKG9yIHJlZmVyZW5jZWQpIHRvIGNsYXJpZnkgYWxsIHRo aXM/IEFGQUlSLCB0aGlzIHNwZWMuIG5ldmVyIG1hZGUgY2xlYXIgdGhhdCBtdWx0aXBvaW50IGlz IGEgZm9yayBpbiBpbXBsZW1lbnRhdGlvbnMuDQpHSU0yPj4gQW5kIHNvIGlzIFMtQkZELiAoTm90 ZSwgYmZkLlNlc3Npb25UeXBlIGludHJvZHVjZWQgaW4gUkZDIDc4ODAgUy1CRkQgYnV0IG1pc3Nl ZCB0byBkZWZpbmUgUG9pbnRUb1BvaW50IHZhbHVlKS4NCg0KDQpJIGRvIG5vdCBiZWxpZXZlIHRo ZSBxdWVzdGlvbiB3YXMgd2hldGhlciBTLUJGRCBvciBhbnkgb3RoZXIgcHJvdG9jb2wgZm9sbG93 ZWQgdGhlIGJlaGF2aW9yLiBJdOKAmXMgYSBxdWVzdGlvbiBhYm91dCB0aGlzIGRvY3VtZW50Lg0K DQpGb3IgY29ycmVjdG5lc3MsIFMtQkZEIChSRkMgNzg4MCkgZGlkIG5vdCBtaXNzIHRvIGRlZmlu ZSBQb2ludFRvUG9pbnQgdmFsdWUg4oCUIGl0IGNob3NlIG5vdCB0by4NCg0KQmFjayB0byB0aGlz IGRvY3VtZW50LCB0aGUgcXVlc3Rpb24gd2FzIHdoZXRoZXIgc29tZXRoaW5nIG5lZWRzIHRvIGJl IHdyaXR0ZW4gdG8gY2xhcmlmeS4NCg0KVGhlIHRleHQgaW4gcmV2IC0xOCBzdGlsbCBuZWVkcyBj bGFyaWZpY2F0aW9uLiBJdCByZWFkczoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtYmZkLW11bHRpcG9pbnQtMTgjc2VjdGlvbi01LjQuMQ0KDQogICAgICBiZmQuU2Vz c2lvblR5cGUNCg0KICAgICAgICAgVGhlIHR5cGUgb2YgdGhpcyBzZXNzaW9uIGFzIGRlZmluZWQg aW4gW1JGQzc4ODBdLiAgTmV3bHkgYWRkZWQNCiAgICAgICAgIHZhbHVlcyBhcmU6DQoNCiAgICAg ICAgICAgIFBvaW50VG9Qb2ludDogQ2xhc3NpYyBwb2ludC10by1wb2ludCBCRkQsIGFzIGRlc2Ny aWJlZCBpbg0KICAgICAgICAgICAgW1JGQzU4ODBdLg0KDQogICAgICAgICAgICBNdWx0aXBvaW50 SGVhZDogQSBzZXNzaW9uIG9uIHRoZSBoZWFkIHJlc3BvbnNpYmxlIGZvciB0aGUNCiAgICAgICAg ICAgIHBlcmlvZGljIHRyYW5zbWlzc2lvbiBvZiBtdWx0aXBvaW50IEJGRCBDb250cm9sIHBhY2tl dHMNCiAgICAgICAgICAgIGFsb25nIHRoZSBtdWx0aXBvaW50IHBhdGguDQoNCiAgICAgICAgICAg IE11bHRpcG9pbnRUYWlsOiBBIG11bHRpcG9pbnQgc2Vzc2lvbiBvbiBhIHRhaWwuDQoNCiAgICAg ICAgIFRoaXMgdmFyaWFibGUgTVVTVCBiZSBpbml0aWFsaXplZCB0byB0aGUgYXBwcm9wcmlhdGUg dHlwZSB3aGVuDQogICAgICAgICB0aGUgc2Vzc2lvbiBpcyBjcmVhdGVkLg0KDQoNCkJhc2ljYWxs eSwgdGhlIHZhcmlhYmxlIE1VU1QgYmUgaW5pdGlhbGl6ZWQsIFBvaW50VG9Qb2ludCBpcyB1c2Vk IGZvciBSRkMgNTg4MCwgYW5kIHRoaXMgdGV4dCBlZmZlY3RpdmVseSByZW5kZXJzIGV2ZXJ5IGlt cGxlbWVudGF0aW9uIG9mIFJGQyA1ODgwIG5vbiBjb21wbGlhbnQuDQoNCkNvdWxkIHlvdSBwbGVh c2UgYWRkIHNvbWUgY2xhcmlmeWluZyB0ZXh0IHRoYXQgY29kaWZpZXMgd2hhdCB5b3UgZGVzY3Jp YmVkIGFib3ZlIChpLmUuLCBleGlzdGluZyBwMnAgdHJhZGl0aW9uYWwgQkZEIG9ubHkgZG8gbm90 IG5lZWQgdG8gc2V0IHRoZSB2YXJpYWJsZSkNCg0KVGhhbmtzIQ0KDQoNCuKAlA0KQ2FybG9zIFBp Z25hdGFybywgY2FybG9zQGNpc2NvLmNvbTxtYWlsdG86Y2FybG9zQGNpc2NvLmNvbT4NCg0K4oCc U29tZXRpbWVzIEkgdXNlIGJpZyB3b3JkcyB0aGF0IEkgZG8gbm90IGZ1bGx5IHVuZGVyc3RhbmQs IHRvIG1ha2UgbXlzZWxmIHNvdW5kIG1vcmUgcGhvdG9zeW50aGVzaXMuIg0K --_000_1A5DF3AAED834656AB1BE8CC9E721CE1ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkdyZWcsDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5QbGVhc2UgZmluZCBvbmUgbGF0ZSBmb2xsb3ct dXAgaW5saW5lLjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0 LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj5PbiBKdW4gNCwgMjAxOCwgYXQgMTA6MjMgUE0sIEdyZWcgTWlyc2t5 ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tIiBjbGFzcz0iIj5ncmVn aW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBj bGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOiAwcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9y ZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAy MDQpOyBwYWRkaW5nLWxlZnQ6IDFleDsiPg0KPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIiBjbGFzcz0i Ij48c3BhbiBjbGFzcz0iZ21haWwtIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6 IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBu b25lOyIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Imdt YWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxibG9ja3F1b3RlIGNsYXNz PSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0 LXN0eWxlOiBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFk ZGluZy1sZWZ0OiAxZXg7Ij4NCjgvIEluY3JlbWVudGFsIGRlcGxveW1lbnQ8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpTZWN0aW9uIDQuNC4xLiZuYnNwOyAmcXVvdDtOZXcgU3RhdGUgVmFy aWFibGUgVmFsdWVzJnF1b3Q7IGRlZmluZXMgYmZkLlNlc3Npb25UeXBlID08YnIgY2xhc3M9IiI+ DQpQb2ludFRvUG9pbnQgYXMgd2VsbCBhcyBhIGNvdXBsZSBvZiBNdWx0aXBvaW50IGFsdGVybmF0 aXZlcy4gUHJlc3VtYWJseSB0aGlzPGJyIGNsYXNzPSIiPg0Kc3BlYyBkb2VzIG5vdCByZXF1aXJl IGFsbCBleGlzdGluZyBQb2ludFRvUG9pbnQgc3lzdGVtcyB0byBzdXBwb3J0IHRoaXMgc3RhdGU8 YnIgY2xhc3M9IiI+DQp2YWx1ZS4gSXMgdGhlIGltcGxpY2F0aW9uIHRoYXQgb25seSBNdWx0aXBv aW50IHN5c3RlbXMgdGhhdCBoYXBwZW4gdG8gYmUgaW48YnIgY2xhc3M9IiI+DQpQb2ludFRvUG9p bnQgbW9kZSBzaG91bGQgdXNlIHRoaXMgc3RhdGU/PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdiBjbGFzcz0iIj5HSU0mZ3Q7Jmd0OyBZb3UncmUgYWJvdWx0ZWx5IHJpZ2h0LCBleGlz dGluZyBpbXBsZW1lbnRhdGlvbnMgb2YgQkZEIGRvbid0IG5lZWQgdG8gc3VwcG9ydCBiZmQuU2Vz c2lvblR5cGUgdmFyaWFibGUuIE9ubHkgaW1wbGVtZW50YXRpb25zIHRoYXQgc3VwcG9ydCB0aGUg YmFzZSBCRkQsIHNpbmdsZS1ob3Agb3IgbXVsdGktaG9wLCBhbmQgdGhpcyBzcGVjaWZpY2F0aW9u LCBtcEJGRCwgc2hvdWxkIHN1cHBvcnQgYmZkLlNlc3Npb25UeXBlDQogYW5kIHNldCBpdCB0byBQ b2ludFRvUG9pbnQgdmFsdWUgd2hlbiBCRkQgaXMgaW4gc2luZ2xlLWhvcCBvciBtdWx0aS1ob3Ag bW9kZS4gV2hlbiBpbiBtcEJGRCBtb2RlLCBiZmQuU2Vzc2lvblR5cGUgd2lsbCBiZSBzZXQgdG8g ZWl0aGVyIE11bHRpcG9pbnRIZWFkIG9yIE11bHRpcG9pbnRDbGllbnQuPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+W0JCXTogRG9lc24ndCBzb21l dGhpbmcgbmVlZCB0byBiZSB3cml0dGVuIChvciByZWZlcmVuY2VkKSB0byBjbGFyaWZ5IGFsbCB0 aGlzPyBBRkFJUiwgdGhpcyBzcGVjLiBuZXZlciBtYWRlIGNsZWFyIHRoYXQgbXVsdGlwb2ludCBp cyBhIGZvcmsgaW4gaW1wbGVtZW50YXRpb25zLjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBj bGFzcz0iIj5HSU0yJmd0OyZndDsgQW5kIHNvIGlzIFMtQkZELiAoTm90ZSwgYmZkLlNlc3Npb25U eXBlIGludHJvZHVjZWQgaW4gUkZDIDc4ODAgUy1CRkQgYnV0IG1pc3NlZCB0byBkZWZpbmUgUG9p bnRUb1BvaW50IHZhbHVlKS4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRo OiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigy MDQsIDIwNCwgMjA0KTsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4NCjxkaXYgYmdjb2xvcj0iI0ZGRkZG RiIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWwtaDUiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXY+SSBkbyBub3QgYmVsaWV2ZSB0aGUgcXVlc3Rpb24gd2FzIHdoZXRo ZXIgUy1CRkQgb3IgYW55IG90aGVyIHByb3RvY29sIGZvbGxvd2VkIHRoZSBiZWhhdmlvci4gSXTi gJlzIGEgcXVlc3Rpb24gYWJvdXQgdGhpcyBkb2N1bWVudC48L2Rpdj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2PkZvciBjb3JyZWN0bmVzcywgUy1CRkQgKFJGQyA3ODgwKSBkaWQg bm90IG1pc3MgdG8gZGVmaW5lJm5ic3A7UG9pbnRUb1BvaW50IHZhbHVlIOKAlCBpdCBjaG9zZSBu b3QgdG8uPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5CYWNrIHRvIHRo aXMgZG9jdW1lbnQsIHRoZSBxdWVzdGlvbiB3YXMgd2hldGhlciBzb21ldGhpbmcgbmVlZHMgdG8g YmUgd3JpdHRlbiB0byBjbGFyaWZ5LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+VGhlIHRleHQgaW4gcmV2IC0xOCBzdGlsbCBuZWVkcyBjbGFyaWZpY2F0aW9uLiBJdCBy ZWFkczo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50LTE4I3Nl Y3Rpb24tNS40LjEiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWJmZC1tdWx0aXBvaW50LTE4I3NlY3Rpb24tNS40LjE8L2E+PC9kaXY+DQo8ZGl2PjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgYmZkLlNlc3Npb25UeXBlPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhl IHR5cGUgb2YgdGhpcyBzZXNzaW9uIGFzIGRlZmluZWQgaW4gW1JGQzc4ODBdLiAmbmJzcDtOZXds eSBhZGRlZDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7dmFsdWVzIGFyZTo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IFBvaW50VG9Qb2ludDogQ2xhc3NpYyBwb2ludC10by1wb2ludCBCRkQsIGFzIGRlc2NyaWJl ZCBpbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBbUkZDNTg4MF0uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBNdWx0aXBvaW50SGVhZDogQSBzZXNzaW9uIG9uIHRoZSBoZWFkIHJlc3BvbnNpYmxl IGZvciB0aGU8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgcGVyaW9kaWMgdHJhbnNtaXNzaW9uIG9mIG11bHRpcG9pbnQgQkZEIENv bnRyb2wgcGFja2V0czwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBhbG9uZyB0aGUgbXVsdGlwb2ludCBwYXRoLjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTXVsdGlwb2ludFRhaWw6IEEgbXVsdGlw b2ludCBzZXNzaW9uIG9uIGEgdGFpbC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtUaGlzIHZhcmlhYmxlIE1VU1QgYmUgaW5pdGlhbGl6ZWQgdG8gdGhlIGFwcHJvcHJpYXRlIHR5 cGUgd2hlbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7dGhlIHNlc3Npb24gaXMgY3JlYXRlZC48L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5CYXNpY2FsbHksIHRoZSB2YXJpYWJsZSBNVVNUIGJlIGluaXRpYWxpemVkLCZuYnNwO1Bv aW50VG9Qb2ludCBpcyB1c2VkIGZvciBSRkMgNTg4MCwgYW5kIHRoaXMgdGV4dCBlZmZlY3RpdmVs eSByZW5kZXJzIGV2ZXJ5IGltcGxlbWVudGF0aW9uIG9mIFJGQyA1ODgwIG5vbiBjb21wbGlhbnQu PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5Db3VsZCB5b3UgcGxlYXNlIGFkZCBzb21lIGNsYXJpZnlpbmcgdGV4dCB0aGF0IGNvZGlmaWVz IHdoYXQgeW91IGRlc2NyaWJlZCBhYm92ZSAoaS5lLiwgZXhpc3RpbmcgcDJwIHRyYWRpdGlvbmFs IEJGRCBvbmx5IGRvIG5vdCBuZWVkIHRvIHNldCB0aGUgdmFyaWFibGUpPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MhPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+4oCUPGJyIGNsYXNzPSIiPg0KQ2FybG9z IFBpZ25hdGFybywmbmJzcDs8YSBocmVmPSJtYWlsdG86Y2FybG9zQGNpc2NvLmNvbSIgY2xhc3M9 IiI+Y2FybG9zQGNpc2NvLmNvbTwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8aSBj bGFzcz0iIj7igJxTb21ldGltZXMgSSB1c2UgYmlnIHdvcmRzIHRoYXQgSSBkbyBub3QgZnVsbHkg dW5kZXJzdGFuZCwgdG8gbWFrZSBteXNlbGYgc291bmQgbW9yZSBwaG90b3N5bnRoZXNpcy4mcXVv dDs8L2k+PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1A5DF3AAED834656AB1BE8CC9E721CE1ciscocom_-- From nobody Tue Jun 26 14:47:03 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D4B130EEB; Tue, 26 Jun 2018 14:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 AGpini4nzfTR; Tue, 26 Jun 2018 14:46:55 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD34130E53; Tue, 26 Jun 2018 14:46:55 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id j26-v6so10626133lfb.11; Tue, 26 Jun 2018 14:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M8zbpg/WeqBojPw5cLZQxBhRFKSTcuFV4W1W9jpwCaY=; b=E3rx+xAkIeL/BZB7ASfEee/qxQiQFZ+PdyUPF0QB8FAk6pCoSzBAfEb3hnPOqXbyVh c44Xgb+wJEESNo1YWN93izyFUged8yQ/TuclRzBl4Vougc1PEYYuRCCJicXbRvi5kl5e mMEn5NOLRv8WmX6948cEMItqSAxLA2VLDcY+A8ZmzA9i6/yhC3OQ3Sgw0bGKA03n0f7V BmrDw1QToiPBOawWRS21zVhvT3jNVvs3JhmEX7Roy0swtU2jaSw8jiZbyAQWMjN7+rfO 8H6e85qWsecgkmyrD5l8mk7h3Qf+/kcW8RXQqZsA1UT+7vH4DEQ5eYnDJA8ucTpKGjvy v0Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M8zbpg/WeqBojPw5cLZQxBhRFKSTcuFV4W1W9jpwCaY=; b=s21Jj4p0zEnS7Fgjj7C2DL8R59qKA7HNdMUNrfElEdpF0mKHBCGqhdxaTB24ZzDlm0 aSmC2wdxR2mNYDfyO28aWNerEvssPEJ+C9zn6fA1GGZmbkbOyKLKJx86I/XNDN1JKnG3 uQeaHAtcGWY4DNqtx/64c7QS18cQ5FY0CAyZ6WkieqwQTDPYHBl9WMfVw5CPb5XHNkOb 2UUShncsPxAriikwTkxTGxmzhtGRsim1EdZQ9F0q/Ij4pMAkPsvnKCevdT/tPZHM9BeR 2uwD9LNoag6yzwceX4m2/qDzzc5dJt8cDKu9VACA2fQH0lUMyuTBgiLaaws5MHXEAXwB pI4Q== X-Gm-Message-State: APt69E2eJRwWn4SSFKZA8xHbCGa1w8O99wMZHz+Is6GLfguS/HXLDz58 l0Q4dhGYBDMJZRyL6fTSn6cYCk5uCBfFe4HnuaE= X-Google-Smtp-Source: AAOMgpflHhBXQsnMeqT/9Yih8GJlnaEdYwHjn7jb/lGO3xSmlYgjSB5tMJjTkgZnv6Ma8zxjYT/Cxte4/tb+S0FRccc= X-Received: by 2002:a19:a283:: with SMTP id l125-v6mr2487542lfe.100.1530049613102; Tue, 26 Jun 2018 14:46:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 14:46:52 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Tue, 26 Jun 2018 14:46:52 -0700 Message-ID: Subject: Re: working group adoption poll for draft-mirsky-bfd-p2mp-vrrp-use-case To: Chris Bowers Cc: RTGWG , rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary="000000000000ad8401056f926f73" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 21:46:58 -0000 --000000000000ad8401056f926f73 Content-Type: text/plain; charset="UTF-8" Yes, support WG adoption as co-author Regards, Greg On Wed, Jun 20, 2018 at 9:46 AM, Chris Bowers wrote: > RTGWG, > > The authors of draft-mirsky-bfd-p2mp-vrrp-use-case have requested > that RTGWG adopt this draft as a WG document. > https://datatracker.ietf.org/doc/draft-mirsky-bfd-p2mp-vrrp-use-case/ > > Please indicate whether or not you support adoption of the draft > as a WG document. An explanation of why or why not is also very helpful. > > The two authors have already indicated that they know of no relevant IPR > other than what has already been disclosed. The draft has two IPR > disclosures. > https://datatracker.ietf.org/ipr/3133/ > https://datatracker.ietf.org/ipr/3135/ > > For some history related to this draft, please see: > https://www.ietf.org/mail-archive/web/rtgwg/current/msg06572.html > > For information about IPR in IETF technology, see RFC 8179. > https://datatracker.ietf.org/doc/rfc8179/ > > Note that one of the basic principles regarding how the IETF deals with > IPR claims (from RFC 8179) > is that: "The IETF will make no determination about the validity of any > particular IPR claim." > > Since Jeff Tantsura is a co-author, he will not be involved in judging > consensus. > > The closing date for this poll is Friday, July 6th. > > Thanks, > Chris > > > > > --000000000000ad8401056f926f73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, support WG adoption as co-author

R= egards,
Greg

On Wed, Jun 20, 2018 at 9:46 AM, Chris Bowers <c= hrisbowers.ietf@gmail.com> wrote:
RTGWG,

The authors of= draft-mirsky-bfd-p2mp-vrrp-use-case have requested
tha= t RTGWG adopt this draft as a WG document.=C2=A0

Please indicate whether= or not you support adoption of the draft
as a WG document.= =C2=A0 An explanation of why or why not is also very helpful.

The two authors have already indicated that they know of no= relevant IPR
other than what has already been disclosed. The= draft has two IPR disclosures.
=
For some history related to this draft, please see:

For information a= bout IPR in IETF techno= logy, see RFC 8179.
<= br>
Note that one of the basic principles=20 regard= ing how the IETF deals with<= span style=3D"font-family:arial,helvetica,sans-serif"><= /span> IPR claims (from RFC 8179)
<= /div>
is that: "The IETF will mak= e no determination about the validity of any particular IPR claim."

Since Jeff Tantsura is a co-author, he will not be involved in = judging consensus.=C2=A0

The closing date for this poll is Frid= ay, July 6th.=C2=A0

Thanks,
Chris




=

--000000000000ad8401056f926f73-- From nobody Wed Jun 27 07:52:09 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3E1130FCF; Wed, 27 Jun 2018 07:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 XqhO7cKcCPKS; Wed, 27 Jun 2018 07:52:01 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F89E130FDA; Wed, 27 Jun 2018 07:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8804; q=dns/txt; s=iport; t=1530111121; x=1531320721; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6yYhMLISz7CFXw2hAdhqckZRZj95Ogp9QsYKy+xRjVE=; b=cp5ZaYhpZp1wNPrflDD4Duve2GVWOvD2oqd+I1RwU7SjoexlpJJQ6h99 WsoKkqxivOwmrZvw4/Ap0AKWEEeW8nJ0lYv+779bsxKEQOfbaeeqlLuKT adQ8GOxrsx3J3r3rN0YuNTvmfxPe7J62c3IaFlSXe3ZixYOz1P3MtBAtE E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLAgARpDNb/5NdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJTdmJ/KAqDb5Q+gWUikBGHAQsshEACF4MCITgUAQIBAQI?= =?us-ascii?q?BAQJtHQuFNgEBAQQjVhACAQgRAwECKAMCAgIwFAkIAgQOBYMlAYEbZKxcghy?= =?us-ascii?q?EW4NxgRyIbYFWP4E2DIJcgUGDWRaCSzGCJAKISIkNh1wJAo8RgUCEB4gDkUw?= =?us-ascii?q?CERMBgSQ0IYFScBVlAYI+CYImjiJvgRWOLgGBGQEB?= X-IronPort-AV: E=Sophos;i="5.51,279,1526342400"; d="scan'208,217";a="414071396" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2018 14:51:55 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w5REptuZ029453 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Jun 2018 14:51:55 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 27 Jun 2018 09:51:54 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1320.000; Wed, 27 Jun 2018 09:51:54 -0500 From: "Reshad Rahman (rrahman)" To: "rtg-bfd@ietf.org" CC: "bfd-chairs@ietf.org" Subject: Re: IETF102 BFD WG agenda items Thread-Topic: IETF102 BFD WG agenda items Thread-Index: AQHUDIk4pvhBR5Utw0C5MJ3L/pSRXKR0RGIA Date: Wed, 27 Jun 2018 14:51:54 +0000 Message-ID: References: <37A0060B-5D22-4FAC-85EA-AF2BD15716F4@cisco.com> In-Reply-To: <37A0060B-5D22-4FAC-85EA-AF2BD15716F4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.46] Content-Type: multipart/alternative; boundary="_000_F58DFEF0428648F3A5DCCFF2CFF6C68Cciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 14:52:08 -0000 --_000_F58DFEF0428648F3A5DCCFF2CFF6C68Cciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhZGxpbmUgZm9yIGRyYWZ0IGFnZW5kYXMgaXMgSnVseSA0dGgsIHNvIHBsZWFzZSBzZW5kIHJl cXVlc3RzIGZvciBhZ2VuZGEgaXRlbXMgYnkgSnVseSAybmQuDQoNClJlZ2FyZHMsDQpSZXNoYWQu DQoNCkZyb206ICJSZXNoYWQgUmFobWFuIChycmFobWFuKSIgPHJyYWhtYW5AY2lzY28uY29tPg0K RGF0ZTogTW9uZGF5LCBKdW5lIDI1LCAyMDE4IGF0IDk6MzQgQU0NClRvOiAicnRnLWJmZEBpZXRm Lm9yZyIgPHJ0Zy1iZmRAaWV0Zi5vcmc+DQpDYzogImJmZC1jaGFpcnNAaWV0Zi5vcmciIDxiZmQt Y2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogSUVURjEwMiBCRkQgV0cgYWdlbmRhIGl0ZW1zDQpS ZXNlbnQtRnJvbTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+DQpSZXNlbnQtVG86IEplZmZyZXkg SGFhcyA8amhhYXNAcGZyYy5vcmc+LCA8cnJhaG1hbkBjaXNjby5jb20+DQpSZXNlbnQtRGF0ZTog TW9uZGF5LCBKdW5lIDI1LCAyMDE4IGF0IDk6MzQgQU0NCg0KSGkgZXZlcnlvbmUsDQoNClRoZSBC RkQgV0cgaGFzIGEgdGltZSBzbG90IGR1cmluZyBJRVRGMTAyIGluIE1vbnRyZWFsLCB3ZSBhcmUg bWVldGluZyBvbiBXZWRuZXNkYXkgSnVseSAxOHRoIDIwMTggZnJvbSAxNToyMCB0byAxNjo1MC4N Cg0KUGxlYXNlIHNlbmQgeW91ciByZXF1ZXN0cyBmb3IgYWdlbmRhIGl0ZW1zIChwcmVzZW50ZXIs IGRyYWZ0LCB0aW1lIHJlcXVlc3RlZCkgdG8gYmZkLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86YmZk LWNoYWlyc0BpZXRmLm9yZz4sIG5vIGxhdGVyIHRoYW4gTW9uZGF5IEp1bHkgOXRoIDIwMTguDQoN ClJlZ2FyZHMsDQpSZXNoYWQgJiBKZWZmLg0KDQo= --_000_F58DFEF0428648F3A5DCCFF2CFF6C68Cciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <786C8B11708C574F93FA53E385A2D2B0@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0 eWxlOm5vcm1hbDt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFt ZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpu b3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1DQSIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RGVhZGxpbmUgZm9yIGRyYWZ0IGFnZW5kYXMgaXMg SnVseSA0PHN1cD50aDwvc3VwPiwgc28gcGxlYXNlIHNlbmQgcmVxdWVzdHMgZm9yIGFnZW5kYSBp dGVtcyBieSBKdWx5IDI8c3VwPm5kPC9zdXA+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVzaGFkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5G cm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+JnF1b3Q7UmVzaGFkIFJh aG1hbiAocnJhaG1hbikmcXVvdDsgJmx0O3JyYWhtYW5AY2lzY28uY29tJmd0Ozxicj4NCjxiPkRh dGU6IDwvYj5Nb25kYXksIEp1bmUgMjUsIDIwMTggYXQgOTozNCBBTTxicj4NCjxiPlRvOiA8L2I+ JnF1b3Q7cnRnLWJmZEBpZXRmLm9yZyZxdW90OyAmbHQ7cnRnLWJmZEBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5DYzogPC9iPiZxdW90O2JmZC1jaGFpcnNAaWV0Zi5vcmcmcXVvdDsgJmx0O2JmZC1jaGFp cnNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPklFVEYxMDIgQkZEIFdHIGFnZW5k YSBpdGVtczxicj4NCjxiPlJlc2VudC1Gcm9tOiA8L2I+Jmx0O2FsaWFzLWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+UmVzZW50LVRvOiA8L2I+SmVmZnJleSBIYWFzICZsdDtqaGFhc0BwZnJj Lm9yZyZndDssICZsdDtycmFobWFuQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5SZXNlbnQtRGF0ZTog PC9iPk1vbmRheSwgSnVuZSAyNSwgMjAxOCBhdCA5OjM0IEFNPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5IaSBldmVyeW9uZSw8L3NwYW4+PG86cD48L286cD48L2E+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlRoZSBCRkQgV0cgaGFzIGEgdGltZSBzbG90IGR1 cmluZyBJRVRGMTAyIGluIE1vbnRyZWFsLCB3ZSBhcmUgbWVldGluZyBvbiBXZWRuZXNkYXkgSnVs eSAxOHRoIDIwMTggZnJvbSAxNToyMCB0byAxNjo1MC48L3NwYW4+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNr Ij5QbGVhc2Ugc2VuZCB5b3VyIHJlcXVlc3RzIGZvcjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5hZ2VuZGE8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+aXRlbXMgKHByZXNlbnRlciwNCiBkcmFmdCwgdGltZSByZXF1 ZXN0ZWQpIHRvPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmJmZC1jaGFpcnNAaWV0Zi5vcmciPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+YmZkLWNoYWlyc0BpZXRmLm9yZzwvc3Bhbj48L3Nw YW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwv YT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiwNCiBubyBsYXRl ciB0aGFuIE1vbmRheSBKdWx5IDl0aCAyMDE4Ljwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlJl Z2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+UmVzaGFkICZhbXA7 IEplZmYuPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F58DFEF0428648F3A5DCCFF2CFF6C68Cciscocom_-- From nobody Wed Jun 27 08:10:24 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C74130DE8; Wed, 27 Jun 2018 08:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 jqGplnOC-RRD; Wed, 27 Jun 2018 08:10:18 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E1759130DE0; Wed, 27 Jun 2018 08:10:17 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id E6D381E3CE; Wed, 27 Jun 2018 11:10:11 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_38AD0653-E4C2-4122-99F2-54091332A8B0" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: IETF102 BFD WG agenda items From: Jeffrey Haas In-Reply-To: Date: Wed, 27 Jun 2018 11:10:16 -0400 Cc: "rtg-bfd@ietf.org" , "bfd-chairs@ietf.org" Message-Id: <9FC3C189-27B2-4C7D-8F02-465E5666F6EE@pfrc.org> References: <37A0060B-5D22-4FAC-85EA-AF2BD15716F4@cisco.com> To: "Reshad Rahman (rrahman)" X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 15:10:22 -0000 --Apple-Mail=_38AD0653-E4C2-4122-99F2-54091332A8B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Reshad, Just to kick things off, my co-author Albert and I would like a slot (10 = or so mins) to further get working group engagement on the problem = covered by draft-haas-bfd-large-packets. We'll be focusing on use case = with intent to get WG discussion on the solution space. -- Jeff > On Jun 27, 2018, at 10:51 AM, Reshad Rahman (rrahman) = wrote: >=20 > Deadline for draft agendas is July 4th, so please send requests for = agenda items by July 2nd. > =20 > Regards, > Reshad. > =20 > From: "Reshad Rahman (rrahman)" > > Date: Monday, June 25, 2018 at 9:34 AM > To: "rtg-bfd@ietf.org " > > Cc: "bfd-chairs@ietf.org " = > > Subject: IETF102 BFD WG agenda items > Resent-From: > > Resent-To: Jeffrey Haas >, = > > Resent-Date: Monday, June 25, 2018 at 9:34 AM > =20 > Hi everyone, <> > =20 > The BFD WG has a time slot during IETF102 in Montreal, we are meeting = on Wednesday July 18th 2018 from 15:20 to 16:50. > =20 > Please send your requests for agenda items (presenter, draft, time = requested) to bfd-chairs@ietf.org , no later = than Monday July 9th 2018. > =20 > Regards, > Reshad & Jeff. --Apple-Mail=_38AD0653-E4C2-4122-99F2-54091332A8B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Reshad,

Just to kick things off, my co-author Albert and I would like = a slot (10 or so mins) to further get working group engagement on the = problem covered by draft-haas-bfd-large-packets.  We'll be focusing = on use case with intent to get WG discussion on the solution = space.

-- = Jeff

On Jun 27, 2018, at 10:51 AM, Reshad Rahman = (rrahman) <rrahman=3D40cisco.com@dmarc.ietf.org> wrote:

Deadline for draft agendas is July 4th, = so please send requests for agenda items by July 2nd.
 
Regards,
Reshad.
 
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
Date: Monday, June 25, 2018 = at 9:34 AM
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Cc: "bfd-chairs@ietf.org" <bfd-chairs@ietf.org>
Subject: IETF102 BFD WG agenda = items
Resent-From: <alias-bounces@ietf.org>
Resent-To: Jeffrey Haas <jhaas@pfrc.org>, <rrahman@cisco.com>
Resent-Date: Monday, June 25, 2018 = at 9:34 AM
 
Hi = everyone,
 
The BFD WG has a time slot during = IETF102 in Montreal, we are meeting on Wednesday July 18th 2018 from = 15:20 to 16:50.
 
Please send your requests for agenda items (presenter, draft, = time requested) to bfd-chairs@ietf.org, no later than Monday July 9th = 2018.
 
Regards,
Reshad & = Jeff.

= --Apple-Mail=_38AD0653-E4C2-4122-99F2-54091332A8B0-- From nobody Thu Jun 28 12:30:50 2018 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7062A130EA6; Thu, 28 Jun 2018 12:30:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar To: Cc: rtg-bfd@ietf.org, ietf@ietf.org, draft-ietf-bfd-multipoint-active-tail.all@ietf.org Subject: Genart last call review of draft-ietf-bfd-multipoint-active-tail-09 X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153021423641.18488.4659084638238812446@ietfa.amsl.com> Date: Thu, 28 Jun 2018 12:30:36 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 19:30:37 -0000 Reviewer: Linda Dunbar Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-bfd-multipoint-active-tail-?? Reviewer: Linda Dunbar Review Date: 2018-06-28 IETF LC End Date: 2018-06-18 IESG Telechat date: 2018-07-05 Summary: clear writing of the procedure. Major issues: None Minor issues: None Nits/editorial comments: Are End points that not responding considered "Inactive Tails"? Does the HeadEnd report the "Inactive Tails"? Linda Dunbar From nobody Thu Jun 28 13:35:38 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C86D1310D7; Thu, 28 Jun 2018 13:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nbu5eRc3jOE4; Thu, 28 Jun 2018 13:34:53 -0700 (PDT) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (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 C49301310E2; Thu, 28 Jun 2018 13:34:52 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id h2-v6so2300243ljb.10; Thu, 28 Jun 2018 13:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=jzcbvJe72CNvFSO/oFXQPAoWSFYLo935tqUnkfLFXjE=; b=EUg8HsufciUYdJ/spyR8NqN9Z3UViNWQUT1Xi2XFW8EeJ7EkB8AAaUD0ZPOCy1aaus MXlaGG6gEoM6K8DqWqojQ3YVUNlG5P6zRnn3C1TIptWFCZ7warSgywIvvkEp/ifkfJGv mHpm1CItyrQqI1nTlLut7xD80yUvpzGVVltKXWran8IqR/SGxjCe8K79hi+kyJbVevkd MJPloJLkofPOQ5Sy6xV26yPc2cKXrJ5ajDX5pzvtjFT0OabpTTZJ4h1DNhUDXwQEo3kF J9piKL2RFSzRF/2dpsLdi9ER/jvOdqzpGNR3759y6ymXltq9M5o/zZaQeNfsw8JsTfoU 874Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=jzcbvJe72CNvFSO/oFXQPAoWSFYLo935tqUnkfLFXjE=; b=ois11RUjzgAXSsIUoDlWiTpjKe4kkIHR7kWHWMchjKRj80oftAdudN33c4Gp8lQ9U2 H55CL7NB8tV1IS4B0TnHlsG4Q2lm2T6igLWPjAUD10ICPVExBNLS7bOqda8KZAO6O4k7 eX2sYt1L8yYR4dDFQsZs1aVJLlmHpUQn9pCusukVi80xIkJmcOLmg9SLne2g2sZ02WVF tdOyZQuP04F0rKffWW9KjoY7HiO12vtOLzkNFi9qCYbireoGYPJItHZtrkRCVFjBEAxe PHEj51MaLgLy7Gxwj57ZzfD0GrsMl4UYNQ93vo7MBnMKstns50wC3Uehne6J4KmZczPY igcQ== X-Gm-Message-State: APt69E2MTJN6X/YZMUAColRUByqtIHatsWWDMj+i0nKgk3n6YkRB9oQU Gjsc8gkuO188QxLvViUzrhVyEk6dE3rNDfh6VyrUww== X-Google-Smtp-Source: AAOMgpfoIjByF9offX+tnWgeHW8QtzrGw6smSQxijnT4oeiyIRIa/t7ASKv8oUHIteIOW3pjzB3F4S2XHthp+dJ5frg= X-Received: by 2002:a2e:2161:: with SMTP id h94-v6mr8653391ljh.58.1530218090558; Thu, 28 Jun 2018 13:34:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Thu, 28 Jun 2018 13:34:49 -0700 (PDT) In-Reply-To: <153020466705.14520.2646847580748723541.idtracker@ietfa.amsl.com> References: <153020466705.14520.2646847580748723541.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Thu, 28 Jun 2018 13:34:49 -0700 Message-ID: Subject: Fwd: New Version Notification for draft-mirsky-rtgwg-oam-identify-00.txt To: rtg-bfd@ietf.org, Service Function Chaining IETF list , NVO3 , BIER WG , detnet@ietf.org, int-area@ietf.org Content-Type: multipart/alternative; boundary="000000000000b779cc056fb9a994" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 20:35:09 -0000 --000000000000b779cc056fb9a994 Content-Type: text/plain; charset="UTF-8" Dear All, I hope that this new draft (yes, that's what I wanted to send the first time) will be of interest to those working on overlay encapsulations. Appreciate your comments, questions, and suggestions. Regards, Greg ---------- Forwarded message ---------- From: Date: Thu, Jun 28, 2018 at 9:51 AM Subject: New Version Notification for draft-mirsky-rtgwg-oam-identify-00.txt To: Gregory Mirsky A new version of I-D, draft-mirsky-rtgwg-oam-identify-00.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-rtgwg-oam-identify Revision: 00 Title: Identification of Overlay Operations, Administration, and Maintenance (OAM) Document date: 2018-06-28 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mirsky-rtgwg-oam- identify-00.txt Status: https://datatracker.ietf.org/doc/draft-mirsky-rtgwg-oam- identify/ Htmlized: https://tools.ietf.org/html/draft-mirsky-rtgwg-oam- identify-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-mirsky-rtgwg- oam-identify Abstract: This document analyzes how the presence of Operations, Administration, and Maintenance (OAM) control command and/or special data is identified in some overlay networks, and an impact on the choice of identification may have on OAM functionality. 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. The IETF Secretariat --000000000000b779cc056fb9a994 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
I hope that this new dra= ft (yes, that's what I wanted to send the first time) will be of intere= st to those working on overlay=C2=A0encapsulations. Appreciate your comment= s, questions, and suggestions.

Re= gards,
Greg

---------- Forwarded message ----------
F= rom: <internet-drafts@ietf.org>
D= ate: Thu, Jun 28, 2018 at 9:51 AM
Subject: New Version Notification for = draft-mirsky-rtgwg-oam-identify-00.txt
To: Gregory Mirsky <gregimirsky@gmail.com>


A new version of I-D, draft-mirsky-rtgwg-oam-identify-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-rtgwg-oam-i= dentify
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Identification of Overlay Operatio= ns, Administration, and Maintenance (OAM)
Document date:=C2=A0 2018-06-28
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky= -rtgwg-oam-identify-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mirsky-rtgwg-oam-ide= ntify/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://tools.ietf.org/html/draft-mirsky-rtgwg-oam-identify-00<= br> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mirsky-rtgwg-oam= -identify


Abstract:
=C2=A0 =C2=A0This document analyzes how the presence of Operations,
=C2=A0 =C2=A0Administration, and Maintenance (OAM) control command and/or s= pecial
=C2=A0 =C2=A0data is identified in some overlay networks, and an impact on = the
=C2=A0 =C2=A0choice of identification may have on OAM functionality.




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

The IETF Secretariat


--000000000000b779cc056fb9a994-- From nobody Thu Jun 28 14:32:24 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D7B1310E5 for ; Thu, 28 Jun 2018 14:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 QPsfXkStb7wH for ; Thu, 28 Jun 2018 14:31:59 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 B3E0E1310D3 for ; Thu, 28 Jun 2018 14:31:55 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id y20-v6so6121795qto.8 for ; Thu, 28 Jun 2018 14:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tRy6VinVZKV5pKf/2VuvRQ8hu2UFQ/RR8hXmx0CqbwU=; b=OGaS4JtlfEiXThHJ3eXrqjv5YBmmdWgdLMaCBTrUu3EEqmGy8R/KPy+kvAdQhnRcHy 8tfAhHRFZ704I4eY7ZFpYP6orHqgSjGr59FWQLkXLIYhcQrjeTcaoEQX3qVkKA+k9uge u+ZGD+apAWX9J7PA1zdw+6snz+MJIUOkYw33jkMlc5SUR+/ItU1e2K2XWCdIv+3euzH6 yujjxtYvLd9WnSy41AggAuWDC7uQ/O8dPMdKMZdQSyU9cIZSfVX228asDslW/rLngxZi jTrLr4DUInx/Iw/YM9lehLj3hMGMi/eQPmVEhR+jeEOpkk3BVxBAAfc6aR/BfKk7xW9r q+sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tRy6VinVZKV5pKf/2VuvRQ8hu2UFQ/RR8hXmx0CqbwU=; b=Hb3SWaupNDtA49Crkb0zOQWRIymO/qpJ7bPFDojV88PKGy7o1ldTQ0kJBMRXpmoKaj VS939prX03IjG8x1AUbNfEdyptB2tDpXQAnL5lUYT0sqg0QLpiTFmNyZIyjJWzQSbMDU YxY6bgGNX0vFwp9/VcBe3HzG9PN0ziiOjGyGwyd8maD8+zOcKrJHTUICplj7YFez8ApN Z85pyaJZ2ynyi8ifoQGLqDToYSg9lGWDGEhB3j6LbYmFiQ7wYV82fc0kDqJ3E+WvH7po LjQCSaiiizhPSHsZ0hZ+81+gq7RCqbRRovQ21spkzZou1oe1vFTUjyqZzjfmIBQzQ7I+ IV5Q== X-Gm-Message-State: APt69E2YnLRRjvNtjcSOZvx+V4WaQSdA4YpGG/KKnUjJUlBe0eG+zm1V Jos05nnMZapnGaQQrmUbP+kvo/TbwN3xCtn7mCjA/Za6 X-Google-Smtp-Source: AAOMgpeR+1CVMg7EMSfm7YC6AfDS00zsMWo43YvM4zGhdvq0E09juSWZbDHWbaSLHUwQR6VTyMyspRaZaP3dCaqDuLI= X-Received: by 2002:ac8:2393:: with SMTP id q19-v6mr11032977qtq.197.1530221514539; Thu, 28 Jun 2018 14:31:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Thu, 28 Jun 2018 14:31:53 -0700 (PDT) In-Reply-To: References: <153020466705.14520.2646847580748723541.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Thu, 28 Jun 2018 14:31:53 -0700 Message-ID: Subject: Re: [Int-area] Fwd: New Version Notification for draft-mirsky-rtgwg-oam-identify-00.txt To: Greg Mirsky Cc: rtg-bfd@ietf.org, Service Function Chaining IETF list , NVO3 , BIER WG , detnet@ietf.org, int-area Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 21:32:04 -0000 On Thu, Jun 28, 2018 at 1:34 PM, Greg Mirsky wrote: > Dear All, > I hope that this new draft (yes, that's what I wanted to send the first > time) will be of interest to those working on overlay encapsulations. > Appreciate your comments, questions, and suggestions. > Regarding OAM in GUE, the C bit can be set to indicate a control packet which could be OAM (draft-ietf-intarea-gue-05). I imagine that OAM could be implement in one or more ctypes. This is considered an alternative to GUE carrying a data protocol payload, it's not considered part of the GUE header and isn't limited by GUE header len. The statement in Geneve description "transit devices MUST NOT attempt to interpret or process it" is true for all UDP encapsulation protocols. The problem is that encapsulation is determined by destination port number. As described in RFC7605, UDP port numbers only have meaning at the endpoints, so transit devices may incorrectly interpret packets as being an encapsulation. Incorrectly reading a packet as encapsulation might be innocuous, but an intermediate node modifying such a packet that it incorrectly believes is an encapsulation would be systematic data corruption. Because of this, probably the only robust method for in-situ OAM is Hop-by-Hop options. Tom > Regards, > Greg > > ---------- Forwarded message ---------- > From: > Date: Thu, Jun 28, 2018 at 9:51 AM > Subject: New Version Notification for draft-mirsky-rtgwg-oam-identify-00.txt > To: Gregory Mirsky > > > > A new version of I-D, draft-mirsky-rtgwg-oam-identify-00.txt > has been successfully submitted by Greg Mirsky and posted to the > IETF repository. > > Name: draft-mirsky-rtgwg-oam-identify > Revision: 00 > Title: Identification of Overlay Operations, Administration, and > Maintenance (OAM) > Document date: 2018-06-28 > Group: Individual Submission > Pages: 9 > URL: > https://www.ietf.org/internet-drafts/draft-mirsky-rtgwg-oam-identify-00.txt > Status: > https://datatracker.ietf.org/doc/draft-mirsky-rtgwg-oam-identify/ > Htmlized: > https://tools.ietf.org/html/draft-mirsky-rtgwg-oam-identify-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-mirsky-rtgwg-oam-identify > > > Abstract: > This document analyzes how the presence of Operations, > Administration, and Maintenance (OAM) control command and/or special > data is identified in some overlay networks, and an impact on the > choice of identification may have on OAM functionality. > > > > > 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. > > The IETF Secretariat > > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From nobody Fri Jun 29 09:45:24 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10D8130DDB; Fri, 29 Jun 2018 09:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 g6QhoYdQedc8; Fri, 29 Jun 2018 09:45:05 -0700 (PDT) Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (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 A6622130DC1; Fri, 29 Jun 2018 09:45:04 -0700 (PDT) Received: by mail-lj1-x243.google.com with SMTP id g3-v6so7808788ljk.12; Fri, 29 Jun 2018 09:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nVQthTZQtL+xu0QekldhZC4wZUacHAaZ6IkirqGrxRU=; b=HKuKjVqhRsdMBkXlO6rS+W9SUIKGSxFbE8IHDKEyOQbQEVqXvIE890urvuIt7w9fis 56kHRjq7a9nlyaZgCt0hhJVOtUvrPzSRGLcMAMty9nLtaz0mp3ZEIvUcGn4Jj0qGFLku gEaMxPFoHnZDhfyb+9FK/xJkErRC3X/v4Cy5MqYNmN5jawaBrkL5uAXRA3XVVeOuytGB 61IEHYPrXp+ZlhnvhlQPGcaA/Ape8bsHPOELw0kvIOkVgi6FvtlmyPAp8uyG+qLvFodC HbOOwOlF4A7yJGuOJ3P+1LsynaU5oammY8CZX3Dva3fVuCSXdR4GbE7Du0B7wbqhKtwi fBtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nVQthTZQtL+xu0QekldhZC4wZUacHAaZ6IkirqGrxRU=; b=hqS/jldP8C5elX/CsoZiGD79rJ9hsbBjovCiodcGH60RofQboj8XvBFm2m0xWAcGiC NdkI0ly3efsO/7ctTAJEPdlUKWcuQbbFip/WhlhhML4+nOGlbWzEi07TCKYO6mwgf3cd N5XUcjZQe4F9gAVL91KyYUUgDmCGxm0RC9fIbY68cZjQ/HxTWIoVujgq071RNKXdOMur a0zfkP2QHaxgwNCjO+FAstnwBtWuOi1QrofBk3FJikkQjPAKGZaXfW2vhK79wQa+ubfm toJ3d1q+FO+1RgyaFFPPT+i/3TyZft3CrAWD76oP9v42giA3nYFIEhvpSulEVzSkpHyf bpDA== X-Gm-Message-State: APt69E19euwgIefKnF4thJfwBF2Jym9swc67a4QIbGLdtRpD90GrTThv tsbdh+ez9As4A7f0Cmfah2NSEKRgpElg56v/TEg= X-Google-Smtp-Source: ADUXVKKeAxTNJ/mqG2LL910/cMNcRRLRWM4ak9g8c4J4eKiGIv0nP5Jawx5isFAxRJs15x4/BHmLac1/FhPj6iFWj30= X-Received: by 2002:a2e:c52:: with SMTP id o18-v6mr10527714ljd.72.1530290702758; Fri, 29 Jun 2018 09:45:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Fri, 29 Jun 2018 09:45:02 -0700 (PDT) In-Reply-To: <153021423641.18488.4659084638238812446@ietfa.amsl.com> References: <153021423641.18488.4659084638238812446@ietfa.amsl.com> From: Greg Mirsky Date: Fri, 29 Jun 2018 09:45:02 -0700 Message-ID: Subject: Re: Genart last call review of draft-ietf-bfd-multipoint-active-tail-09 To: Linda Dunbar Cc: gen-art@ietf.org, rtg-bfd@ietf.org, IETF list , draft-ietf-bfd-multipoint-active-tail.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000bdb75c056fca91db" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 16:45:07 -0000 --000000000000bdb75c056fca91db Content-Type: text/plain; charset="UTF-8" Hi Linda, thank you for the review and your kind words, much appreciated. If an end-point during the p2mp BFD session never responded to the head's multicast poll it is unknown to the head and cannot be reported as "inactive tail". I can imagine that if the head has been given the list of the tails, then the unresponsive end-point can be reported as "inactive tails". Regards, Greg On Thu, Jun 28, 2018 at 12:30 PM, Linda Dunbar wrote: > Reviewer: Linda Dunbar > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-bfd-multipoint-active-tail-?? > Reviewer: Linda Dunbar > Review Date: 2018-06-28 > IETF LC End Date: 2018-06-18 > IESG Telechat date: 2018-07-05 > > Summary: clear writing of the procedure. > > Major issues: None > > Minor issues: None > > Nits/editorial comments: > > Are End points that not responding considered "Inactive Tails"? Does the > HeadEnd report the "Inactive Tails"? > > Linda Dunbar > > > --000000000000bdb75c056fca91db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Linda,
thank you for the review and your kind words= , much appreciated.

If an end-point during the p2m= p BFD session never responded to the head's multicast poll it is unknow= n to the head and cannot be reported as "inactive tail". I can im= agine that if the head has been given the list of the tails, then the unres= ponsive end-point can be reported as "inactive tails".
<= div>
Regards,
Greg

On Thu, Jun 28, 2018 at 12:30 PM, Lind= a Dunbar <Linda.dunbar@huawei.com> wrote:
Reviewer: Linda Dunbar
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq<= /a>>.

Document: draft-ietf-bfd-multipoint-active-tail-??
Reviewer: Linda Dunbar
Review Date: 2018-06-28
IETF LC End Date: 2018-06-18
IESG Telechat date: 2018-07-05

Summary: clear writing of the procedure.

Major issues: None

Minor issues: None

Nits/editorial comments:

Are End points that not responding considered "Inactive Tails"?= =C2=A0 Does the
HeadEnd report the "Inactive Tails"?

Linda Dunbar



--000000000000bdb75c056fca91db-- From nobody Fri Jun 29 09:52:09 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C989A130DCC; Fri, 29 Jun 2018 09:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 edk-1KKEy8TO; Fri, 29 Jun 2018 09:52:05 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 14C66130DC1; Fri, 29 Jun 2018 09:52:05 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 4BF7BBACDA739; Fri, 29 Jun 2018 17:52:00 +0100 (IST) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 29 Jun 2018 17:52:02 +0100 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.90]) by SJCEML702-CHM.china.huawei.com ([169.254.4.228]) with mapi id 14.03.0382.000; Fri, 29 Jun 2018 09:51:58 -0700 From: Linda Dunbar To: Greg Mirsky CC: "gen-art@ietf.org" , "rtg-bfd@ietf.org" , IETF list , "draft-ietf-bfd-multipoint-active-tail.all@ietf.org" Subject: RE: Genart last call review of draft-ietf-bfd-multipoint-active-tail-09 Thread-Topic: Genart last call review of draft-ietf-bfd-multipoint-active-tail-09 Thread-Index: AQHUD8iO22YytSIWJ0Ko2uRvTqHK8KR3cr6w Date: Fri, 29 Jun 2018 16:51:58 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B0764D4@sjceml521-mbs.china.huawei.com> References: <153021423641.18488.4659084638238812446@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.89] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B0764D4sjceml521mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 16:52:08 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F66B0764D4sjceml521mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZywNCg0KVGhhbmtzIGZvciB0aGUgcmVwbHkuDQoNCkl0IG1pZ2h0IGJlIHRvbyBsYXRlIHRv IGFzayB0aGlzIHF1ZXN0aW9uLCBJIGFtIGN1cmlvdXMgaWYgdGhlIGhlYWQtZW5kIGlzIGF3YXJl IG9mIHRoZSBsaXN0IG9mIGVuZCBwb2ludHMsIHdoYXQgaXMgd3JvbmcgaWYgdGhleSBqdXN0IHVz ZSB1bmljYXN0IEJGRCB0byBlYWNoIG9mIHRoZW0/IE11bHRpY2FzdC1CRkQgc2VlbXMgcmVxdWly ZXMgbW9yZSBzdXBwb3J0IG9mIHRoZSBuZXR3b3JrLCBpc27igJl0IGl0Pw0KDQpMaW5kYQ0KDQpG cm9tOiBHcmVnIE1pcnNreSBbbWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbV0NClNlbnQ6IEZy aWRheSwgSnVuZSAyOSwgMjAxOCAxMTo0NSBBTQ0KVG86IExpbmRhIER1bmJhciA8bGluZGEuZHVu YmFyQGh1YXdlaS5jb20+DQpDYzogZ2VuLWFydEBpZXRmLm9yZzsgcnRnLWJmZEBpZXRmLm9yZzsg SUVURiBsaXN0IDxpZXRmQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludC1hY3Rp dmUtdGFpbC5hbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBHZW5hcnQgbGFzdCBjYWxsIHJldmll dyBvZiBkcmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50LWFjdGl2ZS10YWlsLTA5DQoNCkhpIExpbmRh LA0KdGhhbmsgeW91IGZvciB0aGUgcmV2aWV3IGFuZCB5b3VyIGtpbmQgd29yZHMsIG11Y2ggYXBw cmVjaWF0ZWQuDQoNCklmIGFuIGVuZC1wb2ludCBkdXJpbmcgdGhlIHAybXAgQkZEIHNlc3Npb24g bmV2ZXIgcmVzcG9uZGVkIHRvIHRoZSBoZWFkJ3MgbXVsdGljYXN0IHBvbGwgaXQgaXMgdW5rbm93 biB0byB0aGUgaGVhZCBhbmQgY2Fubm90IGJlIHJlcG9ydGVkIGFzICJpbmFjdGl2ZSB0YWlsIi4g SSBjYW4gaW1hZ2luZSB0aGF0IGlmIHRoZSBoZWFkIGhhcyBiZWVuIGdpdmVuIHRoZSBsaXN0IG9m IHRoZSB0YWlscywgdGhlbiB0aGUgdW5yZXNwb25zaXZlIGVuZC1wb2ludCBjYW4gYmUgcmVwb3J0 ZWQgYXMgImluYWN0aXZlIHRhaWxzIi4NCg0KUmVnYXJkcywNCkdyZWcNCg0KT24gVGh1LCBKdW4g MjgsIDIwMTggYXQgMTI6MzAgUE0sIExpbmRhIER1bmJhciA8TGluZGEuZHVuYmFyQGh1YXdlaS5j b208bWFpbHRvOkxpbmRhLmR1bmJhckBodWF3ZWkuY29tPj4gd3JvdGU6DQpSZXZpZXdlcjogTGlu ZGEgRHVuYmFyDQpSZXZpZXcgcmVzdWx0OiBSZWFkeQ0KDQpJIGFtIHRoZSBhc3NpZ25lZCBHZW4t QVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVhDQpSZXZpZXcgVGVh bSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkDQpi eSB0aGUgSUVTRyBmb3IgdGhlIElFVEYgQ2hhaXIuICBQbGVhc2UgdHJlYXQgdGhlc2UgY29tbWVu dHMganVzdA0KbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpGb3IgbW9yZSBp bmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgRkFRIGF0DQoNCjxodHRwczovL3RyYWMuaWV0Zi5v cmcvdHJhYy9nZW4vd2lraS9HZW5BcnRmYXE+Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1iZmQt bXVsdGlwb2ludC1hY3RpdmUtdGFpbC0/Pw0KUmV2aWV3ZXI6IExpbmRhIER1bmJhcg0KUmV2aWV3 IERhdGU6IDIwMTgtMDYtMjgNCklFVEYgTEMgRW5kIERhdGU6IDIwMTgtMDYtMTgNCklFU0cgVGVs ZWNoYXQgZGF0ZTogMjAxOC0wNy0wNQ0KDQpTdW1tYXJ5OiBjbGVhciB3cml0aW5nIG9mIHRoZSBw cm9jZWR1cmUuDQoNCk1ham9yIGlzc3VlczogTm9uZQ0KDQpNaW5vciBpc3N1ZXM6IE5vbmUNCg0K Tml0cy9lZGl0b3JpYWwgY29tbWVudHM6DQoNCkFyZSBFbmQgcG9pbnRzIHRoYXQgbm90IHJlc3Bv bmRpbmcgY29uc2lkZXJlZCAiSW5hY3RpdmUgVGFpbHMiPyAgRG9lcyB0aGUNCkhlYWRFbmQgcmVw b3J0IHRoZSAiSW5hY3RpdmUgVGFpbHMiPw0KDQpMaW5kYSBEdW5iYXINCg0KDQo= --_000_4A95BA014132FF49AE685FAB4B9F17F66B0764D4sjceml521mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWls U3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkdyZWcsDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIHJlcGx5Lg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JdCBtaWdodCBiZSB0 b28gbGF0ZSB0byBhc2sgdGhpcyBxdWVzdGlvbiwgSSBhbSBjdXJpb3VzIGlmIHRoZSBoZWFkLWVu ZCBpcyBhd2FyZSBvZiB0aGUgbGlzdCBvZiBlbmQgcG9pbnRzLCB3aGF0IGlzIHdyb25nIGlmIHRo ZXkganVzdCB1c2UgdW5pY2FzdCBCRkQgdG8gZWFjaA0KIG9mIHRoZW0/IE11bHRpY2FzdC1CRkQg c2VlbXMgcmVxdWlyZXMgbW9yZSBzdXBwb3J0IG9mIHRoZSBuZXR3b3JrLCBpc27igJl0IGl0PyA8 bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TGluZGE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENv bXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gR3JlZyBNaXJza3kgW21haWx0bzpncmVn aW1pcnNreUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdW5lIDI5LCAy MDE4IDExOjQ1IEFNPGJyPg0KPGI+VG86PC9iPiBMaW5kYSBEdW5iYXIgJmx0O2xpbmRhLmR1bmJh ckBodWF3ZWkuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gZ2VuLWFydEBpZXRmLm9yZzsgcnRnLWJm ZEBpZXRmLm9yZzsgSUVURiBsaXN0ICZsdDtpZXRmQGlldGYub3JnJmd0OzsgZHJhZnQtaWV0Zi1i ZmQtbXVsdGlwb2ludC1hY3RpdmUtdGFpbC5hbGxAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYmZkLW11bHRpcG9p bnQtYWN0aXZlLXRhaWwtMDk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I aSBMaW5kYSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGFu ayB5b3UgZm9yIHRoZSByZXZpZXcgYW5kIHlvdXIga2luZCB3b3JkcywgbXVjaCBhcHByZWNpYXRl ZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SWYgYW4gZW5kLXBvaW50IGR1cmluZyB0aGUgcDJtcCBCRkQgc2Vzc2lvbiBuZXZlciByZXNwb25k ZWQgdG8gdGhlIGhlYWQncyBtdWx0aWNhc3QgcG9sbCBpdCBpcyB1bmtub3duIHRvIHRoZSBoZWFk IGFuZCBjYW5ub3QgYmUgcmVwb3J0ZWQgYXMgJnF1b3Q7aW5hY3RpdmUgdGFpbCZxdW90Oy4gSSBj YW4gaW1hZ2luZSB0aGF0IGlmIHRoZSBoZWFkIGhhcyBiZWVuIGdpdmVuIHRoZSBsaXN0IG9mIHRo ZSB0YWlscywgdGhlbiB0aGUNCiB1bnJlc3BvbnNpdmUgZW5kLXBvaW50IGNhbiBiZSByZXBvcnRl ZCBhcyAmcXVvdDtpbmFjdGl2ZSB0YWlscyZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdyZWc8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKdW4gMjgsIDIwMTgg YXQgMTI6MzAgUE0sIExpbmRhIER1bmJhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOkxpbmRhLmR1bmJh ckBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+TGluZGEuZHVuYmFyQGh1YXdlaS5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlJldmlld2VyOiBMaW5kYSBEdW5iYXI8 YnI+DQpSZXZpZXcgcmVzdWx0OiBSZWFkeTxicj4NCjxicj4NCkkgYW0gdGhlIGFzc2lnbmVkIEdl bi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBHZW5lcmFsIEFyZWE8YnI+DQpSZXZp ZXcgVGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vz c2VkPGJyPg0KYnkgdGhlIElFU0cgZm9yIHRoZSBJRVRGIENoYWlyLiZuYnNwOyBQbGVhc2UgdHJl YXQgdGhlc2UgY29tbWVudHMganVzdDxicj4NCmxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21t ZW50cy48YnI+DQo8YnI+DQpGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgRkFR IGF0PGJyPg0KPGJyPg0KJmx0OzxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dl bi93aWtpL0dlbkFydGZhcSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90 cmFjL2dlbi93aWtpL0dlbkFydGZhcTwvYT4mZ3Q7Ljxicj4NCjxicj4NCkRvY3VtZW50OiBkcmFm dC1pZXRmLWJmZC1tdWx0aXBvaW50LWFjdGl2ZS10YWlsLT8/PGJyPg0KUmV2aWV3ZXI6IExpbmRh IER1bmJhcjxicj4NClJldmlldyBEYXRlOiAyMDE4LTA2LTI4PGJyPg0KSUVURiBMQyBFbmQgRGF0 ZTogMjAxOC0wNi0xODxicj4NCklFU0cgVGVsZWNoYXQgZGF0ZTogMjAxOC0wNy0wNTxicj4NCjxi cj4NClN1bW1hcnk6IGNsZWFyIHdyaXRpbmcgb2YgdGhlIHByb2NlZHVyZS48YnI+DQo8YnI+DQpN YWpvciBpc3N1ZXM6IE5vbmU8YnI+DQo8YnI+DQpNaW5vciBpc3N1ZXM6IE5vbmU8YnI+DQo8YnI+ DQpOaXRzL2VkaXRvcmlhbCBjb21tZW50czo8YnI+DQo8YnI+DQpBcmUgRW5kIHBvaW50cyB0aGF0 IG5vdCByZXNwb25kaW5nIGNvbnNpZGVyZWQgJnF1b3Q7SW5hY3RpdmUgVGFpbHMmcXVvdDs/Jm5i c3A7IERvZXMgdGhlPGJyPg0KSGVhZEVuZCByZXBvcnQgdGhlICZxdW90O0luYWN0aXZlIFRhaWxz JnF1b3Q7Pzxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFz cz0iaG9lbnpiIj5MaW5kYSBEdW5iYXI8L3NwYW4+PGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F66B0764D4sjceml521mbschi_-- From nobody Fri Jun 29 10:07:01 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0761130DC7; Fri, 29 Jun 2018 10:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 BVRCf6Ul7_lc; Fri, 29 Jun 2018 10:06:51 -0700 (PDT) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::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 60AD5124C04; Fri, 29 Jun 2018 10:06:51 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id t21-v6so7860765lji.0; Fri, 29 Jun 2018 10:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Uax7kU/iTVcVDecltNGA8e5ufhBV6xYLSUs2756HY2Y=; b=mNQfSLkcaLsYyLtK9ZiSY4PbCUBUVDTXNazk8F4hZ21/RxJuoInynm68zH1wyQLbAr W3uBW1RVY/5XCT2Wv/zf9AT4vapWoogMHIegqZyJMJPW9KOL1qtjpWbLvafrqW++Hb5I F7Zn9s7XC5g3xXGpnbSAa3r9iRXQx+AO6GRbrFP5cXh9+0YdfL2qFAyvo1EFKF6bWBMT bXEAn+NrGqSG8NfWuqjp7ry3qxvA3qebdUfTlHTllKyWDEKytGkeIIeFAVyoctPpMA+O 2iBtyq+NeIwRA1K2/vCgL//rgTZwK+kGbMOxsB2kSVku8tKK6bGo3pTTMU6TTg2z8CxI +PMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Uax7kU/iTVcVDecltNGA8e5ufhBV6xYLSUs2756HY2Y=; b=nL466wdAIz5Rh6TZXYfPk/4JyVvODkG7nuFYpBLNOkOg+v7+G9V+vQ/aufRpJj5d/v 8xKzeV3/zH9qh1ACpaKmq1twthMxKgbg+RRbVGsGJ9a7L1Y0JIR8vP7yT0V6XX9OprQ0 0W8H6nOqqOS628BPMvBNKx4IWKB+MJHcR1QF6UJoCsYgFzvXAYAaadr5qBJtSalsAN5P /2lVPqvWsAolKKIuxf3wJizbEQxuNxk7jrtOYoV5E7agrzSuK6y7IZb4JyWJjJAWypWV ijl7gs+mNxICcRYrP0h7RRi3lM+hmYxrOalHLkcPxvnQMxIAXIhq33bYKgM7p9U5DbS1 0WTg== X-Gm-Message-State: APt69E0XORuZ5GVFj9jo1J2r1F4v5wof3C0WVTv9VjvQTESKlS7pK6/K c6iudAY33DGjY9l2IYLbR9wCNsAA8sp+PJvVoMU= X-Google-Smtp-Source: ADUXVKJQVnEEnI6Ka0RBCVAtsdEGnJFZs0jM/7nmqkx48EnnGxGXAwPWfCC6/YGDfPSsIYhwiWAhXXwKpz9/6ycoos8= X-Received: by 2002:a2e:c52:: with SMTP id o18-v6mr10571575ljd.72.1530292009554; Fri, 29 Jun 2018 10:06:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Fri, 29 Jun 2018 10:06:48 -0700 (PDT) In-Reply-To: References: <153020466705.14520.2646847580748723541.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Fri, 29 Jun 2018 10:06:48 -0700 Message-ID: Subject: Re: [Int-area] Fwd: New Version Notification for draft-mirsky-rtgwg-oam-identify-00.txt To: Tom Herbert Cc: rtg-bfd@ietf.org, Service Function Chaining IETF list , NVO3 , BIER WG , detnet@ietf.org, int-area Content-Type: multipart/alternative; boundary="000000000000a1d950056fcadfd6" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 17:06:54 -0000 --000000000000a1d950056fcadfd6 Content-Type: text/plain; charset="UTF-8" Hi Tom, many thanks for taking interest in the topic and helping with details on GUE and OAM. I've reviewed the listed in the draft encapsulations and analyzed how active OAM may be identified in each of the cases. For active OAM to be more useful the test packets must be in-band with the data that is being monitored. For the GUE case, I believe, that means that an OAM test packet will have all the values that characterize the monitored flow that may affect routing the packet with exception of values of C-bit and Proto/ctype field. Regards, Greg On Thu, Jun 28, 2018 at 2:31 PM, Tom Herbert wrote: > On Thu, Jun 28, 2018 at 1:34 PM, Greg Mirsky > wrote: > > Dear All, > > I hope that this new draft (yes, that's what I wanted to send the first > > time) will be of interest to those working on overlay encapsulations. > > Appreciate your comments, questions, and suggestions. > > > > Regarding OAM in GUE, the C bit can be set to indicate a control > packet which could be OAM (draft-ietf-intarea-gue-05). I imagine that > OAM could be implement in one or more ctypes. This is considered an > alternative to GUE carrying a data protocol payload, it's not > considered part of the GUE header and isn't limited by GUE header len. > > The statement in Geneve description "transit devices MUST NOT attempt > to interpret or process it" is true for all UDP encapsulation > protocols. The problem is that encapsulation is determined by > destination port number. As described in RFC7605, UDP port numbers > only have meaning at the endpoints, so transit devices may incorrectly > interpret packets as being an encapsulation. Incorrectly reading a > packet as encapsulation might be innocuous, but an intermediate node > modifying such a packet that it incorrectly believes is an > encapsulation would be systematic data corruption. Because of this, > probably the only robust method for in-situ OAM is Hop-by-Hop options. > > Tom > > > > > > Regards, > > Greg > > > > ---------- Forwarded message ---------- > > From: > > Date: Thu, Jun 28, 2018 at 9:51 AM > > Subject: New Version Notification for draft-mirsky-rtgwg-oam- > identify-00.txt > > To: Gregory Mirsky > > > > > > > > A new version of I-D, draft-mirsky-rtgwg-oam-identify-00.txt > > has been successfully submitted by Greg Mirsky and posted to the > > IETF repository. > > > > Name: draft-mirsky-rtgwg-oam-identify > > Revision: 00 > > Title: Identification of Overlay Operations, Administration, and > > Maintenance (OAM) > > Document date: 2018-06-28 > > Group: Individual Submission > > Pages: 9 > > URL: > > https://www.ietf.org/internet-drafts/draft-mirsky-rtgwg-oam- > identify-00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-mirsky-rtgwg-oam-identify/ > > Htmlized: > > https://tools.ietf.org/html/draft-mirsky-rtgwg-oam-identify-00 > > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-mirsky-rtgwg-oam-identify > > > > > > Abstract: > > This document analyzes how the presence of Operations, > > Administration, and Maintenance (OAM) control command and/or special > > data is identified in some overlay networks, and an impact on the > > choice of identification may have on OAM functionality. > > > > > > > > > > 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. > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > > --000000000000a1d950056fcadfd6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,
many thanks for taking interest in the topic a= nd helping with details on GUE and OAM. I've reviewed the listed in the= draft encapsulations and analyzed how active OAM may be identified in each= of the cases. For active OAM to be more useful the test packets must be in= -band with the data that is being monitored. For the GUE case, I believe, t= hat means that an OAM test packet will have all the values that characteriz= e the monitored flow that may=C2=A0affect routing the packet with exception= of values of C-bit and Proto/ctype=C2=A0field.=C2=A0

<= div>Regards,
Greg

On Thu, Jun 28, 2018 at 2:31 PM, Tom Herbert <tom@= herbertland.com> wrote:
On Thu, Jun 28, 2018 at 1:34 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
> Dear All,
> I hope that this new draft (yes, that's what I wanted to send the = first
> time) will be of interest to those working on overlay encapsulations.<= br> > Appreciate your comments, questions, and suggestions.
>

Regarding OAM in GUE, the C bit can be set to indicate a control
packet which could be OAM (draft-ietf-intarea-gue-05). I imagine that
OAM could be implement in one or more ctypes. This is considered an
alternative to GUE carrying a data protocol payload, it's not
considered part of the GUE header and isn't limited by GUE header len.<= br>
The statement in Geneve description "transit devices MUST NOT attempt<= br> to interpret or process it" is true for all UDP encapsulation
protocols. The problem is that encapsulation is determined by
destination port number. As described in RFC7605, UDP port numbers
only have meaning at the endpoints, so transit devices may incorrectly
interpret packets as being an encapsulation. Incorrectly reading a
packet as encapsulation might be innocuous, but an intermediate node
modifying such a packet that it incorrectly believes is an
encapsulation would be systematic data corruption. Because of this,
probably the only robust method for in-situ OAM is Hop-by-Hop options.

Tom




> Regards,
> Greg
>
> ---------- Forwarded message ----------
> From: <internet-drafts@= ietf.org>
> Date: Thu, Jun 28, 2018 at 9:51 AM
> Subject: New Version Notification for draft-mirsky-rtgwg-oam-iden= tify-00.txt
> To: Gregory Mirsky <gregim= irsky@gmail.com>
>
>
>
> A new version of I-D, draft-mirsky-rtgwg-oam-identify-00.txt
> has been successfully submitted by Greg Mirsky and posted to the
> IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-rtgwg-oam-<= wbr>identify
> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Identification of Overlay Ope= rations, Administration, and
> Maintenance (OAM)
> Document date:=C2=A0 2018-06-28
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
> URL:
> https://www.ietf.org= /internet-drafts/draft-mirsky-rtgwg-oam-identify-00.txt
> Status:
> https://datatracker.ietf.org/<= wbr>doc/draft-mirsky-rtgwg-oam-identify/
> Htmlized:
> https://tools.ietf.org/html/= draft-mirsky-rtgwg-oam-identify-00
> Htmlized:
> https://datatracker.ietf.o= rg/doc/html/draft-mirsky-rtgwg-oam-identify
>
>
> Abstract:
>=C2=A0 =C2=A0 This document analyzes how the presence of Operations, >=C2=A0 =C2=A0 Administration, and Maintenance (OAM) control command and= /or special
>=C2=A0 =C2=A0 data is identified in some overlay networks, and an impac= t on the
>=C2=A0 =C2=A0 choice of identification may have on OAM functionality. >
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat
>
>
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-ar= ea
>

--000000000000a1d950056fcadfd6-- From nobody Fri Jun 29 10:17:23 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC53130DDD; Fri, 29 Jun 2018 10:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 wAzVsUTzVRal; Fri, 29 Jun 2018 10:17:03 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E030130DDB; Fri, 29 Jun 2018 10:17:03 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id v15-v6so7880533ljk.5; Fri, 29 Jun 2018 10:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DZJUjMLZAsMADSRW4EoJRwWcnwbcjCTnJ1wFeJCydi8=; b=rfAE1CzlPQIxrSLydiCjwNx97k0PTEEHebVC0FJkaOxa66LJ3//oIt7KgxwzI1hP3Y GhyfjvAsrx4mbQTA4XMO7kT4uSHJAlw2ATdQ5JOC6fdRjfBZQD3CDFHvwgTFct2ddcp0 YES0AfRNcO/jX5S3kaJe8+cMlbPkxgAlKvUq/gvBLJzoTajSjV7zpgmN15J+R9t1TMWJ jQnJ/XQdUy5otTCUGhMXJIK6UZWr3k3u4to0kQp66PcMsYCkMWnbRW50uloEx0bElENz J/yO3AcNtVYzJqpbEv+xUwjOo7nhoxUNKSjfl1dlwXXb3IE9KxDdQMBzEfz4suWOwRpf AfcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DZJUjMLZAsMADSRW4EoJRwWcnwbcjCTnJ1wFeJCydi8=; b=kOEm67XYrj4/APpimJdCIdOVbEPkKDbz6f+2LznFDPdU7T0GRiA/PrDEb21R7spbTU ua3PzS3AgbZsBvERtaLITD7zPETOfWeGIL1fsXC12pG4O+N3va1Dy9vVsfRwvYzsWqUH lhUf77wxSTA+pMyBRCCEF246+LOWM9ltTOoQiHrv5EpE59Pns23aOFh3YuH9MOBn72zh be42Y6oqlBXGpfKeTRCNv3IRDxIjmSK5ARBf4nUAWfwhQaj8+kFB+FgJcVfPcBeTHe17 NMciW9Kn9vVAjpUTND74Pc+ARfXPP2L9NUNxFbokGMjR3KOelrbkRzUUKRByXT2YlT0j NPaA== X-Gm-Message-State: APt69E3RD5weUQZG/3gEUYk5EwruhMW7QpdLqrNiHGtowl7XeBrseuxP ru0cIMrT5e3nqXm2wAgyTZ+ARfj++541q2L7bfc= X-Google-Smtp-Source: ADUXVKKzS3rYcPaYHgydzzEXQ0KTt4mCeM4KzAwFvvv6ygv0r0V424CMbnaguQ/ZhMiFRrxt05KGC8uYckQDAQbyzYM= X-Received: by 2002:a2e:c52:: with SMTP id o18-v6mr10591550ljd.72.1530292621263; Fri, 29 Jun 2018 10:17:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Fri, 29 Jun 2018 10:17:00 -0700 (PDT) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B0764D4@sjceml521-mbs.china.huawei.com> References: <153021423641.18488.4659084638238812446@ietfa.amsl.com> <4A95BA014132FF49AE685FAB4B9F17F66B0764D4@sjceml521-mbs.china.huawei.com> From: Greg Mirsky Date: Fri, 29 Jun 2018 10:17:00 -0700 Message-ID: Subject: Re: Genart last call review of draft-ietf-bfd-multipoint-active-tail-09 To: Linda Dunbar Cc: "gen-art@ietf.org" , "rtg-bfd@ietf.org" , IETF list , "draft-ietf-bfd-multipoint-active-tail.all@ietf.org" Content-Type: multipart/alternative; boundary="00000000000017c7e6056fcb04bd" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 17:17:15 -0000 --00000000000017c7e6056fcb04bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Linda, thank you for the question. Always happy to discuss the technology. If the head is required to know the state of the set of the tails, then using p2p BFD session between the head and each of such tails may be the right solution. But it may be challenging to ensure that the unicast path from the head to each of the tails in that set is co-routed with the multicast path used to transport the data. The use of p2mp BFD does ensure that the BFD control packets transmitted by the head follow exactly the same path as data packets of the monitored flow. Regards, Greg On Fri, Jun 29, 2018 at 9:51 AM, Linda Dunbar wrote: > Greg, > > > > Thanks for the reply. > > > > It might be too late to ask this question, I am curious if the head-end i= s > aware of the list of end points, what is wrong if they just use unicast B= FD > to each of them? Multicast-BFD seems requires more support of the network= , > isn=E2=80=99t it? > > > > Linda > > > > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* Friday, June 29, 2018 11:45 AM > *To:* Linda Dunbar > *Cc:* gen-art@ietf.org; rtg-bfd@ietf.org; IETF list ; > draft-ietf-bfd-multipoint-active-tail.all@ietf.org > *Subject:* Re: Genart last call review of draft-ietf-bfd-multipoint- > active-tail-09 > > > > Hi Linda, > > thank you for the review and your kind words, much appreciated. > > > > If an end-point during the p2mp BFD session never responded to the head's > multicast poll it is unknown to the head and cannot be reported as > "inactive tail". I can imagine that if the head has been given the list o= f > the tails, then the unresponsive end-point can be reported as "inactive > tails". > > > > Regards, > > Greg > > > > On Thu, Jun 28, 2018 at 12:30 PM, Linda Dunbar > wrote: > > Reviewer: Linda Dunbar > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-bfd-multipoint-active-tail-?? > Reviewer: Linda Dunbar > Review Date: 2018-06-28 > IETF LC End Date: 2018-06-18 > IESG Telechat date: 2018-07-05 > > Summary: clear writing of the procedure. > > Major issues: None > > Minor issues: None > > Nits/editorial comments: > > Are End points that not responding considered "Inactive Tails"? Does the > HeadEnd report the "Inactive Tails"? > > Linda Dunbar > > > --00000000000017c7e6056fcb04bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Linda,
thank you for the question. Always happy to = discuss the technology.

If the head is required to= know the state of the set of the tails, then using p2p BFD session between= the head and each of such tails may be the right solution. But it may be c= hallenging to ensure that the unicast path from the head to each of the tai= ls in that set is co-routed with the multicast path used to transport the d= ata. The use of p2mp BFD does ensure that the BFD control packets transmitt= ed by the head follow exactly the same path as data packets of the monitore= d flow.

Regards,
Greg

On Fri, Jun 29, 2018 at = 9:51 AM, Linda Dunbar <linda.dunbar@huawei.com> wrote:=

Greg,

=C2=A0

Thanks for the reply.

=C2=A0

It might be too late to ask this ques= tion, I am curious if the head-end is aware of the list of end points, what= is wrong if they just use unicast BFD to each of them? Multicast-BFD seems requires more support of the network, isn=E2= =80=99t it?

=C2=A0

Linda

=C2=A0

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Friday, June 29, 2018 11:45 AM
To: Linda Dunbar <linda.dunbar@huawei.com>
Cc: gen-art@ie= tf.org; rtg-bfd@i= etf.org; IETF list <ietf@ietf.org>; draft-ietf-bfd-multipoint-activ= e-tail.all@ietf.org
Subject: Re: Genart last call review of draft-ietf-bfd-multipoint-active-tail-09

=C2=A0

Hi Linda,

thank you for the review and your kind words, much a= ppreciated.

=C2=A0

If an end-point during the p2mp BFD session never re= sponded to the head's multicast poll it is unknown to the head and cann= ot be reported as "inactive tail". I can imagine that if the head= has been given the list of the tails, then the unresponsive end-point can be reported as "inactive tails".

=C2=A0

Regards,

Greg

=C2=A0

On Thu, Jun 28, 2018 at 12:30 PM, Linda Dunbar <<= a href=3D"mailto:Linda.dunbar@huawei.com" target=3D"_blank">Linda.dunbar@hu= awei.com> wrote:

Reviewer: Linda Dunba= r
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-bfd-multipoint-active-tail-??
Reviewer: Linda Dunbar
Review Date: 2018-06-28
IETF LC End Date: 2018-06-18
IESG Telechat date: 2018-07-05

Summary: clear writing of the procedure.

Major issues: None

Minor issues: None

Nits/editorial comments:

Are End points that not responding considered "Inactive Tails"?= =C2=A0 Does the
HeadEnd report the "Inactive Tails"?

Linda Dunbar

=C2=A0


--00000000000017c7e6056fcb04bd-- From nobody Sat Jun 30 08:16:53 2018 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 798EA12D949; Sat, 30 Jun 2018 08:16:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-bfd-multipoint@ietf.org, Reshad Rahman , bfd-chairs@ietf.org, rrahman@cisco.com, rtg-bfd@ietf.org Subject: Alexey Melnikov's No Objection on draft-ietf-bfd-multipoint-18: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153037181249.26424.1683177097893955126.idtracker@ietfa.amsl.com> Date: Sat, 30 Jun 2018 08:16:52 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 15:16:53 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-bfd-multipoint-18: 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-bfd-multipoint/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is a very readable document, so thank you for that. One small nit: In Section 5.6, last sentence of the first paragraph says: All other information MAY be determined dynamically. This is not correct use of RFC 2119 MAY, because it doesn't look like an implementation choice. I suggest you change it to lowercase "may" or "can". From nobody Sat Jun 30 11:18:24 2018 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B7F130DC9; Sat, 30 Jun 2018 11:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 4j9rck_xT_CO; Sat, 30 Jun 2018 11:18:12 -0700 (PDT) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::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 6D663130DE1; Sat, 30 Jun 2018 11:18:09 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id u6-v6so9669304lju.13; Sat, 30 Jun 2018 11:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gftiJHZY75CrasRTw/H5LakqSLjrmd5D+uB1lu1dgpE=; b=vRwojjIMS3b3OCVFFSI5CKVoQ05u1CxGyiM4jAjUBaJNODwSGdlCvB3SkG/sAeC0rJ J7oHvnY6gR0l9fY3OQlJWVQsambVlcrP0GTCIPxxIBuHM9JxFEz4siAhN4v+X3gjCj4Y c4o2MC+u5mnW8qe2L4tL/WLAH+3yFCPah+hSHCJ5CfX9uwu/WnHZZj8N7n5ecvpRjTl3 GneJH3mKHOIcj7yGwDEQwo2nedlM4XKYz8PyELzXl5cAgAqoqAhPF4Vy6pTV4lVK9eRh VRnBd1UaYVBj8EeoZEoO4z809EtBMrLE+l9nQoE5op5blBx4/TxUzZTPYuueA9fZ/Zsd OkBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gftiJHZY75CrasRTw/H5LakqSLjrmd5D+uB1lu1dgpE=; b=C/l87pNGDxX+jqO/UP/M/zO4Cyj8PBJabqRr9G+t1No7HT8Su/zApkG4wCZK3bqqde we4fiWupx4ZxjByE5FTXP+DsM7S8kwlk0FnPQJ4o2Q8Rl5RyGU2vfA7h+CbqFQ+8FuHS uw97FrnDzECcq7wq0h9hjS+t+2IPJyf8LuYRSgY+qxJzifmnZPY9qyyGoEUcMxM6WvFZ zZuCyOeixI9gTpZxzrfJ5/IxVGl9jbUwSb2phJDJUBQL7hgqk4Njj5IVLo3GE9leaie0 4LegvdEzb0f/K+WWTGwdqMk7+bMwhbtHwhuoN8CQsEZmblSamqzCJhh/+w0SkBt8wPtN AliA== X-Gm-Message-State: APt69E18ZI36/cxr++xaa7C+lxC1zZ/pe7N3UzgWzRcNccKwjatjDXfR C64FPnxvNofEh0LDld4IQuHN0N3qHzIo5pQgKcU= X-Google-Smtp-Source: AAOMgpf+Lx6Kbath705ykx8FHubOpyEdv12GR99gdkb+zk35TlZ5X/+TUii4/Bm+rz/irDK+F5uwHkQfvXz6ORDABQw= X-Received: by 2002:a2e:2161:: with SMTP id h94-v6mr13879440ljh.58.1530382687685; Sat, 30 Jun 2018 11:18:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Sat, 30 Jun 2018 11:18:07 -0700 (PDT) In-Reply-To: <153037181249.26424.1683177097893955126.idtracker@ietfa.amsl.com> References: <153037181249.26424.1683177097893955126.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Sat, 30 Jun 2018 11:18:07 -0700 Message-ID: Subject: Re: Alexey Melnikov's No Objection on draft-ietf-bfd-multipoint-18: (with COMMENT) To: Alexey Melnikov Cc: The IESG , draft-ietf-bfd-multipoint@ietf.org, Reshad Rahman , bfd-chairs@ietf.org, rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary="00000000000078509a056fdffca2" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 18:18:15 -0000 --00000000000078509a056fdffca2 Content-Type: text/plain; charset="UTF-8" Hi Alexey, thank you for the review and your kind words. Will change to "can" and publish in the next version. Regards, Greg On Sat, Jun 30, 2018 at 8:16 AM, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-bfd-multipoint-18: 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-bfd-multipoint/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This is a very readable document, so thank you for that. One small nit: > > In Section 5.6, last sentence of the first paragraph says: > > All other information MAY be determined dynamically. > > This is not correct use of RFC 2119 MAY, because it doesn't look like an > implementation choice. I suggest you change it to lowercase "may" or "can". > > > --00000000000078509a056fdffca2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alexey,
thank you for the review and your kind word= s.

Will change to "can" and publish in t= he next version.

Regards,
Greg

On Sat, Jun 30,= 2018 at 8:16 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
Alexey Melnikov has entered th= e following ballot position for
draft-ietf-bfd-multipoint-18: 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/<= wbr>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/dra= ft-ietf-bfd-multipoint/



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

This is a very readable document, so thank you for that. One small nit:

In Section 5.6, last sentence of the first paragraph says:

=C2=A0 =C2=A0All other information MAY be=C2=A0 =C2=A0determined dynamicall= y.

This is not correct use of RFC 2119 MAY, because it doesn't look like a= n
implementation choice. I suggest you change it to lowercase "may"= or "can".



--00000000000078509a056fdffca2--