From nobody Sun Apr 1 07:07: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 ADFD9126B7E; Sun, 1 Apr 2018 07:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 8u8vjn8mh_os; Sun, 1 Apr 2018 07:07:05 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-oln040092006058.outbound.protection.outlook.com [40.92.6.58]) (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 0800312422F; Sun, 1 Apr 2018 07:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kRglhTZyhupClK90jmuQokVwg9vdSDYpbS31b86FhVM=; b=jNtodmeK+OmyWj8TKv3+HsEovWY9Cg0PfS7Xnj7vT+Stqi0KYrjOJBrRQ+tQzwphORhE/57JO+T+MQsNkb01eWIB7GuDG4bHkOsqw/nucDidy6jpVIE59sDkbf+EGV2mz3mVqhgmnA5Aqk/sBGMvOrEDr3LaNF9wYzzXgBZz8rB+CRZ3l39d1+DVWWmCWRRFGUhoNi0Ct4LnNSdwDst381kHwwolzNOaJv/pUvxh2UdIaDauOhy19x0X5/U+h5GrRirrl/EZrvlr/SQ9MkwQniNk1s4H8bav1Xzn+GS9tO5kfWKStC3hsaI/XTjTatcszAMsnFK4bkefmSLwZWwQqg== Received: from BY2NAM03FT029.eop-NAM03.prod.protection.outlook.com (10.152.84.58) by BY2NAM03HT032.eop-NAM03.prod.protection.outlook.com (10.152.85.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.631.7; Sun, 1 Apr 2018 14:07:04 +0000 Received: from BL0PR0102MB3345.prod.exchangelabs.com (10.152.84.52) by BY2NAM03FT029.mail.protection.outlook.com (10.152.84.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.631.7 via Frontend Transport; Sun, 1 Apr 2018 14:07:04 +0000 Received: from BL0PR0102MB3345.prod.exchangelabs.com ([fe80::a5f3:348:c9a1:1754]) by BL0PR0102MB3345.prod.exchangelabs.com ([fe80::a5f3:348:c9a1:1754%3]) with mapi id 15.20.0631.013; Sun, 1 Apr 2018 14:07:04 +0000 From: Ashesh Mishra To: Jeffrey Haas , "draft-ietf-bfd-secure-sequence-numbers@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: Comments on secure sequence number draft Thread-Topic: Comments on secure sequence number draft Thread-Index: AQHTxrauLV/wJdX/MEqu8zTlAaSnU6Pr9Tre Date: Sun, 1 Apr 2018 14:07:03 +0000 Message-ID: References: <20180328170335.GE3126@pfrc.org> In-Reply-To: <20180328170335.GE3126@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:F2EE71DD01AC022823A158B6C028C68B63C09C7978398F761CDA2E8D73D2BCA7; UpperCasedChecksum:A8910FBADCAFE3D497956BF66D43EA6AC5FA04FE6BB37501F756644BFA684D8E; SizeAsReceived:7150; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [cJJAxLk1W07M6KlR2Ef04ckX4+daTh0Y] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2NAM03HT032; 7:Fw4ZOp/eh0IPChoGK1FgLfT1nqlWIZN24IKgUatfPwZn2IMPY6EX3HbfndC0fr/Ym4zkd0GZAOdRX8fWd2esvr1+tXHkmxwnwN63TsNOOlfypaoXvksOiJ2Dr/GlWt4hcwpGVRHT/qKSmkNMb2DJv16FyDbwtzQRoY8NJ0F7ZU+BWeYrRX2rWQJ4+h05hNG40yWG0Iuco5s/IArnd2XgyixSgZl0998M4TpNwldx4Ec5xSwpa/WMqRBACc5QdQRv x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:BY2NAM03HT032; x-ms-traffictypediagnostic: BY2NAM03HT032: x-ms-office365-filtering-correlation-id: 56dd6e44-5a80-4f01-cf16-08d597d9d8a5 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BY2NAM03HT032; BCL:0; PCL:0; RULEID:; SRVR:BY2NAM03HT032; x-forefront-prvs: 06290ECA9D x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:BY2NAM03HT032; H:BL0PR0102MB3345.prod.exchangelabs.com; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: rnOGD5sOV9aKzN/elL5i5s9gnltPC3p0EpFvkKK7SUWW30Sux0Ygx6rTXWCm5GmtImlF1EmiEguAsxyIXm/n9c/7qFQ1Stgfdrk/XKCvN+WCAf61wctkxOBuimggyxPYg947e2OQTHTkhjYzA/ZRLMNR4Aqe63mxnFXquPSpRFstjE5XMYR1Hs5qmARFhSRl spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR0102MB3345E7EC829E7C74BE5A41A0FAA70BL0PR0102MB3345_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 56dd6e44-5a80-4f01-cf16-08d597d9d8a5 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2018 14:07:03.7329 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM03HT032 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: Sun, 01 Apr 2018 14:07:07 -0000 --_000_BL0PR0102MB3345E7EC829E7C74BE5A41A0FAA70BL0PR0102MB3345_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jeff, You noted a couple if great questions. Since there aren't any more fields l= eft in the BFD packet or TLVs to overload for this function (the AUTH TYPE = field, which is the only usable field for overloading, is being used for de= fining new TLVs so we didn't want to use it as this method doesn't change t= he packet format), the clean way to configure secure sequence numbers is by= coordinating configuration on the two end-points (the keys will need to be= configured on each end point, so the knob to turn the feature on can resid= e there as well). It would have been infinitely simpler if there was an "experimental" or "fu= ture use" field in the BFD packet :) I'll defer the YANG question to our YANG expert author, Mahesh. I'll add text to the security considerations. -- Ashesh ________________________________ From: Rtg-bfd on behalf of Jeffrey Haas Sent: Wednesday, March 28, 2018 10:03:35 AM To: draft-ietf-bfd-secure-sequence-numbers@ietf.org; rtg-bfd@ietf.org Subject: Comments on secure sequence number draft Authors, A few comments on your draft in no particular order: Operational Considerations: - How do you go about enabling this feature? + It's independent of, but recommended for, optimizing BFD authentication= . - What are the yang considerations? + Similar point - changes to the yang model for optimizing authentication likely need this as a separate knob. - The Security Considerations section is empty. That needs to be fixed. -- Jeff --_000_BL0PR0102MB3345E7EC829E7C74BE5A41A0FAA70BL0PR0102MB3345_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jeff, 


You noted a couple if great quest= ions. Since there aren't any more fields left in the BFD packet or TLVs to = overload for this function (the AUTH TYPE field, which is the only usable f= ield for overloading, is being used for defining new TLVs so we didn't want to use it as this method doesn't c= hange the packet format), the clean way to configure secure sequence number= s is by coordinating configuration on the two end-points (the keys wil= l need to be configured on each end point, so the knob to turn the feature on can reside there as well). 


It would have been infinitely sim= pler if there was an "experimental" or "future use" fie= ld in the BFD packet :)


I'll defer the YANG question to o= ur YANG expert author, Mahesh. 


I'll add text to the security con= siderations. 


--

Ashesh

From: Rtg-bfd <rtg-bfd-b= ounces@ietf.org> on behalf of Jeffrey Haas <jhaas@pfrc.org>
Sent: Wednesday, March 28, 2018 10:03:35 AM
To: draft-ietf-bfd-secure-sequence-numbers@ietf.org; rtg-bfd@ietf.or= g
Subject: Comments on secure sequence number draft
 
Authors,

A few comments on your draft in no particular order:

Operational Considerations:
- How do you go about enabling this feature?
  + It's independent of, but recommended for, optimizing BFD authe= ntication.
- What are the yang considerations? 
  + Similar point - changes to the yang model for optimizing authe= ntication
    likely need this as a separate knob.

- The Security Considerations section is empty.  That needs to be fixe= d.

-- Jeff

--_000_BL0PR0102MB3345E7EC829E7C74BE5A41A0FAA70BL0PR0102MB3345_-- From nobody Sun Apr 1 07:54:30 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 38142126BF6 for ; Sun, 1 Apr 2018 07:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 0JMqOYPcuz6u for ; Sun, 1 Apr 2018 07:54:25 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-oln040092008037.outbound.protection.outlook.com [40.92.8.37]) (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 0A184124C27 for ; Sun, 1 Apr 2018 07:54:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/HhLzY4od4MxTJQjvxAV+sBw8vLZPdMfOX5G4Mm1HqI=; b=Lr+YPfVCglFCeDcc6GZEm+PSnuRCCfd5wAKJ30EFsBEGRMBjL9zS1ODujozl+jA9aGcKUxakfUg7gxe6CLnHCN++iFay4DWpZhA4VTOf1QsWu2nbm7jHlMhB8NedhQ4do4FEcp9WrV8Tbvjis3Fgln6vGlh1jnCUK5GPet4oHLrCrZvkUTQ7/YlUxY4CcdyItyF2qNO/GJeZIQg+Pjq1K88aQdIuyVckdUiE08CvRD2bMYs27+TIQvmUQ5bIIugSoVfa/G3vRz3AjElW3lLbao0qpyDJC3p5GZSbGu3AtXdVtREdnx64CxkXI6DW7SRGSSWzCgbaPnqViTpf7GTluQ== Received: from DM3NAM03FT058.eop-NAM03.prod.protection.outlook.com (10.152.82.57) by DM3NAM03HT029.eop-NAM03.prod.protection.outlook.com (10.152.83.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.631.7; Sun, 1 Apr 2018 14:54:23 +0000 Received: from BL0PR0102MB3345.prod.exchangelabs.com (10.152.82.59) by DM3NAM03FT058.mail.protection.outlook.com (10.152.82.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.631.7 via Frontend Transport; Sun, 1 Apr 2018 14:54:23 +0000 Received: from BL0PR0102MB3345.prod.exchangelabs.com ([fe80::a5f3:348:c9a1:1754]) by BL0PR0102MB3345.prod.exchangelabs.com ([fe80::a5f3:348:c9a1:1754%3]) with mapi id 15.20.0631.013; Sun, 1 Apr 2018 14:54:23 +0000 From: Ashesh Mishra To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: Tuning BFD session times Thread-Topic: Tuning BFD session times Thread-Index: AQHTxsWKBNltmss7WESLSBbS7Nadv6Pr+Fuy Date: Sun, 1 Apr 2018 14:54:23 +0000 Message-ID: References: <20180328184959.GB25442@pfrc.org> In-Reply-To: <20180328184959.GB25442@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:32DF6C8C01AF7F7E7543D20AB6ED0334E3C267BC03298350A58A46FE328FE7E8; UpperCasedChecksum:1B632A229825BC73D398E31A80E4C31362373C40722AB102299B2CCABC7C00B6; SizeAsReceived:6980; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [E72Ogy6C21uFGp7SvMESO8qFjng+zNJF] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM3NAM03HT029; 7:wUxz2poDuHA8ZT1kSy1g6qbzUpNUE2aBIBhLPTm4YbUcNaQA/QmGiuteNokswFgyrQ2NqI843+9kOXOkndpvbNqKKRAV1XjKHB9SAhpZeO5lEBvNJh07WGbfs1iN/26+dJ4tS6kUb+UIEBmjvKXnyemIlGQh0OLqkKEpHR/Z3KcUYQ/nlVorv4agAasIvicP9UPrPfUAQk3pTHKBAKt1dA93ezPZiX5utZN4j1XuVutzS7+kAjGSO/yhksA6Dbqa x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:DM3NAM03HT029; x-ms-traffictypediagnostic: DM3NAM03HT029: x-ms-office365-filtering-correlation-id: e3a32071-af59-47a4-0e3d-08d597e07543 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:DM3NAM03HT029; BCL:0; PCL:0; RULEID:; SRVR:DM3NAM03HT029; x-forefront-prvs: 06290ECA9D x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:DM3NAM03HT029; H:BL0PR0102MB3345.prod.exchangelabs.com; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: guTi6JrJYVwfFQHiBr/FCBYi7m/2A+86M7wIKYeOHYnHR65E3w4gi4CKSoAOMVn6NyA2ieFZDi3kGXKAW4OQAHxVLRdm0Yr+i52vb7lYWCouIzic5UKe4J7leZwADI35uRy7KjcppzhgB3cJJ2HCRP7aFR2vM2nn9TPyLmg+gz3/jH+TcCOP4C9bEDZNjVYX spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR0102MB3345EC535EE558FC4CC692E6FAA70BL0PR0102MB3345_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e3a32071-af59-47a4-0e3d-08d597e07543 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2018 14:54:23.7496 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3NAM03HT029 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: Sun, 01 Apr 2018 14:54:28 -0000 --_000_BL0PR0102MB3345EC535EE558FC4CC692E6FAA70BL0PR0102MB3345_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jeff, thanks for kicking-off this discussion on the list! One additional comment that I wanted to make was around automation. There w= ere questions during the meeting around the need for auto-tuning and that t= he process of determining the interval can/should be manual. The automation of control in all aspects of dynamic behavior is a priority = for network operators. When configuring manually, parameters such BFD inter= vals are typically set at very conservative values because human latency is= very high when responding to changing network conditions. Manual configura= tion also takes a lot of time and is accounts for significant number of los= t opportunities and value for operators. [JH] "applications should generally choose a detection interval that is rea= soanble for their application rather than try to dynamically discover the l= owest possible stable detection interval. " [AM] This depends on the use-case. From the point-of-view of a service prov= ider that delivers long-haul connectivity (typical scenario in which the li= nk characteristics have large variance) then the intent is to provide the b= est performance. As such providers deliver connectivity to critical applica= tions, and are often the only way of delivering connectivity in such places= , the ability to tune the system to deliver an up-time that is superior dri= ves significant value. Consider a scenario where there is a 130ms RTT link = (MEO satellite, LEO will be in the 20-60ms range) and its backup is a 600ms= RTT link (GEO satellite), and are being used to deliver transit connectivi= ty. The rate at which the end-to-end service can run BFD is significantly f= aster when MEO is active versus when GEO is active. The application, in thi= s scenario, may survive the RTT, but the business continuity is critical in= many cases. Since the provider of long-haul can not control the applicatio= n, it must provide the best possible failover performance. [JH] "1. BFD is asymmetric. This means a receiving BFD implementation must= provide feedback to a sending implementation in order for it to understand= perceived reliability." [AM] May not need to be the BFD implementation providing the feedback if th= ere are other performance mechanisms running. The challenge is to standardi= ze the mechanism that BFD can use (if the measurement is not self-contained= in BFD). You're right in pointing out the challenge in accounting for the = CPU delays and that was the reason for the original proposal for BFD perfor= mance measurement. If the measurement is within the BFD realm, it will acco= unt for the CPU delays. However, most good BFD engines have relatively dete= rministic performance and are quite optimized so the variance with scale an= d time is not significant (but I concede that not all BFD implementations a= re good). [JH] "2. Measurement infrastructure may negatively impact session scale. G= reg, I believe, made this point when discussing host processing issues vs. = BFD ingress/egress." [AM] This is an issue if using a measurement mechanism within BFD (other pe= rformance measurement methods are always running in network for SLA reporti= ng and/or network optimization). Within a metro-area with fiber or terrestr= ial wireless (microwave, LTE, etc.) connectivity, I would likely not need c= onstant auto-tuning. The variance in the primary and backup links in such n= etwork will not be significant to affect the BFD parameters. In long-haul l= inks, this may be a valuable feature in which case, the additional overhead= may be justified. So it depends on the use-case whether continuous auto-tu= ning is required or if it is one-time. [JH] "3. Detection interval calculations really need to take into account t= hings that are greater than simple packet transmission times. As an exampl= e, if your measurement is always taken during low system CPU or network act= ivity, how high is your confidence about the interval? What about scaling = vs. number of total BFD sessions?" [AM] Great questions. Typically when running BFD or CFM (or similar) high f= requency OAM, CPU peaks should not affect the OAM performance (a variety of= methods, based on the system on which OAM is running, can ensure that). CP= U peaks become a bigger issue if BFD is used to detect continuity for a par= ticular flow (or QoS). -- Asheh ________________________________ From: Rtg-bfd on behalf of Jeffrey Haas Sent: Wednesday, March 28, 2018 11:49 AM To: rtg-bfd@ietf.org Subject: Tuning BFD session times Working Group, We had very active discussion (yay!) at the microphone as part of Mahesh's presentation on BFD Performance Measurement. (draft-am-bfd-performance) I wanted to start this thread to discuss the greater underlying issues this discussion raised. In particular, active tuning of BFD session parameters. Please note that opinions I state here are as an individual contributor. BFD clients typically want the fastest, most stable detection interval that is appropriate to their application. That stability component is very important since too aggressive of timers can result in unnecessary BFD session instability which will impact the subscribing application. Such stability is a function of many things, scale of the system running BFD being a major one. In my opinion, applications should generally choose a detection interval that is reasoanble for their application rather than try to dynamically discover the lowest possible stable detection interval. This is because a number of unstable factors, such as CPU load, contention with other network traffic and other things that are outside the general control of many sytems may impact such scale. That said, here's a few thoughts on active feedback mechanisms: 1. BFD is asymmetric. This means a receiving BFD implementation must provi= de feedback to a sending implementation in order for it to understand perceived reliability. 2. Measurement infrastructure may negatively impact session scale. Greg, I believe, made this point when discussing host processing issues vs. BFD ingress/egress. 3. Detection interval calculations really need to take into account things that are greater than simple packet transmission times. As an example, if your measurement is always taken during low system CPU or network activity, how high is your confidence about the interval? What about scaling vs. number of total BFD sessions? I have no strong conclusions here, just some cautionary thoughts. What are yours? -- Jeff --_000_BL0PR0102MB3345EC535EE558FC4CC692E6FAA70BL0PR0102MB3345_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Jeff, t<= span style=3D"font-size: 12pt;">hanks for kicking-off this discussion on th= e list!


One addi= tional comment that I wanted to make was around automation. There were= questions during the meeting around the need for auto-tuning and that the = process of determining the interval can/should be manual.


The auto= mation of control in all aspects of dynamic behavior is a priority for netw= ork operators. When configuring manually, parameters such BFD intervals are= typically set at very conservative values because human latency is very high when responding to changing netw= ork conditions. Manual configuration also takes a lot of time and is accoun= ts for significant number of lost opportunities and value for operators.&nb= sp;


[JH]&= nbsp;"applications sh= ould generally choose a detection interval that is reasoanble for their application rather than try to dynamically discover the lowest possible stable dete= ction interval. "<= /i>

[AM] Thi= s depends on the use-case. From the point-of-view of a service provider tha= t delivers long-haul connectivity (typical scenario in which the link chara= cteristics have large variance) then the intent is to provide the best performance. As such providers deliver c= onnectivity to critical applications, and are often the only way of deliver= ing connectivity in such places, the ability to tune the system to deliver = an up-time that is superior drives significant value. Consider a scenario where there is a 130ms RTT link (ME= O satellite, LEO will be in the 20-60ms range) and its backup is a 600ms RT= T link (GEO satellite), and are being used to deliver transit connectivity.= The rate at which the end-to-end service can run BFD is significantly faster when MEO is active versus when= GEO is active. The application, in this scenario, may survive the RTT, but= the business continuity is critical in many cases. Since the provider of l= ong-haul can not control the application, it must provide the best possible failover performance. 


[JH] "1. BFD is asymmetric= .  This means a receiving BFD implementation must provide = feedback to a sending implementation in order for it to understand = perceived reliability.&= quot;

[AM] May not need to be the= BFD implementation providing the feedback if there are other performance m= echanisms running. The challenge is to standardize the mechanism that BFD can use (if the measurement is not s= elf-contained in BFD). You're right in pointing out the challenge in accoun= ting for the CPU delays and that was the reason for the original proposal f= or BFD performance measurement. If the measurement is within the BFD realm, it will account for the CPU de= lays. However, most good BFD engines have relatively deterministic performa= nce and are quite optimized so the variance with scale and time is not sign= ificant (but I concede that not all BFD implementations are good). 


[JH] "2. Measurement infra= structure may negatively impact session scale.  Greg, I believe, made this point when discussing host processing issues vs. BFD ingress/egress.&qu= ot;

[AM] This is an issue if us= ing a measurement mechanism within BFD (other performance measurement metho= ds are always running in network for SLA reporting and/or network optimization). Within a metro-area with = fiber or terrestrial wireless (microwave, LTE, etc.) connectivity, I would = likely not need constant auto-tuning. The variance in the primary and backu= p links in such network will not be significant to affect the BFD parameters. In long-haul links, this may be a valuable f= eature in which case, the additional overhead may be justified. So it depen= ds on the use-case whether continuous auto-tuning is required or if it is o= ne-time. 


[JH] "3. Detection interval calculations re= ally need to take into account things that are greater than simple packet transmission times.  As an example, if your measurement is always taken duri= ng low system CPU or network activity, how high is your confidence about the interval?  What about scaling vs. number of total BFD sessions?&qu= ot;

[AM] Great questions. Typically when running BFD or CFM (or similar) h= igh frequency OAM, CPU peaks should not affect the OAM performance (a varie= ty of methods, based on the system on which OAM is running, can ensure= that). CPU peaks become a bigger issue if BFD is used to detect continuity for a particular flow (or QoS). 

--
Asheh

From: Rtg-bfd <rtg-bfd-b= ounces@ietf.org> on behalf of Jeffrey Haas <jhaas@pfrc.org>
Sent: Wednesday, March 28, 2018 11:49 AM
To: rtg-bfd@ietf.org
Subject: Tuning BFD session times
 
Working Group,

We had very active discussion (yay!) at the microphone as part of Mahesh's<= br> presentation on BFD Performance Measurement.
(draft-am-bfd-performance)

I wanted to start this thread to discuss the greater underlying issues this=
discussion raised.  In particular, active tuning of BFD session parame= ters.
Please note that opinions I state here are as an individual contributor.
BFD clients typically want the fastest, most stable detection interval that=
is appropriate to their application.  That stability component is very=
important since too aggressive of timers can result in unnecessary BFD
session instability which will impact the subscribing application.  Su= ch
stability is a function of many things, scale of the system running BFD
being a major one.

In my opinion, applications should generally choose a detection interval that is reasoanble for their application rather than try to dynamically
discover the lowest possible stable detection interval.  This is becau= se a
number of unstable factors, such as CPU load, contention with other network=
traffic and other things that are outside the general control of many
sytems may impact such scale.

That said, here's a few thoughts on active feedback mechanisms:
1. BFD is asymmetric.  This means a receiving BFD implementation must = provide
   feedback to a sending implementation in order for it to unders= tand
   perceived reliability.
2. Measurement infrastructure may negatively impact session scale.  Gr= eg, I
   believe, made this point when discussing host processing issue= s vs. BFD
   ingress/egress.
3. Detection interval calculations really need to take into account things<= br>    that are greater than simple packet transmission times.  = As an example,
   if your measurement is always taken during low system CPU or n= etwork
   activity, how high is your confidence about the interval? = ; What about
   scaling vs. number of total BFD sessions?

I have no strong conclusions here, just some cautionary thoughts.

What are yours?

-- Jeff

--_000_BL0PR0102MB3345EC535EE558FC4CC692E6FAA70BL0PR0102MB3345_-- From nobody Sun Apr 1 08:11: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 C8F69124C27 for ; Sun, 1 Apr 2018 08:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 hH5TazpTQcth for ; Sun, 1 Apr 2018 08:11:23 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-oln040092002016.outbound.protection.outlook.com [40.92.2.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E811200B9 for ; Sun, 1 Apr 2018 08:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DsCaFzbAwyyTi7LbXn/RwIeN8XbESZTJHWE7nA6g2UM=; b=KOmK1D43afjU6X7gBPkq0Z7Jjy1Vg6gIcacOhA5LC+48Zc8TzmuswqJ9ikPOcxzyyiKvHdFj75GKMeA/5d+CN/27NIlcTHSZmiN0Is4PhaoiHleJZoMqFx9Ul3S/2qpZzC8ComVg1axmqjuWucZ6ghel/3xDEdTOo2zhZS6uS5iyfPtiVU3XluA8PR9bTvzmFAUFz7aNi8VhlDudNedRQMlbPn7TWB4t3SK6s2UABbAZrKAItBIJnUuxLgT2SHtVJSElG2wNtLfi33ZJ4OurH1Ez4VrHcDBGfn+K7rrImt5R6+NNMA10h8bl0xXBM5hXGnR3GWlCzpZb4z2TGWk3Ig== Received: from BY2NAM01FT063.eop-nam01.prod.protection.outlook.com (10.152.68.60) by BY2NAM01HT027.eop-nam01.prod.protection.outlook.com (10.152.69.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.631.7; Sun, 1 Apr 2018 15:11:21 +0000 Received: from BL0PR0102MB3345.prod.exchangelabs.com (10.152.68.60) by BY2NAM01FT063.mail.protection.outlook.com (10.152.69.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.631.7 via Frontend Transport; Sun, 1 Apr 2018 15:11:21 +0000 Received: from BL0PR0102MB3345.prod.exchangelabs.com ([fe80::a5f3:348:c9a1:1754]) by BL0PR0102MB3345.prod.exchangelabs.com ([fe80::a5f3:348:c9a1:1754%3]) with mapi id 15.20.0631.013; Sun, 1 Apr 2018 15:11:21 +0000 From: Ashesh Mishra To: Greg Mirsky , Jeffrey Haas CC: "rtg-bfd@ietf.org" Subject: Re: WGLC BFD Authentication Drafts Thread-Topic: WGLC BFD Authentication Drafts Thread-Index: AQHTxrM8j4pe2ek2RUW1GIkZ+QU4DqPnD20AgAT20DI= Date: Sun, 1 Apr 2018 15:11:21 +0000 Message-ID: References: <20180328163856.GB3126@pfrc.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:ECA0F19FD515576C923BA3EE2471C77FA31B7F4A85CDB0A0F3498D52958926F9; UpperCasedChecksum:A3E5E89678C09E2B9D4E813F00CEB3EA81EBE46D56CCC1891D6A0FA012BF9D32; SizeAsReceived:7133; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [ql2vzvtok0Szx8SKuZ3AsU2zdc7ER5i9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2NAM01HT027; 7:cyuXrmnwY0fs01ZKSLJCu4ShOaNkBy7NvRUOvdwypdfsRNvyFsawwNXOquCHmTp6tQ6CQdUk79k4+0083/1F0rUki96mWZUQKOIUvI3lbs7Ym+2GXo1cOObuve4caze31GzwaUgkwjXt9l3myP7MTN/l/2GxIH10d5q4Ja3E9JLrg+1ioIporD95cRScKxLybGxa8V7qsufTXgvJA2OO5/LC4gor2Xu/UBR38DiQcgnhXc7f9kxV42K2S4neexTY x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:BY2NAM01HT027; x-ms-traffictypediagnostic: BY2NAM01HT027: x-ms-office365-filtering-correlation-id: 1010dd5f-0121-4c03-5fdd-08d597e2d39a x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BY2NAM01HT027; BCL:0; PCL:0; RULEID:; SRVR:BY2NAM01HT027; x-forefront-prvs: 06290ECA9D x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:BY2NAM01HT027; H:BL0PR0102MB3345.prod.exchangelabs.com; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: eyecwTich0GyrvQkpCCydoHQEhZI940NgBY+jChhBMv0PJ3+iYEogpjZgmnfsQbPaYI1Y6FB0z5rs5Ky0oYyEqOJwwt1VarvXZYdOWONgZEZ30LPGTLFCYQfUfvaVEoCQO7f4j+MjilP1TBwI7nqn+c3znlawiOal7A9KmEn//iMIDJUu0jmZ0qNr693kdnX spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR0102MB33454D88A214B8EFFDD242B5FAA70BL0PR0102MB3345_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1010dd5f-0121-4c03-5fdd-08d597e2d39a X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2018 15:11:21.0680 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM01HT027 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: Sun, 01 Apr 2018 15:11:26 -0000 --_000_BL0PR0102MB33454D88A214B8EFFDD242B5FAA70BL0PR0102MB3345_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Your questions in the IETF-98 meeting seemed to stem from the challenges of= authentication in fast BFD sessions at high scale. I'll address the issue in two parts - "Is there a need for authenticated BFD sessions?" - I believe we can all ag= ree that there is a clear market need for BFD authentication. So we should = direct the conversation to the way in which we can address this requirement= . "How can authentication work at scale?" - BFD authentication puts significa= nt stress on the system and a non-meticulous method alleviates this computa= tion pressure. That's the premise of this draft as it presents a way to rel= ieve the BFD authentication requirement based on the capability of the syst= em to handle the additional stress which maintaining the session scale. There are some BFD systems in the market, which are not conducive to authen= tication (even the optimized method), where the impediment to authenticatio= n is due to the implementation details specific to that vendor or system. I believe all these issues were address during the meeting. Are there any s= pecific questions that I missed or any recommendations for the method in wh= ich the requirements can be addressed? Thanks, Ashesh ________________________________ From: Rtg-bfd on behalf of Greg Mirsky Sent: Thursday, March 29, 2018 4:09:32 AM To: Jeffrey Haas Cc: rtg-bfd@ietf.org Subject: Re: WGLC BFD Authentication Drafts Dear WG Chairs, et. al, I cannot support WG LC for draft-ietf-bfd-optimizing-authentication as my c= omments at BFD WG meeting dating back to IETF-98 still not have been addressed no= r even there was an attempt to address. As I've asked to clarify impact of = the proposed mechanism, particularly periodic authentication, on the BFD St= ate Machine, I'd point that the proposed mechanism directly affects BFD sec= urity as discussed in RFC 5880 and the section Security Considerations in t= he document, in my view, does not adequately reflects that and doesn't expl= ain how the security of the BFD session maintained when the periodic authen= tication is in use. Regards, Greg On Wed, Mar 28, 2018 at 7:38 PM, Jeffrey Haas > wrote: Working Group, The authors of the following Working Group drafts have requested Working Group Last Call on the following documents: https://tools.ietf.org/html/draft-ietf-bfd-secure-sequence-numbers-01 https://tools.ietf.org/html/draft-ietf-bfd-optimizing-authentication-04 https://tools.ietf.org/html/draft-ietf-bfd-stability-01 Given the overlap of functionality, WGLC will conclude for the bundle simultaneously. Authors, please positively acknowledge whether or not you know about any IP= R for your documents. Progression of the document will not be done without that statement. Last call will complete on April 20. -- Jeff --_000_BL0PR0102MB33454D88A214B8EFFDD242B5FAA70BL0PR0102MB3345_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg, 


Your questions in the IETF-9= 8 meeting seemed to stem from the challenges of authentication in fast BFD = sessions at high scale. 


I'll address the issue in two par= ts - 


"Is there a need for authent= icated BFD sessions?" - I believe we can all agree that there is a cle= ar market need for BFD authentication. So we should direct the conversation= to the way in which we can address this requirement. 


"How can authentication work= at scale?" - BFD authentication puts significant stress on the system= and a non-meticulous method alleviates this computation pressure. That's t= he premise of this draft as it presents a way to relieve the BFD authentication requirement based on the capability of t= he system to handle the additional stress which maintaining the session&nbs= p;scale. 


There are some BFD systems in the= market, which are not conducive to authentication (even the optimized meth= od), where the impediment to authentication is due to the implementation de= tails specific to that vendor or system. 


I believe all these issues were a= ddress during the meeting. Are there any specific questions that I missed o= r any recommendations for the method in which the requirements can be addre= ssed? 


Thanks,

Ashesh

From: Rtg-bfd <rtg-bfd-b= ounces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com><= br> Sent: Thursday, March 29, 2018 4:09:32 AM
To: Jeffrey Haas
Cc: rtg-bfd@ietf.org
Subject: Re: WGLC BFD Authentication Drafts
 
Dear WG Chairs, et. al, 
I cannot support WG LC for draft-ietf-bfd-optimizing-authenticati= on as my comments at BFD WG meeting dating back to IETF-98 still not have been add= ressed nor even there was an attempt to address. As I've asked to clarify i= mpact of the proposed mechanism, particularly periodic authentication, on the BFD State Machine, I'd point that the prop= osed mechanism directly affects BFD security as discussed in RFC 5880 and t= he section Security Considerations in the document, in my view, does not ad= equately reflects that and doesn't explain how the security of the BFD session maintained when the periodic a= uthentication is in use.

Regards,
Greg

On Wed, Mar 28, 2018 at 7:38 PM, Jeffrey Haas = <jhaas@pfrc.org&= gt; wrote:
Working Group,

The authors of the following Working Group drafts have requested
Working Group Last Call on the following documents:

https://tools.ietf.org/html/draft-ietf-bfd-secure-sequence-numbers-01
https://tools.ietf.org/html/<= wbr>draft-ietf-bfd-optimizing-authentication-04
https://tools.ietf.org/html/draft-ietf-b= fd-stability-01

Given the overlap of functionality, WGLC will conclude for the bundle
simultaneously.

Authors, please positively acknowledge whether or not you know about any IP= R
for your documents.  Progression of the document will not be done with= out
that statement.

Last call will complete on April 20.

-- Jeff


--_000_BL0PR0102MB33454D88A214B8EFFDD242B5FAA70BL0PR0102MB3345_-- From nobody Sun Apr 1 08:40:26 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 5C6C1126BF6; Sun, 1 Apr 2018 08:40:24 -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 5Mb8V-joU-Ld; Sun, 1 Apr 2018 08:40:22 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 997181200B9; Sun, 1 Apr 2018 08:40:22 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id l3so15627542iog.0; Sun, 01 Apr 2018 08:40:22 -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=34HRNaTQJa2ql6IbLee/rwt7xck/gc88GyDbd4clXOY=; b=OZvKCg+bmbooxu8CbBwzmfDD+EMTuO7o8D8RxbdqWqyTT3+NSSi4OYHE++hiGscuic 7AMEwMEvA+MLWQ3wxQn/47GQxJnLTsZqY5muMN3zq+o52Q5KunPL/FqVx3jxMsxoNkDa TGnDWWp4NcJgKAuPujbnpLWb6bvwTqDmQAlBDNyOU6+2JjEPW8E8yisW+vw+V0gny//R L8yj/NLyxz7oM/UkklXxXdd2aOoh9dh0EMweG6EUujjns89SRyqZZem5lHE8Q82lHaiX AJri4MGiBapZIS6+I49HvMIFEVrOxzUHd50UMggrdsQ0aPrYMR4Eco6eba0H3NmQpYj1 AwzQ== 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=34HRNaTQJa2ql6IbLee/rwt7xck/gc88GyDbd4clXOY=; b=hwocMwKRMZBbLEs9UtE0plCn6gzTpefxNb+CU3X83W1tBOvFv9ZcvKGYJojbbQz902 acMeM+Y1VeLXGLEaxupm6oopvcoi0ViDZ8vUypCgoRsrblkV6u+b2tBube8Dmn1dL4S6 Ohug52UE0EnLTdKYar4v80rbdPFD26QpW/6d74mdpdc5bJiFQDCGwwnXdNx1feDy8qFe Hrf8smd+PE5eRFbzbRqXujf+6Dzip/1caOR6l0ATVlGsny3sPtFTR37wB5Jw1A4dU8qo QY+qqvdPQQ2XkSf36eBVrINkwd3Yug6wfsEyYRYsRdMEGiT+2wsalqedThpizTEUwTxl 2Qow== X-Gm-Message-State: AElRT7GzT2GflaoanvmPlpp2Ld21r7TdKcvn9zUylhKMTh73kBwcZ1Gb CH1jsYyGvgWGMd5URNaiSfwkg5tAO4OSb2Hl2wk= X-Google-Smtp-Source: AIpwx4/H2iR//eND/hTdh9yPcxH7XAY0v8QV/feyC081w+ioVdw+w/oHJTgFW1/EPgp+lhFC+4IbXvpmGghMxdAx9+8= X-Received: by 10.107.181.72 with SMTP id e69mr5876822iof.267.1522597221859; Sun, 01 Apr 2018 08:40:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.222.3 with HTTP; Sun, 1 Apr 2018 08:40:01 -0700 (PDT) In-Reply-To: <20180328165736.GD3126@pfrc.org> References: <20180328165736.GD3126@pfrc.org> From: Ashesh Mishra Date: Sun, 1 Apr 2018 11:40:01 -0400 Message-ID: Subject: Re: Comments on Optimizing BFD Authentication To: Jeffrey Haas Cc: draft-ietf-bfd-optimizing-authentication@ietf.org, rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary="001a114441ee8b887c0568cb4ad6" 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: Sun, 01 Apr 2018 15:40:24 -0000 --001a114441ee8b887c0568cb4ad6 Content-Type: text/plain; charset="UTF-8" Inline On Wed, Mar 28, 2018 at 12:57 PM, Jeffrey Haas wrote: > Authors, > > Several comments on the draft in no particular order: > > --- > > The document header says "BFD Authentication". You should include the word > "optimizing" somewhere in that. :-) [AM] Addressed :) > > --- > > The NULL Auth TLV has a recommended Authentication Type of 0. While this > seems like a good idea, it's problematic in a few regards. > > RFC 5880 defines the bfd.AuthType variable. This is basically set using > the > received AuthType in the packet when authentication is received. E.g.: > > : Authentication Present (A) > : > : Set to 1 if authentication is in use on this session (bfd.AuthType > : is nonzero), or 0 if not. > > Further, section 6.8.6 contains the following: > > : If the A bit is set and no authentication is in use (bfd.AuthType > : is zero), the packet MUST be discarded. > > My recommendation is to remove the AuthType of 0 and replace it with a TBD > to be assigned by IANA. This impacts the IANA Considerations section. [AM] Good catch! I'll make the change. > > --- > > Section 3 notes a "Reserved" field. It notes "multiple keys". This seems > to > be missing text describing how it's intended to be used. > > [AM] This is a copy-paste error. It should read "This byte MUST be set to zero on transmit and ignored on receipt." --- > > > There are also a few other issues that require attention, which are largely > operational considerations: > > How do you go about enabling the optimized procedures? Is it expected to > be > via configuration? [AM] The intention is to be configuration-based (as is with other authentication methods). > > What are the yang model considerations? (See prior point.) > [AM] I'll let Mahesh comment on this. > > -- Jeff > --001a114441ee8b887c0568cb4ad6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Inline

On Wed, Mar 28, 2018 at 12:57 PM, Jeffrey Haas <= jhaas@pfrc.org><= /span> wrote:
Authors,

Several comments on the draft in no particular order:

---

The document header says "BFD Authentication".=C2=A0 You should i= nclude the word
"optimizing" somewhere in that. :-)

[AM] Addressed :)=C2=A0
=C2=A0
=C2=A0
---

The NULL Auth TLV has a recommended Authentication Type of 0.=C2=A0 While t= his
seems like a good idea, it's problematic in a few regards.

RFC 5880 defines the bfd.AuthType variable.=C2=A0 This is basically set usi= ng the
received AuthType in the packet when authentication is received.=C2=A0 E.g.= :

:=C2=A0 =C2=A0 Authentication Present (A)
:
:=C2=A0 =C2=A0 =C2=A0 =C2=A0Set to 1 if authentication is in use on this se= ssion (bfd.AuthType
:=C2=A0 =C2=A0 =C2=A0 =C2=A0is nonzero), or 0 if not.

Further, section 6.8.6 contains the following:

:=C2=A0 =C2=A0 =C2=A0 =C2=A0If the A bit is set and no authentication is in= use (bfd.AuthType
:=C2=A0 =C2=A0 =C2=A0 =C2=A0is zero), the packet MUST be discarded.

My recommendation is to remove the AuthType of 0 and replace it with a TBD<= br> to be assigned by IANA.=C2=A0 This impacts the IANA Considerations section.=

[AM] Good catch! I'll make the change.= =C2=A0
=C2=A0
=C2=A0
---

Section 3 notes a "Reserved" field.=C2=A0 It notes "multiple= keys". This seems to
be missing text describing how it's intended to be used.

[AM] This is a copy-paste error. It should read "= ;This byte = MUST be set to zero on transmit and ignored on receipt."=C2=A0<= /div>

---


There are also a few other issues that require attention, which are largely=
operational considerations:

How do you go about enabling the optimized procedures?=C2=A0 Is it expected= to be
via configuration?

[AM] The intention is to= be configuration-based (as is with other authentication methods).=C2=A0
=C2=A0
=C2=A0
What are the yang model considerations?=C2=A0 (See prior point.)

[AM] I'll let Mahesh comment on this.=C2=A0
=C2=A0

-- Jeff

--001a114441ee8b887c0568cb4ad6-- From nobody Sun Apr 1 09:28:55 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 2212D126C22 for ; Sun, 1 Apr 2018 09:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 Wp6rw7Y6-0jw for ; Sun, 1 Apr 2018 09:28:52 -0700 (PDT) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.6]) (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 5FA6C1200B9 for ; Sun, 1 Apr 2018 09:28:51 -0700 (PDT) Received: from [85.158.142.101] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-6.bemta.az-a.eu-central-1.aws.symcld.net id 08/E0-06180-1C801CA5; Sun, 01 Apr 2018 16:28:49 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTWUwTURSGvTPTYVBGL0Xl2IgPFU1EplIlBkx cEnxAo1FeG7cBRtpYBtKWWCVGVETiFomIiESpqT6gVlOtW41SHhoF4lIUESWoCCrgEsAFUeN0 LrjMw813//+cc89JznC0tofVcZLTIdlk0apnxzLJs77FCwEuYEqqaIxOuR14r0mpKinXpAz8u IKW0Olu9xCVfqn3LZ3efMCnWU2bNBY5M8+5QWPu8wxT+b465Dzfcp0tQmW1aC8ayzG4hIar7T Vs+KLFhymo8D+nyaUDwcWBUsWJ5Fi8ELxn21WeiAW4c/SDyjROh4M+v8oxeAbseP44gsTMhIe v7tKEF8DHzx4qzAyOh8EvQTWex2vA13la1bV4O1S+3K3qkXgtlN3yaMKM8GT42nCOIm/FQtvr kyoDxuC+eZ8mPAnedf4aic+Eji4XIroeqn/u0hCOg9DJferIgC9T8GxfMUsMAT4dOaIU4hSeD pffriXySui9WcSQ+McInnobGGIkQMve7hHeBDfKL4zwNvBcC2lIwika/N6OkS6mwrDvBU2M6y x8aNnDkpGz4E71AHMIJVb9Mx1hGRq/d6nM42i4e+w1Q/REqPH3s4RnwxlXLz3KTXWd1L96DYq oRamZNkuO2ZErWqyCMSlJMBrnCUZhbvJcg7hVEA1SgZAlyQ6bqLgGcbPdYN+Sm2XNNsiSw4uU XRujfNfQu2BWPZrCUfpJvFxyy6Qdn5mXvcUs2s3rbQVWyV6PpnKcHvjhiIBJG22TciTnRotVW dhRG7go/UR+nLKyWt6eL+baLTnEakCpXP3H8v00d089g80V+2ktI+fJki6Wp8IJOJxgLpD/lB v9BUIoThfDI6VBbVS+ZMu1OP73e1Ash/QxPISrRFlkx59Xe5SGKKWhxXJduCGH+NfSFSFfZWh P9qXk+y/bUUZqzipH6Zny91sXdc9wt1TXTQh19uMTHp/rSk9hc1nf8ezAPdexoR+b+s7OCU4b Ex/j7qqy1V9cITSnDTZNFnuLC/3L+lfsdDa5uucPVi4vXlr4aiijLe6NrjWxjPsVLH2kS1v3z N/4oDU57Unqw9PeBNP2cW16xm4WjQm0zS7+BiIX7Vr9AwAA X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-40.tower-226.messagelabs.com!1522600125!57896!1 X-Originating-IP: [52.41.248.36] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 19917 invoked from network); 1 Apr 2018 16:28:48 -0000 Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR03-VE1-obe.outbound.protection.outlook.com) (52.41.248.36) by server-40.tower-226.messagelabs.com with AES256-SHA256 encrypted SMTP; 1 Apr 2018 16:28:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=B3tpCPrkvHfpdQUoiMtG0qn/DefYnLq3JDb/P5il1lU=; b=TJht7+7jDyiNW+GVhvIRSvgNYroOKsaE6q38woNI7epLspS4AmlNQVy58HxCt1UZPU0uQ/3OfPMSFV59Fg1wJn390ywP8v1K9kr1cKfSeAvhXyAqIaWUE2w3HWjOwG1ZuYfva20PzTo+KXYkctyuPbqrNGJzYcGHLU9OajrL4CE= Received: from DB3PR03MB0969.eurprd03.prod.outlook.com (10.161.58.145) by DB3PR03MB0826.eurprd03.prod.outlook.com (10.161.55.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.10; Sun, 1 Apr 2018 16:28:43 +0000 Received: from DB3PR03MB0969.eurprd03.prod.outlook.com ([fe80::147b:66b2:a2d4:56e1]) by DB3PR03MB0969.eurprd03.prod.outlook.com ([fe80::147b:66b2:a2d4:56e1%18]) with mapi id 15.20.0609.012; Sun, 1 Apr 2018 16:28:43 +0000 From: Alexander Vainshtein To: Ashesh Mishra CC: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Tuning BFD session times Thread-Topic: Tuning BFD session times Thread-Index: AQHTxsWMtes9PCMSZUCS5+3WL2YKnKPsBRmAgAAY0DA= Date: Sun, 1 Apr 2018 16:28:43 +0000 Message-ID: References: <20180328184959.GB25442@pfrc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [79.177.112.202] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR03MB0826; 7:NpYF4iojchPqs42eSEE5NL8DdTPuhknJtKkrAb+qzS5mAAsvakZ6cFYU1qC9uKqg+DXzydqEyAO4l3/3eySybN4jF1MDk8JMCRRB0oUuUfjNVPnZWhaAv0CGHGlhIwLvrkd9Keutewbc3ihscVlJdBV9pLYmcWNP/7a39yC8cwinDu195H+SBMXOKDoK00YTzdx78Damn7aZNfaJcP1lis7bnssVFw6U77skPkYue5/R3Y2BIPRUuiiJmhmAcDNX x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e7ed8045-3506-45f7-012a-08d597eda276 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB3PR03MB0826; x-ms-traffictypediagnostic: DB3PR03MB0826: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(278428928389397)(21748063052155)(279101305709854)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231221)(944501327)(52105095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:DB3PR03MB0826; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0826; x-forefront-prvs: 06290ECA9D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(396003)(346002)(39380400002)(366004)(376002)(189003)(199004)(252514010)(7736002)(6246003)(55016002)(3280700002)(33656002)(106356001)(74316002)(6916009)(72206003)(97736004)(6116002)(476003)(478600001)(3846002)(5660300001)(105586002)(790700001)(9686003)(2906002)(99286004)(6436002)(236005)(54896002)(86362001)(14454004)(561944003)(6306002)(25786009)(66066001)(4326008)(229853002)(3660700001)(316002)(8936002)(39060400002)(2900100001)(54906003)(53936002)(7696005)(26005)(6506007)(81156014)(76176011)(11346002)(102836004)(53546011)(59450400001)(486005)(5250100002)(81166006)(8676002)(186003)(446003)(68736007)(486005)(3480700004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0826; H:DB3PR03MB0969.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: PWO8ydBM++jFJdLyQWha0S5aZ4tQtaLTTwj9HmnNnnSwfkRaOpDkv1Nd/+pli6M5RT8Ue9QqlHP2+grmQS5inT50eMzNZMc87DnDs+7jQROBZ5e4bH+CKx6OcUETMrDJLjI6bfAiMg+QWVr3vvqFOp+y+nFah7Ce6wwAvXbvsnzJxSFhNSpLbugL8Jd8VjEgXjVE5HXy94ygM1EGgZhORpdlxdor1ii4mq38rhGWe4l4429fbnA7PGVdtccfdwwcpTk9xohp34rsjSHMpOYuVl6/xxASWm0ukI5cVoU8gtZi1zFrsKj51iudwpd1PQlNFTtqT71JMmgW45Mu2JNAdMwuLXf+PKidcHx2/p/4cbJbDXthBQEEc/zBrOZozEuT37JJn2TZt2VwGN2KMxA1lzan3d6zCfXaHH7Kbw5MWpw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0969877EE63E4514F3975D6C9DA70DB3PR03MB0969eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: e7ed8045-3506-45f7-012a-08d597eda276 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2018 16:28:43.0854 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0826 X-CFilter-Loop: Reflected 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: Sun, 01 Apr 2018 16:28:54 -0000 --_000_DB3PR03MB0969877EE63E4514F3975D6C9DA70DB3PR03MB0969eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ashesh, I would like to understand better the use case with satellite links that y= ou have described. In particular, can you please explain why long RTT affects the BFD detecti= on times? As I see it, what could really affect these times is variable delay introd= uced in some cases by the satellite links since the distance between the s= atellite and the terrestrial antennae may change significantly with time. What did I miss? Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Ashesh Mishra= Sent: Sunday, April 1, 2018 5:54 PM To: Jeffrey Haas ; rtg-bfd@ietf.org Subject: Re: Tuning BFD session times Jeff, thanks for kicking-off this discussion on the list! One additional comment that I wanted to make was around automation. There = were questions during the meeting around the need for auto-tuning and that= the process of determining the interval can/should be manual. The automation of control in all aspects of dynamic behavior is a priority= for network operators. When configuring manually, parameters such BFD int= ervals are typically set at very conservative values because human latency= is very high when responding to changing network conditions. Manual confi= guration also takes a lot of time and is accounts for significant number o= f lost opportunities and value for operators. [JH] "applications should generally choose a detection interval that is re= asoanble for their application rather than try to dynamically discover the= lowest possible stable detection interval. " [AM] This depends on the use-case. From the point-of-view of a service pro= vider that delivers long-haul connectivity (typical scenario in which the = link characteristics have large variance) then the intent is to provide th= e best performance. As such providers deliver connectivity to critical app= lications, and are often the only way of delivering connectivity in such p= laces, the ability to tune the system to deliver an up-time that is superi= or drives significant value. Consider a scenario where there is a 130ms RT= T link (MEO satellite, LEO will be in the 20-60ms range) and its backup is= a 600ms RTT link (GEO satellite), and are being used to deliver transit c= onnectivity. The rate at which the end-to-end service can run BFD is signi= ficantly faster when MEO is active versus when GEO is active. The applicat= ion, in this scenario, may survive the RTT, but the business continuity is= critical in many cases. Since the provider of long-haul can not control t= he application, it must provide the best possible failover performance. [JH] "1. BFD is asymmetric.. This means a receiving BFD implementation mu= st provide feedback to a sending implementation in order for it to underst= and perceived reliability." [AM] May not need to be the BFD implementation providing the feedback if t= here are other performance mechanisms running. The challenge is to standar= dize the mechanism that BFD can use (if the measurement is not self-contai= ned in BFD). You're right in pointing out the challenge in accounting for = the CPU delays and that was the reason for the original proposal for BFD p= erformance measurement. If the measurement is within the BFD realm, it wil= l account for the CPU delays. However, most good BFD engines have relative= ly deterministic performance and are quite optimized so the variance with = scale and time is not significant (but I concede that not all BFD implemen= tations are good). [JH] "2. Measurement infrastructure may negatively impact session scale. = Greg, I believe, made this point when discussing host processing issues vs= . BFD ingress/egress." [AM] This is an issue if using a measurement mechanism within BFD (other p= erformance measurement methods are always running in network for SLA repor= ting and/or network optimization). Within a metro-area with fiber or terre= strial wireless (microwave, LTE, etc.) connectivity, I would likely not ne= ed constant auto-tuning. The variance in the primary and backup links in s= uch network will not be significant to affect the BFD parameters. In long-= haul links, this may be a valuable feature in which case, the additional o= verhead may be justified. So it depends on the use-case whether continuous= auto-tuning is required or if it is one-time. [JH] "3. Detection interval calculations really need to take into account = things that are greater than simple packet transmission times. As an exam= ple, if your measurement is always taken during low system CPU or network = activity, how high is your confidence about the interval? What about scal= ing vs. number of total BFD sessions?" [AM] Great questions. Typically when running BFD or CFM (or similar) high = frequency OAM, CPU peaks should not affect the OAM performance (a variety = of methods, based on the system on which OAM is running, can ensure that).= CPU peaks become a bigger issue if BFD is used to detect continuity for a= particular flow (or QoS). -- Asheh ________________________________ From: Rtg-bfd > = on behalf of Jeffrey Haas > Sent: Wednesday, March 28, 2018 11:49 AM To: rtg-bfd@ietf.org Subject: Tuning BFD session times Working Group, We had very active discussion (yay!) at the microphone as part of Mahesh's= presentation on BFD Performance Measurement. (draft-am-bfd-performance) I wanted to start this thread to discuss the greater underlying issues thi= s discussion raised. In particular, active tuning of BFD session parameters= . Please note that opinions I state here are as an individual contributor. BFD clients typically want the fastest, most stable detection interval tha= t is appropriate to their application. That stability component is very important since too aggressive of timers can result in unnecessary BFD session instability which will impact the subscribing application. Such stability is a function of many things, scale of the system running BFD being a major one. In my opinion, applications should generally choose a detection interval that is reasoanble for their application rather than try to dynamically discover the lowest possible stable detection interval. This is because a= number of unstable factors, such as CPU load, contention with other networ= k traffic and other things that are outside the general control of many sytems may impact such scale. That said, here's a few thoughts on active feedback mechanisms: 1. BFD is asymmetric. This means a receiving BFD implementation must prov= ide feedback to a sending implementation in order for it to understand perceived reliability. 2. Measurement infrastructure may negatively impact session scale. Greg, = I believe, made this point when discussing host processing issues vs. BFD= ingress/egress. 3. Detection interval calculations really need to take into account things= that are greater than simple packet transmission times. As an example,= if your measurement is always taken during low system CPU or network activity, how high is your confidence about the interval? What about scaling vs. number of total BFD sessions? I have no strong conclusions here, just some cautionary thoughts. What are yours? -- Jeff __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_DB3PR03MB0969877EE63E4514F3975D6C9DA70DB3PR03MB0969eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ashesh,

I would like to understand better t= he use case with satellite links that you have described.

In particular, can you please expla= in why long RTT affects the BFD detection times?

As I see it, what could really affe= ct these times is variable delay introduced in some cases by the satellite= links since the distance between the satellite and the terrestrial antennae may change significantly with time. <= /span>

 

What did I miss?<= /p>

 

Regards,

Sasha

 

Office: +972-39266302

Cell:     = +972-549266302

Email:   Alexander.Vainsh= tein@ecitele.com

 

From: Rtg-bfd [mailto:rtg-bfd-bou= nces@ietf.org] On Behalf Of Ashesh Mishra
Sent: Sunday, April 1, 2018 5:54 PM
To: Jeffrey Haas <jhaas@pfrc.org>; rtg-bfd@ietf.org
Subject: Re: Tuning BFD session times

 

= Jeff, thanks for kicking-off this discussion on the list!

=  

= One additional comment that I wanted to make was around automation. T= here were questions during the meeting around the need for auto-tuning and= that the process of determining the interval can/should be manual.

=  

= The automation of control in all aspects of dynamic behavior is a priority= for network operators. When configuring manually, parameters such BFD int= ervals are typically set at very conservative values because human latency is very high when responding to changing network co= nditions. Manual configuration also takes a lot of time and is accounts fo= r significant number of lost opportunities and value for operators. <= o:p>

=  

[JH] "applications should general= ly choose a detection interval that is reasoanble for their applicati= on rather than try to dynamically discover the lowest possible sta= ble detection interval. "

= [AM] This depends on the use-case. From the point-of-view of a service pro= vider that delivers long-haul connectivity (typical scenario in which the = link characteristics have large variance) then the intent is to provide the best performance. As such providers deliver = connectivity to critical applications, and are often the only way of deliv= ering connectivity in such places, the ability to tune the system to deliv= er an up-time that is superior drives significant value. Consider a scenario where there is a 130ms RTT link (M= EO satellite, LEO will be in the 20-60ms range) and its backup is a 600ms = RTT link (GEO satellite), and are being used to deliver transit connectivi= ty. The rate at which the end-to-end service can run BFD is significantly faster when MEO is active versus whe= n GEO is active. The application, in this scenario, may survive the RTT, b= ut the business continuity is critical in many cases. Since the provider o= f long-haul can not control the application, it must provide the best possible failover performance. <= /span>

=  

[JH] "1. BFD is asymmetric..  This means a r= eceiving BFD implementation must provide feedback to a sending implem= entation in order for it to understand perceived reliability."

= [AM] May not need to be the BFD implementation providing the feedback if t= here are other performance mechanisms running. The challenge is to standar= dize the mechanism that BFD can use (if the measurement is not self-contained in BFD). You're right in pointing out the challenge= in accounting for the CPU delays and that was the reason for the original= proposal for BFD performance measurement. If the measurement is within th= e BFD realm, it will account for the CPU delays. However, most good BFD engines have relatively deterministic = performance and are quite optimized so the variance with scale and time is= not significant (but I concede that not all BFD implementations are good)= . 

=  

[JH] "2. Measurement infrastructure may negativel= y impact session scale.  Greg, I believe, made this point when d= iscussing host processing issues vs. BFD ingress/egress."=

= [AM] This is an issue if using a measurement mechanism within BFD (other p= erformance measurement methods are always running in network for SLA repor= ting and/or network optimization). Within a metro-area with fiber or terrestrial wireless (microwave, LTE, etc.) connectivity, I= would likely not need constant auto-tuning. The variance in the primary a= nd backup links in such network will not be significant to affect the BFD = parameters. In long-haul links, this may be a valuable feature in which case, the additional overhead may be j= ustified. So it depends on the use-case whether continuous auto-tuning is = required or if it is one-time. 

=  

[JH] "3. Detection interval calculations really n= eed to take into account things that are greater than simple packet t= ransmission times.  As an example, if your measurement is always taken during low system CPU or network activity, how high is = your confidence about the interval?  What about scaling vs. numb= er of total BFD sessions?"

[AM] Great questions. Typically when running BFD = or CFM (or similar) high frequency OAM, CPU peaks should not affect the OA= M performance (a variety of methods, based on the system on which OAM is running, can ensure that). CPU peaks become a bigger= issue if BFD is used to detect continuity for a particular flow (or QoS).=  

 

--

Asheh=

From: Rtg= -bfd <rtg-bfd-bounces@ietf.= org> on behalf of Jeffrey Haas <jhaas@pfr= c.org>
Sent: Wednesday, March 28, 2018 11:49 AM
To: rtg-bfd@ietf.org
Subject: Tuning BFD session times

 

Workin= g Group,

We had very active discussion (yay!) at the microphone as part of Mahesh's=
presentation on BFD Performance Measurement.
(draft-am-bfd-performance)

I wanted to start this thread to discuss the greater underlying issues thi= s
discussion raised.  In particular, active tuning of BFD session param= eters.
Please note that opinions I state here are as an individual contributor.
BFD clients typically want the fastest, most stable detection interval tha= t
is appropriate to their application.  That stability component is ver= y
important since too aggressive of timers can result in unnecessary BFD
= session instability which will impact the subscribing application.  S= uch
stability is a function of many things, scale of the system running BFD being a major one.

In my opinion, applications should generally choose a detection interval that is reasoanble for their application rather than try to dynamically discover the lowest possible stable detection interval.  This is beca= use a
number of unstable factors, such as CPU load, contention with other networ= k
traffic and other things that are outside the general control of many
sytems may impact such scale.

That said, here's a few thoughts on active feedback mechanisms:
1. BFD is asymmetric.  This means a receiving BFD implementation must= provide
   feedback to a sending implementation in order for it to under= stand
   perceived reliability.
2. Measurement infrastructure may negatively impact session scale.  G= reg, I
   believe, made this point when discussing host processing issu= es vs. BFD
   ingress/egress.
3. Detection interval calculations really need to take into account things=
   that are greater than simple packet transmission times. = As an example,
   if your measurement is always taken during low system CPU or = network
   activity, how high is your confidence about the interval?&nbs= p; What about
   scaling vs. number of total BFD sessions?

I have no strong conclusions here, just some cautionary thoughts.

What are yours?

-- Jeff


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_DB3PR03MB0969877EE63E4514F3975D6C9DA70DB3PR03MB0969eurp_-- From nobody Sun Apr 1 10:17:49 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 4AD88127023 for ; Sun, 1 Apr 2018 10:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 Dcx7zdgk-0xP for ; Sun, 1 Apr 2018 10:17:43 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-oln040092006100.outbound.protection.outlook.com [40.92.6.100]) (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 D4583126DCA for ; Sun, 1 Apr 2018 10:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LHct8foE0VpcYc8o0r6rHujTJLK5yVFEj4Ez3Zo+Okk=; b=m+SlX/1JvRjARy2Q8dihLz6AfDb5bxX+2QLy9Rc0Eek8pjWRNviboGQbgYyq22dhsdGN7yb5UG8PqE5J5BHzUVHxPa3JClsGPvDA1yTMu6rZA09phl4Arfnlo0fbzLpByeAjvoGNQuDKGho8PdouQkj4hlS35S7WMmYg8w+6Rgmr7a7/VvEYv/wrLk4F3Ki+qiQgwhq5Izo2AC2sL7YTqpYAXCk/JgMjzFCJThIABvq64CiGFGidDImM42cFBnkJn856j+gbPqnnEC3+YvpBOA9R2Z0D99DqYN/VyJBhphTT/XEy4xs8TyffFpN5g3mWPRFpKE11IMwWiECyWSyYtg== Received: from BY2NAM03FT004.eop-NAM03.prod.protection.outlook.com (10.152.84.59) by BY2NAM03HT076.eop-NAM03.prod.protection.outlook.com (10.152.85.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.631.7; Sun, 1 Apr 2018 17:17:42 +0000 Received: from BL0PR0102MB3345.prod.exchangelabs.com (10.152.84.58) by BY2NAM03FT004.mail.protection.outlook.com (10.152.84.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.631.7 via Frontend Transport; Sun, 1 Apr 2018 17:17:42 +0000 Received: from BL0PR0102MB3345.prod.exchangelabs.com ([fe80::a5f3:348:c9a1:1754]) by BL0PR0102MB3345.prod.exchangelabs.com ([fe80::a5f3:348:c9a1:1754%3]) with mapi id 15.20.0631.013; Sun, 1 Apr 2018 17:17:42 +0000 From: Ashesh Mishra To: Alexander Vainshtein CC: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: Tuning BFD session times Thread-Topic: Tuning BFD session times Thread-Index: AQHTxsWKBNltmss7WESLSBbS7Nadv6Pr+FuygAAnGYCAAAl1kg== Date: Sun, 1 Apr 2018 17:17:41 +0000 Message-ID: References: <20180328184959.GB25442@pfrc.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:78DC7C1312B4EF5199C13460FB9DF0AB6F33CE83B4BB55C68466346427798FFA; UpperCasedChecksum:FD70B3F6A6789B22B4F64B39E6315BD28E3B43832D615467E51F3068CB9CDACE; SizeAsReceived:7264; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [K5tKdIFfLPI082GOu5S63TeNzrPwgiYE] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2NAM03HT076; 7:fYVsog3ZXFPEzUQV+kvm2IMZU4pf/NGr900AZq+amt4VbjN4FpKeesKSBhu4G5GNx4ucojDcDYqWD5vRv099372sD8NS5LneqP0KDSxce3TBRMOSjCfHTA+XJVUbiwD8dfPrCdGPzud1bbku6ePk5kbk3RnYHxobrJhEWmH/8xsfs9v01qnqlozstIU9s8mw7XbO/4jOH+yUmAw0RM9CIQ61dUVO8teiWVeHtcFNA72O606z/2KpE9oTU4t5A0xz x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:BY2NAM03HT076; x-ms-traffictypediagnostic: BY2NAM03HT076: x-ms-office365-filtering-correlation-id: e48d1911-8763-4386-3112-08d597f47a40 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BY2NAM03HT076; BCL:0; PCL:0; RULEID:; SRVR:BY2NAM03HT076; x-forefront-prvs: 06290ECA9D x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:BY2NAM03HT076; H:BL0PR0102MB3345.prod.exchangelabs.com; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: SKBJwbXx7IKgW7tkJyrx5eJJ9dvVnGtX8X2OZSFw0Q5jujQEnS06djebme50u4MyN/CNpkYBn5fZws6gweCTCcvuA2PT0fef9CjSmj5+jkGIeY0ROrYs+9hU759OWXOGMCAYNvvsCfmEnzRsndqFGpQSYM/mR7Mcfd1Z3vmeNdEBFm2MDQUPLxHZOLhp2aaP spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR0102MB33453186C4DE4B6646FD67FEFAA70BL0PR0102MB3345_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e48d1911-8763-4386-3112-08d597f47a40 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2018 17:17:41.8041 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM03HT076 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: Sun, 01 Apr 2018 17:17:47 -0000 --_000_BL0PR0102MB33453186C4DE4B6646FD67FEFAA70BL0PR0102MB3345_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sasha, There are two scenarios here and they depend on whether the satellite is in= geo-stationary orbit (GEO) or non-geo-stationary orbit (NGSO). Scenario-1: Non-Geostationary Satellites: This is the scenario that you des= cribed. Satellites in Middle Earth Orbit (MEO) or Low Earth Orbit (LEO) mov= e relative to the earth and hence, their distance from the ground terminals= varies as they pass over a given location. This results in varying RTT (so= metimes by as much as 30ms). The issue in this scenario is not necessarily = that the BFD detect interval must change frequently but that it's difficult= to accurately select the intervals as the RTT depends on the location of t= he terminal and the gateway (and this gets quite complex). If the session c= an automatically decide the interval, then the complexity in starting a new= service is reduced. Another complicating factor is when the terminal moves= (ship or aircraft, for example) as this increases the variance of the RTT.= We typically set the intervals to a high enough level but that affects the= performance. We see the same varying RTT in GEO when the terminal is mobil= e but the percentage change is much smaller than the overall RTT of GEO (be= cause GEO satellites are much farther away from the earth at ~36,000kms vs = MEO at ~8,000kms and LEO at ~200-1000kms). Scenario-2: Low-latency link backed up by high-latency link: In this case a= GEO satellite backs up NGSO-based connection or fiber (or other terrestria= l wired/wireless WAN options). The end-to-end service then has very differe= nt RTT when the primary is active versus when the backup is active. The typ= ical solution is to base timers on the backup RTT, which is very inefficien= t. Regards, Ashesh ________________________________ From: Alexander Vainshtein Sent: Sunday, April 1, 2018 9:28:43 AM To: Ashesh Mishra Cc: Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: Tuning BFD session times Ashesh, I would like to understand better the use case with satellite links that yo= u have described. In particular, can you please explain why long RTT affects the BFD detectio= n times? As I see it, what could really affect these times is variable delay introdu= ced in some cases by the satellite links since the distance between the sat= ellite and the terrestrial antennae may change significantly with time. What did I miss? Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Ashesh Mishra Sent: Sunday, April 1, 2018 5:54 PM To: Jeffrey Haas ; rtg-bfd@ietf.org Subject: Re: Tuning BFD session times Jeff, thanks for kicking-off this discussion on the list! One additional comment that I wanted to make was around automation. There w= ere questions during the meeting around the need for auto-tuning and that t= he process of determining the interval can/should be manual. The automation of control in all aspects of dynamic behavior is a priority = for network operators. When configuring manually, parameters such BFD inter= vals are typically set at very conservative values because human latency is= very high when responding to changing network conditions. Manual configura= tion also takes a lot of time and is accounts for significant number of los= t opportunities and value for operators. [JH] "applications should generally choose a detection interval that is rea= soanble for their application rather than try to dynamically discover the l= owest possible stable detection interval. " [AM] This depends on the use-case. From the point-of-view of a service prov= ider that delivers long-haul connectivity (typical scenario in which the li= nk characteristics have large variance) then the intent is to provide the b= est performance. As such providers deliver connectivity to critical applica= tions, and are often the only way of delivering connectivity in such places= , the ability to tune the system to deliver an up-time that is superior dri= ves significant value. Consider a scenario where there is a 130ms RTT link = (MEO satellite, LEO will be in the 20-60ms range) and its backup is a 600ms= RTT link (GEO satellite), and are being used to deliver transit connectivi= ty. The rate at which the end-to-end service can run BFD is significantly f= aster when MEO is active versus when GEO is active. The application, in thi= s scenario, may survive the RTT, but the business continuity is critical in= many cases. Since the provider of long-haul can not control the applicatio= n, it must provide the best possible failover performance. [JH] "1. BFD is asymmetric.. This means a receiving BFD implementation mus= t provide feedback to a sending implementation in order for it to understan= d perceived reliability." [AM] May not need to be the BFD implementation providing the feedback if th= ere are other performance mechanisms running. The challenge is to standardi= ze the mechanism that BFD can use (if the measurement is not self-contained= in BFD). You're right in pointing out the challenge in accounting for the = CPU delays and that was the reason for the original proposal for BFD perfor= mance measurement. If the measurement is within the BFD realm, it will acco= unt for the CPU delays. However, most good BFD engines have relatively dete= rministic performance and are quite optimized so the variance with scale an= d time is not significant (but I concede that not all BFD implementations a= re good). [JH] "2. Measurement infrastructure may negatively impact session scale. G= reg, I believe, made this point when discussing host processing issues vs. = BFD ingress/egress." [AM] This is an issue if using a measurement mechanism within BFD (other pe= rformance measurement methods are always running in network for SLA reporti= ng and/or network optimization). Within a metro-area with fiber or terrestr= ial wireless (microwave, LTE, etc.) connectivity, I would likely not need c= onstant auto-tuning. The variance in the primary and backup links in such n= etwork will not be significant to affect the BFD parameters. In long-haul l= inks, this may be a valuable feature in which case, the additional overhead= may be justified. So it depends on the use-case whether continuous auto-tu= ning is required or if it is one-time. [JH] "3. Detection interval calculations really need to take into account t= hings that are greater than simple packet transmission times. As an exampl= e, if your measurement is always taken during low system CPU or network act= ivity, how high is your confidence about the interval? What about scaling = vs. number of total BFD sessions?" [AM] Great questions. Typically when running BFD or CFM (or similar) high f= requency OAM, CPU peaks should not affect the OAM performance (a variety of= methods, based on the system on which OAM is running, can ensure that). CP= U peaks become a bigger issue if BFD is used to detect continuity for a par= ticular flow (or QoS). -- Asheh ________________________________ From: Rtg-bfd > o= n behalf of Jeffrey Haas > Sent: Wednesday, March 28, 2018 11:49 AM To: rtg-bfd@ietf.org Subject: Tuning BFD session times Working Group, We had very active discussion (yay!) at the microphone as part of Mahesh's presentation on BFD Performance Measurement. (draft-am-bfd-performance) I wanted to start this thread to discuss the greater underlying issues this discussion raised. In particular, active tuning of BFD session parameters. Please note that opinions I state here are as an individual contributor. BFD clients typically want the fastest, most stable detection interval that is appropriate to their application. That stability component is very important since too aggressive of timers can result in unnecessary BFD session instability which will impact the subscribing application. Such stability is a function of many things, scale of the system running BFD being a major one. In my opinion, applications should generally choose a detection interval that is reasoanble for their application rather than try to dynamically discover the lowest possible stable detection interval. This is because a number of unstable factors, such as CPU load, contention with other network traffic and other things that are outside the general control of many sytems may impact such scale. That said, here's a few thoughts on active feedback mechanisms: 1. BFD is asymmetric. This means a receiving BFD implementation must provi= de feedback to a sending implementation in order for it to understand perceived reliability. 2. Measurement infrastructure may negatively impact session scale. Greg, I believe, made this point when discussing host processing issues vs. BFD ingress/egress. 3. Detection interval calculations really need to take into account things that are greater than simple packet transmission times. As an example, if your measurement is always taken during low system CPU or network activity, how high is your confidence about the interval? What about scaling vs. number of total BFD sessions? I have no strong conclusions here, just some cautionary thoughts. What are yours? -- Jeff ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have recei= ved this transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original and all copies thereof. ___________________________________________________________________________ --_000_BL0PR0102MB33453186C4DE4B6646FD67FEFAA70BL0PR0102MB3345_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sasha,


There are two scenarios here and = they depend on whether the satellite is in geo-stationary orbit (GEO) = or non-geo-stationary orbit (NGSO). 


Scenario-1: Non-Geostationary Sat= ellites: This is the scenario that you described. Satellites in Middle= Earth Orbit (MEO) or Low Earth Orbit (LEO) move relative to the earth and = hence, their distance from the ground terminals varies as they pass over a given location. This results in varying RTT (so= metimes by as much as 30ms). The issue in this scenario is not necessarily = that the BFD detect interval must change frequently but that it's diff= icult to accurately select the intervals as the RTT depends on the location of the terminal and the gateway (and th= is gets quite complex). If the session can automatically decide the interva= l, then the complexity in starting a new service is reduced. Another compli= cating factor is when the terminal moves (ship or aircraft, for example) as this increases the variance of the= RTT. We typically set the intervals to a high enough level but that affect= s the performance. We see the same varying RTT in GEO when the terminal is = mobile but the percentage change is much smaller than the overall RTT of GEO (because GEO satellites are much farth= er away from the earth at ~36,000kms vs MEO at ~8,000kms and LEO at ~200-10= 00kms). 


Scenario-2: Low-latency link back= ed up by high-latency link: In this case a GEO satellite backs up NGSO-base= d connection or fiber (or other terrestrial wired/wireless WAN options). Th= e end-to-end service then has very different RTT when the primary is active versus when the backup is active.= The typical solution is to base timers on the backup RTT, which is very in= efficient. 


Regards,

Ashesh

From: Alexander Vainshtein = <Alexander.Vainshtein@ecitele.com>
Sent: Sunday, April 1, 2018 9:28:43 AM
To: Ashesh Mishra
Cc: Jeffrey Haas; rtg-bfd@ietf.org
Subject: RE: Tuning BFD session times
 

Ashesh,

I would like to understand better= the use case with satellite links that you have described.

In particular, can you please exp= lain why long RTT affects the BFD detection times?

As I see it, what could really af= fect these times is variable delay introduced in some cases by the satellit= e links since the distance between the satellite and the terrestrial antennae may change significantly with time.

 

What did I miss?

 

Regards,

Sasha

 

Office: +972-39266302<= /p>

Cell:    &nbs= p; +972-549266302

Email:   Alexander.Vain= shtein@ecitele.com

 

From: Rtg-bfd [mailto:rtg-bfd-bo= unces@ietf.org] On Behalf Of Ashesh Mishra
Sent: Sunday, April 1, 2018 5:54 PM
To: Jeffrey Haas <jhaas@pfrc.org>; rtg-bfd@ietf.org
Subject: Re: Tuning BFD session times

 

= Jeff, thanks for kicking-off this discussion on the list!

=  

= One additional comment that I wanted to make was around automation. Th= ere were questions during the meeting around the need for auto-tuning and t= hat the process of determining the interval can/should be manual.

=  

= The automation of control in all aspects of dynamic behavior is a priority = for network operators. When configuring manually, parameters such BFD inter= vals are typically set at very conservative values because human latency is very high when responding to changing netw= ork conditions. Manual configuration also takes a lot of time and is accoun= ts for significant number of lost opportunities and value for operators.&nb= sp;

=  

[JH] "applications should general= ly choose a detection interval that is reasoanble for their applicatio= n rather than try to dynamically discover the lowest possible stab= le detection interval. "

= [AM] This depends on the use-case. From the point-of-view of a service prov= ider that delivers long-haul connectivity (typical scenario in which the li= nk characteristics have large variance) then the intent is to provide the best performance. As such providers deliver c= onnectivity to critical applications, and are often the only way of deliver= ing connectivity in such places, the ability to tune the system to deliver = an up-time that is superior drives significant value. Consider a scenario where there is a 130ms RTT link (ME= O satellite, LEO will be in the 20-60ms range) and its backup is a 600ms RT= T link (GEO satellite), and are being used to deliver transit connectivity.= The rate at which the end-to-end service can run BFD is significantly faster when MEO is active versus when= GEO is active. The application, in this scenario, may survive the RTT, but= the business continuity is critical in many cases. Since the provider of l= ong-haul can not control the application, it must provide the best possible failover performance. 

=  

[JH] "1. BFD is asymmetric..  This means a r= eceiving BFD implementation must provide feedback to a sending impleme= ntation in order for it to understand perceived reliability."

= [AM] May not need to be the BFD implementation providing the feedback if th= ere are other performance mechanisms running. The challenge is to standardi= ze the mechanism that BFD can use (if the measurement is not self-contained in BFD). You're right in pointing out the challenge = in accounting for the CPU delays and that was the reason for the original p= roposal for BFD performance measurement. If the measurement is within the B= FD realm, it will account for the CPU delays. However, most good BFD engines have relatively deterministic p= erformance and are quite optimized so the variance with scale and time is n= ot significant (but I concede that not all BFD implementations are good).&n= bsp;

=  

[JH] "2. Measurement infrastructure may negativel= y impact session scale.  Greg, I believe, made this point when di= scussing host processing issues vs. BFD ingress/egress."<= /span>

= [AM] This is an issue if using a measurement mechanism within BFD (other pe= rformance measurement methods are always running in network for SLA reporti= ng and/or network optimization). Within a metro-area with fiber or terrestrial wireless (microwave, LTE, etc.) connectivity, I = would likely not need constant auto-tuning. The variance in the primary and= backup links in such network will not be significant to affect the BFD par= ameters. In long-haul links, this may be a valuable feature in which case, the additional overhead may be ju= stified. So it depends on the use-case whether continuous auto-tuning is re= quired or if it is one-time. 

=  

[JH] "3. Detection interval calculations really n= eed to take into account things that are greater than simple packet tr= ansmission times.  As an example, if your measurement is always taken during low system CPU or network activity, how high i= s your confidence about the interval?  What about scaling vs. num= ber of total BFD sessions?"

[AM] Great questions. Typically when running BFD= or CFM (or similar) high frequency OAM, CPU peaks should not affect the OA= M performance (a variety of methods, based on the system on which OAM is running, can ensure that). CPU peaks become a bigger = issue if BFD is used to detect continuity for a particular flow (or QoS).&n= bsp;

 

--

Asheh

From: = Rtg-bfd <rtg-bfd-bounces@iet= f.org> on behalf of Jeffrey Haas <jhaas@pfrc= .org>
Sent: Wednesday, March 28, 2018 11:49 AM
To: rtg-bfd@ietf.org
Subject: Tuning BFD session times

 

Work= ing Group,

We had very active discussion (yay!) at the microphone as part of Mahesh's<= br> presentation on BFD Performance Measurement.
(draft-am-bfd-performance)

I wanted to start this thread to discuss the greater underlying issues this=
discussion raised.  In particular, active tuning of BFD session parame= ters.
Please note that opinions I state here are as an individual contributor.
BFD clients typically want the fastest, most stable detection interval that=
is appropriate to their application.  That stability component is very=
important since too aggressive of timers can result in unnecessary BFD
session instability which will impact the subscribing application.  Su= ch
stability is a function of many things, scale of the system running BFD
being a major one.

In my opinion, applications should generally choose a detection interval that is reasoanble for their application rather than try to dynamically
discover the lowest possible stable detection interval.  This is becau= se a
number of unstable factors, such as CPU load, contention with other network=
traffic and other things that are outside the general control of many
sytems may impact such scale.

That said, here's a few thoughts on active feedback mechanisms:
1. BFD is asymmetric.  This means a receiving BFD implementation must = provide
   feedback to a sending implementation in order for it to unders= tand
   perceived reliability.
2. Measurement infrastructure may negatively impact session scale.  Gr= eg, I
   believe, made this point when discussing host processing issue= s vs. BFD
   ingress/egress.
3. Detection interval calculations really need to take into account things<= br>    that are greater than simple packet transmission times.  = As an example,
   if your measurement is always taken during low system CPU or n= etwork
   activity, how high is your confidence about the interval? = ; What about
   scaling vs. number of total BFD sessions?

I have no strong conclusions here, just some cautionary thoughts.

What are yours?

-- Jeff


___________________________________________________________________________=

This e-mail message is intended for the recipient only and contains informa= tion which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have recei= ved this
transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original
and all copies thereof.
___________________________________________________________________________=
--_000_BL0PR0102MB33453186C4DE4B6646FD67FEFAA70BL0PR0102MB3345_-- From nobody Sun Apr 1 21:06:25 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 837E5126CB6; Sun, 1 Apr 2018 21:06:24 -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 slmKOu70n4g8; Sun, 1 Apr 2018 21:06:22 -0700 (PDT) Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (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 C327B126579; Sun, 1 Apr 2018 21:06:22 -0700 (PDT) Received: by mail-pl0-x22c.google.com with SMTP id u11-v6so3420618plq.1; Sun, 01 Apr 2018 21:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GZVlra22Hmo943AVWUZYG80lI7tCF9R/POz4LfEwPLM=; b=dKV7ArqBjFpKrthAuT+c8sxScquLS+60HYjn79kfN+ypgi7hl8YVm468vn3HgAATM3 i5y+DbKsjUNc3cbTwk1ggTSsqBysQ7Nu7DERWDIp9lXyQnvghhgYotK61p5vexIyke7q VCFyelLtwqE0bgP1o+GoV3E4T6zzV8QVPSCTSHXH4cNXIHJ79Gf9CSrIZJtx+HWNDBQi VfyZuhlpZe/uCbGahqS9tzhl3VSumqmHI+iKqMzvbqNBSDYTHWSgjBJh5SXg3hJ3XdA7 5cAOCYnV5w6/bnB+/IIjzW3w6dHkKWrRgoufTNwGS3ZDWi9dqgbYPEjT/vAnyzSCeK4u 6NcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GZVlra22Hmo943AVWUZYG80lI7tCF9R/POz4LfEwPLM=; b=r6ujxH7VaAI7RvsYC5zltHU/1MJtVq/ix8GOFGQBL6ySwndyReorcQi2UBwY52yyTj ZLDJ8Q6WvU1c6hgiLL+Q6Tqz5HNaPeFrHO2/7AjGWDYqF4MKtK5HQHmXAdTHtwnaKVoN cKRWQtYA+ddC9qA2d2bjA+OwIrwMAcKNQwXnhept2gdbT2F6SaR/pY3Pc6Ynl3tbwowZ 5HOQDu7RbwOGy/5PaORm+re8G4J1En0rS2SAYe1o4sHVjeKaMAo1vGcBYM7/95r8WnZu 0bkEygS2++7cCVp1jsjahYUOzoHgsPOkp7SjduWHVsl9IeXRzbrtZYfRTO6+n3ph/8hW 08XA== X-Gm-Message-State: AElRT7Eefp/aTUEbw0Nhl9MJmkiaBCLUVNO9sJHPj3yVH+0AUUOMS6Ts TXqp+IpWbJ/X3F8k8gW7YDU= X-Google-Smtp-Source: AIpwx4+KI7OKdUkOo4CpRb6x+IJQKSIPNkwsDytESjwORKB1h8g/BOOdOGwaVVw8KrynY9qYU0oEYQ== X-Received: by 2002:a17:902:ab88:: with SMTP id f8-v6mr8326457plr.34.1522641982229; Sun, 01 Apr 2018 21:06:22 -0700 (PDT) Received: from ?IPv6:2601:647:4700:1280:483a:1ec3:e512:4540? ([2601:647:4700:1280:483a:1ec3:e512:4540]) by smtp.gmail.com with ESMTPSA id z83sm21797514pfd.31.2018.04.01.21.06.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Apr 2018 21:06:21 -0700 (PDT) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9B4A154D-2683-4E29-A3B6-406CE2ABEFE8" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Comments on Optimizing BFD Authentication Date: Sun, 1 Apr 2018 21:07:45 -0700 In-Reply-To: Cc: Jeffrey Haas , draft-ietf-bfd-optimizing-authentication@ietf.org, "rtg-bfd@ietf.org" To: Ashesh Mishra References: <20180328165736.GD3126@pfrc.org> X-Mailer: Apple Mail (2.3445.6.18) 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: Mon, 02 Apr 2018 04:06:24 -0000 --Apple-Mail=_9B4A154D-2683-4E29-A3B6-406CE2ABEFE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 1, 2018, at 8:40 AM, Ashesh Mishra = wrote: >=20 > =20 > =20 > What are the yang model considerations? (See prior point.) >=20 > [AM] I'll let Mahesh comment on this.=20 To support the optimized BFD authentication, we will need to change the = BFD YANG model to add a =E2=80=98optimized=E2=80=99 authentication = capability. Following are some of the changes I anticipate - The current model has a typedef for auth-type, but since a bit has not = been assigned (it is a TBD), it will require an update to the typedef to = include the new bit, when it is assigned after IANA approves it.=20 - The current YANG model only supports the meticulous mode of = authentication in its grouping for auth-parms. Will need to make it a = choice between meticulous and the =E2=80=98optimized=E2=80=99 mode. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_9B4A154D-2683-4E29-A3B6-406CE2ABEFE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 1, 2018, at 8:40 AM, Ashesh Mishra <mishra.ashesh@gmail.com> wrote:

 
 
What are the = yang model considerations?  (See prior point.)

[AM] = I'll let Mahesh comment on this. 

To support the optimized BFD authentication, we = will need to change the BFD YANG model to add a =E2=80=98optimized=E2=80=99= authentication capability.

Following = are some of the changes I anticipate

-= The current model has a typedef for auth-type, but since a bit has not = been assigned (it is a TBD), it will require an update to the typedef to = include the new bit, when it is assigned after IANA approves = it. 

- The current YANG model = only supports the meticulous mode of authentication in its grouping for = auth-parms. Will need to make it a choice between meticulous and the = =E2=80=98optimized=E2=80=99 mode.


Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_9B4A154D-2683-4E29-A3B6-406CE2ABEFE8-- From nobody Mon Apr 2 05:08: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 F10A21275AB; Mon, 2 Apr 2018 05:08:55 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 KnePizjHO65f; Mon, 2 Apr 2018 05:08:54 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1B71205D3; Mon, 2 Apr 2018 05:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13294; q=dns/txt; s=iport; t=1522670934; x=1523880534; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FJtD0S5UnI0HNmterH/1FbqrJJa0T173wtiAJJg8p0g=; b=VpzjyjmkJkSU/SF2ZxNKOP6GEoIcsoHmhiVmv6zCDm1MGkpTXALS8a6f aO+AOWWs7pYVkGRruEhY6wXL5+wVF/yO8rB9y3mL9Otya/VJOQK5pUB5q dp6Bd6LtcJ5k9xZvIer7lTRo6qspN389qoFfasvnwxVogBnbJm2x+1TAu k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DaAAAMHcJa/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJNdWFvKAqDUogAjQGBUyGBD4Zhhw6EZIF6C4UEAhqEFiE0GAE?= =?us-ascii?q?CAQEBAQEBAmsohSQBAQEBAyNWEAIBCA4DAwECKAMCAgIfERQJCAIEAQ0FhClMA?= =?us-ascii?q?xWuS4IchwENgSyCK4dhghOBDCIMglaCT4JAFoJKMIIkAogIjwYsCAKLMIJ8gTC?= =?us-ascii?q?LB4cmgiqGBgIREwGBJAEcOIFScBVkAYIYCZBEb40TgRcBAQ?= X-IronPort-AV: E=Sophos;i="5.48,395,1517875200"; d="scan'208,217";a="157562992" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Apr 2018 12:08:53 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w32C8rGQ011972 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2018 12:08:53 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; Mon, 2 Apr 2018 08:08:52 -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; Mon, 2 Apr 2018 08:08:52 -0400 From: "Acee Lindem (acee)" To: Mahesh Jethanandani , Ashesh Mishra CC: "rtg-bfd@ietf.org" , "draft-ietf-bfd-optimizing-authentication@ietf.org" Subject: Re: Comments on Optimizing BFD Authentication Thread-Topic: Comments on Optimizing BFD Authentication Thread-Index: AQHTxrXg3MGGV9JCBUmQ/g36/nPaQ6PsVQaAgADQ6oCAAENeAA== Date: Mon, 2 Apr 2018 12:08:52 +0000 Message-ID: References: <20180328165736.GD3126@pfrc.org> 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.200] Content-Type: multipart/alternative; boundary="_000_D08326D225154348982A159971BBE5E7ciscocom_" 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: Mon, 02 Apr 2018 12:08:56 -0000 --_000_D08326D225154348982A159971BBE5E7ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFoZXNoIOKAkyBJIGJlbGlldmUgdGhlc2Ugc2hvdWxkIGJlIGRvbmUgYXMgYXVnbWVudGF0aW9u cyBzaW5jZSBkcmFmdC1pZXRmLWJmZC15YW5nLTEzIGhhcyBhbHJlYWR5IGJlZW4gc3VibWl0dGVk IHRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbi4NClRoYW5rcywNCkFjZWUNCg0KRnJvbTogUnRn LWJmZCA8cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgTWFoZXNoIEpldGhh bmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQpEYXRlOiBNb25kYXksIEFwcmlsIDIs IDIwMTggYXQgMTI6MDYgQU0NClRvOiBBc2hlc2ggTWlzaHJhIDxtaXNocmEuYXNoZXNoQGdtYWls LmNvbT4NCkNjOiAicnRnLWJmZEBpZXRmLm9yZyIgPHJ0Zy1iZmRAaWV0Zi5vcmc+LCAiZHJhZnQt aWV0Zi1iZmQtb3B0aW1pemluZy1hdXRoZW50aWNhdGlvbkBpZXRmLm9yZyIgPGRyYWZ0LWlldGYt YmZkLW9wdGltaXppbmctYXV0aGVudGljYXRpb25AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogQ29t bWVudHMgb24gT3B0aW1pemluZyBCRkQgQXV0aGVudGljYXRpb24NCg0KDQoNCg0KT24gQXByIDEs IDIwMTgsIGF0IDg6NDAgQU0sIEFzaGVzaCBNaXNocmEgPG1pc2hyYS5hc2hlc2hAZ21haWwuY29t PG1haWx0bzptaXNocmEuYXNoZXNoQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoNCg0KV2hhdCBhcmUg dGhlIHlhbmcgbW9kZWwgY29uc2lkZXJhdGlvbnM/ICAoU2VlIHByaW9yIHBvaW50LikNCg0KW0FN XSBJJ2xsIGxldCBNYWhlc2ggY29tbWVudCBvbiB0aGlzLg0KDQpUbyBzdXBwb3J0IHRoZSBvcHRp bWl6ZWQgQkZEIGF1dGhlbnRpY2F0aW9uLCB3ZSB3aWxsIG5lZWQgdG8gY2hhbmdlIHRoZSBCRkQg WUFORyBtb2RlbCB0byBhZGQgYSDigJhvcHRpbWl6ZWTigJkgYXV0aGVudGljYXRpb24gY2FwYWJp bGl0eS4NCg0KRm9sbG93aW5nIGFyZSBzb21lIG9mIHRoZSBjaGFuZ2VzIEkgYW50aWNpcGF0ZQ0K DQotIFRoZSBjdXJyZW50IG1vZGVsIGhhcyBhIHR5cGVkZWYgZm9yIGF1dGgtdHlwZSwgYnV0IHNp bmNlIGEgYml0IGhhcyBub3QgYmVlbiBhc3NpZ25lZCAoaXQgaXMgYSBUQkQpLCBpdCB3aWxsIHJl cXVpcmUgYW4gdXBkYXRlIHRvIHRoZSB0eXBlZGVmIHRvIGluY2x1ZGUgdGhlIG5ldyBiaXQsIHdo ZW4gaXQgaXMgYXNzaWduZWQgYWZ0ZXIgSUFOQSBhcHByb3ZlcyBpdC4NCg0KLSBUaGUgY3VycmVu dCBZQU5HIG1vZGVsIG9ubHkgc3VwcG9ydHMgdGhlIG1ldGljdWxvdXMgbW9kZSBvZiBhdXRoZW50 aWNhdGlvbiBpbiBpdHMgZ3JvdXBpbmcgZm9yIGF1dGgtcGFybXMuIFdpbGwgbmVlZCB0byBtYWtl IGl0IGEgY2hvaWNlIGJldHdlZW4gbWV0aWN1bG91cyBhbmQgdGhlIOKAmG9wdGltaXplZOKAmSBt b2RlLg0KDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1h aWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQo= --_000_D08326D225154348982A159971BBE5E7ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <49EA2F81867C214DA8035D186B6A299A@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiBcKEJvZHkgQ1NcKSI7DQoJcGFub3NlLTE6MiAxMSA2IDQg MiAyIDIgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAs IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h bDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHls ZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdCI+TWFoZXNoIOKAkyBJIGJlbGlldmUgdGhl c2Ugc2hvdWxkIGJlIGRvbmUgYXMgYXVnbWVudGF0aW9ucyBzaW5jZSBkcmFmdC1pZXRmLWJmZC15 YW5nLTEzIGhhcyBhbHJlYWR5IGJlZW4gc3VibWl0dGVkIHRvIHRoZSBJRVNHIGZvciBwdWJsaWNh dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjE2LjBwdCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTYuMHB0Ij5BY2VlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToN Cjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlJ0 Zy1iZmQgJmx0O3J0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIE1haGVz aCBKZXRoYW5hbmRhbmkgJmx0O21qZXRoYW5hbmRhbmlAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRh dGU6IDwvYj5Nb25kYXksIEFwcmlsIDIsIDIwMTggYXQgMTI6MDYgQU08YnI+DQo8Yj5UbzogPC9i PkFzaGVzaCBNaXNocmEgJmx0O21pc2hyYS5hc2hlc2hAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNj OiA8L2I+JnF1b3Q7cnRnLWJmZEBpZXRmLm9yZyZxdW90OyAmbHQ7cnRnLWJmZEBpZXRmLm9yZyZn dDssICZxdW90O2RyYWZ0LWlldGYtYmZkLW9wdGltaXppbmctYXV0aGVudGljYXRpb25AaWV0Zi5v cmcmcXVvdDsgJmx0O2RyYWZ0LWlldGYtYmZkLW9wdGltaXppbmctYXV0aGVudGljYXRpb25AaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBDb21tZW50cyBvbiBPcHRpbWl6aW5n IEJGRCBBdXRoZW50aWNhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxhIG5hbWU9Il9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwv YT48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij5PbiBBcHIgMSwgMjAxOCwgYXQgODo0MCBBTSwgQXNoZXNoIE1pc2hyYSAm bHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptaXNocmEuYXNoZXNoQGdtYWlsLmNvbSI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+bWlzaHJhLmFzaGVzaEBnbWFp bC5jb208L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4m Z3Q7DQogd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbjtjYXJldC1jb2xvcjogcmdiKDAsIDAs IDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTpIZWx2ZXRpY2EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW47Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5XaGF0 IGFyZSB0aGUgeWFuZyBtb2RlbCBjb25zaWRlcmF0aW9ucz8mbmJzcDsgKFNlZSBwcmlvciBwb2lu dC4pPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPltBTV0g SSdsbCBsZXQgTWFoZXNoIGNvbW1lbnQgb24gdGhpcy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+VG8gc3VwcG9ydCB0aGUg b3B0aW1pemVkIEJGRCBhdXRoZW50aWNhdGlvbiwgd2Ugd2lsbCBuZWVkIHRvIGNoYW5nZSB0aGUg QkZEIFlBTkcgbW9kZWwgdG8gYWRkIGEg4oCYb3B0aW1pemVk4oCZIGF1dGhlbnRpY2F0aW9uIGNh cGFiaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5Gb2xsb3dpbmcg YXJlIHNvbWUgb2YgdGhlIGNoYW5nZXMgSSBhbnRpY2lwYXRlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij4tIFRoZSBjdXJyZW50IG1vZGVsIGhhcyBhIHR5cGVkZWYgZm9yIGF1 dGgtdHlwZSwgYnV0IHNpbmNlIGEgYml0IGhhcyBub3QgYmVlbiBhc3NpZ25lZCAoaXQgaXMgYSBU QkQpLCBpdCB3aWxsIHJlcXVpcmUgYW4gdXBkYXRlIHRvIHRoZSB0eXBlZGVmIHRvIGluY2x1ZGUg dGhlIG5ldyBiaXQsDQogd2hlbiBpdCBpcyBhc3NpZ25lZCBhZnRlciBJQU5BIGFwcHJvdmVzIGl0 LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+LSBUaGUgY3VycmVu dCBZQU5HIG1vZGVsIG9ubHkgc3VwcG9ydHMgdGhlIG1ldGljdWxvdXMgbW9kZSBvZiBhdXRoZW50 aWNhdGlvbiBpbiBpdHMgZ3JvdXBpbmcgZm9yIGF1dGgtcGFybXMuIFdpbGwgbmVlZCB0byBtYWtl IGl0IGEgY2hvaWNlIGJldHdlZW4gbWV0aWN1bG91cyBhbmQgdGhlDQog4oCYb3B0aW1pemVk4oCZ IG1vZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki Pk1haGVzaCBKZXRoYW5hbmRhbmk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L3NwYW4+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxicj4NCjxi cj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D08326D225154348982A159971BBE5E7ciscocom_-- From nobody Mon Apr 2 05:47: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 F2C691275AB; Mon, 2 Apr 2018 05:47:22 -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, MIME_QP_LONG_LINE=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 jhgPuln6NFBP; Mon, 2 Apr 2018 05:47:21 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 17C72124D37; Mon, 2 Apr 2018 05:47:21 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id l27so9443435pfk.12; Mon, 02 Apr 2018 05:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=q6Z7+sFAck15vF57meNR4+ou9rwIbGoDbSQtOl62PmE=; b=ZRcRotBonZ9d8O8zLQXmWXEEfanvcQ6CzPWu2IX+q6n21azlSfNp7jTxw3TmRA35vc aS26e7Hjwa2MMkjA8p3YmLv3VkHU2VcYY+WKRDQBexj6goQr0AkCxD0Rw9D1XTvkQWeD kCwJiYuLAwWkI9MVk0oKnTfQ39xOaJ8Cd7TCOKHKro+5dcpzo7sY53S0z8j4P4DpiR0R 2nCCsR1mCH1MHYu4dEb8RjPP6WDkW0Qe7y7A9UTCOkG2amD1LTuSl7r0frt6H11LEBYw /EsrrmDoiDCx81BVMJgxteAy04wDCxZZrHV6PiLSJS3TfCYT7D/Ewg9i/hA8gfdXd/ta vwKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=q6Z7+sFAck15vF57meNR4+ou9rwIbGoDbSQtOl62PmE=; b=bA5t5SS2UMg6YnJh2JkwFufVdZSBPa059qhuPikbDlGqtsFLK7kQrW+YbmdYKh6FPE 1IU+6NBJ0A0+mKo2A31jYQeiIxF1l5xEeZE+ZSfarhE6YE8JYQv2v+l6GUP8fzaTD82e KccdO9uo5Ssn2Xc84TJYKUG2D+rJ0LR4nKvozJixbZGgZHILHhPST+2juGtSuoGcNzZz MVRaVQaDMtXxiWxJfa7CwxwrljxOA2MNDwsJ+VyXf/cId+zdDpxf/yjGrKEUIiEn5eIc fxMipWWtQTt2KHPRB474UinjEB+CyXX/Fu2y0nBUuEs0quLvkAlfyVCkcondgox6U+TP fJcg== X-Gm-Message-State: AElRT7FPouPCE7aY5Z9hrNi6+F1QCCrbcUcdmWDpsdLRU6cITRlI2S+t GzMO8vkyOPboRMXH8QVBciPT+SYJ X-Google-Smtp-Source: AIpwx49XLiKcuisspamFDZpiOryBCv+m9jpcucn1Q1dnnM+SEI0ZQMI5DQ/Z10vzP8T/a+nybuRUBA== X-Received: by 10.98.137.218 with SMTP id n87mr7376934pfk.48.1522673240564; Mon, 02 Apr 2018 05:47:20 -0700 (PDT) Received: from [192.168.1.108] (c-24-6-191-201.hsd1.ca.comcast.net. [24.6.191.201]) by smtp.gmail.com with ESMTPSA id h15sm742548pfi.56.2018.04.02.05.47.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 02 Apr 2018 05:47:19 -0700 (PDT) References: <20180328165736.GD3126@pfrc.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-43E22E4D-F6EA-4E55-AA78-8B20C963947E Content-Transfer-Encoding: 7bit Message-Id: Cc: Ashesh Mishra , "rtg-bfd@ietf.org" , "draft-ietf-bfd-optimizing-authentication@ietf.org" X-Mailer: iPad Mail (13G36) From: Mahesh Jethanandani Subject: Re: Comments on Optimizing BFD Authentication Date: Mon, 2 Apr 2018 05:47:18 -0700 To: "Acee Lindem (acee)" 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: Mon, 02 Apr 2018 12:47:23 -0000 --Apple-Mail-43E22E4D-F6EA-4E55-AA78-8B20C963947E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Acee, Or by doing a "bis" version of the draft. There is no way to augment a typed= ef. Mahesh Jethanandani mjethanandani@gmail.com > On Apr 2, 2018, at 5:08 AM, Acee Lindem (acee) wrote: >=20 > Mahesh =E2=80=93 I believe these should be done as augmentations since dra= ft-ietf-bfd-yang-13 has already been submitted to the IESG for publication. > Thanks, > Acee > =20 > From: Rtg-bfd on behalf of Mahesh Jethanandani <= mjethanandani@gmail.com> > Date: Monday, April 2, 2018 at 12:06 AM > To: Ashesh Mishra > Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-optimizing-auth= entication@ietf.org" > Subject: Re: Comments on Optimizing BFD Authentication > =20 > =20 >=20 >=20 > On Apr 1, 2018, at 8:40 AM, Ashesh Mishra wrote:= > =20 > =20 > =20 > What are the yang model considerations? (See prior point.) > =20 > [AM] I'll let Mahesh comment on this.=20 > =20 > To support the optimized BFD authentication, we will need to change the BFD= YANG model to add a =E2=80=98optimized=E2=80=99 authentication capability. > =20 > Following are some of the changes I anticipate > =20 > - The current model has a typedef for auth-type, but since a bit has not b= een assigned (it is a TBD), it will require an update to the typedef to incl= ude the new bit, when it is assigned after IANA approves it.=20 > =20 > - The current YANG model only supports the meticulous mode of authenticati= on in its grouping for auth-parms. Will need to make it a choice between met= iculous and the =E2=80=98optimized=E2=80=99 mode. > =20 > =20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 --Apple-Mail-43E22E4D-F6EA-4E55-AA78-8B20C963947E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Acee,

Or by doing a "bis" version of t= he draft. There is no way to augment a typedef.

Mahesh Jethanandanimjethanandani@gmail.com

On Apr 2, 2018, at 5:08 AM, Acee Lindem (acee) <acee@cisco.com> wrote:

Mahesh =E2=80=93 I b= elieve these should be done as augmentations since draft-ietf-bfd-yang-13 ha= s already been submitted to the IESG for publication.

Thanks,

Acee

 

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf= of Mahesh Jethanandani <mjeth= anandani@gmail.com>
Date: Monday, April 2, 2018 at 12:06 AM
To: Ashesh Mishra <mish= ra.ashesh@gmail.com>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-optimiz= ing-authentication@ietf.org" <draft-ietf-bfd-optimizing-authentication@ietf.= org>
Subject: Re: Comments on Optimizing BFD Authentication

 

 



On Apr 1, 2018, at 8:40 AM, Ashesh Mishra <mishra.ashesh@gmail.com> wrote:

 

&= nbsp;

&= nbsp;

W= hat are the yang model considerations?  (See prior point.)

<= o:p> 

[= AM] I'll let Mahesh comment on this. 

 

To support the optimized BFD authentication, we will ne= ed to change the BFD YANG model to add a =E2=80=98optimized=E2=80=99 authent= ication capability.

 

Following are some of the changes I anticipate

 

- The current model has a typedef for auth-type, but si= nce a bit has not been assigned (it is a TBD), it will require an update to t= he typedef to include the new bit, when it is assigned after IANA approves it. 

 

- The current YANG model only supports the meticulous m= ode of authentication in its grouping for auth-parms. Will need to make it a= choice between meticulous and the =E2=80=98optimized=E2=80=99 mode.

 

 

Mahesh Jethanandani



= --Apple-Mail-43E22E4D-F6EA-4E55-AA78-8B20C963947E-- From nobody Mon Apr 2 09:18:21 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 C6CAE12D77C for ; Mon, 2 Apr 2018 09:18:19 -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 EHJp_p43h-B8 for ; Mon, 2 Apr 2018 09:18:16 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 A3C4012D889 for ; Mon, 2 Apr 2018 09:18:03 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id d1so14494670wrj.13 for ; Mon, 02 Apr 2018 09:18:03 -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=jguO/Rh80XdORPX9K7OYfJAI7L2sHhfpYSPyT6k/pXo=; b=Jhgv99nSEUn9iRo8BDEp1dnr1w302PMbCOK0hPwnxAmkPKC9vh461+Co1g71jl8QNx CjbIISn0D1eoV6a5CG1/MESkS5bVDTujvI/qJqnsAJJRR/DJcUBeOnI8LD/c+vTD4QhQ kcOxkWyZ05tQ6vFaDDRQegcJlfosjaKWoUFun2cAroC3nNw0pq4ZCURV//ViacddMNxw URV2gQl2qqUCWvfX1dtJLgN3bYDfnJrbsINbx3ODbqT/F8mz/90MMpnYLUIi5Hv54hUI puONjTSnXmWoEfLxqTU1jX8T+iGEXTKxw6nmESpIkKSIKwbUQ487pi6XzozTeBKlICOL p/tA== 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=jguO/Rh80XdORPX9K7OYfJAI7L2sHhfpYSPyT6k/pXo=; b=QYu115mk8o9xrTfwL+vK4sM6BhLMz8uS6MdzxW+ZQHtkWgLc/dw7hHU5jDQowXD5cQ RwhFtmrwYpkDDL7hiVHBy97uvTRve7M04M6TPmQielHzCATkFTZn3hfecXoONil0YNHP zET4ErDPZkJ3Vf1RjwpX71yDAsJ2pxccd+nUns38tyjhyCUMy8Rlbd0q4uTBQj95n3C8 O1jzKsZ7V49YLvdXuZQFWdmBurUzHuC2Dtw7ZF2hwqkSAGdvz8DNw2MTqUzBACJtAFrd z4HDiWcWKOELFKUPWV/PcXMdMt3U87tHRaSV5kYnKZUXJkrqw1oxmrlMjrHLWXxb+F6j z2wA== X-Gm-Message-State: ALQs6tD+i6JDL1pg0c60bN/Fl7Kcxwuhl1+nf8KTo0A5ro2WbX6MoNZL I4h+XYG/eupvESE2qQO0D9r+/PyAcj0bXAm6gw0= X-Google-Smtp-Source: AIpwx4/P6YqFN/kz+49vNOCudoefscV5FZoTRDMwusNprFB/MG/CzsjofLs8mVkIFh+mn0/DXQFSQRK+WoJ+MleTfQw= X-Received: by 2002:a19:179b:: with SMTP id 27-v6mr5835348lfx.143.1522685881907; Mon, 02 Apr 2018 09:18:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.73.66 with HTTP; Mon, 2 Apr 2018 09:18:01 -0700 (PDT) In-Reply-To: References: <20180328184959.GB25442@pfrc.org> From: Greg Mirsky Date: Mon, 2 Apr 2018 19:18:01 +0300 Message-ID: Subject: Re: Tuning BFD session times To: Ashesh Mishra Cc: Alexander Vainshtein , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary="000000000000187dc50568dfef3c" 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: Mon, 02 Apr 2018 16:18:20 -0000 --000000000000187dc50568dfef3c Content-Type: text/plain; charset="UTF-8" Hi Asheh, thank you for very detailed explanation of the scenarios that had motivated this work. Couple questions to help me better understand the use cases: - if understand the first scenario, you propose to use BFD to measure the propagation delay as it is the main component that influences BFD interval selection. Do you see that available on-demand tools, e.g. ICMP ping, not adequate to monitor RTT? What functionality is absent? - For the case #2, the same question as above as I believe that ICMP ping can be directed over the specific egress interface quite easily. Regards, Greg On Sun, Apr 1, 2018 at 8:17 PM, Ashesh Mishra wrote: > Hi Sasha, > > > There are two scenarios here and they depend on whether the satellite is > in geo-stationary orbit (GEO) or non-geo-stationary orbit (NGSO). > > > Scenario-1: Non-Geostationary Satellites: This is the scenario that you > described. Satellites in Middle Earth Orbit (MEO) or Low Earth Orbit (LEO) > move relative to the earth and hence, their distance from the ground > terminals varies as they pass over a given location. This results in > varying RTT (sometimes by as much as 30ms). The issue in this scenario is > not necessarily that the BFD detect interval must change frequently but > that it's difficult to accurately select the intervals as the RTT depends > on the location of the terminal and the gateway (and this gets quite > complex). If the session can automatically decide the interval, then the > complexity in starting a new service is reduced. Another complicating > factor is when the terminal moves (ship or aircraft, for example) as this > increases the variance of the RTT. We typically set the intervals to a high > enough level but that affects the performance. We see the same varying RTT > in GEO when the terminal is mobile but the percentage change is much > smaller than the overall RTT of GEO (because GEO satellites are much > farther away from the earth at ~36,000kms vs MEO at ~8,000kms and LEO at > ~200-1000kms). > > > Scenario-2: Low-latency link backed up by high-latency link: In this case > a GEO satellite backs up NGSO-based connection or fiber (or other > terrestrial wired/wireless WAN options). The end-to-end service then has > very different RTT when the primary is active versus when the backup is > active. The typical solution is to base timers on the backup RTT, which is > very inefficient. > > > Regards, > > Ashesh > ------------------------------ > *From:* Alexander Vainshtein > *Sent:* Sunday, April 1, 2018 9:28:43 AM > *To:* Ashesh Mishra > *Cc:* Jeffrey Haas; rtg-bfd@ietf.org > *Subject:* RE: Tuning BFD session times > > > Ashesh, > > I would like to understand better the use case with satellite links that > you have described. > > In particular, can you please explain why long RTT affects the BFD > detection times? > > As I see it, what could really affect these times is variable delay > introduced in some cases by the satellite links since the distance between > the satellite and the terrestrial antennae may change significantly with > time. > > > > What did I miss? > > > > Regards, > > Sasha > > > > Office: +972-39266302 <+972%203-926-6302> > > Cell: +972-549266302 <+972%2054-926-6302> > > Email: Alexander.Vainshtein@ecitele.com > > > > *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] *On Behalf Of *Ashesh > Mishra > *Sent:* Sunday, April 1, 2018 5:54 PM > *To:* Jeffrey Haas ; rtg-bfd@ietf.org > *Subject:* Re: Tuning BFD session times > > > > Jeff, thanks for kicking-off this discussion on the list! > > > > One additional comment that I wanted to make was around automation. There > were questions during the meeting around the need for auto-tuning and that > the process of determining the interval can/should be manual. > > > > The automation of control in all aspects of dynamic behavior is a priority > for network operators. When configuring manually, parameters such BFD > intervals are typically set at very conservative values because human > latency is very high when responding to changing network conditions. Manual > configuration also takes a lot of time and is accounts for significant > number of lost opportunities and value for operators. > > > > *[JH] "**applications should generally choose a detection interval that > is reasoanble for their application rather than try to dynamically discover > the lowest possible stable detection interval. **"* > > [AM] This depends on the use-case. From the point-of-view of a service > provider that delivers long-haul connectivity (typical scenario in which > the link characteristics have large variance) then the intent is to provide > the best performance. As such providers deliver connectivity to critical > applications, and are often the only way of delivering connectivity in such > places, the ability to tune the system to deliver an up-time that is > superior drives significant value. Consider a scenario where there is a > 130ms RTT link (MEO satellite, LEO will be in the 20-60ms range) and its > backup is a 600ms RTT link (GEO satellite), and are being used to deliver > transit connectivity. The rate at which the end-to-end service can run BFD > is significantly faster when MEO is active versus when GEO is active. The > application, in this scenario, may survive the RTT, but the business > continuity is critical in many cases. Since the provider of long-haul can > not control the application, it must provide the best possible failover > performance. > > > > *[JH] "1. BFD is asymmetric.. This means a receiving BFD implementation > must provide feedback to a sending implementation in order for it to > understand perceived reliability."* > > [AM] May not need to be the BFD implementation providing the feedback if > there are other performance mechanisms running. The challenge is to > standardize the mechanism that BFD can use (if the measurement is not > self-contained in BFD). You're right in pointing out the challenge in > accounting for the CPU delays and that was the reason for the original > proposal for BFD performance measurement. If the measurement is within the > BFD realm, it will account for the CPU delays. However, most good BFD > engines have relatively deterministic performance and are quite optimized > so the variance with scale and time is not significant (but I concede that > not all BFD implementations are good). > > > > *[JH] "2. Measurement infrastructure may negatively impact session scale. > Greg, I believe, made this point when discussing host processing issues vs. > BFD ingress/egress."* > > [AM] This is an issue if using a measurement mechanism within BFD (other > performance measurement methods are always running in network for SLA > reporting and/or network optimization). Within a metro-area with fiber or > terrestrial wireless (microwave, LTE, etc.) connectivity, I would likely > not need constant auto-tuning. The variance in the primary and backup links > in such network will not be significant to affect the BFD parameters. In > long-haul links, this may be a valuable feature in which case, the > additional overhead may be justified. So it depends on the use-case whether > continuous auto-tuning is required or if it is one-time. > > > > *[JH] "3. Detection interval calculations really need to take into account > things that are greater than simple packet transmission times. As an > example, if your measurement is always taken during low system CPU or > network activity, how high is your confidence about the interval? What > about scaling vs. number of total BFD sessions?"* > > [AM] Great questions. Typically when running BFD or CFM (or similar) high > frequency OAM, CPU peaks should not affect the OAM performance (a variety > of methods, based on the system on which OAM is running, can ensure that). > CPU peaks become a bigger issue if BFD is used to detect continuity for a > particular flow (or QoS). > > > > -- > > Asheh > ------------------------------ > > *From:* Rtg-bfd on behalf of Jeffrey Haas < > jhaas@pfrc..org > > > *Sent:* Wednesday, March 28, 2018 11:49 AM > *To:* rtg-bfd@ietf.org > *Subject:* Tuning BFD session times > > > > Working Group, > > We had very active discussion (yay!) at the microphone as part of Mahesh's > presentation on BFD Performance Measurement. > (draft-am-bfd-performance) > > I wanted to start this thread to discuss the greater underlying issues this > discussion raised. In particular, active tuning of BFD session parameters. > Please note that opinions I state here are as an individual contributor. > > BFD clients typically want the fastest, most stable detection interval that > is appropriate to their application. That stability component is very > important since too aggressive of timers can result in unnecessary BFD > session instability which will impact the subscribing application. Such > stability is a function of many things, scale of the system running BFD > being a major one. > > In my opinion, applications should generally choose a detection interval > that is reasoanble for their application rather than try to dynamically > discover the lowest possible stable detection interval. This is because a > number of unstable factors, such as CPU load, contention with other network > traffic and other things that are outside the general control of many > sytems may impact such scale. > > That said, here's a few thoughts on active feedback mechanisms: > 1. BFD is asymmetric. This means a receiving BFD implementation must > provide > feedback to a sending implementation in order for it to understand > perceived reliability. > 2. Measurement infrastructure may negatively impact session scale. Greg, I > believe, made this point when discussing host processing issues vs. BFD > ingress/egress. > 3. Detection interval calculations really need to take into account things > that are greater than simple packet transmission times. As an example, > if your measurement is always taken during low system CPU or network > activity, how high is your confidence about the interval? What about > scaling vs. number of total BFD sessions? > > I have no strong conclusions here, just some cautionary thoughts. > > What are yours? > > -- Jeff > > ____________________________________________________________ > _______________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > ____________________________________________________________ > _______________ > --000000000000187dc50568dfef3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Asheh,
thank you for very detailed explanation of t= he scenarios that had motivated this work. Couple questions to help me bett= er understand the use cases:
  • if understand the first scen= ario, you propose to use BFD to measure the propagation delay as it is the = main component that influences BFD interval selection. Do you see that avai= lable on-demand tools, e.g. ICMP ping, not adequate to monitor RTT? What fu= nctionality is absent?
  • For the case #2, the same question as above = as I believe that ICMP ping can be directed over the specific egress interf= ace quite easily.
Regards,
Greg

On Sun, Apr 1, 2018= at 8:17 PM, Ashesh Mishra <mishra.ashesh@outlook.com> wrote:

Hi Sasha,


There are two scenarios here and = they depend on whether the satellite is in=C2=A0geo-stationary orbit (GEO) = or non-geo-stationary orbit (NGSO).=C2=A0


Scenario-1: Non-Geostationary Sat= ellites: This is the scenario that you described.=C2=A0Satellites in Middle= Earth Orbit (MEO) or Low Earth Orbit (LEO) move relative to the earth and = hence, their distance from the ground terminals varies as they pass over a given location. This results in varying RTT (so= metimes by as much as 30ms). The issue in this scenario is not necessarily = that the BFD=C2=A0detect interval must change frequently but that it's = difficult to accurately select the intervals as the RTT depends on the location of the terminal and the gateway (and th= is gets quite complex). If the session can automatically decide the interva= l, then the complexity in starting a new service is reduced. Another compli= cating factor is when the terminal=C2=A0moves (ship or aircraft, for example) as this increases the variance=C2=A0of the= RTT. We typically set the intervals to a high enough level but that affect= s the performance. We see the same varying RTT in GEO when the terminal is = mobile but the percentage change is much smaller than the overall RTT of GEO (because GEO satellites are much farth= er away from the earth at ~36,000kms vs MEO at ~8,000kms and LEO at ~200-10= 00kms).=C2=A0


Scenario-2: Low-latency link back= ed up by high-latency link: In this case a GEO satellite backs up NGSO-base= d connection or fiber (or other terrestrial wired/wireless WAN options). Th= e end-to-end service then has very different RTT when the primary is active versus when the backup is active.= The typical solution is to base timers on the backup RTT, which is very in= efficient.=C2=A0


Regards,

Ashesh

From: = Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Sent: Sunday, April 1, 2018 9:28:43 AM
To: Ashesh Mishra
Cc: Jeffrey Haas; rtg-bfd@ietf.org
Subject: RE: Tuning BFD session times
=C2=A0

Ashesh,=

I would like t= o understand better the use case with satellite links that you have describ= ed.

In particular,= can you please explain why long RTT affects the BFD detection times?

As I see it, w= hat could really affect these times is variable delay introduced in some ca= ses by the satellite links since the distance between the satellite and the terrestrial antennae may change significantly with time.

=C2=A0<= /p>

What did I mis= s?

=C2=A0<= /p>

Regards,

Sasha

=C2=A0<= /p>

Office: +972-3= 9266302

Cell:=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 +972-549266302

Email:=C2=A0= =C2=A0 Alexander.Vainshtein@ecitele.com

=C2=A0<= /p>

From: Rtg-bfd= [mailto:rtg-= bfd-bounces@ietf.org] On Behalf Of Ashesh Mishra
Sent: Sunday, April 1, 2018 5:54 PM
To: Jeffrey Haas <jhaas@pfrc.org>; rtg-bfd@ietf.org
Subject: Re: Tuning BFD session times

=C2=A0

J= eff, thanks for kicking-off this discussion on the list!

= =C2=A0

O= ne additional comment that I wanted to make was around automation.=C2=A0The= re were questions during the meeting around the need for auto-tuning and th= at the process of determining the interval can/should be manual.

= =C2=A0

T= he automation of control in all aspects of dynamic behavior is a priority f= or network operators. When configuring manually, parameters such BFD interv= als are typically set at very conservative values because human latency is very high when responding to changing netw= ork conditions. Manual configuration also takes a lot of time and is accoun= ts for significant number of lost opportunities and value for operators.=C2= =A0

= =C2=A0

[JH]=C2=A0"applications should generally = choose a detection interval=C2=A0that is reasoanble for their application rather than try to=C2=A0dynamically=C2=A0discover the lowest possible stab= le detection interval.=C2=A0"

[= AM] This depends on the use-case. From the point-of-view of a service provi= der that delivers long-haul connectivity (typical scenario in which the lin= k characteristics have large variance) then the intent is to provide the best performance. As such providers deliver c= onnectivity to critical applications, and are often the only way of deliver= ing connectivity in such places, the ability to tune the system to deliver = an up-time that is superior drives significant value. Consider a scenario where there is a 130ms RTT link (ME= O satellite, LEO will be in the 20-60ms range) and its backup is a 600ms RT= T link (GEO satellite), and are being used to deliver transit connectivity.= The rate at which the end-to-end service can run BFD is significantly faster when MEO is active versus when= GEO is active. The application, in this scenario, may survive the RTT, but= the business continuity is critical in many cases. Since the provider of l= ong-haul can not control the application, it must provide the best possible failover performance.=C2=A0

= =C2=A0

[JH] "1. BFD is asymmetric..=C2=A0 This means a rec= eiving BFD implementation must provide=C2=A0feedback to a sending implement= ation in order for it to understand=C2=A0perceived reliability."

[= AM] May not need to be the BFD implementation providing the feedback if the= re are other performance mechanisms running. The challenge is to standardiz= e the mechanism that BFD can use (if the measurement is not self-contained in BFD). You're right in pointing out the challe= nge in accounting for the CPU delays and that was the reason for the origin= al proposal for BFD performance measurement. If the measurement is within t= he BFD realm, it will account for the CPU delays. However, most good BFD engines have relatively deterministic p= erformance and are quite optimized so the variance with scale and time is n= ot significant (but I concede that not all BFD implementations are good).= =C2=A0

= =C2=A0

[JH] "2. Measurement infrastructure may negatively = impact session scale.=C2=A0 Greg, I=C2=A0believe, made this point when disc= ussing host processing issues vs. BFD=C2=A0ingress/egress."=

[= AM] This is an issue if using a measurement mechanism within BFD (other per= formance measurement methods are always running in network for SLA reportin= g and/or=C2=A0network optimization). Within a metro-area with fiber or terrestrial wireless (microwave, LTE, etc.) connectivity, I = would likely not need constant auto-tuning. The variance in the primary and= backup links in such network will not be significant to affect the BFD par= ameters. In long-haul links, this may be a valuable feature in which case, the additional overhead may be ju= stified. So it depends on the use-case whether continuous auto-tuning is re= quired or if it is one-time.=C2=A0

= =C2=A0

[JH] "3. Detection interval calculations really nee= d to take into account things=C2=A0that are greater than simple packet tran= smission times.=C2=A0 As an example,=C2=A0if your measurement is always taken during low system CPU or network=C2=A0activity, how high i= s your confidence about the interval?=C2=A0 What about=C2=A0scaling vs. num= ber of total BFD sessions?"

[AM] Great questions. Typically w= hen running=C2=A0BFD or CFM (or similar) high frequency OAM, CPU peaks shou= ld not affect the OAM performance (a variety of methods, based on the syste= m on which OAM is running,=C2=A0can ensure that). CPU peaks become a bigger = issue if BFD is used to detect continuity for a particular flow (or QoS).= =C2=A0

=C2=A0

--

As= heh

From:<= /b> Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Jeffrey Haas <jhaas@pfrc..org>


Sent: Wednesday, March 28, 2018 11:49 AM
To: rtg-bfd@ie= tf.org
Subject: Tuning BFD session times

=C2=A0

Working Group,

We had very active discussion (yay!) at the microphone as part of Mahesh= 9;s
presentation on BFD Performance Measurement.
(draft-am-bfd-performance)

I wanted to start this thread to discuss the greater underlying issues this=
discussion raised.=C2=A0 In particular, active tuning of BFD session parame= ters.
Please note that opinions I state here are as an individual contributor.
BFD clients typically want the fastest, most stable detection interval that=
is appropriate to their application.=C2=A0 That stability component is very=
important since too aggressive of timers can result in unnecessary BFD
session instability which will impact the subscribing application.=C2=A0 Su= ch
stability is a function of many things, scale of the system running BFD
being a major one.

In my opinion, applications should generally choose a detection interval that is reasoanble for their application rather than try to dynamically
discover the lowest possible stable detection interval.=C2=A0 This is becau= se a
number of unstable factors, such as CPU load, contention with other network=
traffic and other things that are outside the general control of many
sytems may impact such scale.

That said, here's a few thoughts on active feedback mechanisms:
1. BFD is asymmetric.=C2=A0 This means a receiving BFD implementation must = provide
=C2=A0=C2=A0 feedback to a sending implementation in order for it to unders= tand
=C2=A0=C2=A0 perceived reliability.
2. Measurement infrastructure may negatively impact session scale.=C2=A0 Gr= eg, I
=C2=A0=C2=A0 believe, made this point when discussing host processing issue= s vs. BFD
=C2=A0=C2=A0 ingress/egress.
3. Detection interval calculations really need to take into account things<= br> =C2=A0=C2=A0 that are greater than simple packet transmission times.=C2=A0 = As an example,
=C2=A0=C2=A0 if your measurement is always taken during low system CPU or n= etwork
=C2=A0=C2=A0 activity, how high is your confidence about the interval?=C2= =A0 What about
=C2=A0=C2=A0 scaling vs. number of total BFD sessions?

I have no strong conclusions here, just some cautionary thoughts.

What are yours?

-- Jeff


_________________________________________________________________= __________

This e-mail message is intended for the recipient only and contains informa= tion which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have recei= ved this
transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original
and all copies thereof.
_________________________________________________________________= __________

--000000000000187dc50568dfef3c-- From nobody Mon Apr 2 09:34:52 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 20AB2126C26 for ; Mon, 2 Apr 2018 09:34:51 -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 RHSER4ulhj0S for ; Mon, 2 Apr 2018 09:34:48 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 E269212D778 for ; Mon, 2 Apr 2018 09:34:47 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id o8so14599276wra.1 for ; Mon, 02 Apr 2018 09:34:47 -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=VBskD3sSKC88uhxXCpm68/sLoieV8RHf9opPZislCoA=; b=bQW0SW6ghjtYnfHn36TKl+ei7l/tNoB/yoSEBtPAjxGgMc/T1z0I/uU6UpTUlF8/1b yb+/AhIVv1oTMgoZmLoFMYDogBfTkrCBZUTkheZ9GJwYrCTSDVwqrJg159xJecTREnjo k4JwDyF2/1ig4JJ40uhAUks1OrAduvBzqOPvBn1C1+btS3cQnLxqHNDh5NTW0rIB6myu NHZE6GsLzTRSgIAgYEWI12M4DWuGZKjGSKPolsZAEmgMo5WXpD+8mJEbhMlIeyQsx+Fg nSrD2SxeYhyOy5WQtXiJhpj8iA5xT5jeGVhiIhGkjZUVpbEU3h9tyNS+Qm5kas9IREZw OSRA== 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=VBskD3sSKC88uhxXCpm68/sLoieV8RHf9opPZislCoA=; b=MbiOPSS1I/2oykqsaHCtkYp7O29pda54KxggmZF4fqzUrAJ7ngViG//3GHrioHrfVE Yk1s4BuoN+WzfU1UY0DGGCxC/rTHu8ypcWSj9fZbvTZPfWrCbl9wXkk1Ipd54V9lbtaa lUTeMiEE4k8133LMO0VvTsY1Zcf5k9uoCp3Pg2twVpHhjBCrTl43O3zwVxVB/gVyymch cAm7XlYNSPAV93xU/NSXybK0u2c1M+wbcwErKZLh2IGIClPN+kSgIVh75K8NTx1ZsiCa 8XDg4wRBt1it9702kvzPbO6I1dNDgoqTkWOU3sW7HE7z1+5fGCXD/PBzNk66b76wqtQb 4v0A== X-Gm-Message-State: ALQs6tD2Nk918PphTpStALhJPHDoWV/xbbomVHEPPX37kQht+uQISYBr 7NyQSgUXXEzYSEo8By52B8MNHZYbiXNepUlmPJVY8w== X-Google-Smtp-Source: AIpwx4+jHuLHz1jZTUU1JdptbG3rGqfjCg2QCugJb77TUzuGig9SyiljI/0Ay0bDjsAPbx5qtqifnvoLY6/P7RpW/uc= X-Received: by 2002:a19:4d46:: with SMTP id a67-v6mr6485328lfb.36.1522686886251; Mon, 02 Apr 2018 09:34:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.73.66 with HTTP; Mon, 2 Apr 2018 09:34:45 -0700 (PDT) In-Reply-To: References: <20180328163856.GB3126@pfrc.org> From: Greg Mirsky Date: Mon, 2 Apr 2018 19:34:45 +0300 Message-ID: Subject: Re: WGLC BFD Authentication Drafts To: Ashesh Mishra Cc: Jeffrey Haas , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f596680568e02ac5" 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: Mon, 02 Apr 2018 16:34:51 -0000 --000000000000f596680568e02ac5 Content-Type: text/plain; charset="UTF-8" Hi Asheh, thank you for taking time to review the minutes from BFD WG meeting at IETF-98. I don't think that we had enough time to discuss in details my question: Greg Mirsky: One of the possible modes when the session is up is to use authentication with periodic timer trigger? I'd break it into couple more specific questions: - can the periodic Optimized Authentication mode be used without authorization o state changes; - if the answer to the previous question "yes", then when the first authorized BFD control packet must be transmitted by the system; - does the BFD state machine (section 6.2 RFC 5880) changes resulting from introduction of periodic optimized authentication mode; And additional comments: - "For example, the two ends can decide that BFD frames that indicate a state change should be authenticated and enable authentication on those frames only." I don't think that nodes "decide" anything but are configured to do something. - "If the two ends have not previously negotiated which frames they will transmit or receive with authentication enabled ..." I couldn't find the negotiation procedure being described in the document. Is it out-of-band, i.e. by control or management plane, not part of this BFD enhancement? - "The configuration of the periodic authentication interval for BFD CC UP frames is an open issue." I believe that this open issue must be resolved in the definitive manner before the draft moved to WGLC. Regards, Greg On Sun, Apr 1, 2018 at 6:11 PM, Ashesh Mishra wrote: > Hi Greg, > > > Your questions in the IETF-98 meeting seemed to stem from the challenges > of authentication in fast BFD sessions at high scale. > > > I'll address the issue in two parts - > > > "Is there a need for authenticated BFD sessions?" - I believe we can all > agree that there is a clear market need for BFD authentication. So we > should direct the conversation to the way in which we can address this > requirement. > > > "How can authentication work at scale?" - BFD authentication puts > significant stress on the system and a non-meticulous method alleviates > this computation pressure. That's the premise of this draft as it presents > a way to relieve the BFD authentication requirement based on the capability > of the system to handle the additional stress which maintaining the > session scale. > > > There are some BFD systems in the market, which are not conducive to > authentication (even the optimized method), where the impediment to > authentication is due to the implementation details specific to that vendor > or system. > > > I believe all these issues were address during the meeting. Are there any > specific questions that I missed or any recommendations for the method in > which the requirements can be addressed? > > > Thanks, > > Ashesh > ------------------------------ > *From:* Rtg-bfd on behalf of Greg Mirsky < > gregimirsky@gmail.com> > *Sent:* Thursday, March 29, 2018 4:09:32 AM > *To:* Jeffrey Haas > *Cc:* rtg-bfd@ietf.org > *Subject:* Re: WGLC BFD Authentication Drafts > > Dear WG Chairs, et. al, > I cannot support WG LC for draft-ietf-bfd-optimizing-authentication as my > comments at BFD WG meeting dating back to IETF-98 > still > not have been addressed nor even there was an attempt to address. As I've > asked to clarify impact of the proposed mechanism, particularly periodic > authentication, on the BFD State Machine, I'd point that the proposed > mechanism directly affects BFD security as discussed in RFC 5880 and the > section Security Considerations in the document, in my view, does not > adequately reflects that and doesn't explain how the security of the BFD > session maintained when the periodic authentication is in use. > > Regards, > Greg > > On Wed, Mar 28, 2018 at 7:38 PM, Jeffrey Haas wrote: > > Working Group, > > The authors of the following Working Group drafts have requested > Working Group Last Call on the following documents: > > https://tools.ietf.org/html/draft-ietf-bfd-secure-sequence-numbers-01 > https://tools.ietf.org/html/draft-ietf-bfd-optimizing-authentication-04 > https://tools.ietf.org/html/draft-ietf-bfd-stability-01 > > Given the overlap of functionality, WGLC will conclude for the bundle > simultaneously. > > Authors, please positively acknowledge whether or not you know about any > IPR > for your documents. Progression of the document will not be done without > that statement. > > Last call will complete on April 20. > > -- Jeff > > > --000000000000f596680568e02ac5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Asheh,
thank you for taking time to review the minu= tes from BFD WG meeting at IETF-98. I don't think that we had enough ti= me to discuss in details my question:
Greg Mirsky: One of the pos= sible modes when the session is up is to use authentication with periodic t= imer trigger?
I'd break it into couple more spe= cific questions:
  • can the periodic Optimized Authentication mode= be used without authorization o state changes;
  • if the answer to th= e previous question "yes", then when the first authorized BFD con= trol packet must be transmitted by the system;
  • does the BFD state m= achine (section 6.2 RFC 5880) changes resulting from introduction of period= ic optimized authentication mode;
And additional comments:
  • "For example, the two ends can decide that BFD frames that = indicate a state change should be authenticated and enable authentication o= n those frames only."
I don't think that nodes "deci= de" anything but are configured to do something.
  • "If the two ends have not previously negotiated which frames they= will transmit or receive with authentication enabled ..."
    • I = couldn't find the negotiation procedure being described in the document= . Is it out-of-band, i.e. by control or management plane, not part of this = BFD enhancement?
    • "The configuration of the p= eriodic authentication interval for BFD CC UP frames is an open issue."= ;
    =
    I believe that this open issue must be resolved in the definitive mann= er before the draft moved to WGLC.

    Regards= ,
    Greg

    <= br>
    On Sun, Apr 1, 2018 at 6:11 PM, Ashesh Mishra= <mishra.ashesh@outlook.com> wrote:

    Hi Greg,=C2=A0


    Your questions=C2=A0in the IETF-9= 8 meeting seemed to stem from the challenges of authentication in fast BFD = sessions at high scale.=C2=A0


    I'll address the issue in two= parts -=C2=A0


    "Is there a need for authent= icated BFD sessions?" - I believe we can all agree that there is a cle= ar market need for BFD authentication. So we should direct the conversation= to the way in which we can address this requirement.=C2=A0


    "How can authentication work= at scale?" - BFD authentication puts significant stress on the system= and a non-meticulous method alleviates this computation pressure. That'= ;s the premise of this draft as it presents a way to relieve the BFD authentication requirement based on the capability of t= he system to handle the additional stress which maintaining the session=C2= =A0scale.=C2=A0


    There are some BFD systems in the= market, which are not conducive to authentication (even the optimized meth= od), where the impediment to authentication is due to the implementation de= tails specific to that vendor or system.=C2=A0


    I believe all these issues were a= ddress during the meeting. Are there any specific questions that I missed o= r any recommendations for the method in which the requirements can be addre= ssed?=C2=A0


    Thanks,

    Ashesh

    From: = Rtg-bfd <r= tg-bfd-bounces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com><= br> Sent: Thursday, March 29, 2018 4:09:32 AM
    To: Jeffrey Haas
    Cc: rtg-bfd@ie= tf.org
    Subject: Re: WGLC BFD Authentication Drafts
    =C2=A0
    Dear WG Chairs, et. al,=C2=A0
    I cannot support WG LC for=C2=A0draft-ietf-bfd-optimizing-authent= ication as my comments at BFD WG meeting dating back to IETF-98=C2=A0still= not have been addressed nor even there was an attempt to address. As I'= ;ve asked to clarify impact of the proposed mechanism, particularly periodic authentication, on the BFD State Machine, I'd point that the = proposed mechanism directly affects BFD security as discussed in RFC 5880 a= nd the section Security Considerations in the document, in my view, does no= t adequately reflects that and doesn't explain how the security of the BFD session maintained when the periodic a= uthentication is in use.

    Regards,
    Greg

    On Wed, Mar 28, 2018 at 7= :38 PM, Jeffrey Haas <jhaas@pfrc.org&= gt; wrote:
    Working Group,

    The authors of the following Working Group drafts have requested
    Working Group Last Call on the following documents:

    https://tools.ietf.org/html/dr<= wbr>aft-ietf-bfd-secure-sequence-numbers-01
    https://tools.ietf.org/html/d= raft-ietf-bfd-optimizing-authentication-04
    https://tools.ietf.org/html/draft-ietf-b= fd-stability-01

    Given the overlap of functionality, WGLC will conclude for the bundle
    simultaneously.

    Authors, please positively acknowledge whether or not you know about any IP= R
    for your documents.=C2=A0 Progression of the document will not be done with= out
    that statement.

    Last call will complete on April 20.

    -- Jeff



    --000000000000f596680568e02ac5-- From nobody Mon Apr 2 13:44:30 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 5037D126C2F for ; Mon, 2 Apr 2018 13:44:28 -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 Bixaab436YQq for ; Mon, 2 Apr 2018 13:44:24 -0700 (PDT) Received: from mail-pl0-x22a.google.com (mail-pl0-x22a.google.com [IPv6:2607:f8b0:400e:c01::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 B6DA312D940 for ; Mon, 2 Apr 2018 13:44:24 -0700 (PDT) Received: by mail-pl0-x22a.google.com with SMTP id g20-v6so5698087plo.9 for ; Mon, 02 Apr 2018 13:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Lm6blA8r6ZExDysWj2Qo3BLpMeRxZEHU6sEj0ezmlVY=; b=n0yF/bYkMUIZjbQjBOlWfyRIaNNpgLQZOqdgVsY67xcqW2erph1Ulza4mS1RTi2WZO xy7FMVNOEh4RJpdVC4Djs89QezJtoPVxlYe8sqPZBICRZq9vptG8pCIoc3UZQ7YPsNgZ mBX+wLtt+hC9TXN7kf5P4HIvPC3jUL7Kf18UwLsdiJkU9mW0k757FTi8bcz7JX3J5Iq0 vVtH6gyfg5MWuK2CvEkD5RZE0DdRLHUiXyEM6RvOh6F/TG+L+MSmGyr0mMjm+/uUtWz7 THqjTWDcuE5Axw338M0kuVz+nVd2GJF1/zfKCh0xaqDNTJPxlsD3AdRs8BL0smT99s+W EZYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Lm6blA8r6ZExDysWj2Qo3BLpMeRxZEHU6sEj0ezmlVY=; b=LB6OpgJCuBQEmvaTCxvVXtKMRxNs9zq4fh+dMjqXqyuOe2AcTZqht16FjuuUG0ImWO PA6NKYhuRTN7wLL+bftcpa6BdoeJF53Oik86B3h5evets6XxYseYMI6FsFK2PvaeOi1v uvcyqqlBP1O2AES9wRjxWLARkf6OXO0NssodEqsrWIflEQxchEexkr3IJ5vt3+FgNfYN 9Ig+W5fPZ665Rm8Osn6y72aUrVUSqtogQjng2+loiH4DfE4vaqwwnaCBrFEguzU2syOg uziYRttsq84OMfvp1OovQbW7tfy9xX+I9rNxdyp76ajlLnD1vxEwQcjKZ2AMz9JX6K5G Qo/Q== X-Gm-Message-State: AElRT7FQi2CmUkdryVftWhLZHcxOyQAW1SuWLnXKOV5FHFTtN5HhC4zF LczvqSruvANASn1hJzVXhZU= X-Google-Smtp-Source: AIpwx48cc30Zi2Tz0OgdVNnIA6GRTB77D8Q+djcYs0Ctm0SytMST3sGVDZavU2JmLeuds1TU0kaqiw== X-Received: by 10.101.68.201 with SMTP id g9mr7252363pgs.263.1522701864155; Mon, 02 Apr 2018 13:44:24 -0700 (PDT) Received: from ?IPv6:2601:647:4700:1280:ccbf:b3ae:4317:7062? ([2601:647:4700:1280:ccbf:b3ae:4317:7062]) by smtp.gmail.com with ESMTPSA id l74sm2252786pfi.138.2018.04.02.13.44.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Apr 2018 13:44:23 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <8424435A-4521-45EA-807C-7D6EC4BF0D29@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1B5EC742-9738-490E-8FB9-1902694D135D" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Tuning BFD session times Date: Mon, 2 Apr 2018 13:45:49 -0700 In-Reply-To: Cc: Ashesh Mishra , "rtg-bfd@ietf.org" To: Greg Mirsky References: <20180328184959.GB25442@pfrc.org> X-Mailer: Apple Mail (2.3445.6.18) 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: Mon, 02 Apr 2018 20:44:28 -0000 --Apple-Mail=_1B5EC742-9738-490E-8FB9-1902694D135D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greg, An ICMP ping run from the control plane may or may not follow the same = path followed by BFD in the data plane. Plus, the processing of an ICMP = ping on most systems is very different from the way BFD is processed. = Plus what better way than to use what you are trying to measure for, = give you the measurement. Cheers. > On Apr 2, 2018, at 9:18 AM, Greg Mirsky wrote: >=20 > Hi Asheh, > thank you for very detailed explanation of the scenarios that had = motivated this work. Couple questions to help me better understand the = use cases: > if understand the first scenario, you propose to use BFD to measure = the propagation delay as it is the main component that influences BFD = interval selection. Do you see that available on-demand tools, e.g. ICMP = ping, not adequate to monitor RTT? What functionality is absent? > For the case #2, the same question as above as I believe that ICMP = ping can be directed over the specific egress interface quite easily. > Regards, > Greg >=20 > On Sun, Apr 1, 2018 at 8:17 PM, Ashesh Mishra = > wrote: > Hi Sasha, >=20 > There are two scenarios here and they depend on whether the satellite = is in geo-stationary orbit (GEO) or non-geo-stationary orbit (NGSO).=20 >=20 > Scenario-1: Non-Geostationary Satellites: This is the scenario that = you described. Satellites in Middle Earth Orbit (MEO) or Low Earth Orbit = (LEO) move relative to the earth and hence, their distance from the = ground terminals varies as they pass over a given location. This results = in varying RTT (sometimes by as much as 30ms). The issue in this = scenario is not necessarily that the BFD detect interval must change = frequently but that it's difficult to accurately select the intervals as = the RTT depends on the location of the terminal and the gateway (and = this gets quite complex). If the session can automatically decide the = interval, then the complexity in starting a new service is reduced. = Another complicating factor is when the terminal moves (ship or = aircraft, for example) as this increases the variance of the RTT. We = typically set the intervals to a high enough level but that affects the = performance. We see the same varying RTT in GEO when the terminal is = mobile but the percentage change is much smaller than the overall RTT of = GEO (because GEO satellites are much farther away from the earth at = ~36,000kms vs MEO at ~8,000kms and LEO at ~200-1000kms).=20 >=20 > Scenario-2: Low-latency link backed up by high-latency link: In this = case a GEO satellite backs up NGSO-based connection or fiber (or other = terrestrial wired/wireless WAN options). The end-to-end service then has = very different RTT when the primary is active versus when the backup is = active. The typical solution is to base timers on the backup RTT, which = is very inefficient.=20 >=20 > Regards, > Ashesh > From: Alexander Vainshtein > > Sent: Sunday, April 1, 2018 9:28:43 AM > To: Ashesh Mishra > Cc: Jeffrey Haas; rtg-bfd@ietf.org > Subject: RE: Tuning BFD session times > =20 > Ashesh, >=20 > I would like to understand better the use case with satellite links = that you have described. >=20 > In particular, can you please explain why long RTT affects the BFD = detection times? >=20 > As I see it, what could really affect these times is variable delay = introduced in some cases by the satellite links since the distance = between the satellite and the terrestrial antennae may change = significantly with time. >=20 > =20 > What did I miss? >=20 >=20 > =20 > Regards, >=20 > Sasha >=20 > =20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com = > =20 > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org = ] On Behalf Of Ashesh Mishra > Sent: Sunday, April 1, 2018 5:54 PM > To: Jeffrey Haas >; = rtg-bfd@ietf.org > Subject: Re: Tuning BFD session times >=20 > =20 > Jeff, thanks for kicking-off this discussion on the list! >=20 > =20 > One additional comment that I wanted to make was around automation. = There were questions during the meeting around the need for auto-tuning = and that the process of determining the interval can/should be manual. >=20 > =20 > The automation of control in all aspects of dynamic behavior is a = priority for network operators. When configuring manually, parameters = such BFD intervals are typically set at very conservative values because = human latency is very high when responding to changing network = conditions. Manual configuration also takes a lot of time and is = accounts for significant number of lost opportunities and value for = operators.=20 >=20 > =20 > [JH] "applications should generally choose a detection interval that = is reasoanble for their application rather than try to dynamically = discover the lowest possible stable detection interval. " >=20 > [AM] This depends on the use-case. =46rom the point-of-view of a = service provider that delivers long-haul connectivity (typical scenario = in which the link characteristics have large variance) then the intent = is to provide the best performance. As such providers deliver = connectivity to critical applications, and are often the only way of = delivering connectivity in such places, the ability to tune the system = to deliver an up-time that is superior drives significant value. = Consider a scenario where there is a 130ms RTT link (MEO satellite, LEO = will be in the 20-60ms range) and its backup is a 600ms RTT link (GEO = satellite), and are being used to deliver transit connectivity. The rate = at which the end-to-end service can run BFD is significantly faster when = MEO is active versus when GEO is active. The application, in this = scenario, may survive the RTT, but the business continuity is critical = in many cases. Since the provider of long-haul can not control the = application, it must provide the best possible failover performance.=20 >=20 > =20 > [JH] "1. BFD is asymmetric.. This means a receiving BFD = implementation must provide feedback to a sending implementation in = order for it to understand perceived reliability." >=20 > [AM] May not need to be the BFD implementation providing the feedback = if there are other performance mechanisms running. The challenge is to = standardize the mechanism that BFD can use (if the measurement is not = self-contained in BFD). You're right in pointing out the challenge in = accounting for the CPU delays and that was the reason for the original = proposal for BFD performance measurement. If the measurement is within = the BFD realm, it will account for the CPU delays. However, most good = BFD engines have relatively deterministic performance and are quite = optimized so the variance with scale and time is not significant (but I = concede that not all BFD implementations are good).=20 >=20 > =20 > [JH] "2. Measurement infrastructure may negatively impact session = scale. Greg, I believe, made this point when discussing host processing = issues vs. BFD ingress/egress." >=20 > [AM] This is an issue if using a measurement mechanism within BFD = (other performance measurement methods are always running in network for = SLA reporting and/or network optimization). Within a metro-area with = fiber or terrestrial wireless (microwave, LTE, etc.) connectivity, I = would likely not need constant auto-tuning. The variance in the primary = and backup links in such network will not be significant to affect the = BFD parameters. In long-haul links, this may be a valuable feature in = which case, the additional overhead may be justified. So it depends on = the use-case whether continuous auto-tuning is required or if it is = one-time.=20 >=20 > =20 > [JH] "3. Detection interval calculations really need to take into = account things that are greater than simple packet transmission times. = As an example, if your measurement is always taken during low system CPU = or network activity, how high is your confidence about the interval? = What about scaling vs. number of total BFD sessions?" >=20 > [AM] Great questions. Typically when running BFD or CFM (or similar) = high frequency OAM, CPU peaks should not affect the OAM performance (a = variety of methods, based on the system on which OAM is running, can = ensure that). CPU peaks become a bigger issue if BFD is used to detect = continuity for a particular flow (or QoS).=20 >=20 > =20 > -- >=20 > Asheh >=20 > From: Rtg-bfd > on behalf of Jeffrey Haas = > >=20 >=20 > Sent: Wednesday, March 28, 2018 11:49 AM > To: rtg-bfd@ietf.org > Subject: Tuning BFD session times >=20 > =20 > Working Group, >=20 > We had very active discussion (yay!) at the microphone as part of = Mahesh's > presentation on BFD Performance Measurement. > (draft-am-bfd-performance) >=20 > I wanted to start this thread to discuss the greater underlying issues = this > discussion raised. In particular, active tuning of BFD session = parameters. > Please note that opinions I state here are as an individual = contributor. >=20 > BFD clients typically want the fastest, most stable detection interval = that > is appropriate to their application. That stability component is very > important since too aggressive of timers can result in unnecessary BFD > session instability which will impact the subscribing application. = Such > stability is a function of many things, scale of the system running = BFD > being a major one. >=20 > In my opinion, applications should generally choose a detection = interval > that is reasoanble for their application rather than try to = dynamically > discover the lowest possible stable detection interval. This is = because a > number of unstable factors, such as CPU load, contention with other = network > traffic and other things that are outside the general control of many > sytems may impact such scale. >=20 > That said, here's a few thoughts on active feedback mechanisms: > 1. BFD is asymmetric. This means a receiving BFD implementation must = provide > feedback to a sending implementation in order for it to understand > perceived reliability. > 2. Measurement infrastructure may negatively impact session scale. = Greg, I > believe, made this point when discussing host processing issues vs. = BFD > ingress/egress. > 3. Detection interval calculations really need to take into account = things > that are greater than simple packet transmission times. As an = example, > if your measurement is always taken during low system CPU or = network > activity, how high is your confidence about the interval? What = about > scaling vs. number of total BFD sessions? >=20 > I have no strong conclusions here, just some cautionary thoughts. >=20 > What are yours? >=20 > -- Jeff >=20 >=20 > = __________________________________________________________________________= _ >=20 > This e-mail message is intended for the recipient only and contains = information which is=20 > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have = received this=20 > transmission in error, please inform us by e-mail, phone or fax, and = then delete the original=20 > and all copies thereof. > = __________________________________________________________________________= _ >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_1B5EC742-9738-490E-8FB9-1902694D135D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Greg,

    An = ICMP ping run from the control plane may or may not follow the same path = followed by BFD in the data plane. Plus, the processing of an ICMP ping = on most systems is very different from the way BFD is processed. Plus = what better way than to use what you are trying to measure for, give you = the measurement.

    Cheers.

    On Apr 2, 2018, at 9:18 AM, = Greg Mirsky <gregimirsky@gmail.com> wrote:

    Hi Asheh,
    thank you for very detailed = explanation of the scenarios that had motivated this work. Couple = questions to help me better understand the use cases:
    • if understand the first = scenario, you propose to use BFD to measure the propagation delay as it = is the main component that influences BFD interval selection. Do you see = that available on-demand tools, e.g. ICMP ping, not adequate to monitor = RTT? What functionality is absent?
    • For the case #2, = the same question as above as I believe that ICMP ping can be directed = over the specific egress interface quite easily.
    Regards,
    Greg

    On Sun, = Apr 1, 2018 at 8:17 PM, Ashesh Mishra <mishra.ashesh@outlook.com> wrote:
    Hi Sasha,

    There= are two scenarios here and they depend on whether the satellite is = in geo-stationary orbit (GEO) or non-geo-stationary orbit = (NGSO). 

    Scenario-1: Non-Geostationary Satellites: This is the = scenario that you described. Satellites in Middle Earth Orbit (MEO) = or Low Earth Orbit (LEO) move relative to the earth and hence, their = distance from the ground terminals varies as they pass over a given location. This results in varying RTT = (sometimes by as much as 30ms). The issue in this scenario is not = necessarily that the BFD detect interval must change frequently but = that it's difficult to accurately select the intervals as the RTT depends on the location of the terminal and the gateway (and = this gets quite complex). If the session can automatically decide the = interval, then the complexity in starting a new service is reduced. = Another complicating factor is when the terminal moves (ship or aircraft, for example) as this increases the variance of = the RTT. We typically set the intervals to a high enough level but that = affects the performance. We see the same varying RTT in GEO when the = terminal is mobile but the percentage change is much smaller than the overall RTT of GEO (because GEO satellites are much = farther away from the earth at ~36,000kms vs MEO at ~8,000kms and LEO at = ~200-1000kms). 

    Scenario-2: Low-latency link backed up by high-latency link: = In this case a GEO satellite backs up NGSO-based connection or fiber (or = other terrestrial wired/wireless WAN options). The end-to-end service = then has very different RTT when the primary is active versus when the backup is = active. The typical solution is to base timers on the backup RTT, which = is very inefficient. 

    Regards,
    Ashesh
    From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
    Sent: Sunday, April 1, 2018 9:28:43 AM
    To: Ashesh Mishra
    Cc: Jeffrey Haas; rtg-bfd@ietf.org
    Subject: RE: Tuning BFD session times
     

    Ashesh,

    I would like to understand better the use case with = satellite links that you have described.

    In particular, can you please explain why long RTT = affects the BFD detection times?

    As I see it, what could really affect these times = is variable delay introduced in some cases by the satellite links since = the distance between the satellite and the terrestrial antennae may change significantly with time. =

     

    What did I miss?


     

    Regards,

    Sasha

     

    Office: +972-39266302

    Cell:      +972-549266302

    Email:   Alexander.Vainshtein@ecitele.com

    =
     

    From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org]= On Behalf Of Ashesh Mishra
    Sent: Sunday, April 1, 2018 5:54 PM
    To: Jeffrey Haas <jhaas@pfrc.org>; rtg-bfd@ietf.org
    Subject: Re: Tuning BFD session times

     

    Jeff, thanks for kicking-off this discussion on the = list!

     

    One additional = comment that I wanted to make was around automation. There were = questions during the meeting around the need for auto-tuning and that = the process of determining the interval can/should be manual.

     

    The automation of = control in all aspects of dynamic behavior is a priority for network = operators. When configuring manually, parameters such BFD intervals are = typically set at very conservative values because human latency is very high when responding to changing = network conditions. Manual configuration also takes a lot of time and is = accounts for significant number of lost opportunities and value for = operators. 

     

    [JH] "applications should generally choose a detection = interval that is reasoanble for their application rather than try to dynamically discover the lowest possible = stable detection interval. "

    [AM] This depends on the use-case. =46rom the = point-of-view of a service provider that delivers long-haul connectivity = (typical scenario in which the link characteristics have large variance) = then the intent is to provide the best performance. As such providers = deliver connectivity to critical applications, and are often the only = way of delivering connectivity in such places, the ability to tune the = system to deliver an up-time that is superior drives significant value. Consider a scenario where there is a 130ms RTT link = (MEO satellite, LEO will be in the 20-60ms range) and its backup is a = 600ms RTT link (GEO satellite), and are being used to deliver transit = connectivity. The rate at which the end-to-end service can run BFD is significantly faster when MEO is active versus = when GEO is active. The application, in this scenario, may survive the = RTT, but the business continuity is critical in many cases. Since the = provider of long-haul can not control the application, it must provide the best possible failover = performance. 

     

    [JH] "1. BFD is = asymmetric..  This means a receiving BFD implementation must = provide feedback to a sending implementation in order for it to = understand perceived reliability."

    [AM] May not need to be the BFD implementation = providing the feedback if there are other performance mechanisms = running. The challenge is to standardize the mechanism that BFD can use = (if the measurement is not self-contained in BFD). You're right in pointing out the = challenge in accounting for the CPU delays and that was the reason for = the original proposal for BFD performance measurement. If the = measurement is within the BFD realm, it will account for the CPU delays. However, most good BFD engines have relatively = deterministic performance and are quite optimized so the variance with = scale and time is not significant (but I concede that not all BFD = implementations are good). 

     

    [JH] "2. Measurement = infrastructure may negatively impact session scale.  Greg, = I believe, made this point when discussing host processing issues = vs. BFD ingress/egress."

    [AM] This is an issue if using a measurement = mechanism within BFD (other performance measurement methods are always = running in network for SLA reporting and/or network optimization). = Within a metro-area with fiber or terrestrial wireless (microwave, LTE, etc.) connectivity, = I would likely not need constant auto-tuning. The variance in the = primary and backup links in such network will not be significant to = affect the BFD parameters. In long-haul links, this may be a valuable feature in which case, the additional overhead may be = justified. So it depends on the use-case whether continuous auto-tuning = is required or if it is one-time. 

     

    [JH] "3. Detection = interval calculations really need to take into account things that = are greater than simple packet transmission times.  As an = example, if your measurement is always taken during low system CPU or network activity, how = high is your confidence about the interval?  What = about scaling vs. number of total BFD sessions?"

    [AM] Great = questions. Typically when running BFD or CFM (or similar) high = frequency OAM, CPU peaks should not affect the OAM performance (a = variety of methods, based on the system on which OAM is running, can ensure that). CPU peaks become a = bigger issue if BFD is used to detect continuity for a particular flow = (or QoS). 

     

    --

    Asheh

    From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Jeffrey Haas <jhaas@pfrc..org>


    Sent: Wednesday, March 28, 2018 11:49 AM
    To: rtg-bfd@ietf.org
    Subject: Tuning BFD session times

     

    Working Group,

    We had very active discussion (yay!) at the microphone as part of = Mahesh's
    presentation on BFD Performance Measurement.
    (draft-am-bfd-performance)

    I wanted to start this thread to discuss the greater underlying issues = this
    discussion raised.  In particular, active tuning of BFD session = parameters.
    Please note that opinions I state here are as an individual = contributor.

    BFD clients typically want the fastest, most stable detection interval = that
    is appropriate to their application.  That stability component is = very
    important since too aggressive of timers can result in unnecessary = BFD
    session instability which will impact the subscribing application.  = Such
    stability is a function of many things, scale of the system running = BFD
    being a major one.

    In my opinion, applications should generally choose a detection = interval
    that is reasoanble for their application rather than try to = dynamically
    discover the lowest possible stable detection interval.  This is = because a
    number of unstable factors, such as CPU load, contention with other = network
    traffic and other things that are outside the general control of many
    sytems may impact such scale.

    That said, here's a few thoughts on active feedback mechanisms:
    1. BFD is asymmetric.  This means a receiving BFD implementation = must provide
       feedback to a sending implementation in order for it to = understand
       perceived reliability.
    2. Measurement infrastructure may negatively impact session scale.  = Greg, I
       believe, made this point when discussing host processing = issues vs. BFD
       ingress/egress.
    3. Detection interval calculations really need to take into account = things
       that are greater than simple packet transmission = times.  As an example,
       if your measurement is always taken during low system CPU = or network
       activity, how high is your confidence about the = interval?  What about
       scaling vs. number of total BFD sessions?

    I have no strong conclusions here, just some cautionary thoughts.

    What are yours?

    -- Jeff


    ___________________________________________________________________________

    This e-mail message is intended for the recipient only and contains = information which is
    CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have = received this
    transmission in error, please inform us by e-mail, phone or fax, and = then delete the original
    and all copies thereof.
    ___________________________________________________________________________


    Mahesh Jethanandani
    mjethanandani@gmail.com

    = --Apple-Mail=_1B5EC742-9738-490E-8FB9-1902694D135D-- From nobody Mon Apr 2 22:28:06 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 88C09127775 for ; Mon, 2 Apr 2018 22:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 RXJJexW5fPxO for ; Mon, 2 Apr 2018 22:28:01 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (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 AEE8D126579 for ; Mon, 2 Apr 2018 22:28:00 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id u11so16834192wri.12 for ; Mon, 02 Apr 2018 22:28: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 :cc; bh=jo2Q9kvstBhULc8yR0W/pJQrwPE7TJf4JMqi4VvLTpc=; b=XUI/kzJNnj5NVa8qC2lA+4qbkGgIiV9yiZIcWGXvPdgEDX8HixQqOWTj6IY+FA5Cvw 5ud8LgrRdk+dpPNbOk/L3pInYYv+Zw9YbY9njqcdPNuqDg+Rh422C7Yj3vlEpEyWJDYO EhxncXKfXowhsBsLbysYjxbA7XDA10eCmxl0EodbSrvTws5P4+jzKNHb9IYHd9CvU3sg wx5LuV9TTJNKPpwBQvHD61/4P0pEoKniuDeadJL6MZ4/UzUhtqYSpYfp07L6a2tthTzc 4oneI2Y3G1zQyV/KjgoV3KJmyPv4zbwU0/Gvlr6gwY0Z7UGCD5ffNlnZjRJAbGDv32H9 Tadg== 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=jo2Q9kvstBhULc8yR0W/pJQrwPE7TJf4JMqi4VvLTpc=; b=Li8S9FIxTycwwUsppPB94Zo7mDW71PyoxET2lf8ecvspupZptHo8LOc7Abnby1OwNY nB/DN9Lmjz8ePz6scwjM0jZts/kO+kcjReORJumStyP8fA9NBMSSLnIuDPGy/MYD3brc 6lW+zfvi3mje7NC9YRLal+47J1ewxMhboW+R1gB9Zl0DPZSGSs/2HNHia5uq0IQ/+fyt FnJg0eXC7RmuuL9rBBdogs+0KAE9tekWt1CelwwCXMASHFLLRgl+yo4fG9Tzf+xiZczF ob71qZLpl5MCAja5QKcIkQV6NOkg7f8f8WHWBssM2DYrJFiJk7QdhRN82Kl1gQlYXlWS YQmA== X-Gm-Message-State: ALQs6tAqh/Wg/Vs7eysBVIayYvhPEDobCVhDK9uLbILrjuTio63WtvY9 aWQZ8vvx8SEeiEGB+nQGH+rAbuWPSRNyciSf7USJ25Nq X-Google-Smtp-Source: AIpwx4+ZBd+ICDj44Et3kZHiGHk1Yp13hHspOeHtrQY4eg6naWU1GRFke07Lnds+W9VEbT1c0qWJ+i5IyV9+XTiCcPc= X-Received: by 2002:a19:179b:: with SMTP id 27-v6mr7010354lfx.143.1522733278902; Mon, 02 Apr 2018 22:27:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.73.66 with HTTP; Mon, 2 Apr 2018 22:27:58 -0700 (PDT) In-Reply-To: <8424435A-4521-45EA-807C-7D6EC4BF0D29@gmail.com> References: <20180328184959.GB25442@pfrc.org> <8424435A-4521-45EA-807C-7D6EC4BF0D29@gmail.com> From: Greg Mirsky Date: Mon, 2 Apr 2018 22:27:58 -0700 Message-ID: Subject: Re: Tuning BFD session times To: Mahesh Jethanandani Cc: Ashesh Mishra , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002d3fed0568eaf861" 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: Tue, 03 Apr 2018 05:28:05 -0000 --0000000000002d3fed0568eaf861 Content-Type: text/plain; charset="UTF-8" Hi Mahesh, thank you for additional information to help understand the use case. Please consider my follow-up notes in-lined and tagged GIM>>. Regards, Greg On Mon, Apr 2, 2018 at 1:45 PM, Mahesh Jethanandani wrote: > Greg, > > An ICMP ping run from the control plane may or may not follow the same > path followed by BFD in the data plane. > GIM>> Does that mean that this is case is not only for single-hop BFD but includes scenarios with multi-hop BFD? > Plus, the processing of an ICMP ping on most systems is very different > from the way BFD is processed. > GIM>> I think that is very important to specify where in the processing sequence timestamp values being taken. For example, in case of DM in CFM, it is suggested to take egress timestamp (T1 nd T3) when the first octet of the frame being transmitted. Similarly, the ingress timestamp (T2 and T2) - when the first octet of the frame being received. The goal this recommendation is to exclude queuing delays and jitter that are introduced by the MEPs to measure, as consistently as possible, latency and jitter of the path. Hence the question, When timestamps to be taken for draft-am-bfd-performance? > Plus what better way than to use what you are trying to measure for, give > you the measurement. > GIM>> I think that approach to add time measurement to each and every protocol that may need to characterize its performance and/or tune interval of periodic message would not be advisable. I believe that active measurement methods allow reasonably accurate measurements that can be properly interpreted based on representative statistics of test sessions. Alternatively, hybrid measurement methods, e.g. Alternate Marking, may be used. > > Cheers. > > > On Apr 2, 2018, at 9:18 AM, Greg Mirsky wrote: > > Hi Asheh, > thank you for very detailed explanation of the scenarios that had > motivated this work. Couple questions to help me better understand the use > cases: > > - if understand the first scenario, you propose to use BFD to measure > the propagation delay as it is the main component that influences BFD > interval selection. Do you see that available on-demand tools, e.g. ICMP > ping, not adequate to monitor RTT? What functionality is absent? > - For the case #2, the same question as above as I believe that ICMP > ping can be directed over the specific egress interface quite easily. > > Regards, > Greg > > On Sun, Apr 1, 2018 at 8:17 PM, Ashesh Mishra > wrote: > >> Hi Sasha, >> >> There are two scenarios here and they depend on whether the satellite is >> in geo-stationary orbit (GEO) or non-geo-stationary orbit (NGSO). >> >> Scenario-1: Non-Geostationary Satellites: This is the scenario that you >> described. Satellites in Middle Earth Orbit (MEO) or Low Earth Orbit (LEO) >> move relative to the earth and hence, their distance from the ground >> terminals varies as they pass over a given location. This results in >> varying RTT (sometimes by as much as 30ms). The issue in this scenario is >> not necessarily that the BFD detect interval must change frequently but >> that it's difficult to accurately select the intervals as the RTT depends >> on the location of the terminal and the gateway (and this gets quite >> complex). If the session can automatically decide the interval, then the >> complexity in starting a new service is reduced. Another complicating >> factor is when the terminal moves (ship or aircraft, for example) as this >> increases the variance of the RTT. We typically set the intervals to a high >> enough level but that affects the performance. We see the same varying RTT >> in GEO when the terminal is mobile but the percentage change is much >> smaller than the overall RTT of GEO (because GEO satellites are much >> farther away from the earth at ~36,000kms vs MEO at ~8,000kms and LEO at >> ~200-1000kms). >> >> Scenario-2: Low-latency link backed up by high-latency link: In this case >> a GEO satellite backs up NGSO-based connection or fiber (or other >> terrestrial wired/wireless WAN options). The end-to-end service then has >> very different RTT when the primary is active versus when the backup is >> active. The typical solution is to base timers on the backup RTT, which is >> very inefficient. >> >> Regards, >> Ashesh >> ------------------------------ >> *From:* Alexander Vainshtein >> *Sent:* Sunday, April 1, 2018 9:28:43 AM >> *To:* Ashesh Mishra >> *Cc:* Jeffrey Haas; rtg-bfd@ietf.org >> *Subject:* RE: Tuning BFD session times >> >> >> Ashesh, >> >> I would like to understand better the use case with satellite links that >> you have described. >> >> In particular, can you please explain why long RTT affects the BFD >> detection times? >> >> As I see it, what could really affect these times is variable delay >> introduced in some cases by the satellite links since the distance between >> the satellite and the terrestrial antennae may change significantly with >> time. >> >> >> What did I miss? >> >> >> >> Regards, >> >> Sasha >> >> >> Office: +972-39266302 <+972%203-926-6302> >> >> Cell: +972-549266302 <+972%2054-926-6302> >> >> Email: Alexander.Vainshtein@ecitele.com >> >> >> *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] *On Behalf Of *Ashesh >> Mishra >> *Sent:* Sunday, April 1, 2018 5:54 PM >> *To:* Jeffrey Haas ; rtg-bfd@ietf.org >> *Subject:* Re: Tuning BFD session times >> >> >> Jeff, thanks for kicking-off this discussion on the list! >> >> >> One additional comment that I wanted to make was around automation. There >> were questions during the meeting around the need for auto-tuning and that >> the process of determining the interval can/should be manual. >> >> >> The automation of control in all aspects of dynamic behavior is a >> priority for network operators. When configuring manually, parameters such >> BFD intervals are typically set at very conservative values because human >> latency is very high when responding to changing network conditions. Manual >> configuration also takes a lot of time and is accounts for significant >> number of lost opportunities and value for operators. >> >> >> *[JH] "**applications should generally choose a detection interval that >> is reasoanble for their application rather than try to dynamically discover >> the lowest possible stable detection interval. **"* >> >> [AM] This depends on the use-case. From the point-of-view of a service >> provider that delivers long-haul connectivity (typical scenario in which >> the link characteristics have large variance) then the intent is to provide >> the best performance. As such providers deliver connectivity to critical >> applications, and are often the only way of delivering connectivity in such >> places, the ability to tune the system to deliver an up-time that is >> superior drives significant value. Consider a scenario where there is a >> 130ms RTT link (MEO satellite, LEO will be in the 20-60ms range) and its >> backup is a 600ms RTT link (GEO satellite), and are being used to deliver >> transit connectivity. The rate at which the end-to-end service can run BFD >> is significantly faster when MEO is active versus when GEO is active. The >> application, in this scenario, may survive the RTT, but the business >> continuity is critical in many cases. Since the provider of long-haul can >> not control the application, it must provide the best possible failover >> performance. >> >> >> *[JH] "1. BFD is asymmetric.. This means a receiving BFD implementation >> must provide feedback to a sending implementation in order for it to >> understand perceived reliability."* >> >> [AM] May not need to be the BFD implementation providing the feedback if >> there are other performance mechanisms running. The challenge is to >> standardize the mechanism that BFD can use (if the measurement is not >> self-contained in BFD). You're right in pointing out the challenge in >> accounting for the CPU delays and that was the reason for the original >> proposal for BFD performance measurement. If the measurement is within the >> BFD realm, it will account for the CPU delays. However, most good BFD >> engines have relatively deterministic performance and are quite optimized >> so the variance with scale and time is not significant (but I concede that >> not all BFD implementations are good). >> >> >> *[JH] "2. Measurement infrastructure may negatively impact session >> scale. Greg, I believe, made this point when discussing host processing >> issues vs. BFD ingress/egress."* >> >> [AM] This is an issue if using a measurement mechanism within BFD (other >> performance measurement methods are always running in network for SLA >> reporting and/or network optimization). Within a metro-area with fiber or >> terrestrial wireless (microwave, LTE, etc.) connectivity, I would likely >> not need constant auto-tuning. The variance in the primary and backup links >> in such network will not be significant to affect the BFD parameters. In >> long-haul links, this may be a valuable feature in which case, the >> additional overhead may be justified. So it depends on the use-case whether >> continuous auto-tuning is required or if it is one-time. >> >> >> *[JH] "3. Detection interval calculations really need to take into >> account things that are greater than simple packet transmission times. As >> an example, if your measurement is always taken during low system CPU or >> network activity, how high is your confidence about the interval? What >> about scaling vs. number of total BFD sessions?"* >> >> [AM] Great questions. Typically when running BFD or CFM (or similar) high >> frequency OAM, CPU peaks should not affect the OAM performance (a variety >> of methods, based on the system on which OAM is running, can ensure that). >> CPU peaks become a bigger issue if BFD is used to detect continuity for a >> particular flow (or QoS). >> >> >> -- >> >> Asheh >> ------------------------------ >> >> *From:* Rtg-bfd on behalf of Jeffrey Haas < >> jhaas@pfrc..org > >> >> *Sent:* Wednesday, March 28, 2018 11:49 AM >> *To:* rtg-bfd@ietf.org >> *Subject:* Tuning BFD session times >> >> >> >> Working Group, >> >> We had very active discussion (yay!) at the microphone as part of Mahesh's >> presentation on BFD Performance Measurement. >> (draft-am-bfd-performance) >> >> I wanted to start this thread to discuss the greater underlying issues >> this >> discussion raised. In particular, active tuning of BFD session >> parameters. >> Please note that opinions I state here are as an individual contributor. >> >> BFD clients typically want the fastest, most stable detection interval >> that >> is appropriate to their application. That stability component is very >> important since too aggressive of timers can result in unnecessary BFD >> session instability which will impact the subscribing application. Such >> stability is a function of many things, scale of the system running BFD >> being a major one. >> >> In my opinion, applications should generally choose a detection interval >> that is reasoanble for their application rather than try to dynamically >> discover the lowest possible stable detection interval. This is because a >> number of unstable factors, such as CPU load, contention with other >> network >> traffic and other things that are outside the general control of many >> sytems may impact such scale. >> >> That said, here's a few thoughts on active feedback mechanisms: >> 1. BFD is asymmetric. This means a receiving BFD implementation must >> provide >> feedback to a sending implementation in order for it to understand >> perceived reliability. >> 2. Measurement infrastructure may negatively impact session scale. Greg, >> I >> believe, made this point when discussing host processing issues vs. BFD >> ingress/egress. >> 3. Detection interval calculations really need to take into account things >> that are greater than simple packet transmission times. As an example, >> if your measurement is always taken during low system CPU or network >> activity, how high is your confidence about the interval? What about >> scaling vs. number of total BFD sessions? >> >> I have no strong conclusions here, just some cautionary thoughts. >> >> What are yours? >> >> -- Jeff >> >> ____________________________________________________________ >> _______________ >> >> This e-mail message is intended for the recipient only and contains >> information which is >> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have >> received this >> transmission in error, please inform us by e-mail, phone or fax, and then >> delete the original >> and all copies thereof. >> ____________________________________________________________ >> _______________ >> > > > Mahesh Jethanandani > mjethanandani@gmail.com > > --0000000000002d3fed0568eaf861 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Mahesh,
    thank you for additional information to hel= p understand the use case. Please consider my follow-up notes in-lined and = tagged GIM>>.

    Regards,
    Greg
    <= div class=3D"gmail_extra">
    On Mon, Apr 2, 201= 8 at 1:45 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
    Greg,

    An ICMP ping = run from the control plane may or may not follow the same path followed by = BFD in the data plane.
    GIM>> Does that = mean that this is case is not only for single-hop BFD but includes scenario= s with multi-hop BFD?=C2=A0
    Plus, the proce= ssing of an ICMP ping on most systems is very different from the way BFD is= processed.
    GIM>> I think that is very i= mportant to specify where in the processing sequence timestamp values being= taken. For example, in case of DM in CFM, it is suggested to take egress t= imestamp (T1 nd T3) when the first octet of the frame being transmitted. Si= milarly, the ingress timestamp (T2 and T2) - when the first octet of the fr= ame being received. The goal this recommendation is to exclude queuing dela= ys and jitter that are introduced by the MEPs to measure, as consistently a= s possible, latency and jitter of the path. Hence the question, When timest= amps to be taken for=C2=A0 draft-am-bfd-performance?
    Plus what better way than to use what you are trying to me= asure for, give you the measurement.
    GIM>&g= t; I think that approach to add time measurement to each and every protocol= that may need to characterize its performance and/or tune interval of peri= odic message would not be advisable. I believe that active measurement meth= ods allow reasonably accurate measurements that can be properly interpreted= based on=C2=A0 representative statistics of test sessions. Alternatively, = hybrid measurement methods, e.g. Alternate Marking, may be used.=C2=A0

    Cheers.

    On Apr 2, 2018, at 9:18 AM, Greg M= irsky <gregim= irsky@gmail.com> wrote:

    Hi Asheh,
    thank you for ver= y detailed explanation of the scenarios that had motivated this work. Coupl= e questions to help me better understand the use cases:
    • i= f understand the first scenario, you propose to use BFD to measure the prop= agation delay as it is the main component that influences BFD interval sele= ction. Do you see that available on-demand tools, e.g. ICMP ping, not adequ= ate to monitor RTT? What functionality is absent?
    • For the case #2, = the same question as above as I believe that ICMP ping can be directed over= the specific egress interface quite easily.
    Regards,
    Greg

    On Sun, Apr 1, 2018 at 8:17 PM, Ashesh Mishra <= ;mishra.ashe= sh@outlook.com> wrote:
    Hi Sasha,

    There are two scenari= os here and they depend on whether the satellite is in=C2=A0geo-stationary = orbit (GEO) or non-geo-stationary orbit (NGSO).=C2=A0

    Scenario-1: Non-Geost= ationary Satellites: This is the scenario that you described.=C2=A0Satellit= es in Middle Earth Orbit (MEO) or Low Earth Orbit (LEO) move relative to th= e earth and hence, their distance from the ground terminals varies as they pass over a given location. This results in varying RTT (so= metimes by as much as 30ms). The issue in this scenario is not necessarily = that the BFD=C2=A0detect interval must change frequently but that it's = difficult to accurately select the intervals as the RTT depends on the location of the terminal and the gateway (and th= is gets quite complex). If the session can automatically decide the interva= l, then the complexity in starting a new service is reduced. Another compli= cating factor is when the terminal=C2=A0moves (ship or aircraft, for example) as this increases the variance=C2=A0of the= RTT. We typically set the intervals to a high enough level but that affect= s the performance. We see the same varying RTT in GEO when the terminal is = mobile but the percentage change is much smaller than the overall RTT of GEO (because GEO satellites are much farth= er away from the earth at ~36,000kms vs MEO at ~8,000kms and LEO at ~200-10= 00kms).=C2=A0

    Scenario-2: Low-laten= cy link backed up by high-latency link: In this case a GEO satellite backs = up NGSO-based connection or fiber (or other terrestrial wired/wireless WAN = options). The end-to-end service then has very different RTT when the primary is active versus when the backup is active.= The typical solution is to base timers on the backup RTT, which is very in= efficient.=C2=A0

    Regards,
    Ashesh
    From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
    Sent: Sunday, April 1, 2018 9:28:43 AM
    To: Ashesh Mishra
    Cc: Jeffrey Haas; rtg-bfd@ietf.org
    Subject: RE: Tuning BFD session times
    =C2=A0

    Ashesh,

    I would like to understand better the us= e case with satellite links that you have described.

    In particular, can you please explain why long RTT affect= s the BFD detection times?

    As I see it, what could really affect these times is vari= able delay introduced in some cases by the satellite links since the distan= ce between the satellite and the terrestrial antennae may change significantly with time.

    =C2=A0

    What did I miss?


    =C2=A0

    Regards,

    Sasha

    = =C2=A0

    Office: +972-39266302

    Cell:=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 +972-549266302

    Email:=C2=A0=C2=A0 Alexand= er.Vainshtein@ecitele.com

    =C2=A0

    From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Ashesh Mishra
    Sent: Sunday, April 1, 2018 5:54 PM
    To: Jeffrey Haas <jhaas@pfrc.org>; rtg-bfd@ietf.org
    Subject: Re: Tuning BFD session times

    =C2=A0

    Jeff, thanks for kickin= g-off this discussion on the list!

    =C2=A0

    One additional comment that I wanted to make was around automation.=C2=A0T= here were questions during the meeting around the need for auto-tuning and = that the process of determining the interval can/should be manual.

    = =C2=A0

    The automation of con= trol in all aspects of dynamic behavior is a priority for network operators= . When configuring manually, parameters such BFD intervals are typically se= t at very conservative values because human latency is very high when responding to changing netw= ork conditions. Manual configuration also takes a lot of time and is accoun= ts for significant number of lost opportunities and value for operators.=C2= =A0

    =C2=A0

    [JH]=C2=A0"<= /span>= applications should generally choose a detection interval=C2=A0that is reas= oanble for their application rather than try to=C2=A0dynamically=C2=A0discover the lowest possible stab= le detection interval.=C2=A0"

    [AM] This depends on= the use-case. From the point-of-view of a service provider that delivers l= ong-haul connectivity (typical scenario in which the link characteristics h= ave large variance) then the intent is to provide the best performance. As such providers deliver c= onnectivity to critical applications, and are often the only way of deliver= ing connectivity in such places, the ability to tune the system to deliver = an up-time that is superior drives significant value. Consider a scenario where there is a 130ms RTT link (ME= O satellite, LEO will be in the 20-60ms range) and its backup is a 600ms RT= T link (GEO satellite), and are being used to deliver transit connectivity.= The rate at which the end-to-end service can run BFD is significantly faster when MEO is active versus when= GEO is active. The application, in this scenario, may survive the RTT, but= the business continuity is critical in many cases. Since the provider of l= ong-haul can not control the application, it must provide the best possible failover performance.=C2=A0

    =C2=A0

    [J= H] "1. BFD is asymmetric..=C2=A0 This means a receiving BFD implementa= tion must provide=C2=A0feedback to a sending implementation in order for it= to understand=C2=A0perceived reliability."

    [AM] May not need to= be the BFD implementation providing the feedback if there are other perfor= mance mechanisms running. The challenge is to standardize the mechanism tha= t BFD can use (if the measurement is not self-contained in BFD). You're right in pointing out the challe= nge in accounting for the CPU delays and that was the reason for the origin= al proposal for BFD performance measurement. If the measurement is within t= he BFD realm, it will account for the CPU delays. However, most good BFD engines have relatively deterministic p= erformance and are quite optimized so the variance with scale and time is n= ot significant (but I concede that not all BFD implementations are good).= =C2=A0

    =C2=A0=

    [J= H] "2. Measurement infrastructure may negatively impact session scale.= =C2=A0 Greg, I=C2=A0believe, made this point when discussing host processin= g issues vs. BFD=C2=A0ingress/egress."

    [AM] This is an issu= e if using a measurement mechanism within BFD (other performance measuremen= t methods are always running in network for SLA reporting and/or=C2=A0netwo= rk optimization). Within a metro-area with fiber or terrestrial wireless (microwave, LTE, etc.) connectivity, I = would likely not need constant auto-tuning. The variance in the primary and= backup links in such network will not be significant to affect the BFD par= ameters. In long-haul links, this may be a valuable feature in which case, the additional overhead may be ju= stified. So it depends on the use-case whether continuous auto-tuning is re= quired or if it is one-time.=C2=A0

    =C2=A0

    [J= H] "3. Detection interval calculations really need to take into accoun= t things=C2=A0that are greater than simple packet transmission times.=C2=A0= As an example,=C2=A0if your measurement is always taken during low system CPU or network=C2=A0activity, how high i= s your confidence about the interval?=C2=A0 What about=C2=A0scaling vs. num= ber of total BFD sessions?"

    [AM] Great questions. Typically= when running=C2=A0BFD or CFM (or similar) high frequency OAM, CPU peaks sh= ould not affect the OAM performance (a variety of methods, based on the sys= tem on which OAM is running,=C2=A0can ensure that). CPU peaks become a bigger = issue if BFD is used to detect continuity for a particular flow (or QoS).= =C2=A0

    =C2=A0

    --

    Asheh

    From: Rtg-bfd <rtg-bfd-bounces@ietf= .org> on behalf of Jeffrey Haas <jhaas@pfrc..org>


    Sent: Wednesday, March 28, 2018 11:49 AM
    To: rtg-bfd@ie= tf.org
    Subject: Tuning BFD session times

    =C2=A0

    Working Group,

    We had very active discussion (yay!) at the microphone as part of Mahesh= 9;s
    presentation on BFD Performance Measurement.
    (draft-am-bfd-performance)

    I wanted to start this thread to discuss the greater underlying issues this=
    discussion raised.=C2=A0 In particular, active tuning of BFD session parame= ters.
    Please note that opinions I state here are as an individual contributor.
    BFD clients typically want the fastest, most stable detection interval that=
    is appropriate to their application.=C2=A0 That stability component is very=
    important since too aggressive of timers can result in unnecessary BFD
    session instability which will impact the subscribing application.=C2=A0 Su= ch
    stability is a function of many things, scale of the system running BFD
    being a major one.

    In my opinion, applications should generally choose a detection interval that is reasoanble for their application rather than try to dynamically
    discover the lowest possible stable detection interval.=C2=A0 This is becau= se a
    number of unstable factors, such as CPU load, contention with other network=
    traffic and other things that are outside the general control of many
    sytems may impact such scale.

    That said, here's a few thoughts on active feedback mechanisms:
    1. BFD is asymmetric.=C2=A0 This means a receiving BFD implementation must = provide
    =C2=A0=C2=A0 feedback to a sending implementation in order for it to unders= tand
    =C2=A0=C2=A0 perceived reliability.
    2. Measurement infrastructure may negatively impact session scale.=C2=A0 Gr= eg, I
    =C2=A0=C2=A0 believe, made this point when discussing host processing issue= s vs. BFD
    =C2=A0=C2=A0 ingress/egress.
    3. Detection interval calculations really need to take into account things<= br> =C2=A0=C2=A0 that are greater than simple packet transmission times.=C2=A0 = As an example,
    =C2=A0=C2=A0 if your measurement is always taken during low system CPU or n= etwork
    =C2=A0=C2=A0 activity, how high is your confidence about the interval?=C2= =A0 What about
    =C2=A0=C2=A0 scaling vs. number of total BFD sessions?

    I have no strong conclusions here, just some cautionary thoughts.

    What are yours?

    -- Jeff


    _________________________________________________________________= __________

    This e-mail message is intended for the recipient only and contains informa= tion which is
    CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have recei= ved this
    transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original
    and all copies thereof.
    _________________________________________________________________= __________


    Mahesh Jethanandani


    --0000000000002d3fed0568eaf861-- From nobody Tue Apr 3 17:35: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 7C74D1252BA for ; Tue, 3 Apr 2018 17:35:50 -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 exAkUp0TnQEd for ; Tue, 3 Apr 2018 17:35:47 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 B207912420B for ; Tue, 3 Apr 2018 17:35:46 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id x70-v6so15944131lfa.0 for ; Tue, 03 Apr 2018 17:35:46 -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=pJM7FgycHiZqoGN5XawP4WFODSB9bVBDRrQHj6fl+Ds=; b=Zu3vWV+i0dRW4A3BLRA3shURkS6bSn+5vXMhUC8djt/KTS8Ilq87YlJTJde/4RHNm4 owlTewT87PqtJ6Yt4SR546N3vbffkShJBYE5OWYRxAOWuxX/FtiIwGNj3v5DvVnzB4P3 x+kCJLCL//eb1gTRDAIIqHAoMgOwYCrXT3crAr/f0rgIJaY0iXOd1GY+Bcj24CgeKl9g mnq+0qKXy9w9hdAM2/Fov81vGshpFoogt76ajVoLD9HsP5GXvige3sf4EERYg6WjjN6n 3/XdYALa+JpC3XhYrhDFoiS2VJPjh4u4kcDdPhmRASJ8r8dHT/lDSbBMOxsbS0rQ8qY0 d2BA== 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=pJM7FgycHiZqoGN5XawP4WFODSB9bVBDRrQHj6fl+Ds=; b=NVrY0jCbGZXDGmewNheZZGLaq1g2an8//eJEYBdd35xyhTSyMbd7viR6+oLnGDIeqV 8w5vpajBC0htlwGWm6uaxRlhv3BgBhZ6zzErqD4kEeYTJuobBth2QYzgFJ1409Gd8CCl ktQIxC+rCDmSmagiRT1dJLlGyJ67hpcOvzP1ZpldMRV1Y028+KVDFCiL5yLaqrzgIjxz 3KG1Jg/0YQUOXUEcbLrwo3VpcgpMmFBaZomTgE2BzKnacgFQUtHH8Bw90SUlzRZCxF8y n9pt8TwMNnOXIEH6AzR5/d10qwcs1ZwYf3bsr2oY+JiNQV/zRCug91pTPc/KcjAeLjRK mUBw== X-Gm-Message-State: ALQs6tBLUuU1AYAosj8OomCKJXUbHXASSQZAJ2rgjYhic4RXvyckw7Gh trOfEhnuuWIsZAdBjQ+WJE4V9ywATkfJQXwZdmc= X-Google-Smtp-Source: AIpwx49Eme+Il/JG6lptw4yUGHrpDDJp7EWT7n/KxWwA/ohZNLOdK/Nz1BHkFZfPfqDbnXl4uBRedTLX99OVh9dTsLU= X-Received: by 2002:a19:1a88:: with SMTP id a130-v6mr3485944lfa.7.1522802144859; Tue, 03 Apr 2018 17:35:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.73.66 with HTTP; Tue, 3 Apr 2018 17:35:44 -0700 (PDT) In-Reply-To: <36BBC371-54A2-43B0-8597-69782CFFD5E9@outlook.com> References: <20180328163856.GB3126@pfrc.org> <36BBC371-54A2-43B0-8597-69782CFFD5E9@outlook.com> From: Greg Mirsky Date: Tue, 3 Apr 2018 17:35:44 -0700 Message-ID: Subject: Re: WGLC BFD Authentication Drafts To: Ashesh Mishra Cc: Jeffrey Haas , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e85abf0568fb0067" 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: Wed, 04 Apr 2018 00:35:50 -0000 --000000000000e85abf0568fb0067 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Asheh, thank you for the detailed response to my questions and consideration of my comments. I think I cannot agree that the BFD state machine remains unchanged if optimized BFD authentication is in periodic mode. Let's consider case when only every 5th BFD control packet is authenticated when the session is in Up state. What happens if from some moment every authenticated packet fails to be validated? Would the session go to Down state? But all unauthenticated BFD control packets pass the validation check and since only one packet seems to miss validation the session, if the state machine remains unchanged, will stay Up. Do you see this as plausible scenario? Regards, Greg On Tue, Apr 3, 2018 at 11:03 AM, Ashesh Mishra wrote: > Thanks for the clarification, Greg. > > > > Here are my thoughts on the issues: > > > > *I'd break it into couple more specific questions: * > > =C2=B7 *can the periodic Optimized Authentication mode be used wi= thout > authorization o state changes;* > > =C2=B7 *if the answer to the previous question "yes", then when t= he > first authorized BFD control packet must be transmitted by the system;* > > =C2=B7 *does the BFD state machine (section 6.2 RFC 5880) changes > resulting from introduction of periodic optimized authentication mode;* > > *[AM] The optimized authentication can be used without state changes and > the first auth packet will be the DOWN state frame to kick-off the sessio= n > negotiation as the proposal suggests that all DOWN state frames are > authenticated. The state machine does not change in this proposal but it > only indicates which frames should be authenticated and which ones can us= e > NULL-AUTH TLV (un-authenticated frames). * > > *And additional comments:* > > =C2=B7 *"For example, the two ends can decide that BFD frames tha= t > indicate a state change should be authenticated and enable authentication > on those frames only."* > > *I don't think that nodes "decide" anything but are configured to do > something.* > > > > *[AM] I agree that the language is not accurate. We=E2=80=99ll change it = in the > next revision. The intention is to use indicate configuration rather than > negotiation. * > > =C2=B7 *"If the two ends have not previously negotiated which fra= mes > they will transmit or receive with authentication enabled ..."* > > *I couldn't find the negotiation procedure being described in the > document. Is it out-of-band, i.e. by control or management plane, not par= t > of this BFD enhancement?* > > > > *[AM] The language should indicate configuration instead of negotiation. = * > > =C2=B7 *"The configuration of the periodic authentication interva= l for > BFD CC UP frames is an open issue."* > > *I believe that this open issue must be resolved in the definitive manner > before the draft moved to WGLC.* > > > > *[AM] This line should be removed and the preceding text should indicate > that the parameters for authentication should be configured on the sessio= n > end-points. * > > > > Regards, > Ashesh > > > > *From: *Greg Mirsky > *Date: *Monday, April 2, 2018 at 12:34 PM > *To: *Ashesh Mishra > *Cc: *Jeffrey Haas , "rtg-bfd@ietf.org" > > *Subject: *Re: WGLC BFD Authentication Drafts > > > > Hi Asheh, > > thank you for taking time to review the minutes from BFD WG meeting at > IETF-98. I don't think that we had enough time to discuss in details my > question: > > Greg Mirsky: One of the possible modes when the session is up is to use > authentication with periodic timer trigger? > > I'd break it into couple more specific questions: > > - can the periodic Optimized Authentication mode be used without > authorization o state changes; > - if the answer to the previous question "yes", then when the first > authorized BFD control packet must be transmitted by the system; > - does the BFD state machine (section 6.2 RFC 5880) changes resulting > from introduction of periodic optimized authentication mode; > > And additional comments: > > - "For example, the two ends can decide that BFD frames that indicate > a state change should be authenticated and enable authentication on th= ose > frames only." > > I don't think that nodes "decide" anything but are configured to do > something. > > > - "If the two ends have not previously negotiated which frames they > will transmit or receive with authentication enabled ..." > > I couldn't find the negotiation procedure being described in the document= . > Is it out-of-band, i.e. by control or management plane, not part of this > BFD enhancement? > > > - "The configuration of the periodic authentication interval for BFD > CC UP frames is an open issue." > > I believe that this open issue must be resolved in the definitive manner > before the draft moved to WGLC. > > > > Regards, > > Greg > > > > > > On Sun, Apr 1, 2018 at 6:11 PM, Ashesh Mishra > wrote: > > Hi Greg, > > > > Your questions in the IETF-98 meeting seemed to stem from the challenges > of authentication in fast BFD sessions at high scale. > > > > I'll address the issue in two parts - > > > > "Is there a need for authenticated BFD sessions?" - I believe we can all > agree that there is a clear market need for BFD authentication. So we > should direct the conversation to the way in which we can address this > requirement. > > > > "How can authentication work at scale?" - BFD authentication puts > significant stress on the system and a non-meticulous method alleviates > this computation pressure. That's the premise of this draft as it present= s > a way to relieve the BFD authentication requirement based on the capabili= ty > of the system to handle the additional stress which maintaining the > session scale. > > > > There are some BFD systems in the market, which are not conducive to > authentication (even the optimized method), where the impediment to > authentication is due to the implementation details specific to that vend= or > or system. > > > > I believe all these issues were address during the meeting. Are there any > specific questions that I missed or any recommendations for the method in > which the requirements can be addressed? > > > > Thanks, > > Ashesh > ------------------------------ > > *From:* Rtg-bfd on behalf of Greg Mirsky < > gregimirsky@gmail.com> > *Sent:* Thursday, March 29, 2018 4:09:32 AM > *To:* Jeffrey Haas > *Cc:* rtg-bfd@ietf.org > *Subject:* Re: WGLC BFD Authentication Drafts > > > > Dear WG Chairs, et. al, > > I cannot support WG LC for draft-ietf-bfd-optimizing-authentication as my > comments at BFD WG meeting dating back to IETF-98 > sti= ll > not have been addressed nor even there was an attempt to address. As I've > asked to clarify impact of the proposed mechanism, particularly periodic > authentication, on the BFD State Machine, I'd point that the proposed > mechanism directly affects BFD security as discussed in RFC 5880 and the > section Security Considerations in the document, in my view, does not > adequately reflects that and doesn't explain how the security of the BFD > session maintained when the periodic authentication is in use. > > > > Regards, > > Greg > > > > On Wed, Mar 28, 2018 at 7:38 PM, Jeffrey Haas wrote: > > Working Group, > > The authors of the following Working Group drafts have requested > Working Group Last Call on the following documents: > > https://tools.ietf.org/html/draft-ietf-bfd-secure-sequence-numbers-01 > https://tools.ietf.org/html/draft-ietf-bfd-optimizing-authentication-04 > https://tools.ietf.org/html/draft-ietf-bfd-stability-01 > > Given the overlap of functionality, WGLC will conclude for the bundle > simultaneously. > > Authors, please positively acknowledge whether or not you know about any > IPR > for your documents. Progression of the document will not be done without > that statement. > > Last call will complete on April 20. > > -- Jeff > > > > > --000000000000e85abf0568fb0067 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Asheh,
    thank you for the detailed response to my qu= estions and consideration of my comments.
    I think I cannot agree = that the BFD state machine remains unchanged if optimized BFD authenticatio= n is in periodic mode. Let's consider case when only every 5th BFD cont= rol packet is authenticated when the session is in Up state. What happens i= f from some moment every authenticated packet fails to be validated? Would = the session go to Down state? But all unauthenticated BFD control packets p= ass the validation check and since only one packet seems to miss validation= the session, if the state machine remains unchanged, will stay Up.

    Do you see this as plausible scenario?

    Regards,
    Greg

    On Tue, Apr 3, 2018 at 11:03 AM, Ashesh Mishra <mishra.ashesh@outlook.com> wrote:

    Thanks for the clarification, Greg.

    =C2=A0

    Here are my thoughts on the issues:

    =C2=A0

    I'd break it into= couple more specific questions:

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 can the periodic Optimized Authentication mo= de be used without authorization o state changes;

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 if the answer to the previous question "= ;yes", then when the first authorized BFD control packet must be trans= mitted by the system;

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 does the BFD state machine (section 6.2 RFC = 5880) changes resulting from introduction of periodic optimized authenticat= ion mode;

    [AM] The optimized authentication can be u= sed without state changes and the first auth packet will be the DOWN state = frame to kick-off the session negotiation as the proposal suggests that all DOWN state frames are authenticated. The state machine d= oes not change in this proposal but it only indicates which frames should b= e authenticated and which ones can use NULL-AUTH TLV (un-authenticated fram= es).

    And additional commen= ts:

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 "For example, the two ends can decide t= hat BFD frames that indicate a state change should be authenticated and ena= ble authentication on those frames only."

    I don't think tha= t nodes "decide" anything but are configured to do something.<= /u>

    =C2=A0

    [AM] I agree that the language is not accu= rate. We=E2=80=99ll change it in the next revision. The intention is to use= indicate configuration rather than negotiation.

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 "If the two ends have not previously ne= gotiated which frames they will transmit or receive with authentication ena= bled ..."

    I couldn't find t= he negotiation procedure being described in the document. Is it out-of-band= , i.e. by control or management plane, not part of this BFD enhancement?=

    =C2= =A0

    [AM] The language should indicate configur= ation instead of negotiation.

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 "The configuration of the periodic auth= entication interval for BFD CC UP frames is an open issue."<= /u>

    I believe that this o= pen issue must be resolved in the definitive manner before the draft moved = to WGLC.

    =C2=A0

    [AM] This line should be removed and the p= receding text should indicate that the parameters for authentication should= be configured on the session end-points.

    =C2=A0

    Regards,
    Ashesh

    =C2=A0

    From= : Greg Mirsky <<= a href=3D"mailto:gregimirsky@gmail.com" target=3D"_blank">gregimirsky@gmail= .com>
    Date: Monday, April 2, 2018 at 12:34 PM
    To: Ashesh Mishra <mishra.ashesh@outlook.com>
    Cc: Jeffrey Haas <jhaas@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>


    Subject: Re: WGLC BFD Authentication Drafts

    =C2=A0

    = Hi Asheh,

    thank you for taking time to review the minute= s from BFD WG meeting at IETF-98. I don't think that we had enough time= to discuss in details my question:

    Greg Mirsky: One of the possible modes when th= e session is up is to use authentication with periodic timer trigger?

    I'd break it into couple more specific que= stions:

    • can the periodic Optimized Authentication mode be used without author= ization o state changes;
    • if the answer to the previous question "yes", then when the= first authorized BFD control packet must be transmitted by the system;<= /u>
    • does the BFD state machine (section 6.2 RFC 5880) changes resulting f= rom introduction of periodic optimized authentication mode;

    And additional comments:<= /p>

    • "For example, the two ends can decide that BFD frames that indic= ate a state change should be authenticated and enable authentication on tho= se frames only."

    I don't think that nodes "decide"= ; anything but are configured to do something.

    • "If the two ends have not previously negotiated which frames the= y will transmit or receive with authentication enabled ..."<= /u>

    I couldn't find the negotiation procedure = being described in the document. Is it out-of-band, i.e. by control or mana= gement plane, not part of this BFD enhancement?

    • "The configuration of the periodic authentication interval for B= FD CC UP frames is an open issue."

    I believe that this open issue must be resolve= d in the definitive manner before the draft moved to WGLC.

    =C2=A0

    Regards,

    Greg

    =C2=A0

    =C2=A0

    On Sun, Apr 1, 2018 at 6:11 PM, Ashesh Mishra = <<= span>mishra.ashesh@outlook.com> wrote:

    Hi Greg,=C2=A0

    =C2=A0

    Your questions=C2=A0in the IETF-98 meeting seemed to = stem from the challenges of authentication in fast BFD sessions at high sca= le.=C2=A0

    =C2=A0

    I'll address the issue in two parts -=C2=A0

    =C2=A0

    "Is there a need for authenticated BFD sessions?= " - I believe we can all agree that there is a clear market need for B= FD authentication. So we should direct the conversation to the way in which we can address th= is requirement.=C2=A0

    =C2=A0

    "How can authentication work at scale?" - B= FD authentication puts significant stress on the system and a non-meticulou= s method alleviates this computation pressure. That's the premise of this draft= as it presents a way to relieve the BFD authentication requirement based o= n the capability of the system to handle the additional stress which mainta= ining the session=C2=A0scale.=C2=A0

    =C2=A0

    There are some BFD systems in the market, which are n= ot conducive to authentication (even the optimized method), where the imped= iment to authentication is due to the implementation details specific to that ve= ndor or system.=C2=A0

    =C2=A0

    I believe all these issues were address during the me= eting. Are there any specific questions that I missed or any recommendation= s for the method in which the requirements can be addressed?=C2=A0=

    =C2=A0

    Thanks,

    Ashesh

    From: Rtg-bfd <rtg-bfd-bounc= es@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com= >
    Sent: Thursday, March 29, 2018 4:09:32 AM
    To: Jeffrey Haas
    Cc:     rtg-bfd@ietf.org
    Subject: Re: WGLC BFD Authentication Drafts

    =C2=A0

    Dear WG Chairs, et. al,=C2=A0

    I cannot support WG LC for=C2=A0draft-ietf-bfd= -optimizing-authentication as my comments at BFD WG meeting dating back to IETF-98=C2=A0still not have been addressed nor even there was an attempt to address. As I'= ;ve asked to clarify impact of the proposed mechanism, particularly periodi= c authentication, on the BFD State Machine, I'd point that the proposed= mechanism directly affects BFD security as discussed in RFC 5880 and the section Security Considerations in the do= cument, in my view, does not adequately reflects that and doesn't expla= in how the security of the BFD session maintained when the periodic authent= ication is in use.

    =C2=A0

    Regards,

    Greg

    =C2=A0

    On Wed, Mar 28, 2018 at 7:38 PM, Jeffrey Haas = <jhaas@= pfrc.org> wrote:

    Working Group,<= br>
    The authors of the following Working Group drafts have requested
    Working Group Last Call on the following documents:

    https://tools.ietf.org/html/draf= t-ietf-bfd-secure-sequence-numbers-01 https://tools.ietf.org/html/dr= aft-ietf-bfd-optimizing-authentication-04
    https://tools.ietf.org/html/draft-ietf-bfd-sta= bility-01

    Given the overlap of functionality, WGLC will conclude for the bundle
    simultaneously.

    Authors, please positively acknowledge whether or not you know about any IP= R
    for your documents.=C2=A0 Progression of the document will not be done with= out
    that statement.

    Last call will complete on April 20.

    -- Jeff

    =C2=A0

    =C2=A0


    --000000000000e85abf0568fb0067-- From nobody Fri Apr 6 05:55:52 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 A842512E8EC; Fri, 6 Apr 2018 05:55:36 -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_RP_MATCHES_RCVD=-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 y46I93yr6J93; Fri, 6 Apr 2018 05:55:34 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0648212D7ED; Fri, 6 Apr 2018 05:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18204; q=dns/txt; s=iport; t=1523019334; x=1524228934; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=r5E8fGWhXY0fo9e/EjIPqQ+XRG+BInB9iql0q7qe4Uo=; b=jY6Gye5zigkCCeBX3S2krYK4dm2O4LC2aSiAM57cts8LdZ/QjdQYwPkG MvFBQwBESKHobRzByra3oryuPbi6/I77Jv3cA9cbeiCCcpUh6cj0GGpFw zT8XGEFcwfc/05vzYCvwZcsYyHFEqoI225Xw6uKZzVNDH2oY9UZSCaZJT E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DtAADqbcda/5ldJa1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJNdWFvKAqDVYgAjQqBdIEPhmKHEoRkgXoLhQMCGoIeITQ?= =?us-ascii?q?YAQIBAQEBAQECbCiFIgEBAQEDI1YQAgEIDgMDAQIoAwICAh8RFAkIAgQBDQW?= =?us-ascii?q?EKUwDFakBghyHDg2BK4Ilh2uBVD+BDCKCYoJPgkAWgkowgiQCiAyIQIZLLAg?= =?us-ascii?q?CizSCfYEyiw6HKYIvhgcCERMBgSQBHDiBUnAVZAGCGAmQRW+MTYEXAQE?= X-IronPort-AV: E=Sophos; i="5.48,415,1517875200"; d="scan'208,217"; a="95071243" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2018 12:55:33 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w36CtX5H011299 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Apr 2018 12:55:33 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 6 Apr 2018 07:55:32 -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, 6 Apr 2018 07:55:32 -0500 From: "Reshad Rahman (rrahman)" To: Mahesh Jethanandani , "Acee Lindem (acee)" CC: "rtg-bfd@ietf.org" , "draft-ietf-bfd-optimizing-authentication@ietf.org" , Ashesh Mishra Subject: Re: Comments on Optimizing BFD Authentication Thread-Topic: Comments on Optimizing BFD Authentication Thread-Index: AQHTxrXg7R1nLPZpF0K7q9k2GbGfCKPsZcqAgADQ6oCAAIZsAIAACr0AgAYIkYA= Date: Fri, 6 Apr 2018 12:55:32 +0000 Message-ID: <1DB6199F-61F6-47C7-A5C7-D631ACCC53CD@cisco.com> References: <20180328165736.GD3126@pfrc.org> In-Reply-To: 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: [10.86.255.69] Content-Type: multipart/alternative; boundary="_000_1DB6199F61F647C7A5C7D631ACCC53CDciscocom_" 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, 06 Apr 2018 12:55:38 -0000 --_000_1DB6199F61F647C7A5C7D631ACCC53CDciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzIGxvb2tzIGxpa2Ugd2XigJlsbCBoYXZlIHRvIGRvIGEgYmlzLg0KDQpSZWdhcmRzLA0KUmVz aGFkLg0KDQpGcm9tOiBSdGctYmZkIDxydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFs ZiBvZiBNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCkRhdGU6 IE1vbmRheSwgQXByaWwgMiwgMjAxOCBhdCA4OjQ3IEFNDQpUbzogIkFjZWUgTGluZGVtIChhY2Vl KSIgPGFjZWVAY2lzY28uY29tPg0KQ2M6ICJydGctYmZkQGlldGYub3JnIiA8cnRnLWJmZEBpZXRm Lm9yZz4sICJkcmFmdC1pZXRmLWJmZC1vcHRpbWl6aW5nLWF1dGhlbnRpY2F0aW9uQGlldGYub3Jn IiA8ZHJhZnQtaWV0Zi1iZmQtb3B0aW1pemluZy1hdXRoZW50aWNhdGlvbkBpZXRmLm9yZz4sIEFz aGVzaCBNaXNocmEgPG1pc2hyYS5hc2hlc2hAZ21haWwuY29tPg0KU3ViamVjdDogUmU6IENvbW1l bnRzIG9uIE9wdGltaXppbmcgQkZEIEF1dGhlbnRpY2F0aW9uDQoNCkFjZWUsDQoNCk9yIGJ5IGRv aW5nIGEgImJpcyIgdmVyc2lvbiBvZiB0aGUgZHJhZnQuIFRoZXJlIGlzIG5vIHdheSB0byBhdWdt ZW50IGEgdHlwZWRlZi4NCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFuaUBnbWFp bC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQpPbiBBcHIgMiwgMjAxOCwg YXQgNTowOCBBTSwgQWNlZSBMaW5kZW0gKGFjZWUpIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNl ZUBjaXNjby5jb20+PiB3cm90ZToNCk1haGVzaCDigJMgSSBiZWxpZXZlIHRoZXNlIHNob3VsZCBi ZSBkb25lIGFzIGF1Z21lbnRhdGlvbnMgc2luY2UgZHJhZnQtaWV0Zi1iZmQteWFuZy0xMyBoYXMg YWxyZWFkeSBiZWVuIHN1Ym1pdHRlZCB0byB0aGUgSUVTRyBmb3IgcHVibGljYXRpb24uDQpUaGFu a3MsDQpBY2VlDQoNCkZyb206IFJ0Zy1iZmQgPHJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIE1haGVzaCBKZXRoYW5h bmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWls LmNvbT4+DQpEYXRlOiBNb25kYXksIEFwcmlsIDIsIDIwMTggYXQgMTI6MDYgQU0NClRvOiBBc2hl c2ggTWlzaHJhIDxtaXNocmEuYXNoZXNoQGdtYWlsLmNvbTxtYWlsdG86bWlzaHJhLmFzaGVzaEBn bWFpbC5jb20+Pg0KQ2M6ICJydGctYmZkQGlldGYub3JnPG1haWx0bzpydGctYmZkQGlldGYub3Jn PiIgPHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+PiwgImRyYWZ0LWll dGYtYmZkLW9wdGltaXppbmctYXV0aGVudGljYXRpb25AaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWll dGYtYmZkLW9wdGltaXppbmctYXV0aGVudGljYXRpb25AaWV0Zi5vcmc+IiA8ZHJhZnQtaWV0Zi1i ZmQtb3B0aW1pemluZy1hdXRoZW50aWNhdGlvbkBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1i ZmQtb3B0aW1pemluZy1hdXRoZW50aWNhdGlvbkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogQ29t bWVudHMgb24gT3B0aW1pemluZyBCRkQgQXV0aGVudGljYXRpb24NCg0KDQoNCg0KDQpPbiBBcHIg MSwgMjAxOCwgYXQgODo0MCBBTSwgQXNoZXNoIE1pc2hyYSA8bWlzaHJhLmFzaGVzaEBnbWFpbC5j b208bWFpbHRvOm1pc2hyYS5hc2hlc2hAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0KDQpXaGF0IGFy ZSB0aGUgeWFuZyBtb2RlbCBjb25zaWRlcmF0aW9ucz8gIChTZWUgcHJpb3IgcG9pbnQuKQ0KDQpb QU1dIEknbGwgbGV0IE1haGVzaCBjb21tZW50IG9uIHRoaXMuDQoNClRvIHN1cHBvcnQgdGhlIG9w dGltaXplZCBCRkQgYXV0aGVudGljYXRpb24sIHdlIHdpbGwgbmVlZCB0byBjaGFuZ2UgdGhlIEJG RCBZQU5HIG1vZGVsIHRvIGFkZCBhIOKAmG9wdGltaXplZOKAmSBhdXRoZW50aWNhdGlvbiBjYXBh YmlsaXR5Lg0KDQpGb2xsb3dpbmcgYXJlIHNvbWUgb2YgdGhlIGNoYW5nZXMgSSBhbnRpY2lwYXRl DQoNCi0gVGhlIGN1cnJlbnQgbW9kZWwgaGFzIGEgdHlwZWRlZiBmb3IgYXV0aC10eXBlLCBidXQg c2luY2UgYSBiaXQgaGFzIG5vdCBiZWVuIGFzc2lnbmVkIChpdCBpcyBhIFRCRCksIGl0IHdpbGwg cmVxdWlyZSBhbiB1cGRhdGUgdG8gdGhlIHR5cGVkZWYgdG8gaW5jbHVkZSB0aGUgbmV3IGJpdCwg d2hlbiBpdCBpcyBhc3NpZ25lZCBhZnRlciBJQU5BIGFwcHJvdmVzIGl0Lg0KDQotIFRoZSBjdXJy ZW50IFlBTkcgbW9kZWwgb25seSBzdXBwb3J0cyB0aGUgbWV0aWN1bG91cyBtb2RlIG9mIGF1dGhl bnRpY2F0aW9uIGluIGl0cyBncm91cGluZyBmb3IgYXV0aC1wYXJtcy4gV2lsbCBuZWVkIHRvIG1h a2UgaXQgYSBjaG9pY2UgYmV0d2VlbiBtZXRpY3Vsb3VzIGFuZCB0aGUg4oCYb3B0aW1pemVk4oCZ IG1vZGUuDQoNCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb208 bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQoNCg0K --_000_1DB6199F61F647C7A5C7D631ACCC53CDciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglm b250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLUNBIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+WWVzIGxvb2tzIGxpa2Ugd2XigJlsbCBoYXZlIHRvIGRvIGEgYmlzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVzaGFkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTog PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+UnRn LWJmZCAmbHQ7cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgTWFoZXNo IEpldGhhbmFuZGFuaSAmbHQ7bWpldGhhbmFuZGFuaUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0 ZTogPC9iPk1vbmRheSwgQXByaWwgMiwgMjAxOCBhdCA4OjQ3IEFNPGJyPg0KPGI+VG86IDwvYj4m cXVvdDtBY2VlIExpbmRlbSAoYWNlZSkmcXVvdDsgJmx0O2FjZWVAY2lzY28uY29tJmd0Ozxicj4N CjxiPkNjOiA8L2I+JnF1b3Q7cnRnLWJmZEBpZXRmLm9yZyZxdW90OyAmbHQ7cnRnLWJmZEBpZXRm Lm9yZyZndDssICZxdW90O2RyYWZ0LWlldGYtYmZkLW9wdGltaXppbmctYXV0aGVudGljYXRpb25A aWV0Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0LWlldGYtYmZkLW9wdGltaXppbmctYXV0aGVudGljYXRp b25AaWV0Zi5vcmcmZ3Q7LCBBc2hlc2ggTWlzaHJhICZsdDttaXNocmEuYXNoZXNoQGdtYWlsLmNv bSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IENvbW1lbnRzIG9uIE9wdGltaXppbmcgQkZE IEF1dGhlbnRpY2F0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BY2VlLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PciBieSBkb2luZyBhICZxdW90O2JpcyZxdW90OyB2ZXJzaW9uIG9mIHRo ZSBkcmFmdC4gVGhlcmUgaXMgbm8gd2F5IHRvIGF1Z21lbnQgYSB0eXBlZGVmLjxicj4NCjxicj4N Ck1haGVzaCBKZXRoYW5hbmRhbmkgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0aGFu YW5kYW5pQGdtYWlsLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpPbiBBcHIgMiwgMjAxOCwgYXQgNTowOCBBTSwgQWNlZSBMaW5kZW0gKGFjZWUpICZsdDs8YSBo cmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTYuMHB0Ij5NYWhlc2gg4oCTIEkgYmVsaWV2ZSB0aGVzZSBz aG91bGQgYmUgZG9uZSBhcyBhdWdtZW50YXRpb25zIHNpbmNlIGRyYWZ0LWlldGYtYmZkLXlhbmct MTMgaGFzIGFscmVhZHkgYmVlbiBzdWJtaXR0ZWQgdG8gdGhlIElFU0cgZm9yIHB1YmxpY2F0aW9u Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTYuMHB0Ij5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQiPkFjZWU8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjE2LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5SdGct YmZkICZsdDs8YSBocmVmPSJtYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIj5ydGctYmZk LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgTWFoZXNoIEpldGhhbmFuZGFu aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0aGFuYW5k YW5pQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgQXByaWwgMiwg MjAxOCBhdCAxMjowNiBBTTxicj4NCjxiPlRvOiA8L2I+QXNoZXNoIE1pc2hyYSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1pc2hyYS5hc2hlc2hAZ21haWwuY29tIj5taXNocmEuYXNoZXNoQGdtYWlsLmNv bTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBp ZXRmLm9yZyI+cnRnLWJmZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpy dGctYmZkQGlldGYub3JnIj5ydGctYmZkQGlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9 Im1haWx0bzpkcmFmdC1pZXRmLWJmZC1vcHRpbWl6aW5nLWF1dGhlbnRpY2F0aW9uQGlldGYub3Jn Ij5kcmFmdC1pZXRmLWJmZC1vcHRpbWl6aW5nLWF1dGhlbnRpY2F0aW9uQGlldGYub3JnPC9hPiZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtYmZkLW9wdGltaXppbmctYXV0aGVu dGljYXRpb25AaWV0Zi5vcmciPmRyYWZ0LWlldGYtYmZkLW9wdGltaXppbmctYXV0aGVudGljYXRp b25AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogQ29tbWVudHMgb24g T3B0aW1pemluZyBCRkQgQXV0aGVudGljYXRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGEgbmFtZT0iX01haWxPcmlnaW5hbEJvZHkiPiZuYnNw OzxvOnA+PC9vOnA+PC9hPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5PbiBBcHIgMSwgMjAxOCwgYXQg ODo0MCBBTSwgQXNoZXNoIE1pc2hyYSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptaXNocmEu YXNoZXNoQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+bWlzaHJhLmFzaGVzaEBnbWFpbC5jb208L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mZ3Q7DQogd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVs dmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0O2NhcmV0LWNvbG9yOiBy Z2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRv bTo1LjBwdDtjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1z cGFjaW5nOjBweCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+V2hhdCBhcmUgdGhl IHlhbmcgbW9kZWwgY29uc2lkZXJhdGlvbnM/Jm5ic3A7IChTZWUgcHJpb3IgcG9pbnQuKTwvc3Bh bj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+W0FNXSBJJ2xs IGxldCBNYWhlc2ggY29tbWVudCBvbiB0aGlzLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+VG8gc3VwcG9ydCB0aGUg b3B0aW1pemVkIEJGRCBhdXRoZW50aWNhdGlvbiwgd2Ugd2lsbCBuZWVkIHRvIGNoYW5nZSB0aGUg QkZEIFlBTkcgbW9kZWwgdG8gYWRkIGEg4oCYb3B0aW1pemVk4oCZIGF1dGhlbnRpY2F0aW9uIGNh cGFiaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Rm9sbG93 aW5nIGFyZSBzb21lIG9mIHRoZSBjaGFuZ2VzIEkgYW50aWNpcGF0ZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPi0gVGhlIGN1cnJlbnQgbW9kZWwgaGFzIGEgdHlwZWRl ZiBmb3IgYXV0aC10eXBlLCBidXQgc2luY2UgYSBiaXQgaGFzIG5vdCBiZWVuIGFzc2lnbmVkIChp dCBpcyBhIFRCRCksIGl0IHdpbGwgcmVxdWlyZSBhbiB1cGRhdGUgdG8gdGhlIHR5cGVkZWYgdG8g aW5jbHVkZSB0aGUgbmV3IGJpdCwNCiB3aGVuIGl0IGlzIGFzc2lnbmVkIGFmdGVyIElBTkEgYXBw cm92ZXMgaXQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ LSBUaGUgY3VycmVudCBZQU5HIG1vZGVsIG9ubHkgc3VwcG9ydHMgdGhlIG1ldGljdWxvdXMgbW9k ZSBvZiBhdXRoZW50aWNhdGlvbiBpbiBpdHMgZ3JvdXBpbmcgZm9yIGF1dGgtcGFybXMuIFdpbGwg bmVlZCB0byBtYWtlIGl0IGEgY2hvaWNlIGJldHdlZW4gbWV0aWN1bG91cyBhbmQgdGhlDQog4oCY b3B0aW1pemVk4oCZIG1vZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPk1haGVzaCBKZXRoYW5hbmRhbmk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5tamV0aGFuYW5kYW5pQGdtYWlsLmNv bTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1DB6199F61F647C7A5C7D631ACCC53CDciscocom_-- From nobody Fri Apr 6 08:01: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 A8E1C12D7F9 for ; Tue, 3 Apr 2018 11:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 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, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 5AM1fmtwXmgu for ; Tue, 3 Apr 2018 11:04:26 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-oln040092003080.outbound.protection.outlook.com [40.92.3.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E0112E8D7 for ; Tue, 3 Apr 2018 11:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ii6AYrlwRcPA5+RoJi91Hybs3I3HVf6Ui6uHbL+2F0E=; b=PkyX7S+DCGLjyMPGSW66+ERqcuuarDY9wGlhxXEoZRPLOun+HqI3O31F1IMaeriNmCf3vjR+zBz8y3bTF09zY0SmkN92eKXtgtGrdmDhQQZC1ijlky6z0pY/hkAsgEItvsBXhylKdvgqJBfDqD8mnNUniMBYupC8iBmYmparCGA+GN4jG73MIh/DwxDcBrKNzGZZZjP4Q8nZUA5PHikNmukNaSPDMXIyQHoiFDYnhVOBcP1XfUShVwgba0OTkrjQrlH3SASv6TtZ28xfbLfunOpMsQxYMc3rBmDX9iWejKdOiBj7yu/Yi0bs8DnG3gbepozkQqYTu4SVpZMm5gSanw== Received: from CY1NAM02FT029.eop-nam02.prod.protection.outlook.com (10.152.74.55) by CY1NAM02HT051.eop-nam02.prod.protection.outlook.com (10.152.75.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.653.8; Tue, 3 Apr 2018 18:03:53 +0000 Received: from BL0PR0102MB3345.prod.exchangelabs.com (10.152.74.55) by CY1NAM02FT029.mail.protection.outlook.com (10.152.75.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.653.8 via Frontend Transport; Tue, 3 Apr 2018 18:03:53 +0000 Received: from BL0PR0102MB3345.prod.exchangelabs.com ([fe80::a5f3:348:c9a1:1754]) by BL0PR0102MB3345.prod.exchangelabs.com ([fe80::a5f3:348:c9a1:1754%3]) with mapi id 15.20.0653.012; Tue, 3 Apr 2018 18:03:53 +0000 From: Ashesh Mishra To: Greg Mirsky CC: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: WGLC BFD Authentication Drafts Thread-Topic: WGLC BFD Authentication Drafts Thread-Index: AQHTxrM8j4pe2ek2RUW1GIkZ+QU4DqPnD20AgAT20DKAAa1ggIABNeIA Date: Tue, 3 Apr 2018 18:03:53 +0000 Message-ID: <36BBC371-54A2-43B0-8597-69782CFFD5E9@outlook.com> References: <20180328163856.GB3126@pfrc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:294D1621607C5482E164ED99842A6CFFA66053A22BDCA8F66ADE0E791D5A848B; UpperCasedChecksum:1B2866C6655917B65E14626E0E15940D2BDBD1456CE57D9F1AAC3BC3053CA414; SizeAsReceived:7215; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [tXfod8Nn3IhhdZn/dnGHsxGOPokD7PUU] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1NAM02HT051; 7:0O69dG5rpDz6wOBYGA+fyS9WS/uSy2l8Wb6TnnZcCQhUydfxYxX+IEg2E+UdwO4U9PFNHddlc0StzG0E6S0q+SbHvDsmYvG/kJdBxEQ39jYAzIyqcm4UXsDbT5D1UMQlLiWIgRBF5x148C3jzszKIhSbIpdkY3cplA2vhKlyzC+nCRQjfSqJ1Hr3cQ6SWNSXcdhnPlcXwmvNZp9Y4Vf0S4/+D5fmJpsj202/kUB37hI+qJQ8DMWDlJU1un+JmpKy x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:CY1NAM02HT051; x-ms-traffictypediagnostic: CY1NAM02HT051: x-ms-office365-filtering-correlation-id: 458ef082-3dd2-486f-b524-08d5998d42cc x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:CY1NAM02HT051; BCL:0; PCL:0; RULEID:; SRVR:CY1NAM02HT051; x-forefront-prvs: 0631F0BC3D x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:CY1NAM02HT051; H:BL0PR0102MB3345.prod.exchangelabs.com; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: byrPR1jHXETr0mkMnOvthrUBk8Io7f6C4jKQ1pRrpNTIOghy7oyv/+rExuVNH79Wy3X0hRIDLUKOO7enNbK9wXnZgmw0tPT+Z2WvOVWWrm/aCWcCe9j7/ph5B7gezETeHaiYs3gAkDMEliuT9MfXyZk1XPAPc/rXFhbci9963ErNvg4Sco8jRi/78wK7JcsT spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_36BBC37154A243B0859769782CFFD5E9outlookcom_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 458ef082-3dd2-486f-b524-08d5998d42cc X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2018 18:03:53.2643 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1NAM02HT051 Archived-At: X-Mailman-Approved-At: Fri, 06 Apr 2018 08:01:38 -0700 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: Tue, 03 Apr 2018 18:04:36 -0000 --_000_36BBC37154A243B0859769782CFFD5E9outlookcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbiwgR3JlZy4NCg0KSGVyZSBhcmUgbXkgdGhvdWdo dHMgb24gdGhlIGlzc3VlczoNCg0KSSdkIGJyZWFrIGl0IGludG8gY291cGxlIG1vcmUgc3BlY2lm aWMgcXVlc3Rpb25zOg0KwrcgICAgICAgICBjYW4gdGhlIHBlcmlvZGljIE9wdGltaXplZCBBdXRo ZW50aWNhdGlvbiBtb2RlIGJlIHVzZWQgd2l0aG91dCBhdXRob3JpemF0aW9uIG8gc3RhdGUgY2hh bmdlczsNCsK3ICAgICAgICAgaWYgdGhlIGFuc3dlciB0byB0aGUgcHJldmlvdXMgcXVlc3Rpb24g InllcyIsIHRoZW4gd2hlbiB0aGUgZmlyc3QgYXV0aG9yaXplZCBCRkQgY29udHJvbCBwYWNrZXQg bXVzdCBiZSB0cmFuc21pdHRlZCBieSB0aGUgc3lzdGVtOw0KwrcgICAgICAgICBkb2VzIHRoZSBC RkQgc3RhdGUgbWFjaGluZSAoc2VjdGlvbiA2LjIgUkZDIDU4ODApIGNoYW5nZXMgcmVzdWx0aW5n IGZyb20gaW50cm9kdWN0aW9uIG9mIHBlcmlvZGljIG9wdGltaXplZCBhdXRoZW50aWNhdGlvbiBt b2RlOw0KW0FNXSBUaGUgb3B0aW1pemVkIGF1dGhlbnRpY2F0aW9uIGNhbiBiZSB1c2VkIHdpdGhv dXQgc3RhdGUgY2hhbmdlcyBhbmQgdGhlIGZpcnN0IGF1dGggcGFja2V0IHdpbGwgYmUgdGhlIERP V04gc3RhdGUgZnJhbWUgdG8ga2ljay1vZmYgdGhlIHNlc3Npb24gbmVnb3RpYXRpb24gYXMgdGhl IHByb3Bvc2FsIHN1Z2dlc3RzIHRoYXQgYWxsIERPV04gc3RhdGUgZnJhbWVzIGFyZSBhdXRoZW50 aWNhdGVkLiBUaGUgc3RhdGUgbWFjaGluZSBkb2VzIG5vdCBjaGFuZ2UgaW4gdGhpcyBwcm9wb3Nh bCBidXQgaXQgb25seSBpbmRpY2F0ZXMgd2hpY2ggZnJhbWVzIHNob3VsZCBiZSBhdXRoZW50aWNh dGVkIGFuZCB3aGljaCBvbmVzIGNhbiB1c2UgTlVMTC1BVVRIIFRMViAodW4tYXV0aGVudGljYXRl ZCBmcmFtZXMpLg0KQW5kIGFkZGl0aW9uYWwgY29tbWVudHM6DQrCtyAgICAgICAgICJGb3IgZXhh bXBsZSwgdGhlIHR3byBlbmRzIGNhbiBkZWNpZGUgdGhhdCBCRkQgZnJhbWVzIHRoYXQgaW5kaWNh dGUgYSBzdGF0ZSBjaGFuZ2Ugc2hvdWxkIGJlIGF1dGhlbnRpY2F0ZWQgYW5kIGVuYWJsZSBhdXRo ZW50aWNhdGlvbiBvbiB0aG9zZSBmcmFtZXMgb25seS4iDQpJIGRvbid0IHRoaW5rIHRoYXQgbm9k ZXMgImRlY2lkZSIgYW55dGhpbmcgYnV0IGFyZSBjb25maWd1cmVkIHRvIGRvIHNvbWV0aGluZy4N Cg0KW0FNXSBJIGFncmVlIHRoYXQgdGhlIGxhbmd1YWdlIGlzIG5vdCBhY2N1cmF0ZS4gV2XigJls bCBjaGFuZ2UgaXQgaW4gdGhlIG5leHQgcmV2aXNpb24uIFRoZSBpbnRlbnRpb24gaXMgdG8gdXNl IGluZGljYXRlIGNvbmZpZ3VyYXRpb24gcmF0aGVyIHRoYW4gbmVnb3RpYXRpb24uDQrCtyAgICAg ICAgICJJZiB0aGUgdHdvIGVuZHMgaGF2ZSBub3QgcHJldmlvdXNseSBuZWdvdGlhdGVkIHdoaWNo IGZyYW1lcyB0aGV5IHdpbGwgdHJhbnNtaXQgb3IgcmVjZWl2ZSB3aXRoIGF1dGhlbnRpY2F0aW9u IGVuYWJsZWQgLi4uIg0KSSBjb3VsZG4ndCBmaW5kIHRoZSBuZWdvdGlhdGlvbiBwcm9jZWR1cmUg YmVpbmcgZGVzY3JpYmVkIGluIHRoZSBkb2N1bWVudC4gSXMgaXQgb3V0LW9mLWJhbmQsIGkuZS4g YnkgY29udHJvbCBvciBtYW5hZ2VtZW50IHBsYW5lLCBub3QgcGFydCBvZiB0aGlzIEJGRCBlbmhh bmNlbWVudD8NCg0KW0FNXSBUaGUgbGFuZ3VhZ2Ugc2hvdWxkIGluZGljYXRlIGNvbmZpZ3VyYXRp b24gaW5zdGVhZCBvZiBuZWdvdGlhdGlvbi4NCsK3ICAgICAgICAgIlRoZSBjb25maWd1cmF0aW9u IG9mIHRoZSBwZXJpb2RpYyBhdXRoZW50aWNhdGlvbiBpbnRlcnZhbCBmb3IgQkZEIENDIFVQIGZy YW1lcyBpcyBhbiBvcGVuIGlzc3VlLiINCkkgYmVsaWV2ZSB0aGF0IHRoaXMgb3BlbiBpc3N1ZSBt dXN0IGJlIHJlc29sdmVkIGluIHRoZSBkZWZpbml0aXZlIG1hbm5lciBiZWZvcmUgdGhlIGRyYWZ0 IG1vdmVkIHRvIFdHTEMuDQoNCltBTV0gVGhpcyBsaW5lIHNob3VsZCBiZSByZW1vdmVkIGFuZCB0 aGUgcHJlY2VkaW5nIHRleHQgc2hvdWxkIGluZGljYXRlIHRoYXQgdGhlIHBhcmFtZXRlcnMgZm9y IGF1dGhlbnRpY2F0aW9uIHNob3VsZCBiZSBjb25maWd1cmVkIG9uIHRoZSBzZXNzaW9uIGVuZC1w b2ludHMuDQoNClJlZ2FyZHMsDQpBc2hlc2gNCg0KRnJvbTogR3JlZyBNaXJza3kgPGdyZWdpbWly c2t5QGdtYWlsLmNvbT4NCkRhdGU6IE1vbmRheSwgQXByaWwgMiwgMjAxOCBhdCAxMjozNCBQTQ0K VG86IEFzaGVzaCBNaXNocmEgPG1pc2hyYS5hc2hlc2hAb3V0bG9vay5jb20+DQpDYzogSmVmZnJl eSBIYWFzIDxqaGFhc0BwZnJjLm9yZz4sICJydGctYmZkQGlldGYub3JnIiA8cnRnLWJmZEBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBXR0xDIEJGRCBBdXRoZW50aWNhdGlvbiBEcmFmdHMNCg0KSGkg QXNoZWgsDQp0aGFuayB5b3UgZm9yIHRha2luZyB0aW1lIHRvIHJldmlldyB0aGUgbWludXRlcyBm cm9tIEJGRCBXRyBtZWV0aW5nIGF0IElFVEYtOTguIEkgZG9uJ3QgdGhpbmsgdGhhdCB3ZSBoYWQg ZW5vdWdoIHRpbWUgdG8gZGlzY3VzcyBpbiBkZXRhaWxzIG15IHF1ZXN0aW9uOg0KR3JlZyBNaXJz a3k6IE9uZSBvZiB0aGUgcG9zc2libGUgbW9kZXMgd2hlbiB0aGUgc2Vzc2lvbiBpcyB1cCBpcyB0 byB1c2UgYXV0aGVudGljYXRpb24gd2l0aCBwZXJpb2RpYyB0aW1lciB0cmlnZ2VyPw0KSSdkIGJy ZWFrIGl0IGludG8gY291cGxlIG1vcmUgc3BlY2lmaWMgcXVlc3Rpb25zOg0KDQogICogICBjYW4g dGhlIHBlcmlvZGljIE9wdGltaXplZCBBdXRoZW50aWNhdGlvbiBtb2RlIGJlIHVzZWQgd2l0aG91 dCBhdXRob3JpemF0aW9uIG8gc3RhdGUgY2hhbmdlczsNCiAgKiAgIGlmIHRoZSBhbnN3ZXIgdG8g dGhlIHByZXZpb3VzIHF1ZXN0aW9uICJ5ZXMiLCB0aGVuIHdoZW4gdGhlIGZpcnN0IGF1dGhvcml6 ZWQgQkZEIGNvbnRyb2wgcGFja2V0IG11c3QgYmUgdHJhbnNtaXR0ZWQgYnkgdGhlIHN5c3RlbTsN CiAgKiAgIGRvZXMgdGhlIEJGRCBzdGF0ZSBtYWNoaW5lIChzZWN0aW9uIDYuMiBSRkMgNTg4MCkg Y2hhbmdlcyByZXN1bHRpbmcgZnJvbSBpbnRyb2R1Y3Rpb24gb2YgcGVyaW9kaWMgb3B0aW1pemVk IGF1dGhlbnRpY2F0aW9uIG1vZGU7DQpBbmQgYWRkaXRpb25hbCBjb21tZW50czoNCg0KICAqICAg IkZvciBleGFtcGxlLCB0aGUgdHdvIGVuZHMgY2FuIGRlY2lkZSB0aGF0IEJGRCBmcmFtZXMgdGhh dCBpbmRpY2F0ZSBhIHN0YXRlIGNoYW5nZSBzaG91bGQgYmUgYXV0aGVudGljYXRlZCBhbmQgZW5h YmxlIGF1dGhlbnRpY2F0aW9uIG9uIHRob3NlIGZyYW1lcyBvbmx5LiINCkkgZG9uJ3QgdGhpbmsg dGhhdCBub2RlcyAiZGVjaWRlIiBhbnl0aGluZyBidXQgYXJlIGNvbmZpZ3VyZWQgdG8gZG8gc29t ZXRoaW5nLg0KDQogICogICAiSWYgdGhlIHR3byBlbmRzIGhhdmUgbm90IHByZXZpb3VzbHkgbmVn b3RpYXRlZCB3aGljaCBmcmFtZXMgdGhleSB3aWxsIHRyYW5zbWl0IG9yIHJlY2VpdmUgd2l0aCBh dXRoZW50aWNhdGlvbiBlbmFibGVkIC4uLiINCkkgY291bGRuJ3QgZmluZCB0aGUgbmVnb3RpYXRp b24gcHJvY2VkdXJlIGJlaW5nIGRlc2NyaWJlZCBpbiB0aGUgZG9jdW1lbnQuIElzIGl0IG91dC1v Zi1iYW5kLCBpLmUuIGJ5IGNvbnRyb2wgb3IgbWFuYWdlbWVudCBwbGFuZSwgbm90IHBhcnQgb2Yg dGhpcyBCRkQgZW5oYW5jZW1lbnQ/DQoNCiAgKiAgICJUaGUgY29uZmlndXJhdGlvbiBvZiB0aGUg cGVyaW9kaWMgYXV0aGVudGljYXRpb24gaW50ZXJ2YWwgZm9yIEJGRCBDQyBVUCBmcmFtZXMgaXMg YW4gb3BlbiBpc3N1ZS4iDQpJIGJlbGlldmUgdGhhdCB0aGlzIG9wZW4gaXNzdWUgbXVzdCBiZSBy ZXNvbHZlZCBpbiB0aGUgZGVmaW5pdGl2ZSBtYW5uZXIgYmVmb3JlIHRoZSBkcmFmdCBtb3ZlZCB0 byBXR0xDLg0KDQpSZWdhcmRzLA0KR3JlZw0KDQoNCk9uIFN1biwgQXByIDEsIDIwMTggYXQgNjox MSBQTSwgQXNoZXNoIE1pc2hyYSA8bWlzaHJhLmFzaGVzaEBvdXRsb29rLmNvbTxtYWlsdG86bWlz aHJhLmFzaGVzaEBvdXRsb29rLmNvbT4+IHdyb3RlOg0KDQpIaSBHcmVnLA0KDQoNCg0KWW91ciBx dWVzdGlvbnMgaW4gdGhlIElFVEYtOTggbWVldGluZyBzZWVtZWQgdG8gc3RlbSBmcm9tIHRoZSBj aGFsbGVuZ2VzIG9mIGF1dGhlbnRpY2F0aW9uIGluIGZhc3QgQkZEIHNlc3Npb25zIGF0IGhpZ2gg c2NhbGUuDQoNCg0KDQpJJ2xsIGFkZHJlc3MgdGhlIGlzc3VlIGluIHR3byBwYXJ0cyAtDQoNCg0K DQoiSXMgdGhlcmUgYSBuZWVkIGZvciBhdXRoZW50aWNhdGVkIEJGRCBzZXNzaW9ucz8iIC0gSSBi ZWxpZXZlIHdlIGNhbiBhbGwgYWdyZWUgdGhhdCB0aGVyZSBpcyBhIGNsZWFyIG1hcmtldCBuZWVk IGZvciBCRkQgYXV0aGVudGljYXRpb24uIFNvIHdlIHNob3VsZCBkaXJlY3QgdGhlIGNvbnZlcnNh dGlvbiB0byB0aGUgd2F5IGluIHdoaWNoIHdlIGNhbiBhZGRyZXNzIHRoaXMgcmVxdWlyZW1lbnQu DQoNCg0KDQoiSG93IGNhbiBhdXRoZW50aWNhdGlvbiB3b3JrIGF0IHNjYWxlPyIgLSBCRkQgYXV0 aGVudGljYXRpb24gcHV0cyBzaWduaWZpY2FudCBzdHJlc3Mgb24gdGhlIHN5c3RlbSBhbmQgYSBu b24tbWV0aWN1bG91cyBtZXRob2QgYWxsZXZpYXRlcyB0aGlzIGNvbXB1dGF0aW9uIHByZXNzdXJl LiBUaGF0J3MgdGhlIHByZW1pc2Ugb2YgdGhpcyBkcmFmdCBhcyBpdCBwcmVzZW50cyBhIHdheSB0 byByZWxpZXZlIHRoZSBCRkQgYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnQgYmFzZWQgb24gdGhl IGNhcGFiaWxpdHkgb2YgdGhlIHN5c3RlbSB0byBoYW5kbGUgdGhlIGFkZGl0aW9uYWwgc3RyZXNz IHdoaWNoIG1haW50YWluaW5nIHRoZSBzZXNzaW9uIHNjYWxlLg0KDQoNCg0KVGhlcmUgYXJlIHNv bWUgQkZEIHN5c3RlbXMgaW4gdGhlIG1hcmtldCwgd2hpY2ggYXJlIG5vdCBjb25kdWNpdmUgdG8g YXV0aGVudGljYXRpb24gKGV2ZW4gdGhlIG9wdGltaXplZCBtZXRob2QpLCB3aGVyZSB0aGUgaW1w ZWRpbWVudCB0byBhdXRoZW50aWNhdGlvbiBpcyBkdWUgdG8gdGhlIGltcGxlbWVudGF0aW9uIGRl dGFpbHMgc3BlY2lmaWMgdG8gdGhhdCB2ZW5kb3Igb3Igc3lzdGVtLg0KDQoNCg0KSSBiZWxpZXZl IGFsbCB0aGVzZSBpc3N1ZXMgd2VyZSBhZGRyZXNzIGR1cmluZyB0aGUgbWVldGluZy4gQXJlIHRo ZXJlIGFueSBzcGVjaWZpYyBxdWVzdGlvbnMgdGhhdCBJIG1pc3NlZCBvciBhbnkgcmVjb21tZW5k YXRpb25zIGZvciB0aGUgbWV0aG9kIGluIHdoaWNoIHRoZSByZXF1aXJlbWVudHMgY2FuIGJlIGFk ZHJlc3NlZD8NCg0KDQoNClRoYW5rcywNCg0KQXNoZXNoDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpGcm9tOiBSdGctYmZkIDxydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBHcmVnIE1pcnNreSA8 Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+Pg0KU2Vu dDogVGh1cnNkYXksIE1hcmNoIDI5LCAyMDE4IDQ6MDk6MzIgQU0NClRvOiBKZWZmcmV5IEhhYXMN CkNjOiBydGctYmZkQGlldGYub3JnPG1haWx0bzpydGctYmZkQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFdHTEMgQkZEIEF1dGhlbnRpY2F0aW9uIERyYWZ0cw0KDQpEZWFyIFdHIENoYWlycywgZXQu IGFsLA0KSSBjYW5ub3Qgc3VwcG9ydCBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1iZmQtb3B0aW1pemlu Zy1hdXRoZW50aWNhdGlvbiBhcyBteSBjb21tZW50cyBhdCBCRkQgV0cgbWVldGluZyBkYXRpbmcg YmFjayB0byBJRVRGLTk4PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85OC9t YXRlcmlhbHMvbWludXRlcy05OC1iZmQtMDA+IHN0aWxsIG5vdCBoYXZlIGJlZW4gYWRkcmVzc2Vk IG5vciBldmVuIHRoZXJlIHdhcyBhbiBhdHRlbXB0IHRvIGFkZHJlc3MuIEFzIEkndmUgYXNrZWQg dG8gY2xhcmlmeSBpbXBhY3Qgb2YgdGhlIHByb3Bvc2VkIG1lY2hhbmlzbSwgcGFydGljdWxhcmx5 IHBlcmlvZGljIGF1dGhlbnRpY2F0aW9uLCBvbiB0aGUgQkZEIFN0YXRlIE1hY2hpbmUsIEknZCBw b2ludCB0aGF0IHRoZSBwcm9wb3NlZCBtZWNoYW5pc20gZGlyZWN0bHkgYWZmZWN0cyBCRkQgc2Vj dXJpdHkgYXMgZGlzY3Vzc2VkIGluIFJGQyA1ODgwIGFuZCB0aGUgc2VjdGlvbiBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyBpbiB0aGUgZG9jdW1lbnQsIGluIG15IHZpZXcsIGRvZXMgbm90IGFkZXF1 YXRlbHkgcmVmbGVjdHMgdGhhdCBhbmQgZG9lc24ndCBleHBsYWluIGhvdyB0aGUgc2VjdXJpdHkg b2YgdGhlIEJGRCBzZXNzaW9uIG1haW50YWluZWQgd2hlbiB0aGUgcGVyaW9kaWMgYXV0aGVudGlj YXRpb24gaXMgaW4gdXNlLg0KDQpSZWdhcmRzLA0KR3JlZw0KDQpPbiBXZWQsIE1hciAyOCwgMjAx OCBhdCA3OjM4IFBNLCBKZWZmcmV5IEhhYXMgPGpoYWFzQHBmcmMub3JnPG1haWx0bzpqaGFhc0Bw ZnJjLm9yZz4+IHdyb3RlOg0KV29ya2luZyBHcm91cCwNCg0KVGhlIGF1dGhvcnMgb2YgdGhlIGZv bGxvd2luZyBXb3JraW5nIEdyb3VwIGRyYWZ0cyBoYXZlIHJlcXVlc3RlZA0KV29ya2luZyBHcm91 cCBMYXN0IENhbGwgb24gdGhlIGZvbGxvd2luZyBkb2N1bWVudHM6DQoNCmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmZC1zZWN1cmUtc2VxdWVuY2UtbnVtYmVycy0wMQ0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLW9wdGltaXppbmctYXV0 aGVudGljYXRpb24tMDQNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJm ZC1zdGFiaWxpdHktMDENCg0KR2l2ZW4gdGhlIG92ZXJsYXAgb2YgZnVuY3Rpb25hbGl0eSwgV0dM QyB3aWxsIGNvbmNsdWRlIGZvciB0aGUgYnVuZGxlDQpzaW11bHRhbmVvdXNseS4NCg0KQXV0aG9y cywgcGxlYXNlIHBvc2l0aXZlbHkgYWNrbm93bGVkZ2Ugd2hldGhlciBvciBub3QgeW91IGtub3cg YWJvdXQgYW55IElQUg0KZm9yIHlvdXIgZG9jdW1lbnRzLiAgUHJvZ3Jlc3Npb24gb2YgdGhlIGRv Y3VtZW50IHdpbGwgbm90IGJlIGRvbmUgd2l0aG91dA0KdGhhdCBzdGF0ZW1lbnQuDQoNCkxhc3Qg Y2FsbCB3aWxsIGNvbXBsZXRlIG9uIEFwcmlsIDIwLg0KDQotLSBKZWZmDQoNCg0K --_000_36BBC37154A243B0859769782CFFD5E9outlookcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MTM3Mzc5MDg1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTI1MTcxMTU1ODt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6Mjk5NTAxMzAzOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczotNDk1MDEzODE0O30NCkBsaXN0IGwxOmxldmVsMQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMg0KCXttc28tbGlzdC1pZDoxNTEwMjE1NDYyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotMTkyMzMxOTg2Njt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3Qt aWQ6MTYyMzcyNDIzNTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTU5NDA4NTA5Njt9DQpAbGlz dCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24sIEdyZWcuIDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5IZXJlIGFyZSBteSB0aG91Z2h0cyBvbiB0aGUgaXNzdWVzOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW4iPjxpPkknZCBicmVhayBpdCBp bnRvIGNvdXBsZSBtb3JlIHNwZWNpZmljIHF1ZXN0aW9uczoNCjxvOnA+PC9vOnA+PC9pPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNzVpbjt0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PGk+Y2FuIHRoZSBwZXJpb2Rp YyBPcHRpbWl6ZWQgQXV0aGVudGljYXRpb24gbW9kZSBiZSB1c2VkIHdpdGhvdXQgYXV0aG9yaXph dGlvbiBvIHN0YXRlIGNoYW5nZXM7PG86cD48L286cD48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0Oi43NWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48aT5pZiB0aGUgYW5zd2VyIHRvIHRoZSBwcmV2aW91cyBx dWVzdGlvbiAmcXVvdDt5ZXMmcXVvdDssIHRoZW4gd2hlbiB0aGUgZmlyc3QgYXV0aG9yaXplZCBC RkQgY29udHJvbCBwYWNrZXQgbXVzdCBiZSB0cmFuc21pdHRlZCBieSB0aGUgc3lzdGVtOzxvOnA+ PC9vOnA+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNzVpbjt0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9s Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PGk+ ZG9lcyB0aGUgQkZEIHN0YXRlIG1hY2hpbmUgKHNlY3Rpb24gNi4yIFJGQyA1ODgwKSBjaGFuZ2Vz IHJlc3VsdGluZyBmcm9tIGludHJvZHVjdGlvbiBvZiBwZXJpb2RpYyBvcHRpbWl6ZWQgYXV0aGVu dGljYXRpb24gbW9kZTs8bzpwPjwvbzpwPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPltBTV0gVGhlIG9wdGltaXplZCBhdXRoZW50aWNhdGlvbiBjYW4gYmUgdXNlZCB3aXRob3V0 IHN0YXRlIGNoYW5nZXMgYW5kIHRoZSBmaXJzdCBhdXRoIHBhY2tldCB3aWxsIGJlIHRoZSBET1dO IHN0YXRlIGZyYW1lIHRvIGtpY2stb2ZmIHRoZSBzZXNzaW9uIG5lZ290aWF0aW9uIGFzIHRoZSBw cm9wb3NhbA0KIHN1Z2dlc3RzIHRoYXQgYWxsIERPV04gc3RhdGUgZnJhbWVzIGFyZSBhdXRoZW50 aWNhdGVkLiBUaGUgc3RhdGUgbWFjaGluZSBkb2VzIG5vdCBjaGFuZ2UgaW4gdGhpcyBwcm9wb3Nh bCBidXQgaXQgb25seSBpbmRpY2F0ZXMgd2hpY2ggZnJhbWVzIHNob3VsZCBiZSBhdXRoZW50aWNh dGVkIGFuZCB3aGljaCBvbmVzIGNhbiB1c2UgTlVMTC1BVVRIIFRMViAodW4tYXV0aGVudGljYXRl ZCBmcmFtZXMpLg0KPG86cD48L286cD48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi4yNWluIj48aT5BbmQgYWRkaXRpb25hbCBjb21tZW50czo8bzpwPjwv bzpwPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6Ljc1aW47dGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwzIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxpPiZx dW90O0ZvciBleGFtcGxlLCB0aGUgdHdvIGVuZHMgY2FuIGRlY2lkZSB0aGF0IEJGRCBmcmFtZXMg dGhhdCBpbmRpY2F0ZSBhIHN0YXRlIGNoYW5nZSBzaG91bGQgYmUgYXV0aGVudGljYXRlZCBhbmQg ZW5hYmxlIGF1dGhlbnRpY2F0aW9uIG9uIHRob3NlIGZyYW1lcyBvbmx5LiZxdW90OzxvOnA+PC9v OnA+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouMjVp biI+PGk+SSBkb24ndCB0aGluayB0aGF0IG5vZGVzICZxdW90O2RlY2lkZSZxdW90OyBhbnl0aGlu ZyBidXQgYXJlIGNvbmZpZ3VyZWQgdG8gZG8gc29tZXRoaW5nLjxvOnA+PC9vOnA+PC9pPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+W0FNXSBJIGFncmVlIHRoYXQgdGhlIGxhbmd1YWdlIGlzIG5vdCBhY2N1cmF0 ZS4gV2XigJlsbCBjaGFuZ2UgaXQgaW4gdGhlIG5leHQgcmV2aXNpb24uIFRoZSBpbnRlbnRpb24g aXMgdG8gdXNlIGluZGljYXRlIGNvbmZpZ3VyYXRpb24gcmF0aGVyIHRoYW4gbmVnb3RpYXRpb24u DQo8bzpwPjwvbzpwPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 Ljc1aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMSBsZm8zIj4NCjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxpPiZxdW90O0lmIHRoZSB0d28gZW5kcyBoYXZlIG5vdCBwcmV2aW91c2x5IG5lZ290aWF0 ZWQgd2hpY2ggZnJhbWVzIHRoZXkgd2lsbCB0cmFuc21pdCBvciByZWNlaXZlIHdpdGggYXV0aGVu dGljYXRpb24gZW5hYmxlZCAuLi4mcXVvdDs8bzpwPjwvbzpwPjwvaT48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW4iPjxpPkkgY291bGRuJ3QgZmluZCB0 aGUgbmVnb3RpYXRpb24gcHJvY2VkdXJlIGJlaW5nIGRlc2NyaWJlZCBpbiB0aGUgZG9jdW1lbnQu IElzIGl0IG91dC1vZi1iYW5kLCBpLmUuIGJ5IGNvbnRyb2wgb3IgbWFuYWdlbWVudCBwbGFuZSwg bm90IHBhcnQgb2YgdGhpcyBCRkQgZW5oYW5jZW1lbnQ/PG86cD48L286cD48L2k+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHU+PG86cD48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5v bmUiPiZuYnNwOzwvc3Bhbj48L286cD48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ W0FNXSBUaGUgbGFuZ3VhZ2Ugc2hvdWxkIGluZGljYXRlIGNvbmZpZ3VyYXRpb24gaW5zdGVhZCBv ZiBuZWdvdGlhdGlvbi4NCjxvOnA+PC9vOnA+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDouNzVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwx IGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7Ctzxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PGk+JnF1b3Q7VGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhlIHBlcmlv ZGljIGF1dGhlbnRpY2F0aW9uIGludGVydmFsIGZvciBCRkQgQ0MgVVAgZnJhbWVzIGlzIGFuIG9w ZW4gaXNzdWUuJnF1b3Q7PG86cD48L286cD48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi4yNWluIj48aT5JIGJlbGlldmUgdGhhdCB0aGlzIG9wZW4gaXNz dWUgbXVzdCBiZSByZXNvbHZlZCBpbiB0aGUgZGVmaW5pdGl2ZSBtYW5uZXIgYmVmb3JlIHRoZSBk cmFmdCBtb3ZlZCB0byBXR0xDLjxvOnA+PC9vOnA+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouMjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj5bQU1dIFRoaXMgbGluZSBzaG91bGQgYmUgcmVtb3ZlZCBhbmQg dGhlIHByZWNlZGluZyB0ZXh0IHNob3VsZCBpbmRpY2F0ZSB0aGF0IHRoZSBwYXJhbWV0ZXJzIGZv ciBhdXRoZW50aWNhdGlvbiBzaG91bGQgYmUgY29uZmlndXJlZCBvbiB0aGUgc2Vzc2lvbiBlbmQt cG9pbnRzLg0KPG86cD48L286cD48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxicj4NCkFzaGVz aDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+R3JlZyBNaXJza3kg Jmx0O2dyZWdpbWlyc2t5QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBB cHJpbCAyLCAyMDE4IGF0IDEyOjM0IFBNPGJyPg0KPGI+VG86IDwvYj5Bc2hlc2ggTWlzaHJhICZs dDttaXNocmEuYXNoZXNoQG91dGxvb2suY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+SmVmZnJleSBI YWFzICZsdDtqaGFhc0BwZnJjLm9yZyZndDssICZxdW90O3J0Zy1iZmRAaWV0Zi5vcmcmcXVvdDsg Jmx0O3J0Zy1iZmRAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBXR0xDIEJG RCBBdXRoZW50aWNhdGlvbiBEcmFmdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsT3JpZ2luYWxCb2R5Ij5I aSBBc2hlaCwgPG86cD48L286cD48L2E+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPnRoYW5rIHlvdSBm b3IgdGFraW5nIHRpbWUgdG8gcmV2aWV3IHRoZSBtaW51dGVzIGZyb20gQkZEIFdHIG1lZXRpbmcg YXQgSUVURi05OC4gSSBkb24ndCB0aGluayB0aGF0IHdlIGhhZCBlbm91Z2ggdGltZSB0byBkaXNj dXNzIGluIGRldGFpbHMgbXkgcXVlc3Rpb246PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5HcmVnIE1pcnNreTogT25lIG9mIHRoZSBwb3NzaWJs ZSBtb2RlcyB3aGVuIHRoZSBzZXNzaW9uIGlzIHVwIGlzIHRvIHVzZSBhdXRoZW50aWNhdGlvbiB3 aXRoIHBlcmlvZGljIHRpbWVyIHRyaWdnZXI/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkknZCBicmVhayBpdCBpbnRvIGNvdXBs ZSBtb3JlIHNwZWNpZmljIHF1ZXN0aW9uczoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PmNhbiB0aGUgcGVyaW9kaWMgT3B0aW1pemVkIEF1dGhlbnRpY2F0aW9uIG1vZGUgYmUgdXNlZCB3 aXRob3V0IGF1dGhvcml6YXRpb24gbyBzdGF0ZSBjaGFuZ2VzOzxvOnA+PC9vOnA+PC9zcGFuPjwv bGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5pZiB0aGUgYW5zd2VyIHRv IHRoZSBwcmV2aW91cyBxdWVzdGlvbiAmcXVvdDt5ZXMmcXVvdDssIHRoZW4gd2hlbiB0aGUgZmly c3QgYXV0aG9yaXplZCBCRkQgY29udHJvbCBwYWNrZXQgbXVzdCBiZSB0cmFuc21pdHRlZCBieSB0 aGUgc3lzdGVtOzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij5kb2VzIHRoZSBCRkQgc3RhdGUgbWFjaGluZSAoc2VjdGlvbiA2LjIgUkZD IDU4ODApIGNoYW5nZXMgcmVzdWx0aW5nIGZyb20gaW50cm9kdWN0aW9uIG9mIHBlcmlvZGljIG9w dGltaXplZCBhdXRoZW50aWNhdGlvbiBtb2RlOzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPkFuZCBhZGRpdGlvbmFsIGNvbW1lbnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzIiPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+JnF1b3Q7Rm9yIGV4YW1wbGUsIHRoZSB0d28gZW5kcyBjYW4gZGVjaWRl IHRoYXQgQkZEIGZyYW1lcyB0aGF0IGluZGljYXRlIGEgc3RhdGUgY2hhbmdlIHNob3VsZCBiZSBh dXRoZW50aWNhdGVkIGFuZCBlbmFibGUgYXV0aGVudGljYXRpb24gb24gdGhvc2UgZnJhbWVzIG9u bHkuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjMwLjBwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5J IGRvbid0IHRoaW5rIHRoYXQgbm9kZXMgJnF1b3Q7ZGVjaWRlJnF1b3Q7IGFueXRoaW5nIGJ1dCBh cmUgY29uZmlndXJlZCB0byBkbyBzb21ldGhpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwyIGxldmVsMSBsZm8zIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPiZxdW90O0lmIHRoZSB0d28gZW5kcyBoYXZlIG5vdCBwcmV2aW91 c2x5IG5lZ290aWF0ZWQgd2hpY2ggZnJhbWVzIHRoZXkgd2lsbCB0cmFuc21pdCBvciByZWNlaXZl IHdpdGggYXV0aGVudGljYXRpb24gZW5hYmxlZCAuLi4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48 L2xpPjwvdWw+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi1y aWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkkgY291bGRuJ3QgZmluZCB0aGUgbmVnb3RpYXRp b24gcHJvY2VkdXJlIGJlaW5nIGRlc2NyaWJlZCBpbiB0aGUgZG9jdW1lbnQuIElzIGl0IG91dC1v Zi1iYW5kLCBpLmUuIGJ5IGNvbnRyb2wgb3IgbWFuYWdlbWVudCBwbGFuZSwgbm90IHBhcnQgb2Yg dGhpcyBCRkQgZW5oYW5jZW1lbnQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwxIGxldmVsMSBsZm80Ij4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPiZxdW90O1RoZSBjb25maWd1cmF0aW9uIG9mIHRoZSBwZXJpb2RpYyBhdXRoZW50 aWNhdGlvbiBpbnRlcnZhbCBmb3IgQkZEIENDIFVQIGZyYW1lcyBpcyBhbiBvcGVuIGlzc3VlLiZx dW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tbGVmdDozMC4wcHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+SSBiZWxp ZXZlIHRoYXQgdGhpcyBvcGVuIGlzc3VlIG11c3QgYmUgcmVzb2x2ZWQgaW4gdGhlIGRlZmluaXRp dmUgbWFubmVyIGJlZm9yZSB0aGUgZHJhZnQgbW92ZWQgdG8gV0dMQy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlJlZ2FyZHMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+R3JlZzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPk9uIFN1biwgQXByIDEsIDIwMTggYXQgNjoxMSBQTSwg QXNoZXNoIE1pc2hyYSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptaXNocmEuYXNoZXNoQG91 dGxvb2suY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+bWlzaHJhLmFzaGVzaEBvdXRsb29rLmNvbTwvc3Bhbj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXYgaWQ9Im1fNTgxOTIyMjIzMjU2 NTk1OTg2MGRpdnRhZ2RlZmF1bHR3cmFwcGVyIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkhpIEdyZWcs Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGlu O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Zb3Vy IHF1ZXN0aW9ucyZuYnNwO2luIHRoZSBJRVRGLTk4IG1lZXRpbmcgc2VlbWVkIHRvIHN0ZW0gZnJv bSB0aGUgY2hhbGxlbmdlcyBvZiBhdXRoZW50aWNhdGlvbiBpbiBmYXN0IEJGRCBzZXNzaW9ucyBh dCBoaWdoIHNjYWxlLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+SSdsbCBhZGRyZXNzIHRoZSBpc3N1ZSBpbiB0d28gcGFydHMgLSZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+JnF1b3Q7SXMgdGhlcmUg YSBuZWVkIGZvciBhdXRoZW50aWNhdGVkIEJGRCBzZXNzaW9ucz8mcXVvdDsgLSBJIGJlbGlldmUg d2UgY2FuIGFsbCBhZ3JlZSB0aGF0IHRoZXJlIGlzIGEgY2xlYXIgbWFya2V0IG5lZWQgZm9yIEJG RCBhdXRoZW50aWNhdGlvbi4NCiBTbyB3ZSBzaG91bGQgZGlyZWN0IHRoZSBjb252ZXJzYXRpb24g dG8gdGhlIHdheSBpbiB3aGljaCB3ZSBjYW4gYWRkcmVzcyB0aGlzIHJlcXVpcmVtZW50LiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+JnF1b3Q7SG93 IGNhbiBhdXRoZW50aWNhdGlvbiB3b3JrIGF0IHNjYWxlPyZxdW90OyAtIEJGRCBhdXRoZW50aWNh dGlvbiBwdXRzIHNpZ25pZmljYW50IHN0cmVzcyBvbiB0aGUgc3lzdGVtIGFuZCBhIG5vbi1tZXRp Y3Vsb3VzIG1ldGhvZA0KIGFsbGV2aWF0ZXMgdGhpcyBjb21wdXRhdGlvbiBwcmVzc3VyZS4gVGhh dCdzIHRoZSBwcmVtaXNlIG9mIHRoaXMgZHJhZnQgYXMgaXQgcHJlc2VudHMgYSB3YXkgdG8gcmVs aWV2ZSB0aGUgQkZEIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50IGJhc2VkIG9uIHRoZSBjYXBh YmlsaXR5IG9mIHRoZSBzeXN0ZW0gdG8gaGFuZGxlIHRoZSBhZGRpdGlvbmFsIHN0cmVzcyB3aGlj aCBtYWludGFpbmluZyB0aGUgc2Vzc2lvbiZuYnNwO3NjYWxlLiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+VGhlcmUgYXJlIHNvbWUgQkZEIHN5c3Rl bXMgaW4gdGhlIG1hcmtldCwgd2hpY2ggYXJlIG5vdCBjb25kdWNpdmUgdG8gYXV0aGVudGljYXRp b24gKGV2ZW4gdGhlIG9wdGltaXplZCBtZXRob2QpLCB3aGVyZSB0aGUgaW1wZWRpbWVudA0KIHRv IGF1dGhlbnRpY2F0aW9uIGlzIGR1ZSB0byB0aGUgaW1wbGVtZW50YXRpb24gZGV0YWlscyBzcGVj aWZpYyB0byB0aGF0IHZlbmRvciBvciBzeXN0ZW0uJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9z cGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bh bj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5JIGJlbGlldmUgYWxsIHRoZXNlIGlzc3VlcyB3ZXJl IGFkZHJlc3MgZHVyaW5nIHRoZSBtZWV0aW5nLiBBcmUgdGhlcmUgYW55IHNwZWNpZmljIHF1ZXN0 aW9ucyB0aGF0IEkgbWlzc2VkIG9yIGFueSByZWNvbW1lbmRhdGlvbnMNCiBmb3IgdGhlIG1ldGhv ZCBpbiB3aGljaCB0aGUgcmVxdWlyZW1lbnRzIGNhbiBiZSBhZGRyZXNzZWQ/Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5UaGFua3MsPG86cD48L286 cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkFzaGVzaDxvOnA+PC9vOnA+ PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4NCjxociBzaXplPSIwIiB3aWR0aD0iMTAwJSIgYWxpZ249 ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGlkPSJtXzU4MTkyMjIyMzI1NjU5NTk4NjBk aXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJv bTo8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiBSdGctYmZkICZsdDs8L3NwYW4+PC9z cGFuPjxhIGhyZWY9Im1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5ydGctYmZk LWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsNCiBvbiBiZWhhbGYgb2Yg R3JlZyBNaXJza3kgJmx0Ozwvc3Bhbj48L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5 QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvc3Bhbj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWFyY2ggMjksIDIwMTggNDowOTozMiBB TTxicj4NCjxiPlRvOjwvYj4gSmVmZnJleSBIYWFzPGJyPg0KPGI+Q2M6PC9iPiA8L3NwYW4+PC9z cGFuPjxhIGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+cnRnLWJmZEBpZXRmLm9y Zzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBXR0xDIEJGRCBB dXRoZW50aWNhdGlvbiBEcmFmdHM8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+RGVhciBXRyBDaGFpcnMsIGV0LiBhbCwm bmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5JIGNhbm5vdCBz dXBwb3J0IFdHIExDIGZvciZuYnNwO2RyYWZ0LWlldGYtYmZkLW9wdGltaXppbmctYXV0aGVudGlj YXRpb24gYXMgbXkgY29tbWVudHMgYXQNCjwvc3Bhbj48YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL21lZXRpbmcvOTgvbWF0ZXJpYWxzL21pbnV0ZXMtOTgtYmZkLTAwIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ QkZEIFdHIG1lZXRpbmcgZGF0aW5nIGJhY2sgdG8gSUVURi05ODwvc3Bhbj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwO3N0aWxsDQogbm90IGhhdmUgYmVl biBhZGRyZXNzZWQgbm9yIGV2ZW4gdGhlcmUgd2FzIGFuIGF0dGVtcHQgdG8gYWRkcmVzcy4gQXMg SSd2ZSBhc2tlZCB0byBjbGFyaWZ5IGltcGFjdCBvZiB0aGUgcHJvcG9zZWQgbWVjaGFuaXNtLCBw YXJ0aWN1bGFybHkgcGVyaW9kaWMgYXV0aGVudGljYXRpb24sIG9uIHRoZSBCRkQgU3RhdGUgTWFj aGluZSwgSSdkIHBvaW50IHRoYXQgdGhlIHByb3Bvc2VkIG1lY2hhbmlzbSBkaXJlY3RseSBhZmZl Y3RzIEJGRCBzZWN1cml0eQ0KIGFzIGRpc2N1c3NlZCBpbiBSRkMgNTg4MCBhbmQgdGhlIHNlY3Rp b24gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgaW4gdGhlIGRvY3VtZW50LCBpbiBteSB2aWV3LCBk b2VzIG5vdCBhZGVxdWF0ZWx5IHJlZmxlY3RzIHRoYXQgYW5kIGRvZXNuJ3QgZXhwbGFpbiBob3cg dGhlIHNlY3VyaXR5IG9mIHRoZSBCRkQgc2Vzc2lvbiBtYWludGFpbmVkIHdoZW4gdGhlIHBlcmlv ZGljIGF1dGhlbnRpY2F0aW9uIGlzIGluIHVzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPkdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij5PbiBXZWQsIE1hciAyOCwgMjAxOCBhdCA3OjM4IFBNLCBKZWZmcmV5IEhhYXMgJmx0 Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86amhhYXNAcGZyYy5vcmciIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5qaGFhc0BwZnJjLm9y Zzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDsN CiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5Xb3JraW5nIEdyb3VwLDxicj4NCjxicj4NClRoZSBh dXRob3JzIG9mIHRoZSBmb2xsb3dpbmcgV29ya2luZyBHcm91cCBkcmFmdHMgaGF2ZSByZXF1ZXN0 ZWQ8YnI+DQpXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiB0aGUgZm9sbG93aW5nIGRvY3VtZW50 czo8YnI+DQo8YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtYmZkLXNlY3VyZS1zZXF1ZW5jZS1udW1iZXJzLTAxIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLXNlY3VyZS1zZXF1ZW5jZS1udW1iZXJz LTAxPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGJy Pg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWJmZC1vcHRpbWl6aW5nLWF1dGhlbnRpY2F0aW9uLTA0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLW9wdGltaXppbmctYXV0aGVudGljYXRpb24tMDQ8L3Nw YW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwv YT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+DQo8L3Nw YW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLXN0 YWJpbGl0eS0wMSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJm ZC1zdGFiaWxpdHktMDE8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij48YnI+DQo8YnI+DQpHaXZlbiB0aGUgb3ZlcmxhcCBvZiBmdW5jdGlvbmFsaXR5LCBX R0xDIHdpbGwgY29uY2x1ZGUgZm9yIHRoZSBidW5kbGU8YnI+DQpzaW11bHRhbmVvdXNseS48YnI+ DQo8YnI+DQpBdXRob3JzLCBwbGVhc2UgcG9zaXRpdmVseSBhY2tub3dsZWRnZSB3aGV0aGVyIG9y IG5vdCB5b3Uga25vdyBhYm91dCBhbnkgSVBSPGJyPg0KZm9yIHlvdXIgZG9jdW1lbnRzLiZuYnNw OyBQcm9ncmVzc2lvbiBvZiB0aGUgZG9jdW1lbnQgd2lsbCBub3QgYmUgZG9uZSB3aXRob3V0PGJy Pg0KdGhhdCBzdGF0ZW1lbnQuPGJyPg0KPGJyPg0KTGFzdCBjYWxsIHdpbGwgY29tcGxldGUgb24g QXByaWwgMjAuPGJyPg0KPGJyPg0KLS0gSmVmZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFu Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_36BBC37154A243B0859769782CFFD5E9outlookcom_-- From nobody Mon Apr 9 11:10:52 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 692C41273B1 for ; Mon, 9 Apr 2018 10:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[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=outlook.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 dr43b7JR-dzB for ; Mon, 9 Apr 2018 10:51:21 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-oln040092005028.outbound.protection.outlook.com [40.92.5.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719F5127286 for ; Mon, 9 Apr 2018 10:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=R0MytmSjnHe/MdENxaM2Bq+4tYNthYQXZ0wn3Thfxyk=; b=BaFfPlGiHqpUD8HaxDwBZDtFFxg7u9ZJZxLhXWS0OVWXBNwfskF5Q42qRqZGSafJrr9wd9bMd+xXT5PAx8uWmJIgJqQEVwykSSIB00gAs/KAnPxrqikOjDbdVku7Cr+iMwl9iGt7xESTumMGDjVCgUGAN4Y3nytfsVFFo1TAEMJZ+kWcnB5L+l3421e/rrtFJ+fucyzH1smNoavTqPdyMLCFmZ2ttrImkkYcGxXGN0wb1xBN7pa/ciQ5TojBh0KCprUYgQu96bIxEq1U+RKJc7ITBlwqxT6bnFlH95KbhjgX7JoZqWvwJavceAN94I+7e8R7ywq2+i5YrOI2C2lyDQ== Received: from CY1NAM02FT050.eop-nam02.prod.protection.outlook.com (10.152.74.56) by CY1NAM02HT004.eop-nam02.prod.protection.outlook.com (10.152.75.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.653.8; Mon, 9 Apr 2018 17:51:20 +0000 Received: from MW2PR0102MB3561.prod.exchangelabs.com (10.152.74.55) by CY1NAM02FT050.mail.protection.outlook.com (10.152.75.65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.653.8 via Frontend Transport; Mon, 9 Apr 2018 17:51:20 +0000 Received: from MW2PR0102MB3561.prod.exchangelabs.com ([fe80::9dbc:5290:a6b4:40c]) by MW2PR0102MB3561.prod.exchangelabs.com ([fe80::9dbc:5290:a6b4:40c%13]) with mapi id 15.20.0653.012; Mon, 9 Apr 2018 17:51:20 +0000 From: Ashesh Mishra To: Greg Mirsky CC: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: WGLC BFD Authentication Drafts Thread-Topic: WGLC BFD Authentication Drafts Thread-Index: AQHTxrM8j4pe2ek2RUW1GIkZ+QU4DqPnD20AgAT20DKAAa1ggIABNeIAgADi1gCACIenAA== Date: Mon, 9 Apr 2018 17:51:20 +0000 Message-ID: <350B7795-76FC-4E7A-9532-2F3CF0577C31@outlook.com> References: <20180328163856.GB3126@pfrc.org> <36BBC371-54A2-43B0-8597-69782CFFD5E9@outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:67036BDBD232779BD6E38BF50A54BFC56907945AC2304F7A446819A9446AC48C; UpperCasedChecksum:A298C157B251DA960F0E2C695F16FC2C2FD0A5E437D8B24171E979E3E7311622; SizeAsReceived:7359; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [PjYG5CcGpVWnTsJbPA9UMsJw5zwwSJbO] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1NAM02HT004; 7:z9xchqRdAcvZQiI0wOhQeweJfkSRDLLAgK9fxheO02zIzVuomIuDgLYuxT5L03x4OiGLJGU/5UEfxilhpUBZCWUZ97qgIFo99/7Mu3VWJ9to9DNL7o2l0S/D1JcyHotGEI32l0XZgD3F8K5ndF6yjcjIcQxA5egGDS8vutbEdEG2vbfMBuUNk/Gf31JzDJ66nSwUWnYkdKxcQ5EIMBxwH8e+5KRQH4GnOO+7xdrP0AEE+C+it+Ankig7dwL3ZzGF x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:CY1NAM02HT004; x-ms-traffictypediagnostic: CY1NAM02HT004: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:CY1NAM02HT004; BCL:0; PCL:0; RULEID:; SRVR:CY1NAM02HT004; x-forefront-prvs: 0637FCE711 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:CY1NAM02HT004; H:MW2PR0102MB3561.prod.exchangelabs.com; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: aRXTMigVwPyuFzhGfvCy4LkApI3+eTXoJOK/CnsrE74maU1ubUdNyu6L4EQTcBfUU1fJQmvZARN5kgm9S+P1UV/2g1oHEg4W6RjUfOzDCqfvmBb24Nv3YGibIqnA5kqgvTBqWhIk90o+JOIz6THyibbvZPvZXkBxS8150Z95jFX8kuVVCyokXD2ISmOeu43W Content-Type: multipart/alternative; boundary="_000_350B779576FC4E7A95322F3CF0577C31outlookcom_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 51e34dc1-f9b3-4499-0f18-08d59e428063 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 51e34dc1-f9b3-4499-0f18-08d59e428063 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2018 17:51:20.1017 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1NAM02HT004 Archived-At: X-Mailman-Approved-At: Mon, 09 Apr 2018 11:10:50 -0700 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: Mon, 09 Apr 2018 17:51:24 -0000 --_000_350B779576FC4E7A95322F3CF0577C31outlookcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KV2hhdCBJIG1lYW50IHRvIHNheSB3YXMgdGhhdCB0aGUgc3RhdGUgbWFjaGlu ZSByZW1haW5zIHRoZSBzYW1lIGFzIGluIHRoZSBjYXNlIG9mIDU4ODAgYXV0aGVudGljYXRpb24u IElmIGFuIGF1dGhlbnRpY2F0aW9uIGZyYW1lIGZhaWxzIHZhbGlkYXRpb24gdGhlbiB0aGUgc2Vz c2lvbiBnb2VzIGRvd24gcmVnYXJkbGVzcyBvZiBnb29kIE9QRVItVVAgZnJhbWVzIChhdXRoZW50 aWNhdGlvbiBvciBub3JtYWwpIGJlZm9yZSBvciBhZnRlciB0aGF0IGZyYW1lLiBTaW5jZSB0aGUg YmVoYXZpb3IgaW4gNTg4MCBkb2VzIG5vdCByZXF1aXJlIGFueSBtb3JlIHRoYW4gMSBmcmFtZSB0 byBmYWlsIHZhbGlkYXRpb24sIHRoZSBtZWNoYW5pc20gd29ya3MgYXMtaXMgaW4gdGhlIG5ldyBw cm9wb3NhbC4gT25jZSB0aGUgc2Vzc2lvbiBpcyBkb3duLCBhbGwgZnJhbWVzIG5lZWQgdG8gYmUg YXV0aGVudGljYXRlZCB0byBicmluZyB0aGUgc2Vzc2lvbiB1cCBzbyBhZ2FpbiwgdGhlIHNlc3Np b24gY2Fu4oCZdCBjb21lIGJhY2sgdXAganVzdCBiZWNhdXNlIHRoZSBmcmFtZSB0aGF0IGZhaWxl ZCB2YWxpZGF0aW9uIGlzIGZvbGxvd2VkIGJ5IGEgc3RyZWFtIG9mIHVuYXV0aGVudGljYXRlZCBm cmFtZXMuDQoNCkhvcGUgdGhhdCBhZGRyZXNzZXMgdGhlIGdhcCB0aGF0IHlvdSBwcmVzZW50ZWQu DQoNCkFzaGVzaA0KDQpGcm9tOiBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPg0K RGF0ZTogVHVlc2RheSwgQXByaWwgMywgMjAxOCBhdCA4OjM1IFBNDQpUbzogQXNoZXNoIE1pc2hy YSA8bWlzaHJhLmFzaGVzaEBvdXRsb29rLmNvbT4NCkNjOiBKZWZmcmV5IEhhYXMgPGpoYWFzQHBm cmMub3JnPiwgInJ0Zy1iZmRAaWV0Zi5vcmciIDxydGctYmZkQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFdHTEMgQkZEIEF1dGhlbnRpY2F0aW9uIERyYWZ0cw0KDQpIaSBBc2hlaCwNCnRoYW5rIHlv dSBmb3IgdGhlIGRldGFpbGVkIHJlc3BvbnNlIHRvIG15IHF1ZXN0aW9ucyBhbmQgY29uc2lkZXJh dGlvbiBvZiBteSBjb21tZW50cy4NCkkgdGhpbmsgSSBjYW5ub3QgYWdyZWUgdGhhdCB0aGUgQkZE IHN0YXRlIG1hY2hpbmUgcmVtYWlucyB1bmNoYW5nZWQgaWYgb3B0aW1pemVkIEJGRCBhdXRoZW50 aWNhdGlvbiBpcyBpbiBwZXJpb2RpYyBtb2RlLiBMZXQncyBjb25zaWRlciBjYXNlIHdoZW4gb25s eSBldmVyeSA1dGggQkZEIGNvbnRyb2wgcGFja2V0IGlzIGF1dGhlbnRpY2F0ZWQgd2hlbiB0aGUg c2Vzc2lvbiBpcyBpbiBVcCBzdGF0ZS4gV2hhdCBoYXBwZW5zIGlmIGZyb20gc29tZSBtb21lbnQg ZXZlcnkgYXV0aGVudGljYXRlZCBwYWNrZXQgZmFpbHMgdG8gYmUgdmFsaWRhdGVkPyBXb3VsZCB0 aGUgc2Vzc2lvbiBnbyB0byBEb3duIHN0YXRlPyBCdXQgYWxsIHVuYXV0aGVudGljYXRlZCBCRkQg Y29udHJvbCBwYWNrZXRzIHBhc3MgdGhlIHZhbGlkYXRpb24gY2hlY2sgYW5kIHNpbmNlIG9ubHkg b25lIHBhY2tldCBzZWVtcyB0byBtaXNzIHZhbGlkYXRpb24gdGhlIHNlc3Npb24sIGlmIHRoZSBz dGF0ZSBtYWNoaW5lIHJlbWFpbnMgdW5jaGFuZ2VkLCB3aWxsIHN0YXkgVXAuDQoNCkRvIHlvdSBz ZWUgdGhpcyBhcyBwbGF1c2libGUgc2NlbmFyaW8/DQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIFR1 ZSwgQXByIDMsIDIwMTggYXQgMTE6MDMgQU0sIEFzaGVzaCBNaXNocmEgPG1pc2hyYS5hc2hlc2hA b3V0bG9vay5jb208bWFpbHRvOm1pc2hyYS5hc2hlc2hAb3V0bG9vay5jb20+PiB3cm90ZToNClRo YW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24sIEdyZWcuDQoNCkhlcmUgYXJlIG15IHRob3VnaHRz IG9uIHRoZSBpc3N1ZXM6DQoNCkknZCBicmVhayBpdCBpbnRvIGNvdXBsZSBtb3JlIHNwZWNpZmlj IHF1ZXN0aW9uczoNCuKAoiAgICAgICAgIGNhbiB0aGUgcGVyaW9kaWMgT3B0aW1pemVkIEF1dGhl bnRpY2F0aW9uIG1vZGUgYmUgdXNlZCB3aXRob3V0IGF1dGhvcml6YXRpb24gbyBzdGF0ZSBjaGFu Z2VzOw0K4oCiICAgICAgICAgaWYgdGhlIGFuc3dlciB0byB0aGUgcHJldmlvdXMgcXVlc3Rpb24g InllcyIsIHRoZW4gd2hlbiB0aGUgZmlyc3QgYXV0aG9yaXplZCBCRkQgY29udHJvbCBwYWNrZXQg bXVzdCBiZSB0cmFuc21pdHRlZCBieSB0aGUgc3lzdGVtOw0K4oCiICAgICAgICAgZG9lcyB0aGUg QkZEIHN0YXRlIG1hY2hpbmUgKHNlY3Rpb24gNi4yIFJGQyA1ODgwKSBjaGFuZ2VzIHJlc3VsdGlu ZyBmcm9tIGludHJvZHVjdGlvbiBvZiBwZXJpb2RpYyBvcHRpbWl6ZWQgYXV0aGVudGljYXRpb24g bW9kZTsNCltBTV0gVGhlIG9wdGltaXplZCBhdXRoZW50aWNhdGlvbiBjYW4gYmUgdXNlZCB3aXRo b3V0IHN0YXRlIGNoYW5nZXMgYW5kIHRoZSBmaXJzdCBhdXRoIHBhY2tldCB3aWxsIGJlIHRoZSBE T1dOIHN0YXRlIGZyYW1lIHRvIGtpY2stb2ZmIHRoZSBzZXNzaW9uIG5lZ290aWF0aW9uIGFzIHRo ZSBwcm9wb3NhbCBzdWdnZXN0cyB0aGF0IGFsbCBET1dOIHN0YXRlIGZyYW1lcyBhcmUgYXV0aGVu dGljYXRlZC4gVGhlIHN0YXRlIG1hY2hpbmUgZG9lcyBub3QgY2hhbmdlIGluIHRoaXMgcHJvcG9z YWwgYnV0IGl0IG9ubHkgaW5kaWNhdGVzIHdoaWNoIGZyYW1lcyBzaG91bGQgYmUgYXV0aGVudGlj YXRlZCBhbmQgd2hpY2ggb25lcyBjYW4gdXNlIE5VTEwtQVVUSCBUTFYgKHVuLWF1dGhlbnRpY2F0 ZWQgZnJhbWVzKS4NCkFuZCBhZGRpdGlvbmFsIGNvbW1lbnRzOg0K4oCiICAgICAgICAgIkZvciBl eGFtcGxlLCB0aGUgdHdvIGVuZHMgY2FuIGRlY2lkZSB0aGF0IEJGRCBmcmFtZXMgdGhhdCBpbmRp Y2F0ZSBhIHN0YXRlIGNoYW5nZSBzaG91bGQgYmUgYXV0aGVudGljYXRlZCBhbmQgZW5hYmxlIGF1 dGhlbnRpY2F0aW9uIG9uIHRob3NlIGZyYW1lcyBvbmx5LiINCkkgZG9uJ3QgdGhpbmsgdGhhdCBu b2RlcyAiZGVjaWRlIiBhbnl0aGluZyBidXQgYXJlIGNvbmZpZ3VyZWQgdG8gZG8gc29tZXRoaW5n Lg0KDQpbQU1dIEkgYWdyZWUgdGhhdCB0aGUgbGFuZ3VhZ2UgaXMgbm90IGFjY3VyYXRlLiBXZeKA mWxsIGNoYW5nZSBpdCBpbiB0aGUgbmV4dCByZXZpc2lvbi4gVGhlIGludGVudGlvbiBpcyB0byB1 c2UgaW5kaWNhdGUgY29uZmlndXJhdGlvbiByYXRoZXIgdGhhbiBuZWdvdGlhdGlvbi4NCuKAoiAg ICAgICAgICJJZiB0aGUgdHdvIGVuZHMgaGF2ZSBub3QgcHJldmlvdXNseSBuZWdvdGlhdGVkIHdo aWNoIGZyYW1lcyB0aGV5IHdpbGwgdHJhbnNtaXQgb3IgcmVjZWl2ZSB3aXRoIGF1dGhlbnRpY2F0 aW9uIGVuYWJsZWQgLi4uIg0KSSBjb3VsZG4ndCBmaW5kIHRoZSBuZWdvdGlhdGlvbiBwcm9jZWR1 cmUgYmVpbmcgZGVzY3JpYmVkIGluIHRoZSBkb2N1bWVudC4gSXMgaXQgb3V0LW9mLWJhbmQsIGku ZS4gYnkgY29udHJvbCBvciBtYW5hZ2VtZW50IHBsYW5lLCBub3QgcGFydCBvZiB0aGlzIEJGRCBl bmhhbmNlbWVudD8NCg0KW0FNXSBUaGUgbGFuZ3VhZ2Ugc2hvdWxkIGluZGljYXRlIGNvbmZpZ3Vy YXRpb24gaW5zdGVhZCBvZiBuZWdvdGlhdGlvbi4NCuKAoiAgICAgICAgICJUaGUgY29uZmlndXJh dGlvbiBvZiB0aGUgcGVyaW9kaWMgYXV0aGVudGljYXRpb24gaW50ZXJ2YWwgZm9yIEJGRCBDQyBV UCBmcmFtZXMgaXMgYW4gb3BlbiBpc3N1ZS4iDQpJIGJlbGlldmUgdGhhdCB0aGlzIG9wZW4gaXNz dWUgbXVzdCBiZSByZXNvbHZlZCBpbiB0aGUgZGVmaW5pdGl2ZSBtYW5uZXIgYmVmb3JlIHRoZSBk cmFmdCBtb3ZlZCB0byBXR0xDLg0KDQpbQU1dIFRoaXMgbGluZSBzaG91bGQgYmUgcmVtb3ZlZCBh bmQgdGhlIHByZWNlZGluZyB0ZXh0IHNob3VsZCBpbmRpY2F0ZSB0aGF0IHRoZSBwYXJhbWV0ZXJz IGZvciBhdXRoZW50aWNhdGlvbiBzaG91bGQgYmUgY29uZmlndXJlZCBvbiB0aGUgc2Vzc2lvbiBl bmQtcG9pbnRzLg0KDQpSZWdhcmRzLA0KQXNoZXNoDQoNCkZyb206IEdyZWcgTWlyc2t5IDxncmVn aW1pcnNreUBnbWFpbC5jb208bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+DQpEYXRlOiBN b25kYXksIEFwcmlsIDIsIDIwMTggYXQgMTI6MzQgUE0NClRvOiBBc2hlc2ggTWlzaHJhIDxtaXNo cmEuYXNoZXNoQG91dGxvb2suY29tPG1haWx0bzptaXNocmEuYXNoZXNoQG91dGxvb2suY29tPj4N CkNjOiBKZWZmcmV5IEhhYXMgPGpoYWFzQHBmcmMub3JnPG1haWx0bzpqaGFhc0BwZnJjLm9yZz4+ LCAicnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4iIDxydGctYmZkQGll dGYub3JnPG1haWx0bzpydGctYmZkQGlldGYub3JnPj4NCg0KU3ViamVjdDogUmU6IFdHTEMgQkZE IEF1dGhlbnRpY2F0aW9uIERyYWZ0cw0KDQpIaSBBc2hlaCwNCnRoYW5rIHlvdSBmb3IgdGFraW5n IHRpbWUgdG8gcmV2aWV3IHRoZSBtaW51dGVzIGZyb20gQkZEIFdHIG1lZXRpbmcgYXQgSUVURi05 OC4gSSBkb24ndCB0aGluayB0aGF0IHdlIGhhZCBlbm91Z2ggdGltZSB0byBkaXNjdXNzIGluIGRl dGFpbHMgbXkgcXVlc3Rpb246DQpHcmVnIE1pcnNreTogT25lIG9mIHRoZSBwb3NzaWJsZSBtb2Rl cyB3aGVuIHRoZSBzZXNzaW9uIGlzIHVwIGlzIHRvIHVzZSBhdXRoZW50aWNhdGlvbiB3aXRoIHBl cmlvZGljIHRpbWVyIHRyaWdnZXI/DQpJJ2QgYnJlYWsgaXQgaW50byBjb3VwbGUgbW9yZSBzcGVj aWZpYyBxdWVzdGlvbnM6DQoNCiAgKiAgIGNhbiB0aGUgcGVyaW9kaWMgT3B0aW1pemVkIEF1dGhl bnRpY2F0aW9uIG1vZGUgYmUgdXNlZCB3aXRob3V0IGF1dGhvcml6YXRpb24gbyBzdGF0ZSBjaGFu Z2VzOw0KICAqICAgaWYgdGhlIGFuc3dlciB0byB0aGUgcHJldmlvdXMgcXVlc3Rpb24gInllcyIs IHRoZW4gd2hlbiB0aGUgZmlyc3QgYXV0aG9yaXplZCBCRkQgY29udHJvbCBwYWNrZXQgbXVzdCBi ZSB0cmFuc21pdHRlZCBieSB0aGUgc3lzdGVtOw0KICAqICAgZG9lcyB0aGUgQkZEIHN0YXRlIG1h Y2hpbmUgKHNlY3Rpb24gNi4yIFJGQyA1ODgwKSBjaGFuZ2VzIHJlc3VsdGluZyBmcm9tIGludHJv ZHVjdGlvbiBvZiBwZXJpb2RpYyBvcHRpbWl6ZWQgYXV0aGVudGljYXRpb24gbW9kZTsNCkFuZCBh ZGRpdGlvbmFsIGNvbW1lbnRzOg0KDQogICogICAiRm9yIGV4YW1wbGUsIHRoZSB0d28gZW5kcyBj YW4gZGVjaWRlIHRoYXQgQkZEIGZyYW1lcyB0aGF0IGluZGljYXRlIGEgc3RhdGUgY2hhbmdlIHNo b3VsZCBiZSBhdXRoZW50aWNhdGVkIGFuZCBlbmFibGUgYXV0aGVudGljYXRpb24gb24gdGhvc2Ug ZnJhbWVzIG9ubHkuIg0KSSBkb24ndCB0aGluayB0aGF0IG5vZGVzICJkZWNpZGUiIGFueXRoaW5n IGJ1dCBhcmUgY29uZmlndXJlZCB0byBkbyBzb21ldGhpbmcuDQoNCiAgKiAgICJJZiB0aGUgdHdv IGVuZHMgaGF2ZSBub3QgcHJldmlvdXNseSBuZWdvdGlhdGVkIHdoaWNoIGZyYW1lcyB0aGV5IHdp bGwgdHJhbnNtaXQgb3IgcmVjZWl2ZSB3aXRoIGF1dGhlbnRpY2F0aW9uIGVuYWJsZWQgLi4uIg0K SSBjb3VsZG4ndCBmaW5kIHRoZSBuZWdvdGlhdGlvbiBwcm9jZWR1cmUgYmVpbmcgZGVzY3JpYmVk IGluIHRoZSBkb2N1bWVudC4gSXMgaXQgb3V0LW9mLWJhbmQsIGkuZS4gYnkgY29udHJvbCBvciBt YW5hZ2VtZW50IHBsYW5lLCBub3QgcGFydCBvZiB0aGlzIEJGRCBlbmhhbmNlbWVudD8NCg0KICAq ICAgIlRoZSBjb25maWd1cmF0aW9uIG9mIHRoZSBwZXJpb2RpYyBhdXRoZW50aWNhdGlvbiBpbnRl cnZhbCBmb3IgQkZEIENDIFVQIGZyYW1lcyBpcyBhbiBvcGVuIGlzc3VlLiINCkkgYmVsaWV2ZSB0 aGF0IHRoaXMgb3BlbiBpc3N1ZSBtdXN0IGJlIHJlc29sdmVkIGluIHRoZSBkZWZpbml0aXZlIG1h bm5lciBiZWZvcmUgdGhlIGRyYWZ0IG1vdmVkIHRvIFdHTEMuDQoNClJlZ2FyZHMsDQpHcmVnDQoN Cg0KT24gU3VuLCBBcHIgMSwgMjAxOCBhdCA2OjExIFBNLCBBc2hlc2ggTWlzaHJhIDxtaXNocmEu YXNoZXNoQG91dGxvb2suY29tPG1haWx0bzptaXNocmEuYXNoZXNoQG91dGxvb2suY29tPj4gd3Jv dGU6DQoNCkhpIEdyZWcsDQoNCg0KDQpZb3VyIHF1ZXN0aW9ucyBpbiB0aGUgSUVURi05OCBtZWV0 aW5nIHNlZW1lZCB0byBzdGVtIGZyb20gdGhlIGNoYWxsZW5nZXMgb2YgYXV0aGVudGljYXRpb24g aW4gZmFzdCBCRkQgc2Vzc2lvbnMgYXQgaGlnaCBzY2FsZS4NCg0KDQoNCkknbGwgYWRkcmVzcyB0 aGUgaXNzdWUgaW4gdHdvIHBhcnRzIC0NCg0KDQoNCiJJcyB0aGVyZSBhIG5lZWQgZm9yIGF1dGhl bnRpY2F0ZWQgQkZEIHNlc3Npb25zPyIgLSBJIGJlbGlldmUgd2UgY2FuIGFsbCBhZ3JlZSB0aGF0 IHRoZXJlIGlzIGEgY2xlYXIgbWFya2V0IG5lZWQgZm9yIEJGRCBhdXRoZW50aWNhdGlvbi4gU28g d2Ugc2hvdWxkIGRpcmVjdCB0aGUgY29udmVyc2F0aW9uIHRvIHRoZSB3YXkgaW4gd2hpY2ggd2Ug Y2FuIGFkZHJlc3MgdGhpcyByZXF1aXJlbWVudC4NCg0KDQoNCiJIb3cgY2FuIGF1dGhlbnRpY2F0 aW9uIHdvcmsgYXQgc2NhbGU/IiAtIEJGRCBhdXRoZW50aWNhdGlvbiBwdXRzIHNpZ25pZmljYW50 IHN0cmVzcyBvbiB0aGUgc3lzdGVtIGFuZCBhIG5vbi1tZXRpY3Vsb3VzIG1ldGhvZCBhbGxldmlh dGVzIHRoaXMgY29tcHV0YXRpb24gcHJlc3N1cmUuIFRoYXQncyB0aGUgcHJlbWlzZSBvZiB0aGlz IGRyYWZ0IGFzIGl0IHByZXNlbnRzIGEgd2F5IHRvIHJlbGlldmUgdGhlIEJGRCBhdXRoZW50aWNh dGlvbiByZXF1aXJlbWVudCBiYXNlZCBvbiB0aGUgY2FwYWJpbGl0eSBvZiB0aGUgc3lzdGVtIHRv IGhhbmRsZSB0aGUgYWRkaXRpb25hbCBzdHJlc3Mgd2hpY2ggbWFpbnRhaW5pbmcgdGhlIHNlc3Np b24gc2NhbGUuDQoNCg0KDQpUaGVyZSBhcmUgc29tZSBCRkQgc3lzdGVtcyBpbiB0aGUgbWFya2V0 LCB3aGljaCBhcmUgbm90IGNvbmR1Y2l2ZSB0byBhdXRoZW50aWNhdGlvbiAoZXZlbiB0aGUgb3B0 aW1pemVkIG1ldGhvZCksIHdoZXJlIHRoZSBpbXBlZGltZW50IHRvIGF1dGhlbnRpY2F0aW9uIGlz IGR1ZSB0byB0aGUgaW1wbGVtZW50YXRpb24gZGV0YWlscyBzcGVjaWZpYyB0byB0aGF0IHZlbmRv ciBvciBzeXN0ZW0uDQoNCg0KDQpJIGJlbGlldmUgYWxsIHRoZXNlIGlzc3VlcyB3ZXJlIGFkZHJl c3MgZHVyaW5nIHRoZSBtZWV0aW5nLiBBcmUgdGhlcmUgYW55IHNwZWNpZmljIHF1ZXN0aW9ucyB0 aGF0IEkgbWlzc2VkIG9yIGFueSByZWNvbW1lbmRhdGlvbnMgZm9yIHRoZSBtZXRob2QgaW4gd2hp Y2ggdGhlIHJlcXVpcmVtZW50cyBjYW4gYmUgYWRkcmVzc2VkPw0KDQoNCg0KVGhhbmtzLA0KDQpB c2hlc2gNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFJ0Zy1iZmQg PHJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3Jn Pj4gb24gYmVoYWxmIG9mIEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb208bWFpbHRv OmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+DQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMjksIDIwMTgg NDowOTozMiBBTQ0KVG86IEplZmZyZXkgSGFhcw0KQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRv OnJ0Zy1iZmRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogV0dMQyBCRkQgQXV0aGVudGljYXRpb24g RHJhZnRzDQoNCkRlYXIgV0cgQ2hhaXJzLCBldC4gYWwsDQpJIGNhbm5vdCBzdXBwb3J0IFdHIExD IGZvciBkcmFmdC1pZXRmLWJmZC1vcHRpbWl6aW5nLWF1dGhlbnRpY2F0aW9uIGFzIG15IGNvbW1l bnRzIGF0IEJGRCBXRyBtZWV0aW5nIGRhdGluZyBiYWNrIHRvIElFVEYtOTg8aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzk4L21hdGVyaWFscy9taW51dGVzLTk4LWJmZC0wMD4g c3RpbGwgbm90IGhhdmUgYmVlbiBhZGRyZXNzZWQgbm9yIGV2ZW4gdGhlcmUgd2FzIGFuIGF0dGVt cHQgdG8gYWRkcmVzcy4gQXMgSSd2ZSBhc2tlZCB0byBjbGFyaWZ5IGltcGFjdCBvZiB0aGUgcHJv cG9zZWQgbWVjaGFuaXNtLCBwYXJ0aWN1bGFybHkgcGVyaW9kaWMgYXV0aGVudGljYXRpb24sIG9u IHRoZSBCRkQgU3RhdGUgTWFjaGluZSwgSSdkIHBvaW50IHRoYXQgdGhlIHByb3Bvc2VkIG1lY2hh bmlzbSBkaXJlY3RseSBhZmZlY3RzIEJGRCBzZWN1cml0eSBhcyBkaXNjdXNzZWQgaW4gUkZDIDU4 ODAgYW5kIHRoZSBzZWN0aW9uIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGluIHRoZSBkb2N1bWVu dCwgaW4gbXkgdmlldywgZG9lcyBub3QgYWRlcXVhdGVseSByZWZsZWN0cyB0aGF0IGFuZCBkb2Vz bid0IGV4cGxhaW4gaG93IHRoZSBzZWN1cml0eSBvZiB0aGUgQkZEIHNlc3Npb24gbWFpbnRhaW5l ZCB3aGVuIHRoZSBwZXJpb2RpYyBhdXRoZW50aWNhdGlvbiBpcyBpbiB1c2UuDQoNClJlZ2FyZHMs DQpHcmVnDQoNCk9uIFdlZCwgTWFyIDI4LCAyMDE4IGF0IDc6MzggUE0sIEplZmZyZXkgSGFhcyA8 amhhYXNAcGZyYy5vcmc8bWFpbHRvOmpoYWFzQHBmcmMub3JnPj4gd3JvdGU6DQpXb3JraW5nIEdy b3VwLA0KDQpUaGUgYXV0aG9ycyBvZiB0aGUgZm9sbG93aW5nIFdvcmtpbmcgR3JvdXAgZHJhZnRz IGhhdmUgcmVxdWVzdGVkDQpXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiB0aGUgZm9sbG93aW5n IGRvY3VtZW50czoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZk LXNlY3VyZS1zZXF1ZW5jZS1udW1iZXJzLTAxDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1iZmQtb3B0aW1pemluZy1hdXRoZW50aWNhdGlvbi0wNA0KaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLXN0YWJpbGl0eS0wMQ0KDQpHaXZlbiB0aGUg b3ZlcmxhcCBvZiBmdW5jdGlvbmFsaXR5LCBXR0xDIHdpbGwgY29uY2x1ZGUgZm9yIHRoZSBidW5k bGUNCnNpbXVsdGFuZW91c2x5Lg0KDQpBdXRob3JzLCBwbGVhc2UgcG9zaXRpdmVseSBhY2tub3ds ZWRnZSB3aGV0aGVyIG9yIG5vdCB5b3Uga25vdyBhYm91dCBhbnkgSVBSDQpmb3IgeW91ciBkb2N1 bWVudHMuICBQcm9ncmVzc2lvbiBvZiB0aGUgZG9jdW1lbnQgd2lsbCBub3QgYmUgZG9uZSB3aXRo b3V0DQp0aGF0IHN0YXRlbWVudC4NCg0KTGFzdCBjYWxsIHdpbGwgY29tcGxldGUgb24gQXByaWwg MjAuDQoNCi0tIEplZmYNCg0KDQoNCg== --_000_350B779576FC4E7A95322F3CF0577C31outlookcom_ Content-Type: text/html; charset="utf-8" Content-ID: <617E599E1884A94F97626B7ADEF09448@prod.exchangelabs.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjQxNzEy ODg1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo1MzEyOTk3OTQ7fQ0KQGxpc3QgbDA6bGV2ZWwx DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MQ0KCXttc28tbGlzdC1pZDoyNTIyMDU1NjE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzQ3 OTI5Njg7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxOTg4MTY5MDIxOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczo1MjkxNjYyMzA7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMw0KCXttc28t bGlzdC1pZDoyMDczMDM3MTgxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNzMzOTc1NTk4O30N CkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhpIEdyZWcsIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IEkgbWVhbnQgdG8gc2F5IHdh cyB0aGF0IHRoZSBzdGF0ZSBtYWNoaW5lIHJlbWFpbnMgdGhlIHNhbWUgYXMgaW4gdGhlIGNhc2Ug b2YgNTg4MCBhdXRoZW50aWNhdGlvbi4gSWYgYW4gYXV0aGVudGljYXRpb24gZnJhbWUgZmFpbHMg dmFsaWRhdGlvbiB0aGVuIHRoZSBzZXNzaW9uIGdvZXMgZG93biByZWdhcmRsZXNzIG9mIGdvb2Qg T1BFUi1VUCBmcmFtZXMgKGF1dGhlbnRpY2F0aW9uIG9yIG5vcm1hbCkgYmVmb3JlDQogb3IgYWZ0 ZXIgdGhhdCBmcmFtZS4gU2luY2UgdGhlIGJlaGF2aW9yIGluIDU4ODAgZG9lcyBub3QgcmVxdWly ZSBhbnkgbW9yZSB0aGFuIDEgZnJhbWUgdG8gZmFpbCB2YWxpZGF0aW9uLCB0aGUgbWVjaGFuaXNt IHdvcmtzIGFzLWlzIGluIHRoZSBuZXcgcHJvcG9zYWwuIE9uY2UgdGhlIHNlc3Npb24gaXMgZG93 biwgYWxsIGZyYW1lcyBuZWVkIHRvIGJlIGF1dGhlbnRpY2F0ZWQgdG8gYnJpbmcgdGhlIHNlc3Np b24gdXAgc28gYWdhaW4sIHRoZSBzZXNzaW9uDQogY2Fu4oCZdCBjb21lIGJhY2sgdXAganVzdCBi ZWNhdXNlIHRoZSBmcmFtZSB0aGF0IGZhaWxlZCB2YWxpZGF0aW9uIGlzIGZvbGxvd2VkIGJ5IGEg c3RyZWFtIG9mIHVuYXV0aGVudGljYXRlZCBmcmFtZXMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SG9wZSB0aGF0IGFkZHJlc3NlcyB0aGUgZ2FwIHRoYXQgeW91IHByZXNlbnRlZC4gPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFzaGVzaCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPkdyZWcgTWlyc2t5ICZsdDtncmVnaW1pcnNreUBnbWFpbC5jb20mZ3Q7PGJy Pg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIEFwcmlsIDMsIDIwMTggYXQgODozNSBQTTxicj4NCjxi PlRvOiA8L2I+QXNoZXNoIE1pc2hyYSAmbHQ7bWlzaHJhLmFzaGVzaEBvdXRsb29rLmNvbSZndDs8 YnI+DQo8Yj5DYzogPC9iPkplZmZyZXkgSGFhcyAmbHQ7amhhYXNAcGZyYy5vcmcmZ3Q7LCAmcXVv dDtydGctYmZkQGlldGYub3JnJnF1b3Q7ICZsdDtydGctYmZkQGlldGYub3JnJmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5SZTogV0dMQyBCRkQgQXV0aGVudGljYXRpb24gRHJhZnRzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBu YW1lPSJfTWFpbE9yaWdpbmFsQm9keSI+SGkgQXNoZWgsIDxvOnA+PC9vOnA+PC9hPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij50aGFuayB5b3UgZm9yIHRoZSBkZXRhaWxlZCByZXNwb25zZSB0byBteSBx dWVzdGlvbnMgYW5kIGNvbnNpZGVyYXRpb24gb2YgbXkgY29tbWVudHMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+SSB0aGluayBJIGNhbm5vdCBhZ3JlZSB0 aGF0IHRoZSBCRkQgc3RhdGUgbWFjaGluZSByZW1haW5zIHVuY2hhbmdlZCBpZiBvcHRpbWl6ZWQg QkZEIGF1dGhlbnRpY2F0aW9uIGlzIGluIHBlcmlvZGljIG1vZGUuIExldCdzIGNvbnNpZGVyIGNh c2Ugd2hlbiBvbmx5IGV2ZXJ5IDV0aCBCRkQgY29udHJvbCBwYWNrZXQgaXMgYXV0aGVudGljYXRl ZA0KIHdoZW4gdGhlIHNlc3Npb24gaXMgaW4gVXAgc3RhdGUuIFdoYXQgaGFwcGVucyBpZiBmcm9t IHNvbWUgbW9tZW50IGV2ZXJ5IGF1dGhlbnRpY2F0ZWQgcGFja2V0IGZhaWxzIHRvIGJlIHZhbGlk YXRlZD8gV291bGQgdGhlIHNlc3Npb24gZ28gdG8gRG93biBzdGF0ZT8gQnV0IGFsbCB1bmF1dGhl bnRpY2F0ZWQgQkZEIGNvbnRyb2wgcGFja2V0cyBwYXNzIHRoZSB2YWxpZGF0aW9uIGNoZWNrIGFu ZCBzaW5jZSBvbmx5IG9uZSBwYWNrZXQgc2VlbXMgdG8NCiBtaXNzIHZhbGlkYXRpb24gdGhlIHNl c3Npb24sIGlmIHRoZSBzdGF0ZSBtYWNoaW5lIHJlbWFpbnMgdW5jaGFuZ2VkLCB3aWxsIHN0YXkg VXAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+RG8geW91IHNl ZSB0aGlzIGFzIHBsYXVzaWJsZSBzY2VuYXJpbz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPkdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij5PbiBUdWUsIEFwciAzLCAyMDE4IGF0IDExOjAzIEFNLCBBc2hlc2ggTWlzaHJhICZs dDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1pc2hyYS5hc2hlc2hAb3V0bG9vay5jb20iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5t aXNocmEuYXNoZXNoQG91dGxvb2suY29tPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+Jmd0Ow0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+VGhhbmtzIGZvciB0aGUgY2xhcmlm aWNhdGlvbiwgR3JlZy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5IZXJlIGFyZSBteSB0aG91Z2h0cyBv biB0aGUgaXNzdWVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi4y NWluIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxpPkkn ZCBicmVhayBpdCBpbnRvIGNvdXBsZSBtb3JlIHNwZWNpZmljIHF1ZXN0aW9uczoNCjwvaT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6Ljc1 aW4iPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48L3Nw YW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjxpPmNhbiB0aGUgcGVyaW9kaWMgT3B0aW1pemVkIEF1dGhlbnRpY2F0aW9uIG1v ZGUgYmUgdXNlZCB3aXRob3V0IGF1dGhvcml6YXRpb24gbyBzdGF0ZSBjaGFuZ2VzOzwvaT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6Ljc1 aW4iPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48L3Nw YW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjxpPmlmIHRoZSBhbnN3ZXIgdG8gdGhlIHByZXZpb3VzIHF1ZXN0aW9uICZxdW90 O3llcyZxdW90OywgdGhlbiB3aGVuIHRoZSBmaXJzdCBhdXRob3JpemVkIEJGRCBjb250cm9sIHBh Y2tldCBtdXN0IGJlIHRyYW5zbWl0dGVkIGJ5IHRoZSBzeXN0ZW07PC9pPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNzVpbiI+DQo8c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjwvc3Bhbj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PGk+ZG9lcyB0aGUgQkZEIHN0YXRlIG1hY2hpbmUgKHNlY3Rpb24gNi4yIFJGQyA1ODgwKSBjaGFu Z2VzIHJlc3VsdGluZyBmcm9tIGludHJvZHVjdGlvbiBvZiBwZXJpb2RpYyBvcHRpbWl6ZWQgYXV0 aGVudGljYXRpb24gbW9kZTs8L2k+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48 Yj5bQU1dIFRoZSBvcHRpbWl6ZWQgYXV0aGVudGljYXRpb24gY2FuIGJlIHVzZWQgd2l0aG91dCBz dGF0ZSBjaGFuZ2VzIGFuZCB0aGUgZmlyc3QgYXV0aCBwYWNrZXQgd2lsbCBiZSB0aGUgRE9XTiBz dGF0ZSBmcmFtZSB0byBraWNrLW9mZg0KIHRoZSBzZXNzaW9uIG5lZ290aWF0aW9uIGFzIHRoZSBw cm9wb3NhbCBzdWdnZXN0cyB0aGF0IGFsbCBET1dOIHN0YXRlIGZyYW1lcyBhcmUgYXV0aGVudGlj YXRlZC4gVGhlIHN0YXRlIG1hY2hpbmUgZG9lcyBub3QgY2hhbmdlIGluIHRoaXMgcHJvcG9zYWwg YnV0IGl0IG9ubHkgaW5kaWNhdGVzIHdoaWNoIGZyYW1lcyBzaG91bGQgYmUgYXV0aGVudGljYXRl ZCBhbmQgd2hpY2ggb25lcyBjYW4gdXNlIE5VTEwtQVVUSCBUTFYgKHVuLWF1dGhlbnRpY2F0ZWQN CiBmcmFtZXMpLiA8L2I+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0Oi4yNWluIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPjxpPkFuZCBhZGRpdGlvbmFsIGNvbW1lbnRzOjwvaT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6Ljc1aW4iPg0KPHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48L3NwYW4+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu PjxpPiZxdW90O0ZvciBleGFtcGxlLCB0aGUgdHdvIGVuZHMgY2FuIGRlY2lkZSB0aGF0IEJGRCBm cmFtZXMgdGhhdCBpbmRpY2F0ZSBhIHN0YXRlIGNoYW5nZSBzaG91bGQgYmUgYXV0aGVudGljYXRl ZCBhbmQgZW5hYmxlIGF1dGhlbnRpY2F0aW9uIG9uIHRob3NlIGZyYW1lcyBvbmx5LiZxdW90Ozwv aT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjI1aW4iPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ PGk+SSBkb24ndCB0aGluayB0aGF0IG5vZGVzICZxdW90O2RlY2lkZSZxdW90OyBhbnl0aGluZyBi dXQgYXJlIGNvbmZpZ3VyZWQgdG8gZG8gc29tZXRoaW5nLjwvaT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ PGI+W0FNXSBJIGFncmVlIHRoYXQgdGhlIGxhbmd1YWdlIGlzIG5vdCBhY2N1cmF0ZS4gV2XigJls bCBjaGFuZ2UgaXQgaW4gdGhlIG5leHQgcmV2aXNpb24uIFRoZSBpbnRlbnRpb24gaXMgdG8gdXNl IGluZGljYXRlIGNvbmZpZ3VyYXRpb24NCiByYXRoZXIgdGhhbiBuZWdvdGlhdGlvbi4gPC9iPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDou NzVpbiI+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjwv c3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PGk+JnF1b3Q7SWYgdGhlIHR3byBlbmRzIGhhdmUgbm90IHByZXZpb3VzbHkg bmVnb3RpYXRlZCB3aGljaCBmcmFtZXMgdGhleSB3aWxsIHRyYW5zbWl0IG9yIHJlY2VpdmUgd2l0 aCBhdXRoZW50aWNhdGlvbiBlbmFibGVkIC4uLiZxdW90OzwvaT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjI1aW4iPg0KPHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGk+SSBjb3VsZG4ndCBmaW5kIHRo ZSBuZWdvdGlhdGlvbiBwcm9jZWR1cmUgYmVpbmcgZGVzY3JpYmVkIGluIHRoZSBkb2N1bWVudC4g SXMgaXQgb3V0LW9mLWJhbmQsIGkuZS4gYnkgY29udHJvbCBvciBtYW5hZ2VtZW50IHBsYW5lLCBu b3QgcGFydCBvZiB0aGlzIEJGRCBlbmhhbmNlbWVudD88L2k+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxi PltBTV0gVGhlIGxhbmd1YWdlIHNob3VsZCBpbmRpY2F0ZSBjb25maWd1cmF0aW9uIGluc3RlYWQg b2YgbmVnb3RpYXRpb24uDQo8L2I+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0Oi43NWluIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OlN5bWJvbCI+wrc8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48aT4mcXVvdDtUaGUgY29uZmlndXJh dGlvbiBvZiB0aGUgcGVyaW9kaWMgYXV0aGVudGljYXRpb24gaW50ZXJ2YWwgZm9yIEJGRCBDQyBV UCBmcmFtZXMgaXMgYW4gb3BlbiBpc3N1ZS4mcXVvdDs8L2k+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi4yNWluIj4NCjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxpPkkgYmVsaWV2ZSB0aGF0IHRoaXMg b3BlbiBpc3N1ZSBtdXN0IGJlIHJlc29sdmVkIGluIHRoZSBkZWZpbml0aXZlIG1hbm5lciBiZWZv cmUgdGhlIGRyYWZ0IG1vdmVkIHRvIFdHTEMuPC9pPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouMjVpbiI+DQo8c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPjxiPltBTV0gVGhpcyBsaW5lIHNob3VsZCBiZSByZW1vdmVkIGFuZCB0aGUg cHJlY2VkaW5nIHRleHQgc2hvdWxkIGluZGljYXRlIHRoYXQgdGhlIHBhcmFtZXRlcnMgZm9yIGF1 dGhlbnRpY2F0aW9uIHNob3VsZCBiZSBjb25maWd1cmVkDQogb24gdGhlIHNlc3Npb24gZW5kLXBv aW50cy4gPC9iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5SZWdhcmRzLDxicj4NCkFzaGVzaDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5HcmVnIE1pcnNreSAmbHQ7PC9zcGFuPjwvc3Bhbj48 YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvc3Bhbj48L3NwYW4+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIEFw cmlsIDIsIDIwMTggYXQgMTI6MzQgUE08YnI+DQo8Yj5UbzogPC9iPkFzaGVzaCBNaXNocmEgJmx0 Ozwvc3Bhbj48L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1pc2hyYS5hc2hlc2hAb3V0bG9vay5jb20i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+bWlzaHJhLmFzaGVzaEBvdXRsb29r LmNvbTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jmd0Ozxicj4N CjxiPkNjOiA8L2I+SmVmZnJleSBIYWFzICZsdDs8L3NwYW4+PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpqaGFhc0BwZnJjLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5qaGFh c0BwZnJjLm9yZzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jmd0 OywNCiAmcXVvdDs8L3NwYW4+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPnJ0Zy1iZmRAaWV0Zi5vcmc8L3Nw YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZxdW90Ow0KICZsdDs8L3Nw YW4+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPnJ0Zy1iZmRAaWV0Zi5vcmc8L3NwYW4+PC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZndDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFdHTEMg QkZEIEF1dGhlbnRpY2F0aW9uIERyYWZ0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YSBuYW1lPSJt XzczMTA0OTUyMzU1OTcyMzQ2MzdfX01haWxPcmlnaW5hbEJvZHkiPkhpIEFzaGVoLA0KPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPnRoYW5rIHlvdSBmb3IgdGFr aW5nIHRpbWUgdG8gcmV2aWV3IHRoZSBtaW51dGVzIGZyb20gQkZEIFdHIG1lZXRpbmcgYXQgSUVU Ri05OC4gSSBkb24ndCB0aGluayB0aGF0IHdlIGhhZCBlbm91Z2ggdGltZSB0byBkaXNjdXNzIGlu DQogZGV0YWlscyBteSBxdWVzdGlvbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPkdyZWcgTWlyc2t5OiBPbmUgb2YgdGhlIHBvc3NpYmxlIG1vZGVzIHdoZW4gdGhlIHNlc3Np b24gaXMgdXAgaXMgdG8gdXNlIGF1dGhlbnRpY2F0aW9uIHdpdGggcGVyaW9kaWMgdGltZXIgdHJp Z2dlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij5JJ2QgYnJlYWsgaXQgaW50byBjb3VwbGUgbW9yZSBzcGVjaWZpYyBxdWVz dGlvbnM6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0K PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvMSI+DQo8c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5jYW4gdGhlIHBlcmlvZGljIE9w dGltaXplZCBBdXRoZW50aWNhdGlvbiBtb2RlIGJlIHVzZWQgd2l0aG91dCBhdXRob3JpemF0aW9u IG8gc3RhdGUgY2hhbmdlczs8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+aWYgdGhlIGFuc3dlciB0byB0aGUgcHJldmlvdXMgcXVlc3Rp b24gJnF1b3Q7eWVzJnF1b3Q7LCB0aGVuIHdoZW4gdGhlIGZpcnN0IGF1dGhvcml6ZWQgQkZEIGNv bnRyb2wgcGFja2V0IG11c3QgYmUgdHJhbnNtaXR0ZWQgYnkgdGhlIHN5c3RlbTs8bzpwPjwvbzpw Pjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxm bzEiPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ZG9lcyB0 aGUgQkZEIHN0YXRlIG1hY2hpbmUgKHNlY3Rpb24gNi4yIFJGQyA1ODgwKSBjaGFuZ2VzIHJlc3Vs dGluZyBmcm9tIGludHJvZHVjdGlvbiBvZiBwZXJpb2RpYyBvcHRpbWl6ZWQgYXV0aGVudGljYXRp b24gbW9kZTs8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkFuZCBhZGRp dGlvbmFsIGNvbW1lbnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx1 bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzIiPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+JnF1 b3Q7Rm9yIGV4YW1wbGUsIHRoZSB0d28gZW5kcyBjYW4gZGVjaWRlIHRoYXQgQkZEIGZyYW1lcyB0 aGF0IGluZGljYXRlIGEgc3RhdGUgY2hhbmdlIHNob3VsZCBiZSBhdXRoZW50aWNhdGVkIGFuZCBl bmFibGUgYXV0aGVudGljYXRpb24gb24gdGhvc2UgZnJhbWVzIG9ubHkuJnF1b3Q7PG86cD48L286 cD48L3NwYW4+PC9saT48L3VsPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij5JIGRvbid0IHRoaW5rIHRoYXQgbm9kZXMgJnF1b3Q7ZGVjaWRl JnF1b3Q7IGFueXRoaW5nIGJ1dCBhcmUgY29uZmlndXJlZCB0byBkbyBzb21ldGhpbmcuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8dWwgdHlwZT0iZGlzYyI+ DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NCjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZxdW90O0lmIHRoZSB0d28g ZW5kcyBoYXZlIG5vdCBwcmV2aW91c2x5IG5lZ290aWF0ZWQgd2hpY2ggZnJhbWVzIHRoZXkgd2ls bCB0cmFuc21pdCBvciByZWNlaXZlIHdpdGggYXV0aGVudGljYXRpb24gZW5hYmxlZCAuLi4mcXVv dDs8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzAuMHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkkgY291bGRuJ3QgZmluZCB0aGUgbmVnb3Rp YXRpb24gcHJvY2VkdXJlIGJlaW5nIGRlc2NyaWJlZCBpbiB0aGUgZG9jdW1lbnQuIElzIGl0IG91 dC1vZi1iYW5kLCBpLmUuIGJ5IGNvbnRyb2wgb3IgbWFuYWdlbWVudCBwbGFuZSwgbm90DQogcGFy dCBvZiB0aGlzIEJGRCBlbmhhbmNlbWVudD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+JnF1b3Q7VGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhlIHBlcmlvZGljIGF1 dGhlbnRpY2F0aW9uIGludGVydmFsIGZvciBCRkQgQ0MgVVAgZnJhbWVzIGlzIGFuIG9wZW4gaXNz dWUuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjMwLjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5JIGJlbGlldmUgdGhhdCB0aGlz IG9wZW4gaXNzdWUgbXVzdCBiZSByZXNvbHZlZCBpbiB0aGUgZGVmaW5pdGl2ZSBtYW5uZXIgYmVm b3JlIHRoZSBkcmFmdCBtb3ZlZCB0byBXR0xDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5HcmVnPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+T24gU3VuLCBBcHIgMSwgMjAxOCBhdCA2OjExIFBNLCBB c2hlc2ggTWlzaHJhICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1pc2hyYS5hc2hlc2hAb3V0 bG9vay5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij5taXNocmEuYXNoZXNoQG91dGxvb2suY29tPC9zcGFuPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jmd0Ow0KIHdyb3RlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXYgaWQ9Im1fNzMxMDQ5NTIzNTU5NzIzNDYzN21fNTgxOTIyMjIzMjU2 NTk1OTg2MGRpdnRhZ2RlZmF1bHR3cmFwcGVyIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkhpIEdyZWcs Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGlu O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Zb3Vy IHF1ZXN0aW9ucyZuYnNwO2luIHRoZSBJRVRGLTk4IG1lZXRpbmcgc2VlbWVkIHRvIHN0ZW0gZnJv bSB0aGUgY2hhbGxlbmdlcyBvZiBhdXRoZW50aWNhdGlvbiBpbiBmYXN0IEJGRCBzZXNzaW9ucyBh dCBoaWdoIHNjYWxlLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+SSdsbCBhZGRyZXNzIHRoZSBpc3N1ZSBpbiB0d28gcGFydHMgLSZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+JnF1b3Q7SXMgdGhlcmUg YSBuZWVkIGZvciBhdXRoZW50aWNhdGVkIEJGRCBzZXNzaW9ucz8mcXVvdDsgLSBJIGJlbGlldmUg d2UgY2FuIGFsbCBhZ3JlZSB0aGF0IHRoZXJlIGlzIGEgY2xlYXIgbWFya2V0IG5lZWQgZm9yIEJG RCBhdXRoZW50aWNhdGlvbi4NCiBTbyB3ZSBzaG91bGQgZGlyZWN0IHRoZSBjb252ZXJzYXRpb24g dG8gdGhlIHdheSBpbiB3aGljaCB3ZSBjYW4gYWRkcmVzcyB0aGlzIHJlcXVpcmVtZW50LiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+JnF1b3Q7SG93 IGNhbiBhdXRoZW50aWNhdGlvbiB3b3JrIGF0IHNjYWxlPyZxdW90OyAtIEJGRCBhdXRoZW50aWNh dGlvbiBwdXRzIHNpZ25pZmljYW50IHN0cmVzcyBvbiB0aGUgc3lzdGVtIGFuZCBhIG5vbi1tZXRp Y3Vsb3VzIG1ldGhvZA0KIGFsbGV2aWF0ZXMgdGhpcyBjb21wdXRhdGlvbiBwcmVzc3VyZS4gVGhh dCdzIHRoZSBwcmVtaXNlIG9mIHRoaXMgZHJhZnQgYXMgaXQgcHJlc2VudHMgYSB3YXkgdG8gcmVs aWV2ZSB0aGUgQkZEIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50IGJhc2VkIG9uIHRoZSBjYXBh YmlsaXR5IG9mIHRoZSBzeXN0ZW0gdG8gaGFuZGxlIHRoZSBhZGRpdGlvbmFsIHN0cmVzcyB3aGlj aCBtYWludGFpbmluZyB0aGUgc2Vzc2lvbiZuYnNwO3NjYWxlLiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+VGhlcmUgYXJlIHNvbWUgQkZEIHN5c3Rl bXMgaW4gdGhlIG1hcmtldCwgd2hpY2ggYXJlIG5vdCBjb25kdWNpdmUgdG8gYXV0aGVudGljYXRp b24gKGV2ZW4gdGhlIG9wdGltaXplZCBtZXRob2QpLCB3aGVyZSB0aGUgaW1wZWRpbWVudA0KIHRv IGF1dGhlbnRpY2F0aW9uIGlzIGR1ZSB0byB0aGUgaW1wbGVtZW50YXRpb24gZGV0YWlscyBzcGVj aWZpYyB0byB0aGF0IHZlbmRvciBvciBzeXN0ZW0uJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5JIGJlbGlldmUgYWxsIHRoZXNlIGlzc3VlcyB3ZXJl IGFkZHJlc3MgZHVyaW5nIHRoZSBtZWV0aW5nLiBBcmUgdGhlcmUgYW55IHNwZWNpZmljIHF1ZXN0 aW9ucyB0aGF0IEkgbWlzc2VkIG9yIGFueSByZWNvbW1lbmRhdGlvbnMNCiBmb3IgdGhlIG1ldGhv ZCBpbiB3aGljaCB0aGUgcmVxdWlyZW1lbnRzIGNhbiBiZSBhZGRyZXNzZWQ/Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5UaGFua3MsPC9zcGFuPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkFzaGVzaDwvc3Bhbj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4NCjxociBzaXplPSIwIiB3aWR0aD0iMTAwJSIgYWxpZ249 ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGlkPSJtXzczMTA0OTUyMzU1OTcyMzQ2Mzdt XzU4MTkyMjIyMzI1NjU5NTk4NjBkaXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4gUnRnLWJmZCAmbHQ7PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86cnRnLWJmZC1i b3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mZ3Q7DQogb24gYmVoYWxmIG9mIEdyZWcgTWlyc2t5ICZsdDs8L3NwYW4+PC9zcGFu PjxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5ncmVnaW1pcnNreUBn bWFpbC5jb208L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDs8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNk YXksIE1hcmNoIDI5LCAyMDE4IDQ6MDk6MzIgQU08YnI+DQo8Yj5Ubzo8L2I+IEplZmZyZXkgSGFh czxicj4NCjxiPkNjOjwvYj4gPC9zcGFuPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86cnRnLWJmZEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPnJ0Zy1iZmRAaWV0Zi5vcmc8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogV0dMQyBCRkQgQXV0aGVudGljYXRpb24gRHJhZnRzPC9zcGFuPiA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+RGVhciBXRyBDaGFpcnMsIGV0LiBhbCwmbmJzcDsNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkkgY2Fubm90IHN1cHBvcnQgV0cgTEMgZm9yJm5i c3A7ZHJhZnQtaWV0Zi1iZmQtb3B0aW1pemluZy1hdXRoZW50aWNhdGlvbiBhcyBteSBjb21tZW50 cyBhdA0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGlu Zy85OC9tYXRlcmlhbHMvbWludXRlcy05OC1iZmQtMDAiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5CRkQgV0cgbWVldGluZyBkYXRp bmcgYmFjayB0byBJRVRGLTk4PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+Jm5ic3A7c3RpbGwNCiBub3QgaGF2ZSBiZWVuIGFkZHJlc3NlZCBub3IgZXZl biB0aGVyZSB3YXMgYW4gYXR0ZW1wdCB0byBhZGRyZXNzLiBBcyBJJ3ZlIGFza2VkIHRvIGNsYXJp ZnkgaW1wYWN0IG9mIHRoZSBwcm9wb3NlZCBtZWNoYW5pc20sIHBhcnRpY3VsYXJseSBwZXJpb2Rp YyBhdXRoZW50aWNhdGlvbiwgb24gdGhlIEJGRCBTdGF0ZSBNYWNoaW5lLCBJJ2QgcG9pbnQgdGhh dCB0aGUgcHJvcG9zZWQgbWVjaGFuaXNtIGRpcmVjdGx5IGFmZmVjdHMgQkZEIHNlY3VyaXR5DQog YXMgZGlzY3Vzc2VkIGluIFJGQyA1ODgwIGFuZCB0aGUgc2VjdGlvbiBTZWN1cml0eSBDb25zaWRl cmF0aW9ucyBpbiB0aGUgZG9jdW1lbnQsIGluIG15IHZpZXcsIGRvZXMgbm90IGFkZXF1YXRlbHkg cmVmbGVjdHMgdGhhdCBhbmQgZG9lc24ndCBleHBsYWluIGhvdyB0aGUgc2VjdXJpdHkgb2YgdGhl IEJGRCBzZXNzaW9uIG1haW50YWluZWQgd2hlbiB0aGUgcGVyaW9kaWMgYXV0aGVudGljYXRpb24g aXMgaW4gdXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+R3JlZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5P biBXZWQsIE1hciAyOCwgMjAxOCBhdCA3OjM4IFBNLCBKZWZmcmV5IEhhYXMgJmx0Ozwvc3Bhbj48 YSBocmVmPSJtYWlsdG86amhhYXNAcGZyYy5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5qaGFhc0BwZnJjLm9yZzwvc3Bhbj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDsNCiB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+V29ya2luZyBHcm91cCw8YnI+DQo8YnI+DQpUaGUgYXV0aG9y cyBvZiB0aGUgZm9sbG93aW5nIFdvcmtpbmcgR3JvdXAgZHJhZnRzIGhhdmUgcmVxdWVzdGVkPGJy Pg0KV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gdGhlIGZvbGxvd2luZyBkb2N1bWVudHM6PGJy Pg0KPGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWJmZC1zZWN1cmUtc2VxdWVuY2UtbnVtYmVycy0wMSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmZC1zZWN1cmUtc2VxdWVuY2UtbnVtYmVycy0wMTwv c3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxicj4NCjwv c3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZmQt b3B0aW1pemluZy1hdXRoZW50aWNhdGlvbi0wNCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWJmZC1vcHRpbWl6aW5nLWF1dGhlbnRpY2F0aW9uLTA0PC9zcGFuPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGJyPg0KPC9zcGFuPjxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmZC1zdGFiaWxp dHktMDEiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZmQtc3Rh YmlsaXR5LTAxPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+PGJyPg0KPGJyPg0KR2l2ZW4gdGhlIG92ZXJsYXAgb2YgZnVuY3Rpb25hbGl0eSwgV0dMQyB3 aWxsIGNvbmNsdWRlIGZvciB0aGUgYnVuZGxlPGJyPg0Kc2ltdWx0YW5lb3VzbHkuPGJyPg0KPGJy Pg0KQXV0aG9ycywgcGxlYXNlIHBvc2l0aXZlbHkgYWNrbm93bGVkZ2Ugd2hldGhlciBvciBub3Qg eW91IGtub3cgYWJvdXQgYW55IElQUjxicj4NCmZvciB5b3VyIGRvY3VtZW50cy4mbmJzcDsgUHJv Z3Jlc3Npb24gb2YgdGhlIGRvY3VtZW50IHdpbGwgbm90IGJlIGRvbmUgd2l0aG91dDxicj4NCnRo YXQgc3RhdGVtZW50Ljxicj4NCjxicj4NCkxhc3QgY2FsbCB3aWxsIGNvbXBsZXRlIG9uIEFwcmls IDIwLjxicj4NCjxicj4NCi0tIEplZmY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_350B779576FC4E7A95322F3CF0577C31outlookcom_-- From nobody Mon Apr 9 12:40:07 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 34CB912D77D for ; Mon, 9 Apr 2018 12:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[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 P0RqUaaAenvo for ; Mon, 9 Apr 2018 12:40:02 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 E340412D77C for ; Mon, 9 Apr 2018 12:40:01 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id g203-v6so8255466lfg.11 for ; Mon, 09 Apr 2018 12:40:01 -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=jeND4l5BGhxhKsqVt3af6bO7vXZFRWCdqAhBsNPiOeA=; b=lWIGoU1ZFnwcedU5UH6fSsYcHcKdkzmbvCkVxa9Vo3VfoNX7sDV3+Ut8iVmFYaxIJW O2dAJ26SjjLPxjw3F6ChEoTpDZo9006e3LNCqWVWUCLvdbqgXqJlfG5Zhz7PuF1sYEnT NGZWltbI+IQm0pc3NPFg1Z7KW9TFW99OiyhFE+ZlnlgVYUmng9TdTjNmqNO1iTJK3XRc PBIneST8uBqo9+U+oicfUNRPYMLYHxfkqj1Kf6BPTzHBqPasGV52kCyH6yCcJ2Jo/r3F wPWsPtGvTX3Mn3a6huMUvZJSA84CElWtP+cYy8s7+37gd9JQH6sR/J+YIA3IUByiWwW7 E9eQ== 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=jeND4l5BGhxhKsqVt3af6bO7vXZFRWCdqAhBsNPiOeA=; b=F9r/PIlLkOIqo5CeMsTZk+PkViyjX1JLToNVj/7u+TgI1h6kY7rthGSNkPJYUZDmer aQAS9fgfzAKvJFM/V+RUDZc3Jn/MzBKXvcwvuOfs8NqaneWdoEaxycLRxrUdIshVd+jv /8SB8pABJdmMMV8juEPMsKJFFbsP4dPlKc7j52JZp4IaufdAdRbqZ9uLN1sdCSg7i4bJ l3976NzMWZJH0yKjL6QVp0I8WNzeM35bKzFKajDXmOylVXwl3dnlKrZz9kEgCrbwC+bU J/0HvEwOCrVDY53I3PEQ9A65h4Avx0OgZy04zHmzrb555pwu3eWBQ5hqY8boRYCdgGhG ZF2w== X-Gm-Message-State: ALQs6tB1gQNs9amxU7wEeXpTZFoeYOCs2q7RyreeIw9enO5E4DAO1wD0 jbzkGx+hnIX5nuuhpcnl0tffrBa3Yg8dEmjk+AY= X-Google-Smtp-Source: AIpwx4+Z7sC5AgadIYDqpSZ+1EI3GaM7iujUyBbS8wyK6H00IWKeTZdZYv830tdu09m5AVijpQXFa3JZNvAMtVaqGJI= X-Received: by 2002:a19:1a88:: with SMTP id a130-v6mr153480lfa.7.1523302799931; Mon, 09 Apr 2018 12:39:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.73.66 with HTTP; Mon, 9 Apr 2018 12:39:59 -0700 (PDT) In-Reply-To: <350B7795-76FC-4E7A-9532-2F3CF0577C31@outlook.com> References: <20180328163856.GB3126@pfrc.org> <36BBC371-54A2-43B0-8597-69782CFFD5E9@outlook.com> <350B7795-76FC-4E7A-9532-2F3CF0577C31@outlook.com> From: Greg Mirsky Date: Mon, 9 Apr 2018 12:39:59 -0700 Message-ID: Subject: Re: WGLC BFD Authentication Drafts To: Ashesh Mishra Cc: Jeffrey Haas , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary="00000000000046826505696f9213" 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: Mon, 09 Apr 2018 19:40:06 -0000 --00000000000046826505696f9213 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ashesh, thank you for your response to my questions. I think I need some more of your help to locate the text in RFC 5880 that, as you've stated, mandates that the single failure to authenticate a BFD control packet in Up state triggers the transition to Down state. I only see section 6.7 that describes authentication validation and when the received control packet must be discarded because of validation failure and the following text: If the A bit is set, the packet MUST be authenticated under the rules of section 6.7, based on the authentication type in use (bfd.AuthType). This may cause the packet to be discarded. But I don't find any text that states that if authentication is in use, then Detect Time calculated regardless of the value of the Detect Mult field. Perhaps I will extend the description of the scenario: - authentication is in use and every, for example, the fourth packet to be authenticated, i.e. three control packets with NULL Auth TLV followed= by "real" authenticated control packet; - initial packets, three-way handshake, pass authentication verification and the session is Up; - at some point, the verification of the "real" authenticated packets fails and it is discarded; - packets with NUL Auth TLV pass the validation. Appreciate your consideration and help. Regards, Greg On Mon, Apr 9, 2018 at 10:51 AM, Ashesh Mishra wrote: > Hi Greg, > > > > What I meant to say was that the state machine remains the same as in the > case of 5880 authentication. If an authentication frame fails validation > then the session goes down regardless of good OPER-UP frames > (authentication or normal) before or after that frame. Since the behavior > in 5880 does not require any more than 1 frame to fail validation, the > mechanism works as-is in the new proposal. Once the session is down, all > frames need to be authenticated to bring the session up so again, the > session can=E2=80=99t come back up just because the frame that failed val= idation is > followed by a stream of unauthenticated frames. > > > > Hope that addresses the gap that you presented. > > > > Ashesh > > > > *From: *Greg Mirsky > *Date: *Tuesday, April 3, 2018 at 8:35 PM > > *To: *Ashesh Mishra > *Cc: *Jeffrey Haas , "rtg-bfd@ietf.org" > *Subject: *Re: WGLC BFD Authentication Drafts > > > > Hi Asheh, > > thank you for the detailed response to my questions and consideration of > my comments. > > I think I cannot agree that the BFD state machine remains unchanged if > optimized BFD authentication is in periodic mode. Let's consider case whe= n > only every 5th BFD control packet is authenticated when the session is in > Up state. What happens if from some moment every authenticated packet fai= ls > to be validated? Would the session go to Down state? But all > unauthenticated BFD control packets pass the validation check and since > only one packet seems to miss validation the session, if the state machin= e > remains unchanged, will stay Up. > > > > Do you see this as plausible scenario? > > > > Regards, > > Greg > > > > On Tue, Apr 3, 2018 at 11:03 AM, Ashesh Mishra > wrote: > > Thanks for the clarification, Greg. > > > > Here are my thoughts on the issues: > > > > *I'd break it into couple more specific questions: * > > =C2=B7 *can the periodic Optimized Authentication mode be used wi= thout > authorization o state changes;* > > =C2=B7 *if the answer to the previous question "yes", then when t= he > first authorized BFD control packet must be transmitted by the system;* > > =C2=B7 *does the BFD state machine (section 6.2 RFC 5880) changes > resulting from introduction of periodic optimized authentication mode;* > > *[AM] The optimized authentication can be used without state changes and > the first auth packet will be the DOWN state frame to kick-off the sessio= n > negotiation as the proposal suggests that all DOWN state frames are > authenticated. The state machine does not change in this proposal but it > only indicates which frames should be authenticated and which ones can us= e > NULL-AUTH TLV (un-authenticated frames). * > > *And additional comments:* > > =C2=B7 *"For example, the two ends can decide that BFD frames tha= t > indicate a state change should be authenticated and enable authentication > on those frames only."* > > *I don't think that nodes "decide" anything but are configured to do > something.* > > > > *[AM] I agree that the language is not accurate. We=E2=80=99ll change it = in the > next revision. The intention is to use indicate configuration rather than > negotiation. * > > =C2=B7 *"If the two ends have not previously negotiated which fra= mes > they will transmit or receive with authentication enabled ..."* > > *I couldn't find the negotiation procedure being described in the > document. Is it out-of-band, i.e. by control or management plane, not par= t > of this BFD enhancement?* > > > > *[AM] The language should indicate configuration instead of negotiation. = * > > =C2=B7 *"The configuration of the periodic authentication interva= l for > BFD CC UP frames is an open issue."* > > *I believe that this open issue must be resolved in the definitive manner > before the draft moved to WGLC.* > > > > *[AM] This line should be removed and the preceding text should indicate > that the parameters for authentication should be configured on the sessio= n > end-points. * > > > > Regards, > Ashesh > > > > *From: *Greg Mirsky > *Date: *Monday, April 2, 2018 at 12:34 PM > *To: *Ashesh Mishra > *Cc: *Jeffrey Haas , "rtg-bfd@ietf.org" > > > *Subject: *Re: WGLC BFD Authentication Drafts > > > > Hi Asheh, > > thank you for taking time to review the minutes from BFD WG meeting at > IETF-98. I don't think that we had enough time to discuss in details my > question: > > Greg Mirsky: One of the possible modes when the session is up is to use > authentication with periodic timer trigger? > > I'd break it into couple more specific questions: > > - can the periodic Optimized Authentication mode be used without > authorization o state changes; > - if the answer to the previous question "yes", then when the first > authorized BFD control packet must be transmitted by the system; > - does the BFD state machine (section 6.2 RFC 5880) changes resulting > from introduction of periodic optimized authentication mode; > > And additional comments: > > - "For example, the two ends can decide that BFD frames that indicate > a state change should be authenticated and enable authentication on th= ose > frames only." > > I don't think that nodes "decide" anything but are configured to do > something. > > > - "If the two ends have not previously negotiated which frames they > will transmit or receive with authentication enabled ..." > > I couldn't find the negotiation procedure being described in the document= . > Is it out-of-band, i.e. by control or management plane, not part of this > BFD enhancement? > > > - "The configuration of the periodic authentication interval for BFD > CC UP frames is an open issue." > > I believe that this open issue must be resolved in the definitive manner > before the draft moved to WGLC. > > > > Regards, > > Greg > > > > > > On Sun, Apr 1, 2018 at 6:11 PM, Ashesh Mishra > wrote: > > Hi Greg, > > > > Your questions in the IETF-98 meeting seemed to stem from the challenges > of authentication in fast BFD sessions at high scale. > > > > I'll address the issue in two parts - > > > > "Is there a need for authenticated BFD sessions?" - I believe we can all > agree that there is a clear market need for BFD authentication. So we > should direct the conversation to the way in which we can address this > requirement. > > > > "How can authentication work at scale?" - BFD authentication puts > significant stress on the system and a non-meticulous method alleviates > this computation pressure. That's the premise of this draft as it present= s > a way to relieve the BFD authentication requirement based on the capabili= ty > of the system to handle the additional stress which maintaining the > session scale. > > > > There are some BFD systems in the market, which are not conducive to > authentication (even the optimized method), where the impediment to > authentication is due to the implementation details specific to that vend= or > or system. > > > > I believe all these issues were address during the meeting. Are there any > specific questions that I missed or any recommendations for the method in > which the requirements can be addressed? > > > > Thanks, > > Ashesh > ------------------------------ > > *From:* Rtg-bfd on behalf of Greg Mirsky < > gregimirsky@gmail.com> > *Sent:* Thursday, March 29, 2018 4:09:32 AM > *To:* Jeffrey Haas > *Cc:* rtg-bfd@ietf.org > *Subject:* Re: WGLC BFD Authentication Drafts > > > > Dear WG Chairs, et. al, > > I cannot support WG LC for draft-ietf-bfd-optimizing-authentication as my > comments at BFD WG meeting dating back to IETF-98 > sti= ll > not have been addressed nor even there was an attempt to address. As I've > asked to clarify impact of the proposed mechanism, particularly periodic > authentication, on the BFD State Machine, I'd point that the proposed > mechanism directly affects BFD security as discussed in RFC 5880 and the > section Security Considerations in the document, in my view, does not > adequately reflects that and doesn't explain how the security of the BFD > session maintained when the periodic authentication is in use. > > > > Regards, > > Greg > > > > On Wed, Mar 28, 2018 at 7:38 PM, Jeffrey Haas wrote: > > Working Group, > > The authors of the following Working Group drafts have requested > Working Group Last Call on the following documents: > > https://tools.ietf.org/html/draft-ietf-bfd-secure-sequence-numbers-01 > https://tools.ietf.org/html/draft-ietf-bfd-optimizing-authentication-04 > https://tools.ietf.org/html/draft-ietf-bfd-stability-01 > > Given the overlap of functionality, WGLC will conclude for the bundle > simultaneously. > > Authors, please positively acknowledge whether or not you know about any > IPR > for your documents. Progression of the document will not be done without > that statement. > > Last call will complete on April 20. > > -- Jeff > > > > > > > --00000000000046826505696f9213 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Ashesh,
    thank you for your response to my questions= . I think I need some more of your help to locate the=C2=A0text in RFC 5880= that, as you've stated, mandates that the single failure to authentica= te a BFD control packet in Up state=C2=A0triggers the transition to Down st= ate. I only see section 6.7 that describes authentication validation and wh= en the received=C2=A0control packet must be discarded=C2=A0because of valid= ation failure and the following text:
    =C2=A0 =C2=A0 =C2=A0 I= f the A bit is set, the packet MUST be authenticated under the
    = =C2=A0 =C2=A0 =C2=A0 rules of section 6.7, based on the authentication type= in use
    =C2=A0 =C2=A0 =C2=A0 (bfd.AuthType).=C2=A0 This may cause= the packet to be discarded.
    But I don't find any text = that states that if authentication is in use, then Detect Time calculated r= egardless of the value of the Detect Mult field. Perhaps I will extend the = description of the scenario:
    • authentication is in use and= every, for example, the fourth packet to b= e authenticated, i.e. three control packets with NULL Auth TLV followed by = "real" authenticated control packet;
    • initial packets, thr= ee-way handshake, pass authentication verification and the session is Up;
    • at some point, the verification of the "real" authenticate= d packets fails and it is discarded;
    • packets with NUL Auth TLV pass= the validation.
    Appreciate your consideration and help.

    Regards,
    Greg

    On Mon, Apr 9, 2018 at 10:51 A= M, Ashesh Mishra <mishra.ashesh@outlook.com> wrote:<= br>

    Hi Greg,

    =C2=A0

    What I meant to say was that the state machine remai= ns the same as in the case of 5880 authentication. If an authentication fra= me fails validation then the session goes down regardless of good OPER-UP f= rames (authentication or normal) before or after that frame. Since the behavior in 5880 does not require any more = than 1 frame to fail validation, the mechanism works as-is in the new propo= sal. Once the session is down, all frames need to be authenticated to bring= the session up so again, the session can=E2=80=99t come back up just because the frame that failed validation i= s followed by a stream of unauthenticated frames.

    =C2=A0

    Hope that addresses the gap that you presented. <= /u>

    =C2=A0

    Ashesh

    =C2=A0

    From= : Greg Mirsky <<= a href=3D"mailto:gregimirsky@gmail.com" target=3D"_blank">gregimirsky@gmail= .com>
    Date: Tuesday, April 3, 2018 at 8:35 PM


    To: Ashesh Mishra <mishra.ashesh@outlook.com>
    Cc: Jeffrey Haas <jhaas@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
    Subject: Re: WGLC BFD Authentication Drafts

    =C2=A0

    Hi Asheh,

    thank you for the detailed response to my ques= tions and consideration of my comments.

    I think I cannot agree that the BFD state mach= ine remains unchanged if optimized BFD authentication is in periodic mode. = Let's consider case when only every 5th BFD control packet is authentic= ated when the session is in Up state. What happens if from some moment every au= thenticated packet fails to be validated? Would the session go to Down stat= e? But all unauthenticated BFD control packets pass the validation check an= d since only one packet seems to miss validation the session, if the state machine remains unchanged, will = stay Up.

    =C2=A0

    Do you see this as plausible scenario?<= u>

    =C2=A0

    Regards,

    Greg

    =C2=A0

    On Tue, Apr 3, 2018 at 11:03 AM, Ashesh Mishra= <= mishra.ashesh@outlook.com> wrote:

    Thanks for the clarification, Greg.

    =C2=A0

    Here are my thoughts on the issues:<= /u>

    =C2=A0

    I'd break it into couple more specific questions:

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 can the periodic Optimized Authentication mode be used without au= thorization o state changes;

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if the answer to the previous question "yes", then when= the first authorized BFD control packet must be transmitted by the system;=

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 does the BFD state machine (section 6.2 RFC 5880) changes resulti= ng from introduction of periodic optimized authentication mode;<= u>

    [AM] The optimized authentication can be us= ed without state changes and the first auth packet will be the DOWN state f= rame to kick-off the session negotiation as the proposal suggests that all DOWN state frame= s are authenticated. The state machine does not change in this proposal but= it only indicates which frames should be authenticated and which ones can = use NULL-AUTH TLV (un-authenticated frames).

    And additional comments:

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "For example, the two ends can decide that BFD frames that i= ndicate a state change should be authenticated and enable authentication on= those frames only."

    I don't think that nodes "decide" anything but are c= onfigured to do something.

    =C2=A0

    [AM] I agree that the language is not accur= ate. We=E2=80=99ll change it in the next revision. The intention is to use = indicate configuration rather than negotiation.

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "If the two ends have not previously negotiated which frames= they will transmit or receive with authentication enabled ..."=

    I couldn't find the negotiation procedure being described in t= he document. Is it out-of-band, i.e. by control or management plane, not pa= rt of this BFD enhancement?

    =C2=A0

    [AM] The language should indicate configura= tion instead of negotiation.

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "The configuration of the periodic authentication interval f= or BFD CC UP frames is an open issue."

    I believe that this open issue must be resolved in the definitive = manner before the draft moved to WGLC.

    =C2=A0

    [AM] This line should be removed and the pr= eceding text should indicate that the parameters for authentication should = be configured on the session end-points.

    =C2=A0

    Regards,
    Ashesh

    =C2=A0

    From: Greg M= irsky <gregimirsky@gmail.com= = >
    Date: Monday, April 2, 2018 at 12:34 PM
    To: Ashesh Mishra <    mishr= a.ashesh@outlook.com>
    Cc: Jeffrey Haas <    jhaas@pfrc.org>, "= rtg-bfd@ietf.org= " <rtg-bfd@ietf.org><= /u>


    Subject: Re: WGLC BFD Authentication Drafts

    =C2=A0

    Hi Asheh,

    thank you for taking time to review the minute= s from BFD WG meeting at IETF-98. I don't think that we had enough time= to discuss in details my question:

    Greg Mirsky: One of the possible modes when th= e session is up is to use authentication with periodic timer trigger?

    I'd break it into couple more specific que= stions:

    • can the periodic Optimized Authentication mode be used without author= ization o state changes;
    • if the answer to the previous question "yes", then when the= first authorized BFD control packet must be transmitted by the system;<= /u>
    • does the BFD state machine (section 6.2 RFC 5880) changes resulting f= rom introduction of periodic optimized authentication mode;

    And additional comments:<= /p>

    • "For example, the two ends can decide that BFD frames that indic= ate a state change should be authenticated and enable authentication on tho= se frames only."

    I don't think that nodes "decide"= ; anything but are configured to do something.

    • "If the two ends have not previously negotiated which frames the= y will transmit or receive with authentication enabled ..."<= /u>

    I couldn't find the negotiation procedure = being described in the document. Is it out-of-band, i.e. by control or mana= gement plane, not part of this BFD enhancement?

    • "The configuration of the periodic authentication interval for B= FD CC UP frames is an open issue."

    I believe that this open issue must be resolve= d in the definitive manner before the draft moved to WGLC.

    =C2=A0

    Regards,

    Greg

    =C2=A0

    =C2=A0

    On Sun, Apr 1, 2018 at 6:11 PM, Ashesh Mishra = <<= span>mishra.ashesh@outlook.com> wrote:

    Hi Greg,=C2=A0

    =C2=A0

    Your questions=C2=A0in the IETF-98 meeting seemed to = stem from the challenges of authentication in fast BFD sessions at high sca= le.=C2=A0

    =C2=A0

    I'll address the issue in two parts -=C2=A0

    =C2=A0

    "Is there a need for authenticated BFD sessions?= " - I believe we can all agree that there is a clear market need for B= FD authentication. So we should direct the conversation to the way in which we can address th= is requirement.=C2=A0

    =C2=A0

    "How can authentication work at scale?" - B= FD authentication puts significant stress on the system and a non-meticulou= s method alleviates this computation pressure. That's the premise of this draft= as it presents a way to relieve the BFD authentication requirement based o= n the capability of the system to handle the additional stress which mainta= ining the session=C2=A0scale.=C2=A0

    =C2=A0

    There are some BFD systems in the market, which are n= ot conducive to authentication (even the optimized method), where the imped= iment to authentication is due to the implementation details specific to that ve= ndor or system.=C2=A0

    =C2=A0

    I believe all these issues were address during the me= eting. Are there any specific questions that I missed or any recommendation= s for the method in which the requirements can be addressed?=C2=A0=

    =C2=A0

    Thanks,

    Ashesh

    From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com= >
    Sent: Thursday, March 29, 2018 4:09:32 AM
    To: Jeffrey Haas
    Cc:     rtg-bfd@ietf.org
    Subject: Re: WGLC BFD Authentication Drafts

    =C2=A0

    Dear WG Chairs, et. al,=C2=A0

    I cannot support WG LC for=C2=A0draft-ietf-bfd= -optimizing-authentication as my comments at BFD WG meeting dating back to IETF-98=C2=A0still not have been addressed nor even there was an attempt to address. As I'= ;ve asked to clarify impact of the proposed mechanism, particularly periodi= c authentication, on the BFD State Machine, I'd point that the proposed= mechanism directly affects BFD security as discussed in RFC 5880 and the section Security Considerations in the do= cument, in my view, does not adequately reflects that and doesn't expla= in how the security of the BFD session maintained when the periodic authent= ication is in use.

    =C2=A0

    Regards,

    Greg

    =C2=A0

    On Wed, Mar 28, 2018 at 7:38 PM, Jeffrey Haas = <jhaas@= pfrc.org> wrote:

    Working Group,<= br>
    The authors of the following Working Group drafts have requested
    Working Group Last Call on the following documents:

    https://tools.ietf.org/html/draf= t-ietf-bfd-secure-sequence-numbers-01 https://tools.ietf.org/html/dr= aft-ietf-bfd-optimizing-authentication-04
    https://tools.ietf.org/html/draft-ietf-bfd-sta= bility-01

    Given the overlap of functionality, WGLC will conclude for the bundle
    simultaneously.

    Authors, please positively acknowledge whether or not you know about any IP= R
    for your documents.=C2=A0 Progression of the document will not be done with= out
    that statement.

    Last call will complete on April 20.

    -- Jeff

    =C2=A0

    =C2=A0

    =C2=A0


    --00000000000046826505696f9213-- From nobody Tue Apr 17 08:06:19 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 09D491242F7; Tue, 17 Apr 2018 08:06:18 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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=nokia.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 IPle5OxCpMWe; Tue, 17 Apr 2018 08:06:15 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::720]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15BAD1200C5; Tue, 17 Apr 2018 08:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KFNdYXHOnny4aGWV9zz6Qok3CX6/vC5Vb5TCT/dVJK0=; b=qIKzvYjFOpm/ng+oP4lXAkyjvJHwuEjnwX2bZN9ZYT4njVvxfeT72oqrDm3DCKm5KX+WYDJRQxcb6B9rjYQo4RWNyIgUopbOH06mQ371xzQU1ML/fGJUOSGWZsrG0OCjFjn+c0FrxZWNpwde1B3rR5UNSo8LCkagaW/Wz4mDkV0= Received: from [IPv6:2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65] (2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65) by VI1PR0701MB2141.eurprd07.prod.outlook.com (2603:10a6:800:30::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.8; Tue, 17 Apr 2018 15:06:12 +0000 From: Martin Vigoureux Subject: AD review of draft-ietf-bfd-multipoint-14 To: draft-ietf-bfd-multipoint@ietf.org Cc: rrahman@cisco.com, bfd-chairs@ietf.org, rtg-bfd@ietf.org Message-ID: Date: Tue, 17 Apr 2018 17:06:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Originating-IP: [2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65] X-ClientProxiedBy: VI1PR0602CA0018.eurprd06.prod.outlook.com (2603:10a6:800:bc::28) To VI1PR0701MB2141.eurprd07.prod.outlook.com (2603:10a6:800:30::10) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:VI1PR0701MB2141; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2141; 3:7AjVkarSG0xGPGE06hv5ktH2O8qFsMS+hNWz9PjrAQDIHnKTLR1q/im2H6ayAmTNBKcozECvhv6u6INDs8drM2iOqTOz/+D5AIZQlT97dDZ7lzqdnKVY3+NjAgly9z3stxGQNMx6bQ1QEuK9lNwq0DrrN8eZU9nOVcOwnUy6v6IyinZ40jH7Zre6dvgnSFlZwNnF7brWXR9wlN1y2LE1KD9MKD6tmZoKdcpzEBwzwBH/g66qY2CtmzhJETIt64Gf; 25:4FN0RWH/3qaYiCuhWwDVzYoKDPRVqDIf3V2Gbr1qutog63Ie+tpSEeSAhtXFLbPZGhsLgx06WxLJFixjdh0WR+Vf+BG7a/gLUH5pAfQS/5eg4pQQlbH0lFc3e0hDjscaIFiGIejM5Cpy8Te8rswMl8/qtVI2mFVfJ6MRDwwYmHl4wV3CyESibb0lrQfceiP+mfruH4aHij7KRLAwRRduel+TOAMoYvmENQ5U+B0wR6E8TXIqAZclRansLYS26o9rQo+qzWhHi04/vv7x/Pzhmkv37h6K9xhwR/XZ7B9R0v1WPuTbDAqyL0IyOqt+Qb+/y9XN2iLf2acqjjMH9nolbg==; 31:LQNxFCIqh0nY2HxI9Uc4tZI8ZeRZH/hnPGvnaPQiqSGcj9Hr7bgxyNBdqrqohUkLkTBO0ThbHfwsiBpUW/Ygbes23o9aIfnIm/CRcz+463x5bnW6sCwt9aZ1S2LGi1cIXsskdrpRuYgavvhKATV8fmewnYNnfn+2ufFbroLpuLxeZbrgAGkuU+YsVmaSZPhZSOTNkBb0kYt+d8y2f7GAizo8edaojsLKRWAqwkqVeCk= X-MS-TrafficTypeDiagnostic: VI1PR0701MB2141: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2141; 20:GnbDsInrExkVtmH5icJRAXCr9KqGaWBSj0CauBzGmhJ+rC3WHYyCSw0CR5WJHN10CImq8nsv5yLOUTtHZcgvCKqeZX6jpLV6YTOugTOVZjXyuLUPnHEit1ImUtl3WteK2/bM2VEpINT13yc1iWJ0ERu8pNGqCau7ZD54mPorBCBmRlC2TnPEP521vLIt9iNGlBZ89tuTIMu7yGuY8eLVaU7w6CqbqPCb9WS1rMbq2H8PGhCceUhnRZtvkoKqcsnLJUEygXG0LXSRW5tThti8vx5mQ4RehkxGU8yM2TMSHpMrQhTkHVlPAuHJVPBpAMsWNq3NDyjBQM559JgyZetjuUYjADKLAqhZSH9m9blg+TvWR212S4gIPcwSE/TrNsy4A8J+FCVotr6vjJ3GOOpy2BK4R4Q3NO+24nEsYxjTAcYnR+cyKcI0+byu9DIe29c2Vnpj69ydofI3iOUHB4aSY93Y2YtO4H8ayZpGFjk11bVNuyQEV9t7+ezcqHnituIb; 4:QQDxzk25VOz+5DKzv7nban4pDbZT6s/t/9mDkSbCqq2rp+pUQoL80hf/2PbQR4puolzxtdz6n7Zgcl0GmMeS88pi3xnIRep/C+t2/rTmy6D1PFarOjIQRL+so0Ve76vPo9Soh1SSpgyAdk/Sb2dqshxRMqjYfyV+jY4j4P5ezCHKuPM5KxOKghauwDUg4byoJW5kwKLdEMvGKyo4GgabBSGwJkDFIjaiRfotBnqaP2mUWaliQ4zNj7IUQAlBnRayJz1WP4QlRnzC0avxtFtVzQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231232)(11241501184)(806099)(944501359)(52105095)(6055026)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:VI1PR0701MB2141; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2141; X-Forefront-PRVS: 0645BEB7AA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(396003)(346002)(39380400002)(366004)(54094003)(199004)(189003)(25786009)(86362001)(3260700006)(4326008)(81166006)(97736004)(8936002)(8676002)(81156014)(50466002)(6306002)(31686004)(2361001)(2351001)(6116002)(316002)(230700001)(105586002)(64126003)(36756003)(31696002)(58126008)(345774005)(2906002)(6486002)(65826007)(5660300001)(59450400001)(7736002)(305945005)(1706002)(2486003)(44832011)(386003)(46003)(6666003)(476003)(106356001)(67846002)(16526019)(186003)(68736007)(52116002)(53936002)(52396003)(65956001)(52146003)(478600001)(2616005)(486006)(966005)(6916009)(47776003)(65806001)(23676004); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2141; H:[IPv6:2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3MDFNQjIxNDE7MjM6QWRPNGh2M01SNjBDYXZqVUc2KzZKWWli?= =?utf-8?B?MTNKRHd6aWxJczcwWjRDbDh0a29acUUvcitJekpNMm5xQXh2RXlCNWloM3Vu?= =?utf-8?B?Qmo2SCtRdzB3SGExdjlrMHZZcSsvOTF3UGZwUWR3VnRqTWlaMUZ5RDJHbmlh?= =?utf-8?B?L0RCeWRUMy8vUXp4a2lPYmFwS0xiK3BDZm1JTXlNTlFjNXYrb29mQUg5c25q?= =?utf-8?B?OHBuM3l2aCtJTFVDTkFYSlJiQytTUUE0MUtXTHc0YmNodno5bXV2QW5EaVky?= =?utf-8?B?RzhvN0dCclRnNU9QUGh5MmpiR29SUG1zSHZiZmk2QlluTEZzNFJiS29MNFMz?= =?utf-8?B?VGsvVkRYc0VXN1BXTFBSM3ZoTHpzSXRQWUpIa3JmQXdVMm4wMHBqYUhlQ2hH?= =?utf-8?B?VzJFbC9SaUdFTWlNVGsvZWVQQWdsVXg5YlpvRGVPNVlaMWRLODJxbUJuZkNY?= =?utf-8?B?eEc5cGRQSG0yK0R1YldjSCtSazFRb3NCRjR2RnNGdkdQSlpyV0FaSFNxb2Np?= =?utf-8?B?a0J3QndEeUxXbWFjdEt6bE1rbUdwNlZjdm5OTTNaN2NzaERmVG5ZZnVhV01n?= =?utf-8?B?OVNSQ3dMMzNwaG8rVW1FQzNQRUNrUGFQSHFaZjVoczh1VnUyWjl3TWtGbEdu?= =?utf-8?B?Uytya2w2UUFPMDhkdHpVaDFwZWQ0dU9ZRXd6MCtOYkdoY3VrbTUrQUtWYnkr?= =?utf-8?B?SnVRS1FhNmliVkRlUlZiKzExY0V6anFhVHlMbzVRMTdaZzVOeG1qSzVBVWh0?= =?utf-8?B?ckZCeDFpSGZ5VHBPWUpraVU0c0JsaFpDanJXTmUwQlNUbFFSR0ppVS9YMHQx?= =?utf-8?B?eUxHc3d6a2E1Slk2RjBMQ3BleFR3RDZNUm1xMXQycm5mV0JBTk5WK0UxdVZL?= =?utf-8?B?NDUvRmdKanZVMHRGS1JQMnRkMllwd2N6QkRjUEMwcUU5RFJuWjR1MGRNQVlu?= =?utf-8?B?SEFvWGtFa0pNVDRPQmJtWlZOSmNRS1FtTk1PUnlSM3VxN2NlRUh1em1wYnZi?= =?utf-8?B?czF4VkEwenJQd3dXdk1EaWxmdDBNN1dMUUk3WFEwQ2ptMFBIZGlRN1pKSEhL?= =?utf-8?B?aEdCdVY0QisyWDhNdmpPRWZnY210ZkljUmp1Tng5S0lhay9uRm1kdmhaMVZC?= =?utf-8?B?elR1TzNqOW8xTmxyK1NmRUxaZkNmbFhOVHB6NFo0UEU2YTJ2Z29IZlVSbDJy?= =?utf-8?B?K0g1TXBtS1RIWmROOExNQUV6ZjEwN0lUOERpSlVnNVlJeE9ucGlVbmdMRkpJ?= =?utf-8?B?QkxOVEpXS25ON0JWS2puejR5SzhOQTVTQ1VKbUl4Zm54ekwzOUZHSy95MEg5?= =?utf-8?B?VER0ZENsVkorcEtVejhsU2laQXZkMHNrK0IxYlBqd1poL3VjeldYQ0Z1UEJY?= =?utf-8?B?bng3VVpTZ0x3K0dNc3MxMW9TS1orRE9lbVRCT2RWTk1MVi9wOEtzSXJhUWtt?= =?utf-8?B?Z3JMSVZXa3NiTDNvK0pVQzBzRDFaU2hVaHQxQ3ZVK01rVi9GWVhVajBOK1Nv?= =?utf-8?B?cVZBVVVYbHhrbWJPVTFLSHg0MGtodWJURXNRK3kyR285eXdHMWowWmswRy9J?= =?utf-8?B?NUJ2NVo0SVhlQjNrYTNDNzY2UWM3bGsrKzFBekkybEJ0OE9ZWXNaTG9lY3g2?= =?utf-8?B?d3NFUmo3NGYvZTh1bzNsM1R0cmhzeHRIVFZKeDk3N1FWMFB0Yk1YaWw5bXNz?= =?utf-8?B?Y2l5eHgwTVNBYkMrUnVNMkZhMXVBWjFaMmlwaThoVGsvNzdveWFwWWo5dlpm?= =?utf-8?B?b1B4VnAvakZ4Snk4Z0ZWNXhOV3ZpaDM0N3RXdzE4dER6SU5xa1E4SC9ZMHMx?= =?utf-8?B?RVNZQWtaVjZyVUwwSWlIZnBEWWRCZHFzR0k3YzBLcVVLTWMzdFNyZnF6ZDhi?= =?utf-8?B?dmFuekdLZk50K3lxY0paVmt2YXRJRTJOWGVxUFFmMW9oZ3YvQU5ZamJXWnFT?= =?utf-8?Q?SodukIKR74V0CpJeYyxULqXCfbVuVGBM=3D?= X-Microsoft-Antispam-Message-Info: GBLbiXnesxA6xYv9AYY/l1AjGfc0dzrrxUEiOQfTnEbzsg59/Fm16EQhduJegowqzmbu69spOZ4SzFYlMhwKwxu7mZ265XjWfcApdFpWzVuKT/gsRTEcKyF28nkXfaWc+kiU2T+bEyfYTpL4/Vx3aqk/O+5AKFGzdTiUN8B+21uM2RGpJWHvLBMiL6Wtq0gLg/hMq6+k59DcTuZfznxTPsjMThhnZV+xfzyAnWDlGq5+DMQf6VQYCApJTGw3G2O6 X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2141; 6:hpLDu0bLyE63CNfiAH/YosoCy+Tz6Ijrnrldvd19WNpJC0yEnOGvSVV2qBboh76JnYGOHx6UmFT13o3wlVIBcXwVxafdhjHnL60JY9gIjIVXwvHjAoV+S4zXonpF1/b5DB/6wHjEH65/mK3+nhrUs430Zu/ok7MK18ml7xZKBoNq/DpfyFt+8i0wp5jWYwWyMhg815G7oZwl60x43EbWXBwVFjNxMMqrmC8DPGuKV9ZebKYGMfcwOuZr4qHT8OZrM7lY9PWxfqDW3FWjOBR+5q7esvEDca87YJ6vOd1ysUIKTSsQkGng651ot7fxmmAaE1wcqNFXo+WcVGhJM5NqIrYpd6hbKlCGoOhlkA0b5RWEcNrHa6QmThvmCTJ0UFOCMehaMjV2p187Gmfp4Pe9pFb7ZNH3+wIShABR+da0UCJfp+N1kOf0FOfQ8ruSGF5ceh0WC0bbt4X2YABm4GtM6Q==; 5:kIjB2WhATdZrccMK6h2PNb2LxeBGV4rZAt81hFSBuY3gSmhuY44QPJCod68fjbIxK42rfh/aYZN17aRKw48M5EzfU5rqKb3rqQQWpSq9GrSYIKGSHw5L5fc/btW+FFZ9Yu3yyKFG6ZNjM7U39nue8CJJikYh0aNaPns5OxbqcHs=; 24:w8L+y8qUZHU7GaGtGATUfzi2MrzFy3A8cCvrQ6lVG4fybGU8rf7cwyfGS6j92aP+VoM2PvJ+OWmmo8EKgY3E/fP6gQxQ/l5Ig7uO8K/lBJ8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2141; 7:ICCm+tngfr9Ue7g2RvCUXujV3mA/jJNuc4Qw2i3MxL8P6Rw8OVy8x0ym4/5nCWdpEQ3TeXiydmJ8nUD2JzuDW5DDOaFXswer42hqWs96b36yOc8uvgRLOh/L9MPnbEENtmd3+6REiFyaGDBg0OiaHLp7+7JlVBb4lr0VySYdl+aWbn1cBpwJFcKGqnP9YfmTbAdZQVQtkppkY4JyMgBaHreOvw5P/61bRE1CyIDrsYEdk/n3ZfpXjYmpIKFZcskZ X-MS-Office365-Filtering-Correlation-Id: 2285e4d2-c331-4285-5f41-08d5a474c252 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2018 15:06:12.4421 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2285e4d2-c331-4285-5f41-08d5a474c252 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2141 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: Tue, 17 Apr 2018 15:06:18 -0000 [resend, wrong bfd wg address in first attempt ...] Authors, WG, thank you for this document. It is clear and well written. I didn't find any technical comment to make so I've been nit picking :-) Please find those comments below. regards, martin --- Please check and address the nits: https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-bfd-multipoint-14.txt On that aspect, does this document really update 7880 as the header says? The Introduction only refers to 5880 and it is not clear in the body of the Document what effectively impacts 7880. The only thing I saw is the addition of new session types but that does not require an update in my opinion. Could you clarify? i.e. existence of a path between the sender and the receiver. do you mean "forwarding path"? Section 2. and Section 3. seem a bit redundant. They both state the same thing but from a different angle. Not critical. Although this document describes a single head and a set of tails spanned by a single multipoint path, the protocol is capable of supporting (and discriminating between) more than one multipoint path at both heads and tails. There is no text to describe how one could achieve that. Wouldn't it be worth adding some? Point-to-point sessions, as described in [RFC5880], are of type PointToPoint. Does this really fit in Section 4.2 which looks to be about the mpBFD session model. Sessions of type MultipointHead MUST NOT send BFD control packets with the State field being set to INIT, and MUST be ignored on receipt. English is not my native language but I wonder if this really says what you want. It seems that "Sessions" is the subject of "MUST be ignored" while I think it's the packets which are the intended subject. So I'd write: and those packets MUST be ignored on receipt. Because there is no three-way handshake in Multipoint BFD, a newly started head (that does not have any previous state information available) SHOULD start with bfd.SessionState set to Down and with bfd.RequiredMinRxInterval set to zero in the MultipointHead session. To shut down a multipoint session a head MUST administratively set bfd.SessionState in the MultipointHead session to either Down or AdminDown and SHOULD set bfd.RequiredMinRxInterval to zero. The In both these paragraphs one could read that the head "SHOULD set bfd.RequiredMinRxInterval to zero" while 4.4.2 says MUST. Clarification needed? s/M, P bit/M and P bits/ --- From nobody Tue Apr 17 09:35: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 4DB1F1200F1; Tue, 17 Apr 2018 09:34:59 -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 W7nGrDZ8uGTr; Tue, 17 Apr 2018 09:34:56 -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 E0F26127599; Tue, 17 Apr 2018 09:34:55 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id v207-v6so28256919lfa.10; Tue, 17 Apr 2018 09:34:55 -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=bjNauIQHPc1C2c3okMn2r8ug82EqFXU9v3qQ01HkKFY=; b=HLb/76wM3WKp413Gz5Nw8EzLOt0Aw4p+V2JInQ+9e7QYywPvAEHe5tFQAE6mAYv60v L17yOfjB8uKoYNQgVdYRkIHrFZWiaDxFI1niFBCdznwzTU8fxKBoZNwZgatKCCHAQ/eN /Et60Q6qFg54iVGsPqIJcTjWOSGFkMfHPRO8wY88xbZWb/DWlSJVghYLvihu8YT35OEu osWx51DFoE9pKDrdZPStDuZ59p6qZpTiiEfMeEmoeLNVbbOBTvq1Y/7wxDXId+46rdZk kQyQoq5BzrD0vVGGAxJ/pGt1T4hp/5VPAMrwM2MX9nc+Cmb90v8EvbeiFoGJ+1iGxcmz haXA== 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=bjNauIQHPc1C2c3okMn2r8ug82EqFXU9v3qQ01HkKFY=; b=ZoAOHtWKXXVp74/sp0mbYlccMY2/n8p0Pdsbco/6seFFd0CWolcNwrjOtBndeJwsZL mPN/TfJ5W+63bfLvdaz8qLu0cBRa19BfW3LW8bFeh9Ba7J5/sloYlAMcu7D0tlez72lj AAAy7ybdoVyn+z8FchoFZ6GIfUBjC4xOCuIAZQI2LHXtq5Qla3wjKqy+FM8yVga7r1RL T5F+4f+sjLrynQpCYlv0bwRqz9NaAVjWBE5/qiTl06ofwhdhM+Cg0ZMmpDnR0UXidwqk UpZxrTnn8fhV8RQplH3TuCVTYPNd+Or7atd2wJF2gPeHAvGpGRVdXVQoAXUmxF2ojmTC A+WA== X-Gm-Message-State: ALQs6tCkB3wR61FGwzQAHBP+AQTP/wGYQK+LuM9dz+Xba834luz04SYb KxwJ7JnXiqf2QiFADucQOW+Fi1vAedGFO2WLHk0= X-Google-Smtp-Source: AIpwx4/NNHS74EpWBCyL56fssk3cwDFcUEOTFjUJsTlPjNaXnz6/qVOujL+2w5PacBNDFnEFZzyZwVtB5j7q+436LEU= X-Received: by 10.46.131.197 with SMTP id s5mr1961088ljh.72.1523982893811; Tue, 17 Apr 2018 09:34:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.73.66 with HTTP; Tue, 17 Apr 2018 09:34:53 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Tue, 17 Apr 2018 09:34:53 -0700 Message-ID: Subject: Re: AD review of draft-ietf-bfd-multipoint-14 To: Martin Vigoureux Cc: draft-ietf-bfd-multipoint@ietf.org, "Reshad Rahman (rrahman)" , bfd-chairs@ietf.org, rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary="f4f5e80c39dc078da7056a0deb9d" 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: Tue, 17 Apr 2018 16:34:59 -0000 --f4f5e80c39dc078da7056a0deb9d Content-Type: text/plain; charset="UTF-8" Hi Martin, thank you for your thorough review, thoughtful comments and kind words. Please find my answers to your questions in-line and tagged GIM>>. Regards, Greg On Tue, Apr 17, 2018 at 8:06 AM, Martin Vigoureux < martin.vigoureux@nokia.com> wrote: > [resend, wrong bfd wg address in first attempt ...] > > Authors, WG, > > thank you for this document. It is clear and well written. > I didn't find any technical comment to make so I've been nit picking :-) > Please find those comments below. > > regards, > martin > > --- > Please check and address the nits: > https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/ > draft-ietf-bfd-multipoint-14.txt > > On that aspect, does this document really update 7880 as the header says? > The Introduction only refers to 5880 and it is not clear in the body of the > Document what effectively impacts 7880. The only thing I saw is the > addition of new session types but that does not require an update in my > opinion. Could you clarify? > GIM>> Yes, you'correct, the only connection to RFC 7880 are the new values > of bfd.sessionType. The proposal to list RFC 7880 as updated by this > specification was inteded to address Errata to RFC 7880 > . > > i.e. existence of a path between the sender and the receiver. > do you mean "forwarding path"? > GIM>> Yes. Updated to > i.e. existence of a forwarding path between the sender and the receiver > Section 2. and Section 3. seem a bit redundant. They both state the same > thing but from a different angle. Not critical. > > > Although this document describes a single head and a set of tails > spanned by a single multipoint path, the protocol is capable of > supporting (and discriminating between) more than one multipoint path > at both heads and tails. > There is no text to describe how one could achieve that. Wouldn't it be > worth adding some? > GIM>> The question of applicability of this specification to mp2mp scenario came up at BIER WG meeting in London. Perhaps we can say the these questions are ouside the scope of this document and discuss whether there are interested to work on mp2mp case as a separete document? > > > Point-to-point sessions, as described in [RFC5880], are of type > PointToPoint. > Does this really fit in Section 4.2 which looks to be about the mpBFD > session model. > GIM>> I think that this short reminder is helpful to explain why this document adds value PointToPoint, section 4.4.1, to the defined in RFC 7880 bfd.sessionType variable. > > > Sessions of type MultipointHead MUST NOT send BFD control packets > with the State field being set to INIT, and MUST be ignored on > receipt. > English is not my native language but I wonder if this really says what > you want. It seems that "Sessions" is the subject of "MUST be ignored" > while I think it's the packets which are the intended subject. So I'd write: > and those packets MUST be ignored on receipt. > > > Because there is no three-way handshake in Multipoint BFD, a newly > started head (that does not have any previous state information > available) SHOULD start with bfd.SessionState set to Down and with > bfd.RequiredMinRxInterval set to zero in the MultipointHead session. > > To shut down a multipoint session a head MUST administratively set > bfd.SessionState in the MultipointHead session to either Down or > AdminDown and SHOULD set bfd.RequiredMinRxInterval to zero. The > In both these paragraphs one could read that the head "SHOULD set > bfd.RequiredMinRxInterval to zero" while 4.4.2 says MUST. Clarification > needed? > GIM>> Section 4.4.2 mandates initialization of bfd.RequiredMinRxInterval and, I think, applies to the first paragraph you've pointed. Would the following be clear and consistent: Because there is no three-way handshake in Multipoint BFD, a newly started head (that does not have any previous state information available) SHOULD start with bfd.SessionState set to Down and bfd.RequiredMinRxInterval *MUST be* set to zero in the MultipointHead session. The second paragraph describes manipulation with the value of bfd.RequiredMinRxInterval which process, as noted in section 4.10, "is outside the scope of this document". That may be reason to use SHOULD and not MUST. > s/M, P bit/M and P bits/ > GIM>> Thanks, done. > --- > --f4f5e80c39dc078da7056a0deb9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Martin,
    thank you for your thorough review, thought= ful=C2=A0comments and kind words.
    Please find my answers to your = questions in-line and tagged GIM>>.

    Regards,=
    Greg

    On Tue, Apr 17, 2018 at 8:06 AM, Martin Vigoureux <= ;martin.vig= oureux@nokia.com> wrote:
    [resend, wrong bfd wg address in first attempt ...]

    Authors, WG,

    thank you for this document. It is clear and well written.
    I didn't find any technical comment to make so I've been nit pickin= g :-)
    Please find those comments below.

    regards,
    martin

    ---
    Please check and address the nits:
    https:= //tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-iet= f-bfd-multipoint-14.txt

    On that aspect, does this document really update 7880 as the header says? T= he Introduction only refers to 5880 and it is not clear in the body of the = Document what effectively impacts 7880. The only thing I saw is the additio= n of new session types but that does not require an update in my opinion. C= ould you clarify?
    GIM>> Yes, you'correct, the only connection to RFC 7880 are the n= ew values of bfd.sessionType. The proposal to list RFC 7880 as updated by t= his specification was inteded to address Errata to RFC 7880.= =C2=A0

    =C2=A0 =C2=A0i.e. existence of a path between the sender and the receiver.<= br> do you mean "forwarding path"?
    GIM>> Yes. Updated to=C2=A0
    <= blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px">
    i.e. existence of a fo= rwarding path between the sender and the receiver=C2=A0

    Section 2. and Section 3. seem a bit redundant. They both state the same th= ing but from a different angle. Not critical.


    =C2=A0 =C2=A0Although this document describes a single head and a set of ta= ils
    =C2=A0 =C2=A0spanned by a single multipoint path, the protocol is capable o= f
    =C2=A0 =C2=A0supporting (and discriminating between) more than one multipoi= nt path
    =C2=A0 =C2=A0at both heads and tails.
    There is no text to describe how one could achieve that. Wouldn't it be= worth adding some?
    GIM>> The questi= on of applicability of this specification to mp2mp scenario came up at BIER= WG meeting in London. Perhaps we can say the these questions are ouside th= e scope of this document and discuss whether there are interested to work o= n mp2mp case as a separete document?=C2=A0


    =C2=A0 =C2=A0Point-to-point sessions, as described in [RFC5880], are of typ= e
    =C2=A0 =C2=A0PointToPoint.
    Does this really fit in Section 4.2 which looks to be about the mpBFD sessi= on model.
    GIM>> I think that this sh= ort reminder is helpful to explain why this document adds value PointToPoin= t, section 4.4.1, to the defined in RFC 7880 bfd.sessionType variable.=C2= =A0


    =C2=A0 =C2=A0Sessions of type MultipointHead MUST NOT send BFD control pack= ets
    =C2=A0 =C2=A0with the State field being set to INIT, and MUST be ignored on=
    =C2=A0 =C2=A0receipt.
    English is not my native language but I wonder if this really says what you= want. It seems that "Sessions" is the subject of "MUST be i= gnored" while I think it's the packets which are the intended subj= ect. So I'd write:
    =C2=A0 =C2=A0and those packets MUST be ignored on receipt.


    =C2=A0 =C2=A0Because there is no three-way handshake in Multipoint BFD, a n= ewly
    =C2=A0 =C2=A0started head (that does not have any previous state informatio= n
    =C2=A0 =C2=A0available) SHOULD start with bfd.SessionState set to Down and = with
    =C2=A0 =C2=A0bfd.RequiredMinRxInterval set to zero in the MultipointHead se= ssion.

    =C2=A0 =C2=A0To shut down a multipoint session a head MUST administratively= set
    =C2=A0 =C2=A0bfd.SessionState in the MultipointHead session to either Down = or
    =C2=A0 =C2=A0AdminDown and SHOULD set bfd.RequiredMinRxInterval to zero.=C2= =A0 The
    In both these paragraphs one could read that the head "SHOULD set bfd.= RequiredMinRxInterval to zero" while 4.4.2 says MUST. Clarification ne= eded?
    GIM>> Section 4.4.2 mandates i= nitialization of=C2=A0 bfd.RequiredMinRxInterval=C2=A0and, I thin= k, applies to the first paragraph you've pointed. Would the following b= e clear and consistent:
    =C2=A0 =C2=A0 =C2=A0Because there is no three-way handsh= ake in Multipoint BFD, a newly
    =C2=A0 =C2=A0s= tarted head (that does not have any previous state information
    =C2=A0 =C2=A0available) SHOULD start with bfd.SessionStat= e set to Down and=C2=A0
    =C2=A0 =C2=A0bfd.Requ= iredMinRxInterval MUST be set to zero in the MultipointHead session.=
    The second paragraph describes manipul= ation with the value of=C2=A0 bfd.RequiredMinRxInterval which process, as noted= in section 4.10, "is outside the scope of this document". That m= ay be reason to use SHOULD and not MUST.

    =

    s/M, P bit/M and P bits/
    GIM>> Thank= s, done.=C2=A0
    ---

    --f4f5e80c39dc078da7056a0deb9d-- From nobody Tue Apr 17 09:49:50 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 95538127599; Tue, 17 Apr 2018 09:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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=nokia.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 FYtRWh-8AryY; Tue, 17 Apr 2018 09:49:46 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0137.outbound.protection.outlook.com [104.47.1.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B50E126DEE; Tue, 17 Apr 2018 09:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WNFx1BuYD8yhUnO/a2cnDQTYvndDHBw7Im6lWaalF+8=; b=TbffxrVJB/Of2C3ldYlijUv7WY/z+n91iM1X7e6Dzt5aq3lWlOZbG4HInIRyFvvdSbX+K/USpzuROO/jFK14kmeIIEASw88r3REgcB3E9NBSLM40JzNSj9LMi+BQ3uKbtiF3PJwj6EnYfQ5ewVWxDmo1ycPihFU2ftrE9SyEo7s= Received: from [IPv6:2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65] (2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65) by DB6PR0701MB2135.eurprd07.prod.outlook.com (2603:10a6:4:50::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.10; Tue, 17 Apr 2018 16:49:42 +0000 Subject: Re: AD review of draft-ietf-bfd-multipoint-14 To: Greg Mirsky Cc: draft-ietf-bfd-multipoint@ietf.org, "Reshad Rahman (rrahman)" , bfd-chairs@ietf.org, rtg-bfd@ietf.org References: From: Martin Vigoureux Message-ID: Date: Tue, 17 Apr 2018 18:49:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Originating-IP: [2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65] X-ClientProxiedBy: HE1PR09CA0069.eurprd09.prod.outlook.com (2603:10a6:7:3d::13) To DB6PR0701MB2135.eurprd07.prod.outlook.com (2603:10a6:4:50::14) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DB6PR0701MB2135; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2135; 3:fKOFxU6FeemMChri2Rapa1NTk4fKAkDRnbB9LyczxP1/u99Ud9wesIV65fvzxHCvJElvfacLVW1LdkSbjr2aZk4uUwL67zllhjBjDOR63MiqsPCUeoeGLXrubtnnTU5GyR/0Xg58MXX0ArIJCVOvSrUeVXXCfy47od49k6l0dq9S/tTsgeLy8/Y5syAtK9ECRiHulT7Ks8dQ0nU/mNtRUoliJNKQoRi46S6zv2nuAKppxfwsyp6DYsmeylGKDCFc; 25:osPOqwW3oF3seh075uyUGETfvZUQhQTad0adoq30/icH51iFEgrHj4cu+1HM85pikqLOpukMev+V8dtbA6alAY+XcRJlc9xWPqVUwuE4LrHsyiYLuhi2k5MIHDfDJzuekHyLyTOEb6dZqpZhBniy6cCap2ZADcQtKpcZvPcMdoS7GUdG8bWI83njkySxoeL3bxdeZtjqZ8JKryFBRzlQbI83D56tgkQvPe8sDjoM0SdFAUg785Tb3BEJIrS0EcJNl/XpoDZeDSL8Q7AXDQJncCv2K43Jw+ecaG37VwSIN+DDWZRPI+ByPijD0D7g8f/haf78vCx27yEK/KU/4VOsbg==; 31:Z6GpLqV8d9yj9QEdXEgSvJ8HEJlfCsnFtRG8PxgxQjt3Melb4nCdq7BhLjq0LMGHBqvvhw3HHzhdXtDWy1f1SGviETzZFcJVgUFdAU26C7pOgMZlJN6l6vgm5VvFDGXWfpQyjVUJQle6bs1RdZI2ms5sedUseiuDGdd4lWObzeE7vBugyed+7NMl3wxshZT86zD8YhBpK3u/GmumLRvedCZ9tE4BFKgpITF4YmrdtmE= X-MS-TrafficTypeDiagnostic: DB6PR0701MB2135: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2135; 20:KJFx+1ru+B8HZU5q2oLCO7YZXYBV8H3HBodBTXORDYSTHMcyAhRPQK6u2Cb0A8ZKd1RtwAT5JInzF+/DBsajSm2wVJ2byH5UVcb6xNyI4CfIkP3GY1eEHjeYyLDK5CUbvasZK+roG0nJL89qDKFERmg9o5JuBAFFBU5dL5nuAFouhlggDXDekPJbUj5X8x9BydMJVsAUbHzSeuUVCuz991L6bianDBen2FT0WCsGa850fSLVlzeI+//1NcKOEB6/3UOdfxu6xDTSGW6GSPS672Rjo+N9ZDsxGIg6wEI+AlC2T+0QRKn6UbAEFKvRVyYoHgTUCsRwHBYLQQLR33ZqESyoqcSXzaXRZ+Dr8PujwGOMJ3Rs1Vmu4eJA17OxmonqfJ2WW8AhLjmjtmVFaRzK8/okUziWeKLbH1woOW6YbMtcRwlOTEeyoZ/lcq1AgyK4Zvwxo/p2+VYHx48rPtCnvnENu9Jm7VUJDkwCicGj9dUebQVtyrYyBAo5l8gbw8j8; 4:TfgGNXWG+6ryCBeqdeZPwZa5f2tdQjSnO5pqPOGm8fkxd2qt1oMDCZiy5Vci3bR9Xsxov1jBCvFr8sXy5jWZviIquIXbSUWPoMEkAvDpE7l/1jxt/i8XxktrJBScEdXaCULLtOnAmsgtMRFQZ89V9LVFUyFcKKdk3Ptunr6adeoGl7wVGmYimu7db3LfzP+t9Szq3WzQhfq3AWIcuSrJOAQoao1XxlLFLxxPIUMSiPR5/fDTla/MSakbkuPdSIx8hZ+NYUgDAWgFeI1LldX3NspfmDNjrFpS2MOUegSc6dHk2tevNpaJDmuZxRcjX9/R X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(82608151540597); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231232)(11241501184)(806099)(944501359)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DB6PR0701MB2135; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2135; X-Forefront-PRVS: 0645BEB7AA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(396003)(376002)(39860400002)(366004)(346002)(39380400002)(54094003)(51444003)(189003)(199004)(377424004)(16526019)(186003)(46003)(386003)(59450400001)(53936002)(6306002)(2486003)(11346002)(476003)(52146003)(6246003)(39060400002)(561944003)(23676004)(446003)(486006)(2616005)(97736004)(47776003)(76176011)(229853002)(65826007)(16799955002)(6116002)(6916009)(68736007)(52396003)(67846002)(5660300001)(52116002)(305945005)(65956001)(7736002)(65806001)(345774005)(6666003)(1411001)(31686004)(6486002)(106356001)(81156014)(8676002)(8936002)(81166006)(478600001)(105586002)(966005)(58126008)(25786009)(36756003)(50466002)(1706002)(86362001)(31696002)(2906002)(3260700006)(4326008)(2870700001)(316002)(64126003)(44832011); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2135; H:[IPv6:2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3MDFNQjIxMzU7MjM6Y0tuc3FKSEI2M2JwdlBpQi8vdnd5MFhC?= =?utf-8?B?NUh6Y2wwc2FaWEdtYkV4VzExWmVUbG9qOUljdFRlTDJqUTNjb0REWlJtWkN3?= =?utf-8?B?RENmT0hWaG9oQUdQZnNXOGNXMitFMjJlcVRUdXMydDExNFpVTDVicXJWTXNX?= =?utf-8?B?U0lvVTVDclBYMjJycUZBdFlGdS90RkNzaGkvUjJkbmI1alhxR0NxeEJHbE11?= =?utf-8?B?bXUzY0oveHpYSjJhS3JhWW9mbE9vWWJxYVNFSW54K0N0bHlkcVpRUFpoRnlL?= =?utf-8?B?TTVSUFdmcllDU3Q2V0pySWFKRjNXdGF4eDRzWHpwNitzWENGbDcyUEF6UnM5?= =?utf-8?B?NVN1ZlgrNkpub0c3eTVNY0wxNlkrZ2lUUmxmY0RsQ01hNzdyN2hkMTJ1WC92?= =?utf-8?B?d2ZldUR5WkU5OGJLVHdyOXhYZXNiTWJrR3ZHMU5nRmRRUTB1aVJ0Q3puQ09h?= =?utf-8?B?bmlpR0ZYR0lZSk5naHN6NVhLMTcybUExbjhsT05Vd1ppdWkwcWQyZDJvSmNx?= =?utf-8?B?Ky9qWHhFcytnNGRhc1JRM1I1UnNsWEk0bmVoZUo1eTNlUFNFZk5WZjBTUU9G?= =?utf-8?B?VnR1TDBVdDdWQ2gwK0JJRnhZK3NSS0hlcW9YUzFMTjNxbzlpTE1iME9YYXRa?= =?utf-8?B?Rmw3WTZsUHBQYlQvcWVTM2RvMW9oRnhIK0dEY2h4VU5yNFhPeGpqa2ttV2Fu?= =?utf-8?B?dDQ2ejA4RGc2L0E3VmxCRGNtRHJSWXdpZ1c3UWZIQTFyM1pFUU5tTk9BOW12?= =?utf-8?B?SkNMVUs3R04wa1NhMXAyVk9vMUNzTG01Y1EzTCtTY3ByQlNmNWoxTlcvc3U0?= =?utf-8?B?elhvdlpNa3ZpYXVzMTB6VlBEY2MvVWp4aVB3N3Y3VkQ1RGRyaEVGZjdRTWJs?= =?utf-8?B?RG5VMXFiZTdWLzY5dW43eEszQTVGOHQrek9YcXdpaDROcnZYVlhBMit5MzN1?= =?utf-8?B?aHhqVkk4NzJURXNLOEZCTG1yRkxMWGxENVJncitEMzcwblE0T092bXE0dXJv?= =?utf-8?B?Zk9YcWFURTllNDNUN3RFZFF0NnVTREg5MXdnd1I2TVZtZ1dBL0thUCtyR1lJ?= =?utf-8?B?akd2Q0ZvUFpNV1RDY3BrM2VNbEJjQTNiSndEV0toUU50SjQvK00vYS8yYXhY?= =?utf-8?B?UVc0cU5RKytsYm54a2RsN3VLZXEzZ0U2NDBRVHRMS21ZQ0daVWxoZDlpUERk?= =?utf-8?B?WUJPcHRRcWtVTDBpZFNXNllLUHVaL21IeTdsdmFaaG5hNkEzZ3FWK2xLbmQ2?= =?utf-8?B?SkYvRTJZemZIZ2hHZnJVVG5OOThPRk8xRGFtTWdXSjJWbDFYZnRSUjREUUhv?= =?utf-8?B?OTNCeEdsZzJYdGQwa2Z2WHE1amkrb3NUaDNlZVJhM25RRWdGUWZCREwvQVJi?= =?utf-8?B?R3FoMlcwdUVheFhWY0xMQm5LbWR2Ump4Q05meVd0ZlZYSlR0Z3ZrcVRheHJz?= =?utf-8?B?TFhDN3dod3MvOVF1VXpleTllN1RJYWhVeGdIUndFYUw4c3FvemVuUmcvOGVC?= =?utf-8?B?d2RiaGgrdFNDQW9NVmltT00wU0tyaXkxR0ZseElBZlJCMU1vTU5HRkhoaFpw?= =?utf-8?B?bXl5S1JpZDhrQ2cxbTNDcUpoOER4b0d3MTNsNnVzNmpGTnRYOE5uNU9QOW5l?= =?utf-8?B?VGluMUk2WG8rVnZUZlVlN3R2MEpoNFEzdTZJN2hsR3UybUdlZVhsODRmMk85?= =?utf-8?B?TGhyMlIwbWgwcUwzQU9tLzZQZEdJaDBaT2RrUndCalJkeDJVNDNPOHBmeHZT?= =?utf-8?B?UXNHRGFveGlmS2JzUW0yOVVpeUhlMEZtUFFQSmpwN1RCeEZPeHlkM2JlcjVm?= =?utf-8?B?NE5PbGlnc1JEVUwzMzJHejRLMlI1T1BpZmRSNURCQUFjeDBiSmYxYXpQZzhZ?= =?utf-8?B?WVBtd2lYOXBjRTZqeXJKT0tzY3lGb1kya2lZZmh6MFF3b00zZ1dPT1FBQ21n?= =?utf-8?B?dHFmcXBydytzVXF3bHlBZnp2MEFWR3JJVElBR09oVnNyWFE4Snl1SjlTalZP?= =?utf-8?B?b0M0Tmd0eE1pZmljdmI2dmVDU2VNSm9jb0xlNEJOMlVPbjNiaExPajFxOVN4?= =?utf-8?B?Umo1V0dhVkZsMlY2b1I5bEZMYlVhSHNKUmVzdVdFU3RBZlYwK1JrN2YzMnVH?= =?utf-8?B?T1VMZFR2cGRmaDZldHdkT2djT2hSL0pYZ1RnaTRXdk4yWEIrNmxlS01qeXVR?= =?utf-8?Q?bX3lLMlIwYv7SC9a8FWD6zQj4JXDfRaAUAuuhgLRLVxY=3D?= X-Microsoft-Antispam-Message-Info: LdfsC/TL8FPhHrWbw+ntWRwSDMeH5YLBWn3xVa/42LX/dJbs+Z47Mv1c0atn6wt90E8JNuIxt6QquC4HrGLqR/yXQ7whSMOE3OcqGZ7ZLEJAdztBmh4wjIuxhJLIXbd21OdWY+ZKGATF6cyz1WW1yIFZmfPEUzLDA6zUyOhHa34/IJdyUyvi6jTlwTGJcaUsLV+mrnuKw2gpfu6x2LSZxqqN2CX84qvVd6kkwIaOw3RC8q556Pb/eIPZ+J9udJl1 X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2135; 6:IR9NQTKtsq5VnQTo0lUjqJSLY/4tlm0W45ea4QL4KcbZ9R/mIJawffVvc/BIrqZPJZPhfs7v+LKdmTr4TqdSTxPWY2c4Ck7AhRa5THJSNiVHYFg/MlEqWLGzhGKk5HQQF7GGK/gQt/039EpVcW87MlWFqWOBVDEApgYqQb+aIDr/5nSvne21N5M1Pgmg5pCtsPIKZnJp7YoIvTYU2ezuG4l+GwVrKE6LF+JnnPXpk4eOhzSxk6h4nfvR0DlNEeROdtY8Zh/TmqPk44Nx6B/1rP3p2ytaKaoKHBz61gDxzceOpc9Hw6fncUCYcmZueUU4bKfnPy9aXy4YJ+TgYipXPH5iYavmMHmqsq1etYfRzitG4pR82/joDtoRRgW3P1f4W7EshVv2b2zs2ShI/H+d+9+wY3MPbLyrPoODscdnyNINn1swV8yVD3M+kSHNxvN4sgYNxdhVEJqohzdb8FICOQ==; 5:4NBpIVBRDzuhjWNR3Cxt4HiaxRgOH5ub8aiRjRjvo+BbJiYYtZ1fJFjAzDDsjsBgpbGX2EHGqrVgp/HgGeiR9p6iiUEDXcKfgW5PJYbB33f2iEi04SQHq2EMpNY6kA1AcfQGhplxZ6tXDqrxG0WPn8NHGU9wFOZ8kJmH6XhtH30=; 24:Dxf7UVO1OFkthaNtSSygrSI+xIMGr66+M/1qmbpmd7SjdXeMi9mdL74zOXyt1NCoAJYTXD8eOHsmS//TpM3Xp8fv3mWlwFmNXi5tCa4kxcg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2135; 7:B7EGYP+eE22iUNwKoSJFDzcBzNfWg71Mqu0rfTxxQZQgk0T+czVYvjd+AKvCgZI53PzqQMfJXO6TH8hJzPEBfsSp2Qe5h4uo6l/PWG1RmAE3t3tFQ3odxEULjLGhBhfBz3ZeYIF1VtnyeA8PbAAO1VdzwJ+qbHKKHZ1T19/fDVXzmaMBlciiZ53chaZrTKizMVg46jIfdNRbiHdh/Sj7QTBbUIZNcZ6oGIILjY7useEGqZ4/UNrdSOoggfmMGS0e X-MS-Office365-Filtering-Correlation-Id: b0662cba-2efb-454d-7bc9-08d5a483384a X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2018 16:49:42.8314 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b0662cba-2efb-454d-7bc9-08d5a483384a X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2135 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: Tue, 17 Apr 2018 16:49:49 -0000 Greg, thanks. please see in-line. once I see the update published I will request IETF LC. -m Le 2018-04-17 à 18:34, Greg Mirsky a écrit : > Hi Martin, > thank you for your thorough review, thoughtful comments and kind words. > Please find my answers to your questions in-line and tagged GIM>>. > > Regards, > Greg > > On Tue, Apr 17, 2018 at 8:06 AM, Martin Vigoureux > > wrote: > > [resend, wrong bfd wg address in first attempt ...] > > Authors, WG, > > thank you for this document. It is clear and well written. > I didn't find any technical comment to make so I've been nit picking :-) > Please find those comments below. > > regards, > martin > > --- > Please check and address the nits: > https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-bfd-multipoint-14.txt > > > On that aspect, does this document really update 7880 as the header > says? The Introduction only refers to 5880 and it is not clear in > the body of the Document what effectively impacts 7880. The only > thing I saw is the addition of new session types but that does not > require an update in my opinion. Could you clarify? > GIM>> Yes, you'correct, the only connection to RFC 7880 are the new > values of bfd.sessionType. The proposal to list RFC 7880 as updated > by this specification was inteded to address Errata to RFC 7880 > . I am not sure how this document relates to or addresses the errata. So I still think it does not update 7880. > >    i.e. existence of a path between the sender and the receiver. > do you mean "forwarding path"? > GIM>> Yes. Updated to > > i.e. existence of a forwarding path between the sender and the receiver thx > > Section 2. and Section 3. seem a bit redundant. They both state the > same thing but from a different angle. Not critical. > > >    Although this document describes a single head and a set of tails >    spanned by a single multipoint path, the protocol is capable of >    supporting (and discriminating between) more than one multipoint > path >    at both heads and tails. > There is no text to describe how one could achieve that. Wouldn't it > be worth adding some? > > GIM>> The question of applicability of this specification to mp2mp > scenario came up at BIER WG meeting in London. Perhaps we can say the > these questions are ouside the scope of this document and discuss > whether there are interested to work on mp2mp case as a separete document? I don't read this part of the document as talking about mp2mp but rather as talking about multiple p2mp trees. > > > >    Point-to-point sessions, as described in [RFC5880], are of type >    PointToPoint. > Does this really fit in Section 4.2 which looks to be about the > mpBFD session model. > > GIM>> I think that this short reminder is helpful to explain why this > document adds value PointToPoint, section 4.4.1, to the defined in RFC > 7880 bfd.sessionType variable. Well, I would move the text to 4.4.1 then, but not critical. > > > >    Sessions of type MultipointHead MUST NOT send BFD control packets >    with the State field being set to INIT, and MUST be ignored on >    receipt. > English is not my native language but I wonder if this really says > what you want. It seems that "Sessions" is the subject of "MUST be > ignored" while I think it's the packets which are the intended > subject. So I'd write: >    and those packets MUST be ignored on receipt. You chose to ignore that one or simply missed it? > > >    Because there is no three-way handshake in Multipoint BFD, a newly >    started head (that does not have any previous state information >    available) SHOULD start with bfd.SessionState set to Down and with >    bfd.RequiredMinRxInterval set to zero in the MultipointHead session. > >    To shut down a multipoint session a head MUST administratively set >    bfd.SessionState in the MultipointHead session to either Down or >    AdminDown and SHOULD set bfd.RequiredMinRxInterval to zero.  The > In both these paragraphs one could read that the head "SHOULD set > bfd.RequiredMinRxInterval to zero" while 4.4.2 says MUST. > Clarification needed? > > GIM>> Section 4.4.2 mandates initialization of > bfd.RequiredMinRxInterval and, I think, applies to the first paragraph > you've pointed. Would the following be clear and consistent: >    Because there is no three-way handshake in Multipoint BFD, a newly >    started head (that does not have any previous state information >    available) SHOULD start with bfd.SessionState set to Down and >    bfd.RequiredMinRxInterval _MUST be_ set to zero in the > MultipointHead session. > The second paragraph describes manipulation with the value of > bfd.RequiredMinRxInterval which process, as noted in section 4.10, "is > outside the scope of this document". That may be reason to use SHOULD > and not MUST. Yes, i'd live with that. But then you might also want to clarify in 4.4.2.: OLD: This variable MUST be set to 0 for session type MultipointHead. NEW: This variable MUST be initialized to 0 for session type MultipointHead. > > > > s/M, P bit/M and P bits/ > > GIM>> Thanks, done. > > --- > > From nobody Tue Apr 17 11:55:34 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 B743A12D95F; Tue, 17 Apr 2018 11:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.297 X-Spam-Level: X-Spam-Status: No, score=-1.297 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_LOW=-0.7, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, 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 U8WfKnipm1xy; Tue, 17 Apr 2018 11:40:20 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 79901127201; Tue, 17 Apr 2018 11:40:19 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id b23-v6so9878507lfg.4; Tue, 17 Apr 2018 11:40:19 -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=mBoS2PZn+KmaIUo1EhfjsrRtlOqQk2MXnPV7QRpbkkM=; b=Ll9KYcgdWj+SK1G9PYeHBACxr7gRJ7CivGft8jyKfRsz+UpP405N6fr5Gfvm8eJ3eb XFaxGYqH0K82vcHEEfZghhvzYhximRtUVQQTyaOox0tpON3CPxclEOETlwmoVhmkbTbO Olbj+ovzQpf2BQ7AL/PGj37UHghoAMtZzho4OJ6opXgNYO84R35edkI9iU5/zW/ivrUZ /ooe1WMZpwNOYQZ13rb81uM/mpkWNTVVucSaO2h//sYLWyu0r27CX6Vtgt+tpXIEDKqr LPeeKKbPp1NZHQ1hifrXO5wjeXWL+hCs/y6i/H/HJeFCRc+SfUS/0NJ61+oagxhV4vsy hVDA== 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=mBoS2PZn+KmaIUo1EhfjsrRtlOqQk2MXnPV7QRpbkkM=; b=Z1smGj4Exgm1mwriUB9/c5LRxogqr8Jp7Czul+OiZcRbnDZkWl+40iu8EaIBVz4ET2 V6HDSY2Ra2xruyNvIVYzYILlgZlfeeehVLg5/9M0yCwceFLewZ6bJTwu3BpVwySglo1p yLILH7YBy/7EwoLINrjrGsizjeSebjLCI6N0gYK+aveSgWs7FlofPzofbOF0ieSjfq8y h2Ny4wRWLFmy4Wv26oLgI9sm+xDd4a9wKebHkKsl2xpAgapsPtxreCJc1wEPKRCqG+Nf TK69bCeKMwLOo78ujFdLCUiZugiXpEUeg9p7MRpzz/XAabWh6rxSvS8Iy1qzGMCVvy0d iUbQ== X-Gm-Message-State: ALQs6tC5yMT5S5uzYHSCQwKfpPKeeq2DzFp358gvVxHtorcH/KkBFgb0 NuiXiBUUs10FLNJTzefEOGS1Tgiz/qL/15t12Cc= X-Google-Smtp-Source: AIpwx4/iObCV8SVbQy9VQK81rdIrYas/l92fLckkedJQkQeD36GAWmMMN232ZOnaBwmql51dgbFX35RTY/w9p+Qp9fs= X-Received: by 2002:a19:fa7:: with SMTP id 39-v6mr2156229lfp.138.1523990417577; Tue, 17 Apr 2018 11:40:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.73.66 with HTTP; Tue, 17 Apr 2018 11:40:16 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Tue, 17 Apr 2018 11:40:16 -0700 Message-ID: Subject: Re: AD review of draft-ietf-bfd-multipoint-14 To: Martin Vigoureux Cc: draft-ietf-bfd-multipoint@ietf.org, "Reshad Rahman (rrahman)" , bfd-chairs@ietf.org, rtg-bfd@ietf.org Content-Type: multipart/mixed; boundary="0000000000007b526e056a0fab7a" Archived-At: X-Mailman-Approved-At: Tue, 17 Apr 2018 11:55:33 -0700 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: Tue, 17 Apr 2018 18:40:32 -0000 --0000000000007b526e056a0fab7a Content-Type: multipart/alternative; boundary="0000000000007b526a056a0fab78" --0000000000007b526a056a0fab78 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Martin, I have not ignored that comment but missed to ack its acceptance. Two other outstanding questions: - the text, that I've misinterpreted earlier, is in the Overview section= : Although this document describes a single head and a set of tails > spanned by a single multipoint path, the protocol is capable of > supporting (and discriminating between) more than one multipoint > path > at both heads and tails. > There is no text to describe how one could achieve that. Wouldn't it > be worth adding some? > > GIM>> The question of applicability of this specification to mp2mp > scenario came up at BIER WG meeting in London. Perhaps we can say the the= se > questions are ouside the scope of this document and discuss whether there > are interested to work on mp2mp case as a separete document? > I don't read this part of the document as talking about mp2mp but rather as talking about multiple p2mp trees. Sections 4.7 and 4.13.2 provides details on demultiplexing BFD control packets at a MultipointTail. Would the reference to these sections be sufficient? - yes, moved the reference to Point-to-Point session to section 4.4.1 Attached please find the diff between -14 and the working version of the draft. Please let me know if the changes address your comments. Will upload the new version promptly. Regards, Greg On Tue, Apr 17, 2018 at 9:49 AM, Martin Vigoureux < martin.vigoureux@nokia.com> wrote: > Greg, > > thanks. please see in-line. > > once I see the update published I will request IETF LC. > > -m > > Le 2018-04-17 =C3=A0 18:34, Greg Mirsky a =C3=A9crit : > >> Hi Martin, >> thank you for your thorough review, thoughtful comments and kind words. >> Please find my answers to your questions in-line and tagged GIM>>. >> >> Regards, >> Greg >> >> On Tue, Apr 17, 2018 at 8:06 AM, Martin Vigoureux < >> martin.vigoureux@nokia.com > wrote: >> >> [resend, wrong bfd wg address in first attempt ...] >> >> Authors, WG, >> >> thank you for this document. It is clear and well written. >> I didn't find any technical comment to make so I've been nit picking >> :-) >> Please find those comments below. >> >> regards, >> martin >> >> --- >> Please check and address the nits: >> https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/ >> draft-ietf-bfd-multipoint-14.txt >> > id/draft-ietf-bfd-multipoint-14.txt> >> >> On that aspect, does this document really update 7880 as the header >> says? The Introduction only refers to 5880 and it is not clear in >> the body of the Document what effectively impacts 7880. The only >> thing I saw is the addition of new session types but that does not >> require an update in my opinion. Could you clarify? >> GIM>> Yes, you'correct, the only connection to RFC 7880 are the new >> values of bfd.sessionType. The proposal to list RFC 7880 as updated >> by this specification was inteded to address Errata to RFC 7880 >> . >> > I am not sure how this document relates to or addresses the errata. So I > still think it does not update 7880. > > >> i.e. existence of a path between the sender and the receiver. >> do you mean "forwarding path"? >> GIM>> Yes. Updated to >> >> i.e. existence of a forwarding path between the sender and the >> receiver >> > thx > >> >> Section 2. and Section 3. seem a bit redundant. They both state the >> same thing but from a different angle. Not critical. >> >> >> Although this document describes a single head and a set of tail= s >> spanned by a single multipoint path, the protocol is capable of >> supporting (and discriminating between) more than one multipoint >> path >> at both heads and tails. >> There is no text to describe how one could achieve that. Wouldn't it >> be worth adding some? >> >> GIM>> The question of applicability of this specification to mp2mp >> scenario came up at BIER WG meeting in London. Perhaps we can say the th= ese >> questions are ouside the scope of this document and discuss whether ther= e >> are interested to work on mp2mp case as a separete document? >> > I don't read this part of the document as talking about mp2mp but rather > as talking about multiple p2mp trees. > >> >> >> >> Point-to-point sessions, as described in [RFC5880], are of type >> PointToPoint. >> Does this really fit in Section 4.2 which looks to be about the >> mpBFD session model. >> >> GIM>> I think that this short reminder is helpful to explain why this >> document adds value PointToPoint, section 4.4.1, to the defined in RFC 7= 880 >> bfd.sessionType variable. >> > Well, I would move the text to 4.4.1 then, but not critical. > >> >> >> >> Sessions of type MultipointHead MUST NOT send BFD control packet= s >> with the State field being set to INIT, and MUST be ignored on >> receipt. >> English is not my native language but I wonder if this really says >> what you want. It seems that "Sessions" is the subject of "MUST be >> ignored" while I think it's the packets which are the intended >> subject. So I'd write: >> and those packets MUST be ignored on receipt. >> > You chose to ignore that one or simply missed it? > >> >> >> Because there is no three-way handshake in Multipoint BFD, a new= ly >> started head (that does not have any previous state information >> available) SHOULD start with bfd.SessionState set to Down and wi= th >> bfd.RequiredMinRxInterval set to zero in the MultipointHead >> session. >> >> To shut down a multipoint session a head MUST administratively s= et >> bfd.SessionState in the MultipointHead session to either Down or >> AdminDown and SHOULD set bfd.RequiredMinRxInterval to zero. The >> In both these paragraphs one could read that the head "SHOULD set >> bfd.RequiredMinRxInterval to zero" while 4.4.2 says MUST. >> Clarification needed? >> >> GIM>> Section 4.4.2 mandates initialization of >> bfd.RequiredMinRxInterval and, I think, applies to the first paragraph >> you've pointed. Would the following be clear and consistent: >> Because there is no three-way handshake in Multipoint BFD, a newly >> started head (that does not have any previous state information >> available) SHOULD start with bfd.SessionState set to Down and >> bfd.RequiredMinRxInterval _MUST be_ set to zero in the MultipointHea= d >> session. >> The second paragraph describes manipulation with the value of >> bfd.RequiredMinRxInterval which process, as noted in section 4.10, "is >> outside the scope of this document". That may be reason to use SHOULD an= d >> not MUST. >> > Yes, i'd live with that. But then you might also want to clarify in 4.4.2= . > : > OLD: > This variable MUST be set to 0 for session type MultipointHead. > NEW: > This variable MUST be initialized to 0 for session type > MultipointHead. > > > > >> >> >> s/M, P bit/M and P bits/ >> >> GIM>> Thanks, done. >> >> --- >> >> >> --0000000000007b526a056a0fab78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Martin,
    I have not ignored that comment but missed = to ack its acceptance. Two other outstanding questions:
    • t= he text,=C2=A0that I've misinterpreted=C2=A0earlier, is in the Overview= section:
    =C2=A0= =C2=A0 =C2=A0=C2=A0 =C2=A0Although this document describes a single head a= nd a set of tails
    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0spanned by a single m= ultipoint path, the protocol is capable of
    =C2=A0 =C2=A0 =C2=A0=C2=A0 = =C2=A0supporting (and discriminating between) more than one multipoint
    = =C2=A0 =C2=A0 path
    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0at both heads and ta= ils.
    =C2=A0 =C2=A0 There is no text to describe how one could achieve th= at. Wouldn't it
    =C2=A0 =C2=A0 be worth adding some?

    GIM>&g= t; The question of applicability of this specification to mp2mp scenario ca= me up at BIER WG meeting in London. Perhaps we can say the these questions = are ouside the scope of this document and discuss whether there are interes= ted to work on mp2mp case as a separete document?
    I don't read this part of the document as talk= ing about mp2mp but rather as talking about multiple p2mp trees.
    Sections 4.7 and 4.13.2 provides details on demultiplexing BF= D control packets at a MultipointTail. Would the reference to these section= s be sufficient?=C2=A0
    • yes, moved the reference t= o Point-to-Point session to section 4.4.1
    Attached plea= se find the diff between -14 and the working version of the draft. Please l= et me know if the changes address your comments. Will upload the new versio= n promptly.

    Regards,
    Greg

    On Tue, Apr 17, 2018= at 9:49 AM, Martin Vigoureux <martin.vigoureux@nokia.com>= wrote:
    Greg,

    thanks. please see in-line.

    once I see the update published I will request IETF LC.

    -m

    Le 2018-04-17 =C3=A0 18:34, Greg Mirsky a =C3=A9crit=C2=A0:
    Hi Martin,
    thank you for your thorough review, thoughtful=C2=A0comments and kind words= .
    Please find my answers to your questions in-line and tagged GIM>>.
    Regards,
    Greg

     On Tue, Apr 17, 2018 at 8:06 AM, Martin Vigoureux <martin.vigoureux@nokia.com &= lt;mailto:m= artin.vigoureux@nokia.com>> wrote:

    =C2=A0 =C2=A0 [resend, wrong bfd wg address in first attempt ...]

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

    =C2=A0 =C2=A0 thank you for this document. It is clear and well written. =C2=A0 =C2=A0 I didn't find any technical comment to make so I've b= een nit picking :-)
    =C2=A0 =C2=A0 Please find those comments below.

    =C2=A0 =C2=A0 regards,
    =C2=A0 =C2=A0 martin

    =C2=A0 =C2=A0 ---
    =C2=A0 =C2=A0 Please check and address the nits:
    =C2=A0 =C2=A0 https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/= draft-ietf-bfd-multipoint-14.txt
    =C2=A0 =C2=A0 <https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org= /id/draft-ietf-bfd-multipoint-14.txt>

    =C2=A0 =C2=A0 On that aspect, does this document really update 7880 as the = header
    =C2=A0 =C2=A0 says? The Introduction only refers to 5880 and it is not clea= r in
    =C2=A0 =C2=A0 the body of the Document what effectively impacts 7880. The o= nly
    =C2=A0 =C2=A0 thing I saw is the addition of new session types but that doe= s not
    =C2=A0 =C2=A0 require an update in my opinion. Could you clarify?
    =C2=A0 =C2=A0 GIM>> Yes, you'correct, the only connection to RFC = 7880 are the new
    =C2=A0 =C2=A0 values of bfd.sessionType. The proposal to list RFC 7880 as u= pdated
    =C2=A0 =C2=A0 by this specification was inteded to address Errata to RFC 78= 80
     =C2=A0 =C2=A0 <https://www.rfc-editor.org/= errata_search.php?rfc=3D7880>.
    I am not sure how this document relates to or addresses the errata. So I st= ill think it does not update 7880.


    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0i.e. existence of a path between the sende= r and the receiver.
    =C2=A0 =C2=A0 do you mean "forwarding path"?
    =C2=A0 =C2=A0 GIM>> Yes. Updated to

    =C2=A0 =C2=A0 i.e. existence of a forwarding path between the sender and th= e receiver
    thx

    =C2=A0 =C2=A0 Section 2. and Section 3. seem a bit redundant. They both sta= te the
    =C2=A0 =C2=A0 same thing but from a different angle. Not critical.


    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Although this document describes a single = head and a set of tails
    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0spanned by a single multipoint path, the p= rotocol is capable of
    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0supporting (and discriminating between) mo= re than one multipoint
    =C2=A0 =C2=A0 path
    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0at both heads and tails.
    =C2=A0 =C2=A0 There is no text to describe how one could achieve that. Woul= dn't it
    =C2=A0 =C2=A0 be worth adding some?

    GIM>> The question of applicability of this specification to mp2mp sc= enario came up at BIER WG meeting in London. Perhaps we can say the these q= uestions are ouside the scope of this document and discuss whether there ar= e interested to work on mp2mp case as a separete document?
     I don't read this part of the document as talking about mp2mp but rathe= r as talking about multiple p2mp trees.



    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Point-to-point sessions, as described in [= RFC5880], are of type
    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0PointToPoint.
    =C2=A0 =C2=A0 Does this really fit in Section 4.2 which looks to be about t= he
    =C2=A0 =C2=A0 mpBFD session model.

    GIM>> I think that this short reminder is helpful to explain why this= document adds value PointToPoint, section 4.4.1, to the defined in RFC 788= 0 bfd.sessionType variable.
     Well, I would move the text to 4.4.1 then, but not critical.



    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Sessions of type MultipointHead MUST NOT s= end BFD control packets
    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0with the State field being set to INIT, an= d MUST be ignored on
    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0receipt.
    =C2=A0 =C2=A0 English is not my native language but I wonder if this really= says
    =C2=A0 =C2=A0 what you want. It seems that "Sessions" is the subj= ect of "MUST be
    =C2=A0 =C2=A0 ignored" while I think it's the packets which are th= e intended
    =C2=A0 =C2=A0 subject. So I'd write:
    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0and those packets MUST be ignored on recei= pt.
     You chose to ignore that one or simply missed it?


    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Because there is no three-way handshake in= Multipoint BFD, a newly
    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0started head (that does not have any previ= ous state information
    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0available) SHOULD start with bfd.SessionSt= ate set to Down and with
    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0bfd.RequiredMinRxInterval set to zero in t= he MultipointHead session.

    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0To shut down a multipoint session a head M= UST administratively set
    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0bfd.SessionState in the MultipointHead ses= sion to either Down or
    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0AdminDown and SHOULD set bfd.RequiredMinRx= Interval to zero.=C2=A0 The
    =C2=A0 =C2=A0 In both these paragraphs one could read that the head "S= HOULD set
    =C2=A0 =C2=A0 bfd.RequiredMinRxInterval to zero" while 4.4.2 says MUST= .
    =C2=A0 =C2=A0 Clarification needed?

    GIM>> Section 4.4.2 mandates initialization of bfd.RequiredMinRxInter= val=C2=A0and, I think, applies to the first paragraph you've pointed. W= ould the following be clear and consistent:
    =C2=A0=C2=A0 =C2=A0Because there is no three-way handshake in Multipoint BF= D, a newly
    =C2=A0=C2=A0 =C2=A0started head (that does not have any previous state info= rmation
    =C2=A0=C2=A0 =C2=A0available) SHOULD start with bfd.SessionState set to Dow= n and
     =C2=A0=C2=A0 =C2=A0bfd.RequiredMinRxInterval _MUST be_ set to zero in the M= ultipointHead session.
    The second paragraph describes manipulation with the value of bfd.RequiredM= inRxInterval which process, as noted in section 4.10, "is outside the = scope of this document". That may be reason to use SHOULD and not MUST= .
    Yes, i'd live with that. But then you might also want to clarify in 4.4.2.:
    OLD:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This variable MUST be set to 0 for sessio= n type MultipointHead.
    NEW:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This variable MUST be initialized to 0 fo= r session type
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MultipointHead.






    =C2=A0 =C2=A0 s/M, P bit/M and P bits/

    GIM>> Thanks, done.

    =C2=A0 =C2=A0 ---



    --0000000000007b526a056a0fab78-- --0000000000007b526e056a0fab7a Content-Type: text/html; charset="UTF-8"; name="Diff_ draft-ietf-bfd-multipoint-14.txt - draft-ietf-bfd-multipoint-15.txt.html" Content-Disposition: attachment; filename="Diff_ draft-ietf-bfd-multipoint-14.txt - draft-ietf-bfd-multipoint-15.txt.html" Content-Transfer-Encoding: base64 X-Attachment-Id: f_jg40jj9m0 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPgo8IS0tIHNhdmVkIGZyb20gdXJsPSgwMDQxKWh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmYvcmZjZGlmZi5weWh0IC0tPgo8aHRtbCB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS94aHRtbCIgY2xhc3M9ImdyX19pZXRmX29yZyI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29u dGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPiAKICAgCiAgPG1l dGEgaHR0cC1lcXVpdj0iQ29udGVudC1TdHlsZS1UeXBlIiBjb250ZW50PSJ0ZXh0L2NzcyI+IAog IDx0aXRsZT5EaWZmOiBkcmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50LTE0LnR4dCAtIGRyYWZ0LWll dGYtYmZkLW11bHRpcG9pbnQtMTUudHh0PC90aXRsZT4gCiAgPHN0eWxlIHR5cGU9InRleHQvY3Nz Ij4gCiAgICBib2R5ICAgIHsgbWFyZ2luOiAwLjRleDsgbWFyZ2luLXJpZ2h0OiBhdXRvOyB9IAog ICAgdHIgICAgICB7IH0gCiAgICB0ZCAgICAgIHsgd2hpdGUtc3BhY2U6IHByZTsgZm9udC1mYW1p bHk6IG1vbm9zcGFjZTsgdmVydGljYWwtYWxpZ246IHRvcDsgZm9udC1zaXplOiAwLjg2ZW07fSAK ICAgIHRoICAgICAgeyBmb250LXNpemU6IDAuODZlbTsgfSAKICAgIC5zbWFsbCAgeyBmb250LXNp emU6IDAuNmVtOyBmb250LXN0eWxlOiBpdGFsaWM7IGZvbnQtZmFtaWx5OiBWZXJkYW5hLCBIZWx2 ZXRpY2EsIHNhbnMtc2VyaWY7IH0gCiAgICAubGVmdCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0VF RTsgfSAKICAgIC5yaWdodCAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZGOyB9IAogICAgLmRpZmYg ICB7IGJhY2tncm91bmQtY29sb3I6ICNDQ0Y7IH0gCiAgICAubGJsb2NrIHsgYmFja2dyb3VuZC1j b2xvcjogI0JGQjsgfSAKICAgIC5yYmxvY2sgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkY4OyB9IAog ICAgLmluc2VydCB7IGJhY2tncm91bmQtY29sb3I6ICM4RkY7IH0gCiAgICAuZGVsZXRlIHsgYmFj a2dyb3VuZC1jb2xvcjogI0FDRjsgfSAKICAgIC52b2lkICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAj RkZCOyB9IAogICAgLmNvbnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IH0gCiAgICAubGlu ZWJyIHsgYmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSAKICAgIC5saW5lbm8geyBjb2xvcjogcmVk OyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZGOyBmb250LXNpemU6IDAuN2VtOyB0ZXh0LWFsaWduOiBy aWdodDsgcGFkZGluZzogMCAycHg7IH0gCiAgICAuZWxpcHNpc3sgYmFja2dyb3VuZC1jb2xvcjog I0FBQTsgfSAKICAgIC5sZWZ0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0RERDsgfSAKICAg IC5yaWdodCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IH0gCiAgICAubGJsb2NrIC5j b250IHsgYmFja2dyb3VuZC1jb2xvcjogIzlEOTsgfSAKICAgIC5yYmxvY2sgLmNvbnQgeyBiYWNr Z3JvdW5kLWNvbG9yOiAjREQ2OyB9IAogICAgLmluc2VydCAuY29udCB7IGJhY2tncm91bmQtY29s b3I6ICMwREQ7IH0gCiAgICAuZGVsZXRlIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogIzhBRDsg fSAKICAgIC5zdGF0cywgLnN0YXRzIHRkLCAuc3RhdHMgdGggeyBiYWNrZ3JvdW5kLWNvbG9yOiAj RUVFOyBwYWRkaW5nOiAycHggMDsgfSAKICAgIHNwYW4uaGlkZSB7IGRpc3BsYXk6IG5vbmU7IGNv bG9yOiAjYWFhO30gICAgYTpob3ZlciBzcGFuIHsgZGlzcGxheTogaW5saW5lOyB9ICAgIHRyLmNo YW5nZSB7IGJhY2tncm91bmQtY29sb3I6IGdyYXk7IH0gCiAgICB0ci5jaGFuZ2UgYSB7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsgY29sb3I6IGJsYWNrIH0gCiAgPC9zdHlsZT4gCiAgICAgPHNjcmlw dD4KdmFyIGNodW5rX2luZGV4ID0gMDsKdmFyIG9sZF9jaHVuayA9IG51bGw7CgpmdW5jdGlvbiBm b3JtYXRfY2h1bmsoaW5kZXgpIHsKICAgIHZhciBwcmVmaXggPSAiZGlmZiI7CiAgICB2YXIgc3Ry ID0gaW5kZXgudG9TdHJpbmcoKTsKICAgIGZvciAoeD0wOyB4PCg0LXN0ci5sZW5ndGgpOyArK3gp IHsKICAgICAgICBwcmVmaXgrPScwJzsKICAgIH0KICAgIHJldHVybiBwcmVmaXggKyBzdHI7Cn0K CmZ1bmN0aW9uIGZpbmRfY2h1bmsobil7CiAgICByZXR1cm4gZG9jdW1lbnQucXVlcnlTZWxlY3Rv cigndHJbaWQkPSInICsgbiArICciXScpOwp9CgpmdW5jdGlvbiBjaGFuZ2VfY2h1bmsob2Zmc2V0 KSB7CiAgICB2YXIgaW5kZXggPSBjaHVua19pbmRleCArIG9mZnNldDsKICAgIHZhciBuZXdfc3Ry OwogICAgdmFyIG5ld19jaHVuazsKCiAgICBuZXdfc3RyID0gZm9ybWF0X2NodW5rKGluZGV4KTsK ICAgIG5ld19jaHVuayA9IGZpbmRfY2h1bmsobmV3X3N0cik7CiAgICBpZiAoIW5ld19jaHVuaykg ewogICAgICAgIHJldHVybjsKICAgIH0KICAgIGlmIChvbGRfY2h1bmspIHsKICAgICAgICBvbGRf Y2h1bmsuc3R5bGUub3V0bGluZSA9ICIiOwogICAgfQogICAgb2xkX2NodW5rID0gbmV3X2NodW5r OwogICAgb2xkX2NodW5rLnN0eWxlLm91dGxpbmUgPSAiMXB4IHNvbGlkIHJlZCI7CiAgICB3aW5k b3cubG9jYXRpb24ucmVwbGFjZSgiIyIgKyBuZXdfc3RyKQogICAgd2luZG93LnNjcm9sbEJ5KDAs LTEwMCk7CiAgICBjaHVua19pbmRleCA9IGluZGV4Owp9Cgpkb2N1bWVudC5vbmtleWRvd24gPSBm dW5jdGlvbihlKSB7CiAgICBzd2l0Y2ggKGUua2V5Q29kZSkgewogICAgY2FzZSA3ODoKICAgICAg ICBjaGFuZ2VfY2h1bmsoMSk7CiAgICAgICAgYnJlYWs7CiAgICBjYXNlIDgwOgogICAgICAgIGNo YW5nZV9jaHVuaygtMSk7CiAgICAgICAgYnJlYWs7CiAgICB9Cn07CiAgIDwvc2NyaXB0PiAKPC9o ZWFkPiAKPGJvZHkgZGF0YS1nci1jLXMtbG9hZGVkPSJ0cnVlIj4gCiAgPHRhYmxlIGJvcmRlcj0i MCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj4gCiAgPHRib2R5Pjx0ciBpZD0icGFy dC0xIiBiZ2NvbG9yPSJvcmFuZ2UiPjx0aD48L3RoPjx0aD48YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludC0xNC50eHQiIHN0 eWxlPSJjb2xvcjojMDA4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPiZsdDs8L2E+Jm5ic3A7PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLW11bHRpcG9p bnQtMTQudHh0IiBzdHlsZT0iY29sb3I6IzAwOCI+ZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludC0x NC50eHQ8L2E+Jm5ic3A7PC90aD48dGg+IDwvdGg+PHRoPiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50LTE1LnR4dCIgc3R5 bGU9ImNvbG9yOiMwMDgiPmRyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQtMTUudHh0PC9hPiZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1pZXRmLWJm ZC1tdWx0aXBvaW50LTE1LnR4dCIgc3R5bGU9ImNvbG9yOiMwMDg7IHRleHQtZGVjb3JhdGlvbjpu b25lOyI+Jmd0OzwvYT48L3RoPjx0aD48L3RoPjwvdHI+IAogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkludGVybmV0IEVuZ2luZWVyaW5nIFRh c2sgRm9yY2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRC4gS2F0ejwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2Ug ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRC4gS2F0ejwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBKdW5pcGVyIE5ldHdvcmtzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBKdW5pcGVyIE5ldHdvcmtzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHIgaWQ9ImRpZmYwMDAxIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPlVwZGF0ZXM6IDU4ODA8c3BhbiBjbGFzcz0i ZGVsZXRlIj4sIDc4ODAgKGlmIGFwcHJvdmVkKTwvc3Bhbj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEQuIFdhcmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+VXBkYXRl czogNTg4MDxzcGFuIGNsYXNzPSJpbnNlcnQiPiAoaWYgYXBwcm92ZWQpICAgICAgPC9zcGFuPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRC4gV2FyZDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+SW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAg ICAgICAgICAgICBDaXNjbyBTeXN0ZW1zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ SW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAg ICBDaXNjbyBTeXN0ZW1zPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHIgaWQ9ImRpZmYwMDAyIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPkV4cGlyZXM6IDxzcGFuIGNsYXNzPSJkZWxldGUi PkF1Z3VzdCAyNSwgMjAxOCA8L3NwYW4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTLiBQ YWxsYWdhdHRpLCBFZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+RXhwaXJlczog PHNwYW4gY2xhc3M9Imluc2VydCI+T2N0b2JlciAxOSwgMjAxODwvc3Bhbj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFMuIFBhbGxhZ2F0dGksIEVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJ bmRpdmlkdWFsIGNvbnRyaWJ1dG9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJbmRpdmlkdWFs IGNvbnRyaWJ1dG9yPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRy4gTWlyc2t5LCBFZC48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRy4gTWlyc2t5LCBFZC48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFpURSBDb3JwLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFpURSBDb3JwLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwMyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ RmVicnVhcnkgMjE8L3NwYW4+LCAyMDE4PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBBcHJpbCAxNzwvc3Bhbj4sIDIwMTg8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgIEJGRCBmb3IgTXVsdGlw b2ludCBOZXR3b3JrczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg ICAgICAgICAgICBCRkQgZm9yIE11bHRpcG9pbnQgTmV0d29ya3M8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDQiPjx0ZD48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAg ICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQtMTxzcGFuIGNsYXNzPSJk ZWxldGUiPjQ8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAg ICAgICAgICAgICAgICBkcmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50LTE8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij41PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5BYnN0cmFjdDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkFic3RyYWN0PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGV4dGVuc2lvbnMgdG8g dGhlIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGV4dGVuc2lvbnMgdG8gdGhlIEJpZGlyZWN0 aW9uYWwgRm9yd2FyZGluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRGV0ZWN0aW9u IChCRkQpIHByb3RvY29sIGZvciBpdHMgdXNlIGluIG11bHRpcG9pbnQgYW5kIG11bHRpY2FzdDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERldGVjdGlvbiAoQkZEKSBwcm90b2Nv bCBmb3IgaXRzIHVzZSBpbiBtdWx0aXBvaW50IGFuZCBtdWx0aWNhc3Q8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIG5ldHdvcmtzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIG5ldHdvcmtzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5SZXF1aXJlbWVu dHMgTGFuZ3VhZ2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5SZXF1aXJlbWVudHMg TGFuZ3VhZ2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGtleSB3b3Jk cyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAi TVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiw8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTIiIGNsYXNzPSJj aGFuZ2UiPjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTIi PjxlbT4gcGFnZSAxLCBsaW5lIDQ1PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwv YT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC0y Ij48ZW0+IHBhZ2UgMSwgbGluZSA0NTxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48 L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRz IG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVy bmV0IEVuZ2luZWVyaW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUYXNrIEZvcmNl IChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0 aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlz dCBvZiBjdXJyZW50IEludGVybmV0LTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJl bnQgSW50ZXJuZXQtPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBEcmFmdHMgaXMgYXQg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRHJhZnRzIGlzIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhp bXVtIG9mIHNpeCBtb250aHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRl cm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNp eCBtb250aHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFuZCBtYXkgYmUgdXBkYXRl ZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNl ZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnk8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5l dC1EcmFmdHMgYXMgcmVmZXJlbmNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg dGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZl cmVuY2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUg dGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiI8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAi d29yayBpbiBwcm9ncmVzcy4iPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0ciBpZD0iZGlmZjAwMDUiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgVGhpcyBJbnRlcm5ldC1EcmFm dCB3aWxsIGV4cGlyZSBvbiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5BdWd1c3QgMjU8L3NwYW4+LCAy MDE4LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBUaGlzIEludGVybmV0LURy YWZ0IHdpbGwgZXhwaXJlIG9uIDxzcGFuIGNsYXNzPSJpbnNlcnQiPk9jdG9iZXIgMTk8L3NwYW4+ LCAyMDE4LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5Db3B5cmlnaHQgTm90aWNl PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Q29weXJpZ2h0IE5vdGljZTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDb3B5cmlnaHQgKGMpIDIwMTggSUVURiBUcnVz dCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBDb3B5cmlnaHQgKGMpIDIwMTggSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNv bnMgaWRlbnRpZmllZCBhcyB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRvY3Vt ZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3Qg dG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhl IElFVEYgVHJ1c3QncyBMZWdhbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUHJvdmlz aW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIChodHRwczovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1p bmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAoaHR0cHM6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0 IG9uIHRoZSBkYXRlIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwdWJsaWNhdGlv biBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50 LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTMiIGNsYXNzPSJjaGFuZ2UiPjx0ZD48 L3RkPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTMiPjxlbT4gcGFnZSAy LCBsaW5lIDUwPHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4g PC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC0zIj48ZW0+IHBhZ2Ug MiwgbGluZSA1MDxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgICAgNC4xMi4xLiAgTXVsdGlwb2ludEhlYWQgU2Vzc2lvbnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICAgNC4xMi4xLiAgTXVsdGlwb2ludEhlYWQgU2Vzc2lvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgIDk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICA0LjEyLjIuICBN dWx0aXBvaW50VGFpbCBTZXNzaW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICA0LjEyLjIuICBNdWx0aXBvaW50 VGFpbCBTZXNzaW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICA0LjEzLiBCYXNlIFNwZWNpZmljYXRpb24gVGV4dCBSZXBs YWNlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICA0LjEzLiBCYXNlIFNwZWNpZmljYXRpb24gVGV4dCBSZXBsYWNlbWVudCAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg ICAgNC4xMy4xLiAgUmVjZXB0aW9uIG9mIEJGRCBDb250cm9sIFBhY2tldHMgLiAuIC4gLiAuIC4g LiAuIC4gLiAgMTA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgNC4xMy4x LiAgUmVjZXB0aW9uIG9mIEJGRCBDb250cm9sIFBhY2tldHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAg MTA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICA0LjEzLjIuICBEZW11bHRpcGxl eGluZyBCRkQgQ29udHJvbCBQYWNrZXRzIC4gLiAuIC4gLiAuIC4gLiAuICAxMzwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICA0LjEzLjIuICBEZW11bHRpcGxleGluZyBCRkQg Q29udHJvbCBQYWNrZXRzIC4gLiAuIC4gLiAuIC4gLiAuICAxMzwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgICAgIDQuMTMuMy4gIFRyYW5zbWl0dGluZyBCRkQgQ29udHJvbCBQYWNrZXRz IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgIDQuMTMuMy4gIFRyYW5zbWl0dGluZyBCRkQgQ29udHJvbCBQYWNrZXRzIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDE0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA1LiAgQXNzdW1w dGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg MTY8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA1LiAgQXNzdW1wdGlvbnMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTY8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDYuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIDYuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgNy4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDE2PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgNy4gIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDE2PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA4LiAgQ29udHJpYnV0b3JzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTc8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA4LiAgQ29udHJpYnV0b3JzICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTc8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDYiPjx0ZD48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg OS4gIEFja25vd2xlZGc8c3BhbiBjbGFzcz0iZGVsZXRlIj5lbWVudHMgPC9zcGFuPiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNzwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICA5LiAgQWNrbm93bGVkZzxzcGFuIGNsYXNzPSJpbnNlcnQiPm1l bnRzIC48L3NwYW4+IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDE3PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAxMC4gTm9ybWF0aXZlIFJlZmVyZW5j ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTc8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAxMC4gTm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTc8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxODwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAxODwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4xLiAgSW50 cm9kdWN0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+MS4gIEludHJvZHVjdGlv bjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgQmlkaXJlY3Rpb25hbCBG b3J3YXJkaW5nIERldGVjdGlvbiBwcm90b2NvbCBbUkZDNTg4MF0gc3BlY2lmaWVzIGE8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5n IERldGVjdGlvbiBwcm90b2NvbCBbUkZDNTg4MF0gc3BlY2lmaWVzIGE8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIG1ldGhvZCBmb3IgdmVyaWZ5aW5nIHVuaWNhc3QgY29ubmVjdGl2aXR5 IGJldHdlZW4gYSBwYWlyIG9mIHN5c3RlbXMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgbWV0aG9kIGZvciB2ZXJpZnlpbmcgdW5pY2FzdCBjb25uZWN0aXZpdHkgYmV0d2VlbiBh IHBhaXIgb2Ygc3lzdGVtcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgZG9j dW1lbnQgZGVmaW5lcyBhIG1ldGhvZCBmb3IgdXNpbmcgQkZEIHRvIHByb3ZpZGUgdmVyaWZpY2F0 aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBkb2N1bWVudCBkZWZp bmVzIGEgbWV0aG9kIGZvciB1c2luZyBCRkQgdG8gcHJvdmlkZSB2ZXJpZmljYXRpb248L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9mIG11bHRpcG9pbnQgb3IgbXVsdGljYXN0IGNvbm5l Y3Rpdml0eSBiZXR3ZWVuIGEgbXVsdGlwb2ludCBzZW5kZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBvZiBtdWx0aXBvaW50IG9yIG11bHRpY2FzdCBjb25uZWN0aXZpdHkgYmV0 d2VlbiBhIG11bHRpcG9pbnQgc2VuZGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAo dGhlICJoZWFkIikgYW5kIGEgc2V0IG9mIG9uZSBvciBtb3JlIG11bHRpcG9pbnQgcmVjZWl2ZXJz ICh0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAodGhlICJoZWFkIikgYW5k IGEgc2V0IG9mIG9uZSBvciBtb3JlIG11bHRpcG9pbnQgcmVjZWl2ZXJzICh0aGU8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTQiIGNsYXNz PSJjaGFuZ2UiPjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFs bD48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0 LTQiPjxlbT4gcGFnZSAzLCBsaW5lIDI0PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2Vt PjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21h bGw+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFy dC00Ij48ZW0+IHBhZ2UgMywgbGluZSAyNDxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9l bT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBcyBtdWx0aXBvaW50IHRyYW5zbWlzc2lvbnMgYXJlIGlu aGVyZW50bHkgdW5pZGlyZWN0aW9uYWwsIHRoaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBBcyBtdWx0aXBvaW50IHRyYW5zbWlzc2lvbnMgYXJlIGluaGVyZW50bHkgdW5pZGly ZWN0aW9uYWwsIHRoaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1lY2hhbmlzbSBw dXJwb3J0cyBvbmx5IHRvIHZlcmlmeSB0aGlzIHVuaWRpcmVjdGlvbmFsIGNvbm5lY3Rpdml0eS48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBtZWNoYW5pc20gcHVycG9ydHMgb25s eSB0byB2ZXJpZnkgdGhpcyB1bmlkaXJlY3Rpb25hbCBjb25uZWN0aXZpdHkuPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBBbHRob3VnaCB0aGlzIHNlZW1zIGluIGNvbmZsaWN0IHdpdGgg dGhlICJCaWRpcmVjdGlvbmFsIiBpbiBCRkQsIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIEFsdGhvdWdoIHRoaXMgc2VlbXMgaW4gY29uZmxpY3Qgd2l0aCB0aGUgIkJpZGly ZWN0aW9uYWwiIGluIEJGRCwgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwcm90 b2NvbCBpcyBjYXBhYmxlIHN1cHBvcnRpbmcgdGhpcyB1c2UgY2FzZS48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBwcm90b2NvbCBpcyBjYXBhYmxlIHN1cHBvcnRpbmcgdGhpcyB1 c2UgY2FzZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBhcHBsaWNh dGlvbiBvZiBCRkQgYWxsb3dzIGZvciB0aGUgdGFpbHMgdG8gZGV0ZWN0IGEgbGFjayBvZjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgYXBwbGljYXRpb24gb2YgQkZEIGFs bG93cyBmb3IgdGhlIHRhaWxzIHRvIGRldGVjdCBhIGxhY2sgb2Y8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGNvbm5lY3Rpdml0eSBmcm9tIHRoZSBoZWFkLiAgRHVlIHRvIHVuaWRpcmVj dGlvbmFsIG5hdHVyZSwgdmlydHVhbGx5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgY29ubmVjdGl2aXR5IGZyb20gdGhlIGhlYWQuICBEdWUgdG8gdW5pZGlyZWN0aW9uYWwgbmF0 dXJlLCB2aXJ0dWFsbHk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFsbCBvcHRpb25z IGFuZCB0aW1pbmcgcGFyYW1ldGVycyBhcmUgY29udHJvbGxlZCBieSB0aGUgaGVhZC48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbGwgb3B0aW9ucyBhbmQgdGltaW5nIHBhcmFt ZXRlcnMgYXJlIGNvbnRyb2xsZWQgYnkgdGhlIGhlYWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIEFzIGFuIG9wdGlvbiwgdGhlIHRhaWwgbWF5IG5vdGlmeSB0aGUgaGVhZCBv ZiB0aGUgbGFjayBvZiBtdWx0aXBvaW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgQXMgYW4gb3B0aW9uLCB0aGUgdGFpbCBtYXkgbm90aWZ5IHRoZSBoZWFkIG9mIHRoZSBsYWNr IG9mIG11bHRpcG9pbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 ciBpZD0iZGlmZjAwMDciPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgY29ubmVjdGl2aXR5LiAgRGV0YWlscyBvZiB0 YWlsIG5vdGlmaWNhdGlvbiB0byBoZWFkIGFyZSBvdXRzaWRlIHRoZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICBjb25uZWN0aXZpdHkuICBEZXRhaWxzIG9mIHRhaWwgbm90aWZp Y2F0aW9uIHRvIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnRoZTwvc3Bhbj4gaGVhZCBhcmUgb3V0c2lk ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBzY29wZSBvZiB0aGlzIGRvY3VtZW50 LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICB0aGUgc2NvcGUgb2YgdGhpcyBk b2N1bWVudC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhyb3VnaG91dCB0 aGlzIGRvY3VtZW50LCB0aGUgdGVybSAibXVsdGlwb2ludCIgaXMgZGVmaW5lZCBhcyBhPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhyb3VnaG91dCB0aGlzIGRvY3VtZW50LCB0 aGUgdGVybSAibXVsdGlwb2ludCIgaXMgZGVmaW5lZCBhcyBhPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBtZWNoYW5pc20gYnkgd2hpY2ggb25lIG9yIG1vcmUgc3lzdGVtcyByZWNlaXZl IHBhY2tldHMgc2VudCBieSBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbWVj aGFuaXNtIGJ5IHdoaWNoIG9uZSBvciBtb3JlIHN5c3RlbXMgcmVjZWl2ZSBwYWNrZXRzIHNlbnQg YnkgYTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc2luZ2xlIHNlbmRlci4gIFRoaXMg c3BlY2lmaWNhbGx5IGluY2x1ZGVzIHN1Y2ggdGhpbmdzIGFzIElQPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgc2luZ2xlIHNlbmRlci4gIFRoaXMgc3BlY2lmaWNhbGx5IGluY2x1 ZGVzIHN1Y2ggdGhpbmdzIGFzIElQPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtdWx0 aWNhc3QgYW5kIHBvaW50LXRvLW11bHRpcG9pbnQgTVBMUy48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBtdWx0aWNhc3QgYW5kIHBvaW50LXRvLW11bHRpcG9pbnQgTVBMUy48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGVybSAiY29ubmVjdGl2aXR5IiBpbiB0 aGlzIGRvY3VtZW50IGlzIG5vdCBiZWluZyB1c2VkIGluIHRoZSBjb250ZXh0PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGVybSAiY29ubmVjdGl2aXR5IiBpbiB0aGlzIGRvY3Vt ZW50IGlzIG5vdCBiZWluZyB1c2VkIGluIHRoZSBjb250ZXh0PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBvZiBjb25uZWN0aXZpdHkgdmVyaWZpY2F0aW9uIGluIHRyYW5zcG9ydCBuZXR3 b3JrIGJ1dCBhcyBhbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9mIGNvbm5l Y3Rpdml0eSB2ZXJpZmljYXRpb24gaW4gdHJhbnNwb3J0IG5ldHdvcmsgYnV0IGFzIGFuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA4Ij48dGQ+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgIGFsdGVybmF0aXZlIHRvICJjb250aW51aXR5IiwgaS5lLiBleGlzdGVuY2Ugb2Yg YSBwYXRoIGJldHdlZW4gdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGFs dGVybmF0aXZlIHRvICJjb250aW51aXR5IiwgaS5lLiBleGlzdGVuY2Ugb2YgYSA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij5mb3J3YXJkaW5nPC9zcGFuPiBwYXRoPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgIHNlbmRlciBhbmQgdGhlIHJlY2VpdmVyLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICBiZXR3ZWVuIHRoZSBzZW5kZXIgYW5kIHRoZSByZWNlaXZlci48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBlZmZlY3RpdmVseSBt b2RpZmllcyBhbmQgYWRkcyB0byB0aGUgYmFzZSBCRkQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IGVmZmVjdGl2ZWx5IG1vZGlmaWVzIGFuZCBhZGRzIHRv IHRoZSBiYXNlIEJGRDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc3BlY2lmaWNhdGlv biBbUkZDNTg4MF0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc3BlY2lmaWNh dGlvbiBbUkZDNTg4MF0uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjIuICBHb2Fs czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjIuICBHb2FsczwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgcHJpbWFyeSBnb2FsIG9mIHRoaXMgbWVjaGFuaXNt IGlzIHRvIGFsbG93IHRhaWxzIHRvIHJhcGlkbHk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBUaGUgcHJpbWFyeSBnb2FsIG9mIHRoaXMgbWVjaGFuaXNtIGlzIHRvIGFsbG93IHRh aWxzIHRvIHJhcGlkbHk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRldGVjdCB0aGUg ZmFjdCB0aGF0IG11bHRpcG9pbnQgY29ubmVjdGl2aXR5IGZyb20gdGhlIGhlYWQgaGFzPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGV0ZWN0IHRoZSBmYWN0IHRoYXQgbXVsdGlw b2ludCBjb25uZWN0aXZpdHkgZnJvbSB0aGUgaGVhZCBoYXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIGZhaWxlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBmYWls ZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy IGlkPSJwYXJ0LTUiIGNsYXNzPSJjaGFuZ2UiPjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcg dG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm L3JmY2RpZmYucHlodCNwYXJ0LTUiPjxlbT4gcGFnZSA0LCBsaW5lIDE3PHNwYW4gY2xhc3M9Imhp ZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5n IHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zi9yZmNkaWZmLnB5aHQjcGFydC01Ij48ZW0+IHBhZ2UgNCwgbGluZSAxNzxzcGFuIGNsYXNzPSJo aWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkb25lIGluZGVwZW5kZW50 bHkgKGFuZCB3aXRoIG5vIHBlbmFsdHkgaW4gcHJvdG9jb2wgb3ZlcmhlYWQpIGJ5PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZG9uZSBpbmRlcGVuZGVudGx5IChhbmQgd2l0aCBu byBwZW5hbHR5IGluIHByb3RvY29sIG92ZXJoZWFkKSBieTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgdXNpbmcgcG9pbnQtdG8tcG9pbnQgQkZELjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIHVzaW5nIHBvaW50LXRvLXBvaW50IEJGRC48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+My4gIE92ZXJ2aWV3PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+My4gIE92ZXJ2aWV3PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBo ZWFydCBvZiB0aGlzIHByb3RvY29sIGlzIHRoZSBwZXJpb2RpYyB0cmFuc21pc3Npb24gb2YgQkZE PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGhlYXJ0IG9mIHRoaXMgcHJv dG9jb2wgaXMgdGhlIHBlcmlvZGljIHRyYW5zbWlzc2lvbiBvZiBCRkQ8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIENvbnRyb2wgcGFja2V0cyBhbG9uZyBhIG11bHRpcG9pbnQgcGF0aCwg ZnJvbSB0aGUgaGVhZCB0byBhbGwgdGFpbHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBDb250cm9sIHBhY2tldHMgYWxvbmcgYSBtdWx0aXBvaW50IHBhdGgsIGZyb20gdGhlIGhl YWQgdG8gYWxsIHRhaWxzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvbiB0aGUgdHJl ZS4gIFRoZSBjb250ZW50cyBvZiB0aGUgQkZEIHBhY2tldHMgcHJvdmlkZSB0aGUgbWVhbnMgZm9y PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb24gdGhlIHRyZWUuICBUaGUgY29u dGVudHMgb2YgdGhlIEJGRCBwYWNrZXRzIHByb3ZpZGUgdGhlIG1lYW5zIGZvcjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIHRhaWxzIHRvIGNhbGN1bGF0ZSB0aGUgZGV0ZWN0aW9u IHRpbWUgZm9yIHBhdGggZmFpbHVyZS4gIElmIG5vPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgdGhlIHRhaWxzIHRvIGNhbGN1bGF0ZSB0aGUgZGV0ZWN0aW9uIHRpbWUgZm9yIHBh dGggZmFpbHVyZS4gIElmIG5vPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBCRkQgQ29u dHJvbCBwYWNrZXRzIGFyZSByZWNlaXZlZCBieSBhIHRhaWwgZm9yIGEgZGV0ZWN0aW9uIHRpbWUs IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEJGRCBDb250cm9sIHBhY2tl dHMgYXJlIHJlY2VpdmVkIGJ5IGEgdGFpbCBmb3IgYSBkZXRlY3Rpb24gdGltZSwgdGhlPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA5Ij48dGQ+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgIHRhaWwgZGVjbGFyZXMgdGhlIHBhdGggdG8gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ aGF2ZTwvc3Bhbj4gZmFpbGVkLiAgRm9yIHNvbWUgYXBwbGljYXRpb25zIHRoaXMgaXM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgdGFpbCBkZWNsYXJlcyB0aGUgcGF0aCB0byA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5oYXZpbmc8L3NwYW4+IGZhaWxlZC4gIEZvciBzb21lIGFwcGxp Y2F0aW9ucyB0aGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHRoZSBvbmx5IG1l Y2hhbmlzbSBuZWNlc3Nhcnk7IHRoZSBoZWFkIGNhbiByZW1haW4gaWdub3JhbnQgb2YgdGhlPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGlzIHRoZSBvbmx5IG1lY2hhbmlzbSBu ZWNlc3Nhcnk7IHRoZSBoZWFkIGNhbiByZW1haW4gaWdub3JhbnQgb2YgdGhlPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICB0YWlscy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICB0YWlscy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyIGlkPSJkaWZmMDAxMCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5BPC9z cGFuPiBoZWFkIG1heSB3aXNoIHRvIGJlIGFsZXJ0ZWQgdG8gdGhlIHRhaWxzJyBjb25uZWN0aXZp dHkgKG9yIGxhY2s8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xh c3M9Imluc2VydCI+VGhlPC9zcGFuPiBoZWFkIDxzcGFuIGNsYXNzPSJpbnNlcnQiPm9mIGEgbXVs dGlwb2ludCBCRkQgc2Vzc2lvbjwvc3Bhbj4gbWF5IHdpc2ggdG8gYmUgYWxlcnRlZCB0byB0aGU8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgdGhlcmVvZikuICBEZXRhaWxzIG9mIGhv dyB0aGUgaGVhZCBrZWVwcyB0cmFjayBvZiB0YWlscyBhbmQgaG93IHRhaWxzPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHRhaWxzJyBjb25uZWN0aXZpdHkgKG9yIGxhY2sgdGhl cmVvZikuICBEZXRhaWxzIG9mIGhvdyB0aGUgaGVhZCBrZWVwczwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICBhbGVydCB0aGVpciBjb25uZWN0aXZpdHkgdG8gdGhlIGhlYWQgYXJlIG91 dHNpZGUgc2NvcGUgb2YgdGhpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICB0 cmFjayBvZiB0YWlscyBhbmQgaG93IHRhaWxzIGFsZXJ0IHRoZWlyIGNvbm5lY3Rpdml0eSB0byB0 aGUgaGVhZCBhcmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgZG9jdW1lbnQuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIG91dHNpZGUgc2NvcGUgb2YgdGhpcyBk b2N1bWVudC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQWx0aG91Z2ggdGhp cyBkb2N1bWVudCBkZXNjcmliZXMgYSBzaW5nbGUgaGVhZCBhbmQgYSBzZXQgb2YgdGFpbHM8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBbHRob3VnaCB0aGlzIGRvY3VtZW50IGRl c2NyaWJlcyBhIHNpbmdsZSBoZWFkIGFuZCBhIHNldCBvZiB0YWlsczwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgc3Bhbm5lZCBieSBhIHNpbmdsZSBtdWx0aXBvaW50IHBhdGgsIHRoZSBw cm90b2NvbCBpcyBjYXBhYmxlIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg c3Bhbm5lZCBieSBhIHNpbmdsZSBtdWx0aXBvaW50IHBhdGgsIHRoZSBwcm90b2NvbCBpcyBjYXBh YmxlIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzdXBwb3J0aW5nIChhbmQgZGlz Y3JpbWluYXRpbmcgYmV0d2VlbikgbW9yZSB0aGFuIG9uZSBtdWx0aXBvaW50IHBhdGg8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzdXBwb3J0aW5nIChhbmQgZGlzY3JpbWluYXRp bmcgYmV0d2VlbikgbW9yZSB0aGFuIG9uZSBtdWx0aXBvaW50IHBhdGg8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIGF0IGJvdGggaGVhZHMgYW5kIHRhaWxzLiAgRnVydGhlcm1vcmUsIHRo ZSBzYW1lIGhlYWQgYW5kIHRhaWwgbWF5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgYXQgYm90aCBoZWFkcyBhbmQgdGFpbHMuICBGdXJ0aGVybW9yZSwgdGhlIHNhbWUgaGVhZCBh bmQgdGFpbCBtYXk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNoYXJlIG11bHRpcGxl IG11bHRpcG9pbnQgcGF0aHMsIGFuZCBhIG11bHRpcG9pbnQgcGF0aCBtYXkgaGF2ZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNoYXJlIG11bHRpcGxlIG11bHRpcG9pbnQgcGF0 aHMsIGFuZCBhIG11bHRpcG9pbnQgcGF0aCBtYXkgaGF2ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgbXVsdGlwbGUgaGVhZHMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgbXVsdGlwbGUgaGVhZHMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjQuICBQ cm90b2NvbCBEZXRhaWxzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NC4gIFByb3Rv Y29sIERldGFpbHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHIgaWQ9InBhcnQtNiIgY2xhc3M9ImNoYW5nZSI+PHRkPjwvdGQ+PHRoPjxzbWFsbD5z a2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmYvcmZjZGlmZi5weWh0I3BhcnQtNiI+PGVtPiBwYWdlIDQsIGxpbmUgNTE8c3BhbiBj bGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+ c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTYiPjxlbT4gcGFnZSA0LCBsaW5lIDUxPHNwYW4g Y2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSBNIGJp dCBbUkZDNTg4MF0uICBUaGlzIG1lYW5zIHRoYXQgTXVsdGlwb2ludCBCRkQgZG9lcyBub3QgZGVw ZW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhlIE0gYml0IFtSRkM1ODgw XS4gIFRoaXMgbWVhbnMgdGhhdCBNdWx0aXBvaW50IEJGRCBkb2VzIG5vdCBkZXBlbmQ8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9uIHRoZSByZWNpcGllbnQgb2YgYSBwYWNrZXQgdG8g a25vdyB3aGV0aGVyIHRoZSBwYWNrZXQgd2FzIHJlY2VpdmVkPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgb24gdGhlIHJlY2lwaWVudCBvZiBhIHBhY2tldCB0byBrbm93IHdoZXRo ZXIgdGhlIHBhY2tldCB3YXMgcmVjZWl2ZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IG92ZXIgYSBtdWx0aXBvaW50IHBhdGguICBUaGlzIGNhbiBiZSB1c2VmdWwgaW4gc2NlbmFyaW9z IHdoZXJlIHRoaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvdmVyIGEgbXVs dGlwb2ludCBwYXRoLiAgVGhpcyBjYW4gYmUgdXNlZnVsIGluIHNjZW5hcmlvcyB3aGVyZSB0aGlz PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbmZvcm1hdGlvbiBtYXkgbm90IGJlIGF2 YWlsYWJsZSB0byB0aGUgcmVjaXBpZW50LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGluZm9ybWF0aW9uIG1heSBub3QgYmUgYXZhaWxhYmxlIHRvIHRoZSByZWNpcGllbnQuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjQuMi4gIFNlc3Npb24gTW9kZWw8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij40LjIuICBTZXNzaW9uIE1vZGVsPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE11bHRpcG9pbnQgQkZEIGlzIG1vZGVsZWQgYXMgYSBz ZXQgb2Ygc2Vzc2lvbnMgb2YgZGlmZmVyZW50IHR5cGVzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIE11bHRpcG9pbnQgQkZEIGlzIG1vZGVsZWQgYXMgYSBzZXQgb2Ygc2Vzc2lv bnMgb2YgZGlmZmVyZW50IHR5cGVzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhl IGVsZW1lbnRzIG9mIHByb2NlZHVyZSBkaWZmZXIgc2xpZ2h0bHkgZm9yIGVhY2ggdHlwZS48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgZWxlbWVudHMgb2YgcHJvY2VkdXJl IGRpZmZlciBzbGlnaHRseSBmb3IgZWFjaCB0eXBlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDExIj48dGQ+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFu IGNsYXNzPSJkZWxldGUiPlBvaW50LXRvLXBvaW50IHNlc3Npb25zLCBhcyBkZXNjcmliZWQgaW4g W1JGQzU4ODBdLCBhcmUgb2YgdHlwZTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUi PiAgIFBvaW50VG9Qb2ludC48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg VGhlIGhlYWQgaGFzIGEgc2Vzc2lvbiBvZiB0eXBlIE11bHRpcG9pbnRIZWFkLCBhcyBkZWZpbmVk IGluPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGhlYWQgaGFzIGEgc2Vz c2lvbiBvZiB0eXBlIE11bHRpcG9pbnRIZWFkLCBhcyBkZWZpbmVkIGluPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBTZWN0aW9uIDQuNC4xLCB0aGF0IGlzIGJvdW5kIHRvIGEgbXVsdGlw b2ludCBwYXRoLiAgTXVsdGlwb2ludCBCRkQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBTZWN0aW9uIDQuNC4xLCB0aGF0IGlzIGJvdW5kIHRvIGEgbXVsdGlwb2ludCBwYXRoLiAg TXVsdGlwb2ludCBCRkQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENvbnRyb2wgcGFj a2V0cyBhcmUgc2VudCBieSB0aGlzIHNlc3Npb24gb3ZlciB0aGUgbXVsdGlwb2ludCBwYXRoLDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENvbnRyb2wgcGFja2V0cyBhcmUgc2Vu dCBieSB0aGlzIHNlc3Npb24gb3ZlciB0aGUgbXVsdGlwb2ludCBwYXRoLDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgYW5kIG5vIEJGRCBDb250cm9sIHBhY2tldHMgYXJlIHJlY2VpdmVk IGJ5IGl0LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFuZCBubyBCRkQgQ29u dHJvbCBwYWNrZXRzIGFyZSByZWNlaXZlZCBieSBpdC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgRWFjaCB0YWlsIGhhcyBhIHNlc3Npb24gb2YgdHlwZSBNdWx0aXBvaW50VGFp bCwgYXMgZGVmaW5lZCBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEVhY2gg dGFpbCBoYXMgYSBzZXNzaW9uIG9mIHR5cGUgTXVsdGlwb2ludFRhaWwsIGFzIGRlZmluZWQgaW48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFNlY3Rpb24gNC40LjEsIGFzc29jaWF0ZWQg d2l0aCBhIG11bHRpcG9pbnQgcGF0aC4gIFRoZXNlIHNlc3Npb25zPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgU2VjdGlvbiA0LjQuMSwgYXNzb2NpYXRlZCB3aXRoIGEgbXVsdGlw b2ludCBwYXRoLiAgVGhlc2Ugc2Vzc2lvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHJlY2VpdmUgQkZEIENvbnRyb2wgcGFja2V0cyBmcm9tIHRoZSBoZWFkIG92ZXIgdGhlIG11bHRp cG9pbnQgcGF0aC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICByZWNlaXZlIEJG RCBDb250cm9sIHBhY2tldHMgZnJvbSB0aGUgaGVhZCBvdmVyIHRoZSBtdWx0aXBvaW50IHBhdGgu PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjQuMy4gIFNlc3Npb24gRmFpbHVyZSBT ZW1hbnRpY3M8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij40LjMuICBTZXNzaW9uIEZh aWx1cmUgU2VtYW50aWNzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0ciBpZD0iZGlmZjAwMTIiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgVGhlIHNlbWFudGljcyBvZiBzZXNz aW9uIGZhaWx1cmUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+YXJlPC9zcGFuPiBzdWJ0bGUgZW5vdWdo IHRvIHdhcnJhbnQgZnVydGhlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBU aGUgc2VtYW50aWNzIG9mIHNlc3Npb24gZmFpbHVyZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5pczwv c3Bhbj4gc3VidGxlIGVub3VnaCB0byB3YXJyYW50IGZ1cnRoZXI8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGV4cGxhbmF0aW9uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGV4cGxhbmF0aW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBNdWx0 aXBvaW50SGVhZCBzZXNzaW9ucyBjYW5ub3QgZmFpbCAoc2luY2UgdGhleSBhcmUgY29udHJvbGxl ZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIE11bHRpcG9pbnRIZWFkIHNlc3Np b25zIGNhbm5vdCBmYWlsIChzaW5jZSB0aGV5IGFyZSBjb250cm9sbGVkPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBhZG1pbmlzdHJhdGl2ZWx5KS48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBhZG1pbmlzdHJhdGl2ZWx5KS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgSWYgYSBNdWx0aXBvaW50VGFpbCBzZXNzaW9uIGZhaWxzLCBpdCBtZWFucyB0 aGF0IHRoZSB0YWlsIGRlZmluaXRlbHk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBJZiBhIE11bHRpcG9pbnRUYWlsIHNlc3Npb24gZmFpbHMsIGl0IG1lYW5zIHRoYXQgdGhlIHRh aWwgZGVmaW5pdGVseTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaGFzIGxvc3QgY29u dGFjdCB3aXRoIHRoZSBoZWFkIChvciB0aGUgaGVhZCBoYXMgYmVlbiBhZG1pbmlzdHJhdGl2ZWx5 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaGFzIGxvc3QgY29udGFjdCB3aXRo IHRoZSBoZWFkIChvciB0aGUgaGVhZCBoYXMgYmVlbiBhZG1pbmlzdHJhdGl2ZWx5PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkaXNhYmxlZCkgYW5kIHRoZSB0YWlsIHNob3VsZCB0YWtl IGFwcHJvcHJpYXRlIGFjdGlvbi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBk aXNhYmxlZCkgYW5kIHRoZSB0YWlsIHNob3VsZCB0YWtlIGFwcHJvcHJpYXRlIGFjdGlvbi48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+NC40LiAgU3RhdGUgVmFyaWFibGVzPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NC40LiAgU3RhdGUgVmFyaWFibGVzPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTMiPjx0 ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgTXVsdGlwb2ludCBCRkQgaW50cm9kdWNlcyBzb21lIG5ldyBzdGF0ZSB2YXJp YWJsZXM8c3BhbiBjbGFzcz0iZGVsZXRlIj4sPC9zcGFuPiBhbmQgbW9kaWZpZXMgdGhlPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIE11bHRpcG9pbnQgQkZEIGludHJvZHVjZXMg c29tZSBuZXcgc3RhdGUgdmFyaWFibGVzIGFuZCBtb2RpZmllcyB0aGU8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHVzYWdlIG9mIGEgZmV3IGV4aXN0aW5nIG9uZXMuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdXNhZ2Ugb2YgYSBmZXcgZXhpc3Rpbmcgb25lcy48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+NC40LjEuICBOZXcgU3RhdGUgVmFyaWFibGUg VmFsdWVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NC40LjEuICBOZXcgU3RhdGUg VmFyaWFibGUgVmFsdWVzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEEgbnVt YmVyIG9mIG5ldyB2YWx1ZXMgb2YgdGhlIHN0YXRlIHZhcmlhYmxlIGJmZC5TZXNzaW9uVHlwZSBh cmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBIG51bWJlciBvZiBuZXcgdmFs dWVzIG9mIHRoZSBzdGF0ZSB2YXJpYWJsZSBiZmQuU2Vzc2lvblR5cGUgYXJlPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBhZGRlZCB0byB0aGUgYmFzZSBCRkQgW1JGQzU4ODBdIGFuZCBi YXNlIFMtQkZEIFtSRkM3ODgwXTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFk ZGVkIHRvIHRoZSBiYXNlIEJGRCBbUkZDNTg4MF0gYW5kIGJhc2UgUy1CRkQgW1JGQzc4ODBdPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzcGVjaWZpY2F0aW9ucyBpbiBzdXBwb3J0IG9m IE11bHRpcG9pbnQgQkZELjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNwZWNp ZmljYXRpb25zIGluIHN1cHBvcnQgb2YgTXVsdGlwb2ludCBCRkQuPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICAgIGJmZC5TZXNzaW9uVHlwZTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgIGJmZC5TZXNzaW9uVHlwZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgICBUaGUgdHlwZSBvZiB0aGlzIHNlc3Npb24gYXMgZGVmaW5lZCBp biBbUkZDNzg4MF0uICBOZXdseSBhZGRlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgICAgIFRoZSB0eXBlIG9mIHRoaXMgc2Vzc2lvbiBhcyBkZWZpbmVkIGluIFtSRkM3ODgw XS4gIE5ld2x5IGFkZGVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICB2YWx1 ZXMgYXJlOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgIHZhbHVlcyBh cmU6PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0i ZGlmZjAwMTQiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgUG9pbnRUb1BvaW50OiBDbGFzc2ljIHBv aW50LXRvLXBvaW50IDxzcGFuIGNsYXNzPSJkZWxldGUiPkJGRC48L3NwYW4+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgIFBvaW50VG9Qb2ludDogQ2xhc3NpYyBw b2ludC10by1wb2ludCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5CRkQsIGFzIGRlc2NyaWJlZCBpbjwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgIFtSRkM1ODgwXS48 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgIE11bHRp cG9pbnRIZWFkOiBBIHNlc3Npb24gb24gdGhlIGhlYWQgcmVzcG9uc2libGUgZm9yIHRoZTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgIE11bHRpcG9pbnRIZWFkOiBB IHNlc3Npb24gb24gdGhlIGhlYWQgcmVzcG9uc2libGUgZm9yIHRoZTwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICAgICAgcGVyaW9kaWMgdHJhbnNtaXNzaW9uIG9mIG11bHRpcG9p bnQgQkZEIENvbnRyb2wgcGFja2V0czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICAgICAgICAgIHBlcmlvZGljIHRyYW5zbWlzc2lvbiBvZiBtdWx0aXBvaW50IEJGRCBDb250cm9s IHBhY2tldHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgIGFsb25nIHRo ZSBtdWx0aXBvaW50IHBhdGguPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg ICAgICAgYWxvbmcgdGhlIG11bHRpcG9pbnQgcGF0aC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgICAgICAgICAgTXVsdGlwb2ludFRhaWw6IEEgbXVsdGlwb2ludCBzZXNzaW9u IG9uIGEgdGFpbC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICBN dWx0aXBvaW50VGFpbDogQSBtdWx0aXBvaW50IHNlc3Npb24gb24gYSB0YWlsLjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICBUaGlzIHZhcmlhYmxlIE1VU1QgYmUgaW5p dGlhbGl6ZWQgdG8gdGhlIGFwcHJvcHJpYXRlIHR5cGUgd2hlbjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgICAgIFRoaXMgdmFyaWFibGUgTVVTVCBiZSBpbml0aWFsaXplZCB0 byB0aGUgYXBwcm9wcmlhdGUgdHlwZSB3aGVuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICAgICB0aGUgc2Vzc2lvbiBpcyBjcmVhdGVkLCBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVzIGlu IFNlY3Rpb24gNC4xMzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgIHRo ZSBzZXNzaW9uIGlzIGNyZWF0ZWQsIGFjY29yZGluZyB0byB0aGUgcnVsZXMgaW4gU2VjdGlvbiA0 LjEzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjQuNC4yLiAgU3RhdGUgVmFyaWFi bGUgSW5pdGlhbGl6YXRpb24gYW5kIE1haW50ZW5hbmNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+NC40LjIuICBTdGF0ZSBWYXJpYWJsZSBJbml0aWFsaXphdGlvbiBhbmQgTWFpbnRl bmFuY2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU29tZSBzdGF0ZSB2YXJp YWJsZXMgZGVmaW5lZCBpbiBzZWN0aW9uIDYuOC4xIG9mIFtSRkM1ODgwXSBuZWVkIHRvIGJlPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgU29tZSBzdGF0ZSB2YXJpYWJsZXMgZGVm aW5lZCBpbiBzZWN0aW9uIDYuOC4xIG9mIFtSRkM1ODgwXSBuZWVkIHRvIGJlPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbml0aWFsaXplZCBvciBtYW5pcHVsYXRlZCBkaWZmZXJlbnRs eSBkZXBlbmRpbmcgb24gdGhlIHNlc3Npb24gdHlwZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBpbml0aWFsaXplZCBvciBtYW5pcHVsYXRlZCBkaWZmZXJlbnRseSBkZXBlbmRp bmcgb24gdGhlIHNlc3Npb24gdHlwZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgYmZkLlJlcXVpcmVkTWluUnhJbnRlcnZhbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgIGJmZC5SZXF1aXJlZE1pblJ4SW50ZXJ2YWw8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxNSI+PHRkPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICAgICAgICBUaGlzIHZhcmlhYmxlIE1VU1QgYmUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+c2V0PC9z cGFuPiB0byAwIGZvciBzZXNzaW9uIHR5cGUgTXVsdGlwb2ludEhlYWQuPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgIFRoaXMgdmFyaWFibGUgTVVTVCBiZSA8c3BhbiBj bGFzcz0iaW5zZXJ0Ij5pbml0aWFsaXplZDwvc3Bhbj4gdG8gMCBmb3Igc2Vzc2lvbiB0eXBlPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICAgICAgICBNdWx0aXBvaW50SGVhZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgYmZkLkRlbWFuZE1vZGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICBiZmQuRGVtYW5kTW9kZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICAgICBUaGlzIHZhcmlhYmxlIE1VU1QgYmUgaW5pdGlhbGl6ZWQgdG8gMSBmb3Igc2Vzc2lv biB0eXBlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgVGhpcyB2YXJp YWJsZSBNVVNUIGJlIGluaXRpYWxpemVkIHRvIDEgZm9yIHNlc3Npb24gdHlwZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgTXVsdGlwb2ludEhlYWQgYW5kIE1VU1QgYmUgaW5p dGlhbGl6ZWQgdG8gMCBmb3Igc2Vzc2lvbiB0eXBlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgICAgTXVsdGlwb2ludEhlYWQgYW5kIE1VU1QgYmUgaW5pdGlhbGl6ZWQgdG8g MCBmb3Igc2Vzc2lvbiB0eXBlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICBN dWx0aXBvaW50VGFpbC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICBN dWx0aXBvaW50VGFpbC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+NC41LiAgU3Rh dGUgTWFjaGluZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjQuNS4gIFN0YXRlIE1h Y2hpbmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIEJGRCBzdGF0ZSBt YWNoaW5lIHdvcmtzIHNsaWdodGx5IGRpZmZlcmVudGx5IGluIHRoZSBtdWx0aXBvaW50PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIEJGRCBzdGF0ZSBtYWNoaW5lIHdvcmtz IHNsaWdodGx5IGRpZmZlcmVudGx5IGluIHRoZSBtdWx0aXBvaW50PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBhcHBsaWNhdGlvbi4gIEluIHBhcnRpY3VsYXIsIHNpbmNlIHRoZXJlIGlz IGEgbWFueS10by1vbmUgbWFwcGluZyw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBhcHBsaWNhdGlvbi4gIEluIHBhcnRpY3VsYXIsIHNpbmNlIHRoZXJlIGlzIGEgbWFueS10by1v bmUgbWFwcGluZyw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRocmVlLXdheSBoYW5k c2hha2VzIGZvciBzZXNzaW9uIGVzdGFibGlzaG1lbnQgYW5kIHRlYXJkb3duIGFyZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRocmVlLXdheSBoYW5kc2hha2VzIGZvciBzZXNz aW9uIGVzdGFibGlzaG1lbnQgYW5kIHRlYXJkb3duIGFyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxNiI+PHRkPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBuZWl0aGVy IHBvc3NpYmxlIG5vciBhcHByb3ByaWF0ZS4gIEFzIHN1Y2ggdGhlcmUgaXMgbm8gSW5pdCBzdGF0 ZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgbmVpdGhlciBwb3NzaWJsZSBu b3IgYXBwcm9wcmlhdGUuICBBcyBzdWNoPHNwYW4gY2xhc3M9Imluc2VydCI+LDwvc3Bhbj4gdGhl cmUgaXMgbm8gSW5pdCBzdGF0ZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFNlc3Np b25zIG9mIHR5cGUgTXVsdGlwb2ludEhlYWQgTVVTVCBOT1Qgc2VuZCBCRkQgY29udHJvbCBwYWNr ZXRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgU2Vzc2lvbnMgb2YgdHlwZSBN dWx0aXBvaW50SGVhZCBNVVNUIE5PVCBzZW5kIEJGRCBjb250cm9sIHBhY2tldHM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTciPjx0ZD48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgd2l0aCB0aGUgU3RhdGUgZmllbGQgYmVpbmcgc2V0IHRvIElOSVQsIGFuZCBNVVNUIGJl IGlnbm9yZWQgb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgd2l0aCB0aGUg U3RhdGUgZmllbGQgYmVpbmcgc2V0IHRvIElOSVQsIGFuZCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij50 aG9zZSBwYWNrZXRzPC9zcGFuPiBNVVNUIGJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIHJlY2VpcHQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGlnbm9yZWQg b24gcmVjZWlwdC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGZvbGxv d2luZyBkaWFncmFtIHByb3ZpZGVzIGFuIG92ZXJ2aWV3IG9mIHRoZSBzdGF0ZSBtYWNoaW5lIGZv cjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBmb2xsb3dpbmcgZGlhZ3Jh bSBwcm92aWRlcyBhbiBvdmVydmlldyBvZiB0aGUgc3RhdGUgbWFjaGluZSBmb3I8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNlc3Npb24gdHlwZSBNdWx0aXBvaW50VGFpbC4gIFRoZSBu b3RhdGlvbiBvbiBlYWNoIGFyYyByZXByZXNlbnRzIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIHNlc3Npb24gdHlwZSBNdWx0aXBvaW50VGFpbC4gIFRoZSBub3RhdGlvbiBv biBlYWNoIGFyYyByZXByZXNlbnRzIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg c3RhdGUgb2YgdGhlIHJlbW90ZSBzeXN0ZW0gKGFzIHJlY2VpdmVkIGluIHRoZSBTdGF0ZSBmaWVs ZCBpbiB0aGUgQkZEPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc3RhdGUgb2Yg dGhlIHJlbW90ZSBzeXN0ZW0gKGFzIHJlY2VpdmVkIGluIHRoZSBTdGF0ZSBmaWVsZCBpbiB0aGUg QkZEPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDb250cm9sIHBhY2tldCkgb3IgaW5k aWNhdGVzIHRoZSBleHBpcmF0aW9uIG9mIHRoZSBEZXRlY3Rpb24gVGltZXIuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ29udHJvbCBwYWNrZXQpIG9yIGluZGljYXRlcyB0aGUg ZXhwaXJhdGlvbiBvZiB0aGUgRGV0ZWN0aW9uIFRpbWVyLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERPV04sIEFETUlOIERP V04sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBET1dOLCBBRE1JTiBET1dOLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tKyAgVElNRVIgICAgICAgICAgICAgICArLS0t LS0tKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLSsgIFRJTUVSICAgICAgICAgICAgICAgKy0tLS0tLSs8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICstLS0tfCAgICAgIHwmbHQ7LS0tLS0tLS0t LS0tLS0tLS0tLS0tfCAgICAgIHwtLS0tKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgICAgICAgICAgICAgICstLS0tfCAgICAgIHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0t fCAgICAgIHwtLS0tKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgIERP V04sfCAgICB8IERPV04gfCAgICAgICAgICAgICAgICAgICAgICB8ICBVUCAgfCAgICB8VVA8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgRE9XTix8ICAgIHwgRE9X TiB8ICAgICAgICAgICAgICAgICAgICAgIHwgIFVQICB8ICAgIHxVUDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgIEFETUlOIERPV04sKy0tLSZndDt8ICAgICAgfC0tLS0tLS0tLS0t LS0tLS0tLS0tLSZndDt8ICAgICAgfCZsdDstLS0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgIEFETUlOIERPV04sKy0tLSZndDt8ICAgICAgfC0tLS0tLS0tLS0tLS0tLS0t LS0tLSZndDt8ICAgICAgfCZsdDstLS0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg ICAgICAgICBUSU1FUiAgICAgICstLS0tLS0rICAgICAgICAgIFVQICAgICAgICAgICstLS0tLS0r PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgVElNRVIgICAgICAr LS0tLS0tKyAgICAgICAgICBVUCAgICAgICAgICArLS0tLS0tKzwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBTZXNzaW9ucyBvZiB0eXBlIE11bHRpcG9pbnRIZWFkIG5ldmVyIHJl Y2VpdmUgcGFja2V0cyBhbmQgaGF2ZSBubzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIFNlc3Npb25zIG9mIHR5cGUgTXVsdGlwb2ludEhlYWQgbmV2ZXIgcmVjZWl2ZSBwYWNrZXRz IGFuZCBoYXZlIG5vPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBEZXRlY3Rpb24gVGlt ZXIsIGFuZCBhcyBzdWNoIGFsbCBzdGF0ZSB0cmFuc2l0aW9ucyBhcmU8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBEZXRlY3Rpb24gVGltZXIsIGFuZCBhcyBzdWNoIGFsbCBzdGF0 ZSB0cmFuc2l0aW9ucyBhcmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFkbWluaXN0 cmF0aXZlbHkgZHJpdmVuLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFkbWlu aXN0cmF0aXZlbHkgZHJpdmVuLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij40LjYu ICBTZXNzaW9uIEVzdGFibGlzaG1lbnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij40 LjYuICBTZXNzaW9uIEVzdGFibGlzaG1lbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxOCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBVbmxpa2UgcG9p bnQtdG8tcG9pbnQgQkZELCBNdWx0aXBvaW50IEJGRCBwcm92aWRlcyBhIGZvcm0gb2Y8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVW5saWtlIHBvaW50LXRvLXBvaW50IEJGRCwg TXVsdGlwb2ludCBCRkQgcHJvdmlkZXMgYSBmb3JtIG9mPHNwYW4gY2xhc3M9Imluc2VydCI+IHRo ZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRpc2NvdmVyeSBtZWNoYW5p c20gZm9yIHRhaWxzIHRvIGRpc2NvdmVyIHRoZSBoZWFkLiAgVGhlIG1pbmltdW08L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciB0YWlscyB0 byBkaXNjb3ZlciB0aGUgaGVhZC4gIFRoZSBtaW5pbXVtPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBhbW91bnQgb2YgYSBwcmlvcmkgaW5mb3JtYXRpb24gcmVxdWlyZWQgYm90aCBvbiB0 aGUgaGVhZCBhbmQgdGFpbHMgaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBh bW91bnQgb2YgYSBwcmlvcmkgaW5mb3JtYXRpb24gcmVxdWlyZWQgYm90aCBvbiB0aGUgaGVhZCBh bmQgdGFpbHMgaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBp ZD0iZGlmZjAwMTkiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+dGhlPC9zcGFu PiBiaW5kaW5nIHRvIHRoZSBtdWx0aXBvaW50IHBhdGggb3ZlciB3aGljaCBCRkQgaXMgcnVubmlu Zy4gIFRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBiaW5kaW5nIHRvIHRo ZSBtdWx0aXBvaW50IHBhdGggb3ZlciB3aGljaCBCRkQgaXMgcnVubmluZy4gIFRoZSBoZWFkPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGhlYWQgdHJhbnNtaXRzIE11bHRpcG9pbnQg QkZEIHBhY2tldHMgb24gdGhhdCB0cmVlLCBhbmQgdGhlIHRhaWxzPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgIHRyYW5zbWl0cyBNdWx0aXBvaW50IEJGRCBwYWNrZXRzIG9uIHRo YXQgdHJlZSwgYW5kIHRoZSB0YWlscyBsaXN0ZW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgbGlzdGVuIGZvciBCRkQgcGFja2V0cyBvbiB0aGF0IHRyZWUuICBBbGwgb3RoZXIgaW5m b3JtYXRpb24gTUFZIGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGZvciBC RkQgcGFja2V0cyBvbiB0aGF0IHRyZWUuICBBbGwgb3RoZXIgaW5mb3JtYXRpb24gTUFZIGJlPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZXRlcm1pbmVkIGR5bmFtaWNhbGx5LjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRldGVybWluZWQgZHluYW1pY2FsbHkuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEEgc2Vzc2lvbiBvZiB0eXBlIE11bHRp cG9pbnRIZWFkIGlzIGNyZWF0ZWQgZm9yIGVhY2ggbXVsdGlwb2ludCBwYXRoPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQSBzZXNzaW9uIG9mIHR5cGUgTXVsdGlwb2ludEhlYWQg aXMgY3JlYXRlZCBmb3IgZWFjaCBtdWx0aXBvaW50IHBhdGg8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIG92ZXIgd2hpY2ggdGhlIGhlYWQgd2lzaGVzIHRvIHJ1biBCRkQuICBUaGlzIHNl c3Npb24gcnVucyBpbiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvdmVy IHdoaWNoIHRoZSBoZWFkIHdpc2hlcyB0byBydW4gQkZELiAgVGhpcyBzZXNzaW9uIHJ1bnMgaW4g dGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBY3RpdmUgcm9sZSAsIHBlciBzZWN0 aW9uIDYuMSBbUkZDNTg4MF0uICBFeGNlcHQgd2hlbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIEFjdGl2ZSByb2xlICwgcGVyIHNlY3Rpb24gNi4xIFtSRkM1ODgwXS4gIEV4Y2Vw dCB3aGVuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhZG1pbmlzdHJhdGl2ZWx5IHRl cm1pbmF0aW5nIEJGRCBzZXJ2aWNlLCB0aGlzIHNlc3Npb24gaXMgYWx3YXlzIGluPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYWRtaW5pc3RyYXRpdmVseSB0ZXJtaW5hdGluZyBC RkQgc2VydmljZSwgdGhpcyBzZXNzaW9uIGlzIGFsd2F5cyBpbjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgc3RhdGUgVXAgYW5kIGFsd2F5cyBvcGVyYXRlcyBpbiBEZW1hbmQgbW9kZS4g IE5vIHJlY2VpdmVkIHBhY2tldHMgYXJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgc3RhdGUgVXAgYW5kIGFsd2F5cyBvcGVyYXRlcyBpbiBEZW1hbmQgbW9kZS4gIE5vIHJlY2Vp dmVkIHBhY2tldHMgYXJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHIgaWQ9ImRpZmYwMDIwIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGV2ZXIgZGVtdWx0aXBsZXhlZCB0byB0aGUg TXVsdGlwb2ludEhlYWQgc2Vzc2lvbi4gIEluIHRoaXMgc2Vuc2UgaXQ8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgZXZlciBkZW11bHRpcGxleGVkIHRvIHRoZSBNdWx0aXBvaW50 SGVhZCBzZXNzaW9uLiAgSW4gdGhpcyBzZW5zZTxzcGFuIGNsYXNzPSJpbnNlcnQiPiw8L3NwYW4+ IGl0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpcyBhIGRlZ2VuZXJhdGUgZm9ybSBv ZiBhIHNlc3Npb24uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaXMgYSBkZWdl bmVyYXRlIGZvcm0gb2YgYSBzZXNzaW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBTZXNzaW9ucyBvbiB0aGUgdGFpbCBNQVkgYmUgZXN0YWJsaXNoZWQgZHluYW1pY2FsbHks IGJhc2VkIG9uIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNlc3Npb25z IG9uIHRoZSB0YWlsIE1BWSBiZSBlc3RhYmxpc2hlZCBkeW5hbWljYWxseSwgYmFzZWQgb24gdGhl PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZWNlaXB0IG9mIGEgTXVsdGlwb2ludCBC RkQgQ29udHJvbCBwYWNrZXQgZnJvbSB0aGUgaGVhZCwgYW5kIGFyZSBvZjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIHJlY2VpcHQgb2YgYSBNdWx0aXBvaW50IEJGRCBDb250cm9s IHBhY2tldCBmcm9tIHRoZSBoZWFkLCBhbmQgYXJlIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICB0eXBlIE11bHRpcG9pbnRUYWlsLiAgVGFpbCBzZXNzaW9ucyBhbHdheXMgdGFrZSB0 aGUgUGFzc2l2ZSByb2xlLCBwZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0 eXBlIE11bHRpcG9pbnRUYWlsLiAgVGFpbCBzZXNzaW9ucyBhbHdheXMgdGFrZSB0aGUgUGFzc2l2 ZSByb2xlLCBwZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNlY3Rpb24gNi4xIFtS RkM1ODgwXS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzZWN0aW9uIDYuMSBb UkZDNTg4MF0uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjQuNy4gIERpc2NyaW1p bmF0b3JzIGFuZCBQYWNrZXQgRGVtdWx0aXBsZXhpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij40LjcuICBEaXNjcmltaW5hdG9ycyBhbmQgUGFja2V0IERlbXVsdGlwbGV4aW5nPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSB1c2Ugb2YgRGlzY3JpbWluYXRv cnMgaXMgc29tZXdoYXQgZGlmZmVyZW50IGluIE11bHRpcG9pbnQgQkZEPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIHVzZSBvZiBEaXNjcmltaW5hdG9ycyBpcyBzb21ld2hh dCBkaWZmZXJlbnQgaW4gTXVsdGlwb2ludCBCRkQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTciIGNsYXNzPSJjaGFuZ2UiPjx0ZD48L3Rk Pjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTciPjxlbT4gcGFnZSA4LCBs aW5lIDIwPHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90 aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC03Ij48ZW0+IHBhZ2UgOCwg bGluZSAyMDxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBleHBsYW5hdGlvbnMgYW5kIHVzYWdlIGluIFtSRkM4MDI5XS4gIFBhY2tldHMgaWRlbnRp ZmllZCBhcyBCRkQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBleHBsYW5hdGlv bnMgYW5kIHVzYWdlIGluIFtSRkM4MDI5XS4gIFBhY2tldHMgaWRlbnRpZmllZCBhcyBCRkQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHBhY2tldHMgTVVTVCBiZSBjb25zdW1lZCBieSBN dWx0aXBvaW50VGFpbCBhbmQgZGVtdWx0aXBsZXggYXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBwYWNrZXRzIE1VU1QgYmUgY29uc3VtZWQgYnkgTXVsdGlwb2ludFRhaWwgYW5k IGRlbXVsdGlwbGV4IGFzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZXNjcmliZWQg aW4gU2VjdGlvbiA0LjEzLjIuICBVc2Ugb2Ygb3RoZXIgdHlwZXMgb2YgZW5jYXBzdWxhdGlvbiBv ZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRlc2NyaWJlZCBpbiBTZWN0aW9u IDQuMTMuMi4gIFVzZSBvZiBvdGhlciB0eXBlcyBvZiBlbmNhcHN1bGF0aW9uIG9mPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGUgQkZEIGNvbnRyb2wgbWVzc2FnZSBvdmVyIG11bHRp cG9pbnQgTFNQIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgdGhlIEJGRCBjb250cm9sIG1lc3NhZ2Ugb3ZlciBtdWx0aXBvaW50IExTUCBp cyBvdXRzaWRlIHRoZSBzY29wZSBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhp cyBkb2N1bWVudC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGlzIGRvY3Vt ZW50LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij40LjkuICBCcmluZ2luZyBVcCBh bmQgU2h1dHRpbmcgRG93biBNdWx0aXBvaW50IEJGRCBTZXJ2aWNlPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+NC45LiAgQnJpbmdpbmcgVXAgYW5kIFNodXR0aW5nIERvd24gTXVsdGlw b2ludCBCRkQgU2VydmljZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBCZWNh dXNlIHRoZXJlIGlzIG5vIHRocmVlLXdheSBoYW5kc2hha2UgaW4gTXVsdGlwb2ludCBCRkQsIGEg bmV3bHk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBCZWNhdXNlIHRoZXJlIGlz IG5vIHRocmVlLXdheSBoYW5kc2hha2UgaW4gTXVsdGlwb2ludCBCRkQsIGEgbmV3bHk8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHN0YXJ0ZWQgaGVhZCAodGhhdCBkb2VzIG5vdCBoYXZl IGFueSBwcmV2aW91cyBzdGF0ZSBpbmZvcm1hdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIHN0YXJ0ZWQgaGVhZCAodGhhdCBkb2VzIG5vdCBoYXZlIGFueSBwcmV2aW91cyBz dGF0ZSBpbmZvcm1hdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyIGlkPSJkaWZmMDAyMSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBhdmFpbGFibGUpIFNIT1VMRCBzdGFydCB3 aXRoIGJmZC5TZXNzaW9uU3RhdGUgc2V0IHRvIERvd24gYW5kIDxzcGFuIGNsYXNzPSJkZWxldGUi PndpdGg8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGF2YWlsYWJs ZSkgU0hPVUxEIHN0YXJ0IHdpdGggYmZkLlNlc3Npb25TdGF0ZSBzZXQgdG8gRG93biBhbmQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgYmZkLlJlcXVpcmVkTWluUnhJbnRlcnZhbCBz ZXQgdG8gemVybyBpbiB0aGUgTXVsdGlwb2ludEhlYWQgc2Vzc2lvbi48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgYmZkLlJlcXVpcmVkTWluUnhJbnRlcnZhbCA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij5NVVNUIGJlPC9zcGFuPiBzZXQgdG8gemVybyBpbiB0aGUgTXVsdGlwb2ludEhl YWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgVGhlIHNlc3Npb24gU0hPVUxEIHJl bWFpbiBpbiB0aGlzIHN0YXRlIGZvciBhIHRpbWUgZXF1YWwgdG88L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgc2Vzc2lvbi4gIFRoZSBzZXNzaW9uIFNIT1VMRCByZW1haW4gaW4g dGhpcyBzdGF0ZSBmb3IgYSB0aW1lIGVxdWFsIHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAoYmZkLkRlc2lyZWRNaW5UeEludGVydmFsICogYmZkLkRldGVjdE11bHQpLiAgVGhpcyB3 aWxsIGVuc3VyZSB0aGF0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKGJmZC5E ZXNpcmVkTWluVHhJbnRlcnZhbCAqIGJmZC5EZXRlY3RNdWx0KS4gIFRoaXMgd2lsbCBlbnN1cmUg dGhhdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYWxsIE11bHRpcG9pbnRUYWlsIHNl c3Npb25zIGFyZSByZXNldCAoc28gbG9uZyBhcyB0aGUgcmVzdGFydGVkIGhlYWQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbGwgTXVsdGlwb2ludFRhaWwgc2Vzc2lvbnMgYXJl IHJlc2V0IChzbyBsb25nIGFzIHRoZSByZXN0YXJ0ZWQgaGVhZDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyMiI+PHRkPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBpcyB1 c2luZyB0aGUgc2FtZSBvciBsYXJnZXIgdmFsdWUgb2YgYmZkLkRlc2lyZWRNaW5UeEludGVydmFs IHRoYW4gaXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgaXMgdXNpbmcgdGhl IHNhbWUgb3IgPHNwYW4gY2xhc3M9Imluc2VydCI+YTwvc3Bhbj4gbGFyZ2VyIHZhbHVlIG9mIGJm ZC5EZXNpcmVkTWluVHhJbnRlcnZhbCB0aGFuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIGRpZCBwcmV2aW91c2x5KS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg aXQgZGlkIHByZXZpb3VzbHkpLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBN dWx0aXBvaW50IEJGRCBzZXJ2aWNlIGlzIGJyb3VnaHQgdXAgYnkgYWRtaW5pc3RyYXRpdmVseSBz ZXR0aW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTXVsdGlwb2ludCBCRkQg c2VydmljZSBpcyBicm91Z2h0IHVwIGJ5IGFkbWluaXN0cmF0aXZlbHkgc2V0dGluZzwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYmZkLlNlc3Npb25TdGF0ZSB0byBVcCBpbiB0aGUgTXVs dGlwb2ludEhlYWQgc2Vzc2lvbi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBi ZmQuU2Vzc2lvblN0YXRlIHRvIFVwIGluIHRoZSBNdWx0aXBvaW50SGVhZCBzZXNzaW9uLjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDIz Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPkE8L3NwYW4+IGhlYWQgbWF5IHdp c2ggdG8gc2h1dCBkb3duIGl0cyBCRkQgc2VydmljZSBpbiBhIGNvbnRyb2xsZWQgZmFzaGlvbi48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+ VGhlPC9zcGFuPiBoZWFkIDxzcGFuIGNsYXNzPSJpbnNlcnQiPm9mIGEgbXVsdGlwb2ludCBCRkQg c2Vzc2lvbjwvc3Bhbj4gbWF5IHdpc2ggdG8gc2h1dCBkb3duIGl0cyBCRkQ8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgVGhpcyBpcyBkZXNpcmFibGUgYmVjYXVzZSB0aGUgdGFpbHMg bmVlZCBub3Qgd2FpdCBhIGRldGVjdGlvbiB0aW1lPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgIHNlcnZpY2UgaW4gYSBjb250cm9sbGVkIGZhc2hpb24uICBUaGlzIGlzIGRlc2ly YWJsZSBiZWNhdXNlIHRoZSB0YWlsczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBw cmlvciB0byBkZWNsYXJpbmcgdGhlIG11bHRpcG9pbnQgc2Vzc2lvbiB0byBiZSBkb3duIChhbmQg dGFraW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIG5lZWQgbm90IHdhaXQg YSBkZXRlY3Rpb24gdGltZSBwcmlvciB0byBkZWNsYXJpbmcgdGhlIG11bHRpcG9pbnQ8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgd2hhdGV2ZXIgYWN0aW9uIGlzIG5lY2Vzc2FyeSBp biB0aGF0IGNhc2UpLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBzZXNzaW9u IHRvIGJlIGRvd24gKGFuZCB0YWtpbmcgd2hhdGV2ZXIgYWN0aW9uIGlzIG5lY2Vzc2FyeSBpbiB0 aGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICBjYXNlKS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyNCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUbyBzaHV0IGRvd24gYSBt dWx0aXBvaW50IHNlc3Npb24gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+YTwvc3Bhbj4gaGVhZCBNVVNU IGFkbWluaXN0cmF0aXZlbHkgc2V0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg IFRvIHNodXQgZG93biBhIG11bHRpcG9pbnQgc2Vzc2lvbiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij50 aGU8L3NwYW4+IGhlYWQgTVVTVCBhZG1pbmlzdHJhdGl2ZWx5IHNldDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgYmZkLlNlc3Npb25TdGF0ZSBpbiB0aGUgTXVsdGlwb2ludEhlYWQgc2Vz c2lvbiB0byBlaXRoZXIgRG93biBvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGJmZC5TZXNzaW9uU3RhdGUgaW4gdGhlIE11bHRpcG9pbnRIZWFkIHNlc3Npb24gdG8gZWl0aGVy IERvd24gb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEFkbWluRG93biBhbmQgU0hP VUxEIHNldCBiZmQuUmVxdWlyZWRNaW5SeEludGVydmFsIHRvIHplcm8uICBUaGU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBZG1pbkRvd24gYW5kIFNIT1VMRCBzZXQgYmZkLlJl cXVpcmVkTWluUnhJbnRlcnZhbCB0byB6ZXJvLiAgVGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBzZXNzaW9uIFNIT1VMRCBzZW5kIEJGRCBDb250cm9sIHBhY2tldHMgaW4gdGhpcyBz dGF0ZSBmb3IgYSBwZXJpb2Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzZXNz aW9uIFNIT1VMRCBzZW5kIEJGRCBDb250cm9sIHBhY2tldHMgaW4gdGhpcyBzdGF0ZSBmb3IgYSBw ZXJpb2Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGVxdWFsIHRvIChiZmQuRGVzaXJl ZE1pblR4SW50ZXJ2YWwgKiBiZmQuRGV0ZWN0TXVsdCkuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgZXF1YWwgdG8gKGJmZC5EZXNpcmVkTWluVHhJbnRlcnZhbCAqIGJmZC5EZXRl Y3RNdWx0KS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIHNlbWFudGlj IGRpZmZlcmVuY2UgYmV0d2VlbiBEb3duIGFuZCBBZG1pbkRvd24gc3RhdGUgaXMgZm9yPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIHNlbWFudGljIGRpZmZlcmVuY2UgYmV0 d2VlbiBEb3duIGFuZCBBZG1pbkRvd24gc3RhdGUgaXMgZm9yPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBmdXJ0aGVyIGRpc2N1c3Npb24uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgZnVydGhlciBkaXNjdXNzaW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij40LjEwLiAgVGltZXIgTWFuaXB1bGF0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+NC4xMC4gIFRpbWVyIE1hbmlwdWxhdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBCZWNhdXNlIG9mIHRoZSBvbmUtdG8tbWFueSBtYXBwaW5nLCBhIHNlc3Npb24g b2YgdHlwZSBNdWx0aXBvaW50SGVhZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IEJlY2F1c2Ugb2YgdGhlIG9uZS10by1tYW55IG1hcHBpbmcsIGEgc2Vzc2lvbiBvZiB0eXBlIE11 bHRpcG9pbnRIZWFkPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBTSE9VTEQgTk9UIGlu aXRpYXRlIGEgUG9sbCBTZXF1ZW5jZSBpbiBjb25qdW5jdGlvbiB3aXRoIHRpbWVyIHZhbHVlPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgU0hPVUxEIE5PVCBpbml0aWF0ZSBhIFBv bGwgU2VxdWVuY2UgaW4gY29uanVuY3Rpb24gd2l0aCB0aW1lciB2YWx1ZTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgY2hhbmdlcy4gIEhvd2V2ZXIsIHRvIGluZGljYXRlIGEgY2hhbmdl IGluIHRoZSBwYWNrZXRzLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNoYW5n ZXMuICBIb3dldmVyLCB0byBpbmRpY2F0ZSBhIGNoYW5nZSBpbiB0aGUgcGFja2V0cyw8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE11bHRpcG9pbnRIZWFkIHNlc3Npb24gTVVTVCBzZW5k IHBhY2tldHMgd2l0aCB0aGUgUCBiaXQgc2V0LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIE11bHRpcG9pbnRIZWFkIHNlc3Npb24gTVVTVCBzZW5kIHBhY2tldHMgd2l0aCB0aGUg UCBiaXQgc2V0LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlk PSJkaWZmMDAyNSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5NdWx0aXBvaW50 VGFpbCBzZXNzaW9uIE1VU1QgTk9UIHJlcGx5IGlmIHBhY2tldCBoYXMgTSwgUCBiaXQgc2V0IGFu ZDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIGJmZC5SZXF1aXJlZE1pblJ4 SW50ZXJ2YWwgc2V0IHRvIDAuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJk aWZmMDAyNiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUaGUgTXVsdGlwb2ludEhlYWQsIHdoZW4gY2hhbmdpbmcg dGhlIHRyYW5zbWl0IGludGVydmFsIHRvIGhpZ2hlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5NdWx0aXBvaW50VGFpbCBzZXNzaW9uIE1V U1QgTk9UIHJlcGx5IGlmIHRoZSBwYWNrZXQgaGFzIE0gYW5kIFAgYml0czwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHNldCBhbmQgYmZkLlJlcXVpcmVkTWluUnhJbnRlcnZh bCBzZXQgdG8gMC48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBUaGUg TXVsdGlwb2ludEhlYWQsIHdoZW4gY2hhbmdpbmcgdGhlIHRyYW5zbWl0IGludGVydmFsIHRvIDxz cGFuIGNsYXNzPSJpbnNlcnQiPmE8L3NwYW4+IGhpZ2hlcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgdmFsdWUsIE1VU1Qgc2VuZCBCRkQgY29udHJvbCBwYWNrZXRzIHdpdGggUCBiaXQg c2V0IGF0IHRoZSBvbGQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB2YWx1ZSwg TVVTVCBzZW5kIEJGRCBjb250cm9sIHBhY2tldHMgd2l0aCBQIGJpdCBzZXQgYXQgdGhlIG9sZDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdHJhbnNtaXQgaW50ZXJ2YWwgYmVmb3JlIHVz aW5nIHRoZSBoaWdoZXIgdmFsdWUgaW4gb3JkZXIgdG8gYXZvaWQ8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICB0cmFuc21pdCBpbnRlcnZhbCBiZWZvcmUgdXNpbmcgdGhlIGhpZ2hl ciB2YWx1ZSBpbiBvcmRlciB0byBhdm9pZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ZmFsc2UgZGV0ZWN0aW9uIHRpbWVvdXRzIGF0IHRoZSB0YWlscy4gIE11bHRpcG9pbnRIZWFkIHNl c3Npb24gTUFZPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZmFsc2UgZGV0ZWN0 aW9uIHRpbWVvdXRzIGF0IHRoZSB0YWlscy4gIE11bHRpcG9pbnRIZWFkIHNlc3Npb24gTUFZPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhbHNvIHdhaXQgc29tZSBhbW91bnQgb2YgdGlt ZSBiZWZvcmUgbWFraW5nIHRoZSBjaGFuZ2VzIHRvIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIGFsc28gd2FpdCBzb21lIGFtb3VudCBvZiB0aW1lIGJlZm9yZSBtYWtpbmcg dGhlIGNoYW5nZXMgdG8gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0cmFuc21p dCBpbnRlcnZhbCAodGhyb3VnaCBjb25maWd1cmF0aW9uKS48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICB0cmFuc21pdCBpbnRlcnZhbCAodGhyb3VnaCBjb25maWd1cmF0aW9uKS48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ2hhbmdlIGluIHRoZSB2YWx1ZSBv ZiBiZmQuUmVxdWlyZWRNaW5SeEludGVydmFsIGlzIG91dHNpZGUgdGhlIHNjb3BlPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ2hhbmdlIGluIHRoZSB2YWx1ZSBvZiBiZmQuUmVx dWlyZWRNaW5SeEludGVydmFsIGlzIG91dHNpZGUgdGhlIHNjb3BlPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBvZiB0aGlzIGRvY3VtZW50LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIG9mIHRoaXMgZG9jdW1lbnQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjQuMTEuICBEZXRlY3Rpb24gVGltZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij40LjExLiAgRGV0ZWN0aW9uIFRpbWVzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC04IiBjbGFzcz0iY2hhbmdlIj48dGQ+PC90ZD48dGg+ PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC04Ij48ZW0+IHBhZ2UgMTEsIGxpbmUg NDE8c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0 aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTgiPjxlbT4gcGFnZSAxMSwgbGlu ZSA0MTxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICBJZiBiZmQuU2Vzc2lvblR5cGUgaXMgUG9pbnRUb1BvaW50LCB1cGRhdGUgdGhlIERldGVj dGlvbiBUaW1lIGFzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgSWYgYmZk LlNlc3Npb25UeXBlIGlzIFBvaW50VG9Qb2ludCwgdXBkYXRlIHRoZSBEZXRlY3Rpb24gVGltZSBh czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgZGVzY3JpYmVkIGluIHNlY3Rpb24g Ni44LjQgb2YgW1JGQzU4ODBdLiAgSWYgYmZkLlNlc3Npb25UeXBlIGlzPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgZGVzY3JpYmVkIGluIHNlY3Rpb24gNi44LjQgb2YgW1JG QzU4ODBdLiAgSWYgYmZkLlNlc3Npb25UeXBlIGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICBNdWx0aXBvaW50VGFpbCwgdGhlbiB1cGRhdGUgdGhlIERldGVjdGlvbiBUaW1lIGFz IHRoZSBwcm9kdWN0IG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgTXVs dGlwb2ludFRhaWwsIHRoZW4gdXBkYXRlIHRoZSBEZXRlY3Rpb24gVGltZSBhcyB0aGUgcHJvZHVj dCBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgdGhlIGxhc3QgcmVjZWl2ZWQg dmFsdWVzIG9mIERlc2lyZWQgTWluIFRYIEludGVydmFsIGFuZCBEZXRlY3Q8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICB0aGUgbGFzdCByZWNlaXZlZCB2YWx1ZXMgb2YgRGVz aXJlZCBNaW4gVFggSW50ZXJ2YWwgYW5kIERldGVjdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgTXVsdCwgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC4xMSBvZiB0aGlzIHNwZWNp ZmljYXRpb24uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgTXVsdCwgYXMg ZGVzY3JpYmVkIGluIFNlY3Rpb24gNC4xMSBvZiB0aGlzIHNwZWNpZmljYXRpb24uPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIElmIGJmZC5TZXNzaW9uU3RhdGUgaXMgQWRt aW5Eb3duPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgSWYgYmZkLlNlc3Np b25TdGF0ZSBpcyBBZG1pbkRvd248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgICAgRGlzY2FyZCB0aGUgcGFja2V0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgICAgRGlzY2FyZCB0aGUgcGFja2V0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMjciPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgSWYgcmVj ZWl2ZWQgc3RhdGUgaXMgQWRtaW5Eb3duPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgICAgIElmIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnRoZSA8L3NwYW4+cmVjZWl2ZWQgc3RhdGUg aXMgQWRtaW5Eb3duPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgIElm IGJmZC5TZXNzaW9uU3RhdGUgaXMgbm90IERvd248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICAgICBJZiBiZmQuU2Vzc2lvblN0YXRlIGlzIG5vdCBEb3duPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgIFNldCBiZmQuTG9jYWxEaWFnIHRvIDMg KE5laWdoYm9yIHNpZ25hbGVkIHNlc3Npb24gZG93bik8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICAgICAgICBTZXQgYmZkLkxvY2FsRGlhZyB0byAzIChOZWlnaGJvciBzaWdu YWxlZCBzZXNzaW9uIGRvd24pPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg ICAgICAgIFNldCBiZmQuU2Vzc2lvblN0YXRlIHRvIERvd248L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgICAgICAgICBTZXQgYmZkLlNlc3Npb25TdGF0ZSB0byBEb3duPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIEVsc2U8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICBFbHNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgIElmIGJmZC5TZXNzaW9uU3RhdGUgaXMgRG93bjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgICAgIElmIGJmZC5TZXNzaW9uU3RhdGUgaXMgRG93bjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9InBhcnQtOSIgY2xh c3M9ImNoYW5nZSI+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3Nt YWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmYvcmZjZGlmZi5weWh0I3Bh cnQtOSI+PGVtPiBwYWdlIDEyLCBsaW5lIDM3PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48 L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwv c21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQj cGFydC05Ij48ZW0+IHBhZ2UgMTIsIGxpbmUgMzc8c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFu PjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICBJZiByZWNlaXZlZCBTdGF0 ZSBpcyBEb3duPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgSWYg cmVjZWl2ZWQgU3RhdGUgaXMgRG93bjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICAgICAgICAgICBTZXQgYmZkLkxvY2FsRGlhZyB0byAzIChOZWlnaGJvciBzaWduYWxlZCBz ZXNzaW9uIGRvd24pPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAg ICAgU2V0IGJmZC5Mb2NhbERpYWcgdG8gMyAoTmVpZ2hib3Igc2lnbmFsZWQgc2Vzc2lvbiBkb3du KTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICBTZXQgYmZk LlNlc3Npb25TdGF0ZSB0byBEb3duPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgICAgICAgICAgU2V0IGJmZC5TZXNzaW9uU3RhdGUgdG8gRG93bjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBDaGVjayB0byBzZWUgaWYgRGVtYW5kIG1vZGUgc2hvdWxk IGJlY29tZSBhY3RpdmUgb3Igbm90IChzZWU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICBDaGVjayB0byBzZWUgaWYgRGVtYW5kIG1vZGUgc2hvdWxkIGJlY29tZSBhY3RpdmUg b3Igbm90IChzZWU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIFtSRkM1ODgwXSBz ZWN0aW9uIDYuNikuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgW1JGQzU4 ODBdIHNlY3Rpb24gNi42KS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyIGlkPSJkaWZmMDAyOCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICBJZiBiZmQuUmVtb3RlRGVt YW5kTW9kZSBpcyAxLCBiZmQuU2Vzc2lvblN0YXRlIGlzIFVwPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ LDwvc3Bhbj4gYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIElmIGJm ZC5SZW1vdGVEZW1hbmRNb2RlIGlzIDEsIGJmZC5TZXNzaW9uU3RhdGUgaXMgVXAgYW5kPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBiZmQuUmVtb3RlU2Vzc2lvblN0YXRlIGlzIFVw LCBEZW1hbmQgbW9kZSBpcyBhY3RpdmUgb24gdGhlIHJlbW90ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgIGJmZC5SZW1vdGVTZXNzaW9uU3RhdGUgaXMgVXAsIERlbWFuZCBt b2RlIGlzIGFjdGl2ZSBvbiB0aGUgcmVtb3RlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICBzeXN0ZW0gYW5kIHRoZSBsb2NhbCBzeXN0ZW0gTVVTVCBjZWFzZSB0aGUgcGVyaW9kaWMg dHJhbnNtaXNzaW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgc3lzdGVt IGFuZCB0aGUgbG9jYWwgc3lzdGVtIE1VU1QgY2Vhc2UgdGhlIHBlcmlvZGljIHRyYW5zbWlzc2lv bjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgb2YgQkZEIENvbnRyb2wgcGFja2V0 cyAoc2VlIFNlY3Rpb24gNC4xMy4zKS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgICBvZiBCRkQgQ29udHJvbCBwYWNrZXRzIChzZWUgU2VjdGlvbiA0LjEzLjMpLjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBJZiBiZmQuUmVtb3RlRGVtYW5kTW9kZSBp cyAwLCBvciBiZmQuU2Vzc2lvblN0YXRlIGlzIG5vdCBVcCwgb3I8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICBJZiBiZmQuUmVtb3RlRGVtYW5kTW9kZSBpcyAwLCBvciBiZmQu U2Vzc2lvblN0YXRlIGlzIG5vdCBVcCwgb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgIGJmZC5SZW1vdGVTZXNzaW9uU3RhdGUgaXMgbm90IFVwLCBEZW1hbmQgbW9kZSBpcyBub3Qg YWN0aXZlIG9uIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGJmZC5S ZW1vdGVTZXNzaW9uU3RhdGUgaXMgbm90IFVwLCBEZW1hbmQgbW9kZSBpcyBub3QgYWN0aXZlIG9u IHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgcmVtb3RlIHN5c3RlbSBhbmQg dGhlIGxvY2FsIHN5c3RlbSBNVVNUIHNlbmQgcGVyaW9kaWMgQkZEIENvbnRyb2w8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICByZW1vdGUgc3lzdGVtIGFuZCB0aGUgbG9jYWwg c3lzdGVtIE1VU1Qgc2VuZCBwZXJpb2RpYyBCRkQgQ29udHJvbDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyOSI+PHRkPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICBw YWNrZXRzIChzZWUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+c2VlIDwvc3Bhbj5TZWN0aW9uIDQuMTMu MykuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIHBhY2tldHMgKHNlZSBT ZWN0aW9uIDQuMTMuMykuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIElm IHRoZSBwYWNrZXQgd2FzIG5vdCBkaXNjYXJkZWQsIGl0IGhhcyBiZWVuIHJlY2VpdmVkIGZvciBw dXJwb3NlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIElmIHRoZSBwYWNr ZXQgd2FzIG5vdCBkaXNjYXJkZWQsIGl0IGhhcyBiZWVuIHJlY2VpdmVkIGZvciBwdXJwb3Nlczwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgb2YgdGhlIERldGVjdGlvbiBUaW1lIGV4 cGlyYXRpb24gcnVsZXMgaW4gW1JGQzU4ODBdIHNlY3Rpb24gNi44LjQuPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgb2YgdGhlIERldGVjdGlvbiBUaW1lIGV4cGlyYXRpb24g cnVsZXMgaW4gW1JGQzU4ODBdIHNlY3Rpb24gNi44LjQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjQuMTMuMi4gIERlbXVsdGlwbGV4aW5nIEJGRCBDb250cm9sIFBhY2tldHM8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij40LjEzLjIuICBEZW11bHRpcGxleGluZyBCRkQg Q29udHJvbCBQYWNrZXRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMg c2VjdGlvbiBpcyBwYXJ0IG9mIHRoZSByZXBsYWNlbWVudCBmb3IgW1JGQzU4ODBdIHNlY3Rpb24g Ni44LjYsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBzZWN0aW9uIGlz IHBhcnQgb2YgdGhlIHJlcGxhY2VtZW50IGZvciBbUkZDNTg4MF0gc2VjdGlvbiA2LjguNiw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNlcGFyYXRlZCBmb3IgY2xhcml0eS48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzZXBhcmF0ZWQgZm9yIGNsYXJpdHkuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIElmIHRoZSBNdWx0aXBvaW50IChNKSBi aXQgaXMgc2V0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgSWYgdGhlIE11 bHRpcG9pbnQgKE0pIGJpdCBpcyBzZXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTEwIiBjbGFzcz0iY2hhbmdlIj48dGQ+PC90ZD48dGg+ PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC0xMCI+PGVtPiBwYWdlIDE1LCBsaW5l IDM2PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48 dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC0xMCI+PGVtPiBwYWdlIDE1LCBs aW5lIDM2PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgIHJlY2VpdmVkIHdpdGggdGhlIFBvbGwgKFApIGJpdCBzZXQsIG9yIDAgaWYgbm90 LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgIHJlY2VpdmVkIHdpdGgg dGhlIFBvbGwgKFApIGJpdCBzZXQsIG9yIDAgaWYgbm90LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICBDb250cm9sIFBsYW5lIEluZGVwZW5kZW50IChDKTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIENvbnRyb2wgUGxhbmUgSW5kZXBlbmRlbnQgKEMp PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgIFNldCB0byAxIGlmIHRo ZSBsb2NhbCBzeXN0ZW0ncyBCRkQgaW1wbGVtZW50YXRpb24gaXM8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICAgICBTZXQgdG8gMSBpZiB0aGUgbG9jYWwgc3lzdGVtJ3MgQkZE IGltcGxlbWVudGF0aW9uIGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICBp bmRlcGVuZGVudCBvZiB0aGUgY29udHJvbCBwbGFuZSAoaXQgY2FuIGNvbnRpbnVlIHRvIGZ1bmN0 aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgaW5kZXBlbmRlbnQg b2YgdGhlIGNvbnRyb2wgcGxhbmUgKGl0IGNhbiBjb250aW51ZSB0byBmdW5jdGlvbjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgdGhyb3VnaCBhIGRpc3J1cHRpb24gb2YgdGhl IGNvbnRyb2wgcGxhbmUpLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAg IHRocm91Z2ggYSBkaXNydXB0aW9uIG9mIHRoZSBjb250cm9sIHBsYW5lKS48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgQXV0aGVudGljYXRpb24gUHJlc2VudCAoQSk8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBBdXRoZW50aWNhdGlvbiBQcmVzZW50 IChBKTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9 ImRpZmYwMDMwIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgIFNldCB0byAxIGlmIGF1dGhlbnRpY2F0aW9u IGlzIGluIHVzZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5vPC9zcGFuPm4gdGhpcyBzZXNzaW9uPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgIFNldCB0byAxIGlmIGF1dGhl bnRpY2F0aW9uIGlzIGluIHVzZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5pPC9zcGFuPm4gdGhpcyBz ZXNzaW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAoYmZkLkF1dGhUeXBl IGlzIG5vbnplcm8pLCBvciAwIGlmIG5vdC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICAgICAoYmZkLkF1dGhUeXBlIGlzIG5vbnplcm8pLCBvciAwIGlmIG5vdC48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgRGVtYW5kIChEKTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIERlbWFuZCAoRCk8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICAgU2V0IHRvIGJmZC5EZW1hbmRNb2RlIGlmIGJmZC5TZXNzaW9u U3RhdGUgaXMgVXAgYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAg U2V0IHRvIGJmZC5EZW1hbmRNb2RlIGlmIGJmZC5TZXNzaW9uU3RhdGUgaXMgVXAgYW5kPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICBiZmQuUmVtb3RlU2Vzc2lvblN0YXRlIGlz IFVwLiAgU2V0IHRvIDEgaWYgYmZkLlNlc3Npb25UeXBlIGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgICAgYmZkLlJlbW90ZVNlc3Npb25TdGF0ZSBpcyBVcC4gIFNldCB0 byAxIGlmIGJmZC5TZXNzaW9uVHlwZSBpczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgICAgTXVsdGlwb2ludEhlYWQuICBPdGhlcndpc2UgaXQgaXMgc2V0IHRvIDAuPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgTXVsdGlwb2ludEhlYWQuICBPdGhlcndp c2UgaXQgaXMgc2V0IHRvIDAuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg IE11bHRpcG9pbnQgKE0pPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgTXVs dGlwb2ludCAoTSk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyIGlkPSJkaWZmMDAzMSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICBTZXQgdG8gMSBpZiBiZmQuU2Vz c2lvblR5cGUgaXMgTXVsdGlwb2ludEhlYWQuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5PdGhlcndp c2U8L3NwYW4+IGl0IGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAg IFNldCB0byAxIGlmIGJmZC5TZXNzaW9uVHlwZSBpcyBNdWx0aXBvaW50SGVhZC4gIDxzcGFuIGNs YXNzPSJpbnNlcnQiPk90aGVyd2lzZSw8L3NwYW4+IGl0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgICAgICAgIHNldCB0byAwLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICAgICAgICBpcyBzZXQgdG8gMC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgRGV0ZWN0IE11bHQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBE ZXRlY3QgTXVsdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICBTZXQg dG8gYmZkLkRldGVjdE11bHQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg ICAgU2V0IHRvIGJmZC5EZXRlY3RNdWx0LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICBMZW5ndGg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBMZW5n dGg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgU2V0IHRvIHRoZSBh cHByb3ByaWF0ZSBsZW5ndGgsIGJhc2VkIG9uIHRoZSBmaXhlZCBoZWFkZXIgbGVuZ3RoPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgU2V0IHRvIHRoZSBhcHByb3ByaWF0 ZSBsZW5ndGgsIGJhc2VkIG9uIHRoZSBmaXhlZCBoZWFkZXIgbGVuZ3RoPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICAgICAoMjQpIHBsdXMgYW55IEF1dGhlbnRpY2F0aW9uIFNlY3Rp b24uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgKDI0KSBwbHVzIGFu eSBBdXRoZW50aWNhdGlvbiBTZWN0aW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC0xMSIgY2xhc3M9ImNoYW5nZSI+PHRkPjwv dGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmYvcmZjZGlmZi5weWh0I3BhcnQtMTEiPjxlbT4gcGFnZSAx NiwgbGluZSAzNTxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+ IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmYvcmZjZGlmZi5weWh0I3BhcnQtMTEiPjxlbT4gcGFn ZSAxNiwgbGluZSAzNTxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48 dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgIFJlcXVpcmVkIE1pbiBFY2hvIFJYIEludGVydmFsPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgUmVxdWlyZWQgTWluIEVjaG8gUlggSW50ZXJ2 YWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgU2V0IHRvIDAgaWYg YmZkLlNlc3Npb25UeXBlIGlzIE11bHRpcG9pbnRIZWFkIG9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgICAgU2V0IHRvIDAgaWYgYmZkLlNlc3Npb25UeXBlIGlzIE11bHRp cG9pbnRIZWFkIG9yPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICBNdWx0aXBv aW50VGFpbC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICBNdWx0aXBv aW50VGFpbC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgQXV0aGVudGlj YXRpb24gU2VjdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIEF1dGhl bnRpY2F0aW9uIFNlY3Rpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg ICAgSW5jbHVkZWQgYW5kIHNldCBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVzIGluIFtSRkM1ODgwXSBz ZWN0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgSW5jbHVkZWQg YW5kIHNldCBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVzIGluIFtSRkM1ODgwXSBzZWN0aW9uPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICA2LjcgaWYgYXV0aGVudGljYXRpb24gaXMg aW4gdXNlIChiZmQuQXV0aFR5cGUgaXMgbm9uemVybykuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgICAgNi43IGlmIGF1dGhlbnRpY2F0aW9uIGlzIGluIHVzZSAoYmZkLkF1 dGhUeXBlIGlzIG5vbnplcm8pLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyIGlkPSJkaWZmMDAzMiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICBPdGhlcndpc2UgdGhpcyBz ZWN0aW9uIGlzIG5vdCBwcmVzZW50LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICAgICAgICBPdGhlcndpc2U8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4sPC9zcGFuPiB0aGlzIHNlY3Rp b24gaXMgbm90IHByZXNlbnQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjUuICBB c3N1bXB0aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjUuICBBc3N1bXB0aW9u czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJZiBhdXRoZW50aWNhdGlvbiBp cyBpbiB1c2UsIGFsbCB0YWlscyBtdXN0IGJlIGNvbmZpZ3VyZWQgdG8gaGF2ZSBhPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSWYgYXV0aGVudGljYXRpb24gaXMgaW4gdXNlLCBh bGwgdGFpbHMgbXVzdCBiZSBjb25maWd1cmVkIHRvIGhhdmUgYTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgY29tbW9uIGF1dGhlbnRpY2F0aW9uIGtleSBpbiBvcmRlciB0byByZWNlaXZl IHRoZSBtdWx0aXBvaW50IEJGRDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNv bW1vbiBhdXRoZW50aWNhdGlvbiBrZXkgaW4gb3JkZXIgdG8gcmVjZWl2ZSB0aGUgbXVsdGlwb2lu dCBCRkQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENvbnRyb2wgcGFja2V0cy48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDb250cm9sIHBhY2tldHMuPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjYuICBJQU5BIENvbnNpZGVyYXRpb25zPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Ni4gIElBTkEgQ29uc2lkZXJhdGlvbnM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBoYXMgbm8gYWN0aW9ucyBm b3IgSUFOQS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50 IGhhcyBubyBhY3Rpb25zIGZvciBJQU5BLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij43LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij43LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgVGhlIHNhbWUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYXMgdGhvc2UgZGVz Y3JpYmVkIGluIFtSRkM1ODgwXTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRo ZSBzYW1lIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFzIHRob3NlIGRlc2NyaWJlZCBpbiBbUkZD NTg4MF08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFwcGx5IHRvIHRoaXMgZG9jdW1l bnQuICBBZGRpdGlvbmFsbHksIGltcGxlbWVudGF0aW9ucyB0aGF0IGNyZWF0ZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFwcGx5IHRvIHRoaXMgZG9jdW1lbnQuICBBZGRpdGlv bmFsbHksIGltcGxlbWVudGF0aW9ucyB0aGF0IGNyZWF0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgTXVsdHBvaW50VGFpbCBzZXNzaW9ucyBkeW5hbWljYWxseSB1cG9uIHJlY2VpcHQg b2YgTXVsdGlwb2ludCBCRkQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBNdWx0 cG9pbnRUYWlsIHNlc3Npb25zIGR5bmFtaWNhbGx5IHVwb24gcmVjZWlwdCBvZiBNdWx0aXBvaW50 IEJGRDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZm MDAzMyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICBDb250cm9sIHBhY2tldHMgTVVTVCBpbXBsZW1lbnQgcHJvdGVj dGl2ZSBtZWFzdXJlcyB0byBwcmV2ZW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIENvbnRyb2wgcGFja2V0cyBNVVNUIGltcGxlbWVudCBwcm90ZWN0aXZlIG1lYXN1cmVzIHRv IHByZXZlbnQ8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gYW48L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBpbmZpbml0ZSBudW1iZXIgb2YgTXVsdGlwb2ludFRhaWwgc2Vzc2lvbnMg YmVpbmcgY3JlYXRlZC4gIEJlbG93IGFyZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGluZmluaXRlIG51bWJlciBvZiBNdWx0aXBvaW50VGFpbCBzZXNzaW9ucyBiZWluZyBjcmVh dGVkLiAgQmVsb3cgYXJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBsaXN0ZWQgc29t ZSBwb2ludHMgdG8gYmUgY29uc2lkZXJlZCBpbiBzdWNoIGltcGxlbWVudGF0aW9ucy48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBsaXN0ZWQgc29tZSBwb2ludHMgdG8gYmUgY29u c2lkZXJlZCBpbiBzdWNoIGltcGxlbWVudGF0aW9ucy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgICAgSWYgYSBNdWx0aXBvaW50IEJGRCBDb250cm9sIHBhY2tldCBkaWQgbm90 IGFycml2ZSBvbiBhIG11bHRpY2FzdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICAgIElmIGEgTXVsdGlwb2ludCBCRkQgQ29udHJvbCBwYWNrZXQgZGlkIG5vdCBhcnJpdmUgb24g YSBtdWx0aWNhc3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBp ZD0iZGlmZjAwMzQiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgdHJlZSAoZS5nLiBvbiBleHBlY3RlZCBpbnRl cmZhY2UsIHdpdGggZXhwZWN0ZWQgTVBMUyBsYWJlbCwgZXRjKSw8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgICAgdHJlZSAoZS5nLiBvbiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij50 aGU8L3NwYW4+IGV4cGVjdGVkIGludGVyZmFjZSwgd2l0aCBleHBlY3RlZCBNUExTIGxhYmVsLDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICB0aGVuIGEgTXVsdGlwb2ludFRhaWwg c2Vzc2lvbiBzaG91bGQgbm90IGJlIGNyZWF0ZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgICAgIGV0YyksIHRoZW4gYSBNdWx0aXBvaW50VGFpbCBzZXNzaW9uIHNob3VsZCBu b3QgYmUgY3JlYXRlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgSWYg cmVkdW5kYW50IHN0cmVhbXMgYXJlIGV4cGVjdGVkIGZvciBhIGdpdmVuIG11bHRpY2FzdCBzdHJl YW0sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgSWYgcmVkdW5kYW50IHN0 cmVhbXMgYXJlIGV4cGVjdGVkIGZvciBhIGdpdmVuIG11bHRpY2FzdCBzdHJlYW0sPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB0aGVuIHRoZSBpbXBsZW1lbnRhdGlvbnMgc2hvdWxk IG5vdCBjcmVhdGUgbW9yZSBNdWx0aXBvaW50VGFpbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgIHRoZW4gdGhlIGltcGxlbWVudGF0aW9ucyBzaG91bGQgbm90IGNyZWF0ZSBt b3JlIE11bHRpcG9pbnRUYWlsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBzZXNz aW9ucyB0aGFuIHRoZSBudW1iZXIgb2Ygc3RyZWFtcy4gIEFkZGl0aW9uYWxseSwgd2hlbiB0aGU8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBzZXNzaW9ucyB0aGFuIHRoZSBu dW1iZXIgb2Ygc3RyZWFtcy4gIEFkZGl0aW9uYWxseSwgd2hlbiB0aGU8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgIG51bWJlciBvZiBNdWx0aXBvaW50VGFpbCBzZXNzaW9ucyBleGNl ZWRzIHRoZSBudW1iZXIgb2YgZXhwZWN0ZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICBudW1iZXIgb2YgTXVsdGlwb2ludFRhaWwgc2Vzc2lvbnMgZXhjZWVkcyB0aGUgbnVt YmVyIG9mIGV4cGVjdGVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBzdHJlYW1z LCB0aGVuIHRoZSBpbXBsZW1lbnRhdGlvbiBzaG91bGQgZ2VuZXJhdGUgYW4gYWxhcm0gdG8gdXNl cnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBzdHJlYW1zLCB0aGVuIHRo ZSBpbXBsZW1lbnRhdGlvbiBzaG91bGQgZ2VuZXJhdGUgYW4gYWxhcm0gdG8gdXNlcnM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHRvIGluZGljYXRlIHRoZSBhbm9tYWx5LjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIHRvIGluZGljYXRlIHRoZSBhbm9tYWx5 LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBUaGUgaW1wbGVtZW50YXRp b24gc2hvdWxkIGhhdmUgYSByZWFzb25hYmxlIHVwcGVyIGJvdW5kIG9uIHRoZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIFRoZSBpbXBsZW1lbnRhdGlvbiBzaG91bGQgaGF2 ZSBhIHJlYXNvbmFibGUgdXBwZXIgYm91bmQgb24gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgICBudW1iZXIgb2YgTXVsdGlwb2ludFRhaWwgc2Vzc2lvbnMgdGhhdCBjYW4gYmUg Y3JlYXRlZCwgd2l0aCB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBu dW1iZXIgb2YgTXVsdGlwb2ludFRhaWwgc2Vzc2lvbnMgdGhhdCBjYW4gYmUgY3JlYXRlZCwgd2l0 aCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHVwcGVyIGJvdW5kIHBvdGVu dGlhbGx5IGJlaW5nIGNvbXB1dGVkIGJhc2VkIG9uIHRoZSBudW1iZXIgb2Y8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICB1cHBlciBib3VuZCBwb3RlbnRpYWxseSBiZWluZyBj b21wdXRlZCBiYXNlZCBvbiB0aGUgbnVtYmVyIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICBtdWx0aWNhc3Qgc3RyZWFtcyB0aGF0IHRoZSBzeXN0ZW0gaXMgZXhwZWN0aW5nLjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIG11bHRpY2FzdCBzdHJlYW1zIHRo YXQgdGhlIHN5c3RlbSBpcyBleHBlY3RpbmcuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjguICBDb250cmlidXRvcnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij44LiAg Q29udHJpYnV0b3JzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFJhaHVsIEFn Z2Fyd2FsIG9mIEp1bmlwZXIgTmV0d29ya3MgYW5kIEdlb3JnZSBTd2FsbG93IG9mIENpc2NvPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUmFodWwgQWdnYXJ3YWwgb2YgSnVuaXBl ciBOZXR3b3JrcyBhbmQgR2VvcmdlIFN3YWxsb3cgb2YgQ2lzY288L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIFN5c3RlbXMgcHJvdmlkZWQgdGhlIGluaXRpYWwgaWRlYSBmb3IgdGhpcyBz cGVjaWZpY2F0aW9uIGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFN5c3Rl bXMgcHJvdmlkZWQgdGhlIGluaXRpYWwgaWRlYSBmb3IgdGhpcyBzcGVjaWZpY2F0aW9uIGFuZDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29udHJpYnV0ZWQgdG8gaXRzIGRldmVsb3Bt ZW50LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvbnRyaWJ1dGVkIHRvIGl0 cyBkZXZlbG9wbWVudC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyIGlkPSJkaWZmMDAzNSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj45LiAgQWNrbm93bGVkZzxzcGFuIGNsYXNz PSJkZWxldGUiPmU8L3NwYW4+bWVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ OS4gIEFja25vd2xlZGdtZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBB dXRob3JzIHdvdWxkIGFsc28gbGlrZSB0byB0aGFuayBOb2JvIEFraXlhLCBWZW5nYWRhIFByYXNh ZCBHb3ZpbmRhbiw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBdXRob3JzIHdv dWxkIGFsc28gbGlrZSB0byB0aGFuayBOb2JvIEFraXlhLCBWZW5nYWRhIFByYXNhZCBHb3ZpbmRh biw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEplZmYgSGFhcywgV2ltIEhlbmRlcmlj a3gsIEdyZWdvcnkgTWlyc2t5IGFuZCBNaW5ndWkgWmhhbmcgd2hvIGhhdmU8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBKZWZmIEhhYXMsIFdpbSBIZW5kZXJpY2t4LCBHcmVnb3J5 IE1pcnNreSBhbmQgTWluZ3VpIFpoYW5nIHdobyBoYXZlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBncmVhdGx5IGNvbnRyaWJ1dGVkIHRvIHRoaXMgZG9jdW1lbnQuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZ3JlYXRseSBjb250cmlidXRlZCB0byB0aGlzIGRvY3Vt ZW50LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4xMC4gIE5vcm1hdGl2ZSBSZWZl cmVuY2VzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+MTAuICBOb3JtYXRpdmUgUmVm ZXJlbmNlczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbUkZDMjExOV0gIEJy YWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkg d29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTks PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBSZXF1aXJlbWVu dCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDMjExOSwgTWFyY2ggMTk5Nyw8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkMyMTE5 LCBNYXJjaCAxOTk3LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KCiAgICAgPHRy Pjx0ZD48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQ+PC90ZD48L3RyPgogICAgIDx0ciBpZD0iZW5kIiBiZ2NvbG9yPSJncmF5Ij48 dGggY29sc3Bhbj0iNSIgYWxpZ249ImNlbnRlciI+Jm5ic3A7RW5kIG9mIGNoYW5nZXMuIDM1IGNo YW5nZSBibG9ja3MuJm5ic3A7PC90aD48L3RyPgogICAgIDx0ciBjbGFzcz0ic3RhdHMiPjx0ZD48 L3RkPjx0aD48aT41NSBsaW5lcyBjaGFuZ2VkIG9yIGRlbGV0ZWQ8L2k+PC90aD48dGg+PGk+IDwv aT48L3RoPjx0aD48aT41NiBsaW5lcyBjaGFuZ2VkIG9yIGFkZGVkPC9pPjwvdGg+PHRkPjwvdGQ+ PC90cj4KICAgICA8dHI+PHRkIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiIGNsYXNzPSJzbWFs bCI+PGJyPlRoaXMgaHRtbCBkaWZmIHdhcyBwcm9kdWNlZCBieSByZmNkaWZmIDEuNDYuIFRoZSBs YXRlc3QgdmVyc2lvbiBpcyBhdmFpbGFibGUgZnJvbSA8YSBocmVmPSJodHRwczovL3d3dy50b29s cy5pZXRmLm9yZy90b29scy9yZmNkaWZmLyI+aHR0cDovL3Rvb2xzLmlldGYub3JnL3Rvb2xzL3Jm Y2RpZmYvPC9hPiA8L3RkPjwvdHI+CiAgIDwvdGJvZHk+PC90YWJsZT4KICAgCiAgIAo8L2JvZHk+ PC9odG1sPg== --0000000000007b526e056a0fab7a-- From nobody Tue Apr 17 12:32:10 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 C1A8912420B; Tue, 17 Apr 2018 12:32:08 -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_HIGH=-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=nokia.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 dOjStud2xhbX; Tue, 17 Apr 2018 12:32:05 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on070f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::70f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E709F1241F5; Tue, 17 Apr 2018 12:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=45FfOh7ZWOwFnR3+YZDD6mKpeNYRbC5kOo9UUWID2OM=; b=ZJa8GaXABInK4SBoxudYnm7Suaw0v1vRo0VPfmea1CUCsyiVCNTuEdD9ZmfX094XdSUxmjcefIuCBN+HbtV9oHHbxx1D24hJCu6C8wOqyBXaaVm+sBsmtyOAd1wnDoyDm+t3GAly5Azompmk5DPFhLAl3xExFcnvPpey8Uu95Gc= Received: from [IPv6:2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65] (2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65) by AM4PR0701MB2131.eurprd07.prod.outlook.com (2603:10a6:200:49::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.8; Tue, 17 Apr 2018 19:32:02 +0000 Subject: Re: AD review of draft-ietf-bfd-multipoint-14 To: Greg Mirsky Cc: draft-ietf-bfd-multipoint@ietf.org, "Reshad Rahman (rrahman)" , bfd-chairs@ietf.org, rtg-bfd@ietf.org References: From: Martin Vigoureux Message-ID: Date: Tue, 17 Apr 2018 21:31:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit X-Originating-IP: [2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65] X-ClientProxiedBy: DB6PR0802CA0044.eurprd08.prod.outlook.com (2603:10a6:4:a3::30) To AM4PR0701MB2131.eurprd07.prod.outlook.com (2603:10a6:200:49::12) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:AM4PR0701MB2131; X-Microsoft-Exchange-Diagnostics: 1; AM4PR0701MB2131; 3:7DQDKqV8QpJCaKQKR9v7+JfGSR7iqdHnTrczPQ8lHpciMQvXxz2ueb6V9inhHayTDC5e75aznyUMJ7iNmey691/Nk0QEziQSM1wq4uYGBypBYGoKDj9BjFkUUGwHJ3nTokoBl2KPTaczqDDRts4bdlYqMyuR0cc1KA1Ij5O7SdJPpN/CE3zkL08fKbfNHu7lOtKqOuwMUzQ5im7zi5T+9fS42yGGn2kAAYky1n3tblYmRhT0xQgvL4H638+TEyBD; 25:nvw8nBNpNVxrfty9nrs2O76hrTGUp++Ee191bzoeU5bkBAp5hxh2YU53G3oUlmqUzun7ArW4vEYZR8/z7JyW15/j+qEyMM5m3GKa+0zjpMj5JHZgr7I3kpG9EJKAiolTKf1Z2MPzAJwBi6HSELBuSk5XevyydA7fDfVmCDQkXCjDpdwaUgFfvRSH8qFMEZy9V4orHUYv2e3oxjYOFb41l+TQSy+7EtjVJt/rDSAH4LvSsZJwd48bDZYuIvCf+9K13osVpk1nbwfVkcM63MNmWp3ANpnxYmih+Xi3DnzvXrUyPS0GT85ResZm0QyQ+qG8TwkVJ3s7BCnQjggGGxAivg==; 31:IUK5zhCEgvLIguYWp6d0PKFyz4mZzzgWXh5gccde+yVM4WwaqXUKSSiZ0XhgfMnmIzZOkZ4qufFkZZHlNBI9MU2VyNR0XNh0DyljXEYDbHbh4QZENfEDOxcXPCyRD5WGP41xbdlpq1BlfSs/bYi3iSxKFIqWGpolOGSAMjVqVWqXCskSWkplDF3b9+ZqDmemMnpCpnF/bslFY9vwUgNT2zPiqyVgpDfYen/b3D+2TPM= X-MS-TrafficTypeDiagnostic: AM4PR0701MB2131: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com; X-Microsoft-Exchange-Diagnostics: 1; AM4PR0701MB2131; 20:ySjfRtdgwFEwLNzxhVKsQGs/Uy4am3NXn3BQLwucK9B0pp/87DnhH8nh8bNfO6S5t3f2AaZROUmEZbPWohUhZaR0v9WtSF9jd4zlfqlQhb1QCXJQ/PeBD84EGMgpEZR8s4rg4G9n5pay5hlhUA6YD0uIwWfO1IKaf9kwnLoLnn6hFSNIvE9eekVPaVYrtkr/RooyfPS0bNLfPrTqaaQsT6lnwaU4YDPNzh2QUyelZKshLqY7nUteyd8EFseyBMWp6LnuFlyJelaY7slOj2yXNcIwqMNJCLI8Cs5WFMvv6pu4ODUbc0TfHwYc0H0fKooEeLnXxyKY4Mv/oCflGOEiS861jQ/WipKfbjs7j8ynSU5k++2fNa2Uc500DMVUbW/Qeq7dIC3eIVNxlS1zTrC5TMsLgKkuvvW3yMEOYIDxKM4s5weoiykI0Jee8x5zscq0Ud3+ovq3wdgQkc+I0WO1JbSXhQU6ATc84XZuUOXcG45uOLZqvX07Xg8rGXmBIh9k; 4:wYsYWyxAHQIsjbA3+6xTb/0EJDBOaA90g4jmhhH6I6EAr3Zfpp0w+OpFBZ5ACcWLfS7J6W2hIppNSj0eObtj73qbzPkL00/pGoWk5ky2+dhkDXvScXv3EpoXvdjAk9s08TKlW8F4XDFVbZZkZTQfpI3snsHnmHqYdHkIvIA3K/T/QOPYmeax9g575MBM7zn5Mt0SPAJMDO6JfDPWjoM5Nv46aOuAlXuJo1qc9mzjeaJXOL/HJxz2O47NkZP5iDbXo9RbSYf6ydgOw/VVbpaOE0YHwZlHpRB5XuUXv3iorF6yCIfHmVx9THRDPcSru4hh X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(82608151540597); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231232)(11241501184)(806099)(944501361)(52105095)(10201501046)(93006095)(93001095)(6055026)(6041310)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM4PR0701MB2131; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0701MB2131; X-Forefront-PRVS: 0645BEB7AA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(39860400002)(366004)(39380400002)(54094003)(189003)(199004)(51444003)(377424004)(316002)(93886005)(64126003)(486006)(39060400002)(446003)(561944003)(58126008)(86362001)(53936002)(68736007)(6666003)(31696002)(6246003)(50466002)(3260700006)(2870700001)(476003)(2906002)(36756003)(6306002)(2616005)(25786009)(5890100001)(1706002)(11346002)(44832011)(1411001)(8676002)(81156014)(76176011)(5660300001)(305945005)(47776003)(52116002)(2486003)(52146003)(81166006)(23676004)(65806001)(65956001)(52396003)(105586002)(67846002)(6486002)(106356001)(186003)(345774005)(6116002)(16526019)(4326008)(6916009)(8936002)(46003)(65826007)(229853002)(478600001)(966005)(7736002)(59450400001)(31686004)(16799955002)(97736004)(386003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR0701MB2131; H:[IPv6:2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTRQUjA3MDFNQjIxMzE7MjM6RXZNVEZGUUVPUmppL3RoRU5ZN3BjWXN5?= =?utf-8?B?WmxuVDhDU3RHMHhtN2owR3UxTk4vT1pKT0RWOXlNZmlZY3FOaGFLZWRaRFB2?= =?utf-8?B?MktqVC9zeXJPSk5xQTBoSnFodFhqbitIbm1YQ2pmdXNWbGcvdGVXN2FUSWQ2?= =?utf-8?B?NE1qRStubUk4NENKRDVkVE1PVkFqa3JNeGxEOTd6eTdPclJaU3E3R2dCaGVM?= =?utf-8?B?YXJQSFlBTU5IbkFzL1hTcXBrRmtsc2d5UTlKY3BnNjBOa3hBdDhvcUNJa01G?= =?utf-8?B?T0J4dWx0WHpNREVqY1JscEpDQ3I1SVlSaGJNNi8rNXNibC9KKzIxV0h0TGhY?= =?utf-8?B?WXNWaWVLRi9vYjRPWlRuMmozK0lNbitpRzlobHp6V29XTnFlM3YvQXF1bnRi?= =?utf-8?B?d2UzOVlncmhnKzd3Y0VSRkZEYlp2Wm1MUTEvRitEc3hGa3ZpYUNrUlNjaXNF?= =?utf-8?B?ZGcvVXBLWDFETC9ZOHlYQmVtRDh4Q3NFTVNndTFLZWZQWHAzV2RScktXdkhz?= =?utf-8?B?dGI5ekxuczljdU5TVTErc21zWUxWSDVtdXg1QUpxdHBpdXJIUGlxSGFWNC9a?= =?utf-8?B?cnFkcFpTZkxTUnp6TkxGcHJlWk9JR3BZMnQyOGJkamx2NWk1Qlpvc0IvTXB5?= =?utf-8?B?ZWlnWjBPeFk1UWwwY2xPd3JPRmFiOVk3WHU1TDhuN0N4WVVrY2pnVFlBTWt4?= =?utf-8?B?WTBHVnViY3lTSnRtYU9oZUZ3SThrcE5IUWZKY0J2TXFFcnkrTEV4SHFuUGEr?= =?utf-8?B?eHdnWVJ1QVRZK014ajJQbHNjZFZBZGpZT0k4K1NhQjhaVVVlU09KeTZoTURh?= =?utf-8?B?OTJEdDl5Y0lxZmE5aExWUjg5dkJyTDBlM3dBRkFFSklZZlBGVnNHbGV1cGVK?= =?utf-8?B?N2xKMVdISkJ6NVVTK3lIc1dXZGQ3eUIzUmx4bmllT3VrQWx5VVE4eVd6WmpM?= =?utf-8?B?Umtrd1hFcnFpSmJsckdlZjdOWXgwTFZ2a2tHdDM1eGNtVk80YmMxVnFDYWFZ?= =?utf-8?B?b1RRQmxXU3QvcmQrd1NlLzl1am4zTUdUaDJ4Q3RKRmZKdHdlSHlHRWFLczFW?= =?utf-8?B?TmhFdzVoVTZybmhYUnhTTHUxNXdBbGJITFRpRWR4YXA4VVYrdUJ1Q0ZZY3h6?= =?utf-8?B?UVlCL0czeXBwVjdzSEg5ZjhsMDEzcHA4QlBpSDZSaGhvT2trbVpzRkhZc0Iw?= =?utf-8?B?ZjRaaTlMbkU3M0VQd2pwR2tBQ09kc3JBMmw3V3gwQjFCVmVZL0xiTG4zSVhK?= =?utf-8?B?eEhMVkFCQVd3d3RJNkxCWmp4LzlFMnkzN0ZvSTBhSlU4L1Z2OWtNajcxNDBt?= =?utf-8?B?TThqK1RKZkNIWm5ydTRYclRCdkI0c1NpUkFxSnBGeW9BbG1sdDZzbGc2cmxO?= =?utf-8?B?ZVpTVU1lK1BlWVVWQzNFV1dZbjZrOWxjRzErKzVzVVNIY3hUSlZQYlpFejJJ?= =?utf-8?B?WDh0TkszWitnVjRHSmZadVIyb203L1AxWkFFSkszc3hBNVVacSs0cmpDMitx?= =?utf-8?B?YjBjaDhzWno3K0xIWXdQbmYzS2F5UEMvTHdQK1VIeUJRKzIzVjViZDd5SGhQ?= =?utf-8?B?cHVhZmVYR3VpL2ZSWUNsSnFlODVWT2tpNXBubW8rK1pMSXlkbTM1dFBSb3Bn?= =?utf-8?B?Zkk3SkJ2aW1IRUFKVm1GOVV6S2RTak9SYyt6UWd3WE0rMVFoampqNE9XdDhp?= =?utf-8?B?NFR2WVl3YVNWbUZyV1RrYTJaTXE0STRTTmdHc3RPUXFLMWtwTGdLK3pBUFox?= =?utf-8?B?cERQSzZIdE1lNE9CcmdQS01nQkpxdW1La3RtTzloakQ5SWc2bWF2eVZmZFlV?= =?utf-8?B?NmZpRTllTWpWRFRqMjhPOXZKMkowMmVhVTk1TVhoOWJmYjM0VzI3b21EbG5r?= =?utf-8?B?UVZsdVIwMXJ5QUZ2c3lFclhYaGNqNGNQRWtoc09pc0I2TGJnSTluVjFZYVJ1?= =?utf-8?B?M1VxSnRMVkRYL0pVdmFJaWgzb05rUmNOZy9aN0lBckhNckR5VXBLcmtXRUxJ?= =?utf-8?B?NTJWUzRRMTZPQ0phN3ZBVFR0TWFqakVDY3RGVTBqY2o4NlFocWl3SG00clY1?= =?utf-8?B?U2JPcVkyYkgwS0h5ekw3THpxeVp4UCtMa0xSYUxReCtPMUY1TVQvWWJ3YnBR?= =?utf-8?B?ZnBZcHpMMGUwSGRweHJLNmpINXJYTzR6dmNGdHp0R3FrNldOMnU0RUtKR25s?= =?utf-8?B?dHd4SW1DVkxoKzRNYmZNb1BnUTJUeURvKy9BU2dvL0JNaVRVaW5FVENtZFQ4?= =?utf-8?B?djN1c3RMeDRwWldUMDB4SHRMUU9ybis2aDIyU0VycGFCR09hNDFVOVJBPT0=?= X-Microsoft-Antispam-Message-Info: 1q34aMD2ZakjtZipYAkyDruFbyCWTgzIBCWl3IgNSqqa62LjNzjZQBtMKgI50aFiCkeyR0R+ZNPt3We52pw5ZbvRLj9cVKUqdCs4PBtMLW29nMpsPcbwV+S/WaJpXmec/pxFyk8PDN/ILHTMIQFoY4Dy2hL8l5PrKsywlJlZvDFCW8CmiWWhoJHw7g61KV/Xvnuefnc3cbYil5aCULlJ/ppFIHiyTXl//yChoOlu9av7p/+7Z5ZMgbzooRTHbGv5 X-Microsoft-Exchange-Diagnostics: 1; AM4PR0701MB2131; 6:R7jf8NsUUxENgepvBNbkpowi8PJBO3x50wmjhndj/UOxUUt02dwf28M6oWGFfujh8xxpe+ucUSIaanVd/ZGPBv3NS8jlUc7lm0Ee3kWSSMBE1WH4Yg4/jAn+eja+pdA/4d0XsKWcO1JGWyqxlUme8FIXkRnP0ZVsny+6HUcsFP8IY6qsBF7iBTVrzL4M2hb7ODGHPvgwQkRk+NPIfRl/nKx2eRtafGSbg/inJ8hjMIu/CL4RnGNa/5AR8FONrZadUQw1/eajt/BdzzJhsI7/YmbwdLETxmpGokxKl3GwmIkeYInjXjqQKx/bAIyAInlTh3zhgI8NWdPfpX3lozHtwDX7rPD/nX/d5Nva1NUVb0KdtoV7r2tfYoTYTZzJfGJ+tgNyDFzGGFECjRlizddft9ZA2X00fGEnpjtCcrS+5u8n09UYrsnkozPVCSIj03gGytdqFY3MmWbFlPwKrcYK/Q==; 5:fCArsbIbts0pLRq8dC9OmTpHvXml2lJX/kU7ydnqjqM5oX6RraPhfp/16mc3Q8phij+TqhpiyRyUPZnm9+d+SwVHRGGNb1iyf8pYht2/64HBdoxUrzqROyzVB+uzqcdr4KT8OD4THYRerbWweOQbrUX85TWvX3atg/rEDDUj69w=; 24:24X/cfHgejkI7+K/X0iHqTYZAc1/r2Wo8RdOU7BFVP71nQMj1GsOxI3xI4MnDzCViZYTWjeR1+G5LkMuSaYrPoSAdYoz7YdRafZsQRXTUvg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM4PR0701MB2131; 7:AWgqAxgxo+EJDhfCewgd33RLU4n+uXJimkhJY1MPio3d8UYEioI8NBPttiL5mTcWJCRAU4ZCNjWCqSnLn8lN4jcDovJEWzkIaOWqjmYr478/FCSPNOIKubwGdF5zRTQhRpGQTOJRnKJ4iZXvIAKUt2LVr+SUOtXK6Bf51gck23syQfEgJPbp+fvxUKOVIln/IfB8I/N3LlVpVihmxhRbctT/310Krp9Fuz+5CK52RzWQdgxPIxBTr6kGkhmd1cZE X-MS-Office365-Filtering-Correlation-Id: 177d560f-c941-487a-9069-08d5a499e521 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2018 19:32:02.0489 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 177d560f-c941-487a-9069-08d5a499e521 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0701MB2131 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: Tue, 17 Apr 2018 19:32:09 -0000 Greg, I'm fine your proposal below. Please post the final update whenever you can. Thx -m Le 2018-04-17 à 20:40, Greg Mirsky a écrit : > Hi Martin, > I have not ignored that comment but missed to ack its acceptance. Two > other outstanding questions: > > * the text, that I've misinterpreted earlier, is in the Overview section: > >         Although this document describes a single head and a > set of tails >         spanned by a single multipoint path, the protocol is > capable of >         supporting (and discriminating between) more than one > multipoint >     path >         at both heads and tails. >     There is no text to describe how one could achieve that. > Wouldn't it >     be worth adding some? > > GIM>> The question of applicability of this specification to > mp2mp scenario came up at BIER WG meeting in London. Perhaps we > can say the these questions are ouside the scope of this > document and discuss whether there are interested to work on > mp2mp case as a separete document? > > I don't read this part of the document as talking about mp2mp but > rather as talking about multiple p2mp trees. > > Sections 4.7 and 4.13.2 provides details on demultiplexing BFD > control packets at a MultipointTail. Would the reference to these > sections be sufficient? > > * yes, moved the reference to Point-to-Point session to section 4.4.1 > > Attached please find the diff between -14 and the working version of the > draft. Please let me know if the changes address your comments. Will > upload the new version promptly. > > Regards, > Greg > > On Tue, Apr 17, 2018 at 9:49 AM, Martin Vigoureux > > wrote: > > Greg, > > thanks. please see in-line. > > once I see the update published I will request IETF LC. > > -m > > Le 2018-04-17 à 18:34, Greg Mirsky a écrit : > > Hi Martin, > thank you for your thorough review, thoughtful comments and kind > words. > Please find my answers to your questions in-line and tagged GIM>>. > > Regards, > Greg > > On Tue, Apr 17, 2018 at 8:06 AM, Martin Vigoureux > > >> wrote: > >     [resend, wrong bfd wg address in first attempt ...] > >     Authors, WG, > >     thank you for this document. It is clear and well written. >     I didn't find any technical comment to make so I've been > nit picking :-) >     Please find those comments below. > >     regards, >     martin > >     --- >     Please check and address the nits: > https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-bfd-multipoint-14.txt > > > > > >     On that aspect, does this document really update 7880 as > the header >     says? The Introduction only refers to 5880 and it is not > clear in >     the body of the Document what effectively impacts 7880. The > only >     thing I saw is the addition of new session types but that > does not >     require an update in my opinion. Could you clarify? >     GIM>> Yes, you'correct, the only connection to RFC 7880 are > the new >     values of bfd.sessionType. The proposal to list RFC 7880 as > updated >     by this specification was inteded to address Errata to RFC 7880 >     >. > > I am not sure how this document relates to or addresses the errata. > So I still think it does not update 7880. > > >         i.e. existence of a path between the sender and the > receiver. >     do you mean "forwarding path"? >     GIM>> Yes. Updated to > >     i.e. existence of a forwarding path between the sender and > the receiver > > thx > > >     Section 2. and Section 3. seem a bit redundant. They both > state the >     same thing but from a different angle. Not critical. > > >         Although this document describes a single head and a > set of tails >         spanned by a single multipoint path, the protocol is > capable of >         supporting (and discriminating between) more than one > multipoint >     path >         at both heads and tails. >     There is no text to describe how one could achieve that. > Wouldn't it >     be worth adding some? > > GIM>> The question of applicability of this specification to > mp2mp scenario came up at BIER WG meeting in London. Perhaps we > can say the these questions are ouside the scope of this > document and discuss whether there are interested to work on > mp2mp case as a separete document? > > I don't read this part of the document as talking about mp2mp but > rather as talking about multiple p2mp trees. > > > > >         Point-to-point sessions, as described in [RFC5880], are > of type >         PointToPoint. >     Does this really fit in Section 4.2 which looks to be about the >     mpBFD session model. > > GIM>> I think that this short reminder is helpful to explain why > this document adds value PointToPoint, section 4.4.1, to the > defined in RFC 7880 bfd.sessionType variable. > > Well, I would move the text to 4.4.1 then, but not critical. > > > > >         Sessions of type MultipointHead MUST NOT send BFD > control packets >         with the State field being set to INIT, and MUST be > ignored on >         receipt. >     English is not my native language but I wonder if this > really says >     what you want. It seems that "Sessions" is the subject of > "MUST be >     ignored" while I think it's the packets which are the intended >     subject. So I'd write: >         and those packets MUST be ignored on receipt. > > You chose to ignore that one or simply missed it? > > > >         Because there is no three-way handshake in Multipoint > BFD, a newly >         started head (that does not have any previous state > information >         available) SHOULD start with bfd.SessionState set to > Down and with >         bfd.RequiredMinRxInterval set to zero in the > MultipointHead session. > >         To shut down a multipoint session a head MUST > administratively set >         bfd.SessionState in the MultipointHead session to > either Down or >         AdminDown and SHOULD set bfd.RequiredMinRxInterval to > zero.  The >     In both these paragraphs one could read that the head > "SHOULD set >     bfd.RequiredMinRxInterval to zero" while 4.4.2 says MUST. >     Clarification needed? > > GIM>> Section 4.4.2 mandates initialization of > bfd.RequiredMinRxInterval and, I think, applies to the first > paragraph you've pointed. Would the following be clear and > consistent: >     Because there is no three-way handshake in Multipoint BFD, > a newly >     started head (that does not have any previous state information >     available) SHOULD start with bfd.SessionState set to Down and >     bfd.RequiredMinRxInterval _MUST be_ set to zero in the > MultipointHead session. > The second paragraph describes manipulation with the value of > bfd.RequiredMinRxInterval which process, as noted in section > 4.10, "is outside the scope of this document". That may be > reason to use SHOULD and not MUST. > > Yes, i'd live with that. But then you might also want to clarify in > 4.4.2. : > OLD: >          This variable MUST be set to 0 for session type > MultipointHead. > NEW: >          This variable MUST be initialized to 0 for session type >          MultipointHead. > > > > > > >     s/M, P bit/M and P bits/ > > GIM>> Thanks, done. > >     --- > > > From nobody Tue Apr 17 13:18:48 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 20780126CD6; Tue, 17 Apr 2018 13:18:47 -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-15.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152399632708.11531.16669790911534260797@ietfa.amsl.com> Date: Tue, 17 Apr 2018 13:18:47 -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: Tue, 17 Apr 2018 20:18:47 -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-15.txt Pages : 18 Date : 2018-04-17 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-15 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-multipoint-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-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 Apr 17 13:20:59 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 36FFB126D05; Tue, 17 Apr 2018 13:20:58 -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, 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 7lozvqq8CE4z; Tue, 17 Apr 2018 13:20:55 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 2D4B4126CD6; Tue, 17 Apr 2018 13:20:55 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id d79-v6so3453523lfd.0; Tue, 17 Apr 2018 13:20:55 -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:content-transfer-encoding; bh=J7Zx+LnvyHHHktBEgY9DErpsRMvaF3rtlvwglMyUWow=; b=laVPrJjkMgFrTzfECzicIjC/vOscO6M1Afssmz1At1wjN4DojU2L89nBtz109vtghN M6crS/R5NA317V9kRiKElAQsG3FsQjZHSU+U0DGG19QDxyqMLMVvRU6jyZ86q/LIPOxD appYg+/ztfBLmpinUvPLlCPiZYeMYFXXnUSdyF4kxRXQqorOC9vC0NQyEV63E4OkiuZJ oCKpqGDsacW8YfldPzSajlx8obQ/8QZhYqjCNvyQsLMkDxQJnoZ+yHFC1qUylPA4WzkE 1Shi4JpkMUpfaPay3GzAHWci/8Nk2eqLyTqmRclNj7xZIxqLEjVhS174lhoNHPNF80l5 dUSg== 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:content-transfer-encoding; bh=J7Zx+LnvyHHHktBEgY9DErpsRMvaF3rtlvwglMyUWow=; b=tgzYZJhI/65NydYYg9v2kIozQnhWSJrsJWEiOW1hF9ZHWmB6iuRTLuxTtrX91FQRPI 5ma44IGVQ1ybKBxvU/Q9WuDbuD8DDMOvhpTKcf4mTtUBuYP5gz1Q/y/Rsfe4JO7auYgy 3WOeWtLLuB93zB9l2hRSN15l/pUz67vRE9xsG50RdG9XI4/1JEIqeAZrN78itlALMhyi H7mceFNhyInrZNPx3c8lmzLerKnr9LYv1WdKb1ydmfWqm2ZwxNQr1Ic1IdP0F86hSV9U iKXrDSd9o+B1L7bikJaCsvG4KBkmJ2r/c4I1N9iJiiYcpQ29fhpSHP44CnY+j4pWk/Dr TFwQ== X-Gm-Message-State: ALQs6tCwgn6Aa7G8gJ6uNhG22r7rAV0uG8AsNCJAUZPAr7H/kNxbs4BY /z69WTyxYLDNB6vmMfqkQJ6hXl7mBmViyU+MaiU= X-Google-Smtp-Source: AIpwx49GXOD8TQIR4+kd4tplYmyHGXcdzfO+1WPZE8AtlIL8hp5JvRCHnXEdSuh9fcmjgjW/bFR1yWu145FKnqKpvB4= X-Received: by 2002:a19:5513:: with SMTP id n19-v6mr2597863lfe.100.1523996453045; Tue, 17 Apr 2018 13:20:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.73.66 with HTTP; Tue, 17 Apr 2018 13:20:52 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Tue, 17 Apr 2018 13:20:52 -0700 Message-ID: Subject: Re: AD review of draft-ietf-bfd-multipoint-14 To: Martin Vigoureux Cc: draft-ietf-bfd-multipoint@ietf.org, "Reshad Rahman (rrahman)" , bfd-chairs@ietf.org, rtg-bfd@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Tue, 17 Apr 2018 20:20:58 -0000 Hi Martin, I've added references to 4.7 and 4.13.2. The new version -15 has been publi= shed. Thank you for your help and support. Regards, Greg On Tue, Apr 17, 2018 at 12:31 PM, Martin Vigoureux wrote: > Greg, > > I'm fine your proposal below. > Please post the final update whenever you can. > Thx > > -m > > > Le 2018-04-17 =C3=A0 20:40, Greg Mirsky a =C3=A9crit : >> >> Hi Martin, >> I have not ignored that comment but missed to ack its acceptance. Two >> other outstanding questions: >> >> * the text, that I've misinterpreted earlier, is in the Overview >> section: >> >> Although this document describes a single head and a >> set of tails >> spanned by a single multipoint path, the protocol is >> capable of >> supporting (and discriminating between) more than one >> multipoint >> path >> at both heads and tails. >> There is no text to describe how one could achieve that. >> Wouldn't it >> be worth adding some? >> >> GIM>> The question of applicability of this specification to >> mp2mp scenario came up at BIER WG meeting in London. Perhaps we >> can say the these questions are ouside the scope of this >> document and discuss whether there are interested to work on >> mp2mp case as a separete document? >> >> I don't read this part of the document as talking about mp2mp but >> rather as talking about multiple p2mp trees. >> >> Sections 4.7 and 4.13.2 provides details on demultiplexing BFD >> control packets at a MultipointTail. Would the reference to these >> sections be sufficient? >> * yes, moved the reference to Point-to-Point session to section 4.4.1 >> >> Attached please find the diff between -14 and the working version of the >> draft. Please let me know if the changes address your comments. Will upl= oad >> the new version promptly. >> >> Regards, >> Greg >> >> On Tue, Apr 17, 2018 at 9:49 AM, Martin Vigoureux >> > wrote: >> >> Greg, >> >> thanks. please see in-line. >> >> once I see the update published I will request IETF LC. >> >> -m >> >> Le 2018-04-17 =C3=A0 18:34, Greg Mirsky a =C3=A9crit : >> >> Hi Martin, >> thank you for your thorough review, thoughtful comments and kind >> words. >> Please find my answers to your questions in-line and tagged GIM>= >. >> >> Regards, >> Greg >> >> On Tue, Apr 17, 2018 at 8:06 AM, Martin Vigoureux >> >> > >> >> wrote: >> >> [resend, wrong bfd wg address in first attempt ...] >> >> Authors, WG, >> >> thank you for this document. It is clear and well written. >> I didn't find any technical comment to make so I've been >> nit picking :-) >> Please find those comments below. >> >> regards, >> martin >> >> --- >> Please check and address the nits: >> >> https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf= -bfd-multipoint-14.txt >> >> >> >> > >> > >> >> On that aspect, does this document really update 7880 as >> the header >> says? The Introduction only refers to 5880 and it is not >> clear in >> the body of the Document what effectively impacts 7880. The >> only >> thing I saw is the addition of new session types but that >> does not >> require an update in my opinion. Could you clarify? >> GIM>> Yes, you'correct, the only connection to RFC 7880 are >> the new >> values of bfd.sessionType. The proposal to list RFC 7880 as >> updated >> by this specification was inteded to address Errata to RFC >> 7880 >> > >. >> >> I am not sure how this document relates to or addresses the errata. >> So I still think it does not update 7880. >> >> >> i.e. existence of a path between the sender and the >> receiver. >> do you mean "forwarding path"? >> GIM>> Yes. Updated to >> >> i.e. existence of a forwarding path between the sender and >> the receiver >> >> thx >> >> >> Section 2. and Section 3. seem a bit redundant. They both >> state the >> same thing but from a different angle. Not critical. >> >> >> Although this document describes a single head and a >> set of tails >> spanned by a single multipoint path, the protocol is >> capable of >> supporting (and discriminating between) more than one >> multipoint >> path >> at both heads and tails. >> There is no text to describe how one could achieve that. >> Wouldn't it >> be worth adding some? >> >> GIM>> The question of applicability of this specification to >> mp2mp scenario came up at BIER WG meeting in London. Perhaps we >> can say the these questions are ouside the scope of this >> document and discuss whether there are interested to work on >> mp2mp case as a separete document? >> >> I don't read this part of the document as talking about mp2mp but >> rather as talking about multiple p2mp trees. >> >> >> >> >> Point-to-point sessions, as described in [RFC5880], are >> of type >> PointToPoint. >> Does this really fit in Section 4.2 which looks to be about >> the >> mpBFD session model. >> >> GIM>> I think that this short reminder is helpful to explain why >> this document adds value PointToPoint, section 4.4.1, to the >> defined in RFC 7880 bfd.sessionType variable. >> >> Well, I would move the text to 4.4.1 then, but not critical. >> >> >> >> >> Sessions of type MultipointHead MUST NOT send BFD >> control packets >> with the State field being set to INIT, and MUST be >> ignored on >> receipt. >> English is not my native language but I wonder if this >> really says >> what you want. It seems that "Sessions" is the subject of >> "MUST be >> ignored" while I think it's the packets which are the >> intended >> subject. So I'd write: >> and those packets MUST be ignored on receipt. >> >> You chose to ignore that one or simply missed it? >> >> >> >> Because there is no three-way handshake in Multipoint >> BFD, a newly >> started head (that does not have any previous state >> information >> available) SHOULD start with bfd.SessionState set to >> Down and with >> bfd.RequiredMinRxInterval set to zero in the >> MultipointHead session. >> >> To shut down a multipoint session a head MUST >> administratively set >> bfd.SessionState in the MultipointHead session to >> either Down or >> AdminDown and SHOULD set bfd.RequiredMinRxInterval to >> zero. The >> In both these paragraphs one could read that the head >> "SHOULD set >> bfd.RequiredMinRxInterval to zero" while 4.4.2 says MUST. >> Clarification needed? >> >> GIM>> Section 4.4.2 mandates initialization of >> bfd.RequiredMinRxInterval and, I think, applies to the first >> paragraph you've pointed. Would the following be clear and >> consistent: >> Because there is no three-way handshake in Multipoint BFD, >> a newly >> started head (that does not have any previous state >> information >> available) SHOULD start with bfd.SessionState set to Down a= nd >> bfd.RequiredMinRxInterval _MUST be_ set to zero in the >> MultipointHead session. >> The second paragraph describes manipulation with the value of >> bfd.RequiredMinRxInterval which process, as noted in section >> 4.10, "is outside the scope of this document". That may be >> reason to use SHOULD and not MUST. >> >> Yes, i'd live with that. But then you might also want to clarify in >> 4.4.2. : >> OLD: >> This variable MUST be set to 0 for session type >> MultipointHead. >> NEW: >> This variable MUST be initialized to 0 for session type >> MultipointHead. >> >> >> >> >> >> >> s/M, P bit/M and P bits/ >> >> GIM>> Thanks, done. >> >> --- >> >> >> > From nobody Wed Apr 18 06:23:19 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 83DEF1243F6; Wed, 18 Apr 2018 06:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 UO4zN6AjFelx; Wed, 18 Apr 2018 06:23:13 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0095.outbound.protection.outlook.com [104.47.0.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057531267BB; Wed, 18 Apr 2018 06:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Sqm+f/nUOERiKw9rTo+v/TordYdDiF6IimBja0vWymc=; b=A3lGczzkWezhhAUfeypo9qkSmx+rF2QoALXvCJn6/iDHuE7Nzu8gqDz4UV/Uf8MY4ofzT/FlExWqIrlutaO8hXfa9EnRLgJ/ZcseZaTuDXk5QW3nlUPN/ZeTOufUotWo3dgHIAvy9iqn9Od99QO5dCT+8ugzHrBT+HQN3A2uekA= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; Received: from [IPv6:2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65] (2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65) by HE1PR0701MB2139.eurprd07.prod.outlook.com (2603:10a6:3:2b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.7; Wed, 18 Apr 2018 13:23:09 +0000 Subject: Re: AD review of draft-ietf-bfd-multipoint-14 To: Greg Mirsky Cc: draft-ietf-bfd-multipoint@ietf.org, "Reshad Rahman (rrahman)" , bfd-chairs@ietf.org, rtg-bfd@ietf.org References: From: Martin Vigoureux Message-ID: Date: Wed, 18 Apr 2018 15:22:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit X-Originating-IP: [2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65] X-ClientProxiedBy: CWLP265CA0012.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:10::24) To HE1PR0701MB2139.eurprd07.prod.outlook.com (2603:10a6:3:2b::12) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:HE1PR0701MB2139; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2139; 3:6riEyUs1EPhHEXtrciRGXK1hQK3THnM48dhGFCvtKBwLB42ipVCqjw8dj4/OoRcDxZtK3e5MM2AB0wi4a/JMz9px3aFGopEmobdu8kzLbuk7YGGEaTF7YETyDZ79bqk9EtVlPm9wGUOAnGIUmGHAIIyO+Q0j4/8Dk3DhTXymeN3PNErakSQ9oaqIaLgAwD8zDp/i5ggCWIGK5pasPDgM5JWO3JfL/+xSRzOwUAJYASZlvcKpcfHfNDvPS7r2Npml; 25:LpzutKLPTCLyXLiD+2YxvMhZ+84hC7o7Y9fK6XG+cIzoCDIhTC1GuSbMbdfIcU8GqhT0zq/J+TJdgVMeQBSaUAXt1Ki0BvkR3rrfg1WwCh0wtr2G6+5kBN45vhzYkuhI7K96pcwXNP07rXzpcUaAWLZtEeBwYYtNEJ9xVw8ojBu9w+Fz0lEh/PzKVVN8kUIgjMLTOGYfNUr+S6mtZzdFoAfiR/Yy99SPtz5kbW4eoDTIbejHOPIExi67WYeerlTaIknT/bpV9QDnO19Pb+e4mYPf8ybTByHlzFGcLkOERXQ0CAmSY2LPassU6gP6P/q1ZZVeh1ZenjprcpGsLCMvHg==; 31:fYaSQtT8sPvYUPz7SoSiqK9Pl0emj0z9OYbB2++CHYQp4TFD8GC9I1ij6O90dG+IICJb9jC55D6yR3UlbJM6sYv13jJjchE8aIBLEbuS1VT85nu7bk+o5OOB95OAT+dptSYuW4QhAXRuY04lQZOZJOtW9ZS8rti0DaCebTTiKfG3MQoWXJRomzI7gHsPYdRGTPcGe7+D8laCzio08hb7718QjsSeurHBxta0UESNR80= X-MS-TrafficTypeDiagnostic: HE1PR0701MB2139: X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2139; 20:tmF2bZx43CY4cn0TFhp3l5A8sGO/xALrorFr8xrOS05BbBFyPoqqFUB2Gf2uIPLJYjFW8uhoWjyEfdIIucK9m9sN2XDIEMOIxb9wBjtyw21vtM8QNIbdUkidXvJc5Yi62Mo10032VZOH1yIo2dUsT18Gvb3bTGDCNHYioYggBwYDocEKx/PNZjcbzBZcz1QoUB9M480gSSOv0CO3ShsRysdpoGNRLKiSnzIXfSJgT/m2ZLKG13Shl35XAFbJ1lTSMoPSEDdaBGjArEcKJNpdFoNvJ9bAgDYY9xSzVpt5q7lbi3f+qZ/W0zo0oJ+deg/sTXeJp83hdSHk8hfV6KsrJ9tbXvMwEw0Ca1gyLC/Fxtpc5IXNkt/SzsXvlX37lX2sfGmMnZmjP/MucUpbihAVh57Voud1GLYz3irW6rRvW9n5OFoznIjRXx/lvXhumXlx3k6egV9um3dd2c3lJeKX7uKN6tQ4ehSjckHnNS6exzc9YXtZJ0bgkl8qFHRe/1jh; 4:siNoWHSHZH1NPSVY5o117olL1S4Qhd19HFTLSpjhAvEfiOcOMslYl9RB2LV3wAUK/Cs5YBvIUrDziirC64Kq8jIzIlS2Ky5isGhs88HBM7QugNiBKFu2TzPQOnEkUGkR8GOJ+BpVAQT3KvpCXmD9Y5LFwu7m6w6Ok930fie6EhyipMjHtnziTc+f31a21y2u3qR48F4ugrP3umMLs3aykm0IUl+J8xcQlOSNfhPYC7YP+p9B6+mDgC/Z6+XO2q2Nj5+cinEEfXRzISADgzh2MgW8olDsrZ9BQxusOKYxj0UCNLA8eLV3N9S52i5QdmPv X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(82608151540597); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231232)(11241501184)(806099)(944501327)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041310)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:HE1PR0701MB2139; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2139; X-Forefront-PRVS: 06469BCC91 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(376002)(39860400002)(396003)(346002)(51444003)(54094003)(40764003)(377424004)(64126003)(44832011)(446003)(6916009)(2616005)(1411001)(67846002)(76176011)(16799955002)(305945005)(52116002)(23676004)(7736002)(6666003)(93886005)(52146003)(2486003)(65826007)(52396003)(65806001)(966005)(5660300001)(561944003)(65956001)(386003)(59450400001)(6246003)(6306002)(476003)(47776003)(53546011)(11346002)(50466002)(31686004)(6486002)(4326008)(316002)(1706002)(229853002)(2870700001)(6116002)(39060400002)(36756003)(53936002)(25786009)(16526019)(2906002)(31696002)(81166006)(46003)(345774005)(478600001)(86362001)(8676002)(106356001)(58126008)(186003)(3260700006)(68736007)(8936002)(5890100001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2139; H:[IPv6:2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65]; FPR:; SPF:None; LANG:en; MLV:ovrnspm; PTR:InfoNoRecords; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjIxMzk7MjM6alR3ZGVONE9nU2FwZVlFRU5VNEFzUldR?= =?utf-8?B?M1RidldNa3JRTDBnSkFjWWNzbHJZV1k5ZWExbUhYMlRpakJPOHp5Qm1FOUJU?= =?utf-8?B?UlI0SmFrN3BCekpxTFExbkpmN0ZLY1hscXk0MFllZGtzZ1hKUFo3eER0K01h?= =?utf-8?B?ZVJaQk1lTSswWWhsS0VYZTkzdG1hTnN3MjVMTXJvRzhucWJ0aXE3Zys2aG1Q?= =?utf-8?B?bGNZMjBBK2xrUHByVFZldi94WDlJWTd6RUErc1hsUFZnV3QzUVhCOWhUZUZ0?= =?utf-8?B?VVJmUVdvVVpMWkFNVlVKY1VLSHdjYUJXZzdCZTM2MnNJMEZIdnFKSzVlVXd6?= =?utf-8?B?azJMaGlTbnV3VjdJS0o0TlM2b0RFbjB1TVVLRjcvM1o1VVZMRk1wRlFmdE9C?= =?utf-8?B?Wks2ZEJKOC83WStLUkYzaWhOUG1oY1piQ0ovU3NQY1Axb096S0pwZDFSRnpm?= =?utf-8?B?Z2RKWEd6aVJ4VWtBaWQyNlF6RE5XSHQrUkJ0bnVRa1lOVTJtNXRSOFpJOGpE?= =?utf-8?B?NVlOVUpyQStqYmR2UHBoM0JQeXVkdXJIdmljczROeDZjRE9HcDBQeHpJclVO?= =?utf-8?B?K1l4TG9JNzdWazluK0NhTERoTHZTK1BJOTdZRCtnZFNjcXNBbHorOG05WWZB?= =?utf-8?B?dUovV0czWGN6L09CVmdVTldRbmNJckpEaUFYWFV4ZkxOVTdJQXJDbTFMbS9U?= =?utf-8?B?REcwVUl5VkZ6YkVubjF1aU10Q1ZwMmM3bGNnRzVxZEFNc0U5RDBmWGw1TFlp?= =?utf-8?B?elNxTXBzdW9hYmlEYTRidVZVanc5L0JUalVPcVJCZHl4STZKV2FqTkxkd3VS?= =?utf-8?B?QmNZUkZ1VEZBYTRheGJKVXJOMzdtRFRic2FXQ1A4TFhBd09rZG9kdjU3TEIr?= =?utf-8?B?azQ5VmsydlBGQnNqKzhPaUpNYkdrN2xkRnZxaFVDWVZUd2ZQNlNvckowMzJr?= =?utf-8?B?TTF6VW56YU1ocExmOHV2ZjdrNXlqVTFNQTZyQWVta0ZLUktobFdNbWdPM09J?= =?utf-8?B?WncvZjhZVjhUR2JNN2FMeUx0cU1CdXFoYVFERVI2QXpSZklmVUM2Uk9EWkVY?= =?utf-8?B?MkxMSmVmcU1TWWhMdkQ0ZkV0dUovbWVLMjdmVENXaE1UdzM2SWloQUppdWJU?= =?utf-8?B?dTVNSXJyM25jRW1JS3FyZjdkVnVjWnM0aEpMclBjczFHY2lLVGNIWVpFSkh0?= =?utf-8?B?MXlHL0tMeDRMVnYvVjZ0aEsvMXpXSUlXTjQxZ2RiTC9ZR2FDQVhab0FmRFds?= =?utf-8?B?YUFsampBSHFLYUczcFFZQ3lBT0RmR2FFRUJNcXFPcUw3RTFhdEo4R1pLWWIy?= =?utf-8?B?QjQzY0VFWC9neFFnbkY1Q3NYK0lZM1pSWWExZERNbmoyUmRQYVBJMVhpWmNo?= =?utf-8?B?endQanZYUElaRldRNDhaaXZwbjMyQkhCMHZ5QURqVmNJVzJDMGtrWW9kLzZi?= =?utf-8?B?V1dEeVNENEdEcGlWUHIzenNtNW55WW9veHZGQWNXS1F1RGdId3RRQjRjQ0VH?= =?utf-8?B?UXIyNXlXRHBYazJ5aVE0ckJ6R0hORDdZdGRtQndzR3kweVFXbkprcDdpWG5Q?= =?utf-8?B?OE96VW9heWRSV0VJSHVKVkhJMlBwckdZKzhKRklsd2ROWWdCTm9jM0xEV1NC?= =?utf-8?B?UmlZY3hra2tCQzZ6Z2l6U2xwT2ZablREcmJ2QmI0elN0SUxmNW8xQy9YemhT?= =?utf-8?B?dHJSQndCNWFGRHlxUnlsYlFBMVFkS2NDTWROSzhhcDQ4NDFQd0o3WXdWNVdH?= =?utf-8?B?Zzd6SkhQTndFQUN3Yzk1eTUxd3lEbGxjcHQxdHFVRnN2bTRpc1FmUGQ1RFlU?= =?utf-8?B?RWpRSmlUTG9IOU9XRUdNTEVxZHk1M00vWlY5YnNEYm9rNDNGUEZSaHlJOG5C?= =?utf-8?B?c0t3R0NCekRvajJpM1h3OE5nbTV3ZmgxOUVhUzcxcmhwamNvWWNQU2tmV3Vu?= =?utf-8?B?NTdoekI0Q0R1a1hORmNlNGhjVE9YTi9td1RjTEkvcWhzbU01cldudE1QZ3gv?= =?utf-8?B?dUJSTmU2bTBCdlZSNXlnMFozZTNzcTdhbHRxeWUrRjA0T2N1aGVVNVgrd3J1?= =?utf-8?B?aE50V3NheTFSLzNzZDdOZlVpOGZpa1N6RXZjQkFEaEJhNTdFbVVZaTlkYnYz?= =?utf-8?B?UWxwLzJidFl4QXlzTFFjeGt6UkpoNlFTL3BBdW9VQkdiaFRZTzIxUkRqQk1K?= =?utf-8?B?dEpwbXIwR25CemMzZ1kyN1BDaS9UdVE9PQ==?= X-Microsoft-Antispam-Message-Info: 7YuDIINMObFnHkHAH+rzlrXqosuG/CeeKk/ept5+OWkZ+/Ji9iPr/Yp0GFg9m4kf1ID0GqbxTigxPbPkm7N1XPEhFJQExPbw2W9fJtlHorj9UoWWgKqi3VNnfQB858XmpVb2QbrFXJNJea3rQovhrNxhyLyOaq5ayRP9ZVkBNe4PIP+45mQTIysgFs5XXlj4r80ixwpA5sGGQzLNhoMghBh3aBN1SUVxJ2r4Q0wIBSXfiS84oY03ocFh/CczNZT/ X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2139; 6:4XQOGmk/Qwzgd7ngs/HV6okZQ1MnztH7kl5G7hkzSFFF/LLVnayIuphALlEnIuPya22xC+9+O8qc/XzZJtGfTHQfb6hqwEBbh4DqyiJFxLbCN3KVqpv+xDfpSk3mhxnVnecjeNhPrAZuu7mv0oIhzUXdwXJGvLFgcbqYkXPIiTwQaz2ngUmB/eYLD3qyJG2jYVDVZ/xwqDMD68GZlZcRx2uBQGQuJe1WKxKus5rxK5dlpWe5niGL2NQNnYbF+JObKELF4MZuqtUlC6zkM0gkX2nE/jRnAWANT8XnWQQuSCeO+LRoktm5Gh87JGn/aNl4LDkYBrbeox+KScn2ppbaQ9KosE9wgDDKi6Th8maA68hIXqPHCpa/Ha3uFoNBPQAD30dH1Wa46Lj63ALpua+VPZfulBbmLb1ZlZovaakzjkfpKTIr7O0oKkErySRgMF5aR121xiCmER5O2pTCDaIAtg==; 5:+LBP+i0zTaUlfKB7Jp3+jb4hdGs5ORvnfaPuecgHpKirCGMFJtvqS2pza3ndlh3Xnl3Bwtk0Riyof9BNPgwOymebrZMQfq85L8yiFj55Vtbn8QxrUPK+Tx/Iwirjz2pjsQQblvGaitM1YFb4zW3SuyTzQNCvgxaSDlCmvXQxsR0=; 24:Gf0oYDPxK85RteKwvqA64fwyd9/iCd0wirTOe5liibs9V7eT2cRmw6juoMsKx9zaaoSqus/HwED0nB4XBDJJNPS6qL2XZ3LU+ACAwRxUCTI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2139; 7:885fuz4n2k4Q42bFurnlTEU/BNS8WKLu0nUd6+ajis61BArZP6Vvlevm2S8wC1ZOGuHGzIMFcXRDb3e29PXYf3Lbm8p/vuUbkdA/NQWJHT4GtN0ikhII/OsWpAe1+5VLvWaMgOFpgVCiTE3iXv0+jsgSBDSvj/hs1YG8+dpaytjp+eig1VOv7yxo6r6vxqR2lt3q5ur7Y5COLRqwilrRMhpHNHZ1EL5FpHoNJDI62Xnem3YMA4EWl7nKveTcpYce X-MS-Office365-Filtering-Correlation-Id: 99285f01-86f7-42c3-b45b-08d5a52f877b X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Apr 2018 13:23:09.3907 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 99285f01-86f7-42c3-b45b-08d5a52f877b X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2139 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: Wed, 18 Apr 2018 13:23:18 -0000 Greg, thanks. Sorry, but reading again the document I found: This variable MUST be initialized to the appropriate type when the session is created, according to the rules in Section 4.13 I might have parsed 4.13 (and subsections) too quickly but I did not find any rule regarding the initalization of this variable. Is that indeed the case? If so then I would suggest to simply remove the pointer. -m Le 2018-04-17 à 22:20, Greg Mirsky a écrit : > Hi Martin, > I've added references to 4.7 and 4.13.2. The new version -15 has been published. > Thank you for your help and support. > > Regards, > Greg > > On Tue, Apr 17, 2018 at 12:31 PM, Martin Vigoureux > wrote: >> Greg, >> >> I'm fine your proposal below. >> Please post the final update whenever you can. >> Thx >> >> -m >> >> >> Le 2018-04-17 à 20:40, Greg Mirsky a écrit : >>> >>> Hi Martin, >>> I have not ignored that comment but missed to ack its acceptance. Two >>> other outstanding questions: >>> >>> * the text, that I've misinterpreted earlier, is in the Overview >>> section: >>> >>> Although this document describes a single head and a >>> set of tails >>> spanned by a single multipoint path, the protocol is >>> capable of >>> supporting (and discriminating between) more than one >>> multipoint >>> path >>> at both heads and tails. >>> There is no text to describe how one could achieve that. >>> Wouldn't it >>> be worth adding some? >>> >>> GIM>> The question of applicability of this specification to >>> mp2mp scenario came up at BIER WG meeting in London. Perhaps we >>> can say the these questions are ouside the scope of this >>> document and discuss whether there are interested to work on >>> mp2mp case as a separete document? >>> >>> I don't read this part of the document as talking about mp2mp but >>> rather as talking about multiple p2mp trees. >>> >>> Sections 4.7 and 4.13.2 provides details on demultiplexing BFD >>> control packets at a MultipointTail. Would the reference to these >>> sections be sufficient? >>> * yes, moved the reference to Point-to-Point session to section 4.4.1 >>> >>> Attached please find the diff between -14 and the working version of the >>> draft. Please let me know if the changes address your comments. Will upload >>> the new version promptly. >>> >>> Regards, >>> Greg >>> >>> On Tue, Apr 17, 2018 at 9:49 AM, Martin Vigoureux >>> > wrote: >>> >>> Greg, >>> >>> thanks. please see in-line. >>> >>> once I see the update published I will request IETF LC. >>> >>> -m >>> >>> Le 2018-04-17 à 18:34, Greg Mirsky a écrit : >>> >>> Hi Martin, >>> thank you for your thorough review, thoughtful comments and kind >>> words. >>> Please find my answers to your questions in-line and tagged GIM>>. >>> >>> Regards, >>> Greg >>> >>> On Tue, Apr 17, 2018 at 8:06 AM, Martin Vigoureux >>> >>> >> >>> >> wrote: >>> >>> [resend, wrong bfd wg address in first attempt ...] >>> >>> Authors, WG, >>> >>> thank you for this document. It is clear and well written. >>> I didn't find any technical comment to make so I've been >>> nit picking :-) >>> Please find those comments below. >>> >>> regards, >>> martin >>> >>> --- >>> Please check and address the nits: >>> >>> https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-bfd-multipoint-14.txt >>> >>> >>> >>> >> >>> > >>> >>> On that aspect, does this document really update 7880 as >>> the header >>> says? The Introduction only refers to 5880 and it is not >>> clear in >>> the body of the Document what effectively impacts 7880. The >>> only >>> thing I saw is the addition of new session types but that >>> does not >>> require an update in my opinion. Could you clarify? >>> GIM>> Yes, you'correct, the only connection to RFC 7880 are >>> the new >>> values of bfd.sessionType. The proposal to list RFC 7880 as >>> updated >>> by this specification was inteded to address Errata to RFC >>> 7880 >>> >> >. >>> >>> I am not sure how this document relates to or addresses the errata. >>> So I still think it does not update 7880. >>> >>> >>> i.e. existence of a path between the sender and the >>> receiver. >>> do you mean "forwarding path"? >>> GIM>> Yes. Updated to >>> >>> i.e. existence of a forwarding path between the sender and >>> the receiver >>> >>> thx >>> >>> >>> Section 2. and Section 3. seem a bit redundant. They both >>> state the >>> same thing but from a different angle. Not critical. >>> >>> >>> Although this document describes a single head and a >>> set of tails >>> spanned by a single multipoint path, the protocol is >>> capable of >>> supporting (and discriminating between) more than one >>> multipoint >>> path >>> at both heads and tails. >>> There is no text to describe how one could achieve that. >>> Wouldn't it >>> be worth adding some? >>> >>> GIM>> The question of applicability of this specification to >>> mp2mp scenario came up at BIER WG meeting in London. Perhaps we >>> can say the these questions are ouside the scope of this >>> document and discuss whether there are interested to work on >>> mp2mp case as a separete document? >>> >>> I don't read this part of the document as talking about mp2mp but >>> rather as talking about multiple p2mp trees. >>> >>> >>> >>> >>> Point-to-point sessions, as described in [RFC5880], are >>> of type >>> PointToPoint. >>> Does this really fit in Section 4.2 which looks to be about >>> the >>> mpBFD session model. >>> >>> GIM>> I think that this short reminder is helpful to explain why >>> this document adds value PointToPoint, section 4.4.1, to the >>> defined in RFC 7880 bfd.sessionType variable. >>> >>> Well, I would move the text to 4.4.1 then, but not critical. >>> >>> >>> >>> >>> Sessions of type MultipointHead MUST NOT send BFD >>> control packets >>> with the State field being set to INIT, and MUST be >>> ignored on >>> receipt. >>> English is not my native language but I wonder if this >>> really says >>> what you want. It seems that "Sessions" is the subject of >>> "MUST be >>> ignored" while I think it's the packets which are the >>> intended >>> subject. So I'd write: >>> and those packets MUST be ignored on receipt. >>> >>> You chose to ignore that one or simply missed it? >>> >>> >>> >>> Because there is no three-way handshake in Multipoint >>> BFD, a newly >>> started head (that does not have any previous state >>> information >>> available) SHOULD start with bfd.SessionState set to >>> Down and with >>> bfd.RequiredMinRxInterval set to zero in the >>> MultipointHead session. >>> >>> To shut down a multipoint session a head MUST >>> administratively set >>> bfd.SessionState in the MultipointHead session to >>> either Down or >>> AdminDown and SHOULD set bfd.RequiredMinRxInterval to >>> zero. The >>> In both these paragraphs one could read that the head >>> "SHOULD set >>> bfd.RequiredMinRxInterval to zero" while 4.4.2 says MUST. >>> Clarification needed? >>> >>> GIM>> Section 4.4.2 mandates initialization of >>> bfd.RequiredMinRxInterval and, I think, applies to the first >>> paragraph you've pointed. Would the following be clear and >>> consistent: >>> Because there is no three-way handshake in Multipoint BFD, >>> a newly >>> started head (that does not have any previous state >>> information >>> available) SHOULD start with bfd.SessionState set to Down and >>> bfd.RequiredMinRxInterval _MUST be_ set to zero in the >>> MultipointHead session. >>> The second paragraph describes manipulation with the value of >>> bfd.RequiredMinRxInterval which process, as noted in section >>> 4.10, "is outside the scope of this document". That may be >>> reason to use SHOULD and not MUST. >>> >>> Yes, i'd live with that. But then you might also want to clarify in >>> 4.4.2. : >>> OLD: >>> This variable MUST be set to 0 for session type >>> MultipointHead. >>> NEW: >>> This variable MUST be initialized to 0 for session type >>> MultipointHead. >>> >>> >>> >>> >>> >>> >>> s/M, P bit/M and P bits/ >>> >>> GIM>> Thanks, done. >>> >>> --- >>> >>> >>> >> > From nobody Wed Apr 18 09:47:35 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 3D2A0126C2F; Wed, 18 Apr 2018 09:47:33 -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 x_WtiKfVn3f5; Wed, 18 Apr 2018 09:47:29 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 39B821242F7; Wed, 18 Apr 2018 09:47:29 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id i18-v6so3632680lfc.7; Wed, 18 Apr 2018 09:47:29 -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=WiHE7TU6Q2bk87O60pU3SVDzUwBNQ8dht0rUoxRLFGo=; b=Ihd8aSo+sSu0a7etsnb+eBMo1aRziY2gTxxqyr7BKo/6TIR3IltENOgSCNP1yPVfF1 s1gAh18wpp/VEBt9PgyXBmQwEccbpQSzklQAaBOVlQC4wLXhEfdp1IoyiEUyxcu4IZTz mas8kDbUIunMxYJ5wPONH7eiV+/PpJ3ixGpOTcz2euV+eN5ooB0XnHNBNJHwjAwi/kqC 2WXI/pM6NaskmTTnnSRfI9Jpl4heX3nbZB/6aTJvp3O22+jGoC76l2FGSzlh2MnQA0V9 dNhFOAox4rOnFgJ/p0QVU2Y/HpyuCoZ7EEws1Vj/ezPKTRHwuZruEwwJCYkz4X1FzRCE p0zw== 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=WiHE7TU6Q2bk87O60pU3SVDzUwBNQ8dht0rUoxRLFGo=; b=iXYHGMAkaDKPQJtY591ehyM5x8OCJtklEG4QFkJk5ZKnCQjVwXw06eroeZ1EtUWxib 8fxw8JxuAmScAyYu4J2pYtQDjqajUirbase1nZCgonwPgCpM9tPZE65Z95G+KayTSYxx 7x5eqKHVgLRV+c7Ua56nYMpylwNgtxeZD5u/B7y68tZ1Ntp81Hqkog9mqh/J2wqg727i GDKACidgiLB8Mb3gKAGtzT1FaXAAti9eIoaK/ANowpf9iSZE+jH4ZXnf4mTtDrAMY9H1 9xREZuAvNbSmiP0ZmavRHIh0HjCk+57OQU6APfBxSBcTpmnISWkrkt11edDG0vaOC4qc 1VZw== X-Gm-Message-State: ALQs6tBsSZgt6xaWnJ003Sx2yzW1rM+Bmz5EdB03WV3Q5GK0xTqBAmfU LAlJWKCPpOuhbjiaDbtL83UnjunfpKmZ8ko0OORUrYWyZwA= X-Google-Smtp-Source: AIpwx4/gBU0A5n5vurvnBTuT495TziX5Ru2pniRZ5XjYXk+Yv3/zxCOskFuFUlPQsBH1c4qW0CkuO9t0qKH5AIrJ6Lw= X-Received: by 2002:a19:1398:: with SMTP id 24-v6mr2117859lft.106.1524070046806; Wed, 18 Apr 2018 09:47:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.73.66 with HTTP; Wed, 18 Apr 2018 09:47:25 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Wed, 18 Apr 2018 09:47:25 -0700 Message-ID: Subject: Re: AD review of draft-ietf-bfd-multipoint-14 To: Martin Vigoureux Cc: draft-ietf-bfd-multipoint@ietf.org, "Reshad Rahman (rrahman)" , bfd-chairs@ietf.org, rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary="000000000000c0be92056a22355f" 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: Wed, 18 Apr 2018 16:47:33 -0000 --000000000000c0be92056a22355f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Martin, thank you for catching this empty reference. I've looked back and couldn't find any text that describes the initialization of the state variable. The new text simply states: This variable MUST be initialized to the appropriate type when the session is created. Will upload the new version shortly. Regards, Greg On Wed, Apr 18, 2018 at 6:22 AM, Martin Vigoureux < martin.vigoureux@nokia.com> wrote: > Greg, > > thanks. Sorry, but reading again the document I found: > This variable MUST be initialized to the appropriate type when > the session is created, according to the rules in Section 4.13 > I might have parsed 4.13 (and subsections) too quickly but I did not find > any rule regarding the initalization of this variable. Is that indeed the > case? If so then I would suggest to simply remove the pointer. > > -m > > > Le 2018-04-17 =C3=A0 22:20, Greg Mirsky a =C3=A9crit : > >> Hi Martin, >> I've added references to 4.7 and 4.13.2. The new version -15 has been >> published. >> Thank you for your help and support. >> >> Regards, >> Greg >> >> On Tue, Apr 17, 2018 at 12:31 PM, Martin Vigoureux >> wrote: >> >>> Greg, >>> >>> I'm fine your proposal below. >>> Please post the final update whenever you can. >>> Thx >>> >>> -m >>> >>> >>> Le 2018-04-17 =C3=A0 20:40, Greg Mirsky a =C3=A9crit : >>> >>>> >>>> Hi Martin, >>>> I have not ignored that comment but missed to ack its acceptance. Two >>>> other outstanding questions: >>>> >>>> * the text, that I've misinterpreted earlier, is in the Overview >>>> section: >>>> >>>> Although this document describes a single head and a >>>> set of tails >>>> spanned by a single multipoint path, the protocol is >>>> capable of >>>> supporting (and discriminating between) more than on= e >>>> multipoint >>>> path >>>> at both heads and tails. >>>> There is no text to describe how one could achieve that. >>>> Wouldn't it >>>> be worth adding some? >>>> >>>> GIM>> The question of applicability of this specification to >>>> mp2mp scenario came up at BIER WG meeting in London. Perhaps = we >>>> can say the these questions are ouside the scope of this >>>> document and discuss whether there are interested to work on >>>> mp2mp case as a separete document? >>>> >>>> I don't read this part of the document as talking about mp2mp but >>>> rather as talking about multiple p2mp trees. >>>> >>>> Sections 4.7 and 4.13.2 provides details on demultiplexing BFD >>>> control packets at a MultipointTail. Would the reference to these >>>> sections be sufficient? >>>> * yes, moved the reference to Point-to-Point session to section 4.4= .1 >>>> >>>> Attached please find the diff between -14 and the working version of t= he >>>> draft. Please let me know if the changes address your comments. Will >>>> upload >>>> the new version promptly. >>>> >>>> Regards, >>>> Greg >>>> >>>> On Tue, Apr 17, 2018 at 9:49 AM, Martin Vigoureux >>>> > wrote= : >>>> >>>> Greg, >>>> >>>> thanks. please see in-line. >>>> >>>> once I see the update published I will request IETF LC. >>>> >>>> -m >>>> >>>> Le 2018-04-17 =C3=A0 18:34, Greg Mirsky a =C3=A9crit : >>>> >>>> Hi Martin, >>>> thank you for your thorough review, thoughtful comments and >>>> kind >>>> words. >>>> Please find my answers to your questions in-line and tagged >>>> GIM>>. >>>> >>>> Regards, >>>> Greg >>>> >>>> On Tue, Apr 17, 2018 at 8:06 AM, Martin Vigoureux >>>> >>> > >>>> >>> >>>> >> wrote: >>>> >>>> [resend, wrong bfd wg address in first attempt ...] >>>> >>>> Authors, WG, >>>> >>>> thank you for this document. It is clear and well writte= n. >>>> I didn't find any technical comment to make so I've been >>>> nit picking :-) >>>> Please find those comments below. >>>> >>>> regards, >>>> martin >>>> >>>> --- >>>> Please check and address the nits: >>>> >>>> https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/ >>>> draft-ietf-bfd-multipoint-14.txt >>>> >>>> >>> id/draft-ietf-bfd-multipoint-14.txt> >>>> >>>> >>> id/draft-ietf-bfd-multipoint-14.txt >>>> >>>> >>> id/draft-ietf-bfd-multipoint-14.txt>> >>>> >>>> On that aspect, does this document really update 7880 as >>>> the header >>>> says? The Introduction only refers to 5880 and it is not >>>> clear in >>>> the body of the Document what effectively impacts 7880. >>>> The >>>> only >>>> thing I saw is the addition of new session types but tha= t >>>> does not >>>> require an update in my opinion. Could you clarify? >>>> GIM>> Yes, you'correct, the only connection to RFC 7880 >>>> are >>>> the new >>>> values of bfd.sessionType. The proposal to list RFC 7880 >>>> as >>>> updated >>>> by this specification was inteded to address Errata to R= FC >>>> 7880 >>>> >>> >. >>>> >>>> I am not sure how this document relates to or addresses the errat= a. >>>> So I still think it does not update 7880. >>>> >>>> >>>> i.e. existence of a path between the sender and the >>>> receiver. >>>> do you mean "forwarding path"? >>>> GIM>> Yes. Updated to >>>> >>>> i.e. existence of a forwarding path between the sender a= nd >>>> the receiver >>>> >>>> thx >>>> >>>> >>>> Section 2. and Section 3. seem a bit redundant. They bot= h >>>> state the >>>> same thing but from a different angle. Not critical. >>>> >>>> >>>> Although this document describes a single head and a >>>> set of tails >>>> spanned by a single multipoint path, the protocol is >>>> capable of >>>> supporting (and discriminating between) more than on= e >>>> multipoint >>>> path >>>> at both heads and tails. >>>> There is no text to describe how one could achieve that. >>>> Wouldn't it >>>> be worth adding some? >>>> >>>> GIM>> The question of applicability of this specification to >>>> mp2mp scenario came up at BIER WG meeting in London. Perhaps = we >>>> can say the these questions are ouside the scope of this >>>> document and discuss whether there are interested to work on >>>> mp2mp case as a separete document? >>>> >>>> I don't read this part of the document as talking about mp2mp but >>>> rather as talking about multiple p2mp trees. >>>> >>>> >>>> >>>> >>>> Point-to-point sessions, as described in [RFC5880], >>>> are >>>> of type >>>> PointToPoint. >>>> Does this really fit in Section 4.2 which looks to be >>>> about >>>> the >>>> mpBFD session model. >>>> >>>> GIM>> I think that this short reminder is helpful to explain >>>> why >>>> this document adds value PointToPoint, section 4.4.1, to the >>>> defined in RFC 7880 bfd.sessionType variable. >>>> >>>> Well, I would move the text to 4.4.1 then, but not critical. >>>> >>>> >>>> >>>> >>>> Sessions of type MultipointHead MUST NOT send BFD >>>> control packets >>>> with the State field being set to INIT, and MUST be >>>> ignored on >>>> receipt. >>>> English is not my native language but I wonder if this >>>> really says >>>> what you want. It seems that "Sessions" is the subject o= f >>>> "MUST be >>>> ignored" while I think it's the packets which are the >>>> intended >>>> subject. So I'd write: >>>> and those packets MUST be ignored on receipt. >>>> >>>> You chose to ignore that one or simply missed it? >>>> >>>> >>>> >>>> Because there is no three-way handshake in Multipoin= t >>>> BFD, a newly >>>> started head (that does not have any previous state >>>> information >>>> available) SHOULD start with bfd.SessionState set to >>>> Down and with >>>> bfd.RequiredMinRxInterval set to zero in the >>>> MultipointHead session. >>>> >>>> To shut down a multipoint session a head MUST >>>> administratively set >>>> bfd.SessionState in the MultipointHead session to >>>> either Down or >>>> AdminDown and SHOULD set bfd.RequiredMinRxInterval t= o >>>> zero. The >>>> In both these paragraphs one could read that the head >>>> "SHOULD set >>>> bfd.RequiredMinRxInterval to zero" while 4.4.2 says MUST= . >>>> Clarification needed? >>>> >>>> GIM>> Section 4.4.2 mandates initialization of >>>> bfd.RequiredMinRxInterval and, I think, applies to the first >>>> paragraph you've pointed. Would the following be clear and >>>> consistent: >>>> Because there is no three-way handshake in Multipoint BF= D, >>>> a newly >>>> started head (that does not have any previous state >>>> information >>>> available) SHOULD start with bfd.SessionState set to Dow= n >>>> and >>>> bfd.RequiredMinRxInterval _MUST be_ set to zero in the >>>> MultipointHead session. >>>> The second paragraph describes manipulation with the value of >>>> bfd.RequiredMinRxInterval which process, as noted in section >>>> 4.10, "is outside the scope of this document". That may be >>>> reason to use SHOULD and not MUST. >>>> >>>> Yes, i'd live with that. But then you might also want to clarify = in >>>> 4.4.2. : >>>> OLD: >>>> This variable MUST be set to 0 for session type >>>> MultipointHead. >>>> NEW: >>>> This variable MUST be initialized to 0 for session type >>>> MultipointHead. >>>> >>>> >>>> >>>> >>>> >>>> >>>> s/M, P bit/M and P bits/ >>>> >>>> GIM>> Thanks, done. >>>> >>>> --- >>>> >>>> >>>> >>>> >>> >> --000000000000c0be92056a22355f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Martin,
    thank you for catching this empty reference= . I've looked back and couldn't find any text that describes the in= itialization of the state variable. The new text simply states:
    <= blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px">
    T= his variable MUST be initialized to the appropriate type when the session i= s created.

    Will upload the new version= shortly.

    Regards,
    Greg


    On Wed,= Apr 18, 2018 at 6:22 AM, Martin Vigoureux <martin.vigoureux@noki= a.com> wrote:
    Greg,

    thanks. Sorry, but reading again the document I found:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This variable MUST be initialized to the = appropriate type when
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the session is created, according to the = rules in Section 4.13
    I might have parsed 4.13 (and subsections) too quickly but I did not find a= ny rule regarding the initalization of this variable. Is that indeed the ca= se? If so then I would suggest to simply remove the pointer.

    -m


    Le 2018-04-17 =C3=A0 22:20, Greg Mirsky a =C3=A9crit=C2=A0:
    Hi Martin,
    I've added references to 4.7 and 4.13.2. The new version -15 has been p= ublished.
    Thank you for your help and support.

    Regards,
    Greg

    On Tue, Apr 17, 2018 at 12:31 PM, Martin Vigoureux
    <martin.= vigoureux@nokia.com> wrote:
    Greg,

    I'm fine your proposal below.
    Please post the final update whenever you can.
    Thx

    -m


    Le 2018-04-17 =C3=A0 20:40, Greg Mirsky a =C3=A9crit :

    Hi Martin,
    I have not ignored that comment but missed to ack its acceptance. Two
    other outstanding questions:

    =C2=A0 =C2=A0* the text, that I've misinterpreted earlier, is in the Ov= erview
    section:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Although thi= s document describes a single head and a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0set of tails
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 spanned by a= single multipoint path, the protocol is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0capable of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 supporting (= and discriminating between) more than one
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0multipoint
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 path
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 at both head= s and tails.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 There is no text to descri= be how one could achieve that.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Wouldn't it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be worth adding some?

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GIM>> The question of applicability= of this specification to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mp2mp scenario came up at BIER WG meeting= in London. Perhaps we
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can say the these questions are ouside th= e scope of this
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0document and discuss whether there are in= terested to work on
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mp2mp case as a separete document?

    =C2=A0 =C2=A0 =C2=A0I don't read this part of the document as talking a= bout mp2mp but
    =C2=A0 =C2=A0 =C2=A0rather as talking about multiple p2mp trees.

    =C2=A0 =C2=A0 =C2=A0Sections 4.7 and 4.13.2 provides details on demultiplex= ing BFD
    =C2=A0 =C2=A0 =C2=A0control packets at a MultipointTail. Would the referenc= e to these
    =C2=A0 =C2=A0 =C2=A0sections be sufficient?
    =C2=A0 =C2=A0* yes, moved the reference to Point-to-Point session to sectio= n 4.4.1

    Attached please find the diff between -14 and the working version of the draft. Please let me know if the changes address your comments. Will upload=
    the new version promptly.

    Regards,
    Greg

    On Tue, Apr 17, 2018 at 9:49 AM, Martin Vigoureux
    <martin.= vigoureux@nokia.com <mailto:martin.vigoureux@nokia.com>> wrote:<= br>
    =C2=A0 =C2=A0 =C2=A0Greg,

    =C2=A0 =C2=A0 =C2=A0thanks. please see in-line.

    =C2=A0 =C2=A0 =C2=A0once I see the update published I will request IETF LC.=

    =C2=A0 =C2=A0 =C2=A0-m

    =C2=A0 =C2=A0 =C2=A0Le 2018-04-17 =C3=A0 18:34, Greg Mirsky a =C3=A9crit :<= br>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Martin,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0thank you for your thorough review, thoug= htful comments and kind
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0words.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please find my answers to your questions = in-line and tagged GIM>>.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, Apr 17, 2018 at 8:06 AM, Martin V= igoureux
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<martin.vigoureux@nokia.com <mailto:martin.vigoureux@= nokia.com>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:martin.vigoureux@nokia.com

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:martin.vigoureux@nokia.com>&g= t;> wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [resend, wrong bfd wg addr= ess in first attempt ...]

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

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 thank you for this documen= t. It is clear and well written.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I didn't find any tech= nical comment to make so I've been
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nit picking :-)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Please find those comments= below.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 regards,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 martin

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ---
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Please check and address t= he nits:

    https:= //tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-iet= f-bfd-multipoint-14.txt

    <ht= tps://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft= -ietf-bfd-multipoint-14.txt>

    <ht= tps://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft= -ietf-bfd-multipoint-14.txt

    <ht= tps://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft= -ietf-bfd-multipoint-14.txt>>

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On that aspect, does this = document really update 7880 as
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the header
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 says? The Introduction onl= y refers to 5880 and it is not
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clear in
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the body of the Document w= hat effectively impacts 7880. The
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0only
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 thing I saw is the additio= n of new session types but that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0does not
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 require an update in my op= inion. Could you clarify?
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 GIM>> Yes, you'c= orrect, the only connection to RFC 7880 are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the new
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 values of bfd.sessionType.= The proposal to list RFC 7880 as
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0updated
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 by this specification was = inteded to address Errata to RFC
    7880
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.rfc-editor.org/errata_search.php?rfc=3D7880 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https:/= /www.rfc-editor.org/errata_search.php?rfc=3D7880>>.

    =C2=A0 =C2=A0 =C2=A0I am not sure how this document relates to or addresses= the errata.
    =C2=A0 =C2=A0 =C2=A0So I still think it does not update 7880.


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i.e. existen= ce of a path between the sender and the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0receiver.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 do you mean "forwardi= ng path"?
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 GIM>> Yes. Updated t= o

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i.e. existence of a forwar= ding path between the sender and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the receiver

    =C2=A0 =C2=A0 =C2=A0thx


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Section 2. and Section 3. = seem a bit redundant. They both
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0state the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 same thing but from a diff= erent angle. Not critical.


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Although thi= s document describes a single head and a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0set of tails
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 spanned by a= single multipoint path, the protocol is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0capable of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 supporting (= and discriminating between) more than one
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0multipoint
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 path
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 at both head= s and tails.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 There is no text to descri= be how one could achieve that.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Wouldn't it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be worth adding some?

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GIM>> The question of applicability= of this specification to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mp2mp scenario came up at BIER WG meeting= in London. Perhaps we
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can say the these questions are ouside th= e scope of this
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0document and discuss whether there are in= terested to work on
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mp2mp case as a separete document?

    =C2=A0 =C2=A0 =C2=A0I don't read this part of the document as talking a= bout mp2mp but
    =C2=A0 =C2=A0 =C2=A0rather as talking about multiple p2mp trees.




    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Point-to-poi= nt sessions, as described in [RFC5880], are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of type
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 PointToPoint= .
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Does this really fit in Se= ction 4.2 which looks to be about
    the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mpBFD session model.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GIM>> I think that this short remin= der is helpful to explain why
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this document adds value PointToPoint, se= ction 4.4.1, to the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0defined in RFC 7880 bfd.sessionType varia= ble.

    =C2=A0 =C2=A0 =C2=A0Well, I would move the text to 4.4.1 then, but not crit= ical.




    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sessions of = type MultipointHead MUST NOT send BFD
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0control packets
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with the Sta= te field being set to INIT, and MUST be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ignored on
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 receipt.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 English is not my native l= anguage but I wonder if this
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0really says
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 what you want. It seems th= at "Sessions" is the subject of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"MUST be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ignored" while I thin= k it's the packets which are the
    intended
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 subject. So I'd write:=
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and those pa= ckets MUST be ignored on receipt.

    =C2=A0 =C2=A0 =C2=A0You chose to ignore that one or simply missed it?



    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Because ther= e is no three-way handshake in Multipoint
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD, a newly
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 started head= (that does not have any previous state
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0information
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 available) S= HOULD start with bfd.SessionState set to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Down and with
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bfd.Required= MinRxInterval set to zero in the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MultipointHead session.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 To shut down= a multipoint session a head MUST
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0administratively set
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bfd.SessionS= tate in the MultipointHead session to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0either Down or
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 AdminDown an= d SHOULD set bfd.RequiredMinRxInterval to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0zero.=C2=A0 The
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In both these paragraphs o= ne could read that the head
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"SHOULD set
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bfd.RequiredMinRxInterval = to zero" while 4.4.2 says MUST.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Clarification needed?

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GIM>> Section 4.4.2 mandates initia= lization of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bfd.RequiredMinRxInterval and, I think, a= pplies to the first
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0paragraph you've pointed. Would the f= ollowing be clear and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0consistent:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Because there is no three-= way handshake in Multipoint BFD,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a newly
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 started head (that does no= t have any previous state
    information
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 available) SHOULD start wi= th bfd.SessionState set to Down and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bfd.RequiredMinRxInterval = _MUST be_ set to zero in the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MultipointHead session.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The second paragraph describes manipulati= on with the value of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bfd.RequiredMinRxInterval which process, = as noted in section
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04.10, "is outside the scope of this = document". That may be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reason to use SHOULD and not MUST.

    =C2=A0 =C2=A0 =C2=A0Yes, i'd live with that. But then you might also wa= nt to clarify in
    =C2=A0 =C2=A0 =C2=A04.4.2. <http://4.4.2.>:
    =C2=A0 =C2=A0 =C2=A0OLD:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This variable MUST b= e set to 0 for session type
    =C2=A0 =C2=A0 =C2=A0MultipointHead.
    =C2=A0 =C2=A0 =C2=A0NEW:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This variable MUST b= e initialized to 0 for session type
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MultipointHead.






    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 s/M, P bit/M and P bits/
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GIM>> Thanks, done.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ---






    --000000000000c0be92056a22355f-- From nobody Wed Apr 18 09:59:49 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 95729127137; Wed, 18 Apr 2018 09:59:36 -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-16.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152407077657.13802.17412181383864731754@ietfa.amsl.com> Date: Wed, 18 Apr 2018 09:59:36 -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: Wed, 18 Apr 2018 16:59:37 -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-16.txt Pages : 18 Date : 2018-04-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-16 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-multipoint-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-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/